vSphere Replication 5.1 в продакшне: настраиваем DR с RPO 15 минут без SRM
Настраиваем vSphere Replication 5.1 между двумя площадками клиента - репликация без SRM и без одинаковых СХД. RPO 15 минут, первый реальный DR для небольшого бизнеса.
VMware vSphere 5.1 вышел 27 августа 2012 с vSphere Replication 5.1, vMotion без shared storage и VXLAN в составе vSphere Networking
В марте мы разбирали анонс vSphere 5.1 и считали, как vSphere Replication меняет арифметику DR для небольших клиентов. С тех пор VMware дала бету, мы получили доступ и развернули стенд. А на прошлой неделе один клиент дал добро - делаем на нём пилот в реальных условиях.
Пишем по горячим следам, пока не всё устоялось.
Что за клиент и почему не SRM
Производственный офис, около 25 виртуальных машин на vSphere 5.0: контроллер домена, 1С, файловый сервер, несколько прикладных систем. Основная площадка - собственная серверная. Резервная - арендованный стоечный сервер в коло, примерно в 20 км.
DR у клиента не было вообще. Были ежедневные бэкапы на локальный NAS и раз в неделю - архив на внешний диск. Разговоры про «нормальный» DR шли года полтора: как только называли ценник SRM плюс совместимые СХД на обеих площадках, разговор заканчивался. Не потому что клиент жадный, а потому что реально не влезало в бюджет - SRM на 25 ВМ это несколько тысяч долларов только в лицензиях, и это без железа на резервной площадке.
vSphere Replication без SRM - другая история.
Что разворачивали
Схема простая: основной хост с vSphere Essentials Plus, резервный хост в коло с такой же лицензией, между ними - выделенный канал 50 Мбит/с от одного провайдера. vCenter на основной площадке.
vSphere Replication работает через виртуальный аплайанс - vSphere Replication Appliance. Его нужно два: один на основную площадку, один на резервную. Разворачивается из OVF-пакета в vCenter, конфигурируется через веб-интерфейс. Процедура без сюрпризов, если читать документацию. Мы читали.
Настройка репликации для конкретной ВМ - через правую кнопку в vCenter: «Configure Replication», выбираешь целевой сайт, целевое хранилище, ставишь RPO. Минимальный RPO в 5.1 - 15 минут, максимальный - 24 часа. Для клиента выбрали 15 минут для критичных ВМ (контроллер домена, 1С-сервер) и час для остальных.
Что реально потребовало времени
Первый seed. При первичной репликации vSphere Replication гонит полный образ ВМ на резервную площадку. Для диска в 200 ГБ это занимает несколько часов при канале 50 Мбит/с - математика простая. На 25 машин мы растянули seed на три дня, запуская следующую партию после того, как предыдущая переходила в инкрементальный режим.
Тротлинг трафика. Без ограничений репликация во время первого seed забивала канал полностью. vSphere Replication умеет ограничивать полосу через параметр в аплайансе, но интерфейс это не выпячивает - нашли в документации. Ограничили до 25 Мбит/с в рабочее время, ночью - без ограничений.
Сеть на резервной площадке. У виртуальных машин после failover должны быть рабочие IP-адреса. Без SRM автоматической смены сети нет - машина стартует с теми же настройками, что были на основной площадке. Клиент согласился на ручную перенастройку IP после failover. Для 25 ВМ это реально, хоть и требует аккуратного плана: список машин, IP на основной, что ставить на резервной, порядок старта.
Этот план мы оформили как отдельный документ - RunBook DR. Без него никакая репликация не поможет: три человека в ночи будут выяснять, что запускать первым - контроллер домена или 1С-сервер.
Как выглядит мониторинг
vCenter показывает состояние репликации для каждой ВМ прямо во вкладке Summary: когда был последний checkpoint, текущий статус, отставание от RPO. Это удобно - не нужно лезть отдельно в аплайанс за каждой машиной.
Для managed-сопровождения нам важны алерты: если репликация отстаёт или встала - об этом надо знать не от клиента. vCenter генерирует события по каждой ВМ при нарушении RPO, но алерты из коробки не очень информативны. Мы прописали кастомные правила в vCenter Alarms: если ВМ из списка критичных не имеет checkpoint за последние 20 минут - отправка на почту и в наш Zabbix через внешний скрипт.
Пока работает, но это не элегантно. Ждём, когда VMware добавит нормальный SNMP MIB для состояния репликации.
Что обнаружили в процессе
RPO 15 минут - это не гарантия потери не более 15 минут данных. Это частота синхронизации. Если за эти 15 минут на диске VM было интенсивное IO, следующий checkpoint может немного съехать. На тестовых машинах с активной записью мы видели расхождение от 15 до 22 минут. Для большинства офисных систем это нормально, но 1С-сервер во время активной работы пользователей - отдельный разговор.
Failover без SRM - ручной. Правая кнопка на ВМ, «Recover» на резервном сайте, vSphere Replication Appliance поднимает машину из последнего checkpoint. Мы прогнали это на тестовых ВМ несколько раз - работает. Время от решения «переключаемся» до работающей 1С на резервной площадке в нашем тесте составило около 40 минут, включая ручную перенастройку сети и проверку запуска сервисов.
Это несравнимо с нулевым DR, который был раньше. С другой стороны, SRM автоматизировал бы половину этих действий.
Где сейчас
Репликация крутится третью неделю. Checkpoint'ы ходят, мониторинг молчит. Клиент смотрит на дашборд в vCenter и первый раз в жизни видит, что у него есть что-то похожее на DR.
Полноценный тест failover с остановкой основной площадки - запланирован на конец месяца, в воскресенье. Отпишемся по результатам: насколько RunBook оказался точным и где он расходится с реальностью.
Пока вывод осторожный: vSphere Replication 5.1 реально снижает порог входа в DR для небольших компаний. Не замена SRM для серьёзных требований по RTO, но очень приличный первый уровень защиты там, где его вовсе не было.