Multi-Region Disaster Recovery: архитектура, репликация и тестирование

Почему мультирегиональный DR ломается на репликации

Резервный регион обычно появляется раньше, чем проверяется его работоспособность. Репликация настроена в одну сторону: изменения уходят из основного контура в резервный, а обратный поток никто не поднимает. Пока оба региона живы, схема выглядит надёжной — отставание реплики измеряется секундами, статистика чистая.

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

Вторая причина — общая точка отказа за пределами региона. Хранилище секретов, домен, служба аутентификации, очередь фоновых заданий часто живут в одном месте. Резервный контур поднимается, но взять учётные данные к собственной базе ему негде: они лежат в том самом регионе, который недоступен.

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

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

Что даёт гео-резервирование: эффект в измеримых метриках

Резервирование в одном регионе не спасает от отказа площадки: авария у провайдера связи или ошибка конфигурации, разошедшаяся по всем узлам, останавливает сервис на часы. Гео-резервирование переносит работу во второй регион, но ценность дают не сами копии данных, а то, за какое время и с какой потерей данных мы вернёмся в строй. Поэтому контур проектируем от целевых показателей, а не от «поставим реплику на всякий случай».

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

Убранные классы отказов важнее процентов доступности. Гео-контур закрывает отказ площадки, разрыв канала между регионами и ошибку выпуска, когда откат одного региона не затрагивает второй. Остаются ошибки в данных и логике: репликация разносит их по обоим контурам, поэтому выпуски изолируем и проверяем перед переключением.

Режимы работы мультирегионального DR: холодный, тёплый, активный

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

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

Этапы внедрения: от аудита до учебных переключений

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

1. Аудит инфраструктуры. Инвентаризируем сервисы, базы, очереди, внешние интеграции и связи между ними, присваиваем каждому класс критичности и целевое время восстановления. Результат — карта зависимостей, по которой видно, что нельзя поднимать по отдельности.
2. Схема репликации. Решаем, что переносим синхронно (транзакционные данные), а что асинхронно (логи, кэш, аналитика), и фиксируем допустимую потерю данных для каждого класса. Отдельно проверяем, как ведёт себя отставание реплики под пиковой нагрузкой.
3. Подготовка второго региона. Разворачиваем идентичный контур из описания инфраструктуры: сетевые правила, доступы, секреты, конфигурация сервисов. Регулярная сверка ловит расхождения, которые накапливаются при ручных правках.
4. Переключение трафика. Описываем порядок подъёма сервисов с учётом зависимостей и способ перевода нагрузки через управление доменными записями и балансировщик. Перед приёмом трафика — проверка готовности узлов.
5. Проверка целостности. Сверяем объёмы и контрольные суммы данных, прогоняем критичные сценарии на реплике, фиксируем расхождения и решаем, какие из них допустимы, а какие блокируют переключение.
6. Учебные переключения. Проводим по регламенту, с замером времени от сигнала до приёма нагрузки и обратным возвратом. Каждое учение заканчивается разбором и правками регламента — он живёт, а не лежит в документации.
7. Передача в эксплуатацию. Дежурные инструкции, чек-листы, автоматизация повторяющихся шагов и явные зоны ответственности.

Регламент переключения обновляется после каждого учения — иначе он расходится с реальной инфраструктурой уже через пару изменений.

Комплект документации, схем и регламентов переключения

Аварийное переключение региона — это не про выдержку дежурного, а про документ, по которому он действует. Поэтому схемы и регламенты мы передаём как часть поставки, а не как приложение к ней: инженер, не участвовавший в проектировании, должен по этим материалам перевести нагрузку на резервный контур и заранее понимать, где именно он теряет данные.

• Схемы репликации — направление потоков по каждому хранилищу, режим синхронный или асинхронный, допустимое отставание и точки, где аварийное переключение обрывает ещё не доехавшие данные.
• Карта зависимостей — что завязано на основной контур: очереди, внешние сервисы, записи в системе имён, хранилище секретов, и в каком порядке это поднимается в резервном регионе.
• Регламент переключения — кто принимает решение, по каким критериям запускается процедура, последовательность шагов, контрольные тайм-ауты, точка невозврата и условия возврата обратно.
• Политики доступа — роли на период аварии, порядок выдачи расширенных прав, где лежат ключи и как они работают при недоступном основном контуре.
• Описания конфигураций обоих регионов — инфраструктура как код, чтобы резервный стенд воспроизводился сборкой, а не собирался руками по памяти.
• Чек-листы дежурной смены — что проверить до переключения, во время и после, с отметками и ответственным по каждому пункту.
• Матрица сверки данных — какие расхождения считаются допустимыми после возврата, чем сверяем и как догоняем накопленное отставание.
• Протоколы учений — сценарии, фактические времена переключения и список расхождений, которые по итогам закрыли.

Комплект обновляется вместе с архитектурой: изменение схемы репликации или добавление зависимости без правки карты и регламента считается незавершённой работой. Опишите ваш контур — вернёмся с оценкой и планом.

Кейс: восстановление за минуты вместо часов простоя

Клиент — сервис с круглосуточным трафиком в одном регионе. Восстановление держалось на ручном сценарии: инженер поднимал узлы из ночных резервных копий, разворачивал кластер PostgreSQL из снимка и правил маршрутизацию балансировщика вручную. На первых учениях уложились в 6-8 часов, причём больше половины ушло на ожидание копии и сверку данных, а не на саму работу. Снимок отставал на сутки — часть подтверждённых операций терялась безвозвратно.

Что нашли при разборе

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

Что стало после

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

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

Чем отличается плановое переключение от аварийного?

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

Плановое переключение идёт по регламенту: сверяем отставание реплики, переводим приложения в режим только чтения, гасим фоновые задачи, дожидаемся нулевого лага и переключаем трафик. Отставание и подтверждение записи видны по системным представлениям СУБД, например PostgreSQL. Основной регион остаётся в горячем резерве — вернуться можно тем же регламентом.

Аварийное переключение запускается автоматикой при недоступности региона или дежурным, если автоматика молчит. Часть подтверждённых операций может не дойти до реплики — ради доступности сервиса свежими записями жертвуют, а старый регион потом синхронизируют вручную по журналам.

Критерии выбора режима сводятся к трём проверкам:

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

Практическое правило: пока регион управляем и лаг в допуске — переключаемся планово. У автоматики есть порог: при большом отставании она не поднимает второй регион, а только будит дежурного. Каждое аварийное переключение затем проигрывается как плановое — иначе процедура возврата остаётся непроверенной.

Технические сомнения: репликация, задержки, учения

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

Насколько часто нужны учения?

Полное переключение — раз в квартал, отдельные сценарии (потеря зоны, отказ хранилища, деградация канала) — ежемесячно. Каждый прогон даёт замер времени переключения и восстановления, расхождения разбираем с владельцем сервиса до следующего учения.

Чем подтверждается целостность данных?

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

Что с конфликтами при возврате трафика?

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

Обсудим вашу схему резервирования и режим переключения

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

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

Получив это, вернёмся с оценкой и планом: режим репликации по сервисам, этапы, сценарии учений, критерии приёмки. Предлагаем обсудить задачу — часть вводных обычно уже есть в документации, остальное доберём вместе.