Выполнение тестирования аварийного восстановления виртуальных машин Hyper-V на дополнительный сайт

В этой статье описывается, как с помощью Azure Site Recovery выполнить тестирование аварийного восстановления виртуальных машин Hyper-V, управление которыми осуществляется в облаках System Center Virtual Machine Manager (VMM), на локальный дополнительный сайт.

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

Как работает тестовая отработка отказа

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

• Вы можете запустить тестовую отработку отказа на одной виртуальной машине или в плане восстановления.
• Ее можно запустить без подключения к сети, в существующей сети или с помощью автоматически созданной сети. Дополнительные сведения об этих параметрах приведены в следующей таблице.
  • Тестовую отработку отказа можно запустить без подключения к сети. Этот вариант полезен, если вам нужно просто проверить, может ли виртуальная сеть выполнить отработку отказа, но вы не можете проверить параметры сети.
  • Выполните отработку отказа имеющейся сети. Мы рекомендуем не использовать рабочую сеть.
  • Выполните отработку отказа и разрешите Site Recovery автоматически создавать тестовую сеть. В этом случае Site Recovery создаст сеть автоматически, а затем очистит ее по завершении тестовой отработки отказа.
  • Последняя обработанная. Отработка отказа выполняется до последней точки восстановления виртуальной машины, которая была обработана Site Recovery. Этот вариант обеспечивает низкий показатель целевого времени восстановления, так как не требует времени на обработку данных.
  • Последняя точка во времени согласованности приложений. Отработка отказа виртуальной машины выполняется до последней точки восстановления с согласованным состоянием приложений, которая была обработана Site Recovery.
  • Последняя. При этом варианте сначала обрабатываются все данные, отправленные в службу Site Recovery, чтобы создать точку восстановления для каждой виртуальной машины, прежде чем выполнять в нее отработку отказа. Этот вариант обеспечивает самое низкое значение RPO (целевая точка восстановления), так как виртуальная машина, созданная после отработки отказа, будет иметь все данные, реплицированные в службу Site Recovery до момента активации отработки отказа.
  • Последние обработанные для нескольких виртуальных машин. Этот параметр доступен для планов восстановления, которые содержат одну или больше виртуальных машин с согласованностью нескольких виртуальных машин. Виртуальные машины с этим параметром выполняют отработку отказа до последней согласованной точки восстановления, общей для нескольких виртуальных машин. Другие виртуальные машины выполняют отработку отказа до последней обработанной точки восстановления.
  • Последняя для нескольких виртуальных машин с согласованием приложений. Этот параметр доступен для планов восстановления, которые содержат одну или несколько виртуальных машин с согласованностью нескольких виртуальных машин. Виртуальные машины, которые являются частью группы репликации, выполняют отработку отказа до последней согласованной с приложением точки восстановления, общей для нескольких виртуальных машин. Остальные виртуальные машины выполняют отработку отказа до последней точки восстановления, согласованной с приложением.
  • Настраиваемая. Выполняет отработку отказа определенной виртуальной машины до определенной точки восстановления.

  Подготовка сетей

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

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

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

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

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

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

  Используйте этот параметр, если план восстановления использует несколько сетей виртуальных машин.

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

  Рекомендации

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

  Тип тестовой сети не обязательно должен соответствовать типу логической сети VMM, используемой для тестовой отработки отказа. Однако некоторые сочетания типов не будут работать.

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

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

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

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

  Сеть виртуальных машин настроенная без изоляции или с изоляцией виртуальной локальной сети

  Если сеть виртуальной машины VMM настроена без изоляции или с изоляцией виртуальных локальных сетей, обратите внимание на следующее:

  • Если для сети виртуальных машин определен DHCP, то реплика виртуальной машины подключится к идентификатору виртуальной локальной сети с использованием параметров, указанных для сайта сети в сопоставленной логической сети. Виртуальная машина получает свой IP-адрес от доступного DHCP-сервера.
  • Вам не потребуется определять пул статических IP-адресов для целевой сети виртуальных машин. Если для сети виртуальных машин используется пул статических IP-адресов, то реплицированная виртуальная машина будет подключаться к идентификатору виртуальной локальной сети с помощью параметров, указанных для сайта сети в сопоставленной логической сети.
  • Виртуальная машина получит свой IP-адрес из пула, определенного для сети виртуальных машин. Если пул статических IP-адресов не определен в целевой сети виртуальных машин, произойдет сбой выделения IP-адресов. Создайте пул IP-адресов на исходном и целевом серверах VMM, которые будут использоваться для защиты и восстановления.
  Сеть виртуальных машин с виртуализацией сети Windows

  Если сеть виртуальной машины VMM настроена с использованием виртуализации сети Windows, обратите внимание на следующее:

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

  Подготовка инфраструктуры

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

  • Если запустить тестовую отработку отказа, используя имеющуюся сеть, подготовьте Active Directory, DHCP и DNS в этой сети.
  • При запуске тестовой отработки отказа с возможностью автоматического создания сети виртуальных машин необходимо добавить ресурсы инфраструктуры для автоматического создания сети перед запуском тестовой отработки отказа. В плане восстановления можно решить данную проблему, добавив ручной шаг перед Group-1 в плане восстановления, который будет использоваться для отработки отказа. затем — ресурсы инфраструктуры в автоматически созданную сеть.
  Подготовка DHCP

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

  Подготовка Active Directory

  Чтобы выполнить тестовую отработку отказа для тестирования приложения, потребуется копия рабочей среды Active Directory в тестовой среде. Дополнительные сведения см. в разделе Рекомендации по тестированию отработки отказа.

  Подготовка DNS

  Подготовьте DNS-сервер для тестовой отработки отказа указанным ниже образом.

  DHCP. Если виртуальные машины используют DHCP, необходимо обновить IP-адрес тестового DNS-сервера на тестовом DHCP-сервере. Если используется сеть с технологией виртуализации сети Windows, VMM-сервер будет выступать в роли DHCP-сервера. Следовательно, IP-адрес DNS-сервера должен обновляться в сети тестовой отработки отказа. В этом случае виртуальные машины регистрируются на соответствующем DNS-сервере.

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

  Запуск тестовой отработки отказа

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

  1. Выберите Планы восстановления>имя_плана_восстановления. Последовательно выберите пункты Тип отработки отказа>Test Тип отработки отказа.
  2. В колонке Тестовая отработка отказа укажите, каким способом реплики виртуальных машин должны подключаться к сетям после тестовой отработки отказа.
  3. Ход выполнения отработки отказа можно отслеживать на вкладке Задания .
  4. После отработки отказа проверьте, успешно ли запущены виртуальные машины.
  5. Когда все будет готово, щелкните Cleanup test failover (Очистить тестовую отработку отказа) в плане восстановления. В разделе Примечания можно записать и сохранить любые замечания, связанные с тестовой отработкой отказа. На этом шаге удаляются виртуальные машины и сети, созданные Site Recovery при тестовой отработке отказа.

  IP-адрес, выделенный виртуальной машине при тестовой отработки отказа, это тот же IP-адрес, который она бы получила при выполнении плановой или внеплановой отработки отказа (если этот IP-адрес доступен в сети тестовой отработки отказа). Если такой IP-адрес недоступен в сети тестовой отработки отказа, виртуальная машина получит другой IP-адрес, доступный в сети тестовой отработки отказа.

  Выполнение тестовой отработки отказа в рабочую сеть

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

  • При выполнении тестовой отработки отказа убедитесь, что работа основной виртуальной машины была завершена. Если этого не сделано, в одной сети будут одновременно работать две виртуальные машины с одинаковыми идентификаторами. Такая ситуация может привести к нежелательным последствиям.
  • Любые изменения, внесенные в виртуальные машины тестовой отработки отказа, будут потеряны при выполнении очистки этих машин. Они не реплицируются на основные виртуальные машины.
  • Такой способ тестирования приводит к простою рабочего приложения. Попросите пользователей не использовать приложение во время тренировки аварийного восстановления.

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

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

  📎📎📎📎📎📎📎📎📎📎