16

我们设置了 3 台服务器：

  • 服务器 A 使用 Nginx + HAproxy 进行负载均衡
  • 后端服务器 B
  • 后端服务器 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

三台服务器都有大量的 RAM 和 CPU 内核来处理请求

浏览时显示随机 HTTP 503 错误：503 Service Unavailable - No server is available to handle this request.

并且也在服务器的控制台上：

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

请注意，90% 的时间没有错误。这些错误是随机发生的。

4

7 回答 7

29

我遇到过同样的问题。经过几天拔头发后，我发现了问题。

我有两个 HAProxy 实例正在运行。一个是僵尸，在更新或 haproxy 重启期间不知何故从未被杀死。我在刷新 /haproxy 统计页面时注意到了这一点，并且 PID 会在两个不同的数字之间变化。带有其中一个数字的页面具有荒谬的连接统计信息。确认我做了

netstat -tulpn | grep 80

或者

sudo lsof -i:80

并看到两个 haproxy 进程正在监听端口 80。

为了解决这个问题，我做了一个“kill xxxx”，其中 xxxx 是带有可疑统计信息的 pid。

于 2015-06-17T17:24:40.587 回答
9

在此处为遇到此完全相同问题但以上列出的解决方案均不适用的其他任何人添加我的答案。请注意，我的回答不适用于上面列出的原始代码。

对于其他可能遇到此问题的人，请检查您的配置，看看您是否错误地将相同的“绑定”行放在配置的多个部分中。Haproxy 不会在启动期间进行检查，我计划将此作为推荐的验证检查提交给开发人员。就我而言，我有 3 个不同的配置部分，我错误地将相同的 IP 绑定放在两个不同的地方。关于是否使用正确的部分或使用不正确的部分，大约是 50/50。即使使用了正确的部分，大约一半的请求仍然得到 503。

于 2018-03-06T16:43:07.607 回答
1

您的服务器可能共享一个在特定时间超时的公共资源，并且您的健康检查请求正在同时发出（因此同时将后端服务器拉出）。

您可以尝试使用 HAProxy 选项spread-checks来随机进行健康检查。

于 2013-11-13T05:50:09.567 回答
1

我遇到了同样的问题，因为 linux 机器上运行了 2 个 HAProxy 服务，但名称/pid/resources 不同。除非我停止不需要的实例，否则所需的实例会随机抛出 503 错误，例如 5 次中的 1 次。

试图使用单个 linux 框进行多个 URL 路由，但在 haproxy 或我定义的 haproxy 配置文件中看起来存在限制。

于 2015-07-22T20:08:36.860 回答
0

很难说没有更多细节，但是您是否有可能超出每个后端配置的 maxconn？Stats UI 在前端和单个后端显示这些统计信息。

于 2013-10-01T09:04:20.063 回答
0

option http-server-close我通过添加到后端解决了我使用 HAProxy 的间歇性 503 。看起来uWSGI（上游）在keep-alive方面做得不好。不知道问题的真正原因是什么，但是在添加了这个选项之后，从那以后就再也没有看到过单一的 503 了。

于 2019-07-05T12:26:09.190 回答
0

例如，不要在 haproxy.cfg 的多个部分中使用“绑定”行，这是错误的

frontend stats
bind *:443 ssl crt /etc/ssl/certs/your.pem
frontend Main
bind *:443 ssl crt /etc/ssl/certs/your.pem

像这样修复

frontend stats
bind *:8443 ssl crt /etc/ssl/certs/your.pem
frontend Main
bind *:443 ssl crt /etc/ssl/certs/your.pem
于 2021-02-27T13:21:30.457 回答