Использование локальных растянутых кластеров Azure для аварийного восстановления

В следующей эталонной архитектуре показано, как разработать и реализовать аварийное восстановление локальной среды Azure с помощью растянутой кластеризации.

Архитектура

Скачайте файл Visio этой архитектуры.

Компоненты

Архитектура включает следующие компоненты и возможности:

• Azure Stack HCI версии 22H2. локальной Azure — это решение кластера гиперконвергентной инфраструктуры (HCI), которое можно использовать для размещения виртуализированных рабочих нагрузок Windows и Linux и их хранилища в гибридной локальной среде. Вы можете настроить растянутый кластер с 4-16 физическими узлами.
• реплике хранилища. Реплика хранилища — это технология Windows Server, которая обеспечивает репликацию томов между серверами или кластерами для аварийного восстановления.
• динамической миграции. Динамическая миграция — это функция Hyper-V в Windows Server, которая позволяет легко перемещать виртуальные машины с одного узла Hyper-V на другой без предполагаемого простоя.
• облачный свидетель. Cloud Witness — это свидетель кворума отказоустойчивого кластера, использующий хранилище BLOB-объектов Microsoft Azure для предоставления голосования по кворуму кластера.

Сведения о сценарии

Обычно эта архитектура используется для аварийного восстановления с автоматической отработкой отказа локальных виртуальных машин Azure и общих папок между двумя физическими расположениями в диапазоне от 5 мс до задержки сети кругового пути.

Рекомендации

Следующая рекомендация применяется для большинства сценариев. Следуйте рекомендациям, если у вас нет определенного требования, которое переопределяет его.

Использование растянутых кластеров для реализации автоматического аварийного восстановления для виртуализированных рабочих нагрузок и общих папок, размещенных в локальной среде Azure

Чтобы повысить устойчивость локальной среды Azure, реализуйте растянутый локальный экземпляр Azure, состоящий из двух групп узлов с одной группой на сайт. Каждая группа должна содержать не менее двух узлов. Общее количество узлов в кластере не может превышать максимальное количество узлов, поддерживаемых локальным экземпляром Azure. Узлы должны соответствовать стандартным требованиям оборудования HCI.

Растянутый локальный экземпляр Azure использует реплику хранилища для выполнения синхронной репликации хранилища между томами хранилища, размещенными двумя группами узлов на соответствующих физических сайтах. Если сбой влияет на доступность первичного сайта, кластер автоматически перемещает рабочие нагрузки на узлы на выживших сайтах, чтобы свести к минимуму потенциальное время простоя. Для запланированных или ожидаемых простоев на основном сайте можно использовать Hyper-V Live Migration для простоя рабочих нагрузок на другой сайт, избегая простоя в целом. В этом сценарии следует учитывать расположение хранилища. Сначала следует изменить направление репликации для реплики хранилища, а затем выполнить динамическую миграцию виртуальных машин. До завершения динамической миграции производительность будет влиять на производительность.

Соображения

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для повышения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Надёжность

Надежность гарантирует, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Дополнительные сведения см. в контрольном списке проверки конструктора длянадежности.

• Домены сбоя уровня сайта. Каждый физический сайт локального растянутого кластера Azure представляет отдельные домены сбоя, обеспечивающие дополнительную устойчивость. Домен сбоя — это набор аппаратных компонентов, которые совместно используют одну точку сбоя. Чтобы быть отказоустойчивым к определенному уровню, вам потребуется несколько доменов сбоя на этом уровне.

• Осведомленность о сайте. Осведомленность о сайте позволяет управлять размещением виртуализированных рабочих нагрузок, назначая их предпочитаемые сайты. Указание предпочтительного сайта для растянутого кластера дает множество преимуществ, включая возможность группировать рабочие нагрузки на уровне сайта и настраивать параметры голосования кворума. По умолчанию во время холодного запуска все виртуальные машины используют предпочтительный сайт, хотя также можно настроить предпочтительный сайт на уровне роли кластера или группы. Это позволяет выделить определенные виртуальные машины соответствующим сайтам в активно-активном режиме. С точки зрения кворума, предпочтительный выбор сайта влияет на выделение голосов таким образом, чтобы благоприястить этот сайт. Например, если подключение между двумя сайтами, на которых размещаются растянутые узлы кластера, завершается сбоем, и свидетель кластера недоступен, предпочтительный сайт остается в сети, а узлы на другом сайте вытеснимы.

• Улучшена скорость восстановления локальных дисковых пространств. Локальные дисковые пространства обеспечивают автоматическую повторную синхронизацию после событий, влияющих на доступность дисков в пуле носителей, таких как завершение работы одного из узлов кластера или локализованный сбой оборудования. Локальный azure реализует расширенный процесс повторной синхронизации, который работает на гораздо более детальном уровне, чем Windows Server 2019. Этот процесс значительно сокращает продолжительность операции повторной синхронизации и сводит к минимуму потенциальное влияние нескольких перекрывающихся сбоев оборудования.

• Ограничения устойчивости. Azure Local предоставляет несколько уровней устойчивости, но из-за его гиперконвергентной архитектуры, что устойчивость подвержена ограничениям, введенным не только кворума кластера, но и кворум пула.

• Интеграция с рядом служб Azure, которые обеспечивают дополнительные преимущества устойчивости. Вы можете интегрировать виртуализированные рабочие нагрузки, выполняемые в локальных экземплярах Azure, с такими службами Azure, как Azure Backup и Azure Site Recovery.

• Ускорение отработки отказа. Вы можете оптимизировать сетевую инфраструктуру и ее конфигурацию, чтобы ускорить завершение отработки отказа на уровне сайта. Например, можно использовать растянутые виртуальные локальные сети (VLAN), устройства абстракции сети и более короткие значения времени жизни (TTL) в записях DNS, представляющих кластеризованные ресурсы. Кроме того, рекомендуется снизить период устойчивости по умолчанию, который определяет период времени, в течение которого кластеризованная виртуальная машина может выполняться в изолированном состоянии.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в контрольном списке конструктора длябезопасности.

• Защита при передаче. Реплика хранилища обеспечивает встроенную безопасность для трафика репликации, включающую подписывание пакетов, полное шифрование данных AES-128-GCM, поддержку ускорения шифрования Intel AES-NI и защиту целостности подлинности до проверки подлинности. Реплика хранилища также использует Kerberos AES256 для проверки подлинности между узлами репликации.

• Шифрование неактивных данных. Azure Local поддерживает шифрование дисков BitLocker для своих томов данных, что способствует соответствию таким стандартам, как FIPS 140-2 и HIPAA.

• Интеграция с рядом служб Azure, которые обеспечивают дополнительные преимущества безопасности. Вы можете интегрировать виртуализированные рабочие нагрузки, работающие в локальных экземплярах Azure, с такими службами Azure, как Microsoft Defender для cloud

• Конфигурация, удобная для брандмауэра. Для трафика реплики хранилища требуется ограниченное количество открытых портов между реплицируемыми узлами.

Оптимизация затрат

Оптимизация затрат заключается в том, чтобы подумать о способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке конструктора дляоптимизации затрат.

• Конфигурация "активный—активный" и "активный- пассивный". Растянутые локальные экземпляры Azure поддерживают режимы "активный-пассивный" и "активный- активный". В активно-пассивном режиме назначенный первичный сайт однонаправленно реплицируется на другой сайт, предоставляющий возможность аварийного восстановления. В активном режиме два сайта реплицируют соответствующие тома в однонаправленном режиме, обеспечивая возможность отработки отказа в случае сбоя на любом сайте. Режим "активный— активный" помогает свести к минимуму затраты на непрерывность бизнес-процессов, устраняя необходимость выделенного сайта аварийного восстановления.

• Облако-свидетель и файловый ресурс-свидетель. Ресурс-свидетель является обязательным компонентом в локальных экземплярах Azure. Чтобы реализовать его, выберите облачный свидетель Azure или следящий файловый ресурс. Облачный свидетель Azure использует большой двоичный объект в учетной записи хранения Azure, которую вы назначаете в качестве точки арбитража, чтобы предотвратить сценарии разделения мозга. Следящий файловый ресурс использует общую папку "Блок сообщений сервера" (SMB) для достижения той же цели.

• Дедупликация данных. Локальная и реплика хранилища Azure поддерживают дедупликацию данных. Начиная с Windows Server 2019 дедупликация доступна в томах, отформатированных с помощью отказоустойчивой файловой системы (ReFS), которая является рекомендуемой файловой системой для локальной службы Azure. Дедупликация помогает увеличить емкость хранилища, определяя повторяющиеся части файлов и сохраняя их только один раз.

Операционное превосходство

Операционное превосходство охватывает процессы, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в контрольном списке проверки конструктора дляоперационного превосходства.

• Автоматическая отработка отказа и восстановление. Сбой первичного сайта активирует автоматическую отработку отказа. После отработки отказа процесс установки репликации с нового первичного или бывшего вторичного сайта обратно на новый вторичный или бывший первичный сайт также является автоматическим. Чтобы предотвратить потенциальную потерю данных, кластер предотвращает восстановление размещения до полной синхронизации реплицированных томов.

• Упрощенная подготовка и управление с помощью Windows Admin Center. Мастер создания кластера в Windows Admin Center предоставляет управляемый мастером интерфейс, который поможет вам создать локальный растянутый кластер Azure. Мастер определяет, находятся ли узлы кластера на двух разных сайтах доменных служб Active Directory (AD DS) или принадлежат ли их IP-адреса двум разным подсетям. Если они находятся в двух разных подсетях, мастер автоматически создает и настраивает соответствующие сайты кластера с каждым из которых представляет отдельный домен сбоя. Он также позволяет назначить предпочтительный сайт. Аналогичным образом Windows Admin Center упрощает процесс подготовки реплицированных томов.

• Поддержка автоматизированной подготовки растянутого кластера и управления хранилищами с помощью Windows PowerShell. PowerShell можно запускать локально с одного из локальных компьютеров Azure или удаленно с компьютера управления.

• Интеграция с рядом служб Azure, которые обеспечивают дополнительные операционные преимущества. Вы можете интегрировать виртуализированные рабочие нагрузки, работающие в локальных экземплярах Azure, с такими службами Azure, как Azure Monitor и решения службы автоматизации Azure, включая отслеживание изменений и инвентаризацию и управление обновлениями. После первоначальной обязательной регистрации локальные экземпляры Azure могут использовать Azure Arc для мониторинга и выставления счетов. Интеграция Azure Arc обеспечивает расширенную интеграцию с другими гибридными службами, например политики Azure и Log Analytics. Регистрация активирует создание ресурса Azure Resource Manager, представляющего локальный экземпляр Azure, эффективно расширяя уровень управления Azure на локальный.

Эффективность производительности

Эффективность производительности — это возможность вашей рабочей нагрузки отвечать требованиям, заданным пользователями. Дополнительные сведения см. в контрольном списке проверки конструктора дляпроизводительности.

• Оптимизированный трафик репликации. При разработке инфраструктуры для локальных растянутых кластеров Azure рассмотрите дополнительные реплики хранилища, динамической миграции и журнала производительности кластера хранилища, поступающие между сайтами. Для синхронной репликации требуется по крайней мере 1 ГБ удаленного прямого доступа к памяти (RDMA) или Ethernet/TCP-подключение между растянутыми сайтами кластера. Однако в зависимости от объема трафика репликации может потребоваться более быстрыйподключения RDMA. Вы также должны подготовить несколько подключений между сайтами, что обеспечивает преимущества устойчивости и позволяет отдельный трафик реплики хранилища от Hyper-V потоковой миграции.

• поддержка начальной синхронизации. Можно реализовать начальную синхронизацию в сценариях, когда начальное время синхронизации необходимо свести к минимуму или где между двумя сайтами, на которых размещен растянутый кластер, ограничена пропускная способность.

• Оптимизированная обработка операций ввода-вывода хранилища. Убедитесь, что оптимальную конфигурацию реплицированных данных и томов журналов, включая их уровень производительности, размер тома и сектора, тип диска и файловую систему.

Дальнейшие действия

• Обзор локального решения Azure
• кластеризация отработки отказа в Windows Server и локальном Azure
• развертывание облачного следящего сервера для отказоустойчивого кластера
• Новые возможности локальной Azure
• локальные вопросы и ответы по Azure

Связанные ресурсы

• проектирование гибридной архитектуры
• гибридные параметры Azure
• Использование локального переключения и упрощенного кворума для удаленного офиса или филиала
• Оптимизация администрирования экземпляров SQL Server в локальных и многооблачных средах с помощью Azure Arc
• конфигурации состояния автоматизации Azure