Москва, ул. Пришвина, д.8, корп.2
Отказоустойчивая инфраструктура обычно строится слоями. Резервируют питание и каналы связи, диски и узлы виртуализации, настраивают backup, мониторинг и репликацию. Всё это снижает вероятность простоя, но не отвечает на один вопрос: что произойдёт с сервисом, если недоступной станет вся площадка?
Именно здесь заканчивается резервирование отдельных компонентов и начинается disaster recovery.
Задача DR не в том, чтобы иметь второй комплект серверов «на всякий случай». Задача в том, чтобы критичные сервисы можно было восстановить на другой инфраструктуре за приемлемое время и с допустимой потерей данных.
Для одной системы достаточно резервных копий и подготовленной вычислительной мощности. Для другой нужен постоянно синхронизируемый второй контур. Где-то резерв можно разместить в соседнем дата-центре, где-то требования к рискам заставят вынести его в другой регион.
Поэтому проектирование резервной площадки начинается не с выбора серверов, а с требований к непрерывности сервисов.
Backup и DR: почему одного резервного копирования недостаточно
Backup позволяет вернуть данные к определённой точке во времени. Это защита от удаления, повреждения, ошибок пользователей, ransomware и ряда других сценариев.
Disaster recovery решает другую задачу: восстанавливает работоспособность системы после потери основной инфраструктуры.
Допустим, у компании есть актуальная резервная копия базы. Если недоступен один сервер, её можно восстановить на другой машине. Если недоступен весь ЦОД, кроме самой копии понадобятся вычислительные ресурсы на другой площадке, конфигурация приложений, сетевой контур, доступ к внешним системам и понятный способ переключения нагрузки.
Поэтому наличие backup ещё не означает готовность к DR.
Причём резервная копия остаётся нужна даже при репликации между площадками. Ошибочное удаление данных или логическая ошибка могут быстро попасть и в реплику. Репликация помогает поддерживать актуальное состояние второго контура, backup позволяет вернуться к более ранней корректной версии данных.
Для резервного копирования часто используют классическое правило 3-2-1: иметь три экземпляра данных, хранить их как минимум на двух разных типах носителей, а одну копию держать вне основной площадки. Это не заменяет DR, но хорошо показывает общий принцип: копия не должна зависеть от той же инфраструктуры, которую она страхует.
Сначала сервис, потом инфраструктура
Для DR полезнее инвентаризировать не серверы, а сервисы и их зависимости.
Возьмём условный клиентский портал. За одним адресом могут стоять несколько application-серверов, база данных, файловое или объектное хранилище, балансировщик, внешняя авторизация и интеграции с другими системами. Потеря любого обязательного компонента может сделать портал недоступным, даже если большая часть инфраструктуры успешно запустилась на резервной площадке.
Поэтому для каждого критичного сервиса стоит определить:
- какие компоненты нужны для его запуска;
- какие данные и состояния сервиса нужно сохранять и с какой актуальностью;
- от каких внутренних и внешних систем он зависит;
- какие компоненты можно восстановить позже;
- какие элементы должны быть подготовлены заранее.
Так довольно быстро выясняется, что резервировать инфраструктуру один в один обычно не требуется.
У компании может быть сто виртуальных машин, но только десять из них действительно нужны в первые часы после отказа. Остальные можно поднять позже.
И это уже сильно влияет на стоимость второго контура.
Hot, warm и cold reserve: сколько готовности действительно нужно
Степень готовности резерва обычно описывают как hot, warm или cold, хотя в реальных проектах между этими вариантами много промежуточных состояний.
Hot reserve
Резервная инфраструктура работает постоянно, данные регулярно или непрерывно реплицируются, а механизм переключения заранее подготовлен.
Такой вариант позволяет получить минимальный RTO, но требует постоянно оплачивать ресурсы второго контура и поддерживать его в актуальном состоянии.
Warm reserve
Основные компоненты резервной среды уже существуют, но часть сервисов требуется запустить или донастроить при переключении. Данные синхронизируются заранее или могут быть быстро восстановлены из актуальной копии.
Для многих корпоративных систем это наиболее практичная схема: резерв не простаивает полностью, но и не приходится содержать полноценный active-active контур.
Cold reserve
На второй площадке есть данные, оборудование или возможность быстро выделить ресурсы, но сервисы разворачиваются после возникновения аварийного сценария.
Стоимость такого резерва ниже, зато увеличивается время восстановления и растёт число операций, которые придётся выполнить уже во время инцидента.
Выбор между этими подходами должен следовать из требований к сервису, а не наоборот.
RPO и RTO определяют архитектуру резерва
Здесь появляются две ключевые характеристики.
RPO, Recovery Point Objective, определяет, к какой точке во времени мы должны суметь восстановить данные. По сути это максимально допустимая потеря данных.
Если RPO составляет четыре часа, периодическое резервное копирование может оказаться достаточным. Если допустимы минуты, понадобится более частая или непрерывная репликация.
RTO, Recovery Time Objective, определяет допустимое время восстановления сервиса.
RTO в несколько часов позволяет использовать инфраструктуру, которую нужно дополнительно развернуть и настроить. RTO в несколько минут уже требует заранее подготовленного контура и, как правило, значительно большей автоматизации переключения.
RPO и RTO связаны со стоимостью напрямую. Чем меньше допустимая потеря данных и чем быстрее требуется вернуть сервис в работу, тем больше ресурсов приходится держать готовыми заранее.
Поэтому фраза «нам нужна резервная площадка» сама по себе почти ничего не говорит об архитектуре. Гораздо информативнее звучит: «для этого сервиса RPO 15 минут, RTO один час».
После этого уже можно обсуждать способ репликации, вычислительные ресурсы и схему переключения.
Failover нужно проектировать заранее
Наличие второй площадки ещё не означает, что система сможет на неё переключиться.
DR-план должен описывать хотя бы критическую последовательность: какие компоненты запускаются первыми, где находится актуальная копия данных, когда резервная сторона становится основной и как на неё переводится нагрузка.
Здесь же обычно проявляются зависимости, которые не были заметны при проектировании отдельных серверов. Например, приложение успешно поднялось, но не может обратиться к внешнему API с нового адреса. Или реплика базы актуальна, но часть сервисов всё ещё использует старую точку подключения.
Чем больше ручных действий требуется при failover, тем сложнее гарантировать заявленный RTO. Поэтому для действительно критичных систем автоматизация процедуры восстановления не менее важна, чем наличие резервных мощностей.
При автоматическом переключении появляется ещё один риск, который особенно важен для распределённых систем: split-brain. Если площадки потеряли связь между собой, но обе продолжают работать, каждая сторона может решить, что именно она теперь основная. Для защиты от такого сценария в кластерных решениях используют quorum или witness и механизмы fencing, которые не позволяют двум сторонам одновременно работать с одними и теми же данными как с основными.
Сетевую схему тоже имеет смысл проектировать именно в контексте failover. В зависимости от архитектуры потребуется изменить маршрутизацию, переключить DNS, поднять туннели или перенаправить пользовательский трафик другим способом.
Отдельный «резерв сети» здесь не самоцель. Важно заранее понимать, каким путём пользователи и связанные системы попадут к сервису после переключения.
Второй ЦОД, облако или гибридная схема
Резервный контур необязательно должен повторять тип основной инфраструктуры.
Если основная система работает на физических серверах, резерв может быть виртуальным. Облачную инфраструктуру можно использовать как часть резервного контура или комбинировать её с dedicated-серверами. Возможна и комбинация нескольких подходов.
Второй ЦОД удобен, когда нужна предсказуемая физическая инфраструктура и заранее выделенные мощности. Облако позволяет гибче обращаться с ресурсами, особенно если резерв не должен работать постоянно. Гибридная модель даёт возможность разделить компоненты по требованиям.
Главный критерий здесь тот же: выбранная площадка и ресурсы должны позволять выполнить заданные RPO и RTO.
Насколько далеко разносить площадки
Внутренняя отказоустойчивость ЦОДа и георезервирование решают разные задачи.
Дата-центр может иметь независимые вводы электропитания, ИБП, ДГУ, резервирование охлаждения и несколько операторов связи. Всё это снижает вероятность отказа инфраструктуры площадки. Но если DR-сценарий предполагает потерю площадки целиком, второй контур должен находиться за пределами её общей зоны отказа.
При этом «чем дальше, тем лучше» тоже не универсальное правило.
Расстояние между площадками влияет на latency, а значит, и на возможный режим репликации. Для синхронной репликации требования к задержке обычно достаточно жёсткие и зависят от конкретной СХД, СУБД или платформы виртуализации. Асинхронная репликация позволяет разнести площадки значительно дальше, но тогда появляется ненулевой RPO.
Поэтому два независимых ЦОДа в одном городе могут быть вполне корректным решением для одной системы, а для другой потребуется другой регион.
География здесь определяется не красивой картой с двумя точками, а моделью рисков, возможностями технологии репликации и требованиями приложения.
DR без тестирования существует только на схеме
Самая опасная часть резервного контура часто не оборудование, а предположение, что всё заработает именно так, как задумано.
Во время тестов обнаруживаются несовместимые версии ПО, просроченные сертификаты, недостающие секреты, неактуальные инструкции, забытые зависимости или слишком медленное восстановление большой базы.
Поэтому проверять нужно не только наличие копий или состояние репликации. Нужен тест самого сценария восстановления.
И здесь необязательно сразу начинать с полного переключения production. Проверки можно проводить поэтапно: сначала пройти сценарий с командой в формате tabletop exercise, затем проверить отдельные процедуры восстановления или поднять резервный контур параллельно с основной инфраструктурой. Самый полный вариант, full failover test, предполагает реальное переключение сервисов на резервную площадку и последующий возврат.
Полезный результат такого теста не только «всё поднялось», но и фактическое время восстановления. Иногда именно проверка показывает, что реальный RTO совсем не совпадает с тем, который был записан в документации.
После failover будет failback
Успешное переключение на резервную площадку не завершает сценарий.
Пока сервис работает на резерве, именно там появляются актуальные данные. После восстановления основной площадки состояние двух контуров уже отличается.
Перед возвратом нагрузки потребуется синхронизировать изменения, проверить основную инфраструктуру и только затем выполнить failback.
Если этот процесс заранее не предусмотрен, можно успешно пережить исходный инцидент, а затем получить сложную ручную миграцию обратно.
Поэтому хороший DR-план описывает полный цикл: failover, работа на резервной стороне, восстановление основной площадки, обратная синхронизация и failback.
Как может выглядеть резервный контур на практике
Представим инфраструктуру компании, где основная площадка содержит базу данных, несколько application-серверов, внутренние сервисы и вспомогательные системы.
После классификации выясняется, что в течение первого часа необходимо восстановить только базу и несколько клиентских приложений. Остальные системы допускают простой в несколько часов.
В этом случае на второй площадке нет смысла держать полную копию всего оборудования. Можно заранее выделить ресурсы для критичного контура, настроить передачу данных и подготовить процедуру переключения. Менее важные системы будут восстановлены позже.
Если RTO критичных сервисов небольшой, часть инфраструктуры можно держать постоянно запущенной. При более мягких требованиях достаточно подготовленной среды и актуальных данных.
Такой подход обычно экономичнее полного дубля и при этом лучше соответствует реальным требованиям бизнеса.
С чего начать проектирование
У резервной площадки нет универсальной конфигурации. Поэтому начинать с вопроса «сколько нужно серверов» действительно рано.
Сначала стоит классифицировать сервисы по критичности и определить для них RPO и RTO. Затем описать зависимости и порядок восстановления. После этого становится понятно, какой объём ресурсов нужен на второй площадке, насколько постоянно они должны быть готовы к работе и какой способ передачи данных подходит для выбранной схемы.
И только на этом этапе имеет смысл считать инфраструктуру и стоимость.
Если для резервного контура нужна отдельная площадка, её можно разместить в дата-центре ESTT в Москве. Для этого можно использовать собственное оборудование по модели colocation, арендовать выделенные серверы или виртуальные ресурсы.
Со стороны ESTT мы предоставляем площадку, электропитание, охлаждение, сетевую инфраструктуру и серверные ресурсы. Наши инженеры помогут с размещением и подключением оборудования и подберут физические или виртуальные ресурсы под требования проекта.
Репликацию данных, настройку приложений, автоматизацию failover/failback и тестирование сценария восстановления нужно проектировать отдельно с учётом архитектуры конкретной системы. До начала работ важно определить состав проекта и ответственность каждой стороны.
Если у вас уже определены RPO/RTO и состав критичных систем, пришлите эти требования. Если пока есть только задача обеспечить работу сервисов при недоступности основной площадки, можно начать с описания текущей инфраструктуры.
Рассчитаем ресурсы резервной площадки
Инженеры ESTT помогут подобрать вариант размещения и рассчитать ресурсы резервной площадки в Москве под ваш сценарий восстановления.