Как вы спроектируете отказоустойчивость связки DNS и L4/L7-балансировщиков на случай полного отказа одного дата-центра, и какие компромиссы между сложностью, стоимостью и временем восстановления (RTO) при этом нужно явно обсуждать с заинтересованными сторонами?

Короткий ответ

Готового универсального решения нет: степень избыточности (active-active с несколькими живыми дата-центрами одновременно против active-passive с холодным/тёплым резервом) и конкретные механизмы (Anycast, GeoDNS, глобальный L7-балансировщик, репликация состояния между ДЦ) должны выбираться исходя из целевого RTO/RPO, бюджета на дублирующую инфраструктуру и того, насколько приложение вообще готово к работе из нескольких дата-центров одновременно (stateless или stateful с репликацией данных).

Как это работает подробнее

При active-passive схеме балансировщик и DNS в резервном ДЦ большую часть времени простаивают, включаясь только при обнаружении отказа основного ДЦ (через health checks на уровне DNS или специального failover-контроллера), что проще в эксплуатации, но даёт более долгий RTO (время на обнаружение отказа плюс время на реальное переключение трафика и прогрев резерва); при active-active с Anycast или глобальным L7-балансировщиком трафик распределён между дата-центрами постоянно, и при отказе одного из них оставшиеся продолжают обслуживать запросы почти без видимого простоя, но такая схема требует, чтобы приложение и данные были спроектированы для согласованной работы из нескольких регионов одновременно (репликация БД, разрешение конфликтов, идемпотентность).

Пример кода

example.txtКопировать

Пример active-active отказоустойчивости:
- Anycast IP перед L4-балансировщиками в ДЦ A и ДЦ B
- БД: репликация между регионами + чёткая стратегия разрешения конфликтов
  или единый источник истины с синхронной репликацией в пределах допустимой задержки
- Регулярные game days: полное отключение ДЦ A, замер фактического RTO и доли ошибок

Что использовать на практике

• Практика. для сервисов с жёстким требованием низкого RTO выбирают active-active с Anycast/глобальным балансировщиком и инвестируют в архитектуру данных, поддерживающую мультирегиональность; для менее критичных сервисов допустим active-passive с автоматизированным, но не мгновенным failover, что существенно дешевле в эксплуатации; в обоих случаях необходимо регулярно проводить управляемые disaster recovery учения (game days) с реальным отключением одного ДЦ, потому что теоретически написанный план failover часто ломается на практике из-за забытых зависимостей (например, компонент, который всё ещё жёстко завязан на IP одного дата-центра).
• Компромисс. Game day с полным отключением одного дата-центра должен показать, что трафик продолжает обслуживаться оставшимся ДЦ с измеримым, заранее согласованным уровнем деградации (или без неё), а не выявлять в момент учений забытые жёсткие зависимости от конкретного дата-центра.

Подводные камни

• Риск. считать наличие резервного дата-центра достаточным без регулярной проверки реального переключения на нём; проектировать DNS/балансировку как единственный уровень защиты, не учитывая, что данные (БД) могут не быть готовы к failover так же быстро, как трафик; занижать RTO в документах 'на бумаге', не подтверждая его реальными учениями с измерением фактического времени восстановления.