Linux 雙網卡bonding測試

原文:http://www.cnblogs.com/killkill/archive/2009/02/15/1390717.html

先介紹一下情況,服務器A和服務器B都是CentOS 4.6的系統,現在要做HA Cluster,爲了避免裂腦的發生,要提高心跳鏈路的可靠性,下圖是現時的連接情況,服務器A的eth2、eth3分別和服務器B的eth2、eth3 相連(沒有順序關係),所有網卡都是千兆網卡,拓撲圖如下所示:

p_w_picpath

在介紹一起硬件情況,服務器A是一臺HP DL380 G5,兩年多的服務器了,4核心8G內存,5塊72GB的2.5寸硬盤做RAID5。服務期B是DELL 2950,幾個月前剛購入的新機器,8核16G內存,3塊3.5寸300G SAS硬盤做RAID5。

業務交換機爲DELL的千兆交換機,沒做任何配置,僅當接入交換機使用。

圖中的藍線用的是幾年前的超五類非屏蔽雙絞線。

圖中的紅線用的是新購的六類非屏蔽雙絞線。

測試方法很簡單,將一個3.4G的ISO從服務器A scp到服務器B中,對比傳輸的時間。

數據走業務鏈路,沒有使用bonding技術。

############## No Binding ##############
[root@rac-node01 tmp]# time scp rhel-5.1-server-x86_64-dvd.iso  10.168.0.202:/tmp 
[email protected]'s password: 
rhel-5.1-server-x86_64-dvd.iso                                                    100% 3353MB  44.1MB/s   01:16    

real    1m20.105s
user    0m34.752s
sys     0m11.002s
############## 速度還是挺快的
數據走心跳鏈路,使用了bonding技術,mode設置爲6,即不需要交換機參與的負載均衡。

令人奇怪的是該種模式下會丟一些數據包,也許是這種比較奇怪的拓撲結果造成的。


############## model=6 ##############
[root@rac-node01 tmp]# time scp rhel-5.1-server-x86_64-dvd.iso  192.168.0.202:/tmp
[email protected]'s password: 
rhel-5.1-server-x86_64-dvd.iso                                                    100% 3353MB  21.4MB/s   02:37    

real    2m47.812s
user    0m34.965s
sys     0m19.421s  
[root@rac-node01 tmp]# netstat -i #@ Receive
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
bond1      1500   0  5123831   2045      0      0  5138747      0      0      0 BMmRU
eth0       1500   0     2847      0      0      0      703      0      0      0 BMRU
eth2       1500   0  2562665     11      0      0  2569378      0      0      0 BMsRU
eth3       1500   0  2561166   2034      0      0  2569369      0      0      0 BMsRU
lo        16436   0     2261      0      0      0     2261      0      0      0 LRU
############## 有數據包丟失
數據走心跳鏈路,使用了bonding技術,mode設置爲0,即需要交換機參與的負載均衡。

該模式下不像mode=6那樣會丟包,而且eth2和eth3的流量幾乎平均。下面測試數據中的 RX-ERR是上面測試數據遺留下來的。


############## model=0 ##############
[root@rac-node01 tmp]# time scp rhel-5.1-server-x86_64-dvd.iso  192.168.0.202:/tmp
[email protected]'s password: 
rhel-5.1-server-x86_64-dvd.iso                                                    100% 3353MB  38.1MB/s   01:28    

real    1m33.508s
user    0m34.539s
sys     0m19.363s
[root@mailserver tmp]# netstat -i     
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
bond1      1500   0 11133871   2045      0      0 11180462      0      0      0 BMmRU
eth0       1500   0  1334477      0      0      0  2575981      0      0      0 BMRU
eth2       1500   0  5567685     11      0      0  5590236      0      0      0 BMsRU
eth3       1500   0  5566186   2034      0      0  5590226      0      0      0 BMsRU
lo        16436   0     2270      0      0      0     2270      0      0      0 LRU
############## 沒有丟包
數據走心跳鏈路,使用了bonding技術,mode設置爲1,即Active-Backup,FailOver模式。

該模式存在一個問題,當服務器A的eth2和服務器B的eth3作爲Active設備時,服務器A是不能和服務器B通過心跳鏈路通信的,此時拔掉其中一根心跳線再插就好了。


############## model=1 ##############
[root@rac-node01 ~]# time scp /tmp/rhel-5.1-server-x86_64-dvd.iso  192.168.0.202:/tmp/
[email protected]'s password: 
rhel-5.1-server-x86_64-dvd.iso                                                    100% 3353MB  41.4MB/s   01:21    

real    1m24.162s
user    0m35.007s
sys     0m13.455s

[root@mailserver ~]#  netstat -i
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
bond1      1500   0  3436804      0      0      0  1774259      0      0      0 BMmRU
eth0       1500   0     3962      0      0      0      773      0      0      0 BMRU
eth2       1500   0  3436804      0      0      0  1774254      0      0      0 BMsRU
eth3       1500   0        0      0      0      0        5      0      0      0 BMsRU
lo        16436   0     3071      0      0      0     3071      0      0      0 LRU
############## 沒有丟包,只走單網卡
結論:

從以上結果顯示,單就速度來說的確不做綁定單網卡速度最快,但是沒有容錯能力。其次是綁定後的FailOver模式,但是該模式會存在一定的問題。而mode=6的負載均衡模式會丟包,比較危險。

mode=0的負載均衡模式貌似並不能加大帶寬,但是對於提高最大的可用性來說是最好的選擇了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章