关于何时使用roundrobin
以及何时使用有什么建议吗leastconn
?
我目前正在使用roundrobin
,发现后端服务器的负载分布不均匀。当然可能还有其他问题,但我们想尝试一下leastconn
,但由于这是一台关键任务服务器,我想在进行更改之前咨询其他经验。
有什么想法可以分享吗?
答案1
我没有尝试过 leastconn,但我的理解是 leastconn 的典型用例是当你对可以有长连接的东西进行负载平衡时。原因是 leastconn 专注于确保平衡并发而客场罗宾将提供更平衡的到达率。如果这个区别不明显,请参阅我关于差异的回答。
当您说负载分布不均匀时,对“负载”进行更好的定义可能会有所帮助。如果您指的是服务器资源,那么我建议确定导致负载增加的确切原因(即某些类型的连接),然后从那里开始反向分析。
答案2
这取决于协议和要平衡的用例。对于任何连接数量与负载/使用量相关的情况,最好使用leastconn
。由于网络和应用程序的工作方式,它几乎总是正确的,您最好leastconn
默认使用。
RDP/X11 远程桌面/Jump Hosts
例如,一家公司拥有一个员工可以连接的远程桌面池。您希望员工可以均匀地分布在各个桌面上。
该用例中的活动连接数大致等于“当前有多少员工正在使用该桌面”。连接数最少的主机使用的员工也最少,因此负载可能也是最低的。在这种情况下使用“leastconn”,它会根据用户数量均匀地分配负载。
理想的负载均衡器应该了解远程桌面负载。有多少用户?有多少应用程序?消耗了多少内存和 CPU?有专门用于远程桌面的商业解决方案(Microsoft/Citrix/etc...),它们通常会测量这些指标以很好地分散使用量。HAProxy 是一个简单的网络负载均衡器,它所能做的最好的就是使用 来计算连接数leastconn
。
HTTP / HTTPS
对于 HTTP,活跃连接意味着服务器正忙于处理请求。连接数与负载成正比。您需要选择活跃连接数(正在进行的请求)最少的服务器。用于leastconn
HTTP(S) 流量。
想象一下有两个 HTTP 服务器的情况,其中一个服务器处理请求较慢(可能超载,可能硬件较旧)。
roundrobin
将在两台服务器之间平分请求。这非常低效,较快的服务器应该承担更多。更糟糕的是,较慢的服务器可能会超载,随着更多请求的到来,它会变得更慢,并且可能随时开始丢弃请求。你不希望这样。
leastconn
会检测到服务器不均衡。较慢的服务器保持连接的时间更长,其连接数更高。leastconn
考虑到这一点,它会优先选择另一台服务器。
根据我的经验,包括我专门为中型到大型网站进行性能测试的角色。leastconn
效率可以是roundrobin
HTTP(S) 的 300%。roundrobin
不能公平地分配连接,并且会在高负载下导致不稳定。
DNS 请求
(我们忽略HAProxy不支持UDP,并且UDP是无连接的)。
最后一个例子。DNS 是一个简单的协议。客户端发送一条 UDP 消息来请求域,DNS 服务器以一条消息回复。
在这种情况下,实际上没有连接。即使有,也会立即关闭(理论上)。
在这种情况下计算连接数是没有意义的,这不是最佳选择leastconn
。简单的roundrobin
就可以分发消息。
常见的误解
人们有时认为它们不应该用于leastconn
短时间连接(类似于上一个示例)。甚至 HAProxy 文档也对此有误导。
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
在现实世界中,short connections
不是一个东西。
应用程序建立在 TCP 之上。消息按顺序传递和处理。当服务器速度慢或过载时,“短”连接会变长。如果有(更多)连接,则可能正在执行(更多)工作。连接数和连接持续时间各不相同,且有意义。
想象一下一个基本的 HTTP 服务器。一些资产需要几毫秒,一些 API 调用需要几秒钟,一个页面可能需要任何时间来加载,其中包含任何数量的请求,等等。请求不是短暂的,它们的生命周期取决于在哪个服务器上处理的内容。leastconn
了解正在进行的活动并调整分布,这正是您希望从负载平衡器中获得的。
答案3
当与没有相同硬件的服务器进行循环时,您应该调整每台服务器的权重,并使用 maxconn 作为保障。
server www0 192.168.1.10:3001 maxconn 20 weight 60
server www1 192.168.1.10:3002 maxconn 10 weight 40
关于 leastconn,您应该相信 haproxy 文档,而不是“leastconn”名称的含义。
根据经验,它在短暂的 HTTP 连接上无法按预期工作(它可以工作,但不如预期)。
就我而言,我在使用新服务器时遇到了问题,或者当 haproxy 降级/升级服务器时,新服务器会受到新连接的重击,而无响应的服务器可能会吸收所有新连接,直到它们被降级,从而导致更多失败的 HTTP 请求。