☰

haproxy tcp roundrobin 负载平衡未按预期工作

tag-icon • tag-icon haproxy
haproxy tcp roundrobin 负载平衡未按预期工作

我是 haproxy 的新手，使用它来将 rsyslog 日志的 TCP 负载平衡到 ArcSight 连接器。就我而言，我无法让流量在池中的所有节点之间均匀平衡（这是理想的行为）。我尝试了许多权重和 maxconn 的排列，但都无济于事。

感觉这应该是一个简单的问题，但每个池节点的行为非常令人困惑。此外，由于大多数人使用 haproxy 进行 http 负载平衡，我发现关于如何最好地完成我所尝试做的事情的文档很少。

有人有任何见解、经过验证的配置或故障排除步骤可以推荐吗？

谢谢！

这是我们当前的配置：

global
    log 127.0.0.1       local0
    log 127.0.0.1       local1 notice
    maxconn 256000
    user haproxy
    group haproxy
    spread-checks 5
    daemon
    quiet

defaults
    log global
    option dontlognull
    option redispatch
    option allbackups
    maxconn 256000
    timeout connect 5000

listen stats :1936
    mode http
    stats enable
    stats realm Haproxy\ Statistics
    stats uri /
    stats auth admin:savetheday

frontend rsyslog_netscreen
    bind 127.0.0.1:8514
    mode tcp
    option tcplog
    option contstats
    option tcpka
    default_backend rsyslog_netscreen_backend

backend rsyslog_netscreen_backend
    balance roundrobin
    mode tcp
    option tcpka
    option srvtcpka
    server netscreen1 localhost:9515 weight 1 maxconn 1024 check
    server netscreen2 localhost:9516 weight 1 maxconn 1024 check
    server netscreen3 localhost:9517 weight 1 maxconn 1024 check
    server netscreen4 localhost:9518 weight 1 maxconn 1024 check
    server netscreen5 localhost:9519 weight 1 maxconn 1024 check
    server netscreen6 localhost:9520 weight 1 maxconn 1024 check

答案1

请注意，这roundrobin不是实现均匀负载的好策略。它将确保每个后端都收到相同的数字随着时间的推移，连接数会增加，但不关心每个连接持续多长时间。

在您stats看来，每个后端服务器的会话总数应该几乎相等（如果它们的正常运行时间相等）。但是，当前会话数可能会有很大差异。

我们发现使用leastconn而不是roundrobin会产生更均匀的负载。这是有道理的，因为服务器恰好被许多长期存在的客户端所困扰，这些客户端保持着连接，因此不需要承受新的传入连接的负担。

答案2

对于短寿命连接使用 roundrobin，对于相当长寿命连接使用 leastconn。

相关内容