Ошибки HAProxy random HTTP 503

У нас установлено 3 сервера:

Сервер A с Nginx + HAproxy для балансировки нагрузки
серверный сервер B
сервер backend C

Вот наш /etc/haproxy/haproxy.cfg:

global
        log /dev/log   local0
        log 127.0.0.1   local1 notice
        maxconn 40096
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        maxconn 2000
        contimeout      50000
        clitimeout      50000
        srvtimeout      50000
                stats enable
                stats uri /lb?stats
                stats realm Haproxy\ Statistics
                stats auth admin:admin
listen statslb :5054 # choose different names for the 2 nodes
        mode http
        stats enable
        stats hide-version
        stats realm Haproxy\ Statistics
        stats uri /
        stats auth admin:admin

listen  Server-A 0.0.0.0:80    
        mode http
        balance roundrobin
        cookie JSESSIONID prefix
        option httpchk HEAD /check.txt HTTP/1.0
        server  Server-B <server.ip>:80 cookie app1inst2 check inter 1000 rise 2 fall 2
        server  Server-C <server.ip>:80 cookie app1inst2 check inter 1000 rise 2 fall 3

Все три сервера имеют достаточное количество ОЗУ и процессорных ядер для обработки запросов

Случайные ошибки HTTP 503 отображаются при просмотре: 503 Service Unavailable - No server is available to handle this request.

А также на консоли сервера:

Message from [email protected] at Dec 21 18:27:20 ...
 haproxy[1650]: proxy Server-A has no server available!

Обратите внимание, что в 90% случаев ошибок нет. Эти ошибки происходят случайным образом.

Ответ 1

У меня была такая же проблема. После нескольких дней вытягивания волос я нашел проблему.

У меня было два экземпляра HAProxy. Один из них был зомби, который так или иначе никогда не был убит во время обновления или перезапуска haproxy. Я заметил это при обновлении страницы /haproxy stats и PID изменился бы между двумя разными номерами. На странице с одним из номеров была абсурдная статистика соединений. Чтобы подтвердить, что я сделал

netstat -tulpn | grep 80

и увидел два процесса haproxy, прослушивающих порт 80.

Чтобы исправить проблему, я сделал "kill xxxx", где xxxx является pid с подозрительной статистикой.

Ответ 2

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

Если у вас есть другие проблемы, проверьте вашу конфигурацию и посмотрите, не ошиблись ли вы, поместив одну и ту же строку "bind" в несколько разделов вашей конфигурации. Haproxy не проверяет это во время запуска, и я планирую отправить это в качестве рекомендуемой проверки проверки разработчикам. В моем случае у меня есть 3 различных раздела конфигурации, и я по ошибке поместил одну и ту же привязку IP в двух разных местах. Речь шла о 50/50 о том, будет ли использоваться правильный раздел или неправильный раздел. Даже когда был использован правильный раздел, около половины запросов все равно получили 503.

Ответ 3

Возможно, ваши серверы разделяют, возможно, общий ресурс, который тайминг в определенные моменты времени, и что ваши запросы проверки работоспособности выполняются одновременно (и, таким образом, одновременно выводятся серверы backend).

Вы можете попробовать использовать опцию HAProxy spread-checks для рандомизации проверок работоспособности.

Ответ 4

У меня была такая же проблема, из-за 2 HAProxy-сервисов, работающих в Linux-окне, но с разными именами /pid/resources. Если я не остановлю нежелательный, требуемые экземпляры случайным образом выбрасывают 503 ошибки, скажем, 1 раз в 5 раз.

Пробовал использовать один linux-бокс для множественной маршрутизации URL-адресов, но выглядит как ограничение в haproxy или файл конфигурации haproxy, который я определил.

Ответ 5

Сложно сказать без каких-либо подробностей, но возможно ли, что вы превысили настроенное максимальное соединение для каждого бэкэнд? Пользовательский интерфейс статистики показывает эти параметры как на интерфейсе, так и на отдельных бэкэндах.

Ответ 6

Я решил свои прерывистые 503 с HAProxy, добавив option http-server-close к backend. Похоже, что uWSGI (который является upstream) не очень хорошо работает с keep-alive. Не уверен, что на самом деле стоит за проблемой, но после добавления этой опции, не видел ни одного 503 с тех пор.