Третья, заключительная часть статьи о технологии репликации виртуальных машин в Windows Server 2012. В ней мы рассмотрим то, ради чего собственно и нужна репликация, а именно отработку отказа (Failover). Напомню, что Hyper-V Replica не обеспечивает автоматический Failover, поэтому все операции необходимо производить вручную. При репликации есть целых три варианта файловера.
Planned Failover
Если на данный момент все в порядке, а неприятности запланированы 🙂 на определенное время, то можно не дожидаться проблем и произвести переключение с основной площадки на резервную заранее. Эта процедура называется Planned Failover. Проводить ее будем в следующей конфигурации: основной сервер GATEWAY-01, резервный сервер GATEWAY-02 и виртуальная машина TestVM.
Открываем Hyper-V Manager и подключаемся к основному серверу. Выбираем виртуальную машину TestVM и останавливаем ее. Затем в контекстном меню переходим на пункт Replication -> Planned Failover.
В открывшемся окне проверяем, соблюдены ли требования и жмем кнопку «Fail Over». Обратите внимание, что по умолчанию реплицированая машина стартует сразу после переключения. Плановый файловер проходит в несколько этапов:
• Все изменения, произошедшие со времени последней репликации, сохраняются и передаются на сервер реплики;
• Происходит переключение с основной ВМ на реплику;
• Репликация разворачивается в обратную сторону, т.е. основной и резервный сервер меняются местами;
• Виртуальная машина запускается.
То же самое можно сделать с помощью 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.
При наличии дополнительных точек восстановления указываем, на какое время восстанавливать реплику и жмем «Fail Over». Обратите внимание, что будут потеряны все изменения, произошедшие с основной машиной со времени последней передачи данных.
Реплика ВМ запускается и начинает работать. При этом в состоянии репликации появляется сообщение о произведенном файловере, а репликация переходит в аварийное состояние.
Когда последствия аварии будут устранены и связь с основным сервером будет восстановлена, у нас есть два варианта развития событий:
• Cancel Failover — произвести отмену файловера. Реплика останавливается, основная машина стартует и репликация продолжает идти в том же направлении. При этом все изменения, которые производились с репликой во время файловера, будут потеряны;
• Reverse Replication — повернуть репликацию в обратную сторону, меняя местами основной сервер и сервер реплики. Если выбрать этот пункт, то запустится мастер настройки и репликацию придется настраивать заново.
И то же из 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. Эту копию можно запустить как обычную виртуалку, при этом не надо останавливать основную машину.
Примечание. Чтобы избежать конфликтов, тестовую копию лучше подключать к отдельной, изолированой сети. В настройках сети для Test Failover можно указать отдельный виртуальный коммутатор.
Проверив работоспособность реплики, мы просто идем в меню и выбираем Replication -> Stop Test Failover. Копия со всеми изменениями будет бесследно удалена с сервера.
Из PowerShell Test Failover запускается командлетом Start-VMFailover с ключом -AsTest:
Start-VMFailover -VMName TestVM -AsTest
Мониторинг
Несколько слов о том, как осуществлять мониторинг репликации. Состояние, основные параметры и статистику можно посмотреть, перейдя в меню на Replication -> View Replication Health.
Если нужны подробности, то можно воспользоваться командлетом Measure-VMReplication. Для получения полной информации команда будет выглядеть так:
Measure-VMReplication -VMName TestVM | fl *
Для сбора статистики можно воспользоваться монитором производительности (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 можно использовать не вместо, а вместе с кластерами, для обеспечения еще большей отказоустойчивости.
Дополнение:
Для мониторинга можно использовать SCOM
http://blogs.technet.com/b/virtualization/archive/2013/09/13/monitoring-hyper-v-replica-using-system-center-operations-manager.aspx