Что такое DNS Failover?
DNS failover — это автоматизированный механизм перенаправления трафика с неработающего сервера на работающий путём изменения DNS-ответов в реальном времени. Когда проверка здоровья обнаруживает, что основной сервер недоступен, DNS-провайдер автоматически обновляет запись, направляя на резервный сервер.
Традиционный DNS статичен — записи устанавливаются вручную. DNS failover добавляет интеллектуальный слой: непрерывный мониторинг сайтов здоровья с автоматическим переключением записей. Пользователи бесшовно перенаправляются на работающую инфраструктуру без ручного вмешательства.
Как работает DNS Failover
Процесс включает три компонента:
- Проверки здоровья — DNS-провайдер непрерывно мониторит серверы, отправляя HTTP-запросы, TCP- или ICMP-Ping инструмент каждые 30–60 секунд
- Логика переключения — когда проверка проваливается заданное число раз подряд (например, 3), система помечает сервер как нездоровый
- Обновление DNS Lookup — DNS-ответ меняется, возвращая IP резервного сервера
Нормальная работа:
Пользователь → DNS → api.example.com → 203.0.113.10 (основной)
Основной не прошёл проверку (3 неудачи подряд):
Система помечает 203.0.113.10 как DOWN
Failover активирован:
Пользователь → DNS → api.example.com → 203.0.113.20 (резерв)
Основной восстановился (3 успеха подряд):
Пользователь → DNS → api.example.com → 203.0.113.10 (основной)TTL и скорость переключения
Критический фактор — TTL (Time to Live). При TTL 3600 секунд (1 час) резолверы кэшируют старый IP до часа после переключения. Пользователи продолжают обращаться к упавшему серверу.
| TTL | Скорость failover | Нагрузка на DNS | Применение |
|---|---|---|---|
| 30 с | ~30–90 с | Очень высокая | Критичные сервисы |
| 60 с | ~1–3 мин | Высокая | Продакшен API документацию и сайты |
| 300 с | ~5–10 мин | Умеренная | Общие веб-ресурсы |
| 3600 с | ~1 час | Низкая | Не подходит для failover |
Компромисс: низкий TTL = быстрый failover, но больше DNS-запросов и чуть выше задержка из-за частых DNS-лукапов.
Стратегии переключения
Active-Passive
Основной сервер обрабатывает весь трафик. Резервный простаивает до переключения. Просто и экономично, но резервные мощности тратятся впустую.
Active-Active
Несколько серверов разделяют трафик (round-robin или weighted). При отказе одного его доля распределяется между оставшимися. Эффективнее — нет простаивающих мощностей — но все серверы должны выдержать дополнительную нагрузку.
Географический (GeoDNS) Failover
Маршрутизация пользователей на ближайший дата-центр по IP геолокацию. При отказе регионального сервера — перенаправление на ближайший здоровый регион. Сочетает оптимизацию задержки с высокой доступностью.
Настройка проверок здоровья
Эффективные проверки должны быть:
- Конкретными — проверяйте сам сервис, а не просто пинг. HTTP-проверка
/healthс верификацией БД лучше ICMP-пинга - Частыми — каждые 30–60 секунд для критичных сервисов
- Устойчивыми — несколько неудач подряд до переключения (защита от «мигания» из-за кратковременных сетевых проблем)
- Из нескольких точек — проверка из одной локации может не пройти из-за проблем сетевого пути, а не реального даунтайма. Используйте 3+ географических точек
# Пример конфигурации проверки здоровья
endpoint: https://api.example.com/health
method: GET
interval: 30s
timeout: 10s
healthy_threshold: 3 # 3 успеха для статуса UP
unhealthy_threshold: 3 # 3 неудачи для статуса DOWN
expected_status: 200
check_regions:
- us-east
- eu-west
- ap-southeastDNS Failover vs балансировщик нагрузки
| Свойство | DNS Failover | Балансировщик |
|---|---|---|
| Уровень | DNS (до соединения) | Сеть/Приложение (L4/L7) |
| Скорость | Секунды–минуты (зависит от TTL) | Миллисекунды–секунды |
| Охват | Кросс-региональный | Внутри кластера/региона |
| Стоимость | Низкая | Выше (инфраструктура LB) |
| Гранулярность | Уровень сервера/IP | Уровень запроса |
Лучшая практика: используйте оба. Балансировщики для быстрого переключения внутри региона, DNS failover для межрегионального аварийного восстановления.
Типичные ошибки
- Высокий TTL — самая частая ошибка. TTL 3600 с делает DNS failover почти бесполезным. Снизьте до 60–300 с
- Мигание (flapping) — агрессивные пороги вызывают быстрое переключение туда-обратно. Требуйте 3+ последовательных неудач
- Непротестированный резерв — резервный сервер не тестировался под продакшен-нагрузкой. Failover срабатывает, резерв тут же падёт
- «Липкие» резолверы — некоторые ISP-резолверы игнорируют TTL и кэшируют записи дольше
- Нет плана обратного переключения — когда основной восстановится, как переключиться обратно? Автоматический failback может быть рискован
Мониторинг DNS Failover
- Мониторьте статус проверок здоровья из нескольких регионов
- Отслеживайте DNS propagation после событий failover — используйте Enterno.io для проверки записей с глобальных локаций
- Алертинг на события переключения (активация и восстановление)
- Регулярно тестируйте failover симуляцией отказа основного
- Мониторьте соблюдение TTL основными резолверами
Заключение
DNS failover — необходимый компонент архитектуры высокой доступности. Обеспечивает межрегиональную отказоустойчивость при низкой стоимости, дополняя балансировщики нагрузки для внутрирегионального переключения. Настройте низкие TTL, реализуйте надёжные проверки здоровья из нескольких локаций, тестируйте резервную инфраструктуру под нагрузкой и непрерывно мониторьте события переключения.