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 相连（没有顺序关系），所有网卡都是千兆网卡，拓扑图如下所示：

在介绍一起硬件情况，服务器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的负载均衡模式貌似并不能加大带宽，但是对于提高最大的可用性来说是最好的选择了。