Георезервирование: почему второй ЦОД ещё не гарантирует отказоустойчивость

На фоне недавних инцидентов с дата-центрами «Яндекса» хочу подробнее разобрать георезервирование.

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

Но иметь второй ЦОД и быть готовым потерять первый — совершенно разные вещи.

🔴Active-Passive или Active-Active?

В Active-Passive основная нагрузка работает на одной площадке, вторая находится в резерве. Это проще в эксплуатации, но требует достаточных резервных ресурсов и регулярного тестирования переключения.

В Active-Active обе площадки работают одновременно. Это может сократить время восстановления, но усложняет маршрутизацию, синхронизацию данных и защиту от split-brain. Не каждое приложение готово к такой архитектуре.

🔴Главная сложность — не вычисления, а данные.

Развернуть Kubernetes в другом регионе можно автоматизированно. Гораздо сложнее обеспечить корректное состояние PostgreSQL, очередей сообщений и других stateful-компонентов.

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

Поэтому сначала нужно определить:

➖RPO — сколько данных бизнес готов потерять.

➖RTO — сколько времени допустимо потратить на восстановление.

Чем ближе эти показатели к нулю, тем сложнее и дороже обеспечить отказоустойчивость.

🔴А если недоступны обе площадки?

Даже физически разделённые ЦОДы могут зависеть от общего DNS, системы авторизации, сетевого провайдера или облачного control plane.

А ошибка в Terraform, неудачная миграция БД или компрометация административного аккаунта способны затронуть оба региона.

Поэтому георезервирование — это не просто размещение инфраструктуры в разных местах, а устранение общих точек отказа (SPOF) на уровне всей системы.

🔴И сколько это стоит?

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

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

Во время недавних инцидентов с дата-центрами «Яндекса» мощности у топ-10 провайдеров закончились в течение одного календарного дня.

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

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

🔴Так нужно ли всем срочно строить второй ЦОД?

Необязательно. Для внутреннего сервиса простой на несколько часов может быть приемлемым. Для платёжной системы или крупного интернет-магазина даже короткий простой способен стоить дороже резервной инфраструктуры.

Поэтому начинать нужно с оценки рисков, определения RPO/RTO и анализа зависимостей. И только потом выбирать архитектуру.

Георезервирование — это не про количество дата-центров. Это про способность системы пережить потерю целой площадки в пределах, согласованных с бизнесом.