DNS Failover: чому один вузол валить весь сервіс
Типова відмова виглядає передбачувано: A-запис вказує на одну адресу, і все — застосунок, база, черга — живе на одному майданчику. Вузол або його канал падає, а трафік продовжує йти на мертву адресу.
Перемикання робить черговий вручну: дізнався з дзвінка, відкрив панель, змінив запис — і весь цей час сервіс лежить у всіх одночасно.
Причина не у швидкості правки запису, а в кеші. Рекурсивні резолвери, кеші провайдерів і локальний кеш операційної системи тримають відповідь рівно стільки, скільки вказано в TTL.
За типових значень це години, тому миттєва правка зони не рятує: частина клієнтів ще довго стукає на виведений вузол, і час відновлення виходить плаваючим.
Окрема точка відмови — сама зона: один авторитативний сервер, один акаунт реєстратора, з якого правлять записи. Якщо недоступна панель або закінчився термін домену, перемкнути трафік нічим, навіть коли резервний майданчик повністю готовий.
Частину цього завдання знімає Anycast — одна адреса анонсується з кількох точок, і маршрутизація відводить трафік від майданчика, що впав, автоматично, але лише на мережевому рівні.
Розбираємо, як це закривається: короткі TTL під перемикання, автоматичні перевірки доступності, кілька авторитативних серверів у різних провайдерів і заздалегідь прописаний порядок дій без дзвінка.
Що дає кероване перемикання трафіку
Кероване перемикання прибирає ручний крок із відновлення. Перевірки доступності вузлів ідуть постійно, і щойно майданчик перестає відповідати на них, трафік автоматично йде на резервний — без дзвінка черговому й правки записів вручну.
Час відновлення визначається вже не швидкістю реакції людини, а часом життя DNS-запису й порогом спрацювання перевірки.
На практиці це перетворює відновлення з десятків хвилин в одиниці хвилин, а за короткого часу життя запису — у секунди.
Клас відмов «упав майданчик — упав сервіс» перестає відтворюватися: сервіс продовжує відповідати з резерву, користувач бачить хіба що одиничну помилку в момент перемикання. Доступність сервісу перестає залежати від того, хто саме на зміні.
Розподіл навантаження задається вагами між майданчиками. Резерв при цьому не простоює: він постійно несе частину трафіку, тому в момент перемикання не захлинається від раптового обсягу — його ємність уже перевірена реальною роботою. Заодно знімається ризик «резерву, який не запускали пів року».
Перевірки доступності вузлів налаштовуємо за прикладною ознакою, а не лише за фактом відповіді мережі: вузол може бути ввімкнений, але віддавати помилки — такий сценарій теж перехоплюється. Поріг спрацювання задається із запасом, щоб короткий сплеск не давав хибного перемикання.
Доступність сервісу у звітності вважаємо за часткою успішних відповідей, а не за заявленим часом роботи.
Окремо важливе повернення трафіку на основний майданчик — воно робиться плавно, ступенями ваг, із спостереженням за затримками й помилками.
Варіанти DNS Failover: порівняння режимів роботи
Вибір режиму — це компроміс між швидкістю реакції та передбачуваністю. Активно-резервна схема тримає в роботі одну адресу, друга чекає в гарячому резерві й вмикається за перевіркою доступності майданчика.
Активно-активна роздає обидві адреси одразу, тому відмова одного майданчика не потребує чекати спрацювання механізму. Ручне переведення залишає рішення за інженером і застосовується там, де автоматика може нашкодити.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Активно-резервна схема | Основний і резервний майданчик, різна ємність, рідкі відмови | Перемикання займає від однієї до кількох хвилин: поки живе час життя запису, частина клієнтів іде на адресу, що впала |
| Активно-активна схема | Два рівні майданчики, вимога нульового простою, трафік зростає | Обидва майданчики зобов’язані тримати однакові дані й конфігурацію, інакше частина запитів іде на неготовий вузол |
| Ручне переведення | Регламентні роботи, міграції, тестові контури | Швидкість залежить від чергового; вночі та у вихідні вікно реакції зростає |
Ключовий параметр у будь-якому режимі — час життя записів. Короткий час прискорює перемикання, але підвищує навантаження на сервери імен і трафік на запитах; надто довгий розтягує простій на весь час кешу в проміжних резолверів.
На практиці його підбирають під допустиме вікно недоступності й знижують заздалегідь, до планових робіт, а не в момент аварії.
Додатково обмежують перемикання: перевіряємо кілька точок і вимагаємо кілька невдалих відгуків підряд, щоб одиничний збій мережі не відвів трафік із живого майданчика.
Порядок впровадження: від аудиту до передачі в підтримку
Перемикання трафіку при відмові вузла або цілого регіону — це не одне налаштування, а послідовність робіт, де кожен крок спирається на результат попереднього.
Поки зона не описана, перевірки доступності налаштовувати ні на що, а без навчальної відмови не можна стверджувати, що перемикання спрацює в реальній аварії, а не на папері.
- Аудит зони. Інвентаризуємо записи: які вказують на бойові вузли, які використовуються поштою й сервісами, де зона делегована і хто має право її змінювати. На виході — карта залежностей і список записів, які не можна чіпати автоматикою.
- Схема перемикання. Визначаємо, як розподіляється трафік між майданчиками, за якою ознакою вибирається основний вузол і як швидко записи перестають вказувати на того, хто впав. Окремо фіксуємо поведінку сесій і те, що відбувається з клієнтами в момент зміни адреси.
- Налаштування перевірок доступності. Задаємо, що саме перевіряється — відгук сервісу чи прикладна відповідь, скільки підтверджень потрібно до спрацювання й до повернення, щоб не перемикатися на короткому збої й не «тремтіти» між майданчиками.
- Навчальна відмова. Вимикаємо основний вузол і дивимося фактичний час до відновлення, частку втрачених запитів і коректність роботи резерву під навантаженням. Розходження з розрахунком — привід повернутися до порогів.
- Документація. Схема, матриця відповідальних, порядок ручного перемикання й відкату, точки, де автоматика зупиняється і потрібна людина.
- Передача в підтримку. Чергова зміна отримує оповіщення, інструкції щодо типових збоїв і регламент регулярної перевірки: раз на квартал повторюємо навчальну відмову, інакше налаштування тихо розходиться з реальністю.
Конфігурації, схеми та регламенти на виході
Сенс роботи в тому, що після здачі вся логіка перемикання залишається у вашої команди, а не в листуванні з підрядником. Ми віддаємо конфігурації у вашому репозиторії, схеми зв’язків і регламенти, за якими черговий приймає рішення без нас. Нижче — що саме фіксується в комплекті, який передається.
- Конфігурації зон: зонні файли з повним набором NS, SOA і сервісних записів, значення TTL за типами записів, split-horizon види для зовнішніх і внутрішніх резолверів.
- Перевірки доступності: адреси й порти проб, інтервали опитування, поріг спрацювання, порядок пріоритетів і ваг записів, правила автоматичного повернення на основний вузол після відновлення.
- Схема топології: де розміщені основні та резервні вузли, як між ними узгоджуються зони, які мережеві маршрути й адреси задіяні, що відбувається при відмові майданчика цілком.
- Політики доступу: ролі та права на зміну записів, розділення контурів, ключі підпису передач зон, обмеження й час життя токенів керування, журнал усіх змін.
- Регламент чергування: які події дають алерт, хто і в який строк піднімається, порядок ескалації, точки прийняття рішення про ручне перемикання.
- Інструкції для чергового: покрокові сценарії на деградацію резолвінгу, ручне перемикання трафіку, перевірку результату й відкат до попереднього стану.
- Моніторинг: набір метрик за часом відповіді та часткою успішних розв’язань, синтетичні проби із зовнішніх точок, панель стану з розділенням за сервісами.
Комплект оформлюється так, щоб новий інженер відтворив схему за документами, а не за пам’яттю колег. При змінах топології ми оновлюємо і схеми, і сценарії — інакше документація розходиться з реальністю за один реліз.
Як це працює на практиці: показники до і після
До: ручне перемикання й холодний резерв
Інфраструктура жила на одному активному вузлі: записи в зоні тримали довгий час життя, а резервний майданчик піднімали вручну за тривогою чергового.
Коли основний майданчик втрачав мережу, трафік продовжував іти на недоступну адресу, поки інженер не змінював записи — перемикання займало 3–7 хвилин.
Резерв при цьому був «холодним»: там віддавалася лише статика, без актуальних даних і без прогрітого кешу, тому повне навантаження він би не витримав.
Після: автоматика та гарячий резерв
Перемикання перевели на автоматику: зовнішній моніторинг із кількох точок знімає перевірки стану з обох вузлів, а записи в Cloudflare перемикаються за їхніми результатами, час життя записів знижено до хвилини.
Резервний вузол зробили гарячим — реплікація даних, прогрів кешу й навантажувальний тест на повний обсяг трафіку, щоб він тримав 100% запитів із запасом, а не «як вийде».
Пороги проб налаштували так, щоб одна втрачена відповідь не запускала перемикання: потрібні підтвердження від кількох точок у межах вікна спостереження.
Хибні спрацювання практично зникли, а навантаження на резервний вузол у момент аварії вкладається в його розрахункову ємність — без деградації часу відповіді.
За квартал доступність зросла з 99,5% до 99,97%, середній час перемикання скоротився з 3–7 хвилин до 45–70 секунд, частка відмов, що дійшли до користувача, впала з 0,4% до 0,03%.
Нічних ручних підйомів більше немає: черговий лише підтверджує, що автоматика відпрацювала штатно, а хибні спрацювання розбираються за журналом перемикань.
Що робити, якщо резервний контур уже розгорнуто
Резервний контур розгорнуто, сервіси в ньому відповідають, але аварійне переведення не спрацьовує — інфраструктура готова, а процедура ні.
Перевіряти варто три речі по порядку: за яким сигналом приймається рішення про перемикання, чи сходиться стан даних між контурами і чи збігається картина у внутрішніх перевірок з тим, що бачать користувачі.
Ламається зазвичай третє: перевірка стукає в сервіс зсередини мережі, а клієнтський трафік приходить через зовнішні резолвери.
| Сценарій переведення | Коли підходить | Обмеження |
|---|---|---|
| Автоматично за перевіркою доступності | Резерв прогрітий постійно, дані синхронні | Хибні спрацювання при збоях мережі та деградації зовнішнього маршруту |
| Ручний режим переведення за командою чергового | Критичні сервіси, де ціна помилки вища за час простою | Потрібен цілодобовий відповідальний і однозначний регламент |
| Визначення аварії автоматикою, підтвердження людиною | Потрібне перемикання без простою, але без «смикання» зони | Складніший регламент, потрібні явні критерії підтвердження |
Перевірка готовності відповідає лише на питання «чи живий резерв». Перемикання без простою потребує більшого: навчань із реальним переведенням трафіку, контролю часу життя запису в кеші резолверів і впевненості, що дані реплікуються до аварії, а не наздоганяють після.
Вимоги до делегування зони та роботи з реєстратором сформульовані в правилах ICANN — їх корисно звірити заздалегідь, а не під час збою.
Ручний режим переведення не скасовує автоматику, а задає межу, за якою рішення приймає людина. Робочий варіант — автоматичне виявлення аварії з обов’язковим підтвердженням черговим: зона не «смикається» від короткого мережевого збою, а переведення вкладається у вікно відновлення.
Часті технічні сумніви перед стартом
На старті майже завжди зринають одні й ті самі питання: чи не залипне перемикання через кеш, чи не буде хибних спрацювань і чи не постраждає пошта. Відповідаємо коротко — з розрахунком на те, що рішення ви будете перевіряти самі.
Чи не залипне перемикання через кеш у провайдерів?
Час життя запису (TTL) — ключовий параметр: на записах, що перемикаються, тримаємо його низьким, щоб сервери провайдерів перезапитували адресу кожні кілька хвилин. Надто короткий TTL підвищує навантаження на авторитетний сервер, тому значення підбираємо під профіль трафіку.
Наскільки часті хибні спрацювання перевірок?
Одинична перевірка сама стає точкою відмови. Тому стан підтверджується серією невдалих відповідей із кількох незалежних вузлів у різних мережах — одиничний таймаут або короткочасна втрата пакетів перемикання не запускає.
Чи можна перемикати лише частину сервісів і що з поштою?
Політика задається за записами: перемикаються лише сервісні піддомени, а основний сайт залишається статичним.
Поштові записи в відмовостійкість не включаємо — при недоступності вузла листи накопичуються в черзі відправника, а різка зміна маршруту б’є по репутації домену й перевірках справжності.
Як відбувається повернення на основний контур?
Повернення — та сама процедура у зворотний бік, але з попередньою перевіркою резерву: контур, що піднявся, має пройти тести, перш ніж отримає трафік. Інакше перемикання почнуть ходити туди-сюди, і клієнти побачать плаваючі затримки.
Обговоримо вашу схему відмовостійкості
Щоб повернутися з оцінкою та планом робіт, а не з уточнювальними питаннями, нам достатньо ввідних щодо вашої схеми відмовостійкості. Нижче — мінімальний набір, який закриває 90% невідомих: решту наші інженери піднімуть самі, зокрема тестовий контур для перевірки перемикання.
- Список зон і піддоменів, які мають переживати відмову: продакшн-домени, службові (API, особистий кабінет, статика), поштові записи.
- Де живуть зони зараз: реєстратор, керований DNS-провайдер або власні сервери імен, хто тримає делегування та NS-записи.
- Що стоїть за записами: пули адрес, балансувальники, зовнішні сервіси, CDN — від цього залежить, на якому рівні перемикати трафік.
- Цільовий час перемикання й допустиме вікно недоступності: від нього рахуємо частоту перевірок, пороги спрацювання та час життя записів.
- Точки контролю: з яких регіонів і мереж перевіряємо доступність, за якими ознаками вважаємо вузол таким, що впав, чи потрібен ручний режим підтвердження.
- Порядок робіт і регламент: хто погоджує зміни в продакшені, чи потрібен журнал перемикань і повідомлення черговій зміні.
- Доступи й обмеження: ролі в реєстратора, права на правку зон, наявність тестового домену, заборони на автоматичні зміни.
З цим набором ми збираємо схему відмовостійкості, оцінюємо обсяг і називаємо строки впровадження. Опишіть завдання в зручному вигляді — повернемося з оцінкою та планом робіт.
