Disaster Recovery в облако: кому нужно и как его обеспечить

Рассказываем, кому стоит позаботиться об аварийном восстановлении инфраструктуры и какими способами можно реализовать DR.

Что такое Disaster Recovery

Disaster Recovery, или аварийное восстановление, — это комплекс инструментов, обеспечивающих быстрое восстановление инфраструктуры, данных, работы всех систем в случае критических сбоев. 

Причины сбоев могут быть как рядовыми — отключение электричества в районе размещения оборудования и проблемы с сетью, так и чрезвычайными. Например, DR готовит сервис к землетрясениям, пожарам, наводнениям. Любым событиям, которые серьезно навредят дата-центру с инфраструктурой компании, вплоть до полного уничтожения.

По сути, Disaster Recovery подразумевает резервную площадку для восстановления полного «клона» или части инфраструктуры компании. Чтобы отвечать требованиям DR, площадка должна: 

→ быть географически удалена от основной (в таком случае ЧС, произошедшая в первом дата-центре, не затронет второй),

→ иметь хорошую сетевую связность с местом размещения инфраструктуры (чем выше пропускная способность канала, тем быстрее данные будут «добираться» до резервной площадки). 

Способы организации DR

Disaster Recovery — концепция, которую можно реализовать разными способами. 

Сделать самостоятельно на своей инфраструктуре (on-premises)

В таком случае не избежать капитальных затрат (всю инфраструктуру нужно будет умножать на два) и простаивания закупленного оборудования. Также Disaster Recovery собственными силами — это сложный проект, требующий серьезных компетенций сотрудников. Поэтому к CAPEX добавим еще и потребность в высококвалифицированных DevOps-, NetOps-специалистах и архитекторах инфраструктуры. 

Построить Disaster Recovery на арендованных физических серверах

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

Развернуть Disaster Recovery в облако

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

Также очевидным преимуществом является модель оплаты pay-as-you-go — оплата за потребленные ресурсы, которую поддерживают облака. Если компании не нужна активная репликация инфраструктуры 24/7/365, она может экономить на ресурсах.  

Disaster Recovery as a service

В качестве альтернативы самостоятельному созданию резервной площадки в облаке можно рассмотреть готовый сервис по DR. Помимо перехода на OPEX-модель, он облегчит такие задачи, как поиск и — самое главное — настройка инфраструктуры в концепции Disaster Recovery. Также клиент, как правило, получает дополнительные «плюшки» в виде консультации экспертов и SLA. У Selectel в этом списке также защита от DDoS-атак и соответствие 152-ФЗ. 

Аварийное восстановление в облако

Пользуйтесь вычислительными ресурсами в облаке на базе VMware в Selectel в случае аварии на вашей основной площадке.

Характеристики Disaster Recovery

Основные характеристики, своеобразные метрики аварийного восстановления — это RPO (Recovery Point Objective) и RTO (Recovery Time Objective). В зависимости от их значений компания выбирает техническое решение, которое будет в основе Disaster Recovery. 

RTO

Определяет максимальное время простоя, которое может позволить себе бизнес. Чем меньше этот показатель, тем незаметнее для конечного пользователя пройдет переключение на резервную площадку. Допустим, RTO установлен на 15 минут. В таком случае сервис начнет работать в штатном режиме не позже этого времени. В идеале — раньше. 

Чем меньше RTO, тем больше это будет стоить бизнесу. Поскольку в реализации будут использовать более технологичные (и дорогие) решения, а резервную инфраструктуру нужно будет держать в состоянии active-active. 

RPO

Определяет максимальный объем данных, который может позволить себе потерять компания в случае аварии и простоя. Чем меньше устанавливается показатель, тем чаще компания делает резервное копирование. Так, если RPO составляет 1 минуту, значит, резервная копия будет создаваться каждую минуту. 

Все это также влияет на стоимость решения. Поэтому нет «золотых стандартов» RPO и RTO — каждая компания определяет эти показатели индивидуально. Обычно это консенсус между тем, что потеряет компания из-за простоя, и тем, что она потратит на достижение нужных метрик RPO и RTO. 

Есть компании — например, крупные банки, чьи потенциальные репутационные и финансовые издержки в случае даунтайма всегда покроют затраты на организацию Disaster Recovery на высшем уровне. А есть бизнес, которому выгоднее «полежать», чем увеличивать чек за инфраструктуру. 

Определение показателей RTO и RPO – это часть плана аварийного восстановления IT-систем (Disaster Recovery Plan, DRP). В идеале такой план должен быть у любой компании — вне зависимости от масштаба и специфики бизнеса. О нем мы еще напишем подробнее. 

Всем ли нужен Disaster Recovery?

Аварийное восстановление нужно не всем. Оно необходимо компаниям, где репутационные и финансовые потери при простое сервисов недопустимы. Рассмотрим несколько примеров. 

Крупный банк

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

Служба доставки еды

В районе ЦОД, где расположена инфраструктура сервиса, случился шатдаун. Пользователи не могут заказать продукты домой (допустим, сервис неудачно выбрал провайдера без ИБП и ДГУ). За час, ушедший на восстановление систем, несколько сотен клиентов не смогли выполнить свои заказы — финансовые убытки оцениваются в несколько сотен тысяч. Половина этих клиентов заказали доставку у конкурентов. Добила ситуацию потеря части данных о заказах клиентов — несколько десятков людей ждали свою пиццу в течение 4 часов. Еще один денежный транш ушел на сохранение лояльности клиентов. 

В обоих случаях затраты на Disaster Recovery окупятся с лихвой. Компаниям, которым отзываются описанные кейсы, стоит задуматься о DR. В остальных случаях будет достаточно бэкапов. В отличие от аварийного восстановления резервные копии — безусловный мастхэв для компаний любого размера.  

Чем отличаются бэкапы от Disaster Recovery?

В случае бэкапов вы делаете резервную копию данных. Если случается локальная авария, систему можно будет развернуть из бэкапа на новой инфраструктуре. В облаке это можно сделать достаточно быстро, если у вас один-два сервера. Если речь о восстановлении всей инфраструктуры — конфигураций серверов, сетевой обвязки, БД и т.д., восстановление займет непозволительные часы. Резервное копирование данных — обязательная часть Disaster Recovery, но это лишь часть. 

Подробнее о типах и способах бэкапа → 

Гайд по репликации инфраструктуры в облако

Итак, вы задумались об организации аварийного восстановления. С чего начать?  

1. Определите, какие проекты или сервисы нужно «продублировать» в облако. Клонировать инфраструктуру полностью не обязательно. Так, тестовое окружение или внутренние сервисы, некритичные для бизнеса, можно исключить из этого списка. 

2. Выберите провайдера. При выборе отталкивайтесь от того, где расположены дата-центры, на какие ресурсы в облаке вы можете рассчитывать, какая пропускная способность каналов связи и производительность инфраструктуры. Нелишним будет уточнить, есть ли тестовый период решений, сравнить цены на рынке, выяснить, подписывает ли провайдер соглашение об уровне услуг (SLA) с клиентом. 

3. Выберите техническое решение. Как правило, провайдер предлагает несколько решений по организации Disaster Recovery с разными значениями RTO и RPO. Ознакомьтесь со всеми и выберите наиболее подходящее. Если сомневаетесь в выборе, хороший провайдер всегда подскажет решение.

4. Сформируйте план аварийного восстановления (DRP), если у вас его еще нет. Базово в нем должен быть прописан алгоритм действий в случае аварии: кому звонить, кого подключать, как распределяется ответственность за восстановление систем. Главная задача плана — исключить паническое накопление ошибок и неправильных действий в случае ЧС. В крупных компаниях в DRP прописывают даже порядок коммуникации со СМИ, чтобы отработать потенциальные риски.

5. Преднастройте сетевую инфраструктуру, NAT, межсетевые экраны. Инфраструктура — это не только набор серверов. Если вы быстро восстановили сервер БД, но при этом не связали его с веб-сервером, полноценно приложение работать не будет. Настройка сети требует много времени, поэтому откладывает ее на последний момент не стоит. К слову, часто в готовых DR-сервисах это можно настроить в интерфейсе.

6. Настройте техническое решение и DR для сервисов. Вне зависимости от выбранного решения (если это, конечно, не полная настройка DR под ключ) систему придется настраивать. Так, например, если вы выбрали Cloud Director Availability, нужно будет обеспечить управление инфраструктурой через плагин vSphere или Cloud Director. Опасаться этого пункта, впрочем, не нужно: если вы выбрали правильного провайдера, подробные инструкции по настройке вы найдете в его базе знаний. 

7. Протестируйте работоспособность системы. Просто настроить и забыть — не вариант. Настроенный Disaster Recovery нужно протестировать, то есть искусственно устроить отказ инфраструктуры на основной площадке и реализовать тот самый план Б. Это ваш шанс найти слабые места в DRP и засечь время восстановления. Действительно ли оно соответствует желаемым метрикам RPO и RTO? В Selectel протестировать настроенную систему для решения можно бесплатно. 

8. Установите периодичность тестирования DR. Рекомендуется повторять предыдущий пункт гайда хотя бы раз в два месяца, чтобы удостовериться в корректности восстановления в облако.  

Технические решения для DR

Существует несколько технических решений, которые позволяют организовать аварийное восстановление в облако. Наиболее распространенные реализуются через Cloud Director Availability и Veeam Cloud Connect Replication (в связке с Veeam Backup & Replication). Эти решения предлагает и Selectel. 

Cloud Director Availability

Это решение может быть использовано как для безопасной миграции в облако, так и для аварийного восстановления нагрузок между облаками VMware в облаке Selectel или из частного облака клиента.  

Больше про разницу между частным, публичным и гибридным облаками →

Особенности 

• минимальный RPO – 5 минут,
• можно управлять и основной инфраструктурой, и репликациями в единой панели управления Cloud Director,
• при настройке сетей не нужно открывать дополнительные порты (достаточно порта TCP 443),
• есть подробная документация по настройке и видеодемонстрация настройки.

Кому подойдет

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

Veeam Cloud Connect

Этот облачный репозиторий не только позволяет хранить бэкапы в облаке, но и восстанавливать данные в облако в случае критических сбоев. 

Особенности 

• минимальный PRO – 1 минута,
• необходимо иметь Veeam Backup & Replication (бесплатный Community Edition не подойдет, минимум — версия Standard, для сжатия трафика — Enterprise), 
• тестировать настроенную систему придется вручную, автоматическое тестирование не поддерживается.

Кому подойдет

Решение больше подходит компаниям, которые уже использует платное ПО от Veeam в работе.

---

Если у вас остались вопросы по реализации Disaster Recovery для своего бизнеса, пишите на sales@selectel.ru.