Hyper-V Replica в 2012 R2: RPO 5 минут для 20 VM без SAN-репликатора

Когда у клиента стоит вопрос о disaster recovery, первый рефлекс у многих интеграторов - смотреть в сторону SAN с аппаратной репликацией. Это надёжно, предсказуемо и стоит как небольшой автомобиль за лицензии и железо. Для среднего бизнеса с 20 виртуальными машинами и одним арендованным серверным шкафом в колокейшне - это часто просто нереально по бюджету.

Мы в последние недели как раз разбирались с такой задачей. Клиент - производственная компания, основные системы в своём серверном помещении, резервная площадка в колокейшне в другом конце города. Гипервизор - Hyper-V на Windows Server 2012 R2, переехали туда в начале года. И вот свежая новость из мира Microsoft: в 2012 R2 появилась поддержка Extended Replication - то есть интервалы репликации теперь не только 15 минут, но и 5 минут, и даже 30 секунд. Это меняет расчёт.

Что такое Hyper-V Replica и при чём здесь Extended Replication

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

В 2012 R2 добавили Extended Replication: вы настраиваете основную репликацию с интервалом 5 минут, а поверх неё - расширенную на второй (третий) хост. Кроме того, появился интервал 30 секунд - для самых критичных ВМ, готовых платить за это трафиком и IOPS на принимающей стороне.

Для нашего клиента мы взяли 5 минут - это компромисс между RPO и нагрузкой на канал между площадками.

Как выглядела схема

Первичный хост - два сервера в Hyper-V кластере на основной площадке. Реплика-хост - один сервер в колокейшне, там же Hyper-V, та же версия 2012 R2. Канал между площадками - арендованный 100 Мбит/с, чего вполне хватает для 20 ВМ при инкрементальной репликации.

Настройка репликации делается через Hyper-V Manager или PowerShell. Мы пошли через PowerShell - проще автоматизировать на 20 машин, чем кликать по каждой в GUI:

# Включаем роль Replica Server на принимающем хосте
Set-VMReplicationServer -ReplicationEnabled $true `
    -AllowedAuthenticationType Certificate `
    -ReplicationAllowedFromAnyServer $false

# Настраиваем репликацию для каждой ВМ
Enable-VMReplication -VMName "vm-erp-01" `
    -ReplicaServerName "replica-host.domain.local" `
    -ReplicaServerPort 443 `
    -AuthenticationType Certificate `
    -CertificateThumbprint $thumbprint `
    -ReplicationFrequencySec 300

Аутентификация через сертификаты - это важно, если реплика-хост не в домене или домен разный на площадках. У клиента площадки в одном домене, но мы всё равно взяли сертификаты - на случай если в аварийной ситуации связность с контроллерами домена окажется под вопросом. Потеря видимости DC в аварийной ситуации - отдельная головная боль.

Что проверяли и где споткнулись

Первоначальный дельта-синк после настройки - самое медленное место. 20 ВМ, суммарно несколько терабайт, первая репликация идёт через сеть. Мы делали начальную синхронизацию ночами, по несколько ВМ, чтобы не перегружать канал. По-хорошему - лучше заранее договориться о возможности перевезти начальный снапшот на носителе.

Первая проблема, на которую наткнулись: на реплика-хосте не хватало места на диске для точек восстановления. Hyper-V Replica хранит несколько точек (по умолчанию - 1, можно до 15 для Recovery History), и каждая жрёт место. Пришлось пересчитать хранилище с учётом того, что у нас 5-минутный интервал и 24 часа истории - это примерно 288 точек на ВМ в пике. На практике место требуется не под 288 полных копий, а под дельты, но всё равно нужно считать заранее.

Второй момент - тестирование отказоустройства. Hyper-V Replica позволяет делать Test Failover без прерывания репликации - поднимаешь ВМ на реплике в изолированной сети, проверяешь что она стартует и работает, потом убираешь. Это важно делать регулярно, потому что ВМ которую «никогда не проверяли» - это не DR, это иллюзия DR. Настроили ежеквартальный регламент в рамках сопровождения.

Третья история - failover из Windows Server Failover Cluster. Если ВМ живёт в кластере (а у нас кластер на основной площадке), репликация работает, но failover нужно делать аккуратно: сначала вывести ВМ из-под управления кластера, потом инициировать failover на реплике. Порядок действий важен, иначе можно получить split-brain ситуацию, если кластер вдруг решит поднять ВМ самостоятельно.

Что получилось по факту

RPO 5 минут на 20 ВМ - достигнут. Трафик репликации в рабочее время держится в пределах 20-30 Мбит/с на 100-мегабитном канале - есть запас. Ночью, когда идут бэкапы через Veeam, трафик разумнее ограничить через QoS-политику на маршрутизаторе, иначе репликация и бэкап начинают соревноваться за канал.

Стоимость решения по лицензиям - нулевая поверх уже купленных Windows Server лицензий. Железо на реплика-хосте - один сервер в колокейшне, которого хватает для запуска 20 ВМ в аварийном режиме (не все одновременно под полной нагрузкой, но для работы в ограниченном режиме - достаточно). RTO зависит от того, сколько ВМ нужно поднимать и в каком порядке - это уже вопрос к регламенту, а не к технологии.

Для сравнения: SAN-репликатор на аналогичный объём потребовал бы отдельного iron-level железа на обеих площадках и лицензии, которые в сумме легко перевалили бы за несколько миллионов рублей. Hyper-V Replica - это не замена SAN-репликации для enterprise-нагрузок с синхронным RPO=0, но для СМБ с асинхронным DR и приемлемым RPO в 5 минут - вполне рабочая история.

Пока смотрим как ведёт себя в продакшне. Первая реальная проверка будет, когда в следующий раз понадобится плановое обслуживание основной площадки.