Заметки о Windows и других программных продуктах Microsoft...

Технология Hyper-V Replica в Windows Server 2012 (часть 3)

Технология Hyper-V Replica в Windows Server 2012 (часть 3)

Третья, заключительная часть статьи о технологии репликации виртуальных машин в Windows Server 2012. В ней мы рассмотрим то, ради чего собственно и нужна репликация, а именно отработку отказа (Failover). Напомню, что Hyper-V Replica не обеспечивает автоматический Failover, поэтому все операции необходимо производить вручную. При репликации есть целых три варианта файловера.

Planned Failover

Если на данный момент все в порядке, а неприятности запланированы 🙂 на определенное время, то можно не дожидаться проблем и произвести переключение с основной площадки на резервную заранее. Эта процедура называется Planned Failover. Проводить ее будем в следующей конфигурации: основной сервер GATEWAY-01, резервный сервер GATEWAY-02 и виртуальная машина TestVM.

Открываем Hyper-V Manager и подключаемся к основному серверу. Выбираем виртуальную машину TestVM и останавливаем ее. Затем в контекстном меню переходим на пункт Replication -> Planned Failover.

запуск Planned Failover

 

В открывшемся окне проверяем, соблюдены ли требования и жмем кнопку «Fail Over». Обратите внимание, что по умолчанию реплицированая машина стартует сразу после переключения. Плановый файловер проходит в несколько этапов:

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

требования для Planned Failover

 

То же самое можно сделать с помощью PowerShell. На основном сервере:

Stop-VM TestVM
Start-VMFailover -VMName TestVM –Prepare

Затем на резервном: 

Start-VMFailover -VMName TestVM
Set-VMReplication -VMName TestVM -Reverse
Start-VM TestVM

При плановом переключении нет потери данных, а реплика соответствует состоянию основной ВМ на момент выключения. Плановый файловер наиболее предпочтителен, но, как сами понимаете, в случае внезапной аварии этот вариант невозможен. Поэтому рассмотрим второй вариант.

Failover

Этот вариант на тот случай, если неприятность уже произошла и основная площадка недоступна. Ради такого дела я отключил сеть на основном сервере, которым теперь является GATEWAY-02. Переходим на резервный сервер GATEWAY-01, выбираем реплику TestVM и в контекстном меню выбираем пункт Replication -> Failover.

запуск Failover

 

При наличии дополнительных точек восстановления указываем, на какое время восстанавливать реплику и жмем «Fail Over». Обратите внимание, что будут потеряны все изменения, произошедшие с основной машиной со времени последней передачи данных.

выбор снапшота при Failover

 

Реплика ВМ запускается и начинает работать. При этом в состоянии репликации появляется сообщение о произведенном файловере, а репликация переходит в аварийное состояние.

после Filover

 

Когда последствия аварии будут устранены и связь с основным сервером будет восстановлена, у нас есть два варианта развития событий:

• Cancel Failover — произвести отмену файловера. Реплика останавливается, основная машина стартует и репликация продолжает идти в том же направлении. При этом все изменения, которые производились с репликой во время файловера, будут потеряны;
• Reverse Replication — повернуть репликацию в обратную сторону, меняя местами основной сервер и сервер реплики. Если выбрать этот пункт, то запустится мастер настройки и репликацию придется настраивать заново.

возможные действия после Filover

 

И то же из PowerShell:

Start-VMFailover -VMName TestVM
Start-VM TestVM

При переключении будет выдан запрос на подтверждение. Если вы хотите автоматизировать Failover, то надо будет подавить запрос:

Start-VMFailover -VMName TestVM -Confirm:$false

Развернуть репликацию в обратную сторону можно командой:

Set-VMReplication -VMName TestVM -Reverse

И отменить:

Stop-VMFailover -VMName TestVM

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

Test Failover

Исключительно для того, чтобы проверить работоспособность реплики ВМ, есть еще один вариант файловера — тестовый. Для его проведения подключаемся к серверу реплики, выбираем реплику TestVM, и в контекстном меню переходим на пункт Replication -> Test Failover.

запуск Test Failover

 

Также как и при обычном файловере, выбираем точку восстановления и затем жмем на кнопку «Test Failover».

выбор снапшота для Test Failover

 

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

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

Test Failover в действии

 

Проверив работоспособность реплики, мы просто идем в меню и выбираем Replication -> Stop Test Failover. Копия со всеми изменениями будет бесследно удалена с сервера.

завершение Test Failover

 

Из PowerShell Test Failover запускается командлетом Start-VMFailover с ключом -AsTest:

Start-VMFailover -VMName TestVM -AsTest

Мониторинг

Несколько слов о том, как осуществлять мониторинг репликации. Состояние, основные параметры и статистику можно посмотреть, перейдя в меню на Replication -> View Replication Health.

состояние репликации

 

Если нужны подробности, то можно воспользоваться командлетом Measure-VMReplication. Для получения полной информации команда будет выглядеть так:

Measure-VMReplication -VMName TestVM | fl *

состояние репликации в PowerShell

 

Для сбора статистики можно воспользоваться монитором производительности (Performance Monitor). В нем есть специальный счетчик Hyper-V Replica VM, в котором отслеживаются параметры репликации.

счетчики состояния репликации

 

И наконец события репликации можно найти в системном журнале, в разделе Custom Views. Логи могут пригодиться в случае проблем с репликацией.

репликация в системных логах

 Заключение

Подводя итог, рассмотрим основные плюсы и минусы технологии Hyper-V Replica.

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

Плюсы
+ Основной плюс Hyper-V Replica — это минимальные требования к оборудованию. Для репликации не нужны дорогостоящие системы хранения данных, поддерживаются любые хранилища. Выделенный канал связи также не нужен, т.к. данные передаются асинхронно и сжимаются;
+ Не требуется обязательное наличие домена AD, сервера могут находится в рабочих группах;
+ Основная и резервная площадка могут располагаться на любом расстоянии друг от друга, например в разных странах;

Microsoft позиционирует репликацию как технологию отказоустойчивости на уровне датацентров и даже придумали для Hyper-V Replica термин ”Катастрофоустойчивость”, что означает доступность сервисов даже в случае глобальной катастрофы. Однако лично я не вижу препятствий для использования репликации как дешевой альтернативы кластерам.

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

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

 
 
Комментарии
Eugene Leitan
Виталий

Отличная статья! Автору спасибо!

Александр

Хороший цикл. Спасибо. Как вы считаете можно ли будет реплицировать сервера с работающим MS SQL 2008 r2 допустим с базами 1С. У меня вызывает опасение целостность баз в репликации. Или лучше пользоваться встроенным зеркалированием самого SQL сервера.

Реплицировать сервера БД в принципе можно, для этого есть VSS. Но я предпочитаю для этих целей использовать встроенные средства MS SQL.