出于某种原因，使用wlc或lc调度程序时，ipvsadm似乎没有同样平衡我的真实服务器之间的连接。 一个真正的服务器获得绝对的请求，而其他人收到相对较less的连接。
我的ldirectord.cf文件如下所示：
quiescent = yes autoreload = yes checktimeout = 10 checkinterval = 10 # *.example.com http virtual = 192.0.2.111:http real = 10.10.10.1:http ipip 10 real = 10.10.10.2:http ipip 10 real = 10.10.10.3:http ipip 10 real = 10.10.10.4:http ipip 10 real = 10.10.10.5:http ipip 10 scheduler = lc protocol = tcp service = http checktype = negotiate request = "/lb" receive = "Up and running" virtualhost = "site.com" fallback = 127.0.0.1:http 奇怪的事情，我认为可能导致的问题（但我真的不知道）是ipvsadm似乎并没有正确跟踪活动连接，他们都显示为不活动的连接
IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.0.2.111:http lc -> 10.10.10.1:http Tunnel 10 0 10 -> 10.10.10.2:http Tunnel 10 0 18 -> 10.10.10.3:http Tunnel 10 0 3 -> 10.10.10.4:http Tunnel 10 0 10 -> 10.10.10.5:http Tunnel 10 0 5
如果我做ipvsadm -Lnc然后我看到很多的连接，但只有在ESTABLISHED和FIN_WAIT状态。
以前我在一个基于Gentoo的负载平衡器上使用ldirectord，而activeconn以前是准确的，因为转移到Ubuntu 10.4 LTS似乎有所不同。
# ipvsadm -v ipvsadm v1.25 2008/5/15 (compiled with popt and IPVS v1.2.1)
那么，ipvsadm没有正确地跟踪活动连接，从而使负载平衡工作不正确，如果是这样，我怎么得到它再次正常工作？
编辑：它变得更加怪异，如果我cat /proc/net/ip_vs那么它看起来像正确的activeconns在那里：
IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP C000026F:0050 rr -> 0AB42453:0050 Tunnel 10 1 24 -> 0AB4321D:0050 Tunnel 10 0 23 -> 0AB426B2:0050 Tunnel 10 2 25 -> 0AB4244C:0050 Tunnel 10 2 22 -> 0AB42024:0050 Tunnel 10 2 23
使用lc（最less连接）如果所有服务器具有相同数量的连接，则它将始终给列表中的第一个服务器提供新的连接。 这可能意味着，如果您的利用率很低，并且每隔一段时间只有一个连接，则该连接将始终转到列表中的第一个主机。
我最喜欢的是（轮回罗宾）。 我是否正确地假设你正在使用DR方法（直接路由）？
在这种情况下，ipvsadm不会看到这样的连接，因为来自RS（真实服务器）的答案将直接发送到客户端 – 而不是通过LB返回。
从你的连接数来看，这对你来说可能不是问题，但是如果一台真实服务器比其他服务器的响应速度慢，那么你可能得到的连接数量不均匀分布不均匀，它会更快地连接到连接上。
David的命令输出表明他正在使用隧道模式（IPIP），通常将其设置为DR的变体。 我们需要看一些路由表或图表来更好地理解他的设置。
但我同意，可能在LVS中的连接跟踪是混乱的，因为它没有看到TCP FIN数据包。
ipvsadm有一些设置来更快地超时过期的连接。 例如，以下命令将在1小时后超时不活动的连接：
/sbin/ipvsadm --set 3600 120 300
客户的来源应该重复检查。 LVS的默认行为是通过客户端IP进行持久连接。 因此，如果使用wget或ab从相同的testing客户端IP进行压力testing，所有的连接都将被发送到同一个realserver。
Haproxy是一个更智能的负载平衡器，但需要坐在数据包的返回path中才能完全透明地工作。