Disaster Recovery: как выбрать подход к построению и тестированию
Даже современные дата-центры все еще остаются уязвимыми к отказам систем электропитания, обрывам магистральных каналов связи, авариям инженерного оборудования и другим рискам, количество которых продолжает расти. Поэтому внедрение продуманных средств аварийного восстановления — Disaster Recovery (DR) — становится все более востребованным среди компаний разного уровня.
Александр Гавриленко, руководитель направления технологических партнерств и проектов по интеграции платформы виртуализации zVirt в инфраструктурах заказчиков Orion soft, подтверждает: количество задач по построению устойчивой виртуальной инфраструктуры на два и более территориально распределенных ЦОДа выросло вдвое за последние два года. В колонке эксперт разбирает существующие подходы к построению DR, принципы выбора оптимального решения для разных типов инфраструктуры и основные ошибки в тестировании систем аварийного восстановления.
Почему «встает» инфраструктура
Инциденты с ИТ-инфраструктурой случаются даже в самых защищенных дата-центрах. Какими бы надежными ни были современные ЦОДы, они остаются уязвимыми к самым разным проблемам: от сбоев в электропитании до неожиданных аварий инженерных систем и кибератак.
Например, в опыте работы команды Orion soft был кейс, когда целый этаж дата-центра одного из заказчиков остался без электричества, что привело к отключению критически важных сервисов. В другом кейсе во время ремонта дороги экскаватор повредил магистральный кабель, и связь с дата-центром была потеряна. Были случаи и серьезных пожаров: в одном из крупных ЦОДов возгорание произошло на крыше здания.
Еще один случай из практики: в одном из ведущих дата-центров взорвался баллон системы пожаротушения. Взрыв разрушил стену, которая превратилась в мелкодисперсную пыль. Она вывела из строя серверное оборудование, и вся инфраструктура остановилась.
Отдельного внимания заслуживает вопрос кибербезопасности. При проектировании DR важно понимать: если речь идет о шифровальщиках, они с равной вероятностью могут поразить как основную, так и резервную площадку. В таких ситуациях критически важно иметь правильно организованную систему резервного копирования с хранением бэкапов на изолированной площадке и четким планом восстановления данных.
Некоторые типы кибератак способны привести к полной остановке площадки — например, при целенаправленном выведении из строя оборудования. Поэтому план DR должен учитывать все виды угроз: от физических отказов до программных сбоев и проблем с безопасностью.
Варианты построения DR
DR всегда подразумевает работу с двумя и более площадками — в рамках одной от всех рисков не защититься. Сегодня на рынке есть два основных подхода к организации DR: DR как сервис или самостоятельное построение.
DR как сервис (DRaaS)
Это сервис непрерывной репликации данных и приложений на площадку провайдера с возможностью быстрого переключения в случае сбоя. Заказчику не нужно строить собственную резервную площадку или закупать дорогостоящее оборудование.
Самостоятельное построение DR
Для компаний, которые хотят полностью контролировать процесс, существует вариант самостоятельного построения DR с использованием своих площадок. Здесь можно комбинировать различные технологии.
-
Резервное копирование. При этом подходе создаются регулярные резервные копии данных. Главные минусы — при восстановлении можно потерять данные за период между последним бэкапом и сбоем, а сам процесс восстановления требует длительного времени.
-
Метрокластер. Отказоустойчивое решение, которое синхронно реплицирует данные между площадками и автоматически переключает нагрузку при сбое. Технология используется для критически важных систем, где даже минутный простой недопустим. Метрокластер гарантирует нулевую потерю данных и практически мгновенное восстановление. Таким образом, виртуальные машины с данными критичных приложений имеют возможность практически бесшовно «переезжать» между территориально распределенными серверами. Однако такое решение требует вложений в системы хранения данных и высокоскоростные каналы связи между площадками.
-
Репликация данных на разных уровнях. Есть несколько вариантов передачи данных с основной площадки на резервную. Можно организовать ее на уровне системы хранения данных с автоматизацией их восстановления в резервном ЦОДе. Можно передавать данные на уровне приложений: часто они имеют встроенные средства организации DR. Наконец, по опыту Orion soft, частый запрос бизнеса — инструменты для организации Disaster Recovery на уровне платформы виртуализации. Они позволяют автоматизированно проводить репликацию виртуальных машин между площадками и контролировать процесс восстановления.
Такие инструменты могут быть разработаны вендором самостоятельно и заранее встроены в платформу виртуализации, как, например, VMware SRM или его отечественный аналог — модуль репликации и DR zVirt. Модули для организации DR могут также разрабатываться внешним производителем и устанавливаться поверх платформы виртуализации. Пример — ранее популярный иностранный Veeam Backup and Replication или российский MIND Guard, который некоторые отечественные вендоры включают в состав своих решений.
Чаще всего используется дифференцированный подход к построению DR — комбинирование перечисленных технологий в зависимости от критичности систем и доступного бюджета.
Как выбрать вариант построения DR для конкретного бизнеса
Выбор подхода к DR зависит в первую очередь от того, к какому уровню критичности относится бизнес-система:
- Mission critical — системы, критичные для выполнения основной деятельности. Например, процессинг банковских карт, система управления производственной линией, биржевые торги.
- Business critical — важные системы, где небольшой простой допустим. Например, CRM в кол-центре, система управления складом.
- Business operation — системы, поддерживающие бизнес-процессы. Например, корпоративная почта, система документооборота.
- Office productivity — вспомогательные системы. Например, учет командировок, заказ канцтоваров.
Для каждого уровня определяют два ключевых параметра:
- RTO (Recovery Time Objective — целевое время восстановления) — определяет, сколько времени можно восстанавливать систему после сбоя.
- RPO (Recovery Point Objective — целевая точка восстановления) — определяет, какой объем данных можно потерять при сбое.
Первым шагом в построении DR становится именно классификация систем по уровням критичности. Это позволяет точно определить требования к решению и оптимально распределить бюджет: не все системы требуют мгновенного восстановления с нулевой потерей данных.
Разберем, какие подходы к DR оптимальны для каждого уровня критичности.
Системы уровня mission critical. В них простои недопустимы, поэтому для таких систем чаще всего используют встроенные средства обеспечения отказоустойчивости — выстраивают кластеры баз данных и серверов приложений. В особых случаях применяют метрокластеры, обеспечивающие практически мгновенное переключение между площадками с нулевым уровнем потери данных, при условии их близкого расположения друг к другу.
Он расскажет, почему огульное импортозамещение не является лучшей стратегией, как защитить существующие ERP-, PLM- и MES-системы, а также почему российские интеграторы должны переосмыслить свой подход к внедрению цифровых решений.
Системы уровня business critical. Чаще всего их защищают с помощью репликации на уровне систем хранения данных (СХД). Этот подход эффективен для крупной инфраструктуры с сотнями виртуальных машин. При использовании синхронной репликации RPO будет стремиться к нулю, при использовании асинхронной репликации составит десятки минут.
Приемлемого значения RTO при этом подходе помогают достичь автоматизированные средства восстановления данных на резервной площадке, например, средства управления репликацией на уровне платформы виртуализации.
Системы уровня business operation. Для них подходит программная репликация на уровне платформы виртуализации. Это гибкое и экономичное решение, не требующее привязки к конкретному производителю СХД, но со своими ограничениями по количеству одновременно реплицируемых виртуальных машин и их размеру. RTO и RPO в данном случае достигает десятков минут.
Системы уровня office productivity. На этом уровне часто достаточно правильно организованного резервного копирования без использования репликации. Такой подход оптимален для некритичных офисных систем и одновременно обеспечивает защиту от специфических угроз вроде вирусов-шифровальщиков. Для комплексной защиты каждый из описанных подходов почти всегда дополняют резервным копированием, что позволяет восстанавливать инфраструктуру после логических ошибок или вмешательства вредоносного ПО. Выбор конкретного набора технологий зависит также от требований к непрерывности работы каждой системы.
Как часто тестировать «план спасения» и чего избегать
Мы рекомендуем тестировать план DR как минимум раз в год, оптимально — каждые полгода. Особенно это важно для компаний с динамично меняющейся инфраструктурой. Частота проверок должна соответствовать темпу изменений в системах: чем активнее меняется конфигурация, добавляются новые системы, дополнительные зависимости, тем чаще нужно проводить тестирование.
В Enterprise-компаниях управлением DR часто занимается выделенный сотрудник или целый отдел. Менеджер обеспечения непрерывности бизнеса отвечает за планирование восстановления, проведение тестов и выделение необходимых ресурсов. Но даже при таком подходе часто возникают проблемы из-за человеческого фактора: IP-адреса, зарезервированные для резервной площадки, могут оказаться занятыми, нужная файловая система может использоваться для других целей.
Такие «мелочи» способны полностью нарушить процесс восстановления в реальной ситуации. Поэтому современные системы виртуализации предоставляют возможность тестирования в изолированной среде-«песочнице». В ней можно безопасно проверить доступность всех сервисов, не затрагивая производственную среду.
При тестировании DR важно соблюдать баланс между тщательностью проверки и безопасностью систем. Например, не стоит подвергать дорогостоящее оборудование экстремальным перегрузкам — серверы требуют штатного отключения, а не простого обесточивания. В Orion soft нам известны случаи, когда при тестировании DR заказчики достаточно агрессивно имитировали отказы — в результате выходили из строя блоки питания и сетевые карты, а возврат к нормальной работе превращался в отдельную задачу. В другом кейсе при тестировании на бирже приложение запустили одновременно на двух площадках с общим хранилищем. Результат — поврежденные базы данных и дополнительные проблемы с восстановлением.
Поэтому к выполнению DR-планов нужно подходить аккуратно, исключая риск повреждения рабочих систем и данных.
DR сегодня — это не просто галочка в документации. Согласно внутренним подсчетам Orion soft, 100% заказчиков ПО для виртуализации пользуются средствами резервного копирования виртуальных машин, а 35% используют те или иные механизмы репликации данных виртуальных машин, и эта доля растет — что подтверждает значимость подобных технологий для бизнеса.
Опубликовано 04.03.2025
