Що таке DNS Failover
DNS Failover — це автоматична заміна IP-адреси в A чи AAAA-записі, коли основний сервер перестає відповідати. Спеціальний моніторинг постійно опитує основний хост, і у разі виявлення збою система переписує запис зони на резервний сервер без участі людини. Це дешева альтернатива балансувальнику навантаження для сайтів, яким не потрібна постійна робота двох серверів одночасно, а потрібна лише страховка на випадок відмови основного.
Технологія не замінює резервне копіювання і не рятує від втрати даних — вона вирішує лише завдання доступності домену, поки основна інфраструктура відновлюється.
Як працює перевірка доступності
В основі DNS Failover — health check: зовнішній агент раз на 10–60 секунд звертається до сервера через HTTP, TCP чи ping і чекає коректної відповіді. Налаштування зазвичай виглядає так:
check_type: http
url: https://example.com/health
interval: 30s
timeout: 5s
failures_before_switch: 3Поріг у кілька поспіль невдалих перевірок (у прикладі — 3) потрібен, щоб не перемикатися на резерв через одну випадкову затримку в мережі. Після спрацювання порогу система замінює A-запис на IP резервного сервера і чекає повернення основного до життя, щоб перемкнути назад.
Налаштування низького TTL для швидкого перемикання
Швидкість, з якою відвідувачі побачать новий IP, визначається значенням TTL запису, а не швидкістю самого моніторингу. Поки старе значення живе в кеші резолвера у провайдера користувача, той продовжить стукати в сервер, що впав. Для доменів з Failover TTL зазвичай знижують до 60–300 секунд:
example.com. 60 IN A 203.0.113.10Детально про вибір значення TTL та його вплив на швидкість оновлення — у статті про налаштування TTL. Тут важливо пам'ятати компроміс: занадто низький TTL збільшує кількість запитів до DNS-серверів і трохи підвищує затримку резолвінгу, занадто високий — гальмує перемикання під час збою.
DNS Failover і Anycast: у чому різниця
DNS Failover і Anycast вирішують схоже завдання — доступність сервісу — але різними способами. Failover змінює вміст запису і залежить від TTL та швидкості оновлення кешів резолверів по всьому світу, тому перемикання займає хвилини. Anycast віддає одну й ту саму IP-адресу з кількох точок присутності одночасно, а маршрутизація на рівні BGP сама відводить трафік від вузла, що впав, — перемикання відбувається на рівні мережі, а не DNS, і вкладається в секунди.
Anycast складніше і дорожче розгортати, тому для невеликих проєктів DNS Failover залишається розумним компромісом між вартістю і часом простою.
Обмеження і підводні камені
| Проблема | Чому виникає |
|---|---|
| Частина користувачів досі бачить старий IP | Резолвер провайдера тримає запис довше за TTL, ігноруючи його |
| Хибне перемикання | Здоров'я перевірялося з однієї точки, а мережа блимнула локально |
| Перемикання відбулося, але сайт все одно недоступний | На резервному сервері не синхронізовано дані чи конфігурацію |
| Перемикання назад не відбувається | Основний сервер відповідає на health check, але застосунок на ньому все ще зламаний |
Чек-лист впровадження DNS Failover
- Налаштуйте health check за тим самим протоколом, що використовує реальний трафік, а не просто ping.
- Знизьте TTL запису заздалегідь, за добу до увімкнення Failover, щоб старі значення випали з кешів.
- Тримайте резервний сервер з актуальними даними і конфігурацією, а не лише зі встановленим ПЗ.
- Перевіряйте перемикання через dig з різних резолверів, а не лише з одного пристрою.
- Налаштуйте поріг у кілька невдалих перевірок поспіль, щоб уникнути хибних спрацювань.