Часто бывает так: команда держит бэкапы (резервные копии данных) и закрывает на этом для себя вопрос защиты от сбоев и потери основной площадки. Случается сбой: копии данных целы, но сервис не работает, а поднять инфраструктуру с нуля занимает время, которое часто сильно больше, чем нужно бизнесу.

Бэкап данных – это не восстановление

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

Разберём механику. Бэкап сохраняет копии файлов и баз. Чтобы вернуть сервис в строй, эти копии нужно найти, развернуть, запустить операционные системы и приложения и заново связать их между собой. Пока идёт развёртывание, сервис остаётся недоступным. Данные при этом не теряются, но и работу не выполняют.

DRaaS (Disaster Recovery as a Service) строит процесс по-другому. Сервис заранее реплицирует данные в виртуальные машины на резервной площадке, и при отказе основного контура переносит на неё нагрузку в полуавтоматическом режиме.

Поэтому DRaaS закрывает три задачи, которые один бэкап не покрывает:

• восстанавливает работу сервисов после сбоя на основной площадке;
• возвращает приложения в работу с заранее заданным временем простоя;
• переключает нагрузку на резервную площадку, когда основной контур отказывает или когда надо провести учения.

На этапе планирования и при тестировании команда отвечает на вопрос: за какое время сервис снова заработает после сбоя. Этот срок задают заранее, двумя параметрами: RTO и RPO. К ним и переходим.

RTO и RPO – две метрики, от которых всё зависит

Восстановление настраивают вокруг двух параметров, которые важно согласовать с бизнесом, а лучше от него и получить: RPO и RTO.

RTO (Recovery Time Objective) отвечает на вопрос «за какое время сервис должен быть поднят». Это срок, за который системы должны вернуться в работу после отказа. RTO в один час и RTO в одни сутки задают разный сценарий восстановления и разную стоимость.

RPO (Recovery Point Objective) отвечает на вопрос «сколько данных допустимо потерять». Это объём изменений между последней синхронизацией и моментом сбоя. RPO в пять минут означает, что при аварии теряются данные за последние пять минут работы. RPO в сутки означает потерю данных за последние сутки.

RTO определяет простой системы, RPO определяет потерю данных. Команда выбирает значения под конкретный сервис: платёжный шлюз и внутренний справочник переживают простой по-разному, поэтому и параметры у них разные.

RTO и RPO зависят не только от провайдера сервиса Аварийного восстановления. На них влияют обе стороны:

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

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

Как это работает организационно-технически

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

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

Шаг 1. Настройка сетей. Для того, чтобы сервисы при запуске требовали минимальной донастройки, важно чтобы они запускались в сети максимально похожей на продуктивную. Поэтому в идеале на резервной площадке сделать серые сети с такой же адресацией, а также повторить правила FireWall и NAT.

Шаг 2. Репликация. Виртуальные машины основной площадки реплицируются на площадку Linx через VMware Cloud Director Availability. Инструмент делает копию виртуальных машин и поддерживает их в актуальном состоянии.

При этом можно настроить множество параметров, главные из которых:

• На каких типах дисков будут хранится данные. Чем более быстрые, тем дороже хранение.
• В каких сетях (из шага 1) и с какой адресацией будет запускаться сервер.

• Target RPO: чем чаще идёт синхронизация, тем меньше данных теряется при аварии. RPO задают индивидуально под каждую систему. Чем меньше, тем лучше, но можно уткнуться в ограничение канала связи или в рост нагрузки на СХД, поэтому нужен баланс.
• Retention policy: позволяет задать количество возможных точек восстановления и глубину их хранения. Чем больше больше таких точек, тем больше шанса, восстановить не повреждённые/не зашифрованные данные, но это увеличивает занимаемое на хранилище место. Поэтому тоже нужен баланс.

Шаг 3. Тестовое восстановление каждой ВМ.

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

Шаг 4. Настройка очерёдности восстановления.

Инфраструктура обычно состоит из большого количества ВМ. Часто их надо запускать в определённом порядке, да ещё и иметь возможность делать промежуточные ручные проверки. Эту очерёдность можно заранее записать в специальный скрипт, называемый Recovery Plan. Это позволит ускорить процесс восстановления, а также минимизировать ошибки при ручном запуске.

Шаг 5. Переключение (failover и failback). При аварии на основной площадке, представитель Клиента ответственный за запуск плана восстановления заходит на консоль управления Cloud Director Availability и инициирует преднастроенный Recovery Plan (делает failover). ВМ восстанавливаются, инженеры проверяют работоспособность ИТ сервисов, а бизнес пользователи проверяют и подтверждают восстановление Информационных систем.

Если авария на основной площадке устранена, можно запустить reverse replication, чтобы новые данные начали реплицировать с резервной площадки обратно. А потом в спокойном режиме (например в час наименьшей нагрузки) провести failback и переключить нагрузку обратно на основную площадку.

План аварийного восстановления, который реально сработает

План аварийного восстановления (DRP) задаёт последовательность действий при сбое: какие системы поднимать, в каком порядке и с какими параметрами. План фиксирует логику переключения заранее, чтобы в момент аварии команда выполняла настроенный сценарий, а не собирала его на ходу.

Сам по себе план ничего не гарантирует. Гарантию даёт тест. Команда проверяет, что системы стартуют на резервной площадке и поднимаются в нужном порядке, и только после этого считает план рабочим.

Тестирование строят в несколько этапов:

1. Тестовый запуск. Команда проверяет, что системы стартуют на резервной площадке сразу после репликации и настройки плана. VMware Cloud Director Availability запускает реплику в тестовом режиме, поэтому проверка идёт без влияния на основную площадку.
2. Первое реальное переключение. После теста команда планирует реальный переезд на резервную площадку. Его проводят в нерабочий день или в час наименьшей нагрузки и подключают к проверке как можно больше ролей в компании.
3. Регулярные прогоны. Тестовое переключение проводят раз в месяц, реальное – раз в полгода-год. Регулярность подтверждает, что план продолжает отрабатывать по мере изменений в инфраструктуре.

План устаревает вместе с инфраструктурой. Любое изменение в критичных системах либо не затрагивает план, либо требует обновить его сразу. Чтобы шаг не терялся, пункт про обновление DRP добавляют в стандартный шаблон Change request. Тогда план обновляется в момент изменения, а не задним числом после сбоя.

Где всё это разворачивать

Резервная площадка требует мощностей. Команда либо держит второй ЦОД с собственным оборудованием, либо арендует готовую площадку и репликацию как услугу. Первый вариант закрывает задачу своими силами, но требует железа, каналов и людей, которые поддерживают всё это в актуальном состоянии. Второй вариант снимает часть этой нагрузки с команды.

В случае с услугой Аварийное восстановление (DRaaS) от Linx Cloud Клиент получает резервную площадку в облаке, а также получает инструмент для репликации и восстановления VMware Cloud Director Availability. RPO задаётся под каждую систему, переключение запускается с веб-портала. Подключение идёт по анкете: команда указывает количество виртуальных машин, объём данных и ресурсы (CPU, RAM), получает доступ к порталу и инструкции. Сервис работает в двух сценариях:

• Стандартный – репликация и запуск виртуальных машин по заранее настроенному плану на резервной площадке;
• Расширенный – аудит инфраструктуры, подготовка плана восстановления, настройка сетей и круглосуточная поддержка.

Проверить схему можно до оплаты: Linx даёт бесплатный тест-драйв на 14 дней, чтобы прогнать тестовое переключение и сверить результат с целевыми параметрами. Условия и подключение на странице DRaaS Linx Cloud.

Итого

Аварийное восстановление настраивают до сбоя, а не во время него. Бэкап сохраняет данные, но не возвращает сервис в работу. Для этого нужна реплика на резервной площадке и заранее настроенное переключение. Параметры RTO и RPO задают рамку: за какое время поднять сервис и сколько данных допустимо потерять. Репликация держит копию инфраструктуры в актуальном состоянии, план фиксирует порядок подъёма систем, регулярный тест подтверждает, что план срабатывает.

Главный показатель готовности – не наличие плана, а дата его последнего прогона. План, который не проверяли полгода, отстаёт от инфраструктуры и в момент аварии работает не так, как записано. Проверьте, когда вы в последний раз запускали тестовое переключение. Если ответа нет, это и есть первая задача.