Прочитать на английском

Поделиться через

Общие сведения о растянутых кластерах

  • Статья

Область применения: Azure Stack HCI версии 22H2

Важно!

Azure Stack HCI теперь является частью Azure Local. Однако старые версии Azure Stack HCI, например 22H2, будут продолжать ссылаться на Azure Stack HCI и не отражают изменение имени. Подробнее.

Важно!

Растянутые кластеры не поддерживаются в локальной среде Azure.

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

Реплика хранилища поддерживает синхронную и асинхронную репликацию:

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

Существует два типа растянутых кластеров: активно-пассивные и активно-активные. Вы можете настроить активно-пассивную репликацию, где есть предпочтительный сайт и предпочтительное направление репликации. Репликация «активный-активный» предполагает, что репликация может выполняться в двух направлениях с каждой из сторон. В этой статье рассматриваются только активные и пассивные конфигурации.

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

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

Чтобы просмотреть видео о растянутой кластеризации с помощью Azure Stack HCI, сделайте несколько минут:

Кластер с активным и пассивным растяжением

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

Сценарий активного или пассивного растянутого кластера.

Активно-активный растянутый кластер

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

Сценарий активного или активного растянутого кластера

Соображения по отказоустойчивости гостевых IP-адресов

При обсуждении растянутой кластеризации одним из факторов, которые необходимо учитывать, это виртуальные машины и используемые IP-адреса. Центры обработки данных, которые находятся в разных расположениях, обычно имеют разные IP-подсети. IP-адреса, используемые виртуальными машинами, будут хорошими для одного центра обработки данных, но недоступны в другом. Таким образом, планирование того, как справляться с изменениями IP-адресов, должно быть учтено. Как правило, существует четыре разных способа изменения IP-адреса виртуальной машины при переключении на резервный сервер. Там могут быть другие, но эта статья охватывает первые четыре.

Первое и самое простое — использование DHCP. При перемещении виртуальной машины с одного сайта на другой виртуальная машина запрашивает DHCP-адрес. До тех пор пока доступен DHCP-сервер, можно получить правильный IP-адрес для сети, в которой находится сайт.

Далее используется статический адрес. Однако, в отличие от реплики Hyper-V, нет способа указать альтернативный IP-адрес. Поэтому необходимо создать скрипт, чтобы назначить правильный IP-адрес виртуальной машины в зависимости от того, на каком сайте он находится. Например, SiteA использует сеть 1.x, а SiteB использует сеть 156.x. Этот скрипт должен определить сеть, в которую находится виртуальная машина, и задать схему IP-адресов 1.x, если она находится в SiteA или схеме IP-адресов 156.x, если она находится в SiteB. Службы доменных имен (DNS) также должны быть оповещены об изменении и реплицированы между сайтами.

Другим вариантом является использование промежуточного сетевого устройства, которое предоставляет один IP-адрес виртуальной машины для подключения клиента, который может направлять трафик на виртуальную машину. Клиенты и DNS всегда имеют одинаковый адрес для виртуальной машины, а промежуточное устройство должно отслеживать фактический IP-адрес и расположение виртуальной машины, чтобы клиенты направлялись на виртуальную машину соответствующим образом.

Последним вариантом является использование растянутой виртуальной локальной сети. При использовании растянутой виртуальной локальной сети виртуальные машины могут хранить один и тот же IP-адрес независимо от сайта, на который он находится. Однако из-за некоторых сложностей настройки и обслуживания растянутой виртуальной локальной сети этот параметр не рекомендуется корпорацией Майкрософт.

При использовании любого из указанных выше вариантов необходимо учитывать дополнительные факторы (DNS, кэши ARP, TTL и т. д.) при подключении клиентов и продумать их тщательно. Обратитесь к вашей сетевой команде, чтобы определить наилучший вариант, который соответствует вашим нуждам.

Следующие шаги