Архитектура аварийного восстановления из 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 с локальным Hyper-V сайтом для Azure архитектуры без VMM.

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

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

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

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

Архитектура перехода с Hyper-V на Azure (с VMM)

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

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

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

Примечание.

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

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

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

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

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

Диаграмма, показывающая процесс репликации из Hyper-V в Azure

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

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

  1. После включения защиты для Hyper-V виртуальной машины на портале Azure или локальной среде запускается защита Enable.
  2. Это задание проверяет, соответствует ли компьютер необходимым требованиям перед вызовом метода CreateReplicationRelationship, который настраивает репликацию, используя определенные вами параметры.
  3. Задание запускает начальную репликацию путем вызова метода StartReplication для инициализации полной репликации виртуальных машин и отправки виртуальных дисков виртуальной машины в Azure.
  4. Задание можно отслеживать на вкладке Jobs. Screenshot списка заданий на вкладке Screenshot экрана

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

Примечание.

Windows Server 2008, 2008 R2, 2012 и 2012 R2 достигли окончания поддержки (EOS). Просмотрите, как вы используете операционную систему, и планируйте её обновления и миграции соответственно. Дополнительные сведения см. в разделе "Окончание поддержки"

  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 выберите виртуальную машину >Resynchronize.

    Screenshot с параметром Resynchronize.

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

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

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

Примеры этих ошибок включают разорванную цепочку VHD, недопустимое состояние для виртуальной машины реплики, ошибки сетевой аутентификации, ошибки авторизации и ошибки, когда виртуальная машина не найдена (для автономных серверов 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 в течение некоторого времени или если локальная (on-premises) виртуальная машина была удалена.
    • Создайте виртуальную машину. Вы можете вернуться к той же виртуальной машине или к альтернативной виртуальной машине. Можно указать, что Site Recovery следует создать виртуальную машину, если она еще не существует.

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

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

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

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

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

  • Last updated on