DRaaS простыми словами: как работает аварийное восстановление инфраструктуры

DRaaS – это аварийное восстановление как услуга, при котором компания использует заранее подготовленную резервную инфраструктуру и согласованный сценарий восстановления после серьёзного сбоя. Вместо самостоятельного создания второй площадки бизнес может привлечь провайдера и построить решение на базе колокации, облачных ресурсов или их комбинации. Разбираем, как работает DRaaS, чем он отличается от резервного копирования, что означают RTO и RPO и от каких факторов зависит стоимость аварийного восстановления.

Что такое DRaaS

Аварийное восстановление как услуга, или Disaster Recovery as a Service, – это модель, в рамках которой для критических ИТ-систем заранее создают резервную инфраструктуру и определяют порядок восстановления работы в случае серьёзного инцидента. В зависимости от архитектуры это может быть отдельная физическая площадка, ресурсы в публичном или частном облаке, выделенные серверы или комбинация нескольких подходов.

Без DRaaS компании пришлось бы самостоятельно проектировать резервную площадку, обеспечивать её вычислительными ресурсами, storage, сетью и каналами связи, настраивать репликацию, документировать процедуру переключения и поддерживать команду, способную выполнить восстановление во время инцидента. В сервисной модели часть этих задач берёт на себя провайдер в соответствии с выбранной конфигурацией и распределением ответственности.

При этом DRaaS не следует воспринимать как одну стандартную технологию с одинаковыми параметрами у всех провайдеров. Конкретный состав решения, резервные ресурсы, способ репликации, уровень автоматизации, целевые RTO и RPO и ответственность сторон должны определяться технической спецификацией и договором.

Важно и то, что аварийное восстановление не решает автоматически все проблемы с данными. Если некорректные изменения, повреждение базы или результаты атаки попадают в процесс репликации, они могут быть переданы и на резервную сторону. Поэтому disaster recovery не отменяет необходимость независимых резервных копий.

Наряду с DRaaS существует BaaS – резервное копирование как услуга. Названия похожи, но задачи разные: backup прежде всего создаёт точки, из которых можно вернуть данные, тогда как disaster recovery определяет, как восстановить работу критических сервисов после отказа основной среды.

Чем DRaaS отличается от бекапа

Бекап и аварийное восстановление решают связанные, но разные задачи. Резервная копия позволяет восстановить файлы, базу данных, виртуальную машину или другой объект до доступной точки восстановления. Disaster recovery охватывает более широкий сценарий: где будут работать системы после аварии, в каком порядке они запускаются, как восстанавливаются сетевые соединения, доступы и интеграции и как пользователи попадут в резервную среду.

Именно поэтому наличие бекапа ещё не означает готовность к аварии на уровне всей площадки. Если основные серверы или дата-центр недоступны, необходимо иметь ресурсы, на которых можно развернуть копии, обеспечить сеть, адресацию, доступы и зависимости между системами. В DR-сценарии эти вопросы прорабатывают заранее.

Поэтому одно решение не заменяет другое. Бекап нужен для возврата к предыдущему состоянию после случайного удаления, повреждения данных, некорректного изменения или других инцидентов. Подробнее о принципах резервного копирования мы писали в материале «Что такое бекап».

На практике backup и disaster recovery часто используют вместе. Для критических сервисов определяют сценарий аварийного восстановления, а резервные копии создают независимо, чтобы сохранить возможность вернуть данные к предыдущей корректной точке. Для менее критических систем может быть достаточно backup с более длительным допустимым временем восстановления.

RTO и RPO

RTO и RPO – две основные метрики, с помощью которых бизнес формулирует требования к аварийному восстановлению.

RTO, Recovery Time Objective, – максимально приемлемое время, в течение которого система может оставаться недоступной после инцидента. Например, RTO в четыре часа означает, что сценарий восстановления необходимо спроектировать так, чтобы сервис вернулся в определённое рабочее состояние в пределах этого периода.

RPO, Recovery Point Objective, – максимально приемлемый объём потери данных, выраженный через время. RPO в пятнадцать минут означает, что бизнес допускает потерю изменений, появившихся в течение последних пятнадцати минут до инцидента. Можно ли фактически достичь такого показателя, зависит от технологии репликации или резервного копирования и конкретной архитектуры.

Для RTO и RPO нет универсальных правильных значений для интернет-магазина, ERP, корпоративной почты или другой системы. Одна и та же платформа может быть критической для одной компании и второстепенной для другой. Поэтому показатели определяют через бизнес-влияние простоя и потери данных.

Чтобы не применять одинаковые требования ко всей инфраструктуре, системы целесообразно предварительно разделить по критичности:

• Критические – их недоступность сразу влияет на основные операции, доход, платежи или обслуживание клиентов.
• Важные – их простой в течение определённого времени допустим, но впоследствии существенно влияет на работу подразделений или бизнес-процессов.
• Второстепенные – могут оставаться недоступными дольше без критических последствий для основной деятельности.

Для каждой группы и, при необходимости, каждого workload задают отдельные RTO и RPO. При этом необходимо учитывать зависимости между системами. Если приложение, база данных и интегрированный с ними сервис восстановятся до несовместимых моментов времени, технически запущенные компоненты могут не образовать работоспособную систему.

Поэтому определять RTO и RPO только силами ИТ-отдела недостаточно. Бизнес-подразделения оценивают допустимые последствия простоя и потери данных, а техническая команда определяет архитектуру, способную обеспечить эти требования в рамках приемлемого бюджета.

Сколько стоит простой

Без оценки последствий простоя сложно обоснованно определить RTO. Формулировка «нужно восстановиться как можно быстрее» не даёт технической команде границы, ради которой целесообразно увеличивать резервные ресурсы, пропускную способность каналов или уровень автоматизации.

Начать можно с прямых финансовых последствий: потерянных продаж или операций, простоя сотрудников, расходов на внеплановое восстановление, работу инженеров и внешних подрядчиков. Для компаний с договорными обязательствами необходимо также учитывать возможные штрафы, компенсации и нарушение собственных SLA перед клиентами.

Не все часы простоя имеют одинаковую цену. Для e-commerce сбой во время пиковой нагрузки может иметь значительно большее влияние, чем в период минимальной активности. В производстве или B2B-сервисах последствия могут накапливаться постепенно и проявиться уже после восстановления системы.

Оценка стоимости простоя помогает сравнивать разные уровни защиты. Однако простого сопоставления стоимости одного часа недоступности с месячной ценой DRaaS недостаточно. Необходимо учитывать потенциальную продолжительность инцидента, его вероятность, масштаб бизнес-последствий, полную стоимость резервной архитектуры и то, какие риски она действительно покрывает.

Чужая статистика о «средней стоимости часа простоя» также не заменяет собственного расчёта. Влияние отказа зависит от бизнес-модели, сезона, зависимости операций от конкретной системы и договорных обязательств компании.

Как работает DRaaS

Конкретная механика DRaaS зависит от выбранной архитектуры. Для виртуализированных и облачных сценариев типичный процесс может включать передачу изменений на резервную площадку, контроль состояния репликации, объявление аварии, failover на резервные ресурсы и последующий failback после восстановления основной среды. В варианте с колокацией часть компонентов и порядок действий могут отличаться.

Резервная среда может строиться на публичном или частном облаке, выделенных серверах, колокации или комбинации нескольких подходов. Необходимый объём ресурсов определяется проектом: резервная площадка может повторять основную инфраструктуру или содержать только те мощности, которые нужны для поддержки приоритетных бизнес-функций во время аварии.

Репликация данных

Репликация – это передача данных или изменений между основной и резервной средами. В зависимости от платформы она может работать на уровне storage, виртуальных машин, баз данных или приложений, а также использовать синхронный или асинхронный механизм.

Способ репликации непосредственно влияет на потенциальный RPO, но сам факт «непрерывной репликации» не является гарантией конкретного количества минут потери данных. Важны технологические ограничения платформы, скорость изменения данных, производительность storage, задержка и пропускная способность канала, а также требования к application consistency.

Отдельно контролируют lag – отставание резервной копии или реплики от основной среды. Если система генерирует изменения быстрее, чем они могут быть переданы и применены на резервной стороне, фактическая точка восстановления отдаляется от целевого RPO.

Репликацию также не следует отождествлять с backup. Если удаление, повреждение или шифрование данных реплицируется на резервную сторону, для возврата к корректному состоянию может потребоваться независимая резервная копия или другая доступная точка восстановления.

Failover и failback

Failover – это перевод работы на резервную среду. Он может запускаться вручную после решения ответственных лиц или автоматически по заранее определённым критериям. Уровень автоматизации необходимо согласовывать для конкретной системы, поскольку ошибочное переключение также может создать сбой.

Failover часто включает больше, чем запуск резервных серверов. В зависимости от архитектуры необходимо обеспечить маршрутизацию трафика, балансировку, DNS, VPN, firewall, доступ пользователей, внешние интеграции и правильный порядок запуска зависимых сервисов. Именно эти компоненты необходимо включать в recovery plan и тестирование.

Failback – возврат работы на основную среду после устранения причины аварии. После failover новые данные уже могут создаваться на резервной стороне, поэтому перед возвратом необходимо определить способ их синхронизации, последовательность переключения и проверку целостности.

Failback не стоит автоматически считать более простым, чем failover. Для сложных систем это отдельный этап плана аварийного восстановления, который также необходимо документировать и тестировать.

Варианты реализации DRaaS

На актуальной коммерческой странице Hostpark для DRaaS описано несколько подходов к построению резервной среды. Выбор зависит от типа существующей инфраструктуры, требований к ресурсам, сети, совместимости и бюджету.

Колокация

Колокация может использоваться как основа резервной площадки для компаний, которые хотят размещать собственное физическое оборудование в дата-центре. Для DR-сценария такая конфигурация может дополнительно предусматривать каналы связи между основной и резервной инфраструктурой.

Этот подход особенно актуален для систем, которые сложно или нецелесообразно переносить в стандартную облачную среду. При проектировании необходимо отдельно определить оборудование, каналы передачи данных, способ репликации, сетевую архитектуру и процедуру переключения.

Облачное решение

Для аварийного восстановления могут использоваться ресурсы публичного или частного облака. Такой подход позволяет подготовить резервные вычислительные и дисковые ресурсы без создания собственной второй физической площадки.

Однако возможность переноса систем в облако необходимо проверять отдельно. Устаревшие платформы, специфическое оборудование, особые сетевые зависимости или лицензионные ограничения могут потребовать адаптации архитектуры или другого варианта резервирования.

Гибридное решение

Гибридный сценарий сочетает разные инфраструктурные компоненты. Например, часть систем может работать на физическом оборудовании, а резервные ресурсы для других workload – в облаке. Такой подход позволяет подобрать разный уровень защиты для систем с разными техническими и бизнес-требованиями.

Конкретная реализация DRaaS в любом из этих вариантов должна определяться техническим проектом. Название услуги само по себе не устанавливает RTO, RPO, объём резервных ресурсов или уровень автоматизации.

Что проверить у провайдера

Предложения DRaaS необходимо сравнивать не только по названию сервиса или стоимости. Основные параметры должны быть описаны в технической спецификации, SLA или других договорных документах.

1. RTO и RPO. Являются ли они целевыми или гарантированными, для каких именно систем действуют, как измеряются и какие события исключены из расчёта.
2. Архитектура резервной среды. Где физически или логически находятся резервные ресурсы, какой уровень изоляции используется и какая юрисдикция применяется к данным.
3. Репликация. Какая технология используется, как контролируется её состояние и что происходит при превышении допустимого lag.
4. Failover. Кто объявляет аварию, кто запускает переключение, какие компоненты процесса автоматизированы и какие действия остаются на стороне клиента.
5. Резервные ресурсы. Соответствует ли их производительность основной среде или во время аварии предусмотрена работа в сокращённой конфигурации.
6. Тестирование. Какой формат проверок предусмотрен, как часто они выполняются, что именно тестируется и включена ли их стоимость в сервис.
7. Failback. Как происходит возврат на основную площадку, как синхронизируются данные и требует ли этот этап отдельных работ или оплаты.
8. Совместимость. Поддерживаются ли текущая платформа виртуализации, операционные системы, сетевые компоненты, приложения и лицензионная модель клиента.
9. Распределение ответственности. За какие компоненты отвечает провайдер, а какие остаются на стороне внутренней ИТ-команды.

Важно также оценивать инфраструктуру дата-центра, в котором будут размещаться резервные ресурсы: схему электропитания, охлаждение, физическую безопасность, подключения операторов и резервирование каналов. Общие принципы такой инфраструктуры подробнее разобраны в материале о работе дата-центра.

У Hostpark есть отдельная услуга DRaaS, для которой могут использоваться колокация, облачные или гибридные решения. Конкретную архитектуру, резервные ресурсы, целевые показатели восстановления и распределение ответственности необходимо согласовывать под инфраструктуру конкретного клиента.

Тестирование плана восстановления

DR-план нельзя считать проверенным только потому, что репликация работает без ошибок. Во время реального переключения могут проявиться проблемы с доступами, лицензиями, DNS, маршрутизацией, firewall, внешними интеграциями, порядком запуска систем или зависимостями между ними.

Проверка может иметь разную глубину. На базовом уровне команда проходит recovery plan и проверяет роли, контакты, критерии объявления аварии и порядок действий. Более глубокий тест может включать запуск копий систем в изолированной среде, проверку приложений и зависимостей. Для критических workload при необходимости проводят контролируемый failover в соответствии с согласованным сценарием.

Универсального правила вроде «тестировать раз в полгода» нет. Периодичность определяется критичностью систем, внутренними политиками, нормативными требованиями, договором и скоростью изменений инфраструктуры. После существенного изменения сети, приложений, storage, платформы виртуализации или зависимостей recovery plan необходимо пересмотреть независимо от календарного графика.

Во время теста важно фиксировать фактическое время выполнения этапов, достигнутый RTO, доступную точку восстановления, проблемные зависимости и ручные операции. Это позволяет сравнивать реальный сценарий с запланированными показателями и корректировать архитектуру до того, как произойдёт авария.

Тестирование охватывает и организационную часть. В плане должны быть актуальные ответственные лица, резервные контакты и понятная процедура эскалации. Формат проверки необходимо организовать так, чтобы риск для production-среды был контролируемым и соответствовал согласованному плану работ.

Ограничения DRaaS

DRaaS значительно расширяет возможности восстановления после серьёзных инцидентов, но не является универсальной защитой от любого отказа или потери данных.

• Ошибки могут реплицироваться. Некорректные изменения, повреждения или последствия шифрования могут попасть на резервную сторону, если архитектура не предусматривает отдельных точек восстановления.
• RPO зависит от технологии и сети. Пропускная способность, latency, change rate и возможности платформы влияют на фактическое отставание резервной среды.
• Малый RTO требует соответствующей архитектуры. Чем быстрее система должна вернуться к работе, тем выше могут быть требования к резервным ресурсам, автоматизации и сети.
• Резервная конфигурация может отличаться от основной. Если для DR предусмотрено меньше ресурсов, после переключения необходимо заранее понимать допустимый уровень производительности.
• Recovery plan устаревает. Новые сервисы, интеграции, IP-адреса, правила доступа и изменения архитектуры необходимо своевременно добавлять в сценарий.
• Организационные процедуры остаются важными. Даже технически готовая резервная среда требует понятных критериев объявления аварии, ответственных лиц и процедуры эскалации.

Именно поэтому DRaaS целесообразно использовать вместе с независимым резервным копированием. Для бизнеса также доступен отдельный сервис BaaS, предназначенный именно для организации резервных копий. Backup и disaster recovery выполняют разные функции и дополняют друг друга.

Вывод

DRaaS – это не разновидность бекапа, а способ заранее подготовить инфраструктуру и процедуры для восстановления критических систем после серьёзной аварии. Конкретное решение может использовать колокацию, публичное или частное облако, выделенные ресурсы или гибридную архитектуру.

Планирование начинается с бизнес-требований: необходимо определить, сколько времени каждая система может оставаться недоступной и какой объём потери последних данных является приемлемым. Эти требования формализуются через RTO и RPO, после чего под них подбирают технологию репликации, резервные ресурсы, сеть и порядок failover и failback.

Защищать всю инфраструктуру одинаково не всегда экономически оправданно. Критические системы могут получить более короткий RTO и меньший RPO, тогда как для второстепенных workload может быть достаточно резервного копирования и более длительного времени восстановления.

Готовность к аварии подтверждает не само наличие DRaaS в договоре, а регулярно проверяемый recovery plan, в котором понятны зависимости систем, роли сторон, процедура переключения и фактические результаты тестов.