Архитектура аварийного восстановления из Hyper-V в Azure

Эта статья описывает архитектуру и процессы, используемые при репликации, отработке отказа и восстановлении виртуальных машин (ВМ) Hyper-V между локальными узлами Hyper-V и Azure с помощью службы Azure Site Recovery.

Узлы Hyper-V могут управляться в частных облаках System Center Virtual Machine Manager (VMM).

Компоненты архитектуры — Hyper-V без VMM

Таблица и рисунок ниже позволяют получить общее представление о компонентах, используемых для репликации Hyper-V в Azure, когда узлы Hyper-V не управляются VMM.

Компонент Требование Подробности
Azure Подписка Azure, учетная запись хранения Azure и сеть Azure. Реплицированные данные из локальных рабочих нагрузок ВМ хранятся в учетной записи хранения. Виртуальные машины Azure создаются с использованием реплицированных данных рабочих нагрузок при отработке отказа с локального сайта.

При создании виртуальные машины Azure подключаются к виртуальной сети Azure.
Hyper-V Во время развертывания Site Recovery вы собираете узлы и кластеры Hyper-V в сайты Hyper-V. Установите поставщик Azure Site Recovery и агент служб восстановления на каждом отдельном хосте Hyper-V или на каждом узле кластера Hyper-V. Поставщик оркестрирует репликацию через Интернет с помощью службы Site Recovery. Агент служб восстановления обрабатывает репликацию данных.

Обмен данными между поставщиком и агентом осуществляется по защищенным и зашифрованным каналам. Реплицированные данные в службе хранилища Azure также шифруются.
Виртуальные машины Hyper-V На Hyper-V выполняется одна или несколько виртуальных машин. На виртуальных машинах не нужно ничего устанавливать явным образом.

Архитектура: из Hyper-V в Azure (без VMM)

Diagram showing on-premises Hyper-V site to Azure architecture without VMM.

Компоненты архитектуры — Hyper-V с VMM

Таблица и рисунок ниже позволяют получить общее представление о компонентах, используемых для репликации Hyper-V в Azure, когда узлы Hyper-V управляются в облаках VMM.

Компонент Требование Подробности
Azure Подписка Azure, учетная запись хранения Azure и сеть Azure. Реплицированные данные из локальных рабочих нагрузок ВМ хранятся в учетной записи хранения. Виртуальные машины Azure создаются с использованием реплицированных данных при отработке отказа с локального сайта.

При создании виртуальные машины Azure подключаются к виртуальной сети Azure.
Сервер VMM Сервер VMM содержит одно или несколько облаков с узлами Hyper-V. На сервере VMM устанавливается поставщик Site Recovery для оркестрации репликации с Site Recovery, а сам сервер регистрируется в хранилище служб восстановления.
Узел Hyper-V Один или несколько кластеров (узлов) Hyper-V под управлением VMM. Установите агент служб восстановления на каждом узле Hyper-V или узле кластера.
Виртуальные машины Hyper-V Хотя бы одна виртуальная машина, запущенная на сервере узла Hyper-V. На виртуальных машинах не нужно ничего устанавливать явным образом.
Сеть Логическая сеть и сеть виртуальных машин, настроенные на сервере VMM. Сеть виртуальных машин должна быть связана с логической сетью, которая сопоставлена с облаком. Сети виртуальных машин сопоставляются с виртуальными сетями Azure. При создании виртуальных машин Azure после отработки отказа они добавляются в сеть Azure, сопоставленную с сетью виртуальных машин.

Архитектура: из Hyper-V в Azure (с VMM)

Diagram showing on-premises Hyper-V site to Azure architecture with VMM.

Настройка исходящих сетевых подключений

Чтобы служба Site Recovery работала должным образом, необходимо модифицировать исходящее сетевое подключение, так, чтобы оно позволило вашей среде делать репликацию.

Примечание.

Site Recovery не поддерживает использование прокси-сервер проверки подлинности для управления сетевым подключением.

Исходящие подключения для URL-адресов

При использовании прокси-сервера или брандмауэра на основе URL-адресов для управления исходящими подключениями разрешите использование этих URL-адресов:

Название Коммерческие организации Государственный сектор Description
Хранилище *.blob.core.windows.net *.blob.core.usgovcloudapi.net Позволяет записывать данные из виртуальной машины в учетную запись хранения кэша в исходном регионе.
ИД Microsoft Entra login.microsoftonline.com login.microsoftonline.us Обеспечивает авторизацию и проверку подлинности URL-адресов службы Site Recovery.
Репликация *.hypervrecoverymanager.windowsazure.com *.hypervrecoverymanager.windowsazure.com Позволяет виртуальной машине взаимодействовать со службой Site Recovery.
Cлужебная шина *.servicebus.windows.net *.servicebus.usgovcloudapi.net Позволяет виртуальной машине записывать данные мониторинга и диагностики службы Site Recovery.

Процесс репликации

Diagram showing the Hyper-V to Azure replication process

Процедура репликации и восстановления

Включить защиту

  1. После включения защиты для виртуальных машин Hyper-V на портале Azure или локально запустится рабочий процесс Включение защиты.
  2. Это задание проверяет, соответствует ли компьютер необходимым требованиям перед вызовом метода CreateReplicationRelationship, который настраивает репликацию, используя определенные вами параметры.
  3. Задание запускает начальную репликацию, вызывая метод StartReplication, чтобы инициализировать полную репликацию виртуальной машины и отправить ее виртуальные диски в Azure.
  4. Задание можно отслеживать на вкладке "Задания ". Screenshot of the jobs list in the Jobs tab.Screenshot of the Enable protection screen with more details.

Начальная репликация данных

  1. При запуске начальной репликации создается моментальный снимок виртуальной машины Hyper-V.
  2. Виртуальные жесткие диски на виртуальной машине реплицируются по одному, пока все они не будут скопированы в Azure. В зависимости от размера виртуальной машины и пропускной способности сети это может занять некоторое время. Дополнительные сведения о том, как увеличить пропускную способность сети.
  3. В случае возникновения изменений на диске при выполнении начальной репликации модуль отслеживания репликации реплики Hyper-V регистрирует их в журналах репликации Hyper-V (HRL), которые находятся в одной папке с дисками. С каждым диском связан HRL-файл, который отправляется в дополнительное хранилище. При начальной репликации файлы моментальных снимков и журналов потребляют ресурсы диска.
  4. После завершения начальной репликации моментальный снимок виртуальной машины удаляется.
  5. Разностные изменения на диске в журнале синхронизируются и объединяются в родительском диске.

Процедура завершения подготовки защиты

  1. После завершения начальной репликации запускается задача Завершить подготовку защиты на виртуальной машине. Она выполняет настройку сети и других параметров, действующих после репликации, для защиты виртуальной машины.
  2. На этом этапе можно проверить параметры виртуальной машины, чтобы убедиться в ее готовности к отработке отказа. Вы можете запустить отработку аварийного восстановления (тестовая отработка отказа) для виртуальной машины, чтобы проверить правильность отработки отказа.

Разностная репликация данных

  1. После начальной репликации начинается разностная репликация в соответствии с политикой репликации.
  2. Модуль отслеживания репликации реплики Hyper-V регистрирует изменения на виртуальном жестком диске в виде HRL-файлов. Для каждого диска, предназначенного для репликации, создается связанный HRL-файл.
  3. Этот журнал передается в учетную запись хранения клиента. При передаче журнала в Azure изменения на основном диске фиксируются в дополнительном журнале, который находится в той же папке.
  4. Во время начальной и разностной репликаций вы можете отслеживать состояние виртуальной машины на портале Azure.

Процедура повторной синхронизации

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

    • Например, когда HRL-файлы заполняют до 50 % объема диска, виртуальная машина отмечается для повторной синхронизации.
    • По умолчанию повторная синхронизация автоматически выполняется в нерабочее время.
  2. При ней отправляются только разностные данные.

    • Это позволяет минимизировать объем передаваемых данных, вычисляя контрольные суммы исходной и целевой виртуальной машины.
    • Повторная синхронизация использует алгоритм фрагментации, то есть разбивает исходный и целевой файлы на фрагменты фиксированного размера.
    • Для каждого фрагмента данных создаются контрольные суммы. Их сравнение позволяет определить, какие из блоков нужно передать от источника к целевому объекту.
  3. После завершения повторной синхронизации возобновляется обычная разностная репликация данных.

  4. Если вы не хотите ждать времени повторной синхронизации по умолчанию, то можете повторно синхронизировать виртуальную машину вручную. Например, такая потребность может возникнуть в случае сбоя. Для этого на портале Azure выберите виртуальную машину и щелкните >Повторно синхронизировать.

    Screenshot showing the Resynchronize option.

Процедура повторных попыток

При ошибке репликации используется встроенный механизм повторных попыток. Повторная попытка классифицируется согласно описанию в таблице.

Категория Подробности
Неустранимые ошибки Без повторных попыток. Состояние виртуальной машины отображается как Критическое, что требует вмешательства администратора.

Это может быть обусловлено неисправной цепочкой виртуальных жестких дисков, недопустимым состоянием реплики виртуальной машины, ошибками проверки подлинности сети, ошибками авторизации и ошибками "Не найдено" для виртуальной машины (для отдельных серверов Hyper-V).
Устранимые ошибки Повторные попытки выполняются в рамках каждого интервала репликации с использованием экспоненциального алгоритма отсрочки, то есть каждая следующая попытка выполняется с большей задержкой (1, 2, 4, 8 и 10 минут). Если проблема не устранена, повторные попытки выполняются каждые 30 минут. Примерами таких ошибок являются сетевые ошибки, нехватка места на диске и нехватка памяти.

Процесс отработки отказа и восстановления размещения

  1. Вы можете запустить плановую или внеплановую отработку отказа с локальных виртуальных машин Hyper-V в Azure. Чтобы не допустить потери данных при выполнении плановой отработки отказа, выключите исходные виртуальные машины. Вы можете выполнять незапланированную отработку отказа, если основной сайт недоступен.
  2. Вы можете выполнить отработку отказа одного компьютера или создать планы восстановления для координации отработки отказа нескольких компьютеров.
  3. Вы запускаете отработку отказа. По окончании ее первого этапа в Azure должны отобразиться созданные виртуальные машины реплик. При необходимости виртуальной машине можно назначить общедоступный IP-адрес.
  4. Затем требуется зафиксировать отработку отказа для получения доступа к рабочей нагрузке из виртуальной машины реплики Azure.

Восстановив работоспособность локальной инфраструктуры, вы можете восстановить размещение. Восстановление размещения выполняется в три этапа:

  1. Запустите плановую отработку отказа из Azure на локальный сайт:

    • Минимизировать простой: если выбран этот параметр, Site Recovery синхронизирует данные перед отработкой отказа. Эта система проверяет наличие измененных блоков данных и скачивает их на локальный сайт, при этом виртуальная машина Azure продолжает работать, что сводит время простоя к минимуму. Если вы вручную указываете, что требуется выполнение отработки отказа, завершается работа виртуальной машины Azure, копируются все окончательные разностные изменения и начинается отработка отказа.
    • Скачать полностью: при выборе этого параметра данные синхронизируются во время отработки отказа. При этом скачивается весь диск. В этом случае работа идет быстрее, так как не нужно вычислять контрольные суммы, однако увеличивается время простоя. Используйте этот параметр, если вы уже некоторое время работаете с виртуальными машинами Azure реплики или была удалена локальная виртуальная машина.
    • Создать виртуальную машину: этот параметр можно выбрать, чтобы восстановить размещение в той же или другой виртуальной машине. Вы можете указать, что системе Site Recovery следует создать виртуальную машину, если она еще не существует.
  2. После завершения начальной синхронизации вы решаете выполнить отработку отказа. После ее завершения вы можете войти в локальную виртуальную машину, чтобы проверить, правильно ли работают все компоненты. На портале Azure видно, что виртуальные машины Azure остановлены.

  3. После этого вы фиксируете отработку отказа для завершения и снова получаете доступ к рабочей нагрузке из локальной виртуальной машины.

  4. После отработки отказа рабочих нагрузок вы включаете обратную репликацию, чтобы локальные виртуальные машины снова реплицировались в Azure.

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

Выполните инструкции этого руководства, чтобы начать работу с Hyper-V для репликации в Azure.