Налаштування балансування навантаження через HAProxy: конфігурація та моніторинг

Чому штатне налаштування HAProxy ламається під навантаженням

Штатне налаштування HAProxy — це набір значень за замовчуванням, яких вистачає на стенді й не вистачає на піку.

Перше вузьке місце — не задані явно таймаути з'єднань: поки клієнт утримує неактивне з'єднання, а сервер застосунків відповідає довше за звичайне, слоти обробки закінчуються раніше, ніж трафік.

Черга зростає, час відповіді збільшується лавиноподібно, і балансування навантаження починає розподіляти вже не запити, а затримки.

Відсутність перевірок стану вузлів — друга міна. За замовчуванням балансувальник нерідко перевіряє лише доступність порту: застосунок може віддавати помилки, але залишатися в ротації й отримувати свою частку трафіку.

Один деградований вузол тягне вниз весь пул, а проблему виявляють за скаргами користувачів, а не за метриками.

Третє — єдиний вхід у систему як точка відмови. Один процес, одна адреса, ручне редагування конфігурації: оновлення або перезапуск означають розрив активних сесій, а відмова самого балансувальника кладе весь сервіс.

Статистика при цьому не знімається, тому розбір інциденту відбувається вже після нього, за логами застосунків.

Розбираємо, як це закривається: явні таймаути під профіль трафіку, перевірки стану за прикладним відгуком, резервування входу й моніторинг, який показує деградацію до того, як вона стане відмовою.

Що змінюється після переробки конфігурації та вмикання моніторингу

Що змінюємо в конфігурації, видно за трьома метриками: час відгуку на піку, частка помилкових відповідей і час, за який система повертається до норми після падіння вузла.

На піку трафік перестає впиратися в один сервер: алгоритм балансування обирає вузол за кількістю активних з'єднань, а не по колу, кількість одночасних сесій на кожен вузол обмежена, а з'єднання до застосунків перевикористовуються замість відкриття нового на кожен запит.

Таймаути виставлені за фактичним розподілом часу обробки, тому повільний, але живий вузол встигає відповісти, а не обривається раніше строку, і черга на вході не зростає лавиноподібно.

HAProxy тримає окрему перевірку здоров'я для кожного вузла: інтервал, поріг послідовних невдач і умови повернення в ротацію.

Це закриває клас відмов, який до переробки був основним джерелом 5xx — деградований вузол, який відповідає, але повільно, продовжував отримувати свою частку трафіку й псував відповіді частині користувачів.

Тепер вузол виводиться з ротації до того, як почне віддавати помилки, повтор надсилається лише на безпечні для повтору запити, а решта отримують явну відповідь замість підвішеного з'єднання.

Час відновлення після падіння вузла задається інтервалом перевірки й порогом невдач — це настроювана величина, а не наслідок удачі.

Назад у ротацію вузол входить плавно: спочатку отримує невелику частку трафіку, і тільки якщо час відгуку тримається в нормі, повертається до повної. Резервний вузол вмикається в роботу, коли основний пул деградував цілком, тому сплеск відмов не перетворюється на повний простій.

Моніторинг навантаження спирається на журнали доступу й лічильники: час обробки за кожним запитом, розподіл трафіку між вузлами, частка помилок, очікування в черзі, стан кожного сервера.

З цих даних видно, деградував конкретний вузол чи зріс загальний трафік, і оповіщення виставляються від спостережуваного профілю навантаження, а не на око.

Через кілька діб після вмикання стає зрозуміло, які пороги стали зайвими, а де потрібен запас — конфігурація уточнюється за фактом, а не за припущеннями.

HAProxy налаштування: варіанти балансування та їхні обмеження

Схема балансування — це не одна директива, а набір: алгоритм розподілу, перевірки стану, резервний контур і точка входу. Помилка на будь-якому рівні виглядає однаково — частина запитів іде на неробочий вузол і висить там до закінчення очікування.

Чотири схеми та їхні межі

Перед вибором перевіряємо три речі: за скільки секунд вузол виводиться з ротації, що відбувається за відмови самого балансувальника і де живе стан сесії.

Якщо сесії липкі, а вузол іде — користувач втрачає кошик; якщо перевірка дивиться лише на відкритий порт, деградація залишається невидимою. Схему підбираємо під профіль трафіку, а не за замовчуванням.

Як проходить впровадження: від розбору схеми до передачі

Порядок робіт однаковий і для нового впровадження, і для перебудови балансувальника, що вже працює: спочатку фіксуємо фактичний стан, потім збираємо цільову схему й перевіряємо її в тестовому контурі, і лише після цього чіпаємо робочий контур. Вартість розраховується після аудиту.

1. Аудит інфраструктури. Знімаємо карту сервісів, адрес і портів, дивимося, де стоїть балансувальник відносно периметра й захисту. Розбираємо статистику та логи: де губляться запити, як живе сесія, які правки вносилися на серверах руками.
2. Цільова схема. Вирішуємо, що балансується на рівні з'єднання, а що потребує розбору заголовків, як розподіляється навантаження, де зберігається стан сесії. Схему узгоджуємо до першого рядка конфігурації.
3. Конфігурація на стенді. Розгортаємо HAProxy у тестовому контурі з тими самими ролями серверів. Тут же налаштовуємо збирання статистики, логи й обмеження частоти звернень.
4. Перевірка під навантаженням. Проганяємо профіль, близький до пікового: час відповіді, розподіл за серверами, поведінка за зростання кількості з'єднань і повільних клієнтів. Правки вносимо, поки стенд, а не користувачі.
5. Випробування відмовами. По черзі виводимо сервери з ладу, перевіряємо роботу перевірок доступності та самостійне повернення вузла в стрій. Тут же фіксуємо сценарій відкату змін.
6. Переведення трафіку. Перемикаємо поетапно: спочатку частка запитів, потім весь потік, зі спостереженням за помилками й затримками. Якщо метрики виходять за межі, відкат займає хвилини.
7. Передача черговій зміні. Віддаємо схему, конфігурацію, порядок типових операцій і розбір інцидентів. Черговий інженер разом з нашим проходить перезавантаження конфігурації й навчальний збій.

Що залишається у вас: конфігурації, схеми, регламенти

Балансувальник залишається у вашому контурі, а отже, все потрібне для його роботи й правок має залишитися у вашої команди, а не в листуванні з нами.

Тому здаємо не «файли на пам'ять», а комплект артефактів, за яким черговий інженер без нашої допомоги підніме контур, змінить маршрут і відкотить невдалу правку.

Кожен документ пишемо під людину, яка бачить систему вперше: де дивитися, що перевірити після зміни, на який сигнал реагувати першим.

• Робочі конфігурації — файли HAProxy за всіма середовищами, з коментарями до неочевидних рішень: чому вибрано такий час очікування відповіді, як розподіляються черги, що зарезервовано під пікові навантаження.
• Схема потоків — звідки приходить трафік, де завершується шифрування, які вузли стоять за балансувальником і які місця залишаються точками відмови. Відновлення картини займає хвилини, а не години розбору логів.
• Політики доступу — правила, хто і з яких адрес потрапляє в панель керування й статистику, як обмежені зміни на бойовому контурі та хто має право їх підтверджувати.
• Інструкція з відкату — покрокове повернення попередньої конфігурації однією операцією, список перевірок після повернення й порядок дій, якщо відкат не допоміг.
• Версіонування змін — конфігурації в системі контролю версій, кожна правка окремим набором з описом: видно, хто, коли й навіщо змінив маршрут або правило.
• Регламент моніторингу — які показники знімаємо, за яких порогів приходить оповіщення, куди воно йде й хто чергує.
• Порядок передачі — облікові записи, ролі та права видаються вашим людям, наші доступи закриваються одразу після здачі.

Кейс: перевели трафік на резервний контур без простою

До робіт вхідний трафік обслуговував один вузол балансування: на ньому сходилися термінація шифрованого трафіку, прив'язка клієнтських сесій до конкретного сервера й перевірки доступності бекендів.

Будь-яке планове оновлення конфігурації означало перезапуск процесу — за логами це давало до 400 перерваних сесій за вікно обслуговування й сплеск відповідей 502 на вході. Резервний контур існував, але перемикалися на нього вручну й лише в аварійному порядку.

Ми перевели вхід на пару вузлів HAProxy зі спільною плаваючою адресою: конфігурація збирається з одного джерела й розкочується цілком, а безшовне перезавантаження передає слухаючі сокети новому процесу, не розриваючи вже встановлені з'єднання.

Прив'язку сесій прибрали — стан винесли в спільне сховище, тому запит обслуговує будь-який вузол. Перемиканням між контурами тепер керують перевірки доступності, а не черговий інженер.

Що показали заміри

Перевіряли двома способами: прогоном профілю навантаження, знятого з бойового трафіку, і контрольованим вимкненням вузла в робочі години. Медіана часу відгуку на вході скоротилася майже втричі, частка відповідей довше секунди впала з 7% до 0,3%, а відповіді 5xx — з 2,4% до 0,02%.

Перерваних сесій під час обслуговування більше немає: перемикання на резервний контур укладається в один інтервал перевірки, і користувач його не помічає. Зворотне переведення контуру — та сама операція з тим самим результатом.

Чим відрізняється мережевий балансувальник від прикладного?

Мережевий рівень працює з потоком з'єднань: балансувальник бачить адресу й порт, обирає сервер за алгоритмом і далі в трафік не втручається. Вміст пакетів не розбирається, тому затримка мінімальна, а поведінка однакова для HTTP, СУБД і довготривалих з'єднань.

Обмеження одне: одиниця балансування — з'єднання цілком, і якщо клієнт тримає один канал, різні типи запитів усередині нього за призначенням не розвести.

Прикладний рівень розбирає прикладний протокол і бачить метод, шлях, заголовки, cookie. Звідси маршрутизація запитів: статику віддає один пул серверів, API — другий, службові адреси — третій, і правила змінюються на вході без правок на самих серверах.

Там же працює прив'язка сесії за cookie і точна перевірка доступності: вузол, що відповідає помилкою на службовій адресі, виводиться з ротації, хоча на мережевому рівні виглядав би живим.

Завершення шифрування — окреме рішення зі своєю ціною. Коли шифр знімається на вході, сертифікати й параметри з'єднання живуть в одному місці, внутрішні сервіси отримують відкритий трафік, а правила маршрутизації бачать вміст цілком.

Наскрізне шифрування до сервера залишає трафік закритим для балансувальника, але маршрутизація тоді йде лише за метаданими, а оновлення сертифікатів лягає на кожен вузол.

На практиці режими співіснують: HAProxy веде частину сервісів на мережевому рівні, а HTTP-навантаження — на прикладному, і режим задається для кожного пулу серверів окремо.

Часті технічні сумніви перед стартом робіт

Сумніви в інженерної команди зазвичай ті самі: що станеться за відмови вузла, як швидко відкотитися, хто відповідає за сертифікати й чи не доведеться ловити деградацію за скаргами користувачів.

Ми проговорюємо ці точки до старту, щоб схема залишалася ремонтопридатною, а не «працює, поки її не торкнеш».

Нижче — короткі відповіді в розкривних блоках. Якщо вашого питання тут немає, додамо його в розбір задачі й повернемося з оцінкою та планом робіт.

Що буде, якщо сам балансувальник стане єдиною точкою відмови?

Ставимо два вузли в режимі гарячого резерву зі спільною віртуальною адресою: активний обслуговує трафік, другий тримає стан і приймає керування за втрати зв'язку.

Перемикання займає частки секунди й не потребує ручних дій — сесії та таблиці з'єднань зберігаються завдяки синхронізації.

Як бути із сертифікатами та їхнім продовженням?

Шифрування термінується на балансувальнику, сертифікати продовжуються автоматично, а ланцюжок перевіряється до викочування в продуктив. Заміна сертифіката проходить без розриву активних з'єднань: спочатку підхоплюється новий, потім витісняється старий.

Чи можна відкотити зміни й розібрати інцидент?

Конфігурація живе в системі контролю версій, викочування йде через перевірку синтаксису й плавне перезавантаження без обриву з'єднань. Відкат — повернення попередньої ревізії однією операцією.

Для розбору інцидентів збираємо журнали з мітками часу, кодами відповідей і часом відгуку за кожним вузлом: за ними видно, де почалася деградація й який вузол її спричинив.

Обговоримо вашу схему й повернемося з планом робіт

Щоб оцінка була предметною, а не «на око», потрібен мінімум вихідних даних. Надішліть поточну схему проходження трафіку, конфігурацію балансувальника, перелік сервісів за ним і вимоги до доступності — цього достатньо, щоб побачити вузькі місця й повернутися з планом робіт.

Ми не беремося «зробити все» замість вас: частину задач розумніше залишити внутрішній команді, і це теж відобразимо в плані.

Далі рухаємося за етапами, і на кожному зрозуміло, що відбувається й навіщо.

• Вихідні дані: точки входу, домени, сертифікати, цільові сервіси та правила маршрутизації.
• Розбір поточної схеми: як розподіляється трафік, де єдина точка відмови, що вже налаштовано в HAProxy.
• План впровадження: зміни за кроками з перевіркою після кожного — від правки конфігурації до перемикання трафіку.
• Вікно робіт: узгоджуємо інтервал з мінімальним впливом на користувачів і готовим відкатом на попередню конфігурацію.
• Моніторинг: метрики, оповіщення й панель за балансувальником — щоб проблему бачили раніше, ніж прийдуть звернення.
• Оцінка строків: тривалість кожного етапу й загальний графік з точками, де потрібне ваше узгодження.
• Передача: інструкції з експлуатації та розбір типових ситуацій з вашою командою.

Опишіть задачу у вільній формі — повернемося з оцінкою, планом і складом робіт.