Настройка DNS Failover для высокой доступности

DNS Failover: почему один узел роняет весь сервис

Типовой отказ выглядит предсказуемо: A-запись указывает на один адрес, и всё — приложение, база, очередь — живёт на одной площадке. Узел или его канал уходит вниз, а трафик продолжает идти на мёртвый адрес. Переключение делает дежурный руками: узнал по звонку, открыл панель, поменял запись — и всё это время сервис лежит у всех сразу.

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

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

Разбираем, как это закрывается: короткие TTL под переключение, автоматические проверки живости, несколько авторитативных серверов у разных провайдеров и заранее прописанный порядок действий без звонка.

Что даёт управляемое переключение трафика

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

На практике это переводит восстановление из десятков минут в единицы минут, а при коротком времени жизни записи — в секунды. Класс отказов «упала площадка — упал сервис» перестаёт воспроизводиться: сервис продолжает отвечать из резерва, пользователь видит разве что единичную ошибку в момент переключения. Доступность сервиса перестаёт зависеть от того, кто именно на смене.

Распределение нагрузки задаётся весами между площадками. Резерв при этом не простаивает: он постоянно несёт часть трафика, поэтому в момент переключения не захлёбывается от внезапного объёма — его ёмкость уже проверена реальной работой. Заодно снимается риск «резерва, который не запускали полгода».

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

Отдельно важен возврат трафика на основную площадку — он делается плавно, ступенями весов, с наблюдением за задержками и ошибками.

Варианты DNS Failover: сравнение режимов работы

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

Ключевой параметр в любом режиме — срок жизни записей. Короткий срок ускоряет переключение, но повышает нагрузку на серверы имён и трафик на запросах; слишком длинный растягивает простой на всё время кэша у промежуточных резолверов. На практике его подбирают под допустимое окно недоступности и снижают заранее, до плановых работ, а не в момент аварии. Дополнительно ограничивают переключение: проверяем несколько точек и требуем несколько неудачных откликов подряд, чтобы одиночный сбой сети не увёл трафик с живой площадки.

Порядок внедрения: от аудита до передачи в поддержку

Переключение трафика при отказе узла или целого региона — это не одна настройка, а последовательность работ, где каждый шаг опирается на результат предыдущего. Пока зона не описана, проверки доступности настраивать не на что, а без учебного отказа нельзя утверждать, что переключение сработает в реальной аварии, а не на бумаге.

1. Аудит зоны. Инвентаризируем записи: какие указывают на боевые узлы, какие используются почтой и сервисами, где зона делегирована и кто имеет право её менять. На выходе — карта зависимостей и список записей, которые нельзя трогать автоматикой.
2. Схема переключения. Определяем, как распределяется трафик между площадками, по какому признаку выбирается основной узел и как быстро записи перестают указывать на упавший. Отдельно фиксируем поведение сессий и то, что происходит с клиентами в момент смены адреса.
3. Настройка проверок доступности. Задаём, что именно проверяется — отклик сервиса или прикладной ответ, сколько подтверждений нужно до срабатывания и до возврата, чтобы не переключаться на коротком сбое и не «дрожать» между площадками.
4. Учебный отказ. Отключаем основной узел и смотрим фактическое время до восстановления, долю потерянных запросов и корректность работы резерва под нагрузкой. Расхождение с расчётом — повод вернуться к порогам.
5. Документация. Схема, матрица ответственных, порядок ручного переключения и отката, точки, где автоматика останавливается и нужен человек.
6. Передача в поддержку. Дежурная смена получает оповещения, инструкции по типовым сбоям и регламент регулярной проверки: раз в квартал повторяем учебный отказ, иначе настройка тихо расходится с реальностью.

Конфигурации, схемы и регламенты на выходе

Смысл работы в том, что после сдачи вся логика переключения остаётся у вашей команды, а не в переписке с подрядчиком. Мы отдаём конфигурации в вашем репозитории, схемы связей и регламенты, по которым дежурный принимает решение без нас. Ниже — что именно фиксируется в передаваемом комплекте.

• Конфигурации зон: зонные файлы с полным набором NS, SOA и сервисных записей, значения TTL по типам записей, split-horizon виды для внешних и внутренних резолверов.
• Проверки доступности: адреса и порты проб, интервалы опроса, порог срабатывания, порядок приоритетов и весов записей, правила автоматического возврата на основной узел после восстановления.
• Схема топологии: где размещены основные и резервные узлы, как между ними согласуются зоны, какие сетевые маршруты и адреса задействованы, что происходит при отказе площадки целиком.
• Политики доступа: роли и права на изменение записей, разделение контуров, ключи подписи передач зон, ограничения и срок жизни токенов управления, журнал всех изменений.
• Регламент дежурства: какие события дают алерт, кто и в какой срок поднимается, порядок эскалации, точки принятия решения о ручном переключении.
• Инструкции для дежурного: пошаговые сценарии на деградацию резолвинга, ручное переключение трафика, проверку результата и откат к прежнему состоянию.
• Мониторинг: набор метрик по времени ответа и доле успешных разрешений, синтетические пробы из внешних точек, панель состояния с разделением по сервисам.

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

Как это работает на практике: показатели до и после

До: ручное переключение и холодный резерв

Инфраструктура жила на одном активном узле: записи в зоне держали длинное время жизни, а резервную площадку поднимали вручную по тревоге дежурного. Когда основная площадка теряла сеть, трафик продолжал идти на недоступный адрес, пока инженер не менял записи — переключение занимало 3–7 минут. Резерв при этом был «холодным»: там отдавалась только статика, без актуальных данных и без прогретого кэша, поэтому полную нагрузку он бы не выдержал.

После: автоматика и горячий резерв

Переключение перевели на автоматику: внешний мониторинг с нескольких точек снимает проверки состояния с обоих узлов, а записи в Cloudflare переводятся по их результатам, время жизни записей снижено до минуты. Резервный узел сделали горячим — репликация данных, прогрев кэша и нагрузочный тест на полный объём трафика, чтобы он держал 100% запросов с запасом, а не «как получится».

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

За квартал доступность выросла с 99,5% до 99,97%, среднее время переключения сократилось с 3–7 минут до 45–70 секунд, доля отказов, дошедших до пользователя, упала с 0,4% до 0,03%. Ночных ручных подъёмов больше нет: дежурный лишь подтверждает, что автоматика отработала штатно, а ложные срабатывания разбираются по журналу переключений.

Что делать, если резервный контур уже развёрнут

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

Проверка готовности отвечает только на вопрос «жив ли резерв». Переключение без простоя требует большего: учений с реальным переводом трафика, контроля времени жизни записи в кэше резолверов и уверенности, что данные реплицируются до аварии, а не догоняют после. Требования к делегированию зоны и работе с регистратором сформулированы в правилах ICANN — их полезно сверить заранее, а не во время сбоя.

Ручной режим перевода не отменяет автоматику, а задаёт границу, за которой решение принимает человек. Рабочий вариант — автоматическое обнаружение аварии с обязательным подтверждением дежурным: зона не «дёргается» от краткого сетевого сбоя, а перевод укладывается в окно восстановления.

Частые технические сомнения перед стартом

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

Насколько часты ложные срабатывания проверок?

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

Можно ли переключать только часть сервисов и что с почтой?

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

Как проходит возврат на основной контур?

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

Обсудим вашу схему отказоустойчивости

Чтобы вернуться с оценкой и планом работ, а не с уточняющими вопросами, нам достаточно вводной по вашей схеме отказоустойчивости. Ниже — минимальный набор, который закрывает 90% неизвестных: остальное наши инженеры поднимут сами, включая тестовый контур для проверки переключения.

• Список зон и поддоменов, которые должны переживать отказ: продакшн-домены, служебные (API, личный кабинет, статика), почтовые записи.
• Где живут зоны сейчас: регистратор, управляемый DNS-провайдер или собственные серверы имён, кто держит делегирование и NS-записи.
• Что стоит за записями: пулы адресов, балансировщики, внешние сервисы, CDN — от этого зависит, на каком уровне переключать трафик.
• Целевое время переключения и допустимое окно недоступности: от него считаем частоту проверок, пороги срабатывания и время жизни записей.
• Точки контроля: из каких регионов и сетей проверяем доступность, по каким признакам считаем узел упавшим, нужен ли ручной режим подтверждения.
• Порядок работ и регламент: кто согласует изменения в продакшене, нужен ли журнал переключений и уведомления дежурной смене.
• Доступы и ограничения: роли у регистратора, права на правку зон, наличие тестового домена, запреты на автоматические изменения.

С этим набором мы собираем схему отказоустойчивости, оцениваем объём и называем сроки внедрения. Опишите задачу в удобном виде — вернёмся с оценкой и планом работ.