Disaster Recovery: кому и когда нужно обезопасить инфраструктуру?
Представьте, что строите замок из «Лего». Ищете подходящие детали и размышляете о их расположении. Но вдруг врывается «монстр» в облике питомца, и замок рассыпается на глазах... В бизнесе тоже так бывает: случаются пожары, катаклизмы и падения метеоритов. О том, как снизить финансовые и репутационные риски, рассказываем в тексте.
Какие бывают причины сбоев
Disaster Recovery (DR) нужен для быстрого аварийного восстановления инфраструктуры, данных и работы всех систем в случае критических сбоев.
Причины неполадок бывают разными.
- Рядовые — отключение электричества в районе размещения оборудования, проблемы с сетью.
- Чрезвычайные — любые события, которые могут серьезно навредить IT-инфраструктуре. Среди них — землетрясения, пожары и даже наводнения.
Требования Disaster Recovery
По сути, Disaster Recovery подразумевает резервную площадку для восстановления «клона» или части поврежденной инфраструктуры компании. Чтобы отвечать требованиям Disaster Recovery, площадка должна:
→ быть географически удалена от основной (в таком случае ЧС, произошедшая в первом дата-центре, не затронет второй),
→ иметь хорошую сетевую связность с местом размещения инфраструктуры (чем выше пропускная способность канала, тем быстрее данные будут «добираться» до резервной площадки).
Наиболее оптимальный и распространенный вариант — развернуть Disaster Recovery в облаке. В отличие от DR на физической инфраструктуре облачная реализация проще и гибче в масштабировании. Иногда достаточно нескольких минут, чтобы развернуть резервную площадку.
Еще одно преимущество — модель pay-as-you-go. Это оплата за потребленные ресурсы, которую поддерживают облака. Если компании не нужна активная репликация инфраструктуры 24/7/365, она может экономить на ресурсах.
Аварийное восстановление в облаке можно реализовать на базе VMWare в Selectel.
Всем ли нужен Disaster Recovery?
Спойлер: аварийное восстановление нужно не всем. Оно необходимо компаниям, где репутационные и финансовые потери при простое сервисов недопустимы.
Пример: крупный банк
На основной площадке случилась авария — у клиентов не получается зайти в мобильное приложение и личные кабинеты. Сервис недоступен 30 минут: физлица не могут оплачивать покупки и переводить деньги близким, юрлица — совершать необходимые транзакции. При восстановлении системы оказалось, что данные о переводах за последний час потеряны. Менеджеры хватаются за головы, а клиенты уходят в другой банк.
Пример: служба доставки еды
В районе дата-центра, где расположена инфраструктура сервиса, отключили электричество. Резервного источника электропитания по какой-то причине нет. Пользователи не могут заказать продукты домой. За час, потраченный на восстановление систем, несколько сотен клиентов не смогли выполнить свои заказы. Финансовые убытки оцениваются в несколько сотен тысяч: половина этих клиентов заказали доставку у конкурентов. Добила ситуацию потеря части данных о заказах — несколько десятков людей ждали свою пиццу в течение 4 часов. Еще один денежный транш ушел на сохранение лояльности к компании.
Как подготовиться?
Итак, вы задумались об организации аварийного восстановления. С чего начать?
Определите, какие сервисы нужно «продублировать» в облако. Например, тестовое окружение или внутренние сервисы, некритичные для бизнеса, клонировать не обязательно.
- Выберите провайдера. Отталкивайтесь от того, где расположены дата-центры, на какие ресурсы в облаке можно рассчитывать, какая пропускная способность каналов связи и производительность инфраструктуры. Также можно уточнить, есть ли тестовый период решений, сравнить цены на рынке и выяснить, подписывает ли провайдер SLA — соглашения об уровне предоставления услуг.
- Определитесь с техническим решением. Как правило, провайдер предлагает несколько решений по организации Disaster Recovery. Среди них — варианты с разными показателями по максимальному времени простоя и допустимому объему данных, которые может потерять компания при аварии. Подробней о доступных технических решениях читайте в расширенной версии статьи.
- Сформируйте план аварийного восстановления. В нем должен быть прописан алгоритм действий в случае аварии: кому звонить, кого подключать, как распределить ответственность за восстановление систем. В крупных компаниях регламентируют даже порядок коммуникаций со СМИ, чтобы отработать потенциальные риски.
- Настройте сетевую инфраструктуру, NAT, межсетевые экраны. Инфраструктура — это не только набор серверов. Если вы быстро восстановили сервер базы-данных, но при этом не связали его с веб-сервером, полноценно приложение работать не будет. Настройка сети требует много времени, поэтому откладывать ее на последний момент не стоит. К слову, часто в готовых DR-сервисах настройки есть прямо в интерфейсе.
- Подготовьте техническое решение и DR. Вне зависимости от выбранного решения систему необходимо настроить. Например, если в качестве DR вы выбрали Cloud Director Availability, нужно обеспечить управление инфраструктурой через специальный плагин — vSphere или Cloud Director. Что-то страшное и непонятное? Не переживайте: если вы выбрали правильного провайдера, подробные инструкции по настройке наверняка есть в его базе знаний.
- Протестируйте работоспособность системы. Это ваш шанс найти слабые места в плане DR и узнать точное время восстановления. В Selectel протестировать настроенную систему можно бесплатно.
- Установите периодичность тестирования DR. Рекомендуется повторять предыдущий пункт хотя бы раз в два месяца, чтобы удостовериться в корректности восстановления в облако.
Если хотите углубиться в тему про аварийное восстановление, узнать про технические характеристики и решения для DR — читайте полный гайд на сайте Selectel.
А вам приходилось сталкиваться с аварийным восстановлением на практике? Напишите о своем опыте в комментариях.
Читайте также: