Архитектура аварийного восстановления из VMware в Azure — классическая модель

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

Дополнительные сведения об модернизации архитектуры см. в этой статье.

Это важно

Классический интерфейс для защиты компьютеров VMware с помощью ASR был выведен из эксплуатации 30 марта 2026 года. Подробнее. Переключитесь на обновленный интерфейс , чтобы избежать прерывания работы службы.

Компоненты архитектуры

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

Компонент Требование Сведения
Azure Подписка Azure, учетная запись хранения Azure для кэша, управляемый диск и сеть Azure. Вы храните реплицированные данные из локальных виртуальных машин в хранилище Azure. При переключении на резервную систему из локальной инфраструктуры в облако Azure вы создаете виртуальные машины Azure с реплицированными данными. При создании виртуальные машины Azure подключаются к виртуальной сети Azure.
Сервер конфигурации Отдельный локальный компьютер. Запустите её как виртуальную машину VMware, развертываемую из скаченного шаблона OVF.

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

Сервер обработки по умолчанию устанавливается на сервере конфигурации. Он получает данные репликации, оптимизирует его с помощью кэширования, сжатия и шифрования и отправляет его в службу хранилища Azure. Сервер обработки также устанавливает службу Mobility Service Azure Site Recovery на виртуальные машины, которые требуется реплицировать, и выполняет автоматическое обнаружение локальных компьютеров. По мере роста развертывания можно добавить дополнительные отдельные серверы обработки для обработки больших объемов трафика репликации.

Главный целевой сервер по умолчанию устанавливается на сервере конфигурации. Он управляет данными репликации при возврате после отказа из Azure. Для крупных развертываний можно добавить дополнительный главный целевой сервер для восстановления размещения.
Серверы VMware Виртуальные машины VMware размещаются на локальных серверах vSphere ESXi. Используйте сервер vCenter для управления узлами. При развертывании Site Recovery добавьте серверы VMware в хранилище служб восстановления.
Реплицируемые компьютеры Установите Службу Mobility Service на каждой реплицируемой виртуальной машине VMware. Разрешить автоматическую установку с сервера обработки. Кроме того, вы можете установить службу вручную или использовать средство автоматического развертывания, такое как System Center Configuration Manager.

Схема, показывающая связи архитектуры репликации VMware с архитектурой репликации Azure.

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

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

Примечание.

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

Исходящие подключения для 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.us Позволяет виртуальной машине взаимодействовать со службой Site Recovery.
Cлужебная шина *.servicebus.windows.net *.servicebus.usgovcloudapi.net Позволяет виртуальной машине записывать данные мониторинга и диагностики службы Site Recovery.

Полный список URL-адресов для фильтрации связи между локальной инфраструктурой Azure Site Recovery и службами Azure см. в разделе о требованиях к сети в статье о предварительных требованиях.

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

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

    • Для виртуальных машин VMware репликации осуществляются на уровне блока почти непрерывно с помощью агента Mobility Service на виртуальной машине.
    • Применяются все параметры политики репликации:
      • Пороговое значение RPO. Этот параметр не влияет на репликацию. Он помогает с мониторингом. Будет создано событие, возможно, с отправкой сообщения электронной почты, если текущее значение RPO превышает заданное вами пороговое значение.
      • Хранение точки восстановления. Этот параметр указывает, на какой период в прошлом вы хотите вернуться в случае нарушения работы. Максимальный срок хранения данных на управляемом диске составляет 15 дней.
      • Моментальные снимки, согласованные с приложением. Моментальный снимок, согласованный с приложением, может создаваться с интервалом от 1 до 12 часов в зависимости от потребностей приложения. Это стандартные моментальные снимки BLOB-объектов Azure. Агент службы Mobility, запущенный на виртуальной машине, запрашивает моментальный снимок VSS в соответствии с этим параметром и отмечает этот момент времени как точку согласованности приложения в потоке репликации.

      Примечание.

      Большой период хранения точки восстановления может повлиять на стоимость хранения, так как может потребоваться сохранить дополнительные точки восстановления.

  2. Трафик реплицируется в общедоступные конечные точки службы хранилища Azure через Интернет. Кроме того, можно использовать Azure ExpressRoute со службой Пиринг Microsoft . Репликация трафика через VPN типа "сеть — сеть" с локального сайта в Azure не поддерживается.

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

  4. Обмен данными происходит следующим образом.

    • Виртуальные машины обмениваются данными с локальным сервером конфигурации через HTTPS-порт 443 для входящих подключений, чтобы управлять репликацией.
    • Оркестрация репликации сервером конфигурации осуществляется совместно с Azure через порт HTTPS 443 на исходящих соединениях.
    • Виртуальные машины отправляют данные репликации на сервер обработки (запущенный на компьютере сервера конфигурации) через HTTPS-порт 9443 для входящих подключений. Этот порт можно изменить.
    • Сервер обработки получает данные репликации, оптимизирует и шифрует их, а затем отправляет в службу хранилища Azure через порт 443 для исходящих подключений.

  5. Сначала журналы данных репликации помещаются в учетную запись хранения кэша в Azure. Эти журналы обрабатываются, а данные сохраняются на управляемом диске Azure (называемом начальным диском Azure Site Recovery). На этом диске создаются точки восстановления.

Схема, на которой показан процесс репликации VMware в Azure.

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

  1. Иногда во время начальной репликации или при передаче разностных изменений могут возникнуть проблемы с сетевым подключением между исходным компьютером и сервером обработки или между сервером обработки и Azure. Любая из них может привести к сбоям при мгновенной передаче данных в Azure.
  2. Чтобы избежать проблем с целостностью данных и снизить затраты на их передачу, Site Recovery помечает компьютер для повторной синхронизации.
  3. Компьютер также можно пометить для повторной синхронизации в таких ситуациях, как показано ниже, чтобы обеспечить согласованность между исходным компьютером и данными, хранящимися в Azure.
    • Если устройство подвергается принудительному выключению
    • Если компьютер проходит процесс изменения в конфигурации, например изменение размера диска (размер диска изменяется с 2 ТБ на 4 ТБ)
  4. Повторная синхронизация отправляет в Azure только разностные данные. Обмен данными между локальной средой и Azure сокращен за счет вычисления контрольных сумм данных между исходным компьютером и данными, хранящимися в Azure.
  5. По умолчанию повторная синхронизация автоматически выполняется в нерабочее время. Если вы не хотите ждать выполнения повторной синхронизации по умолчанию вне рабочего времени, вы можете повторно синхронизировать виртуальную машину вручную. Для этого на портале Azure выберите виртуальную машину и щелкните >Повторная синхронизация.
  6. Если повторная синхронизация, установленная по умолчанию, завершается сбоем в нерабочее время и требуется вмешательство вручную, то на определенном компьютере в портале Azure возникает ошибка. Вы можете устранить эту ошибку и запустить повторную синхронизацию вручную.
  7. После завершения повторной синхронизации будет возобновлена репликация разностных изменений.

Управление политиками репликации

  • Вы можете настроить параметры политик репликации при включении репликации.
  • Можно в любой момент создать политику репликации и применить ее при включении репликации.

Согласованность нескольких виртуальных машин

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

Моментальные снимки и точки восстановления

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

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

Site Recovery создает моментальные снимки следующим образом.

  1. Site Recovery по умолчанию создает моментальные снимки данных с учетом краш-согласованности и моментальные снимки, согласованные на уровне приложений, если вы укажете их частоту.
  2. Точки восстановления создаются на основе моментальных снимков и сохраняются в соответствии с параметрами хранения, указанными в политике репликации.

Согласованность

В следующей таблице описываются различные виды согласованности.

Аварийно-консистентный

Description Сведения Рекомендация
Аварийно-консистентный снимок содержит данные, которые были на диске в момент его создания. Он не содержит никакой информации из памяти компьютера.

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

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

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

Точек восстановления без учета состояния приложений обычно вполне достаточно для репликации операционных систем и приложений, таких как DHCP-серверы и серверы печати.

согласованность на уровне приложений

Description Сведения Рекомендация
Точки восстановления с согласованностью на уровне приложений создаются на основе моментальных снимков с согласованностью на уровне приложений.

Моментальный снимок, согласованный с приложением, содержит все сведения из моментального снимка, согласованного с аварийным состоянием, а также все данные в памяти и данные по текущим транзакциям.		 Моментальные снимки, обеспечивающие согласованность на уровне приложений, создаются с помощью службы теневого копирования томов (VSS).

1) Azure Site Recovery использует метод резервного копирования "только копирование" (VSS_BT_COPY). Он не изменяет время резервного копирования и порядковый номер в журнале транзакций Microsoft SQL.

2) При инициации создания моментального снимка VSS выполняет с томом операцию копирования при записи (COW).

3) Перед выполнением процедуры COW, VSS сообщает каждому приложению на компьютере, что ему необходимо сбросить данные из памяти на диск.

4) VSS предоставляет приложению резервного копирования и аварийного восстановления (в нашем примере это Site Recovery) возможность считать данные моментального снимка и продолжить работу.		 Снимки, согласованные с приложениями, создаются с частотой, которую вы указываете. Частота должна всегда быть меньше, чем та, которую вы установили для хранения точек восстановления. Например, если для хранения точек восстановления используется значение по умолчанию - 24 часа, следует установить частоту создания точек с интервалом менее 24 часов.

Такие моментальные снимки более сложны и требуют больше времени на создание, чем аварийно-консистентные моментальные снимки.

Они снижают производительность приложений, которые выполняются на реплицируемой виртуальной машине.

Процесс переключения на резервный узел и возврат на основной узел

После настройки репликации и выполнения аварийного теста (тестовой отработки отказа) для проверки правильности функционирования компонентов, вы можете по мере необходимости запускать переключение на отказоустойчивый режим и восстановление после отказа.

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

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

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

  3. Когда основной сайт на площадке снова станет доступным, можно будет подготовить среду к возврату к исходному размещению. Для отката следует настроить инфраструктуру отката, включая следующее:

    • Временный сервер обработки в Azure. Для восстановления обработки из Azure настройте виртуальную машину Azure, чтобы она выполняла роль сервера обработки и осуществляла репликацию из Azure. После завершения обратного переключения виртуальную машину можно удалить.
    • VPN-подключение: Чтобы выполнить восстановление, вам нужна VPN-связь (или ExpressRoute) от сети Azure до локального сайта.
    • Отдельный мастер целевой сервер. По умолчанию мастер целевой сервер, установленный вместе с сервером конфигурации на локальной виртуальной машине VMware, обрабатывает возврат к исходной системе. Если вам нужно переключить большие объемы трафика обратно, настройте отдельный локальный главный целевой сервер для этой цели.
    • Политика возврата. Для репликации обратно на локальный сайт необходима политика возврата. Эта политика создается автоматически при создании политики репликации из локальной среды в Azure.

  4. После установки компонентов восстановление после отказа выполняется в три этапа:

    • Этап 1. Повторно включите защиту виртуальных машин Azure, чтобы обеспечить их репликацию из Azure в локальные виртуальные машины VMware.
    • Этап 2. Выполните переключение при отказе на локальном сайте.
    • Этап 3. После возврата рабочих нагрузок вновь включите репликацию для виртуальных машин, которые находятся в вашей организации.

Схема возврата после сбоя VMware из Azure.

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

Ознакомьтесь с этим руководством для включения репликации из VMware в Azure.

  • Last updated on