Архитектура аварийного восстановления VMware в Azure — обновлена

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

Это важно

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

Примечание.

Убедитесь, что вы создадите хранилище служб восстановления для настройки устройства репликации ASR. Не используйте существующее хранилище.

Сведения об архитектуре Azure Site Recovery в классической архитектуре см. в этой статье.

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

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

Компонент	Требование	Сведения
Azure	Подписка Azure, учетная запись хранения Azure для кэша, управляемый диск и сеть Azure.	Реплицированные данные из локальных виртуальных машин хранятся в хранилище Azure. Виртуальные машины Azure создаются на основе реплицированных данных при запуске отработки отказа из локальной инфраструктуры в Azure. При создании виртуальные машины Azure подключаются к виртуальной сети Azure.
Устройство репликации Azure Site Recovery	Это основной элемент всей локальной инфраструктуры Azure Site Recovery. Все компоненты устройства координируются с помощью устройства репликации. Эта служба контролирует все сквозные действия Site Recovery, включая мониторинг работоспособности защищенных компьютеров, репликацию данных, автоматическое обновление и т. д.	На устройстве размещаются различные ключевые компоненты, такие как: Прокси-сервер: этот компонент выступает в качестве прокси-канала между агентом мобильности и службами Site Recovery в облаке. Это гарантирует отсутствие других подключений к Интернету, необходимых для рабочих нагрузок для создания точек восстановления. Обнаруженные элементы. Этот компонент собирает сведения о vCenter и координируется со службой управления Azure Site Recovery в облаке. Сервер повторной защиты: Этот компонент управляет координацией между машинами Azure и локальными компьютерами в ходе операций повторной защиты и возврата к исходному размещению. Сервер обработки: этот компонент используется для кэширования, сжатия данных перед отправкой в Azure. Дополнительные сведения об устройстве репликации и об использовании нескольких устройств репликации. Агент службы восстановления: этот компонент используется для настройки и регистрации в службах Site Recovery и для мониторинга работоспособности всех компонентов. Поставщик Site Recovery: этот компонент используется для упрощения повторной защиты. Он различает между альтернативным местоположением резервного копирования и резервным копированием исходного местоположения для исходного компьютера. Служба репликации. Этот компонент используется для репликации данных из исходного расположения в Azure.
Серверы VMware	Виртуальные машины VMware размещаются на локальных серверах vSphere ESXi. Мы рекомендуем управлять узлами с помощью сервера vCenter.	При развертывании Site Recovery добавьте серверы VMware в хранилище служб восстановления.
Реплицируемые компьютеры	Служба Mobility Service устанавливается на каждой реплицируемой виртуальной машине VMware.	Рекомендуется разрешить автоматическую установку службы Mobility Service. Кроме того, можно установить эту службу вручную.

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

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

Примечание.

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

Исходящая связь для URL

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

URL-адрес	Сведения
portal.azure.com	Перейдите на портал Azure.
*.windows.net *.msftauth.net *.msauth.net *.microsoft.com *.live.com *.office.com	Чтобы войти в подписку Azure.
*.microsoftonline.com	Создайте приложения Microsoft Entra для устройства для взаимодействия с Azure Site Recovery.
management.azure.com	Создайте приложения Microsoft Entra для устройства для взаимодействия со службой Azure Site Recovery.
*.services.visualstudio.com	Передача журналов приложений, используемых для внутреннего мониторинга.
*.vault.azure.net	Управление секретами в Azure Key Vault. Примечание. Убедитесь, что для репликации компьютеров есть доступ к этому.
aka.ms	Разрешить доступ к ссылкам ,также известным как". Используется для обновлений устройства Azure Site Recovery.
download.microsoft.com/download	Разрешить загрузки с сайтов Майкрософт.
*.servicebus.windows.net	Обмен данными между устройством и службой Azure Site Recovery.
*.discoverysrv.windowsazure.com	Подключитесь к URL-адресу службы обнаружения Azure Site Recovery.
*.hypervrecoverymanager.windowsazure.com	Подключение к URL-адресам микрослужбы Azure Site Recovery.
*.blob.core.windows.net	Отправьте данные в хранилище Azure, которое используется для создания целевых дисков.
*.backup.windowsazure.com	URL-адрес службы защиты — микрослужба, используемая Azure Site Recovery для обработки и создания реплицированных дисков в Azure.
*.prod.migration.windowsazure.com	Чтобы обнаружить локальное имущество.

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

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 для входящих подключений, чтобы управлять репликацией.
   • Виртуальные машины отправляют данные репликации на устройство через входящий порт HTTPS 9443. Этот порт можно изменить.
   • Устройство получает данные репликации, оптимизирует и шифрует его и отправляет его в хранилище Azure через исходящий порт 443.

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

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

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

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

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

Параметр политики	Сведения	По умолчанию
Хранение точки восстановления	Указывает, как долго в Site Recovery хранятся точки восстановления.	1 день
Периодичность создания снимков, консистентных с приложениями	Как часто Site Recovery делает моментальный снимок, согласованный с приложением	Отключено

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

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

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

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

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

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

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

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

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) Перед этой операцией VSS сообщает каждому приложению на компьютере, что все данные из оперативной памяти необходимо передать на диск. 4) VSS предоставляет приложению резервного копирования и аварийного восстановления (в нашем примере это Site Recovery) возможность считать данные моментального снимка и продолжить работу.	Вы можете указать частоту создания моментальных снимков с согласованностью на уровне приложений. Эта частота всегда должна быть меньше установленной вами для хранения точек восстановления. Например, если для хранения точек восстановления используется значение по умолчанию — 24 часа, настройте частоту создания на интервал менее 24 часов. Такие моментальные снимки более сложны и требуют больше времени на создание, чем аварийно-консистентные снимки. Они снижают производительность приложений, которые выполняются на реплицируемой виртуальной машине.

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

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

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

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

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

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

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

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

Следуйте этому учебнику, чтобы включить репликацию из VMware в Azure.