Проектирование растянутых кластеров vSAN

Из этой статьи вы узнаете, как разработать растянутый кластер vSAN для частного облака Решение Azure VMware.

Общие сведения

Глобальная инфраструктура Azure разбита на регионы. Каждый регион поддерживает службы для заданного географического региона. В каждом регионе Azure создает изолированные и избыточные острова инфраструктуры, называемые зонами доступности (AZ). AZ выступает в качестве границы для управления ресурсами. Вычислительные ресурсы и другие ресурсы, доступные для AZ, являются конечными и могут быть исчерпаны требованиями клиентов. AZ создаётся так, чтобы быть независимой и устойчивой, что означает, что сбои в одном AZ не влияют на другие AZ.

При использовании Решение Azure VMware узлы ESXi, развернутые в стандартном кластере vSphere, традиционно находятся в одной зоне доступности Azure (AZ) и защищены высоким уровнем доступности vSphere (HA). Однако он не защищает рабочие нагрузки от сбоя Azure AZ. Чтобы защититься от сбоя AZ, один кластер vSAN можно включить для охвата двух отдельных зон доступности, называемых растянутым кластером vSAN.

Растянутые кластеры позволяют настроить домены отказа vSAN в двух зонах доступности (AZ), чтобы уведомить vCenter Server о том, что узлы находятся в каждой зоне доступности. Каждый домен сбоя называется в честь зоны доступности (AZ), в которой он находится, чтобы повысить ясность. Если вы растянете кластер vSAN между двумя зонами доступности (AZ) в регионе, и если одна из зон доступности выйдет из строя, это будет обработано как событие высокой доступности vSphere, и виртуальная машина будет перезапущена в другой зоне доступности.

Преимущества растянутого кластера:

  • Повышение доступности приложений.
  • Предоставьте возможность нулевой точки восстановления (RPO) для корпоративных приложений без необходимости их перепроектирования или развертывания дорогостоящих решений аварийного восстановления (DR).
  • Частное облако с растянутыми кластерами предназначено для обеспечения доступности 99,99 % из-за ее устойчивости к сбоям AZ.
  • Позволяет клиентам сосредоточиться на основных требованиях и функциях приложений, а не на доступности инфраструктуры.

Для защиты от сценариев 'split-brain' и оценки работоспособности сайта в третьей AZ создается управляемый vSAN Witness. При копировании данных в каждом AZ vSphere HA пытается восстановиться после любого сбоя с помощью простого перезапуска виртуальной машины.

На следующей схеме показан кластер vSAN, растянутый по двум AZ.

На схеме показан управляемый растянутый кластер vSAN, созданный в третьей зоне доступности с данными, скопированными во все три.

На следующей схеме показан обычный поток сетевого трафика в кластере vSAN, растянутый по двум AZ.

На схеме показаны потоки трафика VMware NSX для управляемого растянутого кластера vSAN.

В итоге растянутые кластеры упрощают потребности в защите, предоставляя те же доверенные элементы управления и возможности в дополнение к масштабу и гибкости инфраструктуры Azure.

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

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

      На следующей схеме показан сценарий секционирования вторичного сайта.

      На диаграмме показано, как vSphere High Availability отключает питание виртуальных машин с рабочей нагрузкой на вторичном сайте.

    • Если во время секционирования вторичного сайта произошел сбой на основном сайте или произошло полное секционирование, vSphere HA попытается перезапустить виртуальные машины рабочей нагрузки на вторичном сайте. Если vSphere HA попытается перезапустить виртуальные машины рабочей нагрузки на вторичном сайте, это приведёт к их нестабильному состоянию.

      На следующих схемах показаны предпочтительный сценарий отказа сайта и полные сценарии разделения сети.

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

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

      На следующей схеме показан поток сетевого трафика в кластере vSAN, растянутый во время полного сбоя сайта.

      На схеме показаны потоки трафика VMware NSX для управляемого растянутого кластера vSAN во время полного сбоя сайта.

Следует отметить, что эти типы сбоев, хотя и редки, выходят за пределы области защиты, предоставляемой растянутыми частным облаком кластера. Из-за таких редких сбоев решение растянутого кластера должно рассматриваться как решение высокого уровня доступности multi-AZ, зависяющее от высокой доступности vSphere HA. Решение с растянутым кластером не предназначено для замены комплексной стратегии аварийного восстановления в нескольких регионах, которая может использоваться для обеспечения доступности приложений. Причина заключается в том, что решение аварийного восстановления обычно имеет отдельные плоскости управления и контроля в отдельных регионах Azure. Решение Azure VMware Solution stretched clusters обладает единой плоскостью управления и контроля, растянутой между двумя зонами доступности в одном регионе Azure. Например, один сервер vCenter Server, один кластер NSX Manager, одна пара виртуальных машин Microsoft Edge NSX.

Доступность растянутых кластеров по регионам

Решение Azure VMware для растянутых кластеров доступно в следующих регионах:

  • Южная Часть Великобритании (на AV36 и AV36P)

  • Западная Европа (на AV36 и AV36P)

  • Германия Западно-Центральная (на AV48)

  • Восточная Австралия (AV36P)

  • Восточная часть США (av36P)

Поддерживаемые политики хранения

Следующие политики SPBM поддерживаются с PFTT "Двойное зеркалирование сайтов" и SFTT с "RAID 1 (зеркалирование)", установленных как основные политики по умолчанию для кластера.

  • Параметры отказоустойчивости сайта (PFTT):
    • Дублированное отображение двух сайтов
    • Нет. Хранение данных в предпочтительном режиме
    • Нет . Сохранение данных в непреднаставленных
  • Допустимые локальные сбои (SFTT):
    • Один отказ — RAID 1 (зеркальное отображение)
    • 1 сбой — RAID 5 (кодирование стирания), требуется не менее четырех узлов в каждой Зоне доступности (AZ)
    • 2 сбоя — RAID 1 (зеркалирование)
    • 2 сбоя — RAID 6 (кодирование стиранием), требуется не менее шести узлов в каждой зоне доступности
    • 3 сбоя — RAID 1 (зеркалирование)

Вопросы и ответы

Планируется ли какой-либо другой регион?

В настоящее время существует пять регионов, поддерживаемых для растянутых кластеров.

Какое соглашение об уровне обслуживания предоставляет решение Azure VMware для распределенных кластеров?

Частное облако, созданное с помощью растянутого кластера vSAN, предназначено для предоставления обязательств по доступности инфраструктуры 99,99 % при наличии следующих условий:

  • В кластере развертываются не менее шести узлов (3 в каждой зоне доступности).
  • Когда виртуальные машины рабочей нагрузки используют политику хранилища виртуальных машин с PFTT в режиме "двухсайтовое зеркальное отображение" и SFTT, равным 1.
  • Для достижения целей доступности требуется соответствие дополнительным требованиям, приведенным в сведениях об уровне обслуживания Решение Azure VMware.

Можно ли выбрать зону доступности, в которой развертывается частное облако?

№ Растянутый кластер создается между двумя зонами доступности, а третья зона используется для развертывания следящего узла. Так как все зоны эффективно используются для развертывания растянутой кластерной среды, выбор не предоставляется клиенту. Вместо этого клиент выбирает развертывание узлов в нескольких AZ во время создания частного облака.

Каковы ограничения, о которых я должен знать?

  • После создания частного облака с растянутыми кластерами его нельзя изменить на стандартное частное облако кластера. Аналогичным образом, стандартное частное облако кластера не может быть изменено на растянутое частное облако кластера после создания.
  • Масштабирование растянутых кластеров, включая увеличение и уменьшение размеров, может выполняться только в парах. В растянутой среде кластера поддерживается не менее шести узлов и не более 16 узлов. Дополнительные сведения см. в статье Подписка Azure, границы, квоты и ограничения службы.
  • Виртуальные машины рабочей нагрузки клиента перезапускаются с средним приоритетом для vSphere HA. Виртуальные машины управления имеют самый высокий приоритет перезапуска.
  • Решение использует vSphere HA и vSAN для перезапусков и репликации. Цель времени восстановления (RTO) определяется продолжительностью времени, за которое vSphere HA перезапускает виртуальную машину на выжившей AZ после сбоя одной AZ.
  • В настоящее время не поддерживается в растянутой среде кластера:
    • Недавно выпущенные функции, такие как возможность выделения общедоступных IP-адресов для NSX Microsoft Edge и использование внешних хранилищ, например, хранилищ данных ANF.
    • Надстройки аварийного восстановления, такие как VMware SRM, Zerto и JetStream.
    • NSX Edge Scale-OUT для добавления дополнительных NSX Edge в настоящее время не поддерживается.
  • Откройте запрос в службу поддержки из портал Azure для следующих сценариев (обязательно выберите растянутые кластеры в качестве типа проблемы):
    • Подключите частное облако к частному облаку в растянутом кластере.
    • Подключите два частных облака в растянутом кластере.

Замечание

Взаимное соединение для решения Azure VMware между растянутыми кластерами частных облаков поддерживается только в том случае, если оба растянутых кластера размещены в одном наборе pod или если у них нет общих pod. Поддержка отсутствует, если частное облако использует только один общий pod.

Какие задержки следует ожидать между зонами доступности (AZs)?

Растянутые кластеры vSAN работают при времени задержки в пределах 5 миллисекунд и пропускной способности 10 Гб/с или большей между AZ, на которых размещены виртуальные машины рабочей нагрузки. Развертывание решения Azure VMware для растянутого кластера следует этому принципу. Учитывайте эту информацию при развертывании приложений (с двухсайтовым зеркальным отображением, при использовании синхронных записей), которые имеют строгие требования к задержке.

Можно ли смешивать растянутые и стандартные кластеры в частном облаке?

№ Сочетание растянутых и стандартных кластеров не поддерживается в одном частном облаке. При создании частного облака выбрана растянутая или стандартная среда кластера. После создания частного облака с растянутыми кластерами предполагается, что все кластеры, созданные в этом частном облаке, растягиваются по природе.

Сколько стоит решение?

Клиентам взимается плата в зависимости от количества узлов, развернутых в частном облаке.

Взимается ли плата за узел-свидетель и трафик между AZ?

№ Клиенты не видят плату за узел-свидетель и трафик inter-AZ. Узел-свидетель полностью управляется службой, и Решение Azure VMware обеспечивает необходимое управление жизненным циклом узла-свидетеля. Поскольку все решение управляется как услуга, клиенту нужно только определить соответствующую политику SPBM для виртуальных машин, используемых в рабочей нагрузке. Остальные управляются корпорацией Майкрософт.