利用MBLB解决TCP长连接负载均衡测试方案Word格式.docx
《利用MBLB解决TCP长连接负载均衡测试方案Word格式.docx》由会员分享，可在线阅读，更多相关《利用MBLB解决TCP长连接负载均衡测试方案Word格式.docx（36页珍藏版）》请在冰豆网上搜索。
rulesmblb-basic
profiles{
mblb{}
tcp{}
}
}
pooltest_pool{
monitoralltcp_half_open
members{
60.247.114.34:
9000{}
9001{}
注意mblb的Profile是手工加入的，在图形界面里没有配置。
另外对于这种类型的Server，最好使用tcp_half_open健康检查模式。
rulemblb-basic{
whenCLIENT_ACCEPTED{
TCP:
:
collect
whenCLIENT_DATA{
release
notifyrequest
#log"
client_datatrigered"
whenSERVER_CONNECTED{
whenSERVER_DATA{
notifyresponse
Server_datatrigered"
BIGIPMBLB工作原理：
客户端首先与BIGIP建立TCP连接，在客户端发送数据的时候，BIGIP根据交易将客户端请求发送到不同的服务器，在发送前，BIGIP将与后台服务器建立连接。
在这种工作模式下，可以支持同步阻塞模式交易或者同连接里的异步交易。
同步工作模式：
Client1Request
Server1Response
Client2Request
Server2Response
异步工作模式：
Server2Response-
Server3Response
在异步工作模式下，不能用下面测试的简单irules，需要使用iRules来判断每个交易的边界，以便将每笔交易请求分发到不同的服务器上。
下面的测试基于小包状态，也就是每笔交易的长度不超过1个MTU，通常情况下是1460字节的情况，在这种情况下，在一次CLIENT_DATA事件触发的时候就可以接收到整个的交易请求或者交易回应。
2.V10MBLB测试过程
TCP连接测试
首先启动两台Server，分别侦听9000和9001端口
确认在BIGIP里显示两台服务器都是工作的。
Bconn显示没有任何的链接产生
[root@ltm3600:
Active]config#bconn
60.247.98.162:
14774<
->
60.247.114.44:
ssh<
sshtcp1/0
上面的那个连接是我的SSH登录产生的。
启动客户端，配置好发送的内容，点击Connect
观察BIGIP上的连接状态：
60.247.114.34:
4933<
60.247.114.43:
9000<
any6tcp1/1
在客户端没有发送数据之前，在BIGIP上只有一个Client-Any6的连接，此时客户端还没有发送数据，因此BIGIP与后台并不建立连接。
交易分发测试
点击客户端上的发送按钮
观察客户端的收发状态
观察Server端收发状态
观察BIGIP上的连接状态
any6<
9000tcp1/1
9001tcp1/1
可以看到，在客户端开始发送数据后，BIGIP分别和两台Server建立了连接，并将客户端的请求以轮询的方式发送到两台服务器上。
由于我在这里启用了SNAT，因此可以看到第一个Server连接是使用的客户端源端口和服务器建立连接，第二个客户端连接使用的另外一个源端口和服务器建立连接。
启动第二个客户端的连接建立过程及Timeout
启动第二个客户端建立连接
观察BIGIP状态
1088<
any6tcp1/0
怎么没有Server端连接了呢？
看看Server端日志，原来由于俺写文章的时间太长，被BIGIPtimeout了。
好，现在就让C2开始发送数据
看到Server端又开始建立连接了
BIGIP上的连接状态：
9001tcp1/0
9000tcp1/0
现在开始启动C1发送数据
C1的连接也被断掉了：
重新启动C1并连接
BIGIP上状况：
1144<
当C1开始发送数据的时候：
Server上的状态：
可以看到BIGIP针对每一个客户端连接，分别在每台Server上建立了同样数量的连接，并将请求在这些连接里进行分发。
加入新的客户端观察负载均衡算法
我们再启动C3,看看有什么状况？
BIIGP
1231<
当C3开始发送数据的时候：
Server状态：
两台Server都收到了C3的请求
BIGIP上显示3个clientconnection,6个Serverconnection:
在S2上收到的是C1和C2的请求
在S1上收到的是C1和C3的请求
停止所有的客户端，然后全部重新发送的时候，Server端接收发生了变化：
S1上收到的是C1和C2的请求
S2上收到的是C1和C3的请求
应该是RoundRobin的算法导致了这种现象的出现
BIGIP上的连接没有发生变化：
1271<
手工Disable服务器测试
现在手工Disable一台服务器
在S1上收到了3个客户端的请求
恢复disable的服务器：
S1收到了C1和C2的请求：
S2重新开始接受请求，收到C1和C3的请求
关闭服务器测试
关闭S2
所有的Client和Server都崩溃了
等待服务器程序的改进版本中。
。
V10MBLB测试总结
BIGIPV10已经具备了MBLB的处理能力，可以对长连接里面的TCP交易进行拆分处理，将不同的请求发送到不同的服务器上，并将服务器的返回信息发送到正确的客户端。
目前发现的一些可能存在的问题：
1、对于每个客户端的长连接，BIGIP将在每个Server上建立一个连接，也就是说对于每台Server而言，都会有所有的客户端连接数的总和数量的连接，在实际应用中，需要确定服务器是否能处理全部客户端连接数量的连接数。
2、关于交易的边界定义，目前的测试中非常简单的使用了CLIENT_DATA和SERVER_DATA事件，这两个事件默认情况下是每接收一个数据包就触发一次，因此在交易小于1个MTU，通常情况是1460byte的情况下，可以不用区分交易边界，默认认为一个数据包就是一次交易。
3、如果每次发送交易的长度大于1460，就需要用irules去获取和判断交易的长度。
具体的做法是在第一个数据包进来的时候查询数据包中对于交易长度的定义，然后判断当前收集到得数据是否是完整的交易，如果完整，则释放请求，如果不完整，则继续进行收集，直到收集到足够的数据后，释放交易长度的内容到服务器。
4、目前测试的应用时阻塞类型的应用，也就是Client必须等待Server应答之后才开始发送下一个请求，而且数据包都比较小，肯定在一个packet就发送完毕，因此不存在有边界界定的问题
5、如果有非阻塞型应用，也就是客户端可能一次发出多个请求，在不等待server回应的情况下可以持续发出请求，Server回应也是不等待的情况，从目前的连接状况分析也是可以工作的。
但可能需要进一步的编程处理来确定每一个交易的边界
6、对于目前客户所要求的Disable服务器之后，所有的交易可以正常转发到其他服务器的需求是可以满足的。
7、基本确认这种MBLB工作模式和OneConnect在目前测试配置中不能同时工作，因此当客户端关闭连接时，这个客户端对应的所有服务器连接都会被关闭。
8、从目前了解到得信息，OneConnect工作模式下可以彻底的区分客户端连接和服务器端连接的关系，但服务器端的连接数量在OneConnect模式下无法控制。
9、由于测试服务器软件问题，没有测试到Server端主动关闭连接，是否会造成客户端连接中断。
另外，当一台server故障，而在健康检查还没有检查到服务器故障期间的交易如何处理目前测试环境中也无法测试。
我的初步考虑是用inbandmonitor来解决普通Monitor的间隔周期和检查周期的问题。
10、还没有测试会话保持的情况，比如根据每个交易里的一些内容进行会话保持，还需要改进一下客户端和服务器软件
附：
TCPdump数据包分析
客户端数据包发送和接收
包25,26,27为三次握手建立连接
149开始，客户端发送数据PSH,ACK，
157为客户端收到一个BIGIPACK，没有内容，表明Server已经收到客户端内容
159BIGIP给客户端发送数据PSH,ACK
161客户端给BIGIP发送ACK,表明数据已经收到
163客户端等待1000ms后开始下一个数据包发送
服务器端数据包发送和接收
152，153，154为BIGIP和后台服务器三次握手建立连接，结合客户端连接建立时间，可以看到BIGIP一直等待到客户端有数据发送了才开始和后台建立连接
155BIGIP给服务器端发送数据PSH,ACK
158服务器回应BIGIP数据PSH,ACK
160BIGIP发送给服务器端ACK，表明数据已经收到
164在1000ms以后，BIGIP重新开始给服务器端发送数据包。
数据流程图：
比较有意思的地方：
157和160看上去是BIGIP产生的主动发给客户端和服务器的ACK
161从客户端发给BIGIP，但被BIGIP吞掉了。
俺的TCP理论研究还不是很深刻，是不是一些协议性的东西导致必须这样工作？
3.OneConnect工作模式测试
在前面的测试中，MBLB可以支持异步交易，但在一些同步工作模式下，应用希望两边的连接不存在有太大的关联性，前面一种模式客户端连接一旦中断后，服务器端这个客户端相关连接会全部中断。
通过OneConnect工作模式，可以消除掉这种强制的绑定关系，而使服务器端的连接不会和客户端强制绑定。
因此可以在客户端是长连接和短连接模式下，BIGIP始终保持和后台服务器是长连接的结构。
OneConnect工作模式只支持同步阻塞模式下的TCP连接，即客户端必须等待Server端回应请求之后，再发送下一个请求。
每笔交易都是以ClientRequest->
ServerResponse的方式工作。
和前面的MBLB工作模式最大的不同是OneConnect可以在V9版本下工作。
测试的结构不变，但BIGIP上配置有一些变化
rulesone_connect_rule
oneconnect{}
注意在VS里面必须绑定OneconnectProfile
ruleone_connect_rule{
LB:
detach
OneConnect模式的工作原理
在上图中是以HTTP协议为例，但实际上通过iRules，也可以支持任何协议类型，包括用户自行开发的TCPSocket应用。
当第一个client连接到BIGIP开始发送请求的时候，BIGIP会以这个client的源IP地址和后台服务器建立一个连接，并把客户端的Request转发到服务器。
此时客户端连接和服务器的TCP连接形成了绑定的关系。
当服务器响应了Response之后，由于BIGIP可以识别HTTPResponse，因此，当BIGIP检查到服务器端的Response结束了之后，就拆除了第一个ClientTCP连接和服务器TCP连接之间的对应关系。
即使在客户端关闭连接的情况下，BIGIP和后台服务器的TCP连接也保持Open的状态。
当下一个用户和BIGIP建立连接并发送请求的时候，BIGIP会在当前和后台服务器之间的TCP连接里面挑选一个空闲的连接（当然，还需要满足会话保持、负载均衡的算法的前提下），将第二个用户的Request塞到空闲的连接里面发送到服务器，这时，第二个用户的客户端连接和为第一个客户端建立的服务器连接就形成了新的对应关系。
在第二个用户的Response结束之后，BIGIP又拆除其对应关系。
如果第三个用户连接和请求到达BIGIP的时候，第二个用户的Response并没有结束，也就是当前BIGIP和后台没有空闲连接的时候，BIGIP就会和服务器端再建立一个新的TCP连接，传送第三个客户端的请求到服务器。
如果第四个用户连接和请求到达BIGIP的时候，第二个用户的Response传输完成了，第四个用户就会再使用空闲的后台服务器连接进行请求传输。
这样，当客户端不停的建立连接，拆除连接的时候，BIGIP始终可以保持较少的后台服务器连接。
BIGIP在这里面完成的工作主要就是根据Response结束和新的用户请求到达的时刻点，来切换连接的不同连接对应关系。
首先看看BIGIP上的VS状态，看加入了oneconnectrules之后是否会DisableCMP
+->
VIRTUALtest_vsSERVICE9000
|PVAaccelerationnone
|CMPenableonnonemode:
all
看上去还好，CMP属于enable状态
启动S1
启动S2
启动客户端C1，并建立连接
BIGIP上的连接状态
Active]config#
升级会员 