Что такое 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-сервисов лучше включить проверку по конкретному URL, чтобы отличать "порт открыт" от "приложение реально отвечает":

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: балансировка нагрузки и проверки