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

  • Статья

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

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

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

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

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

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

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

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

Растянутый кластер "активный — пассивный"

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

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

Растянутый кластер "активный — активный"

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

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

Рекомендации по отработки отказа гостевого IP-адреса

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

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

Далее следует использовать статический адрес. Однако, в отличие от реплики 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 и т. д.) при подключении клиента и должны быть тщательно продуманы. Обратитесь к команде по работе с сетями, чтобы определить оптимальный вариант для удовлетворения ваших потребностей.

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