Подготовка к повторному включению защиты и восстановлению размещения виртуальных машин VMware

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

Компоненты повторной защиты или восстановления размещения

Для повторного включения защиты и восстановления размещения из Azure необходимо установить ряд компонентов и параметров.

Компонент	Сведения
Локальный сервер конфигурации	Локальный сервер конфигурации должен быть запущен и подключен к Azure. Виртуальная машина, для которой выполняется восстановление размещения, должна существовать в базе данных сервера конфигурации. Если сервер конфигурации пострадал в результате аварии, восстановите его с тем же IP-адресом, чтобы гарантировать успешное восстановления размещения. Если IP-адреса реплицированных компьютеров при отработке отказа были сохранены, необходимо установить подключение типа "сеть — сеть" (или подключение ExpressRoute) между виртуальными машинами Azure и сетевой картой восстановления размещения сервера конфигурации. Для сохраненных IP-адресов серверу конфигурации требуется две сетевые карты: одна для подключения к исходному компьютеру, а другая — для подключения к серверу восстановления размещения Azure. Это позволяет избежать перекрытия диапазонов адресов подсетей для исходных виртуальных машин и виртуальных машин отработки отказа.
Сервер обработки в Azure	Перед восстановлением размещения на локальном сайте необходимо развернуть сервер обработки в Azure. Сервер обработки получает данные из защищенных виртуальных машин в Azure и отправляет их на локальный сайт. Сеть между сервером обработки и защищенной виртуальной машиной должна иметь низкую задержку, поэтому для повышения производительности репликации рекомендуется развертывать сервер обработки в Azure. В целях эксперимента можно использовать локальный сервер обработки и ExpressRoute с частным пирингом. Сервер обработки должен находиться в той же сети Azure, что и виртуальная машина, для которой выполнена отработка отказа. Кроме того, сервер обработки должен иметь возможность взаимодействовать с локальным сервером конфигурации и главным целевым сервером.
Отдельный главный целевой сервер	Главный целевой сервер получает данные восстановления размещения. По умолчанию главный целевой сервер Windows работает на локальном сервере конфигурации. К главному целевому серверу может быть подключено до 60 дисков. Если виртуальные машины, для которых выполняется восстановление размещения, имеют более 60 дисков или вы выполняете восстановление больших объемов трафика, создайте отдельный master целевом сервере для восстановления размещения. Если компьютеры собираются в группу репликации с целью обеспечения согласованности нескольких виртуальных машин, на всех виртуальных машинах должна быть установлена ОС Windows или ОС Linux. Почему? Так как все виртуальные машины в группе репликации должны использовать один и тот же главный целевой сервер, а на главном целевом сервере должна быть установлена та же операционная система (той же или более поздней версии), что и на реплицированных компьютерах. На дисках главного целевого сервера не должно быть моментальных снимков. В противном случае повторное включение защиты и восстановление размещения не будет работать. На главном целевом сервере не может находиться контроллер Paravirtual SCSI. На нем может быть только контроллер LSI Logic. Если контроллер LSI Logic отсутствует, при повторном включении защиты происходит сбой.
Политика репликации восстановления размещения	Для выполнения репликации обратно на локальный сайт требуется политика восстановления размещения. Эта политика создается автоматически при создании политики репликации в Azure. Политика автоматически сопоставляется с сервером конфигурации. Ей заданы следующие параметры: пороговое значение RPO — 15 минут, период удержания точки восстановления — 24 часа, частота моментальных снимков с согласованием приложений — 60 минут. Политику невозможно изменить.
VPN типа "сеть — сеть" или частный пиринг ExpressRoute	Для репликации данных при повторном включении защиты и восстановлении размещения требуется VPN-подключение типа "сеть — сеть" или частный пиринг ExpressRoute.

Порты для повторного включения защиты и восстановления размещения

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

Развертывание сервера обработки в Azure

1. Настройте сервер обработки в Azure для восстановления размещения.
2. Убедитесь, что виртуальные машины Azure могут подключиться к серверу обработки.
3. Убедитесь, что VPN-подключение типа "сеть — сеть" или сеть частного пиринга ExpressRoute обладает достаточной пропускной способностью для отправки данных с сервера обработки на локальный сайт.

Развертывание главного целевого сервера

1. Обратите внимание на требования и ограничения главного целевого сервера.

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

3. Убедитесь, что для главного целевого сервера не используется Storage vMotion. В противном случае восстановление размещения может завершиться сбоем. Виртуальная машина не может запуститься, так как для нее нет доступных дисков.

   • Чтобы избежать этого, исключите главный целевой сервер из списка vMotion.
   • Если на главном целевом сервере после повторного включения защиты выполняется задача Storage vMotion, диски защищенных виртуальных машин, подключенные к главному целевому серверу, переносятся на целевой сервер задачи vMotion. Если после этого попытаться восстановить размещение, отключение диска завершается неудачей, так как диски не найдены. После этого найти диски в учетных записях хранения становится трудно. В этом случае найдите их вручную и подключите к виртуальной машине. После этого можно загрузить локальную виртуальную машину.

4. Добавьте на имеющийся главный целевой сервер Windows диск хранения. Добавьте новый диск и отформатируйте его. Диск хранения используется для остановки точек во времени при репликации виртуальной машины обратно на локальный сайт. Обратите внимание на следующие условия. Если они не выполнены, то диск не появится на главном целевом сервере:

   • Том не используется для других целей, таких как целевой объект репликации, и не находится в режиме блокировки.
   • Том не является томом кэша. Пользовательский том установки сервера обработки и главного целевого сервера не может использоваться как том хранения. Если на этом томе установлен сервер обработки и главный целевой сервер, он используется в качестве тома кэша главного целевого сервера.
   • Типом файловой системы тома не является FAT или FAT32.
   • Размер тома не равен нулю.
   • Том хранения по умолчанию для Windows — это том R.
   • Том хранения по умолчанию для Linux — /mnt/retention.

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

6. Установите инструменты VMware или open-vm-tools на главном целевом сервере. Без этих инструментов не удастся обнаружить хранилища данных на узле ESXi главного целевого сервера.

7. В разделе параметров конфигурации главной целевой виртуальной машины в VMware установите для параметра disk.enableUUID значение true. Если этой строки нет, добавьте ее. Этот параметр необходим для обеспечения согласованного UUID для правильного подключения VMDK.

8. Проверьте требования к доступу vCenter Server.

   • Если виртуальная машина, для которой выполняется восстановление размещения, находится на узле ESXi под управлением VMware vCenter Server, главному целевому серверу требуется доступ к диску локальной виртуальной машины (VMDK) для записи реплицированных данных на диски виртуальной машины. Убедитесь, что хранилище данных локальной виртуальной машины подключено к узлу главного целевого сервера с доступом на чтение и запись.
   • Если виртуальная машина находится не на узле ESXi под управлением vCenter Server, служба Site Recovery создаст виртуальную машину во время повторного включения защиты. Эта виртуальная машина создается в узле ESXi, в котором создана виртуальная машина главного целевого сервера. Тщательно выбирайте узел ESXi, чтобы создать виртуальную машину на нужном узле. Жесткий диск виртуальной машины должен находиться в хранилище данных, доступном для узла, на котором работает главный целевой сервер.
   • Или при наличии локальной виртуальной машины для восстановления размещения удалите ее, прежде чем выполнить восстановление размещения. Затем служба восстановления размещения создаст новую виртуальную машину на том же узле, где находится главный целевой узел ESXi. Если восстановление размещения выполняется в альтернативном расположении, данные будут восстановлены в то же хранилище данных и тот же узел ESXi, которые использует локальный главный целевой сервер.

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

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

Дальнейшие действия

Узнайте, как повторно включить защиту виртуальной машины.