在探讨这个问题前,我们先假设一种经典的连接模型:Client -> Load Balancer-> RealServer Pool,并且我们假设这里使用NAT模式的负载均衡,在这种模式下:
我们从Client Side(Client->Load Balancer)来分析:
这端的连接都由SourceIP:SoucePort->DesIP:DesPort唯一标识,所以对我们来说,能支持的连接数仅仅受限于负载均衡器的内存数(连接数可以是65000+),因为DesIP和DesPort都是已知的唯一的(比如IP:80).
再从Server Side(Load Balancer->RealServer)来分析:
这端的连接数刚好相反,每个连接都由负载均衡器的IP(这里称MIP:Mapped IP)和随机的端口进行标识。
即: MIP:RandomPort -> RealServerIP:80
这样,因为负载均衡器的端口也受限于TCP/IP的最大端口数64k(65536)限制,因此最多只能建立64k的服务器连接(server connnections).
由于瓶颈很可能就出现在服务器端连接上,针对这种情况,各负载均衡器厂家是怎么解决的呢?
1. NetScaler
我们首先来看NetScaler的解决办法,NetScaler的解决办法很简单,增加MIP的个数,这样最大的服务器连接数将变成:MaxServerConnections = 65536 * MIP数
2. F5
F5其实也使用了一样的办法,但是F5首先建立一个Source-NAT pool,然后在SNAT Pool里面加入多个IP地址。这样得到的最大连接数和NetScaler完全一样:
上述情况都是理论计算值,真实环境下的最大连接数还受限于各种因素:
文章转载来自:trustauth.cn
上一篇:服务器处理性能估算方法
下一篇:Redis主从在线互相切换