Active-active против active-passive: выбор схемы резервирования

Прямой ответ

Схемы различаются тем, обслуживают ли резервные площадки трафик в обычном режиме. Active-passive — одна площадка рабочая, вторая находится в готовности. Active-active — обе обслуживают запросы одновременно.

Active-passive в PostgreSQL реализуется потоковой репликацией: резервный узел получает WAL-сегменты и применяет их:

# резервный узел
primary_conninfo = 'host=primary port=5432 user=replicator'
hot_standby = on

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

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

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

Практический вывод: active-active оправдан, когда простой в течение минут неприемлем или когда пользователи распределены географически и задержка критична; о контексте — в статье про multi-region.

Метрики и проверка готовности

Готовность резервной площадки нельзя оценить по документации — только по метрикам и фактическим переключениям.

Отставание реплики. Ключевая метрика: она показывает, сколько данных будет потеряно при переключении прямо сейчас. Отставание в 2 секунды и в 20 минут — разные значения фактического RPO при одинаковой схеме.

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

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

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

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

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

Практика: выбор и реализация схемы

1. Определите целевое RTO. Если допустим простой в 10 минут, active-passive достаточен и стоит вдвое дешевле.

2. Для active-active разделите источники записи. Каждая сущность принадлежит одному региону, что устраняет большинство конфликтов без сложного слияния.

3. Избегайте записи одной сущности в двух регионах. Если это необходимо, правило разрешения фиксируется явно и проверяется тестами.

4. Проверяйте переключение регулярно. Готовность резерва в active-passive подтверждается только фактическим переключением; о процедуре — в статье про disaster recovery.

5. Учитывайте задержку репликации. Резерв отстаёт от основного, и при переключении теряются данные за период отставания — это и есть фактический RPO.

6. Мониторьте отставание реплики. Метрика отставания показывает реальный RPO; её рост означает, что резерв не готов к переключению.

7. Тестируйте частичный отказ. Потеря одного региона при active-active не должна приводить к потере данных; проверка выполняется отключением площадки на тестовом трафике.

Рекомендации:

1. Не выбирайте active-active из соображений престижа. Схема оправдана метриками, а не архитектурной модой.
2. Начинайте с active-passive. Переход к active-active возможен позже, а обратный путь — признание избыточных затрат.
3. Фиксируйте правило разрешения конфликтов в коде. Правило, существующее только в документации, реализуется по-разному в разных сервисах.
4. Учитывайте стоимость простоя резерва. Простаивающая площадка — не потраченные впустую деньги, а оплаченная страховка; оценивайте её относительно стоимости простоя.
5. Проверяйте возврат после переключения. Возврат на основную площадку сложнее переключения и требует отдельной процедуры.

Практический сценарий: переход от active-passive к схеме с одним источником записи

Контекст: после третьего переключения за год команда решила снизить время восстановления и рассмотрела active-active.

1. Диагностика. Переключение занимало 12 минут, из которых 9 уходило на проверку целостности и перенаправление записи. Целевое RTO составляло 2 минуты.
2. Оценка. Полный active-active требовал разрешения конфликтов для 40 таблиц, что оценивалось в несколько месяцев работы и постоянную сложность. Анализ показал, что только 6 таблиц допускают запись из обоих регионов без конфликтов.
3. Действия. (а) Для 34 таблиц ввели правило одного источника записи: данные пользователя пишутся в его регионе; (б) для 6 общих справочников реализовали репликацию с последней записью как победителем, поскольку конфликты исключены малой частотой изменений; (в) маршрутизацию по региону пользователя добавили на точку входа; (г) переключение автоматизировали, сократив проверку целостности до контрольных запросов; (д) процедуру возврата описали отдельно и проверили на тестовом трафике.
4. Результат. Время восстановления сократилось до 3 минут без реализации полного слияния конфликтов, а сложность осталась управляемой благодаря разделению источников записи.

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

FAQ

Что дешевле: active-passive или active-active? Active-passive: резервная площадка не обслуживает трафик, поэтому её ресурсы меньше. Active-active требует полноценных ресурсов в каждой площадке.

Как определить фактический RPO? По отставанию реплики в момент отказа. Метрика отставания показывает, сколько данных будет потеряно при переключении.

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

Как проверить готовность резерва? Фактическим переключением по расписанию. Метрики репликации показывают отставание, но не подтверждают работоспособность после повышения.

Источники: AWS DR Architecture (multi-site active/active), PostgreSQL docs (warm standby), Azure Architecture Framework — ссылки в шапке.