Настройка HAProxy + Keepalived для отказоустойчивого балансировщика

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

Наша команда сертифицированных DevOps-инженеров с 10+ летним опытом выполнила более 50 проектов по настройке таких схем. Мы настраиваем под ключ: два физических или виртуальных сервера с 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.

Важный параметр — 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 облачные балансировщики

При стабильной нагрузке 10 000 RPS экономия на инфраструктуре составляет до $2.7k–3.9k. в год. Облачные балансировщики удобнее при пиковой нагрузке, когда нужно быстро масштабироваться.

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

• Убедитесь, что 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).

Сроки ориентировочно

Стоимость настройки под ключ — от $720–1k. (уточняется после аудита). Наши сертифицированные инженеры с десятилетним опытом гарантируют SLA 99.9% для балансировщика. Экономия на инфраструктуре достигает 70% по сравнению с облачными решениями при стабильной нагрузке.

Закажите аудит вашей инфраструктуры — мы подберём оптимальную конфигурацию HAProxy+Keepalived под вашу нагрузку. Получите консультацию по настройке HAProxy+Keepalived — мы оценим вашу инфраструктуру. Свяжитесь с нами для предварительной оценки проекта.