DNS-failover: TTL обещает, а выполняет резолвер

TTL в DNS-записи говорит резолверу: «этот ответ можно хранить столько-то». Он не говорит: «через столько-то ты обязательно обновишь».

На практике многие резолверы меняют TTL по-своему. Одни ставят нижнюю границу и поднимают 60 секунд до 300. Другие, наоборот, ставят верхнюю. А внутренние резолверы в корпоративных сетях нередко работают с самыми старыми настройками.

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

Между пользователем и вашим DNS-сервером обычно есть минимум три кеша: кеш операционной системы, кеш браузера и кеш провайдерского или корпоративного резолвера.

Кеш браузера особенно неудобен: он иногда игнорирует TTL и применяет собственный срок. Пользователь с открытой страницей может десять минут стучаться на старый адрес.

К этому добавляется «липкость» на уровне соединений: открытое TCP-соединение продолжает работать со старым адресом и после смены DNS. Чтобы обновиться, оно сначала должно разорваться.

Failover обычно делают через CNAME: запись `www` указывает на имя провайдера, а провайдер отдаёт нужный адрес. Но стандарт не разрешает CNAME на апексе — то есть на `example.uz`.

Поэтому для апекса ставят A-запись, а она статична. Провайдер сменит адрес — ваш апекс останется на старом.

Часть DNS-провайдеров решает это нестандартными механизмами. Но самый надёжный путь другой: делегировать зону провайдеру целиком, то есть сменить NS-записи. Тогда и апекс, и остальные записи управляются из одного места.

Качество failover определяется точками проверки. Проверка из одного места читает сетевую проблему этой точки как аварию для всего мира.

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

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

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

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

И возврат лучше не делать автоматическим. Сервер восстановился или только отвечает на проверку — на это смотрит человек. Автоматический возврат отправляет трафик поверх незавершённого восстановления.

DNS уводит трафик на другой адрес, но не переносит состояние пользователя. Если сессия хранится только на одном сервере, после переключения всем придётся входить заново.

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

Поэтому план failover обязан отвечать на два вопроса: останется ли пользователь авторизованным и работают ли операции записи?

Перечисленные ограничения не делают DNS-failover бесполезным. Они лишь опускают его с обещания «переключимся за минуту» до реальности «за десять–пятнадцать минут перейдёт большая часть пользователей».

Для большинства случаев этого достаточно. Когда падает целый дата-центр или провайдер, увести 80% трафика за десять минут — очень хороший результат.

Важно правильно поставить ожидание. Если бизнес не переживает и минуты простоя, DNS не решение: тогда нужен anycast или архитектура «активный–активный», а это заметно дороже.

Не принимайте план за уверенность без учений. Тренируйте переключение планово и в рабочий день, а не ночью — ночью у вас нет ни кешей, ни пользователей.

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

И тренируйте возврат. Большинство репетирует только уход, а потом на реальной аварии получает второй простой при возвращении.