DR-тест с Hyper-V Replica на WS2016: RTO 25 минут и шифрование репликационного трафика без overhead
Плановый DR-тест на Windows Server 2016: Hyper-V Replica с шифрованием трафика и расширенным журналом изменений, RTO критичных ВМ клиента - 25 минут по факту замера.
Hyper-V Replica в Windows Server 2016 получил улучшенную репликацию с поддержкой шифрования и расширенным журналом изменений
На прошлой неделе провели плановый DR-тест для одного из клиентов - первый полноценный тест на новой инфраструктуре Windows Server 2016 с Hyper-V Replica. Не учебная тревога на бумаге, а реальный failover с замером времени и разбором того, что пошло не по плану. Результат оказался лучше, чем ожидали, хотя и не без нюансов.
Предыстория
Клиент - производственная компания, несколько критичных сервисов: ERP, файловый сервер, контроллер домена. Инфраструктура живёт у нас в managed-окружении. Основная площадка - один дата-центр, реплика - в другом. Hyper-V Replica использовали и раньше, на WS2012 R2, но с переездом на WS2016 в октябре перешли и на новую версию репликации.
DR-тест был запланирован ещё в сентябре - раз в полгода, обязательно. Последний раз делали в мае, результат был не очень: RTO по факту вышло около 55 минут вместо заявленных 30, потому что один из ВМ не поднялся чисто и пришлось возиться с сетевыми настройками вручную. В этот раз хотели разобраться конкретно.
Что нового в Hyper-V Replica на WS2016
Если сравнивать с тем, что было в 2012 R2, в 2016 есть несколько изменений, которые реально влияют на практику.
Шифрование репликационного трафика. В 2012 R2 трафик между primary и replica шёл по HTTP или HTTPS - и HTTPS требовал отдельной возни с сертификатами, так что большинство инсталляций работали по HTTP через выделенный VLAN и надеялись на сегментацию. В 2016 шифрование через Kerberos делается в несколько кликов без PKI. Для реплики в чужом дата-центре это существенно.
Расширенный журнал изменений (HRL). Replica Log теперь хранит историю изменений за более длинный период и ведёт себя устойчивее при длинных разрывах связи между площадками. В нашей инсталляции это почувствовалось: пара выходных с нестабильным каналом между DC не привела к тому, что реплика встала на full resync, как это иногда случалось раньше.
Частота репликации. Минимальный интервал репликации снизился до 30 секунд вместо 5 минут в 2012 R2. Для критичных ВМ с низким RPO это важно.
Как проводили тест
Сценарий был согласован с клиентом заранее: имитируем недоступность основной площадки, поднимаем реплику, проверяем что все критичные сервисы работают, фиксируем время каждого шага, откатываемся обратно.
Критичные ВМ для теста:
- контроллер домена (2 штуки)
- файловый сервер
- сервер ERP-системы
- шлюз RDP
Всего пять машин, из которых три крупные по объёму дисков - ERP и файловый сервер суммарно под 2 ТБ данных. Для репликации это важно: failover по времени зависит не от объёма данных (данные уже реплицированы), а от последовательности запуска и зависимостей между ВМ.
Шифрование настраивалось через PowerShell, ничего экзотического:
Set-VMReplication -VMName "erp-server" -ReplicationFrequencySec 30 `
-AuthenticationType Kerberos -CompressionEnabled $trueЧто замеряли
| Этап | Время |
|---|---|
| Команда на failover всех ВМ | 0:00 |
| DC1 и DC2 доступны | 0:08 |
| Файловый сервер доступен | 0:14 |
| ERP-сервер загружен | 0:19 |
| RDP-шлюз, первый пользователь вошёл | 0:25 |
25 минут от команды до реального рабочего места пользователя. Это по грязному замеру - включая время на то, чтобы переключить DNS у клиента на резервную площадку и убедиться что браузер идёт куда надо.
Для сравнения: в мае на WS2012 R2 было 55 минут с ручными правками. Разница существенная, хотя сравнение не совсем чистое - в мае был инцидент с сетью, а не просто медленная реплика.
Где потратили время лишнего
Два момента, которые съели минуты и которые стоит учесть.
Порядок запуска ВМ. Failover в Hyper-V не знает о зависимостях между ВМ - он поднимает их в том порядке, в котором вы указываете. Если ERP-сервер стартует раньше DC и не видит домен при загрузке - сервис поднимается в деградированном режиме, потом надо рестартовать. Это известная история, но в тестовом сценарии на неё всё равно потратили минут пять, пока разбирались что ERP ругается на AD. Решение простое: зафиксировать порядок запуска в runbook и не отступать.
DNS-переключение вручную. У клиента внешний DNS для RDP-шлюза управляется вручную. В тесте это отняло лишние несколько минут - надо было зайти в панель регистратора и поменять A-запись. Это точка, которую стоит автоматизировать или хотя бы перенести управление DNS на что-то с API.
Про шифрование и overhead
Отдельно про шифрование репликационного трафика - потому что изначально был вопрос, не просядет ли скорость репликации при включённом Kerberos и сжатии одновременно.
По нашим наблюдениям на этом клиенте - не просела. Репликация 30-секундных слепков укладывается в канал без ощутимого роста нагрузки по сравнению с тем, что было на HTTP без шифрования. Объяснение, скорее всего, простое: основной объём трафика определяется дельтой изменений, а не шифрованием - если дельта небольшая, и трафик небольшой вне зависимости от того, шифруется он или нет. При массовых изменениях картина могла бы быть другой, но для типичной рабочей нагрузки ERP + файловый сервер это не проблема.
Что дальше
Результат теста зафиксирован в отчёте для клиента: RTO 25 минут, все пять критичных ВМ подняты в рамках сценария, два пункта для доработки - порядок запуска в runbook и автоматизация DNS.
Следующий тест через полгода. Задача - убрать ручное переключение DNS и добавить автоматическую проверку порядка старта ВМ через скрипт. Тогда посмотрим, можно ли приблизиться к 15 минутам.
Hyper-V Replica остаётся инструментом, который не требует дополнительных лицензий поверх Windows Server Datacenter и при этом даёт вполне рабочий DR для среднего сегмента. Не Zerto и не Site Recovery Manager, но для задачи «поднять пять ВМ на резервной площадке за разумное время» - справляется.