利用MBLB解決TCP長連接負(fù)載均衡測試方案

1、 F5 BIGIP MBLB 測試記錄F5北京 楊明非2009年8月目錄1. 測試環(huán)境31.1 測試環(huán)境準(zhǔn)備31.2 測試網(wǎng)絡(luò)拓?fù)?1.3 BIGIP MBLB工作原理：42. V10 MBLB 測試過程52.1 TCP連接測試52.2 交易分發(fā)測試62.3 啟動(dòng)第二個(gè)客戶端的連接建立過程及Timeout82.4 加入新的客戶端觀察負(fù)載均衡算法102.5 手工Disable服務(wù)器測試122.6 關(guān)閉服務(wù)器測試132.7 V10 MBLB 測試總結(jié)142.8 附：TCPdump數(shù)據(jù)包分析143. One Connect工作模式測試163.1 One Connect模式的工作原理173.2 TCP

2、連接測試173.3 交易分發(fā)測試193.4 啟動(dòng)第二個(gè)客戶端的連接203.5 啟動(dòng)多個(gè)客戶端觀察負(fù)載均衡算法223.6 手工Disable 服務(wù)器測試253.7 重新Enable服務(wù)器263.8 關(guān)閉服務(wù)器測試293.9 One Connect模式測試總結(jié)：304. 附錄304.1 如何使用iRules來判斷交易邊界304.2 關(guān)于交易定向發(fā)送324.3 關(guān)于會(huì)話保持324.4 兩種模式的對(duì)比324.5 還需要研究的部分321. 測試環(huán)境1.1 測試環(huán)境準(zhǔn)備PC server一臺(tái)，安裝Windows 2003 Server.BIGIP 1臺(tái)，安裝10.0.1版本TCP Client/Serve

3、r軟件1.2 測試網(wǎng)絡(luò)拓?fù)渌械腎P地址均在同一個(gè)網(wǎng)段內(nèi)，TCP client 和Server也運(yùn)行在同一臺(tái)設(shè)備上。通過啟動(dòng)多個(gè)不同的實(shí)例來模擬多臺(tái)Server和Client。測試用BIGIP 配置virtual test_vs snat automap pool test_pool destination 3:9000 ip protocol tcp rules mblb-basic profiles mblb tcp pool test_pool monitor all tcp_half_open members 4:9000 60.247.

4、114.34:9001 注意mblb的Profile是手工加入的，在圖形界面里沒有配置。另外對(duì)于這種類型的Server，最好使用tcp_half_open健康檢查模式。rule mblb-basic when CLIENT_ACCEPTED TCP:collectwhen CLIENT_DATA TCP:release TCP:notify request #log "client_data trigered" TCP:collectwhen SERVER_CONNECTED TCP:collectwhen SERVER_DATA TCP:release TCP:notif

5、y response #log "Server_data trigered" TCP:collect1.3 BIGIP MBLB工作原理：客戶端首先與BIGIP建立TCP連接，在客戶端發(fā)送數(shù)據(jù)的時(shí)候，BIGIP根據(jù)交易將客戶端請(qǐng)求發(fā)送到不同的服務(wù)器，在發(fā)送前，BIGIP將與后臺(tái)服務(wù)器建立連接。在這種工作模式下，可以支持同步阻塞模式交易或者同連接里的異步交易。同步工作模式：Client1 RequestServer1 ResponseClient2 RequestServer2 ResponseClient1 RequestServer2 Response異步工作模式：Cli

6、ent1 RequestClient2 RequestClient1 RequestServer1 ResponseServer2 Response-Server3 Response在異步工作模式下，不能用下面測試的簡單irules，需要使用iRules來判斷每個(gè)交易的邊界，以便將每筆交易請(qǐng)求分發(fā)到不同的服務(wù)器上。下面的測試基于小包狀態(tài)，也就是每筆交易的長度不超過1個(gè)MTU，通常情況下是1460字節(jié)的情況，在這種情況下，在一次CLIENT_DATA事件觸發(fā)的時(shí)候就可以接收到整個(gè)的交易請(qǐng)求或者交易回應(yīng)。2. V10 MBLB 測試過程2.1 TCP連接測試首先啟動(dòng)兩臺(tái)Server，分別偵聽900

7、0和9001端口確認(rèn)在BIGIP里顯示兩臺(tái)服務(wù)器都是工作的。B conn顯示沒有任何的鏈接產(chǎn)生rootltm3600:Active config # b conn62:14774 <-> 4:ssh <-> 4:ssh tcp 1/0上面的那個(gè)連接是我的SSH登錄產(chǎn)生的。啟動(dòng)客戶端，配置好發(fā)送的內(nèi)容，點(diǎn)擊Connect觀察BIGIP上的連接狀態(tài)：rootltm3600:Active config # b conn62:14774 <-> 4:s

8、sh <-> 4:ssh tcp 1/04:4933 <-> 3:9000 <-> any6 tcp 1/1在客戶端沒有發(fā)送數(shù)據(jù)之前，在BIGIP上只有一個(gè)Client-Any6的連接，此時(shí)客戶端還沒有發(fā)送數(shù)據(jù)，因此BIGIP與后臺(tái)并不建立連接。2.2 交易分發(fā)測試點(diǎn)擊客戶端上的發(fā)送按鈕觀察客戶端的收發(fā)狀態(tài)觀察Server端收發(fā)狀態(tài)觀察BIGIP上的連接狀態(tài)rootltm3600:Active config # b connany6 <-> 3:900

9、0 <-> 4:9000 tcp 1/1any6 <-> 3:9000 <-> 4:9001 tcp 1/62:14774 <-> 4:ssh <-> 4:ssh tcp 1/04:4933 <-> 3:9000 <-> any6 tcp 1/1可以看到，在客戶端開始發(fā)送數(shù)據(jù)后，BIGIP分別和兩臺(tái)Server建立了連接，

10、并將客戶端的請(qǐng)求以輪詢的方式發(fā)送到兩臺(tái)服務(wù)器上。由于我在這里啟用了SNAT，因此可以看到第一個(gè)Server連接是使用的客戶端源端口和服務(wù)器建立連接，第二個(gè)客戶端連接使用的另外一個(gè)源端口和服務(wù)器建立連接。2.3 啟動(dòng)第二個(gè)客戶端的連接建立過程及Timeout啟動(dòng)第二個(gè)客戶端建立連接觀察BIGIP狀態(tài)rootltm3600:Active config # b conn62:14774 <-> 4:ssh <-> 4:ssh tcp 1/04:1088 <-> 60.24

11、7.114.43:9000 <-> any6 tcp 1/0怎么沒有Server端連接了呢？看看Server端日志，原來由于俺寫文章的時(shí)間太長，被BIGIP timeout了。好，現(xiàn)在就讓C2開始發(fā)送數(shù)據(jù)看到Server端又開始建立連接了BIGIP上的連接狀態(tài)：rootltm3600:Active config # b connany6 <-> 3:9000 <-> 4:9001 tcp 1/0any6 <-> 3:9000 <-> 4:9

12、000 tcp 1/062:14774 <-> 4:ssh <-> 4:ssh tcp 1/04:1088 <-> 3:9000 <-> any6 tcp 1/0現(xiàn)在開始啟動(dòng)C1發(fā)送數(shù)據(jù)C1的連接也被斷掉了：重新啟動(dòng)C1并連接BIGIP上狀況：rootltm3600:Active config # b connany6 <-> 3:9000 <-> 4:900

13、1 tcp 1/0any6 <-> 3:9000 <-> 4:9000 tcp 1/062:14774 <-> 4:ssh <-> 4:ssh tcp 1/04:1088 <-> 3:9000 <-> any6 tcp 1/04:1144 <-> 3:9000 <-> any6 tcp 1

14、/0當(dāng)C1開始發(fā)送數(shù)據(jù)的時(shí)候：rootltm3600:Active config # b connany6 <-> 3:9000 <-> 4:9001 tcp 1/0any6 <-> 3:9000 <-> 4:9000 tcp 1/0any6 <-> 3:9000 <-> 4:9001 tcp 1/0any6 <-> 3:9000 <-&g

15、t; 4:9000 tcp 1/062:14774 <-> 4:ssh <-> 4:ssh tcp 1/04:1088 <-> 3:9000 <-> any6 tcp 1/04:1144 <-> 3:9000 <-> any6 tcp 1/0Server上的狀態(tài)：可以看到BIGIP針對(duì)每一個(gè)客戶端連接，分別在每臺(tái)Server上建立了同樣

16、數(shù)量的連接，并將請(qǐng)求在這些連接里進(jìn)行分發(fā)。2.4 加入新的客戶端觀察負(fù)載均衡算法我們?cè)賳?dòng)C3, 看看有什么狀況？BIIGProotltm3600:Active config # b connany6 <-> 3:9000 <-> 4:9000 tcp 1/0any6 <-> 3:9000 <-> 4:9001 tcp 1/0any6 <-> 3:9000 <-> 4:9000 t

17、cp 1/0any6 <-> 3: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/06

18、4:1231 <-> 3:9000 <-> any6 tcp 1/1當(dāng)C3開始發(fā)送數(shù)據(jù)的時(shí)候：Server狀態(tài)：兩臺(tái)Server都收到了C3的請(qǐng)求BIGIP上顯示3個(gè)client connection, 6個(gè)Server connection:rootltm3600:Active config # b connany6 <-> 3:9000 <-> 4:9000 tcp 1/1any6 <-> 3:9000 <-

19、> 4:9001 tcp 1/1any6 <-> 3:9000 <-> 4:9000 tcp 1/0any6 <-> 3:9000 <-> 4:9001 tcp 1/0any6 <-> 3:9000 <-> 4:9000 tcp 1/0any6 <-> 3:9000 <-> 4:9

20、001 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

21、 1/1在S2上收到的是C1和C2的請(qǐng)求在S1上收到的是C1和C3的請(qǐng)求停止所有的客戶端，然后全部重新發(fā)送的時(shí)候，Server端接收發(fā)生了變化：S1上收到的是C1和C2的請(qǐng)求S2上收到的是C1和C3的請(qǐng)求應(yīng)該是Round Robin的算法導(dǎo)致了這種現(xiàn)象的出現(xiàn)BIGIP上的連接沒有發(fā)生變化：rootltm3600:Active config # b connany6 <-> 3:9000 <-> 4:9001 tcp 1/1any6 <-> 3:9000 <-> 60.247.

22、114.34:9000 tcp 1/0any6 <-> 3:9000 <-> 4:9001 tcp 1/1any6 <-> 3:9000 <-> 4:9000 tcp 1/1any6 <-> 3:9000 <-> 4:9001 tcp 1/0any6 <-> 3:9000 <-> 4:9000 tcp 1/16

23、62:14774 <-> 4:ssh <-> 4:ssh tcp 1/04:1144 <-> 3:9000 <-> any6 tcp 1/04:1231 <-> 3:9000 <-> any6 tcp 1/4:1271 <-> 3:9000 <-> any6 tcp 1/12.5 手工Di

24、sable服務(wù)器測試現(xiàn)在手工Disable一臺(tái)服務(wù)器在S1上收到了3個(gè)客戶端的請(qǐng)求恢復(fù)disable的服務(wù)器：S1收到了C1和C2的請(qǐng)求：S2重新開始接受請(qǐng)求，收到C1和C3的請(qǐng)求2.6 關(guān)閉服務(wù)器測試關(guān)閉S2所有的Client 和Server都崩潰了！等待服務(wù)器程序的改進(jìn)版本中。2.7 V10 MBLB 測試總結(jié)BIGIP V10 已經(jīng)具備了MBLB的處理能力，可以對(duì)長連接里面的TCP交易進(jìn)行拆分處理，將不同的請(qǐng)求發(fā)送到不同的服務(wù)器上，并將服務(wù)器的返回信息發(fā)送到正確的客戶端。目前發(fā)現(xiàn)的一些可能存在的問題：1、 對(duì)于每個(gè)客戶端的長連接，BIGIP將在每個(gè)Server上建立一個(gè)連接，也就是說對(duì)于

25、每臺(tái)Server而言，都會(huì)有所有的客戶端連接數(shù)的總和數(shù)量的連接，在實(shí)際應(yīng)用中，需要確定服務(wù)器是否能處理全部客戶端連接數(shù)量的連接數(shù)。2、 關(guān)于交易的邊界定義，目前的測試中非常簡單的使用了CLIENT_DATA和SERVER_DATA事件，這兩個(gè)事件默認(rèn)情況下是每接收一個(gè)數(shù)據(jù)包就觸發(fā)一次，因此在交易小于1個(gè)MTU，通常情況是1460byte的情況下，可以不用區(qū)分交易邊界，默認(rèn)認(rèn)為一個(gè)數(shù)據(jù)包就是一次交易。3、 如果每次發(fā)送交易的長度大于1460，就需要用irules去獲取和判斷交易的長度。具體的做法是在第一個(gè)數(shù)據(jù)包進(jìn)來的時(shí)候查詢數(shù)據(jù)包中對(duì)于交易長度的定義，然后判斷當(dāng)前收集到得數(shù)據(jù)是否是完整的交易，如

26、果完整，則釋放請(qǐng)求，如果不完整，則繼續(xù)進(jìn)行收集，直到收集到足夠的數(shù)據(jù)后，釋放交易長度的內(nèi)容到服務(wù)器。4、 目前測試的應(yīng)用時(shí)阻塞類型的應(yīng)用，也就是Client必須等待Server應(yīng)答之后才開始發(fā)送下一個(gè)請(qǐng)求，而且數(shù)據(jù)包都比較小，肯定在一個(gè)packet就發(fā)送完畢，因此不存在有邊界界定的問題5、 如果有非阻塞型應(yīng)用，也就是客戶端可能一次發(fā)出多個(gè)請(qǐng)求，在不等待server回應(yīng)的情況下可以持續(xù)發(fā)出請(qǐng)求，Server回應(yīng)也是不等待的情況，從目前的連接狀況分析也是可以工作的。但可能需要進(jìn)一步的編程處理來確定每一個(gè)交易的邊界6、 對(duì)于目前客戶所要求的Disable服務(wù)器之后，所有的交易可以正常轉(zhuǎn)發(fā)到其他服務(wù)器

27、的需求是可以滿足的。7、 基本確認(rèn)這種MBLB工作模式和One Connect在目前測試配置中不能同時(shí)工作，因此當(dāng)客戶端關(guān)閉連接時(shí)，這個(gè)客戶端對(duì)應(yīng)的所有服務(wù)器連接都會(huì)被關(guān)閉。8、 從目前了解到得信息，One Connect工作模式下可以徹底的區(qū)分客戶端連接和服務(wù)器端連接的關(guān)系，但服務(wù)器端的連接數(shù)量在One Connect模式下無法控制。9、 由于測試服務(wù)器軟件問題，沒有測試到Server端主動(dòng)關(guān)閉連接，是否會(huì)造成客戶端連接中斷。另外，當(dāng)一臺(tái)server故障，而在健康檢查還沒有檢查到服務(wù)器故障期間的交易如何處理目前測試環(huán)境中也無法測試。我的初步考慮是用inband monitor來解決普通Mon

28、itor的間隔周期和檢查周期的問題。10、 還沒有測試會(huì)話保持的情況，比如根據(jù)每個(gè)交易里的一些內(nèi)容進(jìn)行會(huì)話保持，還需要改進(jìn)一下客戶端和服務(wù)器軟件2.8 附：TCPdump數(shù)據(jù)包分析客戶端數(shù)據(jù)包發(fā)送和接收包25, 26, 27為三次握手建立連接149開始，客戶端發(fā)送數(shù)據(jù)PSH,ACK，157為客戶端收到一個(gè)BIGIP ACK，沒有內(nèi)容，表明Server已經(jīng)收到客戶端內(nèi)容159 BIGIP給客戶端發(fā)送數(shù)據(jù)PSH,ACK161 客戶端給BIGIP發(fā)送ACK, 表明數(shù)據(jù)已經(jīng)收到163 客戶端等待1000ms后開始下一個(gè)數(shù)據(jù)包發(fā)送服務(wù)器端數(shù)據(jù)包發(fā)送和接收152，153，154為BIGIP和后臺(tái)服務(wù)器三次

29、握手建立連接，結(jié)合客戶端連接建立時(shí)間，可以看到BIGIP一直等待到客戶端有數(shù)據(jù)發(fā)送了才開始和后臺(tái)建立連接155 BIGIP給服務(wù)器端發(fā)送數(shù)據(jù) PSH,ACK158 服務(wù)器回應(yīng)BIGIP數(shù)據(jù) PSH,ACK160 BIGIP發(fā)送給服務(wù)器端ACK，表明數(shù)據(jù)已經(jīng)收到164 在1000ms以后，BIGIP重新開始給服務(wù)器端發(fā)送數(shù)據(jù)包。數(shù)據(jù)流程圖：比較有意思的地方：157和160看上去是BIGIP產(chǎn)生的主動(dòng)發(fā)給客戶端和服務(wù)器的ACK161從客戶端發(fā)給BIGIP，但被BIGIP吞掉了。俺的TCP理論研究還不是很深刻，是不是一些協(xié)議性的東西導(dǎo)致必須這樣工作？3. One Connect工作模式測試在前面的測

30、試中，MBLB可以支持異步交易，但在一些同步工作模式下，應(yīng)用希望兩邊的連接不存在有太大的關(guān)聯(lián)性，前面一種模式客戶端連接一旦中斷后，服務(wù)器端這個(gè)客戶端相關(guān)連接會(huì)全部中斷。通過One Connect工作模式，可以消除掉這種強(qiáng)制的綁定關(guān)系，而使服務(wù)器端的連接不會(huì)和客戶端強(qiáng)制綁定。因此可以在客戶端是長連接和短連接模式下，BIGIP始終保持和后臺(tái)服務(wù)器是長連接的結(jié)構(gòu)。One Connect工作模式只支持同步阻塞模式下的TCP連接，即客戶端必須等待Server端回應(yīng)請(qǐng)求之后，再發(fā)送下一個(gè)請(qǐng)求。每筆交易都是以Client Request->Server Response的方式工作。和前面的MBLB工作

31、模式最大的不同是One Connect可以在V9版本下工作。測試的結(jié)構(gòu)不變，但BIGIP上配置有一些變化virtual test_vs snat automap pool test_pool destination 3:9000 ip protocol tcp rules one_connect_rule profiles oneconnect tcp 注意在VS里面必須綁定Oneconnect Profilerule one_connect_rule when CLIENT_ACCEPTED TCP:collect when CLIENT_DATA LB:detach

32、 TCP:release TCP:collect pool test_pool members 4:9000 4:9001 3.1 One Connect模式的工作原理在上圖中是以HTTP協(xié)議為例，但實(shí)際上通過iRules，也可以支持任何協(xié)議類型，包括用戶自行開發(fā)的TCP Socket應(yīng)用。當(dāng)?shù)谝粋€(gè)client連接到BIGIP開始發(fā)送請(qǐng)求的時(shí)候，BIGIP會(huì)以這個(gè)client的源IP地址和后臺(tái)服務(wù)器建立一個(gè)連接，并把客戶端的Request轉(zhuǎn)發(fā)到服務(wù)器。此時(shí)客戶端連接和服務(wù)器的TCP連接形成了綁定的關(guān)系。當(dāng)服務(wù)器響應(yīng)了Response之后，由于BI

33、GIP可以識(shí)別HTTP Response，因此，當(dāng)BIGIP檢查到服務(wù)器端的Response結(jié)束了之后，就拆除了第一個(gè)Client TCP連接和服務(wù)器TCP連接之間的對(duì)應(yīng)關(guān)系。即使在客戶端關(guān)閉連接的情況下，BIGIP和后臺(tái)服務(wù)器的TCP連接也保持Open的狀態(tài)。當(dāng)下一個(gè)用戶和BIGIP建立連接并發(fā)送請(qǐng)求的時(shí)候，BIGIP會(huì)在當(dāng)前和后臺(tái)服務(wù)器之間的TCP連接里面挑選一個(gè)空閑的連接（當(dāng)然，還需要滿足會(huì)話保持、負(fù)載均衡的算法的前提下），將第二個(gè)用戶的Request塞到空閑的連接里面發(fā)送到服務(wù)器，這時(shí)，第二個(gè)用戶的客戶端連接和為第一個(gè)客戶端建立的服務(wù)器連接就形成了新的對(duì)應(yīng)關(guān)系。在第二個(gè)用戶的Respo

34、nse結(jié)束之后，BIGIP又拆除其對(duì)應(yīng)關(guān)系。如果第三個(gè)用戶連接和請(qǐng)求到達(dá)BIGIP的時(shí)候，第二個(gè)用戶的Response并沒有結(jié)束，也就是當(dāng)前BIGIP和后臺(tái)沒有空閑連接的時(shí)候，BIGIP就會(huì)和服務(wù)器端再建立一個(gè)新的TCP連接，傳送第三個(gè)客戶端的請(qǐng)求到服務(wù)器。如果第四個(gè)用戶連接和請(qǐng)求到達(dá)BIGIP的時(shí)候，第二個(gè)用戶的Response傳輸完成了，第四個(gè)用戶就會(huì)再使用空閑的后臺(tái)服務(wù)器連接進(jìn)行請(qǐng)求傳輸。這樣，當(dāng)客戶端不停的建立連接，拆除連接的時(shí)候，BIGIP始終可以保持較少的后臺(tái)服務(wù)器連接。BIGIP在這里面完成的工作主要就是根據(jù)Response結(jié)束和新的用戶請(qǐng)求到達(dá)的時(shí)刻點(diǎn)，來切換連接的不同連接對(duì)應(yīng)

35、關(guān)系。3.2 TCP連接測試首先看看BIGIP上的VS狀態(tài)，看加入了one connect rules之后是否會(huì)Disable CMP+-> VIRTUAL test_vs SERVICE 9000 | PVA acceleration none| CMP enable on none mode: all看上去還好，CMP屬于enable狀態(tài)啟動(dòng)S1啟動(dòng)S2啟動(dòng)客戶端C1，并建立連接BIGIP上的連接狀態(tài)rootltm3600:Active config # b conn62:47774 <-> 4:ssh <-> 6

36、4:ssh tcp 1/04:1339 <-> 3:9000 <-> any6 tcp 1/1此時(shí)在Server端也看不到任何連接3.3 交易分發(fā)測試C1開始發(fā)送數(shù)據(jù)S1上可以收到數(shù)據(jù)S2上也可以收到數(shù)據(jù)由于SNAT的原因，服務(wù)器收到的TCP 連接的源端口被改變了，但從數(shù)據(jù)包中可以看出，兩臺(tái)機(jī)器收到的是同一個(gè)客戶端的同一個(gè)源端口發(fā)送過來的請(qǐng)求。BIGIP上的連接狀態(tài)：rootltm3600:Active config # b connany6 <-> 3:9000

37、<-> 4:9001 tcp 1/62:47774 <-> 4:ssh <-> 4:ssh tcp 1/04:1339 <-> 3:9000 <-> 4:9000 tcp 1/1有一個(gè)Server 端連接顯示是idle狀態(tài)注意idle狀態(tài)的連接隨時(shí)間變化而變化的：rootltm3600:Active config # b connany6 <-> 60.24

38、7.114.43:9000 <-> 4:9000 tcp 1/62:47774 <-> 4:ssh <-> 4:ssh tcp 1/04:1339 <-> 3:9000 <-> 4:9001 tcp 1/1rootltm3600:Active config # b connany6 <-> 3:9000 <-> 60.24

39、7.114.34:9001 tcp 1/62:47774 <-> 4:ssh <-> 4:ssh tcp 1/04:1339 <-> 3:9000 <-> 4:9000 tcp 1/1在兩次執(zhí)行b conn的過程中，idle狀態(tài)的Server端連接就在發(fā)生變化。但請(qǐng)求是被分配到了兩臺(tái)Server上。從客戶端的Log看，收到了兩臺(tái)Server的Response3.4 啟動(dòng)第二個(gè)客戶端的連接再啟動(dòng)一個(gè)客戶端C

40、2并建立連接BIGIP上的連接狀況rootltm3600:Active config # b connany6 <-> 3:9000 <-> 4:9000 tcp 1/62:47774 <-> 4:ssh <-> 4:ssh tcp 1/04:1339 <-> 3:9000 <-> 4:9001 tcp 1/

41、4:1427 <-> 3:9000 <-> any6 tcp 1/1C2開始發(fā)送數(shù)據(jù)有意思的是此時(shí)S1上總是C2的請(qǐng)求，S2上總是C1得請(qǐng)求S1S2BIGIP上的連接狀態(tài)rootltm3600:Active config # b connany6 <-> 3:9000 <-> 4:9001 tcp 1/1any6 <-> 3:9000 <-> 4:9000 tcp 1/62:477

42、74 <-> 4:ssh <-> 4:ssh tcp 1/04:1339 <-> 3:9000 <-> 4:9001 tcp 1/4:1427 <-> 3:9000 <-> 4:9000 tcp 1/1而此時(shí)服務(wù)器上的真實(shí)連接狀況是這樣的：客戶端到BIGIP VS有兩個(gè)連接，分別是C1和C2，而BIGIP到后臺(tái)服務(wù)器分別有兩個(gè)連接，

43、S1的兩個(gè)連接都用的客戶端源端口，S2的兩個(gè)連接都用的其他端口。3.5 啟動(dòng)多個(gè)客戶端觀察負(fù)載均衡算法再啟動(dòng)4個(gè)客戶端，C3,C4,C5,C6，我們來看看有什么情況出現(xiàn)？S1的收發(fā)狀態(tài)可以看到，C2,C3,C4,C6都在S1上有請(qǐng)求S2上的收發(fā)狀態(tài)可以看到，C1,C3,C5,C6在S2上都有請(qǐng)求BIGIP上的連接顯示rootltm3600:Active config # b connany6 <-> 3:9000 <-> 4:9000 tcp 1/0any6 <-> 3:9000 <

44、;-> 4:9001 tcp 1/1any6 <-> 3:9000 <-> 4:9000 tcp 1/1any6 <-> 3:9000 <-> 4:9001 tcp 1/062:47774 <-> 4:ssh <-> 4:ssh tcp 1/04:1339 <-> 3:9

45、000 <-> 4:9001 tcp 1/4:1427 <-> 3:9000 <-> 4:9000 tcp 1/4:1522 <-> 3:9000 <-> 4:9001 tcp 1/04:1527 <-> 3:9000 <-> 4:9000 tcp 1/160.247.1

46、14.34:1535 <-> 3:9000 <-> 4:9001 tcp 1/4:1536 <-> 3:9000 <-> 4:9000 tcp 1/0客戶端6個(gè)連接，服務(wù)器端4個(gè)連接而實(shí)際上在客戶端和服務(wù)器系統(tǒng)里顯示的呢？作為客戶端發(fā)起到VS的連接共有6個(gè)，分別代表6個(gè)Client服務(wù)器S1有5個(gè)連接，S2有5個(gè)連接。過一段時(shí)間再觀察，這些連接并沒有發(fā)生變化3.6 手工Disable 服務(wù)器測試Disable S1剛才還在兩臺(tái)

47、服務(wù)器之間搖擺不定的C6所有的請(qǐng)求都被轉(zhuǎn)發(fā)到了S2。3.7 重新Enable服務(wù)器重新enable S1看到C5的請(qǐng)求被分配到兩臺(tái)服務(wù)器上了此時(shí)S1接收的請(qǐng)求請(qǐng)求被分配到S1的有C1,C3,C4,C5此時(shí)S2接收的請(qǐng)求請(qǐng)求被分配到S2上的有C1,C2,C3,C4,C5,C6可以確定，在one connect工作模式下，不同的客戶端交易可以被分配到不同的服務(wù)器上。3.8 關(guān)閉服務(wù)器測試同樣的進(jìn)行關(guān)閉服務(wù)器測試，在關(guān)閉S2后，只有C1和S1在工作，其他客戶端全部崩潰了！3.9 One Connect模式測試總結(jié)：1、 在One Connect模式下，也是一樣的可以實(shí)現(xiàn)MBLB的工作，但僅限于阻塞模

48、式的應(yīng)用。2、 同樣的，本次測試僅限于每筆交易小于1460byte的情況。當(dāng)交易大小可能超過1460的時(shí)候，就需要用iRules來進(jìn)行數(shù)據(jù)包長度的判斷。3、 在one connect模式下，關(guān)閉客戶端連接對(duì)服務(wù)器端的連接沒有影響，這個(gè)在本次記錄中沒有被記下來，但實(shí)際上我已經(jīng)測試過了，關(guān)閉客戶端連接的時(shí)候Server端的連接不會(huì)發(fā)生變化。4、 One Connect工作模式下，BIGIP自身的b conn輸出和實(shí)際的情況不大一樣，估計(jì)是b conn輸出的是實(shí)時(shí)信息，因此和實(shí)際上的服務(wù)器看到的連接數(shù)量不能對(duì)應(yīng)5、 測試是在V10版本上進(jìn)行的，但按照其工作原理，在V9平臺(tái)上應(yīng)該也可以工作。6、 On

49、e connect模式CMP是可以正常工作7、 在one connect工作模式下，應(yīng)該也同樣遇到monitor健康檢查的實(shí)效期間的問題。因此，也需要用inband monitor來解決。或者考慮用when LB_FAIL的事件來進(jìn)行處理。4. 附錄4.1 如何使用iRules來判斷交易邊界當(dāng)客戶端的交易可能大于1460byte的時(shí)候，就必須使用iRules來判斷每筆交易的邊界。在進(jìn)行邊界分析的時(shí)候，必須知道數(shù)據(jù)包的格式，通常情況下，在長連接交易中，必然會(huì)有一個(gè)位置來表明每個(gè)交易的長度。處理流程在iRules中，需要進(jìn)行的流程如下：1、 在客戶端連接建立成功的時(shí)候，啟用TCP:collect進(jìn)

50、行數(shù)據(jù)收集2、 當(dāng)客戶端請(qǐng)求內(nèi)容發(fā)送時(shí)，將觸發(fā)CLIENT_DATA事件，此時(shí)就可以通過分析TCP:payload判斷接收到的內(nèi)容判斷交易的長度3、 判斷當(dāng)前收集到的payload長度和交易的實(shí)際長度進(jìn)行比較，如果相等，在One Connect模式下，進(jìn)行LB:detach動(dòng)作，在MBLB模式下，進(jìn)行TCP:notify request動(dòng)作。如果沒有結(jié)束，則繼續(xù)收集，直到收集成功一筆完整的交易。4、 在LB:detach或TCP:notify request完成后，則釋放這部分?jǐn)?shù)據(jù)，將交易請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)器。收集完成后，釋放交易長度的數(shù)據(jù)到服務(wù)器。5、 在數(shù)據(jù)釋放完成后，重新觸發(fā)TCP:coll

51、ect動(dòng)作，等待觸發(fā)下一次CLIENT_DATA動(dòng)作。示例代碼下面這段代碼以LDAP協(xié)議為例，演示如何使用iRules來判斷一個(gè)完整的LDAP 查詢請(qǐng)求。when CLIENT_ACCEPTED TCP:collectwhen CLIENT_DATA binary scan TCP:payload xc ber_lenif $ber_len < 0 set ber_index expr 2 + 128 + $ber_len else set ber_index 2# message idbinary scan TCP:payload $ber_indexxcI ber_len ber_l

52、en_extif $ber_len < 0 set ext_len expr 128 + $ber_lenset ber_len expr ($ber_len_ext>>(4-$ext_len)*8)+(0x100$ext_len)%(0x100$ext_len) else set ext_len 0incr ber_index expr 2 + $ext_len + $ber_len# ldap messagebinary scan TCP:payload $ber_indexc ber_type if expr $ber_type & 0x1f = 2 log l

53、ocal0. "unbind => detach"TCP:payload replace 0 TCP:payload length ""LB:detachTCP:releaseTCP:collect4.2 關(guān)于交易定向發(fā)送由于環(huán)境問題，交易定向發(fā)送，也就是根據(jù)交易的內(nèi)容，指定將交易發(fā)送到某一個(gè)Pool或member中的功能還沒有進(jìn)行測試，但從一些案例上看是完全可行的。必須要注意判斷完交易內(nèi)容后，必須在LB:detach或TCP:notify request動(dòng)作執(zhí)行以前，指定將交易要轉(zhuǎn)發(fā)到的Pool，否則一旦TCP:release完成后，將無法指定數(shù)

54、據(jù)包發(fā)往的目的地。示例代碼如下：when CLIENT_DATA set call_id XXXXXXif $call_id equals “abc” pool pool_a else pool pool_b TCP:releaseTCP:notify requestTCP:collect4.3 關(guān)于會(huì)話保持同樣由于環(huán)境問題，會(huì)話保持目前還沒有進(jìn)行完全的測試。但從已有的案例上看，這兩種模式都支持基于iRules的會(huì)話保持，可以根據(jù)交易里的一些特征代碼，將具備相同特征代碼的請(qǐng)求發(fā)送到同一臺(tái)服務(wù)器。和Pool選擇一樣，Persist uie指令的位置必須放置在LB:detach或TCP:notify動(dòng)作執(zhí)行之前，否則將無法實(shí)現(xiàn)會(huì)話保持處理。示例代碼如下：when CLIENT_DATA set call_id XXXXXXpersist uie $call_id 360TCP:releaseTCP:notify requestTCP:collect其中XXXXXX部分是從TCP payload 中提取特征碼的函數(shù)處理。在長連接的交易處理中，經(jīng)?？赡艹霈F(xiàn)消息串的情況，也就是連續(xù)的幾筆請(qǐng)求都是為了完成一筆交易，在一些情況下，這些請(qǐng)求必須發(fā)往同一臺(tái)服務(wù)器處理，這時(shí)，就可以采用會(huì)話保持模式實(shí)現(xiàn)?；蛘咴谟行┣闆r下，比如同一個(gè)用戶的多筆交易請(qǐng)求都需要發(fā)送到同一臺(tái)服務(wù)器的時(shí)候