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

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

Архитектура

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

Компоненты

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

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

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

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

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

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

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

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

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

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

Microsoft Azure Well-Architected Framework — это набор руководящих принципов, которым следуют в этой эталонной архитектуре. Следующие рекомендации представлены в контексте этих принципов.

надежность;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

эффективность работы;

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

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

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

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

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

Уровень производительности

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

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

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

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

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

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

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

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