Георезервирование: почему второй ЦОД ещё не гарантирует отказоустойчивость
На фоне недавних инцидентов с дата-центрами «Яндекса» хочу подробнее разобрать георезервирование.
Казалось бы, всё просто: размещаем инфраструктуру в двух регионах, настраиваем репликацию и при аварии переключаемся на резервную площадку.
Но иметь второй ЦОД и быть готовым потерять первый — совершенно разные вещи.
🔴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 и анализа зависимостей. И только потом выбирать архитектуру.
Георезервирование — это не про количество дата-центров. Это про способность системы пережить потерю целой площадки в пределах, согласованных с бизнесом.
На фоне недавних инцидентов с дата-центрами «Яндекса» хочу подробнее разобрать георезервирование.
Казалось бы, всё просто: размещаем инфраструктуру в двух регионах, настраиваем репликацию и при аварии переключаемся на резервную площадку.
Но иметь второй ЦОД и быть готовым потерять первый — совершенно разные вещи.
🔴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 и анализа зависимостей. И только потом выбирать архитектуру.
Георезервирование — это не про количество дата-центров. Это про способность системы пережить потерю целой площадки в пределах, согласованных с бизнесом.
Просмотры: 3