HAProxy: балансировка нагрузки и health checks

Когда один сервер перестаёт справляться с нагрузкой, а простого обратного прокси уже недостаточно, на помощь приходит HAProxy. Это балансировщик TCP и HTTP с открытым кодом, который распределяет запросы между бэкендами, проверяет их доступность, завершает TLS и отдаёт подробную статистику. Ниже — рабочая конфигурация, алгоритмы балансировки, health checks и приёмы диагностики, актуальные в 2026 году.

Зачем нужен отдельный балансировщик

Nginx тоже умеет проксировать, и для простых задач его достаточно. HAProxy выигрывает там, где важны предсказуемая задержка, гибкие проверки здоровья и детальная телеметрия. Он не обслуживает статику и не запускает PHP — его задача одна: принять соединение и передать его живому серверу. Такая специализация позволяет держать десятки тысяч одновременных соединений на скромном железе.

Типовая схема выглядит так: клиент, затем HAProxy, затем два-три приложения и общая база. Балансировщик ставится на отдельный хост или на два хоста с keepalived, чтобы не стать единой точкой отказа.

Установка и проверка версии

sudo apt install haproxy
haproxy -v
sudo systemctl enable --now haproxy
haproxy -c -f /etc/haproxy/haproxy.cfg

В RHEL-совместимых дистрибутивах пакет ставится через dnf install haproxy. Флаг -c проверяет синтаксис конфигурации без запуска: возьмите за правило прогонять его перед каждым перезапуском. Если проверка прошла, а сервис не поднялся, смотрите journalctl -u haproxy -n 50 --no-pager.

Скелет конфигурации

Файл /etc/haproxy/haproxy.cfg состоит из нескольких секций. global задаёт процессы, логи и сокет администратора, defaults — общие таймауты, frontend описывает точку входа, backend — пул серверов.

global
    log /dev/log local0
    maxconn 20000
    stats socket /run/haproxy/admin.sock mode 660 level admin

defaults
    mode http
    timeout connect 5s
    timeout client  30s
    timeout server  30s
    option httplog

frontend web_in
    bind *:80
    default_backend app_pool

Таймауты — самая частая причина «зависших» соединений. Если timeout server меньше реального времени ответа приложения, HAProxy будет рвать легитимные запросы и помечать сервер как упавший. Ориентируйтесь на p99 задержки, а не на среднее значение.

Пул серверов и алгоритмы балансировки

backend app_pool
    balance leastconn
    option httpchk GET /health
    server app1 10.0.0.11:8080 check weight 100
    server app2 10.0.0.12:8080 check weight 100
    server app3 10.0.0.13:8080 check weight 50 backup

Алгоритм roundrobin подходит для однородных быстрых запросов, leastconn — для долгих соединений и баз за прокси, source привязывает клиента к серверу по IP и полезен, когда состояние хранится локально. uri хеширует путь и помогает с кэшами. Параметр weight задаёт пропорцию трафика, backup держит сервер в резерве до отказа основных.

Менять вес на лету можно через сокет: set server app_pool/app3 weight 80. Это удобно при постепенном вводе нового сервера в работу.

Health checks: больше, чем ping

Проверка check по умолчанию делает TCP-коннект. Этого мало: приложение может принимать порт, но отдавать ошибку 500. Настройте HTTP-проверку с ожиданием конкретного кода и тела ответа.

option httpchk GET /health HTTP/1.1
http-check send hdr Host example.com
http-check expect status 200
http-check expect string "status":"ok"
default-server inter 3s fall 3 rise 2

inter — интервал, fall — сколько неудач подряд нужно для исключения, rise — сколько успехов для возврата. Не ставьте интервал в миллисекунды: при сотне бэкендов это лишняя нагрузка на приложение. Для не-HTTP сервисов используйте option tcp-check с последовательностью tcp-check send и tcp-check expect, например с командой PING для Redis.

Отдельный приём — agent-check: приложение само сообщает вес или готовность через отдельный порт. Удобно при плавном draining перед деплоем, когда нужно перестать слать трафик, но не обрывать текущие запросы.

HTTPS и sticky sessions

frontend web_tls
    bind *:443 ssl crt /etc/haproxy/certs/example.pem alpn h2,http/1.1
    http-response set-header Strict-Transport-Security "max-age=31536000"
    default_backend app_pool

backend app_pool
    cookie SERVERID insert indirect nocache httponly secure
    server app1 10.0.0.11:8080 check cookie s1

Файл сертификата — это цепочка и ключ в одном PEM. Если приложение хранит сессии в памяти, без привязки пользователь будет терять корзину при каждом переключении. Альтернатива — вынести сессии в Redis и оставить балансировщик stateless: это надёжнее и упрощает масштабирование.

Для обновления сертификатов без простоя положите новый PEM и выполните systemctl reload haproxy. Старые соединения продолжатся, новые пойдут уже с новым сертификатом.

Логи и статистика

Чтобы логи уходили в syslog, создайте правило для локального демона. В Debian и Ubuntu достаточно файла /etc/rsyslog.d/49-haproxy.conf со строкой local0.* -/var/log/haproxy.log, после чего перезапустите rsyslog. Не забывайте про logrotate, иначе файл вырастет до гигабайтов.

echo "show stat" | sudo socat stdio /run/haproxy/admin.sock
echo "show servers state" | sudo socat stdio /run/haproxy/admin.sock
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" http://127.0.0.1/health

Сокет администратора даёт то же, что веб-страница статистики, но в терминале и без браузера. Колонки status, check_status, qcur и rtime показывают, жив ли сервер и сколько запросов стоит в очереди. Для постоянного наблюдения включите stats enable на отдельном порту с basic-аутентификацией или снимите метрики через Prometheus-экспортёр.

Плавное обновление и отказоустойчивость

Команда systemctl reload haproxy перечитывает конфигурацию без разрыва соединений. Если нужны сохранённые stick-таблицы, применяйте перезапуск с сокетом -x /run/haproxy/admin.sock, чтобы старое состояние передалось новому процессу. На двух узлах настройте keepalived с виртуальным IP: клиенты не заметят переключения, а вы получите запас по отказоустойчивости.

Чек-лист перед продакшеном

• Конфигурация проверена через haproxy -c, таймауты согласованы с приложением.
• Health check проверяет бизнес-логику, а не только открытый порт.
• Настроены fall и rise, есть резервный сервер.
• Сертификаты обновляются автоматически, HSTS выставлен осознанно.
• Сокет статистики закрыт правами доступа, метрики собираются.
• Есть второй балансировщик или keepalived с виртуальным IP.

Итог

HAProxy остаётся рабочей лошадкой балансировки: минимальный конфиг умещается в двадцать строк, а глубина настройки позволяет тонко управлять здоровьем сервисов и трафиком. Начните с leastconn и HTTP-проверки /health, добавьте статистику и только потом усложняйте схему — так вы получите предсказуемый результат без лишних слоёв.