Как использовать HAProxy для балансировки HTTP-нагрузки на Ubuntu VPS

Всё началось с простого веб-сайта, который обслуживал пару десятков пользователей в день. Потом траффик пошёл в гору, и один сервер перестал справляться. Знакомая ситуация? Самое время познакомиться с HAProxy — мощным инструментом для балансировки нагрузки, который превратит ваш одинокий сервер в отказоустойчивый кластер. В этой статье разберём, как поднять HAProxy на Ubuntu VPS и заставить его работать как швейцарские часы.

Зачем это нужно? Представьте, что ваш сервер — это единственная касса в супермаркете. Очередь растёт, люди нервничают, а вы теряете клиентов. HAProxy — это как открытие дополнительных касс и умный диспетчер, который направляет покупателей к свободным кассирам. Только вместо покупателей — HTTP-запросы, а вместо касс — ваши backend-серверы.

Как работает HAProxy под капотом

HAProxy — это reverse proxy и load balancer в одном флаконе. Он принимает входящие HTTP-запросы и распределяет их между несколькими backend-серверами по различным алгоритмам. Архитектура выглядит примерно так:

Internet → HAProxy (Frontend) → Backend Servers (Pool)
                ↓
        Health Checks, Logging, SSL Termination

Основные компоненты:

• Frontend — точка входа, которая принимает подключения от клиентов
• Backend — пул серверов, которые обрабатывают запросы
• Server — конкретный сервер внутри backend
• ACL (Access Control Lists) — правила для маршрутизации трафика

HAProxy работает в event-driven режиме, что позволяет ему обрабатывать десятки тысяч одновременных подключений на относительно скромном железе.

Установка и базовая настройка

Начнём с установки HAProxy на Ubuntu. Сначала обновим систему и поставим необходимые пакеты:

sudo apt update
sudo apt upgrade -y
sudo apt install haproxy -y

# Проверим версию
haproxy -v

Теперь создадим резервную копию оригинального конфига и начнём настройку:

sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.backup
sudo nano /etc/haproxy/haproxy.cfg

Базовая конфигурация выглядит так:

global
    log stdout local0
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms
    option httplog
    option dontlognull
    option http-server-close
    option forwardfor except 127.0.0.0/8
    option redispatch
    retries 3
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend main
    bind *:80
    default_backend webservers

backend webservers
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check
    server web3 192.168.1.12:80 check

Алгоритмы балансировки нагрузки

HAProxy поддерживает множество алгоритмов балансировки. Вот самые популярные:

Пример настройки с разными алгоритмами:

backend api_servers
    balance leastconn
    option httpchk GET /health
    server api1 10.0.1.10:8080 check inter 30s
    server api2 10.0.1.11:8080 check inter 30s
    server api3 10.0.1.12:8080 check inter 30s

backend static_servers
    balance uri
    hash-type consistent
    server static1 10.0.1.20:80 check
    server static2 10.0.1.21:80 check

Health Checks и мониторинг

Один из ключевых фичей HAProxy — это health checks. Он умеет проверять состояние backend-серверов и автоматически исключать неисправные из ротации:

backend webservers
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    
    server web1 192.168.1.10:80 check inter 30s fall 3 rise 2
    server web2 192.168.1.11:80 check inter 30s fall 3 rise 2
    server web3 192.168.1.12:80 check inter 30s fall 3 rise 2

Параметры health check:

• inter — интервал между проверками (по умолчанию 2s)
• fall — количество неудачных проверок для пометки сервера как down
• rise — количество успешных проверок для возвращения сервера в ротацию
• timeout — таймаут для проверки

Более продвинутые health checks:

backend database_servers
    balance leastconn
    option httpchk POST /api/health
    http-check send-state
    http-check expect rstatus ^2[0-9][0-9]
    
    server db1 10.0.1.30:5432 check port 8080 inter 10s
    server db2 10.0.1.31:5432 check port 8080 inter 10s backup

SSL Termination и HTTPS

HAProxy умеет обрабатывать SSL/TLS трафик, что позволяет разгрузить backend-серверы от криптографических операций:

# Генерируем SSL сертификат (для тестирования)
sudo mkdir -p /etc/haproxy/certs
sudo openssl req -x509 -newkey rsa:4096 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -nodes
sudo cat /tmp/cert.pem /tmp/key.pem > /etc/haproxy/certs/example.com.pem
sudo chown haproxy:haproxy /etc/haproxy/certs/example.com.pem
sudo chmod 600 /etc/haproxy/certs/example.com.pem

Конфигурация для HTTPS:

global
    tune.ssl.default-dh-param 2048
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11
    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS

frontend https_frontend
    bind *:443 ssl crt /etc/haproxy/certs/example.com.pem
    bind *:80
    redirect scheme https if !{ ssl_fc }
    default_backend webservers

backend webservers
    balance roundrobin
    option httpchk GET /health
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check

Статистика и веб-интерфейс

HAProxy предоставляет отличный веб-интерфейс для мониторинга:

frontend stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 30s
    stats admin if TRUE
    stats auth admin:password123

После перезапуска HAProxy статистика будет доступна по адресу http://your-server:8404/stats. Там вы увидите:

• Состояние всех серверов
• Количество активных соединений
• Пропускную способность
• Время отклика
• Ошибки и их количество

Продвинутые фичи и ACL

ACL (Access Control Lists) позволяют создавать сложные правила маршрутизации:

frontend main
    bind *:80
    
    # ACL для определения типа запроса
    acl is_api path_beg /api/
    acl is_static path_end .css .js .png .jpg .gif
    acl is_mobile hdr_sub(User-Agent) -i mobile
    acl is_admin src 192.168.1.0/24
    
    # Маршрутизация на основе ACL
    use_backend api_servers if is_api
    use_backend static_servers if is_static
    use_backend mobile_servers if is_mobile
    use_backend admin_servers if is_admin
    
    default_backend webservers

Пример с rate limiting:

frontend main
    bind *:80
    
    # Ограничение по IP: максимум 20 запросов в минуту
    stick-table type ip size 100k expire 60s store http_req_rate(60s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 20 }
    
    default_backend webservers

Интеграция с Docker и Kubernetes

HAProxy отлично работает в контейнерной среде. Вот пример Docker Compose для тестирования:

version: '3.8'

services:
  haproxy:
    image: haproxy:latest
    ports:
      - "80:80"
      - "8404:8404"
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg
    depends_on:
      - web1
      - web2

  web1:
    image: nginx:alpine
    ports:
      - "8081:80"
    
  web2:
    image: nginx:alpine
    ports:
      - "8082:80"

Для Kubernetes можно использовать HAProxy Ingress Controller, который автоматически обновляет конфигурацию на основе Ingress ресурсов.

Скрипты для автоматизации

Полезный скрипт для автоматического добавления/удаления серверов:

#!/bin/bash
# manage_backend.sh - управление backend серверами

HAPROXY_STATS_URL="http://admin:password123@localhost:8404/stats"
BACKEND_NAME="webservers"

add_server() {
    local server_name=$1
    local server_addr=$2
    
    echo "disable server ${BACKEND_NAME}/${server_name}" | \
    socat stdio /run/haproxy/admin.sock
    
    echo "add server ${BACKEND_NAME}/${server_name} ${server_addr} check" | \
    socat stdio /run/haproxy/admin.sock
    
    echo "enable server ${BACKEND_NAME}/${server_name}" | \
    socat stdio /run/haproxy/admin.sock
}

remove_server() {
    local server_name=$1
    
    echo "disable server ${BACKEND_NAME}/${server_name}" | \
    socat stdio /run/haproxy/admin.sock
    
    echo "delete server ${BACKEND_NAME}/${server_name}" | \
    socat stdio /run/haproxy/admin.sock
}

case "$1" in
    add)
        add_server $2 $3
        ;;
    remove)
        remove_server $2
        ;;
    *)
        echo "Usage: $0 {add|remove} server_name [server_addr]"
        exit 1
        ;;
esac

Сравнение с конкурентами

HAProxy выигрывает в производительности и функциональности, но требует больше времени на изучение. Nginx проще в настройке и может выполнять роль веб-сервера, а Traefik идеален для микросервисных архитектур.

Типичные ошибки и их решения

Ошибка 503 Service Unavailable:

• Проверьте, что backend-серверы запущены
• Убедитесь, что health checks проходят успешно
• Проверьте сетевую доступность серверов

Высокий CPU usage:

• Увеличьте количество worker processes
• Оптимизируйте ACL правила
• Используйте connection pooling

SSL handshake errors:

• Проверьте права доступа к сертификатам
• Убедитесь в правильности цепочки сертификатов
• Обновите SSL ciphers

Мониторинг и логирование

Настройка логирования в syslog:

# В /etc/rsyslog.conf добавляем:
$UDPServerRun 514
$UDPServerAddress 127.0.0.1
local0.*    /var/log/haproxy.log
& stop

# Перезапускаем rsyslog
sudo systemctl restart rsyslog

Интеграция с Prometheus для мониторинга:

# Устанавливаем HAProxy exporter
wget https://github.com/prometheus/haproxy_exporter/releases/download/v0.13.0/haproxy_exporter-0.13.0.linux-amd64.tar.gz
tar -xzf haproxy_exporter-0.13.0.linux-amd64.tar.gz
sudo mv haproxy_exporter-0.13.0.linux-amd64/haproxy_exporter /usr/local/bin/

# Создаём systemd unit
sudo tee /etc/systemd/system/haproxy_exporter.service > /dev/null <

frontend db_frontend
    bind *:5432
    mode tcp
    default_backend db_servers

backend db_servers
    mode tcp
    balance leastconn
    option tcp-check
    server db1 10.0.1.30:5432 check
    server db2 10.0.1.31:5432 check backup

backend blue_env
    server app1 10.0.1.10:8080 check
    server app2 10.0.1.11:8080 check

backend green_env
    server app3 10.0.1.20:8080 check
    server app4 10.0.1.21:8080 check

frontend main
    bind *:80
    # Переключаем комментарий для смены окружения
    default_backend blue_env
    # default_backend green_env

frontend main
    bind *:80
    
    # 90% трафика на стабильную версию
    use_backend stable_servers if { rand(100) lt 90 }
    # 10% трафика на canary версию
    default_backend canary_servers