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

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

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

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

• Дополнительные сведения о реплике хранилища. Обзор реплики хранилища.
• Узнайте больше об использовании реплики хранилища. См. статью "Настройка отказоустойчивого кластера Hyper-V" или файлового сервера для кластера общего использования.
• Узнайте об оборудовании и других требованиях к растянутых кластерам. См . требования к системе.
• Узнайте, как развернуть растянутый кластер с помощью Windows Admin Center. См. статью "Создание кластера с помощью Центра администрирования Windows".
• Узнайте, как развернуть растянутый кластер с помощью PowerShell. См. статью "Создание кластера с помощью PowerShell".
• Узнайте, как создавать тома и настраивать репликацию для растянутых кластеров. См. статью "Создание томов" и настройка репликации для растянутых кластеров.