Hyper-V Replica в 2012 R2: DR без лицензионного бюджета

Клиент - небольшая производственная компания - пришёл с классическим запросом: «хотим DR, но Veeam дорого, VMware Site Recovery вообще не рассматриваем». Под капотом у них Hyper-V на Windows Server 2012 R2 - и, оказалось, там уже есть всё нужное.

Hyper-V Replica появилась ещё в 2012, но в R2 добавили самое важное: период репликации 30 секунд в дополнение к стандартным 5 минутам первой версии. Для большинства некритичных систем это вполне приемлемо, а для критичных уже не так страшно, как было раньше.

Что за задача

Три виртуальных машины: контроллер домена, файловый сервер и 1С-сервер. Основной хост - в офисе, резервный - в арендованном ЦОД в паре десятков километров, связаны по аренде волокна. Требование клиента: при падении основной площадки поднять всё на резервной за разумное время. Разумным считали до получаса.

Veeam Backup & Replication для этого подходит, но у них уже была лицензия Windows Server 2012 R2 Datacenter - а Hyper-V Replica идёт в комплекте. Нулевые дополнительные расходы на ПО. Это решило вопрос выбора быстро.

Настройка: три шага и несколько граблей

Первое - авторизация хостов. Hyper-V Replica требует, чтобы принимающий хост явно разрешил репликацию от конкретного источника. В диспетчере Hyper-V, в настройках сервера - раздел Replication Configuration. Можно разрешить от любого сервера Kerberos в домене, можно ограничить конкретными машинами. Выбрали второй вариант - принимаем только от основного хоста по имени. Между хостами используем сертификатную аутентификацию, потому что они в разных доменах (офис и ЦОД - разные AD). Это добавило возни с генерацией сертификатов, но зато трафик идёт по HTTPS на порт 443 - никаких вопросов к межсетевому экрану.

Второе - включение репликации на VM. Правый клик на машине, Enable Replication, указываем хост-реплику, выбираем диски (не все - логи репликации Hyper-V создаёт сам), период репликации - 5 минут. Запускается initial replication: по умолчанию это передача начального снимка по сети, что для трёх VM суммарно под 200 ГБ заняло несколько часов ночью. Есть вариант с экспортом на USB и ручным переносом - использовали бы, если бы канал был медленнее.

Третье - мониторинг состояния. Статус репликации виден прямо в диспетчере Hyper-V - последний successful replication, состояние (Normal / Warning / Critical). Добавили проверку через PowerShell в Zabbix:

Get-VMReplication | Select-Object VMName, State, Health, LastReplicationTime

Если Health не Normal или последняя репликация была больше 15 минут назад - алерт. Простой скрипт, но даёт уверенность что репликация не встала незаметно.

Грабли, на которые наступили:

• Синхронизация времени. Хосты в разных площадках, время незначительно расходилось. Hyper-V Replica капризна к рассинхрону - начинает ругаться при расхождении больше 5 минут. Поправили NTP, проверили что оба хоста смотрят на один источник.
• Антивирус на хосте. На основном хосте стоял антивирус с защитой в реальном времени. Папки с VHD-файлами и папки репликации нужно добавлять в исключения - иначе антивирус блокирует запись во время репликации и весь процесс ломается с непонятными ошибками. На это потратили час отладки.
• Место на резервном хосте. Replica хранит recovery points - по умолчанию одна точка, можно настроить до 24 часов истории. Настроили на 4 точки - это примерно 3 часа истории. Место нужно с запасом: на резервном хосте должно быть столько же, сколько занимают сами VM, плюс несколько точек восстановления сверху.

Тест восстановления

Через неделю после запуска провели плановый failover test. Hyper-V Replica позволяет делать это без прерывания репликации - специальная операция Test Failover создаёт временную копию VM на резервном хосте из последней точки восстановления, не ломая основной репликационный канал.

Результат по времени:

• Запустить Test Failover на трёх VM - около 3 минут
• Дождаться загрузки VM - 5-7 минут (зависит от машины, 1С-сервер стартует дольше)
• Проверка доступности сервисов, вход в домен, открытие баз в 1С - ещё 2-3 минуты

Итого примерно 12 минут от команды до «всё работает». Клиент ожидал до 30 минут - уложились с запасом. Test Failover убираем той же кнопкой, VM на реплике удаляется, репликация продолжается как ни в чём не бывало.

Важная оговорка: Test Failover и реальный Failover - разные сценарии. При реальном аварийном переключении нужно дополнительно обновить DNS (контроллер домена переедет, IP может измениться), пересмотреть маршрутизацию - это не сделается само. Задокументировали чек-лист из 8 пунктов на случай настоящей аварии, разобрали с клиентом.

Что не покрывает Hyper-V Replica

Это асинхронная репликация с интервалом 5 минут. RPO = 5 минут в лучшем случае - при внезапной аварии потеряем до 5 минут транзакций. Для 1С с не очень активной базой это терпимо, клиент согласился.

Репликация - это не бэкап. VM реплицируется вместе с её состоянием: если кто-то удалит файлы или база данных повредится - через 5 минут это приедет на реплику тоже. Recovery points частично спасают (откатиться на 3 часа назад), но полноценный бэкап с историей никуда не делся - репликация его не заменяет, а дополняет.

Где сейчас

Схема работает третью неделю, репликация идёт штатно. Потребление канала - в районе 2-5 Мбит/с в зависимости от активности на VM, что в рамках их аренды волокна вполне комфортно. Следующий плановый тест - через месяц, уже с проверкой реального переключения DNS и пользовательского доступа.

Если у клиента уже есть Hyper-V на 2012 R2 - Replica это первое, на что стоит смотреть при разговоре о DR. Нулевые дополнительные лицензии, настройка за день, понятный результат. Для небольших инфраструктур под управляемым сопровождением это сейчас наш первый выбор перед тем, как говорить про Veeam или что-то тяжелее.