☰

当服务器场中的一台服务器宕机时，haproxy 不会进行负载平衡

tag-icon • tag-icon load-balancing haproxy ubuntu-14.04
当服务器场中的一台服务器宕机时，haproxy 不会进行负载平衡

我有三个使用 HAProxy 进行负载平衡的后端服务器。

当所有这 3 个服务器都启动时，我会在 HTTPS 响应中连续看到每个服务器的 ID (1,2,3)。即 1,2,3,1,2,3。正如预期的那样。

但是，如果我关闭一台后端服务器，那么我只会重复看到一个服务器 ID。

即，如果我关闭服务器 1，那么我只会看到服务器 ID 2 (2,2,2,2...)，而我应该看到服务器 ID 2,3 (2,3,2,3,2,3.....)

我已经尝试了 leastconn 和 round robin 平衡，并且都表现出相同的行为

HAProxy 为何会如此表现？如何更改 HAProxy 配置以在剩余的活动后端服务器之间实现负载平衡？

HA 代理版本为 1.6.9。HA 代理服务器为 ubuntu 14.04。

所服务的 HTTP 是一种通过 HTTPS 返回一些 JSON 的 API。它是一个 restful API，因此不需要或不需要会话持久性。

haproxy 的配置如下。

 global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    maxconn 3072
    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private
    # Default ciphers to use on SSL-enabled listening sockets.
    # For more information, see ciphers(1SSL). This list is from:
    #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
    ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH$
    ssl-default-bind-options no-sslv3
defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    option dontlog-normal
    option redispatch
    retries 3
    maxconn 3072
    timeout connect 5000
    timeout client  10000
    timeout server  10000

frontend apis-frontend
    bind x.x.x.x:443 ssl verify none crt /etc/haproxy/xxx
    mode http
    option forwardfor
    default_backend apis

backend apis
    balance leastconn
    mode http
    option httpchk GET /
    server 1 x.x.x.x:443 ssl verify none check
    server 2 x.x.x.x:443 ssl verify none check
    server 3 x.x.x.x:443 ssl verify none check

listen stats
    bind *:8181
    mode http
    stats enable
    stats uri /
    stats realm Haproxy\ Statistics
    stats auth xx

编辑：添加统计数据。

pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,check_status,check_code,check_duration,hrsp_1xx,hrsp_2xx,hrsp_3xx,hrsp_4xx,hrsp_5xx,hrsp_other,hanafail,req_rate,req_rate_max,req_tot,cli_abrt,srv_abrt,comp_in,comp_out,comp_byp,comp_rsp,lastsess,last_chk,last_agt,qtime,ctime,rtime,ttime,
apis-frontend,FRONTEND,,,0,2,3072,24,9118,10021,0,0,19,,,,,OPEN,,,,,,,,,1,2,0,,,,0,0,0,4,,,,0,24,0,19,0,0,,0,6,43,,,0,0,0,0,,,,,,,,
apis,mt-wol-vlx-vps-01,0,0,0,1,,12,4863,3240,,0,,0,0,0,0,UP,1,1,0,1,0,12097,0,,1,3,1,,12,,2,0,,2,L7OK,200,36,0,12,0,0,0,0,0,,,,0,0,,,,,39,OK,,0,1,1,29,
apis,mt-lon-vlx-vps-01,0,0,0,1,,12,4255,3228,,0,,0,0,0,0,UP,1,1,0,0,0,12097,0,,1,3,2,,12,,2,0,,2,L7OK,200,23,0,12,0,0,0,0,0,,,,0,0,,,,,39,OK,,0,1,1,5,
apis,mt-cov-uks-vps-01,0,0,0,0,,0,0,0,,0,,0,0,0,0,DOWN,1,1,0,1,1,12094,12094,,1,3,3,,0,,2,0,,0,L4TOUT,,2001,0,0,0,0,0,0,0,,,,0,0,,,,,-1,,,0,0,0,0,
apis,BACKEND,0,0,0,1,308,24,9118,6468,0,0,,0,0,0,0,UP,2,2,0,,0,12097,0,,1,3,0,,24,,1,0,,3,,,,0,24,0,0,0,0,,,,,0,0,0,0,0,0,39,,,0,1,1,33,
stats,FRONTEND,,,1,4,3072,10,3811,169181,0,0,5,,,,,OPEN,,,,,,,,,1,4,0,,,,0,1,0,4,,,,0,9,0,5,0,0,,1,3,15,,,0,0,0,0,,,,,,,,
stats,BACKEND,0,0,0,0,308,0,3811,169181,0,0,,0,0,0,0,UP,0,0,0,,0,12097,0,,1,4,0,,0,,1,0,,0,,,,0,0,0,0,0,0,,,,,0,0,0,0,0,0,0,,,0,0,0,18,

编辑：不同浏览器中的负载平衡行为

在从不同的 IP 发出测试请求后。我注意到第二个 IP 的负载平衡与预期一致。然后我尝试从第一个 IP 进行测试，但使用不同的浏览器 edge 和 firefox。edge 和 firefox 的负载平衡均与预期一致。

然而，原版 Chrome 浏览器仍然坚持使用一个后端服务器。即使关闭所有 Chrome 窗口并重新启动 Chrome

答案1

经过进一步测试，仅在使用 Google Chrome 浏览器时才会出现上述行为。Chrome 为何会出现此行为尚不确定。

观察到的行为不是 HAProxy 问题。

已使用其他浏览器和其他客户端进行了多次测试。最终验证是几个小时的实时服务。

上述 HAProxy 配置已运行了几个小时，并在三台服务器之间公平分配流量。这从记录服务器 ID 的数据库记录中可以看出。在几个小时的时间内，每台服务器分配了相同数量的请求，大约 4,500 个请求，误差在 +- 50 以内。

更重要的是，考虑到最初的问题，如果其中一台服务器发生故障，它还会继续公平地分配给另外两台服务器。我们的数据库记录再次证明了这一点，其中记录了服务器 ID。当测量超过 15 分钟时，可以在我们的数据库记录中看到一个清晰的均衡服务器 ID 模式。

一个深刻的提醒是，在假设问题出在您尚不了解的解决方案的部分之前，设计测试以查明问题所在。

感谢大家的多次回复，让我意识到了这一点。

相关内容