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


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

Область применения: локальная версия Azure, версия 22H2

Внимание

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

Внимание

Растянутые кластеры пока не поддерживаются в Azure Stack HCI версии 23H2.

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

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

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

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

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

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

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

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

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

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

Растянутый кластер active

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

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