Что такое Disaster Recovery?

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

Даже использование последних технологий и резервирования мощностей в ЦОД не исключает сбои. Они могут быть результатом форс-мажоров, связанными с природными явлениями, например, крупными ураганами и землетрясениями, политическими или экономическими причинами. Те риски, которые не получится предусмотреть, необходимо учитывать при проработке disaster recovery. Что это, как работает система, как найти баланс между объективной необходимостью и расходами — расскажем в статье.

Риск-менеджмент IT проектов должен включать в себя планы по поддержке работоспособности бизнеса даже в условиях форс-мажоров. На прибыль компании влияет каждая минута, поэтому критично важные части системы должны работать без перебоев даже при аварийных ситуациях. Чтобы избежать простоев, потери данных, добиться моментального восстановления инфраструктуры, проводится резервирование ее элементов в облаке или на физическом оборудовании в другом ЦОД.

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

• резервный ЦОД должен располагаться в другой локации, физически удален от основной IT-инфраструктуры;
• для обеспечения высокой скорости нужна сетевая связность с основной площадкой.

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

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

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

Создать систему резервирования и аварийного восстановления можно разными способами. Главное — соблюдать требования автономности, географии и сетевой связанности.

Дублирование физического оборудования (on-premises)

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

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

Аренда физических серверов

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

Резервирование в облаке

Большинство компаний выбирают этот способ для обеспечения катастрофоустойчивости. Причины:

• развернуть резервную инфраструктуру в облаке можно намного быстрее — при использовании инструментов IaC на эту задачу требуется несколько минут, а не месяцев;
• модель оплаты провайдеру pay-as-you-go, в рамках которой стоимость формируется по затраченным ресурсам;
• оптимизация расходов за счет аренды мощностей ЦОД вместо покупки оборудования;
• возможность быстро масштабироваться;
• гибкость — вы можете самостоятельно управлять системой.

DRaaS

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

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

Recovery time objective

Показатель связан с временем простоя, которое требуется на восстановление. Чем ниже показатель, тем быстрее проект начинает работать после сбоя и тем больше бизнес платит за это решение. Метрика отражает максимальное значение, то есть если RTO = 30 минут, инфраструктура этого проекта заработает не позднее, чем через полчаса.

Эта цифра критична для веб-приложений, интернет-магазинов и других компаний, чья прибыль генерируется только во время работы. Задача — не допустить, чтобы пользователи сталкивались со сбоями, потому что это влияет на доверие к бренду, его имидж, клиентский опыт. Для сайтов с небольшими объемами трафика требования ниже.

Recovery point objective

Если время влияет на сервис, то от RPO зависят объемы потерянных данных в аварийных ситуациях. На практике это частота резервного копирования: чем меньше показатель, тем меньше актуальной информации вы потеряете. При работе с сайтом это не так важно, как для SaaS-платформ, в которых постоянно фиксируются действия пользователей, а база обновляется каждые несколько секунд. Метрика также влияет на расходы бизнеса на организацию DR.

Универсального решения по определению уровня RPO и RTO — нет. Чтобы определить его, нужно оценить риски, опираясь на потребности проекта. Помогут следующие вопросы:

• Как часто обновляются данные на сервере?
• Сколько активных пользователей у сайта или приложения?
• Какую сумму в минуту или в час (зависит от продукта) вы теряете при простое?
• Перекрывает ли убытки увеличение расходов на инфраструктуру этого проекта?

При проработке катастрофоустойчивого плана ответы на эти вопросы помогут объективно оценить риски, чтобы найти баланс.

Главный принцип при проработке плана — определение разных типов рисков. Резервный ЦОД нужно выбирать так, чтобы его обеспечение не было связано с основным, чтобы сбой не затрагивал оба дата-центра. Создать катастрофоустойчивый проект можно, только если вы предусмотрели возможности аварий природного характера, электросетей, интернет-каналов. Например, если основная инфраструктура расположена в Москве, а дополнительный ЦОД — в Санкт-Петербурге, то наводнения, ураганы и другие локальные явления не затронут работу.

Алгоритм по защите системы состоит из четырех действий:

1. Оценка рисков и потенциального ущерба.
2. Поиск баланса между расходами на резервные мощности и потребностями компании.
3. Определение уровня RTO и RPO, исходя из специфики бизнеса.
4. Выбор решения DR для восстановления IT-проекта с учетом доступных ресурсов — финансов, экспертизы, кадров и т.д.

От сбоев не застрахован ни один бизнес, работа которого связана с IT. Минимальный набор для защиты данных — настройка резервного копирования. Эта функция нужна всем, даже небольшим сайтам. Если же есть даже небольшая сетевая инфраструктура, бэкапов недостаточно — нужно прорабатывать DR. Чем выше потенциальный ущерб от простоев, тем сильнее потребность в системе для восстановления.

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

Со схожими проблемами сталкиваются и популярные сервисы — например, такси, доставка еды из ресторанов, маркетплейсы. Без параллельного ЦОД или резервов в облаке каждый простой приводит к потерям.

Для восстановления IT-проекта в облако чаще всего используется одно из двух технических решений:

• Veeam Cloud Connect Replication.
• Cloud Director Availability.

Их главное отличие в минимальном RPO — в первом случае потерю данных можно сократить до 1 минуты, а во втором — до 5 минут. Однако второе решение проще в реализации: настройка по инструкции занимает около 15 минут, не нужно открывать дополнительные порты, а для управления создана единая панель. С Veeam работать сложно — тестировать систему нужно будет вручную.

Несмотря на это, облачные услуги не требуют сильной экспертизы — большинство задач выполняют провайдеры.

Вывод

Даже самые продвинутые ЦОД уровня Tier III не могут давать стопроцентные гарантии бизнесу. Риски повреждения оборудования, простоев, серьезных сбоев в таких дата центрах минимальны. Несмотря на это, не все техногенные катастрофы можно предусмотреть. При резервировании форс-мажоры не так страшны, поскольку у вас будет готов план восстановления.

DR — это крайняя мера, которая многим компаниям никогда не пригодится. Однако если критическая аварийная ситуация произойдет, работа не встанет, а восстанавливать инфраструктуру этого проекта будет проще.