F5长连接测试

1、 测试记录F5 BIGIP MBLB 杨明非 F5北京 8月年2009 目录 1. 测试环境 . 3 1.1 测试环境准备 . 3 1.2 测试网络拓扑 . 3 1.3 BIGIP MBLB工作原理： . 4 2. V10 MBLB 测试过程 . 5 2.1 TCP连接测试 . 5 2.2 交易分发测试 . 6 2.3 启动第二个客户端的连接建立过程及Timeout . 8 2.4 加入新的客户端观察负载均衡算法 . 10 2.5 手工Disable服务器测试 . 12 2.6 关闭服务器测试 . 13 2.7 V10 MBLB 测试总结 . 14 2.8 附：TCPdump数据包分析 . 1

2、4 3. One Connect工作模式测试 . 16 3.1 One Connect模式的工作原理 . 17 3.2 TCP连接测试 . 17 3.3 交易分发测试 . 19 3.4 启动第二个客户端的连接 . 20 3.5 启动多个客户端观察负载均衡算法 . 22 3.6 手工Disable 服务器测试 . 24 3.7 重新Enable服务器 . 25 3.8 关闭服务器测试 . 28 3.9 One Connect模式测试总结： . 29 4. 附录 . 29 4.1 如何使用iRules来判断交易边界 . 29 4.2 关于交易定向发送 . 31 4.3 关于会话保持 . 31 4.

3、4 两种模式的对比 . 32 4.5 还需要研究的部分 . 33 2 1. 测试环境 1.1 测试环境准备 PC server一台，安装Windows 2003 Server. BIGIP 1台，安装10.0.1版本 TCP Client/Server软件 1.2 测试网络拓扑 也运行在同一台设备上。通和TCP client Server所有的IP地址均在同一个网段内， Client。过启动多个不同的实例来模拟多台Server和 配置测试用BIGIPvirtual test_vs snat automap pool test_pool destination 3:900

4、0 ip protocol tcp rules mblb-basic profiles mblb tcp pool test_pool monitor all tcp_half_open members 4:9000 4:9001 3 是手工加入的，在图形界面里没有配置。另外对于这种类型的Profile注意mblb的 健康检查模式。Server，最好使用tcp_half_openrule mblb-basic when CLIENT_ACCEPTED TCP:collect when CLIENT_DATA TCP:release TCP:not

5、ify request #log client_data trigered TCP:collect when SERVER_CONNECTED TCP:collect when SERVER_DATA TCP:release TCP:notify response #log Server_data trigered TCP:collect BIGIP MBLB工作原理：1.3 根据交易将客户在客户端发送数据的时候，TCPBIGIP客户端首先与建立连接，BIGIP 4 端请求发送到不同的服务器，在发送前，BIGIP将与后台服务器建立连接。在这种工作模式下，可以支持同步阻塞模式交易或者同连接里的异

6、步交易。 同步工作模式： Client1 Request Server1 Response Client2 Request Server2 Response Client1 Request Server2 Response 异步工作模式： Client1 Request Client2 Request Client1 Request Server1 Response Server2 Response- Server3 Response 在异步工作模式下，不能用下面测试的简单irules，需要使用iRules来判断每个交易的边界，以便将每笔交易请求分发到不同的服务器上。 下面的测试基于小包状态，

7、也就是每笔交易的长度不超过1个MTU，通常情况下是1460字节的情况，在这种情况下，在一次CLIENT_DATA事件触发的时候就可以接收到整个的交易请求或者交易回应。 2. V10 MBLB 测试过程 2.1 TCP连接测试 首先启动两台Server，分别侦听9000和9001端口 里显示两台服务器都是工作的。确认在BIGIP 显示没有任何的链接产生B connrootltm3600:Active config # b conn 62:14774 4:ssh 4:ssh tcp 1/0 上面的那个连接是我的SSH登录产生的。

8、 启动客户端，配置好发送的内容，点击Connect 5 BIGIP上的连接状态：观察rootltm3600:Active config # b conn 62:14774 4:ssh 4:ssh tcp 1/0 4:4933 3:9000 any6 tcp 1/1 的连接，此时客户端Client-Any6在客户端没有发送数据之前，在BIGIP上只有一个与后台并不建立连接。BIGIP 还没有发送数据，因此2.2 交易分发测试 点击客户端上的发送按钮 观察客户端的收发状态 6 Se

9、rver端收发状态观察 BIGIP上的连接状态观察rootltm3600:Active config # b conn any6 3:9000 4:9000 tcp 1/1 any6 3:9000 4:9001 tcp 1/1 62:14774 4:ssh 4:ssh tcp 1/0 4:4933 3:9000 any6 tcp 1/1 可以看到，在客户端开始发送数据后，BIGIP分

10、别和两台Server建立了连接，并将客户端的请求以轮询的方式发送到两台服务器上。由于我在这里启用了SNAT，因此可以看到 7 第一个Server连接是使用的客户端源端口和服务器建立连接，第二个客户端连接使用的另外一个源端口和服务器建立连接。 2.3 启动第二个客户端的连接建立过程及Timeout 启动第二个客户端建立连接 状态观察BIGIrootltm3600:Active config # b conn62:14774 4:ssh 4:ssh tcp 1/04:1088 3:

11、9000 any6 tcp 1/0 Server端连接了呢？怎么没有 了。BIGIP timeout看看Server端日志，原来由于俺写文章的时间太长，被 开始发送数据好，现在就让C2 Server看到端又开始建立连接了 BIGIP上的连接状态：rootltm3600:Active config # b conn any6 3:9000 4:9001 tcp 1/0 any6 3:9000 4:9000 tcp 1/0 62:14774 4:ssh 60

12、.247.114.44:ssh tcp 1/0 8 4:1088 3:9000 any6 tcp 1/0 C1发送数据现在开始启动 的连接也被断掉了：C1 重新启动C1并连接 BIGIP上状况：rootltm3600:Active config # b conn any6 3:9000 4:9001 tcp 1/0any6 3:9000 4:9000 tcp 1/062:14774 4:ssh 60.247

13、.114.44:ssh tcp 1/04:1088 3:9000 any6 tcp 1/04:1144 3:9000 any6 tcp 1/0 开始发送数据的时候：当Crootltm3600:Active config # b conn any6 3:9000 4:9001 tcp 1/0 any6 3:9000 4:9000 tcp 1/0 any6 3:9000 60.247.

14、114.34:9001 tcp 1/0 any6 3:9000 4:9000 tcp 1/0 62:14774 4:ssh 4:ssh tcp 1/0 4:1088 3:9000 any6 tcp 1/0 4:1144 3:9000 any6 tcp 1/0 Server上的状态： 上建立了同样数量的连接，分别在每台BIGIP可以看到针对每一个客户端连接，Server 9 并将请求在

15、这些连接里进行分发。 2.4 加入新的客户端观察负载均衡算法 我们再启动C3, 看看有什么状况？ BIIGProotltm3600:Active config # b connany6 3:9000 4:9000 tcp 1/0any6 3:9000 4:9001 tcp 1/0any6 3:9000 4:9000 tcp 1/0any6 3:9000 4:9001 tcp 1/06

16、2:14774 4:ssh 4:ssh tcp 1/04:1088 3:9000 any6 tcp 1/04:1144 3:9000 any6 tcp 1/04:1231 3:9000 any6 tcp 1/1 当C3开始发送数据的时候： 10 Server状态： 的请求两台Server都收到了C3Server connection: client connection, 63个个BIGIP上显示root

17、ltm3600:Active config # b conn any6 3:9000 4:9000 tcp 1/1 any6 3:9000 4:9001 tcp 1/1 any6 3:9000 4:9000 tcp 1/0 any6 3:9000 4:9001 tcp 1/0 any6 3:9000 4:9000 tcp 1/0 any6 60.247.11

18、4.43:9000 4:9001 tcp 1/062:14774 4:ssh 4:ssh tcp 1/04:1088 3:9000 any6 tcp 1/04:1144 3:9000 any6 tcp 1/04:1231 3:9000 any6 tcp 1/1 在S2上收到的是C1和C2的请求 在S1上收到的是C1和C3的请求 停止所有的客户端，然后全部重新发

19、送的时候，Server端接收发生了变化： S1上收到的是C1和C2的请求 11 的请求C1和C3S2上收到的是 Round Robin的算法导致了这种现象的出现应该是 BIGIP上的连接没有发生变化：rootltm3600:Active config # b conn any6 3:9000 4:9001 tcp 1/1 any6 3:9000 4:9000 tcp 1/0 any6 3:9000 4:9001 tcp 1/1 any6 60.247.

20、114.43:9000 4:9000 tcp 1/1any6 3:9000 4:9001 tcp 1/0any6 3:9000 4:9000 tcp 1/62:14774 4:ssh 4:ssh tcp 1/04:1144 3:9000 any6 tcp 1/04:1231 3:9000 any6 tcp 1/

21、4:1271 3:9000 any6 tcp 1/1 2.5 手工Disable服务器测试 现在手工Disable一台服务器 在S1上收到了3个客户端的请求 12 disable的服务器：恢复 的请求：C1和C2S1收到了 C3的请求S2重新开始接受请求，收到C1和 2.6 关闭服务器测试S2 关闭 ！Server所有的Client 和都崩溃了！ 。等待服务器程序的改进版本中。 13 2.7 V10 MBLB 测试总结 BIGIP V10 已经具备了MBLB的处理能力，可以对长连接里面的TCP交易进行拆分处理，将不同的请求发送到不同的服务器上，

22、并将服务器的返回信息发送到正确的客户端。 目前发现的一些可能存在的问题： 1、 对于每个客户端的长连接，BIGIP将在每个Server上建立一个连接，也就是说对于每台Server而言，都会有所有的客户端连接数的总和数量的连接，在实际应用中，需要确定服务器是否能处理全部客户端连接数量的连接数。 2、 关于交易的边界定义，目前的测试中非常简单的使用了CLIENT_DATA和SERVER_DATA事件，这两个事件默认情况下是每接收一个数据包就触发一次，因此在交易小于1个MTU，通常情况是1460byte的情况下，可以不用区分交易边界，默认认为一个数据包就是一次交易。 3、 如果每次发送交易的长度大于

23、1460，就需要用irules去获取和判断交易的长度。具体的做法是在第一个数据包进来的时候查询数据包中对于交易长度的定义，然后判断当前收集到得数据是否是完整的交易，如果完整，则释放请求，如果不完整，则继续进行收集，直到收集到足够的数据后，释放交易长度的内容到服务器。 4、 目前测试的应用时阻塞类型的应用，也就是Client必须等待Server应答之后才开始发送下一个请求，而且数据包都比较小，肯定在一个packet就发送完毕，因此不存在有边界界定的问题 5、 如果有非阻塞型应用，也就是客户端可能一次发出多个请求，在不等待server回应的情况下可以持续发出请求，Server回应也是不等待的情况，

24、从目前的连接状况分析也是可以工作的。但可能需要进一步的编程处理来确定每一个交易的边界 6、 对于目前客户所要求的Disable服务器之后，所有的交易可以正常转发到其他服务器的需求是可以满足的。 7、 基本确认这种MBLB工作模式和One Connect在目前测试配置中不能同时工作，因此当客户端关闭连接时，这个客户端对应的所有服务器连接都会被关闭。 8、 从目前了解到得信息，One Connect工作模式下可以彻底的区分客户端连接和服务器端连接的关系，但服务器端的连接数量在One Connect模式下无法控制。 9、 由于测试服务器软件问题，没有测试到Server端主动关闭连接，是否会造成客户端

25、连接中断。另外，当一台server故障，而在健康检查还没有检查到服务器故障期间的交易如何处理目前测试环境中也无法测试。我的初步考虑是用inband monitor来解决普通Monitor的间隔周期和检查周期的问题。 10、 还没有测试会话保持的情况，比如根据每个交易里的一些内容进行会话保持，还需要改进一下客户端和服务器软件 2.8 附：TCPdump数据包分析 客户端数据包发送和接收 14 为三次握手建立连接包25, 26, 27 ，开始，客户端发送数据PSH,ACK149 已经收到客户端内容，没有内容，表明Server157为客户端收到一个BIGIP ACKPSH,ACK 给客户端发送数据1

26、59 BIGIP ACK, 表明数据已经收到161 客户端给BIGIP发送 1000ms后开始下一个数据包发送163 客户端等待 服务器端数据包发送和接收 和后台服务器三次握手建立连接，结合客户端连接建立时间，154为BIGIP，152153， 可以看到BIGIP一直等待到客户端有数据发送了才开始和后台建立连接 PSH,ACK 155 BIGIP给服务器端发送数据 PSH,ACK 数据BIGIP158 服务器回应 ，表明数据已经收到160 BIGIP发送给服务器端ACK 以后，BIGIP重新开始给服务器端发送数据包。164 在1000ms 数据流程图： 比较有意思的地方：ACK 160157和

27、看上去是BIGIP产生的主动发给客户端和服务器的 15 161从客户端发给BIGIP，但被BIGIP吞掉了。 俺的TCP理论研究还不是很深刻，是不是一些协议性的东西导致必须这样工作？ 3. One Connect工作模式测试 在前面的测试中，MBLB可以支持异步交易，但在一些同步工作模式下，应用希望两边的连接不存在有太大的关联性，前面一种模式客户端连接一旦中断后，服务器端这个客户端相关连接会全部中断。通过One Connect工作模式，可以消除掉这种强制的绑定关系，而使服务器端的连接不会和客户端强制绑定。因此可以在客户端是长连接和短连接模式下，BIGIP始终保持和后台服务器是长连接的结构。 O

28、ne Connect工作模式只支持同步阻塞模式下的TCP连接，即客户端必须等待Server端回应请求之后，再发送下一个请求。每笔交易都是以Client Request-Server Response的方式工作。 和前面的MBLB工作模式最大的不同是One Connect可以在V9版本下工作。 测试的结构不变，但BIGIP上配置有一些变化 virtual test_vs snat automap pool test_pool destination 3:9000 ip protocol tcp rules one_connect_rule profiles oneconn

29、ect tcp 注意在VS里面必须绑定Oneconnect Profilerule one_connect_rule when CLIENT_ACCEPTED TCP:collect when CLIENT_DATA LB:detach TCP:release TCP:collect pool test_pool members 4:9000 4:9001 16 One Connect模式的工作原理3.1 ，也可以支持任何协议类型，包括iRules在上图中是以HTTP协议为例，但实际上通过 应用。用户自行开发的TCP SocketIPclient

30、BIGIP会以这个的源当第一个client连接到BIGIP开始发送请求的时候，此时客户端连接和并把客户端的Request转发到服务器。地址和后台服务器建立一个连接，可以识Response之后，由于BIGIP服务器的TCP连接形成了绑定的关系。当服务器响应了结束了之后，就拆除了第检查到服务器端的ResponseHTTP Response别，因此，当BIGIP即使在客户端关闭连接的情况下，TCP连接之间的对应关系。一个Client TCP连接和服务器 的状态。连接也保持BIGIP和后台服务器的TCPOpen会在当前和后台服务器之间BIGIP当下一个用户和BIGIP建立连接并发送请求的时候，负载均衡

31、的算法的前提还需要满足会话保持、TCP连接里面挑选一个空闲的连接（当然，的塞到空闲的连接里面发送到服务器，这时，第二个用户的客，将第二个用户的下）Request户端连接和为第一个客户端建立的服务器连接就形成了新的对应关系。在第二个用户的 结束之后，BIGIP又拆除其对应关系。Response并没有结束，的时候，第二个用户的Response如果第三个用户连接和请求到达BIGIPTCP就会和服务器端再建立一个新的和后台没有空闲连接的时候，也就是当前BIGIPBIGIP 连接，传送第三个客户端的请求到服务器。传输完成了，的时候，第二个用户的如果第四个用户连接和请求到达BIGIPResponse 第四

32、个用户就会再使用空闲的后台服务器连接进行请求传输。始终可以保持较少的后台服当客户端不停的建立连接，拆除连接的时候，BIGIP这样，结束和新的用户请求到达的Response务器连接。BIGIP在这里面完成的工作主要就是根据 时刻点，来切换连接的不同连接对应关系。 TCP3.2 连接测试 17 首先看看BIGIP上的VS状态，看加入了one connect rules之后是否会Disable CMP +- VIRTUAL test_vs SERVICE 9000 | PVA acceleration none | CMP enable on none mode: all 看上去还好，CMP属于en

33、able状态 启动S1 启动S2 启动客户端C1，并建立连接 18 上的连接状态BIGIProotltm3600:Active config # b conn 62:47774 4:ssh 4:ssh tcp 1/0 4:1339 3:9000 any6 tcp 1/1 Server端也看不到任何连接此时在 交易分发测试3.3 开始发送数据C1 上可以收到数据S1 上也可以收到数据S2 由于SNAT的原因，服务器收到的TCP 连接的源端口被改变了，但从数据包中可以看出，两台机器

34、收到的是同一个客户端的同一个源端口发送过来的请求。 19 BIGIP上的连接状态： rootltm3600:Active config # b conn any6 3:9000 4:9001 tcp 1/1 62:47774 4:ssh 4:ssh tcp 1/0 4:1339 3:9000 4:9000 tcp 1/1 有一个Server 端连接显示是idle状态 注意idle状态的连接随时间变化而变化的

35、： rootltm3600:Active config # b conn any6 3:9000 4:9000 tcp 1/1 62:47774 4:ssh 4:ssh tcp 1/0 4:1339 3:9000 4:9001 tcp 1/1 rootltm3600:Active config # b conn any6 3:9000 4:9001 tcp 1

36、/1 62:47774 4:ssh 4:ssh tcp 1/0 4:1339 3:9000 4:9000 tcp 1/1 在两次执行b conn的过程中，idle状态的Server端连接就在发生变化。但请求是被分配到了两台Server上。从客户端的Log看，收到了两台Server的Response 3.4 启动第二个客户端的连接 再启动一个客户端C2并建立连接 20 BIGIP上的连接状况rootltm3600:Active config # b con

37、n any6 3:9000 4:9000 tcp 1/1 62:47774 4:ssh 4:ssh tcp 1/0 4:1339 3:9000 4:9001 tcp 1/1 4:1427 3:9000 any6 tcp 1/1 C2开始发送数据 有意思的是此时S1上总是C2的请求，S2上总是C1得请求 S1 S2 BIGIP上的连接状态 21 rootltm3

38、600:Active config # b conn any6 3:9000 4:9001 tcp 1/1 any6 3:9000 4:9000 tcp 1/1 62:47774 4:ssh 4:ssh tcp 1/0 4:1339 3:9000 4:9001 tcp 1/1 4:1427 3:9000 60.2

39、47.114.34:9000 tcp 1/1 而此时服务器上的真实连接状况是这样的： 到后台服务器分别有两个BIGIPC1和，而C2客户端到BIGIP VS有两个连接，分别是 的两个连接都用的其他端口。的两个连接都用的客户端源端口，S2S1连接， 启动多个客户端观察负载均衡算法3.5 C3,C4,C5,C6个客户端，我们来看看有什么情况出现？4再启动 的收发状态S1 22 可以看到，C2,C3,C4,C6都在S1上有请求 S2上的收发状态 S2上都有请求可以看到，C1,C3,C5,C6在 BIGIP上的连接显rootltm3600:Active config # b connany6 60.2

40、47.114.43:9000 4:9000 tcp 1/0any6 3:9000 4:9001 tcp 1/1 any6 3:9000 4:9000 tcp 1/1 any6 3:9000 4:9001 tcp 1/0 62:47774 4:ssh 4:ssh tcp 1/0 4:1339 3:9000 60.2

41、47.114.34:9001 tcp 1/1 4:1427 3:9000 4:9000 tcp 1/1 4:1522 3:9000 4:9001 tcp 1/0 4:1527 3:9000 4:9000 tcp 1/1 4:1535 3:9000 4:9001 tcp 1/1 4:153

42、6 3:9000 4:9000 tcp 1/0 客户端6个连接，服务器端4个连接 而实际上在客户端和服务器系统里显示的呢？ 23 Client 个个，分别代表6作为客户端发起到VS的连接共有6 个连接。5个连接，S2有5服务器S1有 过一段时间再观察，这些连接并没有发生变化 服务器测试手工3.6 Disable Disable S1 C6刚才还在两台服务器之间摇摆不定的所有的请求都被转发到了S2。 24 服务器Enable3.7 重新enable S1 重新 看到C5的请求被分配到两台服务器上了 25 S1此时接收的请求 26 C1,C3,C4,

43、C5 S1请求被分配到的有 S2此时接收的请求 27 C1,C2,C3,C4,C5,C6 上的有S2请求被分配到工作模式下，不同的客户端交易可以被分配到不同的服务one connect可以确定，在 器上。 关闭服务器测试3.8在工作，其他客户端全部崩和C1S1后，只有同样的进行关闭服务器测试，在关闭S2 ！溃了！ 28 模式测试总结：3.9 One Connect的工作，但仅限于阻塞模式MBLB在One Connect模式下，也是一样的可以实现1、 的应用。的情况。当交易大小可能超过1460byte 同样的，本次测试仅限于每笔交易小于、2 来进行数据包长度的判断。的时候，就需要用iRules1460模式下，关闭客户端连接对服务器端的连接没有影响，这个在one connect 在3、本次记录中没有被记下来，但实际上我已经测试过了，关闭客户端连接的时候 Server端的连接不会发生变化。输出和实际的情况不大一样，自身的b conn O