что такое репликация в hyper v
Работа с Hyper-V и репликами Hyper-V в VMM 2012
В этой статье обсуждается работа с Hyper-V и Hyper-V репликами в Microsoft System Center 2012 диспетчер виртуальных машин.
Оригинальная версия продукта: Microsoft System Center 2012 R2 диспетчер виртуальных машин, System Center 2012 диспетчер виртуальных машин
Исходный номер КБ: 3034191
Сводка
Microsoft Azure Восстановление сайта (ASR) — это рекомендуемый продукт для управления Hyper-V репликами. Это включает управление сетью для виртуальных машин реплики (VM) в среде System Center 2012 диспетчер виртуальных машин (VMM 2012). Однако, хотя VMM 2012 не управляет Hyper-V репликами без ASR, можно использовать Hyper-V реплики PowerShell для автоматизации Hyper-V операций, связанных с репликами. К таким операциям относятся сбои над VM с помощью Hyper-V реплики, но без использования ASR.
В этой статье документируется рекомендуемый подход к управлению Hyper-V репликами. В этой статье также предусмотрены необходимые сценарии для сбой над VM с помощью Hyper-V реплики.
В установке восстановления сбоя рекомендуется использовать отдельные сети первичной и вторичной HNV. В этих сетях основной VM должен быть подключен к основной сети HNV, а реплика VM должна быть подключена к вторичной сети VM. Если вы используете единую сеть VM как для основных, так и для вторичных сайтов, рекомендуется использовать ASR, так как она автоматизирует управление репликами VM через функцию сопоставления сети. Если вы не используете ASR, необходимо быть осторожным как с порядком, в котором VMs присоединены к сети, так и с обязательными условиями для создания вложений.
Вы должны следовать указаниям в этих разделах для порядка вложения и необходимых действий. В противном случае записи CA-PA в VMM могут быть удалены и привести к потере подключения к сети.
Следующие сценарии применяются к среде управления VMM 2012 (включая VMM 2012 R2), в которой верны следующие условия:
С помощью отдельных первичных и вторичных сетей HNV для основной и реплики VM можно убедиться, что оба VM могут быть подключены к их сетям одновременно. Эта конфигурация рекомендуется для следующих условий:
Необходимые шаги
Перед выполнением операции по сбойу выполните следующие действия:
Убедитесь, что параметры виртуального коммутатора и логического коммутатора соответствуют требованиям консоли VMM. Дополнительные сведения см. в дополнительных сведениях о просмотре адаптеров хост-Параметры и повышении соответствия требованиям Параметры в VMM.
Если параметры не соответствуют требованиям, операции VMM по присоединению сетей после сбойной работы могут привести к сбойу.
Убедитесь, что основной VM подключен к сети HNV.
Убедитесь, что реплика VM не подключена ни к одной сети.
Реплика VM не должна быть подключена к сети HNV одновременно с основной VM. Параллельное подключение может привести к неправильным состояниям для записей CA-PA.
Убедитесь, что каждому сетевому адаптеру основного VM назначен только один IP-адрес. Для этого запустите следующие команды по командной подсказке:
Если в VM имеется несколько подключенных сетевых адаптеров, запустите эти команды для каждого сетевого адаптера, изменив индекс массива.
Убедитесь, что IP-адрес, присвоенный VM в операционной системе, такой же, как и IP-адрес, указанный в шаге 4. Для этого войдите в VM и запустите следующую команду по командной подсказке:
Убедитесь, что таблицы проверки правильно настроены на первичном и репликаторном сервере. Для этого запустите следующую команду на каждом сервере и убедитесь, что есть запись, соответствующая IP-адресу, который возвращается на шаге 4:
Убедитесь, что используемый IP-адрес — это адрес IPv4, а не IPv6.
Убедитесь, что оба VM отключены до запуска сценариев.
Убедитесь, что значение состояния репликации установлено для включения репликации на обоих VMs.
Сценарий сбой над VM с помощью Hyper-V реплики
Используйте сценарийPlannedFailOver.PS1 для выполнения сбойной работы. Этот сценарий включает в себя параметр для завершения обратной репликации вместе с сбой.
Этот сценарий приводит следующие аргументы:
$VMName : Имя виртуальной машины
$ReverseRep Аргумент Boolean, чтобы указать, следует ли выполнять реверсную репликацию
Если $true, репликация обратного копирования начинается немедленно, и после этого не удается отменить сбой.
Если сценарий не выполняет один или несколько действий при сбойе, необходимо вручную завершить неудались действия и вернуться в окно PowerShell. Действия по сбойу включают в себя следующие действия, в этом порядке:
Следите за ошибками и вручную выполните неудачные действия в заданный порядок. После выполнения действий нажмите любой ключ в окне PowerShell. Сценарий будет продолжаться до завершения.
Скрипт для запуска обратной репликации или отмены сбойной передачи
Этот сценарий приводит следующие аргументы:
$VMName : Имя виртуальной машины
$CancelFO : Аргумент Boolean, чтобы указать, следует ли отменять сбой:
После успешного завершения этого сценария значение состояния репликации должно быть задано включенной репликации на обоих VMs.
Ссылки
Ниже поминаются сценарии процедур, указанных в указанных выше разделах:
Настройка Hyper-V Replica в Windows Server 2012
Всем огненного настроения!
Сегодня хотелось бы рассказать про очень интересное нововведение, которое появилось в Windows Server 2012, — а именно Hyper-V Replica. Данная технология представляет практический интерес — давайте более подробно познакомимся с ней.
В чем смысл Hyper-V Replica?
Смысл, как вы наверное могли догадаться, Hyper-V Replica в… репликации ВМ.
Смысл репликации, я думаю известен всем. В данном конкретном случае функция Hyper-V Replica рассматривается и позиционируется как встроенный в Windows Server 2012 механизм обеспечения катастрофоустойчивости.
И вы не ослышались — речь идет именно о катастрофоустойчивости, но никак не о высокой доступности — для высокой доступности в Windows Server 2012 применяются функции кластеризации, а вот Hyper-V Replica — это именно тот механизм, который позволяет реплицировать экземпляр ВМ за пределы сайта датацентра на удаленную площадку.
Сразу стоит отметить, что до WS2012 катастрофоустойчивые сценарии реализовывались с помощью связки WS2008R2SP1 и SC2012, а именно Orchestrator + DPM. С точки зрения ВМ-инфраструктуры Hyper-V Replica сильно упрощает жизнь — но все же оптимальный эффект будет достигаться в связке с System Center 2012 SP1 Orchestrator.
Давайте посмотрим как настраивается и работает данный механизм.
Настройка Hyper-V Replica
Прежде всего, нужно понять что данный механизм работает по принципу «точка-точка» — то есть реплицируется определенная ВМ с основного хоста или кластера на удаленный резервный хост — оба объекта, естественно, с ролью Hyper-V.
Сначала нужно настроить целевой хост для приема реплицируемых данных.
1) Запустите Hyper-V Manager.
2) Выберите необходимый, целевой хост в Hyper-V Manager и зайдите в его настройки.
3) Выберите пункт Replica Configuration.
4) Выберите пункт Enable this computer as a Replica Server, а также способ репликации данных — по Kerberos (HTTP) или же более безопасным способом на базе сертификатов (HTTPS).
5) Далее вы можете выбрать сервера, с которых можно принимать реплики ВМ, а также их целевое размещение. По умолчанию разрешаем принимать реплики с любых аутентифицированных серверов.
6) Обязательно убедитесь в том, что в брандмауэре на принимающем хосте разрешено исключение для Hyper-V Replica HTTP Listener (TCP-In) или Hyper-V Replica HTTPS Listener (TCP-In) — в зависимости от ваших требований.
Теперь нам необходима настроить ВМ для репликации.
1) Выберите необходимую для репликации ВМ и щелкните по ней правой кнопкой мыши, далее выберите пункт Enable Replication.
2) В появившемся мастере настройки репликации нажмите Next на первом диалоговом окне, а также на следующем.
3) Укажите FQDN-имя целевого сервера, на который вы собираетесь реплицировать ВМ и нажмите Next.
4) Выберите способ аутентификации(Kerberos или на базе сертификата) и нужно ли сжимать данные при передаче. Нажмите Next.
5) Выберите виртуальные диски ВМ, которые собираетесь реплицировать и нажмите Next.
6) Настройте параметры точки восстановления — будете вы использовать только самую актуальную и единственную точку восстановления (Only the latest recovery point) или же решите использовать возможность создания нескольких точек с заданной переодичностью (Additional recovery points) — решать Вам. Во втором случае Вы можете указать необходимое количество точек восстановления, а также интервал между их созданием. Для обеспечения механизмов репликации WS2012 использует VSS в сочетании с инкрементальными снимками ВМ. После того, как Вы определились с выбором — нажмите Next.
7)Теперь необходимо выбрать механизм для проведения первичной репликации — через сеть, через внешний носитель или же использовать существующую ВМ на целевом сервере. Выберите время начала репликации и нажмите Next.
8) Просмотрите итог настроек и нажмите Finish для завершения процесс настройки.
Для просмотра статцса репликации нажмите на вкладке Replication на необходимой ВМ. Также теперь в сетевых настройках ВМ Вы можете задать альтернативную конфигурацию сети на случай резервного запуска реплики ВМ.
Также есть достаточно подробное видео на тему репликации
Некоторые предосторожности
Не следует применять репликацию ВМ, если внутри ВМ находится контроллер домена — так как в случае восстановлении реплики может произойти сбой последовательности генерации ключей безопасности SID внутри контроллера. Это может произойти в виду того, что механизм репликации асинхронно посылает обновления каждые 5 минут — за это время ключи безопасности могут обновиться, а вот на реплике — еще нет. Для таких сценариев рекомендуется держать еще один экземпляр контроллера домена на резервной площадке.
Да и в общем — совет такой — если что-то у вас имеет механизмы репликации отдельно от нижестоящего уровня (например, приложение реплицируется само, а уровень приложения выше уровня контейнера с ВМ — т.к. это уровень инфраструктуры) — то лучше использовать эти нативные механизмы.
В общем — ничего сложного в настройки реплики ВМ нет.
Осталось только проверить как все это работает в реальном окружении — с радостью выслушаю фидбек от мега-админов!
P.S> Ну и конечно же — актуальные и свежие материалы по решениям Microsoft всегда можно найти на MVA!
С уважением,
Человек-огонь
Георгий А. Гаджиев
Эксперт по информационной инфраструктуре
Microsoft Corporation
Поддержка использования реплики Hyper-V для виртуализированных контроллеров домена
— DC1 и DC2 работают Windows Server 2012.
-DC2 завершает работу и отработка отказа выполняется на DC2-REC. Отработка отказа может быть запланированной или незапланированной.
-После запуска DC2-Rec проверяет, совпадает ли значение Вмженид в его базе данных со значением из драйвера виртуальной машины, сохраненного на сервере реплики Hyper-V.
-DC2-Rec сохраняет новое значение Вмженид в своей базе данных и фиксирует все последующие обновления в контексте нового InvocationID.
В результате сброса InvocationID DC1 будет объединять все изменения AD, появившиеся DC2-Rec даже в случае отката времени, что означает, что все обновления AD, выполненные на DC2-Rec после отработки отказа, безопасно сходятся.
— Все обновления AD, полученные на DC2, но еще не реплицированные AD на партнера репликации до тех пор, пока не будет потеряно событие отработки отказа.
— Обновления AD, полученные на DC2 после момента точки восстановления, реплицированной AD на DC1, будут реплицированы с DC1 обратно на DC2-REC.
Windows Server 2008 R2 и более ранних версий
В следующей таблице поясняется поддержка виртуализированных контроллеров домена, работающих под управлением Windows Server 2008 R2 и более ранних версий.
| Выполняет плановую отработку отказа. | Незапланированная отработка отказа |
|---|---|
| Поддерживается, но не рекомендуется, так как контроллеры домена, работающие под управлением этих версий Windows Server, не поддерживают VMGenID или использование соответствующих мер безопасности. Поэтому они подвержены риску отката номера последовательного обновления. Дополнительные сведения см. в разделе USN и откат USN. | Не поддерживается Примечание. Будет поддерживаться внеплановая отработка отказа, где откат USN не является риском, например, одним контроллером домена в лесу (Нерекомендуемая конфигурация). |
| Тестовый случай: — DC1 и DC2 работают Windows Server 2008 R2. -DC2 завершает работу, а плановая отработка отказа выполняется на DC2-REC. Все данные на DC2 реплицируются на DC2-Rec до завершения завершения работы. -После запуска DC2-Rec будет возобновлена репликация на DC1 с использованием того же invocationID, что и DC2. | Н/Д |
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
В данном разделе поясняется поддержка использования реплики Hyper-V для репликации виртуальной машины, которая работает в качестве контроллера домена. Реплика Hyper-V — это новый компонент Hyper-V, появившийся в Windows Server 2012, который предоставляет встроенный механизм репликации на уровне виртуальных машин.
Реплика Hyper-V асинхронно реплицирует выбранные виртуальные машины с основного узла Hyper-V на узел реплики Hyper-V по каналам локальной или глобальной сети. После завершения начальной репликации последующие изменения реплицируются с интервалом, заданным администратором.
Отработка отказа может быть как запланированной, так и незапланированной. Запланированная отработка отказа инициируется администратором для основной виртуальной машины, а все нереплицированные изменения копируются в виртуальную машину реплики для предотвращения потери данных. Незапланированная отработка отказа инициируется в виртуальной машине реплики при реагировании на непредвиденный сбой основной виртуальной машины. Потеря данных может произойти из-за отсутствия возможности передать изменения на основной виртуальной машине, которые, возможно, еще не были реплицированы.
Дополнительные сведения о Hyper-V Replica см. в разделе Обзор Hyper-V Replica и Развертывание Hyper-V Replica.
Реплика Hyper-V может выполняться только в Windows Server Hyper-V, в версии Hyper-V под управлением Windows 8 этот компонент не работает.
требуются Windows Server 2012 или более новые контроллеры домена
Windows Server 2012 Hyper-V представил VM-GenerationID (вмженид). ИД создания виртуальной машины предоставляет низкоуровневой оболочке средство взаимодействия с гостевой ОС при внесении существенных изменений. Например, низкоуровневая оболочка может сообщить виртуализированному контроллеру домена, что было выполнено восстановление из моментального снимка (технология восстановления моментальных снимков Hyper-V, а не резервных копий). AD DS в Windows Server 2012 и более новых версиях осведомлены о технологии виртуальных машин вмженид и использует ее для обнаружения выполнения операций гипервизора, таких как восстановление моментальных снимков, что позволяет ит-специалистам лучше защищать себя.
эти меры безопасности, полученные из вмженид, обеспечивают только AD DS на Windows Server 2012 DCs или более поздней версии. контроллеры доменов, на которых выполняются все предыдущие выпуски Windows Server, подвержены таким проблемам, как откат USN, который может произойти при восстановлении виртуального контроллера домена с помощью неподдерживаемого механизма, такого как восстановление моментальных снимков. Дополнительные сведения об этих мерах безопасности и условиях их активации см. в разделе Архитектура виртуализированных контроллеров доменов.
Если происходит отработка отказа реплики Hyper-V (запланированная или незапланированная), виртуализированный контроллер домена обнаруживает Вмженид сброс, активируя вышеупомянутые функции безопасности. После этого операции Active Directory продолжают выполняться в обычном режиме. Виртуальная машина реплики выполняется вместо основной виртуальной машины.
Учитывая наличие двух экземпляров одного удостоверения контроллера домена, существует вероятность одновременного выполнения как основного, так и реплицированного экземпляра. Хотя реплика Hyper-V снабжена управляющими механизмами, предотвращающими одновременное выполнение основной виртуальной машины и виртуальной машины реплики, такая ситуация все же возможна в случае обрыва канала связи между ними после репликации виртуальной машины. Если такая маловероятная ситуация все же возникнет, в виртуализированных контроллерах домена под управлением Windows Server 2012 предусмотрены специальные меры безопасности для защиты доменных служб Active Directory, в виртуализированных контроллерах домена, работающих под управлением предыдущих версий Windows Server, такие меры отсутствуют.
При использовании Hyper-V Replica убедитесь, что выполнены рекомендации для работающих виртуальных контроллеров доменов на Hyper-V. Среди прочего, в этом разделе рассматриваются рекомендации по хранению файлов Active Directory на виртуальных дисках SCSI, что позволяет гарантировать сохранность данных.
Поддерживаемые и неподдерживаемые сценарии
для внеплановой отработки отказа и тестирования отработки отказа поддерживаются только виртуальные машины под управлением Windows Server 2012 или более поздней версии. даже для плановой отработки отказа рекомендуется Windows Server 2012 или более поздней версии для виртуализированного контроллера домена, чтобы снизить риски в том случае, если администратор случайно запустит как основную виртуальную машину, так и реплицированную виртуальную машину одновременно.
Виртуальные машины под управлением предыдущих версий Windows Server поддерживаются для запланированной отработки отказа, однако не поддерживаются для незапланированной отработки отказа в связи с риском отката номера последовательного обновления. Дополнительные сведения об откате USN см. в разделе USN и откат USN.
Требования к режиму работы для домена или леса отсутствуют, имеются требования только требования к операционной системе для контроллеров домена, работающих в качестве виртуальных машин, которые реплицируются с использованием реплики Hyper-V. Виртуальные машины можно развернуть в лесу, содержащем другие физические или виртуальные контроллеры домена, которые работают под управлением предыдущих версий Windows Server и также могут как реплицироваться, так и не реплицироваться с помощью реплики Hyper-V.
Данное заявление о поддержке основано на тестах, проведенных в лесе с одним доменом, однако конфигурации леса с несколькими доменами также поддерживаются. Для этих тестов виртуализированные контроллеры домена DC1 и DC2 являются партнерами репликации Active Directory на одном сайте, размещенном на сервере, где выполняется Hyper-V в Windows Server 2012. В операционной системе виртуальной машины, где выполняется DC2, включена реплика Hyper-V. Сервер-реплика размещается в другом географически удаленном центре обработки данных. Чтобы упростить восприятие приведенных ниже процедур тестового случая, для виртуальной машины, выполняемой на сервере-реплике, используется имя DC2-Rec (хотя на практике она сохраняет имя исходной виртуальной машины).
Windows Server 2012
В следующей таблице поясняется поддержка виртуализированных контроллеров домена, работающих под управлением Windows Server 2012, и тестовых случаев.
Настройка репликации виртуальных машин в Hyper-V на Windows Server 2016
Функционал репликации в Hyper-V позволяет настроить отказоустойчивость ВМ за счет постоянной синхронизации изменений виртуальной машины, запущенной на одном сервере Hyper-V на другой сервер (сервер-партнер по репликации может даже находится в другом датаценте). Репликации в гипервизоре Microsoft Hyper-V реализуется с помощью встроенных средств (никаких дополнительных средств или плагинов устанавливать не нужно). Рассмотрим, как настроить репликацию виртуальной машины между двумя хостами с Windows Server 2016 Hyper-V.
Как включить репликацию ВМ в Windows Server 2016 Hyper-V
Чтобы настроить репликацию конкретной ВМ в Hyper-V Windows Server 2016, просто щелкните правой кнопкой мыши по нужной виртуальной машине и выберите пункт меню Enable Replication.
Запустится мастер настройки репликации. Тут, прежде чем продолжить, позволю себе небольшую ремарку касательно моей инфраструктуры.
У меня имеется один отдельностоящий хост Hyper-V на Windows Server 2016, одну из виртуальных машин которого я хочу реплицировать на созданный ранее кластер Hyper-V. При реплицаии ВМ на кластер нужно указать имя сервера-брокера — Hyper-V Replica Broker. Это особая кластерная роль, которую нужно настроить на кластере перед настройкой репликации. При попытке настроить репликацию с кластером, у которого отсутствует эта роль, появится ошибка (“The specified replica server is part of a failover cluster”).
Установка роли Hyper-V Replica Broker
Чтобы настроить роль Hyper-V Replica Broker, нужно открыть консоль управления кластером Failover Cluster Manager. Щелкните ПКМ по имени кластера и выберите опцию Configure Role.
Выберите роль Hyper-V Replica Broker.
Нужно указать имя кластерной службы и IP адрес.
На этом все. В Active Directory появится новое имя, а на кластере новая роль.
Настройка репликации виртуальной машины
Еще раз включаем репликацию для ВМ. Указываем имя сервера-брокера репликации Hyper-V. У меня появилось предупреждение:
“The specified Replica server is not configured to receive replication from this server”
В этом случае нужно нажать на кнопку Configure Server для запуска окна настройки брокера в кластере.
Убедитесь, что ваш файервол разрешает входящий трафик по порту 80 — правило Hyper-V Replica HTTP Listener (TCP-In).
Вернемся в окно настройки репликации. Как вы видите, все предупреждения пропали. 
Для единообразия с брокером, выберем тип аутентификации Use Kerberos authentication (HTTP).
Затем нужно указать vhdx файлы виртуальной машины, который нужно реплицировать (в моем случае он один).
Выберите частоту выполнения репликации (каждые 30 секунд, 5 или 15 минут).
На следующем шаге можно настроить параметры создания дополнительных снапшотов ВМ.
Затем нужно выбрать метод первичной репликации файла виртуальной машины (Initial replication Method). Можно вручную перенести файлы ВМ на целевой сервер с помощью внешнего диска (если канал между серверами недостаточно быстрый), либо скопировать файл прямо по сети.
Наконец, появится экран с выбранными опциями.
Нажимаем Finish и видим сообщение «Replication is enabled successfully».
Возвращаемся в консоль Hyper-V Manager нашего отдельного хоста (источника репликации) и видим, что для него запущен процесс создания контрольной точки и в статусе ВМ появилась надпись Sending Initial Replication и процент выполнения репликации.
На целевом хосте откроем Failover Cluster Manager. Как вы видите, на нем появилась новая виртуальная машина – реплика исходной ВМ.
Итак, репликации ВМ между двумя хостами Hyper-V в Windows Server 2016 настраивается крайне просто. Благодаря этой возможности можно довольно легко и прозрачно обеспечить катастрофоустойчивость критических виртуальных машин.