Блог компании Orion soft Виртуализация * IT-инфраструктура * Информационная безопасность * Системное администрирование * Обзор Пожар в ЦОДе, авария на подстанции, разорванный во время ремонта кабель между площадками — таких инцидентов за последние годы хватает. Например, в конце этого сентября пожар в государственном дата-центре Южной Кореи парализовал сотни госсервисов и уничтожил свыше 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 зависят от выбранного метода репликации: Метод репликации Source: https://habr.com/ru/companies/orion_soft/articles/968802/