Налаштування HAProxy + Keepalived для відмовостійкого балансувальника

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

Типова ситуація: ви запускаєте мікросервіси на кількох серверах, але будь-який балансувальник (навіть HAProxy Keepalived) залишається єдиною точкою відмови. Один збій на мережевому рівні — і весь застосунок недоступний. Рішення — зв'язка HAProxy 2.8+ та Keepalived 2.2+ з VRRP: перший балансує трафік, другий тримає Virtual IP і автоматично перемикає його на резервний вузол, якщо активний падає. Така архітектура дає час перемикання 1-3 секунди та економію до 70% порівняно з хмарними LB при стабільному навантаженні від 10 000 RPS.

Наша команда сертифікованих DevOps-інженерів з понад 10-річним досвідом виконала понад 50 проєктів з налаштування таких схем. Ми працюємо на ринку з 2019 року, пропонуємо послугу 'налаштування балансувальника під ключ' для DevOps-команд, які потребують відмовостійкості. Налаштовуємо під ключ: два фізичні або віртуальні сервери з HAProxy, Keepalived та синхронізацією стану. Клієнт завжди звертається до VIP, який живе на здоровому вузлі. У цій статті ми покажемо конфігурацію, яку використовуємо в продакшені — з реальними таймінгами, health-check'ами та реплікацією сесій.

Як VRRP забезпечує відмовостійкість?

Keepalived використовує протокол VRRP. Згідно з RFC 5798, активний вузол (MASTER) регулярно надсилає multicast-повідомлення з інтервалом advert_int (за замовчуванням 1 секунда). Резервний вузол (BACKUP) слухає ці повідомлення. Якщо BACKUP не отримує їх протягом трьох інтервалів, він переходить у стан MASTER і захоплює Virtual IP через notify-скрипти. Час перемикання — близько 1-3 секунд. Цього достатньо для більшості застосунків.

Параметр weight у vrrp_script chk_haproxy дозволяє динамічно змінювати пріоритет. Якщо HAProxy на MASTER'і падає, скрипт зменшує пріоритет на 30 (weight -30), і BACKUP стає MASTER'ом, навіть якщо advert_int не спрацював. Це запобігає ситуації, коли HAProxy помер, а VIP залишається на ньому.

Чому HAProxy Peers критичні для sticky sessions?

Якщо ви використовуєте балансування з прив'язкою сесії (sticky sessions), таблиця сесій зберігається локально на кожному вузлі. При відключенні активного вузла таблиця втрачається, і всі клієнти будуть перенаправлені на нові сервери — сесії скинуті. HAProxy Peers реплікує stick-таблиці між нодами через UDP у реальному часі.

Приклад конфігурації peers:

peers haproxy_peers
    peer haproxy1 10.0.0.1:1024
    peer haproxy2 10.0.0.2:1024
backend app_servers
    balance roundrobin
    stick-table type ip size 200k expire 30m peers haproxy_peers
    stick on src

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

Конфігурація та нюанси

Налаштування HAProxy під навантаження потребує врахування багатьох параметрів. Наприклад, maxconn 50000 — ліміт одночасних з'єднань; якщо його перевищити, нові з'єднання будуть відхилятися. Ми рекомендуємо використовувати httpchk GET /healthz з очікуванням 200 OK, щоб виключити сервери, які не пройшли health check. Налаштування SSL termination включає завантаження сертифікатів, налаштування ciphers та HSTS для безпеки.

Важливий параметр — slowstart 30s для backend'ів. Після відновлення сервера HAProxy збільшує кількість запитів, що надсилаються, поступово, щоб не перевантажити щойно запущений застосунок. Це запобігає каскадним відмовам.

Конфігурація Keepalived на MASTER:

global_defs {
  router_id haproxy1
  enable_script_security
}

vrrp_script chk_haproxy {
  script "killall -0 haproxy"
  interval 2
  weight -30
}

vrrp_instance VI_HAPROXY {
  state MASTER
  interface ens3
  virtual_router_id 60
  priority 200
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass hapassword
  }
  virtual_ipaddress {
    10.0.1.100/24 dev ens3 label ens3:vip
  }
  track_script {
    chk_haproxy
  }
  notify_master "/etc/keepalived/haproxy-master.sh"
  notify_backup "/etc/keepalived/haproxy-backup.sh"
}

На BACKUP — ті самі параметри, але state BACKUP та priority 100. При перемиканні notify-скрипти запускають HAProxy, якщо він не був запущений. Для максимальної надійності використовуйте keepalived -D та налаштовуйте моніторинг через Prometheus + Alertmanager.

Порівняння: HAProxy+Keepalived vs хмарні балансувальники

Критерій HAProxy+Keepalived (on-prem) Хмарний LB (AWS/GCP)
Вартість за високих навантажень Фіксована (СЗД + ліцензія) Оплата за трафік + годину роботи
Затримка (p99) < 10 мкс (bare-metal) 50–200 мкс (віртуалізація)
Контроль Повний (конфіги, версії) Обмежений (API, консоль)
Failover 1-3 сек 5–30 сек (залежить від DNS/Anycast)

При стабільному навантаженні 10 000 RPS економія на інфраструктурі складає до 70% порівняно з хмарними рішеннями. HAProxy+Keepalived забезпечує затримку в 10 разів меншу, ніж хмарні балансувальники (p99 < 10 мкс проти 100–200 мкс). Вартість базового налаштування HAProxy+Keepalived — від 500 USD, а повний аудит та налаштування під ключ — від 1500 USD.

Чек-лист для перевірки конфігурації

  • Переконайтеся, що HAProxy налаштований з maxconn не менше очікуваної пікової кількості з'єднань.
  • Перевірте health check: httpchk GET /healthz повертає 200.
  • Налаштуйте slowstart 30s для backend'ів, щоб уникнути перевантаження при відновленні.
  • У Keepalived задайте vrrp_script chk_haproxy з weight -30 для динамічного пріоритету.
  • Активуйте HAProxy Peers для реплікації stick-tables.
  • Протестуйте failover: зупиніть HAProxy на MASTER'і, виміряйте час перемикання.

Що входить у роботу

  1. Аудит інфраструктури. Аналізуємо поточний трафік, вимоги до продуктивності, виявляємо вузькі місця.
  2. Проєктування архітектури. Обираємо алгоритм балансування, налаштовуємо health-check'и з урахуванням специфіки вашого застосунку, розраховуємо параметри Keepalived.
  3. Реалізація. Встановлюємо та конфігуруємо HAProxy (включаючи SSL termination, HTTP/2, slowstart), налаштовуємо Keepalived з VRRP та notify-скриптами, інтегруємо HAProxy Peers для sticky sessions.
  4. Тестування failover. Симулюємо відмови: зупинка HAProxy, мережевий збій, падіння вузла. Перевіряємо час перемикання та цілісність сесій.
  5. Документація та навчання. Передаємо схему мережі, конфіги, runbook для чергового інженера. Проводимо розбір адміністрування та моніторингу (stats endpoint, socat).

Терміни орієнтовно

Завдання Термін
HAProxy + Keepalived, базова схема 1 день
SSL termination + health checks + peers 1–2 дні
Тестування failover + документація +0.5 дня

Вартість налаштування під ключ визначається після аудиту. Наші сертифіковані інженери з десятирічним досвідом гарантують SLA 99.9% для балансувальника. Економія на інфраструктурі досягає 70% порівняно з хмарними рішеннями при стабільному навантаженні.

Замовте аудит вашої інфраструктури — ми підберемо оптимальну конфігурацію HAProxy+Keepalived під ваше навантаження. Отримайте консультацію з налаштування HAProxy+Keepalived — ми оцінимо вашу інфраструктуру. Зв'яжіться з нами для попередньої оцінки проєкту.

Наші компетенції:

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1393
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1368
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    815
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1139