HAPROXY_DOWN: битый конфиг шлюза

Симптом

• CRITICAL HAPROXY_DOWN: «High availability gateway down and could not be restarted. S3 traffic will be impacted on this system node.»
• В логе монитора каждые несколько минут: haproxy processes expected 1, found 0 (или ожидаемое число из nbproc не совпадает с фактическим).
• S3-клиенты на этой ноде получают ошибку соединения или TLS-ошибку, хотя другие ноды отвечают.
• Подзадача приложения scalerd в FAILURE, следом машинная группа обрывается (TASK_TERMINATED), остальные подзадачи висят в QUEUED.

Что проверить первым (read-only)

1. Кто слушает 80/443: bash sudo ss -ltnp | grep -E ':80 |:443 ' Ожидается haproxy на обоих портах (роли портов — в карте портов). Любой другой процесс — причина: продукт не может занять порт.

2. Какие процессы haproxy есть: bash ps -o pid,ppid,user,args -C haproxy Ожидается: файл конфигурации /etc/haproxy/haproxy.cfg, владелец haproxy, ppid=1, число процессов равно nbproc. Лишние экземпляры с другим конфигом или от другого пользователя — отдельная проблема, их быть не должно.

3. Конфиг валиден — проверять только парой файлов: bash sudo /usr/sbin/haproxy -c -f /etc/haproxy/haproxy.cfg -f /etc/haproxy/conf.d/scalerd.cfg Ожидается Configuration file is valid. Отдельно scalerd.cfg падает на %tr — это ложная ошибка проверки, mode берётся из defaults первого файла.

4. Отвечает ли фронт: bash curl -i http://127.0.0.1/ Ожидается HTTP/1.1 307 и Server: Quantum-ActiveScale плюс x-amz-request-id.

5. Что говорит монитор: grep 'haproxy processes' /opt/ampli/var/log/mona/mona.log | tail

6. Карта IAM: в /etc/haproxy/map/iam.map строка должна быть <DOMAIN> backend-iam-public, а не <DOMAIN> <DOMAIN>. И PEM /opt/ampli/cfg/scalerd/ssl/scalerd.pem читается только под root: «unable to load SSL private key» без sudo — это права, не порча файла.

Причина

1. Конфиг отрендерен с мусором

configure машины рендерит /etc/haproxy/haproxy.cfg и conf.d/scalerd.cfg из источника (плейбук/модель). Если источник испорчен — например, массовая подстановка «домена» затерла все строки value: "…" (TLS-опции, шифры, таймауты, cpu-map, имя IAM-бэкенда) — рендер даёт невалидный файл, haproxy не стартует, чекер видит found 0.

2. Ловушка повтора

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

3. Чужой процесс на порту

Если 80/443 занял посторонний процесс (наш прокси, тестовый сервер, второй haproxy), штатный не может забиндиться. Формально S3 может даже отвечать — но не тем сертификатом и не тем бэкендом, а чекер всё равно видит ноль «правильных» процессов. Это класс «лишние процессы/порты».

4. Где искать первопричину

Порядок разбора: порт (ss -ltnp) → процесс (ps -C haproxy) → конфиг (пара файлов) → источник рендера. Если конфиг валиден, а процесса нет — искать владельца порта; если процесс есть, но чекер его не считает — сверять user/ppid/cmdline с ожиданием чекера. Если конфиг невалиден — подниматься к источнику и не править раскатанный файл «на глаз», иначе следующий configure вернёт мусор.

5. Почему падает вся машинная группа

Прогон configure падает на задаче перезапуска haproxy; подзадача приложения получает FAILURE, и вся группа машины обрывается. В details события подзадачи видно Failed to set 'restarted' for service 'haproxy'. Это следствие, а не отдельная поломка.

Решение (штатное)

1. Вернуть источник конфига. Правка — только значениями из модели/бэкапа; бэкап держать вне каталога продукта. Проверить, что в источнике ровно одна осмысленная правка (например, iam_domain_set), diff с бэкапом — одна строка.
2. Вернуть раскатанные файлы к значениям источника (иначе повтор): сначала сухой прогон, затем запись с бэкапами.
3. Проверить конфиг парой файлов — пункт 3 списка проверок, до Configuration file is valid.
4. Освободить порты. Найти владельца 80/443 (ss -ltnp), остановить посторонний процесс штатными средствами ОС; лишние экземпляры haproxy снять. Порты должны остаться за продуктом.
5. Поднять шлюз штатно: configure машины из Model API (POST /model/machine/<MGUID>/action/configure/) — он перезапускает службу и рендерит конфиги из источника. Ожидается 200 и процесс user=haproxy, ppid=1.
6. Проверить S3-фронт на всех нодах: 307 + Server: Quantum-ActiveScale.

Если штатный путь недоступен

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

Проверка

• haproxy -c -f … -f … → Configuration file is valid.
• ps -C haproxy → нужное число процессов, user=haproxy, ppid=1, конфиг /etc/haproxy/haproxy.cfg.
• curl -i http://127.0.0.1/ → 307 и Server: Quantum-ActiveScale.
• Событие: HAPROXY_DOWN → HANDLED_AUTO, появилось HAPROXY_RECOVERED.
• В mona.log новых строк found 0 нет.
• Подзадача scalerd (action configure) → SUCCESS; mtime конфигов не изменился — значит восстановленный текст совпал с тем, что отрендерил бы продукт.

Профилактика

• Любую правку конфигов шлюза делать точечно (одна строка), с diff против бэкапа.
• Бэкапы — вне каталога продукта; файлы .orig/.bak в group_vars запрещены: ansible грузит все файлы каталога, бэкап побеждает.
• Не оставлять на нодах посторонние процессы на 80/443; порты — только за продуктом.
• В мониторинг добавить haproxy -c и число процессов: это ранний сигнал до HAPROXY_DOWN.

Источники и дата

• Software Documentation Center (доступ 2026-11-07).
• Наша практика (обезличено): восстановление шлюза на 3-нодном кластере после порчи источника конфига; конфиг проверялся парой файлов, службу поднял штатный configure, подзадача scalerd — SUCCESS.
• Обновлено: 2026-11-07.