Налаштування Hetzner Cloud Load Balancer: де рветься відмовостійкість
Типова картина: один віртуальний сервер приймає весь трафік, домен вказує прямо на нього, а другий вузол якщо й існує, то простоює.
Налаштування балансувальника навантаження в такій схемі не виконувалося — його замінюють ручні дії, а єдина точка відмови залишається непоміченою до першої аварії.
Ціна вимірюється не в хвилинах простою, а в незакритих операціях. При відмові вузла частина запитів уже прийнята, але не оброблена: клієнт бачить таймаут, оплата не проходить, надіслана форма зникає. Ручне перемикання трафіку додає до цього час реакції чергового.
З'ясовується це тільки в момент аварії, тому що до неї відмовостійкість сервісу ніхто не вимірював. Немає перевірок працездатності, які знімають вузол з ротації, немає автоматичного перенесення трафіку на живий сервер, немає обмеження на кількість з'єднань до одного вузла.
Зовні система при цьому виглядає здоровою: графіки рівні, затримки в нормі, вільні ресурси є. Проблема в тому, що запас міцності не перевіряється заздалегідь — він проявляється в єдиний момент, коли перевірити його вже не можна.
Розбираємо, як це закривається: розподіл трафіку між кількома вузлами, перевірки працездатності з осмисленими інтервалами та порогом спрацьовування, поведінка відкритих сесій при виведенні сервера з ротації. Далі — що дає керований балансувальник рівня хмари, включаючи Hetzner Cloud.
Вимірюваний ефект: час відновлення, простої, відмовостійкість
Після грамотно зібраної схеми змінюється не відчуття надійності, а конкретні величини. Перевірка доступності вузла йде автоматично кожні кілька секунд: дві невдалі відповіді підряд — і вузол виведено з ротації, трафік іде на живі. Ручне втручання при падінні сервісу більше не потрібне, Hetzner Cloud реагує сам.
На піку втрачаються тільки ті запити, що вже були в обробці на впавшому вузлі. Нові запити балансувальник відправляє на живі сервери відразу, тому сплеск помилок обмежений частками секунди і не перетворюється на відмову всього напрямку.
Що варто звірити у звіті після здачі:
- Час відновлення — виключення вузла вкладається в секунди, а не в десятки хвилин ручних правок і перезапусків.
- Простий сервісу — планове оновлення йде по одному серверу, доступність не обнуляється ні на хвилину.
- Втрачені запити — частка помилок на піку падає з десятих часток відсотка до коротких сплесків у пару секунд.
- Плавне перемикання — активні з'єднання та сесії не рвуться, користувач не бачить перезавантаження.
- Усунений клас відмов — падіння одиночного сервера перестає бути інцидентом і не вимагає авралу.
- Перевірка боєм — гасимо вузол під навантаженням і дивимося, куди пішли запити і скільки помилок побачили клієнти.
Режими балансування та перевірки стану: що і коли підходить
Вибір схеми визначається двома питаннями: що балансувальник бачить у трафіку і як він розуміє, що вузол живий. Балансування на рівні з'єднань розподіляє потоки між вузлами, не розбираючи вміст запитів, — воно дешевше за ресурсами і залишає шифрування на стороні додатка.
Балансування на рівні запитів бачить адресу, заголовки та код відповіді: вміє розводити трафік по шляхах, утримувати сесії та завершувати шифрування на собі.
Розміщення перед кластером дає єдину публічну точку входу, розміщення всередині мережі розділяє шари і приховує внутрішні сервіси від зовнішнього сканування.
Стандартна перевірка стану по порту підтверджує лише те, що процес приймає з'єднання, — додаток при цьому може віддавати помилки користувачеві.
Тому перевірку налаштовують за відповіддю прикладної адреси: код відповіді, час відгуку та кількість спроб визначають, коли вузол виводять з ротації і коли повертають назад.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| За з'єднаннями | Довгі сесії, бази даних, свої обробники шифрування | Не бачить шлях і заголовки, немає маршрутизації за адресами |
| За запитами | Веб-сервіси та API, правила за шляхами та заголовками | Вище навантаження на балансувальник, залежить від коректних заголовків клієнта |
| Перед кластером | Єдина точка входу, прийом шифрованого трафіку ззовні | Публічна адреса вимагає обмежень за частотою та списками доступу |
| Всередині мережі | Внутрішні сервіси, розділення шарів | Немає прямого доступу ззовні, потрібен зовнішній вхід або шлюз |
Пороги перевірок задають поведінку кластера: занадто агресивні дають хибні виключення і «блимаючу» ротацію, занадто м'які затягують виведення впавшого вузла.
Обмеження схеми проявляються і в дрібницях — завершення шифрування на балансувальнику перекладає на нього роботу з сертифікатами, а балансування за з'єднаннями не дає маршрутизації за шляхами.
На практиці варіанти комбінують: зовнішній шар приймає трафік, внутрішній розподіляє його по сервісах.
Порядок впровадження: від аудиту схеми до передачі в експлуатацію
Роботу починаємо з фіксації поточного стану, а не з установки балансувальника: помилка в схемі проявляється не в момент налаштування, а під реальним трафіком, коли перемикання між вузлами вже має працювати.
Тому спочатку знімаємо фактичну картину, потім проектуємо контур і тільки після цього змінюємо те, що обслуговує користувачів.
- Аудит інфраструктури. Збираємо поточну схему: які сервіси опубліковані назовні, як розподіляються адреси, де лежать сертифікати і як зараз перевіряється доступність вузлів. Окремо виписуємо точки відмови — одиночний вузол без резерву, ручні перемикання, відсутність контролю стану серверів додатків.
- Проектування схеми балансування. Визначаємо розміщення балансувальника щодо зон, склад цільових груп, алгоритм розподілу, інтервали та пороги перевірок стану, поведінку при відмові вузла. Тут же вирішуємо, де обробляється захищений трафік і які правила переадресації потрібні.
- Підготовка мережі та доступів. Приватні мережі, правила фільтрації, права інженерів і системи моніторингу — все закриваємо до того, як піде бойовий трафік.
- Конфігурація контуру. Налаштовуємо Hetzner Cloud Load Balancer, цільові групи, перевірки стану, сертифікати та журналювання. Конфігурація зберігається як код: зміна проходить перевірку і відкочується однією операцією.
- Перевірка під навантаженням. Проганяємо сценарії зростання одночасних з'єднань, відмови одного вузла, деградації сервісу та сплеску трафіку. Дивимося, за який час розподіл перебудовується і як поводяться затримки.
- Введення в експлуатацію. Перемикаємо трафік поетапно, з можливістю повернутися на попередню схему. Метрики затримок і помилок знімаємо до і після — щоб бачити ефект, а не припускати його.
- Передача документації. Віддаємо схему, інструкцію з експлуатації та відкату, опис алертів і порядок дій при відмові, щоб інженер замовника міг розібрати інцидент без нас.
Після передачі короткий супровід: розбираємо питання щодо конфігурації та допомагаємо зі змінами, поки команда не почне працювати з контуром самостійно.
Конфігурації, правила перевірок та документація на передачу
Здача — це не демонстрація працюючої панелі, а відтворюваний набір артефактів, який залишається у вашої команди.
Нижче — що саме передаємо по балансувальнику Hetzner: конфігурацію, правила перевірок, схему мережі, доступи та регламент на випадок аварії, — і як цим користуватися без нас.
- Конфігурація балансувальника в декларативному вигляді, у вашому репозиторії: правила маршрутизації, цільові групи, ліміти підключень. Зміна проходить рев'ю і розгортається однією командою, а не правкою в панелі.
- Правила перевірки стану сервісів: шлях, інтервал, поріг невдалих спроб, таймаут. Поруч — обґрунтування значень під ваш профіль трафіку: за який час вузол виводиться з ротації і чому саме за такий.
- Схема мережі: приватний сегмент, підмережі, зони доступності, точки входу, зв'язки балансувальника з серверами додатків і базою. На ній видно, що відкрито ззовні, а що закрито.
- Права доступу та мережеві правила: ролі інженерів, доступ за ключами, ізоляція контуру збірки від промислового. Зрозуміло, хто і що може змінювати і де це фіксується.
- Регламент експлуатації та дій при аварії: як вивести вузол з балансування, як відкотити конфігурацію до попередньої, в якій послідовності діяти і кого підключати.
- Моніторинг: метрики за затримками, часткою помилок і кількістю живих вузлів з порогами спрацьовування. Повідомлення приходить раніше, ніж скарга користувача.
Кейс: прибрали просідання при відмові вузла та ручні перемикання
Як було до робіт
У замовника — два хмарних сервери, трафік між ними розподілявся на рівні DNS з коротким терміном життя запису.
При відмові вузла частина клієнтів продовжувала звертатися до мертвої адреси: термін життя запису спливає не миттєво, а кеші проміжних резолверів тримають стару адресу хвилинами.
Черговий дізнавався про проблему зі скарг, піднімав заміну і вручну правив записи — 6-8 операцій за інцидент і до 20 хвилин просідання під навантаженням.
Що змінювали
Точку входу перенесли з DNS на Hetzner Cloud Load Balancer, вузли оголосили в цільову групу і налаштували перевірки здоров'я за прикладним обробником, а не за відкритим портом.
Поріг — дві невдалі перевірки підряд, виведення вузла з ротації до зупинки сервісу, щоб активні з'єднання доходили до кінця. Додали шаблон розгортання нового вузла і автоматичне підключення його до групи.
Що стало
- Перемикання при відмові вузла — 12-15 секунд замість 20 хвилин і без участі людини.
- Частка успішних запитів у момент інциденту — 99,9% проти 96%; обривів користувацьких сесій на перемиканні не залишилося.
- Ручних операцій чергового на інцидент — нуль замість 6-8: алерт приходить, коли ротація вже виконана.
Хмарний балансувальник або свій сервер з балансуванням: що вибрати
Вибір зводиться до одного питання: хто тримає шар балансування в робочому стані — ми чи ви.
Керований балансувальник Hetzner Cloud — це готовий ресурс з перевірками доступності, цільовими групами, термінацією шифрування та автоматичним виведенням упавшого сервера з ротації: налаштування займає години, а масштабування зводиться до додавання вузлів у групу.
Обмежень два. Політика маршрутизації фіксована провайдером — своїх правил за заголовками або складної логіки відмов там не виразити.
Діагностика впирається в доступні метрики: коли запити «пропадають» між балансувальником і додатком, розбиратися доводиться побічно, за логами бекенду.
Свій вузол балансування дає повний контроль: довільні схеми маршрутизації, власні перевірки, тонке налаштування таймаутів і черг, можливість зняти дамп трафіку в момент збою.
Плата — постійний супровід: оновлення, ротація сертифікатів, відмовостійка пара вузлів і зовнішній спостерігач, який підніме другий, якщо перший впаде.
Зона відповідальності — головний вододіл. У керованого сервісу відмову платформи закриває провайдер, але за конфігурацію цільових груп, коректність перевірок і порядок викату відповідаємо ми.
У свого вузла в нашу зону потрапляє все: додаток, балансування і доступність вхідної точки. Цю межу ми фіксуємо в документації до початку робіт, щоб на розборі інциденту не шукати винного.
Практичний критерій простий: якщо схема маршрутизації вкладається у штатні можливості керованого балансувальника, свій вузол — зайві трудовитрати на супровід без виграшу в надійності. Свій ставимо тоді, коли є вимоги, які платформою не виразити. Опишіть вашу схему трафіку — повернемося з оцінкою та планом.
Технічні сумніви: перевірки, ліміти, переїзд без простою
Перед стартом інженер зазвичай перевіряє три речі: як налаштовані перевірки живості, що з лімітами за одночасними з'єднаннями і чи можна перемкнути працюючий проект без вікна обслуговування.
Від цих рішень залежить схема відмовостійкості, тому в контурі Hetzner Cloud ми проговорюємо їх до робіт, а не після.
Як налаштовується перевірка живості вузла?
Шлях перевірки, інтервал опитування, таймаут відповіді та кількість допустимих невдач підряд — це параметри, а не константи. Балансувальник уводить вузол з ротації після серії невдалих відповідей і повертає, коли перевірка знову проходить.
Занадто агресивні пороги дають хибні спрацьовування на сплесках, занадто м'які — довше тримають трафік на проблемному вузлі. Калібруємо за профілем навантаження.
Що з лімітами за з'єднаннями?
На кожен цільовий сервер задається межа одночасних з'єднань: за її границею нові запити не відкриваються, навіть якщо вузол живий. Запас вважаємо від реального профілю — при постійних з'єднаннях канал зайнятий довше, ніж при коротких запитах.
Якщо впираєтесь у межу, додаємо вузли в пул або піднімаємо ліміт: перший шлях стійкіший, другий швидший.
Чи можна переїхати без простою?
Так: піднімаємо балансувальник у новому контурі, вводимо вузли в пул і чекаємо, поки перевірки підтвердять готовність, — тільки потім перемикаємо трафік. Запис домену переводимо із заздалегідь зниженим кешуванням, сертифікат на нову адресу виписуємо до цього моменту. Старий контур залишається в резерві, відкат — повернення запису, а не відновлення з копій.
Обговоримо задачу і повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою робіт, а не із загальними словами, нам достатньо однієї розмови та вивантаження поточної конфігурації. Нижче — що ми запитуємо на вході і що віддаємо на виході; з вашого боку це не створює зобов'язань.
- Вихідні дані. Список сервісів за балансувальником, їх порти та протоколи, домени, вимоги до TLS, очікуване та пікове навантаження — цього достатньо, щоб зрозуміти обсяг.
- Доступи для розбору. Читання проекту в хмарі або експорт конфігурації: правила міжмережевого екрана, приватні мережі, цільові групи, параметри перевірок доступності.
- Розбір поточної схеми. Показуємо, як трафік іде зараз, де точка відмови, чому не можна підняти другу копію сервісу без ручної правки адрес.
- Перелік ризиків. Окремим списком: обрив з'єднань при деплої, відсутність відкату, відкриті назовні порти, терміни життя сертифікатів, один вузол додатка.
- План впровадження. За кроками: мережа та цільові групи, перевірки доступності, TLS-термінація, перемикання трафіку, перевірка під навантаженням, регламент відкату.
- Терміни робіт. Оцінка за етапами та загальний термін: базове налаштування під ключ вкладається в один робочий день, перенесення живого трафіку — окремим пунктом з вікном.
- Що залишається у вас. Конфігурації, схема проходження трафіку, чек-лист перемикання та набір метрик, за якими видно стан балансувальника.
