Пожар в ЦОДе, авария на подстанции, разорванный во время ремонта кабель между площадками — таких инцидентов за последние годы хватает. Например, в конце этого сентября пожар в государственном дата-центре Южной Кореи парализовал сотни госсервисов и уничтожил свыше 800 терабайтов данных без резервных копий.
Единственная реальная защита от таких сценариев — геораспределенные инсталляции с Disaster Recovery (DR). Система автоматически перекидывает нагрузку на резервную, если основная упала. Большинство российских ИТ-инфраструктур виртуализированы, сервисы работают в виртуальных машинах, и заказчикам нужны DR-сценарии именно для виртуализации. Поэтому мы в Orion soft разработали модуль DR для собственной платформы виртуализации zVirt. Он обеспечивает программную репликацию на уровне гипервизора (без агентов внутри гостевых ОС) и аппаратную на уровне СХД.
Я Александр Гавриленко, директор технического пресейла zVirt. В этой статье расскажу, как мы воспроизвели привычную функциональность VMware, что адаптировали под специфику российского рынка и чем наш DR отличается от того, что было доступно в oVirt.
DR — здесь и сейчас
Раньше DR казался чем-то далеким: про глобальные катастрофы, которые всегда происходят где-то еще. Практика показывает другое. Аварии случаются не «где-то», а буквально через дорогу: горят дата-центры, отрубаются кабели, выходят из строя подстанции. Например, в июне 2019 года из-за пожара в DataLine на Боровой вышел из строя машинный зал — 700+ ВМ оказались недоступны. Те, у кого был настроен DR, избежали длительного простоя. В марте 2025 авария отключила оба ввода 110 кВ в дата-центре «Яндекса», но команда за 35 минут перенаправила трафик, и сервисы продолжили работу почти без перебоев.
Опасны и физические повреждения каналов между площадками. Если разрывается связь между ЦОДами, возникает split-brain: оба центра считают себя главными и не перестают согласовывать данные.
Да, DR нужен не всем. Это решение для крупного бизнеса с критичными сервисами, простой которых измеряется в миллионах убытков. Способы локальной отказоустойчивости могут решить проблему с типовыми сбоями, но не защитят в случае пожара, наводнения или обесточивания. Здесь уже нужен DR с географически удаленной площадкой.
Привычка к хорошему
DR работает на разных уровнях: железо, виртуализация, приложения. Большинство инфраструктур построено на виртуализации, и без ее защиты никуда. VMware vSphere решал задачу встроенными средствами. Все настраивалось из одного интерфейса, контролировалось напрямую, работало понятно и стабильно без скриптов и костылей. Западные платформы установили стандарт, к которому наш рынок быстро привык.
На аппаратном уровне производители СХД предлагали готовые инструменты для катастрофоустойчивости. Синхронная репликация между массивами обеспечивала нулевые потери данных, но требовала быстрых каналов (от 10 Гбит/с) и близкого расположения площадок.
Асинхронная репликация допускала потерю данных за последние минуты, зато была менее требовательна к каналу. Были и более мощные подходы на основе метрокластера: когда две СХД работали как один растянутый кластер, а RPO (максимально допустимая потеря данных) стремилась к нулю. У многих ведущих западных вендоров в линейке были решения такого класса.
На уровне виртуализации все тоже было максимально прозрачно. Администратор открывал встроенный графический интерфейс, видел состояние репликации, управлял защитой ВМ и выполнял восстановление без скриптов, командной строки и паники. В VMware за это отвечал Site Recovery Manager, который управлял как программной репликацией vSphere Replication, так иинтегрировался с топовыми СХД.
Был еще и третий уровень — приложения. Крупные СУБД и специализированные платформы имели встроенную репликацию данных. Ее часто выбирали именно потому, что в этом варианте консистентность данных гарантируется на уровне самого приложения.
Встроенные DR-решения стали стандартом нашего рынка. Западные платформы предлагали такую функциональность как естественную часть инфраструктуры: команда заказчика выбирала подходящий уровень защиты в зависимости от бюджета и требований к RPO, RTO. Настраивала все из знакомого интерфейса и получала предсказуемый результат. Такой подход сформировал ожидание: DR должен быть встроен в решение, а не собираться из отдельных компонентов.
Почему решили делать DR с нуля
В oVirt, на базе которого мы начали разрабатывать нашу платформу zVirt, готовых средств для DR не было. В сообществе oVirt есть статья с примерами, как можно реализовать подобные сценарии на практике. Но это не набор продуктовых функций, а список примеров, как собрать DR вручную под конкретное внедрение.
Аппаратная репликация: нет центрального контроля. В oVirt аппаратная репликация сводится к ansible-скриптам. Нет штатных интеграций с системами хранения данных, все приходится настраивать вручную. Администратор остается один на один с командами и ошибками, без визуального интерфейса и единой панели управления. Статус репликации не виден, мониторить процесс нельзя. Для корпоративных команд это критичное ограничение: минуты простоя значимы, а если случилась авария, то скрипты легко сломать или запустить не вовремя, особенно в стрессе.
Программная репликация: в oVirt нет вообще — даже на уровне примеров и скриптов.
Что мы сделали в zVirt
Мы интегрировали аппаратную репликацию СХД в интерфейс zVirt. Администратор настраивает защиту ВМ через интерфейс платформы, видит статус репликации в консоли, запускает восстановление оттуда же. Переключение направления репликации автоматизировано и не требует ручных действий администратора СХД.
Программную репликацию реализовали на уровне гипервизора через снапшоты ВМ, без установки агентов внутрь гостевых ОС. Система создает снапшоты дисков ВМ и передает на резервную площадку только изменения по расписанию. Все точки восстановления под контролем, поддерживается до пяти точек восстановления — можно откатиться к любой из них прямо из консоли. Это дает возможность защищать виртуалки даже без дорогих СХД с возможностью репликации томов.
В zVirt и аппаратная, и программная репликация реализованы как полноценные, управляемые инструменты платформы. В итоге решение закрывает обе задачи сразу: оркестрацию репликации на уровне СХД и репликацию ВМ. Это не адаптация примеров из документации и не набор скриптов для каждого внедрения, а готовый продукт с графическим интерфейсом, мониторингом и автоматизацией.
Как определить ваши требования к DR
Любой проект Disaster Recovery начинается с анализа бизнес-воздействия — Business Impact Analysis. Заказчик определяет критичные бизнес-процессы, привязывает к ним конкретные ИТ-системы и формирует требования к их непрерывности. В результате получаем два ключевых параметра, которые определяют архитектуру всего решения:
RTO (Recovery Time Objective) — время, за которое система должна быть восстановлена после аварии. Если для одного сервиса допустим простой в час, а для другого критичны даже 15 минут — это разные уровни защиты и разные инвестиции в инфраструктуру;
RPO (Recovery Point Objective) — максимальный промежуток времени, за который допустимо потерять данные. RPO в ноль означает, что потерять нельзя ни одной транзакции. RPO в 15 минут — можно откатиться на четверть часа назад, потеряв все изменения за это время.
В zVirt параметры RTO и RPO зависят от выбранного метода репликации:
Метод репликации | RTO (время восстановления) | RPO (допустимая потеря данных) | Особенности |
Программная репликация (уровень гипервизора) | От 15 минут | От 15 минут | Не требует дорогих СХД, работает на снапшотах ВМ |
Аппаратная асинхронная репликация (СХД) | От 15 минут | От 5–10 минут | Требует поддержки репликации на уровне СХД |
Аппаратная синхронная репликация (СХД) | От 15 минут | Близко к нулю | Требует быстрых каналов, ограничение по расстоянию |
Метрокластер СХД (Active-Active) | Близко к нулю | Близко к нулю | Требует L2-связности между ЦОДами, ALUA, мультипасинг |
Выбор метода репликации определяется требованиями бизн��са и бюджетом:
Программная репликация универсальна, не требует специализированных СХД, позволяет быстро настроить репликацию ВМ через интерфейс платформы. Но есть ограничения: не высоконагруженные I/O ВМ, минимальный интервал 15 минут, плюс лимиты на количество одновременно реплицируемых ВМ и размер их дисков. Это подходит для большинства корпоративных сервисов, но не для массовой репликации сотен машин.
Программная репликация в zVirt поддерживает до пяти точек восстановления. Хранить несколько копий критично. Одна из точек может оказаться поврежденной или содержать ошибку, которая проявится только после восстановления. Минимальное требование к скорости сетевого канала между площадками — 1 Гбит/с. Реальная нагрузка зависит от объема изменяемых данных и настроенного интервала репликации.
Аппаратная репликация нужна там, где потеря даже минуты данных неприемлема. Синхронная репликация практически исключает потери, но требует дорогих СХД и широких каналов связи. Асинхронная — компромисс между стоимостью и защитой, позволяет гибко настроить интервал в зависимости от возможностей массива и канала. Подробнее — в нашем материале об интеграции с YADRO.
Есть еще метрокластер СХД. Это решение для систем, где недопустимы даже секунды простоя. Две СХД работают как единый Active-Active кластер с синхронизацией в реальном времени. При отказе одной площадки вторая продолжает работу мгновенно, без переключения. RTO и RPO приближаются к нулю. Такая архитектура требовательна: нужна L2-связность между ЦОДами, поддержка ALUA, мультипасинг и близкое расположение площадок (обычно до 100 км). Детали — в нашем посте.
DR — это процесс
Определили требования, выбрали метод репликации, настроили параметры через интерфейс — кажется, что все готово. Но это иллюзия безопасности. DR требует постоянного внимания, как и кибербезопасность. Классический сценарий: потратили месяцы на проектирование и внедрение, а в момент реальной аварии оказывается, что половина ВМ не восстанавливается, документация устарела, а ответственный администратор в отпуске.
Почему так происходит? С технической точки зрения zVirt настраивается один раз «из коробки» через графический интерфейс. Репликация запускается, снапшоты создаются по расписанию, статус отображается в консоли. Но это только инструменты, которые без организационных процессов не особо полезны.
Что нужно делать регулярно, чтобы DR действительно работал
Описывать и поддерживать регламенты. Должно быть четкое описание: кто принимает решение о переключении на резервную площадку, в какой последовательности поднимаются сервисы, кто отвечает за каждый этап, как проверить работоспособность после восстановления. Если регламентов нет, команда при аварии будет действовать хаотично.
Проводить тестирование DR-планов. Минимум раз в полгода проводить учения: имитировать сбои сервисов или ключевого оборудования, запускать восстановление, проверять критичные сервисы. Ролевые сценарии помогают найти слабые места: устаревшую документацию, изменившиеся конфигурации, неверный порядок восстановления.
Актуализировать DR. Инфраструктура постоянно меняется: появляются новые ВМ, обновляются зависимости между сервисами. Если не синхронизировать эти изменения с DR-планом, то в момент аварии критичные сервисы окажутся не защищены или восстановление пойдет в неправильном порядке.
Сделать из технологии работающий процесс — задача инфраструктурной команды. Можно купить самое продвинутое решение на рынке, но если команда ни разу не тренировала восстановление, а регламенты лежат мертвым грузом в Confluence и список защищенных ВМ не обновлялся полгода — в момент ЧС все это просто не сработает, как надо.
Четыре боли российских ИТ-команд, которые мы учли
Процесс важен, но инструмент должен позволять его выстроить. Мы проектировали DR-модуль zVirt на основе реальных болей и сценариев российских заказчиков. Вот четыре самые частые проблемы, с которыми сталкиваются команды при внедрении DR, плюс как их решает zVirt.
Доступ к гостевым системам. Многие отечественные решения по программной репликации требуют установки агента внутри каждой ВМ. В теории нормально, но на деле админ инфраструктуры редко имеет доступ к продуктовым ВМ: везде свои политики, команды и цикл согласования. Хочешь защитить 200 ВМ — готовься договариваться с десятком подразделений, тестировать совместимость под каждую ОС, следить за обновлениями. В zVirt программная репликация работает на уровне гипервизора. Настроил защиту в консоли, и репликация пошла.
Аппаратная репликация с наглядным контролем. Когда репликация настроена через скрипты, СХД реплицирует тома, а виртуализация управляет ВМ. Но между ними нет связи. Чтобы понять, какие виртуалки защищены, администратору приходится логиниться в СХД отдельно, смотреть список реплицируемых томов, вручную сопоставлять их с ВМ в платформе. При аварии на такую археологию нет времени. В zVirt интеграция с хранилищем прямая: консоль показывает, какие ВМ лежат на защищенных томах, статус репликации, последнюю синхронизацию. Все в одном месте, не нужно прыгать между системами и держать соответствие в голове.
Отсутствие времени на переобучение и поддержка отечественных ОС. Критичный момент для российского рынка — официальная поддержка отечественных ОС: Astra Linux, РЕД ОС, Alt Linux и других. У VMware такой поддержки не было. Для многих компаний это не просто преимущество, а обязательное требование регуляторов и внутренних политик импортозамещения. В zVirt эта поддержка встроена. ВМ на российских ОС работают так же стабильно, как и на классических системах. Плюс логика управления DR знакомая. Администраторы, работавшие с vSphere Replication, осваивают модуль за несколько дней, а не месяцев. Модуль DR включен в версию Advanced из коробки, не нужно разбираться с дополнительными лицензиями и докупать отдельные модули.
Именно эти вещи определяют, будет ли DR реально работать, а не останется только красивой схемой на созвоне. Делитесь опытом в комментариях, с какими болями при работе с DR сталкивались вы и как их решали?
P.S. Полноценный DR — это еще одно наше отличие от oVirt. Прошлые материалы на эту тему можно почитать здесь и здесь.
