Отказоустойчивость IT-инфраструктуры обеспечивается на разных уровнях. На инженерном резервируют электропитание, охлаждение, подключение к нескольким операторам связи. На уровне IT-оборудования резервируют вычислительные ресурсы, хранение и сеть. Эти меры защищают от отказа отдельных компонентов. Однако они не помогут, если из-за крупной аварии недоступной станет вся площадка.
Вместе с ней компания может потерять доступ к виртуальным машинам, базам данных и корпоративным приложениям. Если там же хранятся резервные копии, восстановить сервисы на другой площадке не получится.
Один из вариантов защиты от недоступности основного ЦОД — резервная площадка в другой географической зоне. На нее выносят критичные системы, реплики или копии данных, чтобы один инцидент не затронул сразу основной и резервный контур. Конкретная схема зависит от допустимого времени простоя, объема возможной потери данных и требований к размещению информации и безопасности.
Что такое геораспределенная IT-инфраструктура
Геораспределенная IT-инфраструктура — это архитектура, в которой вычислительные ресурсы, данные или резервные системы размещены на двух и более территориально разнесенных площадках. Однако чтобы схема действительно работала при аварии, нужно заранее решить несколько вопросов:
Почему резервирования внутри одного ЦОД недостаточно
Резервные серверы и сетевые устройства находятся в том же здании и зависят от его инженерных систем. Авария, которая затрагивает площадку целиком, выводит из строя и основное, и резервное оборудование.
Для каждого типа отказов нужны разные механизмы защиты:
| Сценарий | Что защищает |
|---|---|
| Резервирование компонентов | Отказ сервера, диска, сетевого устройства, блока питания |
| Кластер внутри одного ЦОД | Отказ отдельных узлов инфраструктуры |
| Резервная копия | Удаление, повреждение или потеря данных |
| Резервная площадка/DR | Недоступность основного ЦОД и восстановление сервисов на другой площадке |
Что такое Disaster Recovery и чем он отличается от Backup и High Availability
Backup, High Availability и Disaster Recovery решают разные задачи.
RPO и RTO: какие параметры задают для Disaster Recovery
RTO (целевое время восстановления) — сколько времени система может оставаться недоступной. Если RTO интернет-магазина составляет 30 минут, после серьезного инцидента сервис нужно вернуть в работу за полчаса.
RPO (целевая точка восстановления) — максимально допустимая потеря данных, выраженная во времени. RPO 15 минут означает, что после восстановления допустима потеря изменений максимум за последние 15 минут.
Это две независимые метрики.
Можно восстановить приложение за десять минут, но поднять базу из копии суточной давности. RTO будет хорошим, RPO — совершенно неприемлемым.
И наоборот: данные могут реплицироваться почти непрерывно, но запуск всей системы после аварии занимать несколько часов.
RPO и RTO задают отдельно для каждого сервиса с учетом его критичности.
| Система | Что обычно определяет требования |
|---|---|
| Платежи | Потеря транзакций и прямые финансовые последствия |
| Интернет-магазин | Потеря заказов и выручки во время простоя |
| CRM | Остановка продаж и поддержки |
| ERP | Влияние на склад, закупки, производство и финансы |
| Внутренний портал | Возможность временно работать без системы |
| Архив | Допустимое время восстановления |
Задавать минимальные RPO и RTO для каждого внутреннего сервиса экономически нецелесообразно, это делает проект неоправданно дорогим.
Как устроена резервная архитектура между ЦОД
Чем меньше допустимый простой, тем больше ресурсов приходится держать в готовности на резервной площадке.
Active-passive
Основная нагрузка работает в одном ЦОД. На второй площадке находится резервная среда, которая включается или принимает нагрузку после сбоя.
Резервная среда может отличаться по степени готовности: на второй площадке заранее разворачивают минимальный набор ресурсов или почти полный инфраструктурный контур.
Active-passive подходит для систем, которым нужен быстрый запуск после аварии, но нет экономического смысла постоянно держать две полностью загруженные production-площадки.
Например, для ERP задан RTO 4 часа и RPO 15 минут. Это значит, что при сбое система должна быть восстановлена в течение четырех часов, а потеря данных не должна превышать последние 15 минут работы.
Active-active
Обе площадки участвуют в работе одновременно. Запросы распределяются между ними, а данные синхронизируются. Если одна площадка становится недоступной, вторая принимает на себя всю нагрузку. Для этого на каждой площадке должны быть свободные мощности, иначе неизбежна деградация работы сервисов.
Active-active сложнее active-passive: нужно решить вопросы консистентности данных, маршрутизации, балансировки, кворума и защиты от split-brain — ситуации, когда два узла одновременно считают себя основной и продолжают работать независимо друг от друга.
Многие корпоративные приложения не рассчитаны на одновременную работу в двух площадках. Мешают привязка пользовательских сессий, конфликты записи в базу и компоненты, которые должны работать в единственном экземпляре.
Резервная площадка с восстановлением из копий
Самый простой вариант: рабочая инфраструктура находится в одном месте, а резервные копии отправляются в другой ЦОД. При аварии там создается новая инфраструктура и из копий восстанавливаются данные.
Такая схема обходится дешевле горячего резерва, но восстановление занимает больше времени. Для архива это может быть допустимо, а для интернет-магазина с высокой стоимостью простоя такой вариант может не соответствовать требованиям по RTO. Схему резервирования выбирают исходя из целевых RPO и RTO.
Репликация данных между ЦОД
Отдельно от схемы размещения выбирают способ передачи данных между площадками. Для репликации используют синхронный или асинхронный режим.
При синхронной репликации операция считается завершенной после записи данных на обеих сторонах. Так можно сильно сократить возможную потерю данных, но система становится чувствительнее к задержке между площадками. При этом, чем дальше находятся ЦОДы, тем больше времени занимает передача.
При асинхронной репликации основной контур не ждет подтверждения от резервного при фиксации каждой операции. Изменения передаются с некоторым отставанием, поэтому задержка подтверждения записи меньше зависит от расстояния между площадками, чем при синхронной репликации. При аварии с недоступностью основного контура изменения, которые не успели реплицироваться и надежно закрепиться на резерве, могут быть потеряны. Размер этого отставания влияет на фактический RPO, поэтому способ репликации выбирают под приложение. Одной системе допустимо потерять несколько минут данных, другой недопустимо потерять ни одной транзакции.
Нагрузка на канал зависит от скорости изменения данных. Два сервиса объемом по 10 ТБ могут предъявлять к каналу совершенно разные требования: один меняет несколько гигабайт в сутки, другой постоянно пишет большой поток. Пропускную способность между ЦОД считают по динамике данных, размер хранилища для этого расчета не подходит.
Связь между площадками часто называют Data Center Interconnect, или DCI. Для рабочих схем важны не только скорость канала, но и его резервирование, задержка и независимость маршрутов.
Что происходит, когда основной ЦОД становится недоступен
При восстановлении нужно учитывать зависимости сервиса, а не только запуск виртуальных машин.
Допустим, интернет-магазин состоит из фронтенда, бэкенда, базы данных, очереди сообщений, кеша, DNS, платежного шлюза, VPN для администраторов и интеграции со складской системой. Если поднялся фронтенд, а база или DNS остались на основной площадке, бизнес все равно не восстановился.
Поэтому при аварии действуют согласно DR-плану. Сначала оценивают, удастся ли восстановить основную площадку в пределах целевого RTO. Если нет, принимают решение о переключении. Затем проверяют актуальность данных на резерве. После этого в заданной последовательности запускают инфраструктурные сервисы, базы данных и приложения.
Дальше переключают сеть, чтобы пользовательский трафик пошел на новую площадку. Для этого может потребоваться изменить записи DNS, маршруты, балансировку или сетевые политики.
Потом проверяют внешние интеграции и доступ сотрудников. И только после этого сервис считается восстановленным.
Как вернуть нагрузку на основную площадку
Failover (аварийное переключение) переносит нагрузку на резервную площадку. Пока она работает как основная, все новые транзакции и данные записываются на ней. Когда основная площадка восстановлена, данные синхронизируют и проверяют их согласованность. Только после этого сервисы возвращают обратно — этот процесс называется failback. Порядок возврата заранее прописывают в DR-плане, чтобы при переключении не потерять данные и не вызвать новый простой.
Почему второй ЦОД иногда не спасает
Общие точки отказа. Два ЦОД могут использовать один внешний сервис, одну систему аутентификации или единую точку управления. В случае, когда общий компонент становится недоступен, обе площадки теряют доступ к зависимым сервисам.
Сеть не зарезервирована. Резервные серверы работают, но пользователи не могут до них добраться.
DNS не готов к переключению. Виртуальные машины запущены, а клиентский трафик продолжает идти на старые адреса.
Резерву не хватает ресурсов. Пока он стоял в ожидании, все выглядело нормально. После аварии на него переехала production-нагрузка и быстро закончились CPU, RAM или место в хранилище.
Зачем тестировать Disaster Recovery
Тестовое переключение показывает фактические значения RPO и RTO и позволяет проверить, работает ли DR-сценарий в условиях, близких к реальным. Иногда именно во время проверки выясняется, что DNS переключается дольше расчетного, одна из виртуальных машин не реплицируется, приложение жестко привязано к IP основной площадки или команда не знает, кто должен принять решение о failover.
Во время DR-теста проверяют:
Где размещать резервный ЦОД: в том же городе, другом регионе или другой стране
Чем дальше расположена резервная площадка, тем меньше вероятность, что один физический инцидент затронет оба контура. Но одновременно могут расти задержки и сложность синхронизации. Расстояние между площадками выбирают с учетом рисков, задержки сети, требований к репликации и юрисдикции.
Два ЦОДа в одном городе
Такой вариант хорошо защищает от локальной аварии здания или отдельных инженерных систем. Плюс обычно проще организовать каналы с небольшой задержкой. У схемы сохраняются общие географические риски, потому что оба ЦОД остаются в одном регионе.
Разные города
Площадки в данном случае меньше зависят от локальной инфраструктуры друг друга. Такая схема подходит, когда бизнесу нужно снизить зависимость от ресурсов одного города или локального сетевого узла, а требования к задержке позволяют разместить резервную площадку дальше.
Разные страны
Резервная площадка в другой стране снижает зависимость от рисков, которые могут одновременно затронуть инфраструктуру внутри одного региона или страны. Данный сценарий рассматривает бизнес с высокими требованиями к непрерывности критичных сервисов.
При размещение данных за рубежом учитывают требования законодательства, корпоративной безопасности и доступность связи. Для начала определяют какие системы и данные можно размещать в выбранной юрисдикции, а затем проектируют резервный контур.
Как выбрать провайдера для геораспределенной инфраструктуры
При выборе провайдера для геораспределенной инфраструктуры проверьте:
Насколько независимы площадки. У основной и резервной площадок не должно быть общих критичных зависимостей, отказ которых одновременно повлияет на обе.
Как организована связь между ЦОД. Нужны понятные характеристики канала, задержек и резервирования.
Какие варианты репликации доступны. Они должны соответствовать платформе и приложениям компании.
Какие RPO и RTO достижимы. Показатели зависят от объема и скорости изменения данных, способа репликации, пропускной способности каналов и конфигурации резервной площадки.
Как выполняется переключение. Автоматически, вручную или по согласованному сценарию.
Можно ли провести DR-тест. Желательно до реальной аварии, а не после нее.
Как организован failback. Нужно заранее определить порядок синхронизации данных и переключения нагрузки с резервного контура обратно на основной.
Кто отвечает за каждый этап. Граница ответственности клиента и провайдера должна быть понятной до подписания договора.
Как работает поддержка. При аварии особенно важен канал связи с инженерами и порядок эскалации.
И отдельно стоит спросить, закреплены ли параметры услуги в SLA и договоре.
Как построено георезервирование в ITGLOBAL.COM
В ITGLOBAL.COM используются три сценария, которые рассчитаны на разную критичность систем, что позволяет сочетать их в одной инфраструктуре.
1. Резервные копии в удаленном ЦОД
Подходит для систем, которые допустимо восстанавливать в течение нескольких часов. Резервные копии отправляются в другой дата-центр. Для этого можно использовать Veeam Cloud Connect, S3-совместимое хранилище или отдельную удаленную точку хранения.
Главная задача такой схемы — физически отделить копии от рабочей инфраструктуры.
2. Disaster Recovery для VMware
Виртуальные машины реплицируются в облако ITGLOBAL.COM с помощью VMware Cloud Director Availability. Минимальный интервал репликации — от 15 минут.
Запуск систем на резервной площадке — от 30 минут, доступность площадки зафиксирована на уровне 99,95% по SLA. Работу сценария можно проверить заранее: тестовое переключение на резервную площадку проводят в изолированной сети без остановки рабочей инфраструктуры.
3. Дублирующая инфраструктура
Для систем, где репликация виртуальных машин недоступна или требуется другой архитектурный подход, в облаке разворачивается отдельный резервный контур.
Механизм синхронизации и порядок переключения проектируются под приложение, а RPO и RTO определяются в проекте и фиксируются в договоре.
Георезервирование ITGLOBAL.COM доступно в 9 дата-центрах в 7 странах. Среди доступных географий для размещения резервной инфраструктуры есть Москва, Минск, Алматы, Ташкент, Дубай, Шэньчжэнь и Сан-Паулу.
С чего начать проект георезервирования
Сначала определяют четыре параметра:
| Что определить | Вопрос бизнесу |
|---|---|
| Критичность | Что произойдет, если система не работает? |
| RTO | Сколько времени она может быть недоступна? |
| RPO | Сколько последних данных можно потерять? |
| Зависимости | Без каких других систем она не заработает? |
После этого уже имеет смысл считать объем репликации, канал, резервные ресурсы и выбирать площадку.
Частые вопросы
Предыдущая статья
