Keepalived: чому відмова одного вузла обвалює сервіс
Типова схема зазвичай виглядає відмовостійкою: застосунок розгорнуто в кількох екземплярах, база реплікується, під резерв виділено потужності. Але вхід у сервіс — балансувальник, зворотний проксі або шлюз — закріплений за одним вузлом, і він же виявляється єдиною точкою відмови. Уся надлишковість за ним обнуляється першим же падінням.
Ламається при цьому не застосунок, а адреса. Вузол виходить з ладу через живлення, ядро або невдале оновлення — і точка входу, куди ходять клієнти, перестає відповідати.
DNS-запис перемикається не миттєво: заважають час життя запису й кеші резолверів, а ручне перенесення трафіку займає хвилини й робиться вночі за інструкцією.
Простий при відмові вузла вимірюється десятками хвилин: у користувачів — помилки й тайм-аути, у чергової зміни — розбір інциденту й правка конфігурації під тиском.
Ціна такої схеми не лише в годинах недоступності. Кожне ручне перемикання — це ризик помилитися: не той вузол, забутий маршрут, втрачені сесії. Поки ручний сценарій залишається єдиним, відмовостійкість сервісу тримається на швидкості чергового, а не на архітектурі.
Розбираємо, як це закривається. Keepalived тримає плаваючу адресу на парі вузлів за протоколом VRRP, перевіряє їхній стан скриптами й переводить трафік без участі людини — з передбачуваним часом перемикання й без нічних ручних правок.
Що дає відмовостійкість: вимірюваний ефект
Ефект відмовостійкості вимірюється трьома величинами: скільки сервіс недоступний при відмові вузла, яка частка інцидентів узагалі доходить до користувача і чи можна обслуговувати сервери, не зупиняючи роботу.
Автоматичне перемикання замість ручного втручання
Раніше вузол, що впав, помічав черговий — за сповіщенням моніторингу, іноді за скаргою. Поки він підключався й переносив адресу руками, сервіс лежав десятки хвилин, і кожна хвилина простою припадала на робочий час.
Перемикання виконує Keepalived: резервний вузол забирає адресу за секунди, без людини в контурі. Час відновлення сервісу стискається з десятків хвилин до 1-3 секунд, а черговий дізнається про подію з журналу, коли сервіс вже приймає трафік.
Клас відмов «вузол недоступний» зникає зі статистики
Поки один вузол перезавантажується або ремонтується, другий тримає трафік — відмова обладнання перестає бути відмовою сервісу. Важливо, чим перевіряється живучість: відгук на мережевому рівні підтверджує, що машина ввімкнена, але не що застосунок відповідає.
Перевірка запитом до застосунку відсіює вузли, формально живі, але які віддають помилки. Повна відмова сервісу тоді потребує одночасного падіння всіх вузлів, тобто спільної причини — мережі, живлення або невдалого релізу. Доступність сервісу зростає не «в середньому», а завдяки зникненню цілого класу інцидентів.
Планові роботи без простою
Обслуговування йде по одному вузлу: його виводять з обробки трафіку, оновлюють, повертають у стрій, потім переходять до наступного. Доступність при цьому не провалюється, узгоджувати нічне вікно й поспішати не потрібно — роботи переносяться в зручні години.
Така схема окупається й на рідкісних операціях: заміна заліза або зміна конфігурації більше не перетворюється на плановий простій для користувачів.
Режими роботи Keepalived: порівняння варіантів
Схему резервування обирають до налаштування: від неї залежать пріоритети вузлів, кількість віртуальних адрес і те, як кластер поведеться при поверненні сервера, що вийшов з ладу, у стрій.
VRRP допускає кілька робочих розкладок, і різниця між ними — у тому, скільки вузлів реально несуть навантаження і наскільки передбачуване перемикання.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Активний і резервний вузол | Один сервіс, простий розбір інцидентів, простій резерву допустимий | Резервний вузол простоює; після відновлення основного адреса повернеться до нього лише при дозволеному поверненні володіння |
| Рівноправні вузли з різними пріоритетами | Пара серверів, де важливо швидко повернути адресу на штатний вузол | Пріоритет задається статично — при додаванні третього вузла схему перераховують вручну |
| Розподіл віртуальних адрес за вузлами | Кілька сервісів, потрібно задіяти обидва сервери | Кожен вузол стає основним для своєї групи адрес: конфігурацій і перевірок доступності вдвічі більше |
У будь-якому режимі працездатність вузла визначає не лише обмін службовими пакетами, а й перевірка доступності застосунку. Скрипт-перевірка знижує пріоритет вузла, якщо сервіс не відповідає, — віртуальна адреса переходить на живий сервер. Без неї Keepalived продовжує тримати адресу там, де процес вже впав, і перемикання не відбувається.
Етапи впровадження відмовостійкого кластера
Роботи йдуть від інвентаризації до передачі: спочатку фіксуємо, що реально працює в контурі, потім проєктуємо схему з резервом для кожного критичного сервісу і тільки потім чіпаємо бойові вузли.
Такий порядок виключає ситуацію, коли відмовостійкість вмикають для сервісів, чиї мережеві залежності не готові до резервування.
- Аудит інфраструктури — збираємо карту вузлів, мережевих сегментів і сервісів, позначаємо єдині точки відмови та зв’язки, які переживуть перенесення віртуальної адреси, а які ні.
- Схема резервування — визначаємо пари вузлів і ролі, розподіляємо пріоритети в Keepalived, обираємо режим повернення ролі та інтервали оголошень VRRP, щоб перемикання не спрацьовувало на коротких мережевих сплесках.
- Налаштування й перевірки доступності — пишемо конфігурацію та скрипти, які оцінюють стан самого сервісу, а не лише живучість хоста: інакше вузол із застосунком, що впав, продовжить утримувати віртуальну адресу.
- Перевірка перемикання на стенді — відтворюємо відмови: зупинка демона, розрив лінка, перезавантаження вузла, зависання сервісу. Вимірюємо час, за який резерв приймає адресу, і переконуємося, що сесії та черги не втрачаються.
- Виведення в бойовий контур — вмикаємо по одному сегменту з вікном спостереження, тримаємо попередній варіант конфігурації для швидкого відкату й відстежуємо стан таблиць сусідніх пристроїв.
- Передача регламентів — віддаємо схему адресації, конфігурації, сценарії ручного перемикання та порядок дій чергового при розділенні вузлів, щоб команда експлуатації керувала кластером без нас.
Конфігурації, схеми та регламенти перемикання
Інженерна частина послуги закінчується не запуском сервісу, а пакетом документів, за яким кластером можна керувати без нас.
Ми передаємо замовнику конфігурації Keepalived, схему мережі та регламенти — так чергова зміна розуміє, що відбувається, а новий інженер входить у проєкт за години, а не за тижні.
- Конфігурація кластера: файли обох вузлів із ролями «основна/резервна», ідентифікатором віртуального маршрутизатора, пріоритетами та інтервалами оголошення — з коментарями, чому виставлено саме так.
- Схема мережі: адреси вузлів і віртуальної адреси, підмережі, імена інтерфейсів, точки відмови й таблиця пріоритетів — на одному аркуші, а не зібрана по шматках.
- Перевірки живучості сервісу: скрипти, параметри запуску, пороги спрацьовування й поведінка при деградації вузла та при його повній відмові.
- Регламент перемикання: штатний сценарій, аварійний, ручне перемикання й повернення ролі назад — із зазначенням, хто ухвалює рішення.
- Інструкція для чергового: покрокові дії при втраті віртуальної адреси, зняття стану, збір логів і критерії, коли звати нас.
- Налаштування моніторингу: метрики стану вузлів, оповіщення на зміну ролі та зовнішня перевірка доступності сервісу — щоб відмову бачили до дзвінка користувачів.
- Протокол приймальних випробувань: сценарії відмов, які ми відтворили, і час відновлення за кожним — як доказ, що перемикання працює.
Окремим пунктом іде чек-лист змін: як правити конфігурацію, щоб не вивести обидва вузли з ладу однією дією.
Кейс: перемикання без втрати трафіку на бойовому контурі
Бойовий контур сервісу тримався на двох вузлах: точка входу жила на одному сервері, другий стояв гарячим резервом.
При відмові активного вузла віртуальну адресу піднімали вручну — черговий інженер отримував алерт, підключався до сервера й переналаштовував адресу, поки клієнти бачили помилки.
Точка відліку: заміри до впровадження
Спочатку ми зафіксували вихідний стан — розібрали статистику інцидентів і відтворили відмову на стенді з бойовими налаштуваннями. Вимірювали три величини: час перемикання, частку втрачених з’єднань і кількість ручних втручань.
Стенд дав ті самі цифри, що й бойовий контур: 8–14 хвилин на перемикання, до 6% обірваних з’єднань, 4–6 нічних викликів інженера на місяць.
Що змінили і що отримали
На обидва вузли поставили Keepalived у режимі VRRP: віртуальна адреса закріплена за активним вузлом, резервний відстежує сигнали й забирає адресу при їх зникненні. Пріоритети виставили так, щоб повернення після відновлення було керованим — без «смикання» трафіку туди-назад.
Окремо додали перевірку здоров’я застосунку: якщо сервіс живий, але не відповідає, адреса переїжджає, не чекаючи відмови заліза.
На приймальних випробуваннях перемикання вклалося в 1–2 секунди, частка втрачених з’єднань упала до часток відсотка, ручні втручання в зміні зникли. На бойовому контурі спочатку прогнали відмову кожного вузла окремо, потім — відмову обох із поверненням у стрій.
Чим Keepalived відрізняється від кластерного менеджера
Keepalived — це демон протоколу VRRP: він тримає віртуальну адресу на активному вузлі й переносить її на резервний, коли основний перестав відповідати. Перевірки доступності налаштовуються під конкретний сервіс — перевірка TCP-порту, HTTP-відповідь або наявність процесу.
Поки перевірка проходить, адреса залишається на поточному вузлі; перестала проходити — адреса переходить резервному вузлу, і клієнти продовжують працювати за тією ж адресою без правки конфігів.
Кластерний менеджер працює на іншому рівні. Він керує ресурсами: запускає й зупиняє служби в заданому порядку, підключає спільні диски, стежить за кворумом та ізолює вузол, що втратив зв’язок з іншими. Резервування адреси для нього — лише один із ресурсів, а не основне завдання.
Звідси й критерій вибору. Якщо застосунок вже вміє реплікуватися й стартує самостійно, а критично лише одне — щоб трафік ішов на живий вузол, достатньо резервування адреси й перевірок доступності.
Якщо потрібен керований життєвий цикл — підняти базу, дочекатися синхронізації, підключити спільний диск і тільки потім відкрити адресу, — без кластерного менеджера не обійтися.
На практиці їх не протиставляють. Демон VRRP відповідає за адресу й розподіл трафіку, кластерний менеджер — за ресурси; зв’язка дає швидкий перехід трафіку та коректний порядок запуску служб після перемикання.
Тому на етапі підбору інструмента ми дивимося на сам застосунок: скільки в нього станів, чи потрібен кворум, чи є спільний диск і чи обов’язковий строгий порядок старту. Від відповідей залежить, обійдемося ми одним демоном VRRP чи збираємо повний кластер з управлінням ресурсами.
Перевірки доступності, затримки та розділення мережі
Перевірка доступності сервісу в Keepalived — це не пінг адреси, а перевірка самої служби: локальний скрипт звертається до свого порту або віддає пробний запит і за відповіддю вирішує, чи живий вузол.
Поки перевірка проходить, вузол тримає адресу; при провалі — знімає й віддає партнеру. Поріг спрацьовування та інтервал підбирають так, щоб одинична затримка застосунку не викликала перемикання, інакше адреса буде «стрибати» на рівному місці.
Два активні вузли з’являються там, де службові повідомлення губляться в один бік: кожен вважає партнера мертвим і забирає адресу собі.
Захист — пріоритети, обов’язкове підтвердження зв’язку перед захопленням адреси та розділення мережі: службовий обмін іде окремим сегментом або адресною доставкою, а не широкомовно через прод-трафік.
Що відбувається з уже відкритими з’єднаннями при перемиканні?
Стан з’єднань живе на вузлі й не переїжджає разом з адресою. Клієнт отримує короткий збій і повторює запит, тому перемикання проєктують там, де повтори безпечні: ідемпотентні операції, балансувальник із спільною таблицею станів. Для довгих сесій заздалегідь описують повторний вхід користувача.
Як гарантовано не отримати два активні вузли?
Одних пріоритетів мало: вузол із більшою вагою має ще переконатися, що партнера справді немає. Тому додають затримку ввімкнення після старту, перевірку зв’язаності й окремий канал для службових повідомлень. У розділених сегментах це єдиний спосіб відрізнити втрату зв’язку від відмови вузла.
Як швидко вузол повертається в стрій?
Вузол піднімається сам, але адресу забирає не одразу — спочатку перевірки мають стабілізуватися, потім витримується пауза, щоб сервіс не смикався.
Повернення за пріоритетом можна відкласти до вікна робіт або вимкнути: тоді роль залишається в поточного активного вузла, а відновлений працює як резерв.
Обговоримо задачу: впровадження Keepalived під ваш контур
Перша розмова — це розбір вашого контуру, а не презентація. З’ясовуємо, скільки вузлів бере участь у відмовостійкій парі, які сервіси тримають віртуальну адресу, як розподіляється трафік і чи є вищий балансувальник.
Окремо проговорюємо вікна на зміни: чи можна перезапускати вузли вдень, чи є доступ до керування мережею та журналами.
Щоб оцінка була предметною, від вас потрібні вхідні дані: схема мережі, список сервісів за віртуальною адресою, вимоги щодо часу перемикання й режим обслуговування. Якщо документації немає — зберемо картину на дзвінку з вашими інженерами.
Після розбору надсилаємо:
- схему контуру з позначеними точками відмови й місцем, де стає Keepalived;
- план впровадження за етапами, з вікнами робіт і порядком відкату;
- склад робіт: налаштування VRRP, перевірки доступності сервісів, скрипти перемикання;
- перелік змін у конфігураціях і того, що потрібно від вашої сторони;
- сценарії перевірки: як переконаємося, що вузол справді перехоплює адресу;
- ролі та точки погодження на час робіт;
- оцінку за етапами — трудомісткість і залежності, без прив’язки до календарних дат.
Опишіть задачу в двох абзацах — повернемося з оцінкою та планом впровадження під ваш контур.
