Налаштування Floating IP: де мережа втрачає доступність
Поки адреса закріплена за конкретним вузлом, уся доступність сервісу тримається на ньому одному. Це класична єдина точка відмови: виходить з ладу обладнання, гіпервізор або мережевий інтерфейс — і сервіс зникає повністю, хоча другий вузол у схемі стоїть і простоює.
Клієнт у цей момент не отримує навіть зрозумілої помилки: запити йдуть у таймаут, і зовні це виглядає як «сайт ліг».
Найдорожче обходиться обрив з’єднань. Адресу не можна просто перевісити на інший вузол: уже встановлені сесії прив’язані до попереднього, і все, що йшло в момент відмови — вивантаження файлів, довгі транзакції, потоки даних, — рветься без можливості дослати залишок.
Якщо перемикання робиться лише через DNS, додається час життя кешу в резолверів: частина клієнтів ще хвилини стукає в неробочу машину, а частина — у нову, і картина розходиться.
Налаштування Floating IP знімає проблему тим, що адреса перестає належати конкретній машині. Keepalived тримає віртуальну адресу на провідному вузлі, стежить за станом сервісу і при відмові вузла переносить адресу на резервний — без правки DNS і без очікування кешів.
Деталі, які визначають результат: перевірка має дивитися на сам сервіс, а не на реакцію інтерфейсу; резервний вузол зобов’язаний коректно оголошувати адресу в мережі, інакше трафік піде в нікуди; при розділенні мережі можливі два провідні вузли одночасно, тому потрібен кворум або зовнішній арбітр.
Далі розбираємо, як це закривається на практиці.
Що дає відмовостійка адресація сервісу
Переносна адреса прибирає найдорожчий вид простою — той, що триває, доки інженер вручну переписує записи й чекає, поки зміни розійдуться по всіх вузлах. Відмову визначають за перевірками працездатності, і адреса переїжджає на резервний вузол за секунди, а не за хвилини. Для зовнішніх клієнтів це виглядає як поодинокі невдалі запити замість вікна недоступності.
Частка утриманих з’єднань залежить від того, де живе стан сервісу. Якщо сесії зберігаються на самому вузлі, частина довгих з’єднань під час перемикання обірветься — клієнт перепідключиться, але прогрес операції може загубитися.
Коли стан винесено на окремий шар, а вузли залишаються взаємозамінними, зміна вузла проходить непомітно: короткі запити її взагалі не помічають.
Головний ефект — зникає цілий клас відмов, пов’язаний із ручним перенесенням адреси. Помилка в записі, забута конфігурація на резервному вузлі, різні строки оновлення на різних серверах — усе це перестає бути джерелом аварій. Адресою керує автоматика за одним набором правил, а не черговий із пам’яті й у поспіху.
Швидкість перемикання стає передбачуваною й однаковою для аварії та для планових робіт. Оновлення, заміна вузла, правка конфігурації — трафік переводиться на резерв, роботи виконуються без вікна недоступності, потім адреса повертається назад. Це дозволяє призначати обслуговування в робочий час, а не вночі, коли найменше вільних рук.
Ефект перевіряється цифрами: час недоступності сервісу, частка успішних запитів у момент перемикання, кількість ручних операцій у чергового. Перші дві метрики порівнюються до й після — так підтверджується, що адресація справді відмовостійка, а не просто налаштована.
Режими відмовостійкості адрес: порівняння схем
Вибір схеми визначається не зручністю налаштування, а тим, що відбувається з вхідним трафіком у момент відмови: чи зберігаються встановлені сесії, за скільки секунд сходиться маршрутизація і скільки адрес доведеться анонсувати. Нижче — варіанти, між якими реально обирають, з їхніми обмеженнями.
| Схема | Коли підходить | Обмеження схеми |
|---|---|---|
| Активно-пасивна з перенесенням адреси (VRRP, keepalived) | Один вузол тримає навантаження, другий у гарячому резерві; потрібні мінімальні зміни інфраструктури | Резервний вузол простоює; короткий розрив під час перевиборів; обов’язковий захист від розщеплення стану між вузлами |
| Активно-активна зі спільною адресою | Кілька майданчиків, чутливість до затримки, вимога непомітної відмови | Складніша конфігурація анонсів і налагодження асиметричних маршрутів; помилка в налаштуваннях б’є по всіх майданчиках одразу |
| Плаваюча адреса засобами хмари (перемикання через API) | Сервіс в одному регіоні, перемикання за сигналом моніторингу | Залежність від хмарного API; автоматика збирається вручну; перемикання займає десятки секунд |
| Перемикання на рівні DNS | Резервні майданчики, де швидка відмова не критична | Затримка через кеш резолверів; вже встановлені з’єднання не рятує |
Ключова метрика в усіх схем одна: скільки секунд вхідний трафік іде в нікуди й скільки сесій при цьому розривається.
В активно-пасивній схемі адреса переноситься за секунди, але вузьке місце — час виявлення відмови; в активно-активній відмова майже непомітна, зате зростає ціна помилки в конфігурації.
Тому перед вибором фіксуємо профіль навантаження: частка довгих з’єднань, допустимий простій, вимоги до географії. Далі підбираємо схему й перевіряємо її відмовою на стенді, а не на папері.
Етапи впровадження відмовостійкої адресації
Віртуальна адреса — єдина точка входу для всього трафіку, і помилка в ній валить сервіс повністю, а не окремий вузол. Тому роботу ведемо у фіксованому порядку: спочатку фіксуємо поточний стан мережі, потім проєктуємо ролі адрес, і лише після цього змінюємо правила перемикання. Так конфлікт адрес випливає на етапі схеми, а не в момент аварії.
- Аудит мережі. Збираємо карту сегментів, шлюзів і маршрутів, дивимося, де адреси видаються статично, а де автоматично, шукаємо перетини підмереж. На виході — перелік вільних адрес і тих, що вже закріплені за обладнанням.
- Схема адресації. Розмічаємо ролі: яка адреса обслуговує застосунок, яка залишається службовою, яку тримаємо резервною, і хто власник кожної. Схема знімає головний ризик — подвійне володіння адресою, коли обидва вузли вважають себе активними.
- Налаштування перемикання. Задаємо перевірки доступності, пріоритети вузлів і час, за який адреса переїжджає. Окремо прописуємо поведінку при частковій відмові — вузол відповідає, а застосунок на ньому вже не працює.
- Перевірка під навантаженням. Прогоняємо не лише зупинку вузла, а й обрив каналу, втрату зв’язку між вузлами та плановий перезапуск. Дивимося, скільки займає переїзд адреси і чи рвуться при цьому живі з’єднання.
- Передача в експлуатацію. Віддаємо схему адрес, конфігурації, порядок ручного перемикання і правила повернення адреси на основний вузол. Чергова зміна отримує не «чорну скриньку», а зрозумілу процедуру.
Порядок однаковий для хмарної платформи і власного обладнання — змінюється лише те, де фізично живе адреса. Перед введенням у роботу прогоняємо сценарії відмови повторно, вже на бойовому контурі.
Політики адресації та конфігурації в інфраструктурі
Відмовостійкість тримається не на самому факті наявності другої адреси, а на тому, чи відтворювана його конфігурація. Ми фіксуємо кожен елемент так, щоб перемикання не залежало від того, хто з інженерів у цей момент на чергуванні. Комплект потрапляє до вашого репозиторію й залишається робочим при додаванні нових вузлів і зон.
- Конфігурації адрес: прив'язка Floating IP до інтерфейсів, пріоритети вузлів, інтервали перевірки доступності та поведінка при поверненні вузла до роботи — з поясненням, які параметри змінюються під час масштабування.
- Схема потоків: шлях зовнішнього трафіку до серверів застосунків, точки відмови, момент, коли віртуальна адреса переміщується на резервний вузол, і як поводяться вже встановлені з'єднання.
- Правила доступу: мережеві політики, дозволені джерела для службового трафіку, порядок надання прав черговому та заборона на ручні правки в обхід репозиторію.
- Регламент перевірки: сценарій планового перемикання з очікуваним часом, набір команд підтвердження та критерій, за яким черговий вважає переведення трафіку успішним.
- Регламент відновлення: дії при розщепленні адреси між двома вузлами, порядок повернення трафіку до вихідної зони та межі, за якими підключається наша команда.
- Документація: паспорт сервісу з власниками, історія змін адресації, схема розміщення вузлів і залежності від зовнішніх мереж.
Комплект переглядається на планових навчаннях: якщо перемикання не вкладається в узгоджений час, правимо конфігурацію, а не інструкцію.
Перемикання адреси між вузлами: результати до і після
Сервіс на двох вузлах за балансувальником: до налаштування плаваючої адреси відмова будь-якої машини означала ручне втручання. Адреса залишалася на недоступному вузлі, запити клієнтів завершувалися помилками, черговий змінював запис DNS і чекав оновлення кешів у резолверів. Про збій частіше дізнавалися від користувачів, а не з моніторингу.
Як було до впровадження
Час відновлення доступу — 9–14 хвилин на інцидент: близько хвилини на саме перемикання, решта — на очікування кешів. Активні з'єднання під час відмови втрачалися повністю, тривалі сесії доводилося починати заново.
Перевірку на відмову проводили рідко, тому реальний сценарій перемикання залишався неперевіреним до першого серйозного збою.
Що стало після
Плаваючу адресу закріпили на парі вузлів і пов'язали з перевіркою прикладного стану через keepalived: поки вузол відповідає на службовий запит, адреса залишається на ньому, а таблиця з'єднань синхронізується між машинами.
Під час відмови адреса переходить на резервний вузол за 3–5 секунд, утримувані з'єднання переживають перемикання, частка запитів з помилкою в цей момент — нижче 0,5%.
Перевірку на відмову зробили регулярною: вузол вимикають у робочий час, фіксують час перемикання та втрати запитів, потім повертають до ладу.
Недоступність за квартал скоротилася з годин до одиничних секунд, ручні дії чергового зі сценарію зникли — залишився розбір звіту після навчань.
Чим Floating IP відрізняється від Virtual IP?
Floating IP і Virtual IP розв’язують одне завдання — дати сервісу адресу, яка переживе падіння вузла, — але природа в них різна.
Floating IP належить платформі або провайдеру: він не «прилипає» до машини, а прив’язується до мережевого інтерфейсу за командою, і під час перенесення трафік на новий вузол спрямовує зовнішня маршрутизація.
Virtual IP живе всередині вашої інфраструктури: та сама адреса піднімається на кількох вузлах, а активним її тримає обраний лідер — на практиці це Keepalived або аналогічний демон, який піднімає адресу на інтерфейсі та анонсує її в мережі.
Звідси розходяться сценарії застосування. Floating IP беруть там, де потрібна публічна вхідна точка: зовнішній балансувальник, зворотний проксі, вузол для адміністрування — адреса переприв’язується до резервного екземпляра, і клієнти не помічають зміни.
Virtual IP ставлять усередині: відмовостійкий шлюз, пара серверів бази даних, кластер застосунків, де важлива одна адреса для групи вузлів і перемикання за секунди.
Відрізняються й вимоги до мережі. Floating IP спирається на можливості платформи перенаправити трафік на інший вузол, тому критичні межі підмережі, коректна робота маршрутизації та відсутність жорстких прив’язок до адреси на боці firewall.
Virtual IP вимагає, щоб вузли були сусідами в одному широкомовному домені: потрібен дозволений обмін службовими пакетами вибору лідера, вільна передача ARP і можливість вузла відповідати на чужу адресу.
У хмарних мережах ці умови виконуються не завжди — тоді залишається Floating IP або керований балансувальник.
На етапі проєктування ми перевіряємо три речі: де фізична точка відмови — у провайдера чи в кластері, хто утримує адресу в момент аварії та скільки триває перемикання, і як поводиться стан сесій після зміни вузла.
Часто-густо обирають комбінацію: Virtual IP усередині для швидкого перемикання, Floating IP або балансувальник зовні для публічного доступу. Далі розбираємо, як це збирається під конкретну схему.
Технічні питання щодо налаштування та експлуатації
Інженерні сумніви на етапі впровадження майже завжди ті самі: як поводитимуться вже встановлені з’єднання, чи потрібен другий вузол, як переконатися в перемиканні, не чекаючи реальної аварії. Нижче — короткі відповіді щодо кожного.
Що відбувається з активними з’єднаннями під час перемикання?
Адреса переїжджає за секунди, але відкриті сесії на старому вузлі не продовжуються — таблиця з’єднань між вузлами не синхронізується. Тому критичні сервіси проєктують із короткими таймаутами й повторюваними запитами, а довгі транзакції виносять на рівень застосунку.
Чи можна обійтися без другого вузла? Сам по собі плаваючий адрес доступність не підвищує: якщо резервного вузла немає, перемикати його нікуди. Другий вузол при цьому може бути слабшим — у режимі очікування він лише утримує адресу й опитує сервіс перевіркою живучості.
Як перевірити перемикання під навантаженням? Прогін із бойовим профілем трафіку: тримаємо з’єднання, гасимо активний вузол, заміряємо паузу й частку невдалих запитів.
Окремо дивимося, що адреса оголосилася в мережі рівно один раз і не виникло двох власників одночасно — розщеплення кластера небезпечніше за короткий простій.
Хто керує адресою під час експлуатації? Прив’язку тримаємо в описі інфраструктури, а не в панелі провайдера: тоді адреса відтворювано переїжджає під час перестворення вузла, а зміна власника не залежить від ручних дій чергового.
Обговоримо завдання і повернемося з оцінкою та планом
Щоб повернутися з оцінкою робіт, нам потрібно зрозуміти топологію: де зараз точка відмови, хто утримує адресу і як сервіси дізнаються про перемикання. Налаштування Floating IP майже завжди впирається не в саму адресу, а в поведінку прикладного шару після зміни вузла.
На першій розмові розбираємо це — і вже на її основі віддаємо план впровадження зі складом робіт і термінами.
Обговоримо завдання — на зустрічі уточнюємо:
- скільки вузлів і сервісів мають переживати відмову і як між ними розподіляється трафік;
- як влаштована адресація зараз: пули адрес, підмережі, шлюзи, обмеження майданчика або хмари;
- хто утримуватиме адресу — зовнішній балансувальник, агент на вузлах або керована служба, і що вже розгорнуто;
- чим перевіряється живучість сервісу і скільки секунд недоступності допустимо під час перемикання;
- чи потрібне автоматичне повернення адреси на основний вузол і як це вплине на активні з’єднання;
- вимоги до відкату конфігурації та регламент доступу інженерів до середовища;
- формат роботи: проєктування й налаштування разово або супровід після введення в бій.
У відповідь надсилаємо склад робіт за етапами, терміни, схему розміщення адрес і перелік перевірок перед виведенням у бій. Опишіть завдання і поточну схему мережі — повернемося з оцінкою та планом.
