VMware анонсировала vSphere 5.1: vReplication без SRM - считаем CAPEX для DR

VMware на прошлой неделе анонсировала vSphere 5.1 и сразу выкатила несколько слайдов, от которых у нас дёрнулось ухо: vSphere Replication как встроенная фича без отдельной лицензии SRM. Релиз обещают в августе, но думать об этом надо сейчас - у нескольких клиентов вопрос DR завис именно из-за цены SRM-связки.

Пишем, что поняли из анонса и как это меняет цифры.

Что было до 5.1 и почему DR стоил дорого

Классический DR на VMware - это связка vSphere + Site Recovery Manager. SRM умеет координировать failover: переключает ВМ на резервную площадку по плану, работает с репликацией на уровне хранилища (через storage array-based replication) и сам оркестрирует порядок включения виртуалок. Штука мощная, но лицензия SRM продаётся отдельно и стоит заметно - примерно от $2000 на виртуальную машину для средней конфигурации, плюс нужны два одинаковых СХД, которые умеют синхронную или асинхронную репликацию между собой. Для небольшого кластера из 20-30 ВМ это превращалось в сумму, которая у клиентов класса «средний бизнес» немедленно замораживала проект.

Мы несколько раз проходили через такой разговор: клиент хочет DR, мы объясняем архитектуру, называем ценник, клиент грустнеет и говорит «ну и ладно, будем делать cold backup». Не самый приятный итог.

Что такое vSphere Replication и зачем оно нам

vSphere Replication - это репликация на уровне гипервизора, а не на уровне железа. Компонент уже был в VMware Site Recovery Manager 5.0 как встроенный движок, но работал только в связке с SRM. В версии 5.1 его вытаскивают как самостоятельную функцию, доступную с лицензией vSphere Essentials Plus и выше.

Что это означает практически:

• Репликация ВМ между двумя площадками без покупки SRM, без требования к «поддерживающим репликацию» массивам. Достаточно двух хостов с vSphere и общей сети между площадками.
• Гранулярность до отдельной ВМ: можно реплицировать критичные машины, а не весь кластер.
• RPO от 15 минут: не синхронная репликация, но для большинства DR-сценариев среднего бизнеса это нормально.
• vMotion без общего хранилища - тоже из 5.1. Это чуть отдельная тема, но в контексте DR интересно: ВМ можно переехать между хостами без общего массива, только по сети. Медленнее, но при отказе площадки - рабочий вариант.

Арифметика CAPEX для среднего клиента

Возьмём типичный сценарий: клиент с основной площадкой, 20 ВМ, хочет DR на коло или в арендованный сервер. Раньше минимальный набор для «правильного» DR выглядел примерно так:

• Лицензии vSphere на основной площадке - уже куплены.
• Лицензии vSphere на резервной площадке - нужны.
• SRM на обеих площадках.
• Два СХД с поддержкой синхронной/асинхронной репликации.

Самое болезненное - СХД. Поставить на резервную площадку нормальный массив, совместимый с основным и умеющий репликацию - это отдельная строка в бюджете, и немаленькая. Для 20 ВМ это типично несколько сотен тысяч рублей только на железо резервной площадки.

С vSphere Replication картина другая: на резервной площадке достаточно хоста с локальными дисками или любым дешёвым хранилищем. Репликация идёт напрямую между гипервизорами. СХД с поддержкой репликации на обеих площадках - больше не обязательное условие. SRM - тоже.

Что остаётся в минусах: нет автоматической оркестрации failover, которую даёт SRM. Переключение при аварии придётся делать руками или скриптами. RPO 15 минут - это не синхрон, какие-то данные потеряются. И мы пока не знаем, насколько стабильно это работает в продакшне - анонс есть, релиз в августе, тестировать будем.

Где это реально снижает CAPEX

Наш вывод из анонса: vSphere Replication интересен клиентам, которым:

• DR нужен как best effort, а не как сертифицированный recovery plan.
• RPO 15-30 минут достаточно (большинство офисных систем, 1С на небольших нагрузках, некритичные сервисы).
• Бюджет не позволяет поставить два идентичных СХД с репликацией.
• Реплицировать нужно не всё, а несколько ключевых ВМ.

Для клиентов с требованиями по RTO в минуты и RPO в нули - SRM + storage replication никуда не денется. Но таких в нашей практике меньшинство.

Несколько проектов, где DR завис из-за бюджета, мы уже поставили на паузу до августа - посмотреть на реальный релиз и прогнать через стенд. Если vSphere Replication работает так, как описано в анонсе, это разблокирует несколько разговоров, которые сейчас идут ни к чему.

Что с managed-поддержкой и мониторингом репликации

Отдельный вопрос - как мониторить состояние репликации. SRM даёт для этого нормальный интерфейс и интеграцию с vCenter. У vSphere Replication свой vSphere Replication Appliance - это отдельная виртуальная машина-менеджер, которую нужно разворачивать и поддерживать. Подробностей пока немного, смотрим на то, что VMware публикует в предрелизной документации.

Для клиентов на сопровождении нам важно понять, как статус репликации будет отдаваться в vCenter - есть ли нормальный API для алертов или придётся ловить события самодельными скриптами. Это один из первых вопросов на стенде.

До августа ждём. Анонс выглядит как то, что многие ждали.