Настройка балансировки нагрузки через HAProxy: конфигурация и мониторинг

Почему штатная настройка HAProxy ломается под нагрузкой

Штатная настройка HAProxy — это набор значений по умолчанию, которых хватает на стенде и не хватает на пике. Первое узкое место — не заданные явно таймауты соединений: пока клиент удерживает неактивное соединение, а сервер приложений отвечает дольше обычного, слоты обработки заканчиваются раньше, чем трафик. Очередь растёт, время ответа увеличивается лавинообразно, и балансировка нагрузки начинает распределять уже не запросы, а задержки.

Отсутствие проверок состояния узлов — вторая мина. По умолчанию балансировщик нередко проверяет только доступность порта: приложение может отдавать ошибки, но оставаться в ротации и получать свою долю трафика. Один деградировавший узел тянет вниз весь пул, а проблема обнаруживается по жалобам пользователей, а не по метрикам.

Третья — единственный вход в систему как точка отказа. Один процесс, один адрес, ручная правка конфигурации: обновление или перезапуск означают разрыв активных сессий, а отказ самого балансировщика кладёт весь сервис. Статистика при этом не снимается, поэтому разбор инцидента идёт уже после него, по логам приложений.

Разбираем, как это закрывается: явные таймауты под профиль трафика, проверки состояния по прикладному отклику, резервирование входа и мониторинг, который показывает деградацию до того, как она станет отказом.

Что меняется после переработки конфигурации и включения мониторинга

Что меняем в конфигурации, видно по трём метрикам: время отклика на пике, доля ошибочных ответов и время, за которое система возвращается к норме после падения узла. На пике трафик перестаёт упираться в один сервер: алгоритм балансировки выбирает узел по числу активных соединений, а не по кругу, число одновременных сессий на каждый узел ограничено, а соединения до приложений переиспользуются вместо открытия нового на каждый запрос.

Таймауты выставлены по фактическому распределению времени обработки, поэтому медленный, но живой узел успевает ответить, а не обрывается раньше срока, и очередь на входе не растёт лавинообразно.

HAProxy держит отдельную проверку здоровья для каждого узла: интервал, порог подряд идущих неудач и условия возврата в ротацию. Это закрывает класс отказов, который до переработки был основным источником 5xx — деградировавший узел, который отвечает, но медленно, продолжал получать свою долю трафика и портил ответы части пользователей. Теперь узел выводится из ротации до того, как начнёт отдавать ошибки, повтор отправляется только на безопасные для повтора запросы, а остальные получают явный ответ вместо подвешенного соединения.

Время восстановления после падения узла задаётся интервалом проверки и порогом неудач — это настраиваемая величина, а не следствие удачи. Обратно в ротацию узел входит плавно: сначала получает небольшую долю трафика, и только если время отклика держится в норме, возвращается к полной. Резервный узел включается в работу, когда основной пул деградировал целиком, поэтому всплеск отказов не превращается в полный простой.

Мониторинг нагрузки опирается на журналы доступа и счётчики: время обработки по каждому запросу, распределение трафика между узлами, доля ошибок, ожидание в очереди, состояние каждого сервера. Из этих данных видно, деградировал конкретный узел или вырос общий трафик, и оповещения выставляются от наблюдаемого профиля нагрузки, а не на глаз. Через несколько суток после включения понятно, какие пороги стали лишними, а где нужен запас — конфигурация уточняется по факту, а не по предположениям.

HAProxy настройка: варианты балансировки и их ограничения

Схема балансировки — это не одна директива, а набор: алгоритм распределения, проверки состояния, резервный контур и точка входа. Ошибка на любом уровне выглядит одинаково — часть запросов уходит на нерабочий узел и висит там до истечения ожидания.

Четыре схемы и их границы

Перед выбором проверяем три вещи: за сколько секунд узел выводится из ротации, что происходит при отказе самого балансировщика и где живёт состояние сессии. Если сессии липкие, а узел уходит — пользователь теряет корзину; если проверка смотрит только на открытый порт, деградация остаётся невидимой. Схему подбираем под профиль трафика, а не по умолчанию.

Как проходит внедрение: от разбора схемы до передачи

Порядок работ одинаков и для нового внедрения, и для перестройки уже работающего балансировщика: сначала фиксируем фактическое состояние, затем собираем целевую схему и проверяем её в тестовом контуре, и только после этого трогаем рабочий контур.

1. Аудит инфраструктуры. Снимаем карту сервисов, адресов и портов, смотрим, где стоит балансировщик относительно периметра и защиты. Разбираем статистику и логи: где теряются запросы, как живёт сессия, какие правки вносились на серверах руками.
2. Целевая схема. Решаем, что балансируется на уровне соединения, а что требует разбора заголовков, как распределяется нагрузка, где хранится состояние сессии. Схему согласуем до первой строки конфигурации.
3. Конфигурация на стенде. Разворачиваем HAProxy в тестовом контуре с теми же ролями серверов. Здесь же настраиваем сбор статистики, логи и ограничения частоты обращений.
4. Проверка под нагрузкой. Прогоняем профиль, близкий к пиковому: время ответа, распределение по серверам, поведение при росте числа соединений и медленных клиентах. Правки вносим, пока стенд, а не пользователи.
5. Испытания отказами. По очереди выводим серверы из строя, проверяем работу проверок доступности и самостоятельный возврат узла в строй. Здесь же фиксируем сценарий отката изменений.
6. Перевод трафика. Переключаем поэтапно: сначала доля запросов, затем весь поток, с наблюдением за ошибками и задержками. Если метрики выходят за границы, откат занимает минуты.
7. Передача дежурной смене. Отдаём схему, конфигурацию, порядок типовых операций и разбор инцидентов. Дежурный инженер вместе с нашим проходит перезагрузку конфигурации и учебный сбой.

Что остаётся у вас: конфигурации, схемы, регламенты

Балансировщик остаётся в вашем контуре, а значит, всё нужное для его работы и правок должно остаться у вашей команды, а не в переписке с нами. Поэтому сдаём не «файлы на память», а комплект артефактов, по которому дежурный инженер без нашей помощи поднимет контур, изменит маршрут и откатит неудачную правку.

Каждый документ пишем под человека, который видит систему впервые: где смотреть, что проверить после изменения, к какому сигналу реагировать первым.

• Рабочие конфигурации — файлы HAProxy по всем средам, с комментариями к неочевидным решениям: почему выбрано такое время ожидания ответа, как распределяются очереди, что зарезервировано под пиковые нагрузки.
• Схема потоков — откуда приходит трафик, где завершается шифрование, какие узлы стоят за балансировщиком и какие места остаются точками отказа. Восстановление картины занимает минуты, а не часы разбора логов.
• Политики доступа — правила, кто и с каких адресов попадает в панель управления и статистику, как ограничены изменения на боевом контуре и кто вправе их подтверждать.
• Инструкция по откату — пошаговый возврат предыдущей конфигурации одной операцией, список проверок после возврата и порядок действий, если откат не помог.
• Версионирование изменений — конфигурации в системе контроля версий, каждая правка отдельным набором с описанием: видно, кто, когда и зачем поменял маршрут или правило.
• Регламент мониторинга — какие показатели снимаем, при каких порогах приходит оповещение, куда оно уходит и кто дежурит.
• Порядок передачи — учётные записи, роли и права выдаются вашим людям, наши доступы закрываются сразу после сдачи.

Кейс: перевели трафик на резервный контур без простоя

До работ входной трафик обслуживал один узел балансировки: на нём сходились терминация шифрованного трафика, привязка клиентских сессий к конкретному серверу и проверки доступности бэкендов. Любое плановое обновление конфигурации означало перезапуск процесса — по логам это давало до 400 прерванных сессий за окно обслуживания и всплеск ответов 502 на входе. Резервный контур существовал, но переключались на него вручную и только в аварийном порядке.

Мы перевели вход на пару узлов HAProxy с общим плавающим адресом: конфигурация собирается из одного источника и раскатывается целиком, а бесшовная перезагрузка передаёт слушающие сокеты новому процессу, не разрывая уже установленные соединения. Привязку сессий убрали — состояние вынесли в общее хранилище, поэтому запрос обслуживает любой узел. Переключением между контурами теперь управляют проверки доступности, а не дежурный инженер.

Что показали замеры

Проверяли двумя способами: прогоном профиля нагрузки, снятого с боевого трафика, и контролируемым отключением узла в рабочие часы. Медиана времени отклика на входе сократилась почти втрое, доля ответов дольше секунды упала с 7% до 0,3%, а ответы 5xx — с 2,4% до 0,02%. Прерванных сессий при обслуживании больше нет: переключение на резервный контур укладывается в один интервал проверки, и пользователь его не замечает. Обратный перевод контура — та же операция с тем же результатом.

Чем отличается сетевой балансировщик от прикладного?

Сетевой уровень работает с потоком соединений: балансировщик видит адрес и порт, выбирает сервер по алгоритму и дальше в трафик не вмешивается. Содержимое пакетов не разбирается, поэтому задержка минимальна, а поведение одинаково для HTTP, СУБД и долгоживущих соединений. Ограничение одно: единица балансировки — соединение целиком, и если клиент держит один канал, разные типы запросов внутри него по назначению не развести.

Прикладной уровень разбирает прикладной протокол и видит метод, путь, заголовки, cookie. Отсюда маршрутизация запросов: статику отдаёт один пул серверов, API — второй, служебные адреса — третий, и правила меняются на входе без правок на самих серверах. Там же работает привязка сессии по cookie и точная проверка доступности: узел, отвечающий ошибкой на служебном адресе, выводится из ротации, хотя на сетевом уровне выглядел бы живым.

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

На практике режимы сосуществуют: HAProxy ведёт часть сервисов на сетевом уровне, а HTTP-нагрузку — на прикладном, и режим задаётся для каждого пула серверов отдельно.

Частые технические сомнения перед стартом работ

Сомнения у инженерной команды обычно одни и те же: что произойдёт при отказе узла, как быстро откатиться, кто отвечает за сертификаты и не придётся ли ловить деградацию по жалобам пользователей. Мы проговариваем эти точки до старта, чтобы схема оставалась ремонтопригодной, а не «работает, пока её не тронешь».

Ниже — короткие ответы в раскрывающихся блоках. Если вашего вопроса здесь нет, добавим его в разбор задачи и вернёмся с оценкой и планом работ.

Что будет, если сам балансировщик станет единой точкой отказа?

Ставим два узла в режиме горячего резерва с общим виртуальным адресом: активный обслуживает трафик, второй держит состояние и принимает управление при потере связи. Переключение занимает доли секунды и не требует ручных действий — сессии и таблицы соединений сохраняются за счёт синхронизации.

Как быть с сертификатами и их продлением?

Шифрование терминируется на балансировщике, сертификаты продлеваются автоматически, а цепочка проверяется до выкатки в продуктив. Замена сертификата проходит без разрыва активных соединений: сначала подхватывается новый, затем вытесняется старый.

Можно ли откатить изменения и разобрать инцидент?

Конфигурация живёт в системе контроля версий, выкатка идёт через проверку синтаксиса и плавную перезагрузку без обрыва соединений. Откат — возврат предыдущей ревизии за одну операцию. Для разбора инцидентов собираем журналы с метками времени, кодами ответов и временем отклика по каждому узлу: по ним видно, где началась деградация и какой узел её вызвал.

Обсудим вашу схему и вернёмся с планом работ

Чтобы оценка была предметной, а не «на глаз», нужен минимум исходных данных. Пришлите текущую схему прохождения трафика, конфигурацию балансировщика, перечень сервисов за ним и требования к доступности — этого достаточно, чтобы увидеть узкие места и вернуться с планом работ. Мы не берёмся «сделать всё» вместо вас: часть задач разумнее оставить внутренней команде, и это тоже отразим в плане.

Дальше двигаемся по этапам, и на каждом понятно, что происходит и зачем.

• Исходные данные: точки входа, домены, сертификаты, целевые сервисы и правила маршрутизации.
• Разбор текущей схемы: как распределяется трафик, где единая точка отказа, что уже настроено в HAProxy.
• План внедрения: изменения по шагам с проверкой после каждого — от правки конфигурации до переключения трафика.
• Окно работ: согласуем интервал с минимальным влиянием на пользователей и готовым откатом на предыдущую конфигурацию.
• Мониторинг: метрики, оповещения и панель по балансировщику — чтобы проблему видели раньше, чем придут обращения.
• Оценка сроков: длительность каждого этапа и общий график с точками, где нужно ваше согласование.
• Передача: инструкции по эксплуатации и разбор типовых ситуаций с вашей командой.

Опишите задачу в свободной форме — вернёмся с оценкой, планом и составом работ.