Що таке HAProxy і коли він потрібен на VDS

HAProxy — це TCP/HTTP-балансувальник навантаження та проксі, який розподіляє вхідні запити між кількома серверами-бекендами. Його ставлять перед парою вебсерверів, кластером PHP-FPM або кількома інстансами застосунку, щоб пережити відмову одного вузла і розподілити трафік рівномірно. HAProxy від початку створювався саме як балансувальник і вміє глибоко контролювати стан бекендів — є окрема стаття про Nginx як балансувальник навантаження, для легшого варіанта.

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

Встановлення HAProxy на Ubuntu та Debian

Пакет HAProxy є у стандартних репозиторіях. Встановіть його і перевірте версію:

apt update
apt install haproxy -y
haproxy -v

Сервіс одразу реєструється в systemd. Основний конфігураційний файл лежить за шляхом /etc/haproxy/haproxy.cfg. Перед змінами зробіть копію:

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

Базова конфігурація: frontend і backend

Конфігурація HAProxy будується із секцій frontend (що слухаємо) і backend (куди надсилаємо). Мінімальний робочий приклад для розподілу HTTP-трафіку між двома серверами:

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check

Параметр check наприкінці рядка server вмикає перевірку доступності цього бекенда — без нього HAProxy не дізнається про падіння сервера і надсилатиме на нього трафік далі.

Перевірки доступності бекендів (health checks)

За замовчуванням HAProxy перевіряє TCP-з'єднання з портом бекенда кожні кілька секунд. Для HTTP-сервісів варто увімкнути перевірку за конкретною адресою, щоб відрізняти відкритий порт від застосунку, що справді відповідає:

backend http_back
    option httpchk GET /health
    http-check expect status 200
    server web1 10.0.0.11:80 check inter 3000 fall 3 rise 2
    server web2 10.0.0.12:80 check inter 3000 fall 3 rise 2

Параметр inter 3000 задає інтервал перевірки в 3000 мілісекунд, fall 3 — скільки невдалих перевірок поспіль потрібно для виключення сервера з ротації, а rise 2 — скільки успішних перевірок вимагається, щоб повернути його назад.

Алгоритми балансування навантаження

Параметр balance у секції backend задає розподіл запитів. Основні варіанти:

Алгоритм	Принцип роботи
roundrobin	По черзі на кожен сервер
leastconn	На сервер із найменшою кількістю активних з'єднань
source	За хешем IP клієнта — один клієнт завжди потрапляє на один сервер

Для сесійних застосунків без спільного сховища сесій застосовуйте source або balance leastconn з увімкненим stick-table, щоб користувач не втрачав авторизацію під час перемикання між бекендами.

Перевірка конфігурації, перезапуск і моніторинг

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

haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

Чек-лист для продакшену:

Завжди перевіряйте конфіг командою haproxy -c перед reload.
Налаштуйте httpchk на справжню точку здоров'я застосунку, а не просто на корінь сайту.
Відкрийте порт балансувальника у файрволі — див. статтю про налаштування UFW на VDS.
Підключіть загальний моніторинг ресурсів сервера з HAProxy — див. статтю про моніторинг ресурсів VDS.
Увімкніть сторінку статистики HAProxy (stats enable) на окремому порту, щоб бачити стан бекендів у реальному часі.

HAProxy на VDS: балансування навантаження й перевірки