1bond网卡bond是一种通过很多舒适的荔枝绑定到一个逻辑网卡上，实现本地网卡的冗馀、带宽的扩展和负载的均衡，是生产场景中常用的技术。 Kernels 2.4.12或更高版本由绑定模块提供，早期版本可在patch上实现。 可以通过以下命令确定内核是否支持bonding :
[ root @ Lixin网络- scripts ] # cat/boot/config-2.6.32-573.el6.x86 _ 64|grep-ibonding config _ bonding ]
2 bond的模式http://www.Sina.com/http://www.Sina.com /
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com/http://www.Sina.com /
表示负载分担round-robin，并且通过轮询方式，例如第一分组进行eth0，第二分组进行eth1直到分组的发送结束。
a )优势：流量翻倍
b )缺点：需要访问交换机进行端口聚合。 否则可能无法使用。
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com/http://www.Sina.com /
表示主模式，即同时只有一张网卡在工作。
a )好处：冗馀性高
b )缺点：链路利用率低，两张网卡只能运行一张
http://www.Sina.com/http://www.Sina.com /
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com /
表示XOR Hash的负载分担，与交换机的聚合、强制无协商方式联合。 (需要xmit_hash_policy，需要交换机配置port channel )
特点：根据指定的转发哈希策略转发数据包。 默认策略为(源MAC地址XOR目标MAC地址) % slave数。 其他传输策略可以在xmit_hash_policy选项中指定。 此模式提供了负载平衡和容错能力
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com /
指示所有包都是从所有网络接口发出的。 这种不平衡虽然只有冗长的机制，但也太浪费资源了。 该模型需要可靠的网络，不会出现问题，因此适用于金融业。 必须在没有交换机聚合和强制协商的情况下合作。
特点：此模式提供了在每个slave接口上传输每个数据包的容错能力
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com /
表示支持802.3ad协议，并与交换机聚合LACP方案配合使用。 (需要xmit_hash_policy )。 默认情况下，所有设备在聚合操作期间必须以相同的速率和双工模式运行。 此外，与绑定负载平衡模式(balance-rr模式除外)一样，任何连接都不能使用一个或多个接口的带宽。
特点：创建共享相同速度和双重设置的聚合组。 根据802.3ad规范，多个slave在同一活动聚合物下运行。 外出流量的slave选举基于转发散列策略，可以使用xmit_hash_policy选项将默认XOR策略更改为其他策略。 请注意，并非所有传输策略都支持802.3ad。 特别是，请考虑802.3ad标准43.2.4章中提到的数据包顺序混乱。 根据实现的不同，适应性可能不同。
必要条件：
-条件1:ethtool支持获取每个slave的速率和双工设置
-条件2 :交换机支持IEEE 802.3管理链接聚合
条件3 )大多数交换机要求特定的配置来支持802.3ad模式
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com /
根据各slave的负载状况选择slave进行发送，接收时使用当前的slave。 在此模式下，slave接口的网络设备驱动程序需要某种以太网支持； 此外，不能使用ARP监视。
特点：不需要特殊交换机支持的通道绑定。 每个slave都根据当前负载(基于速度计算)分配外出通信量。 如果正在接收数据的slave发生故障
了，另一个slave接管失败的slave的MAC地址。必要条件：
- ethtool支持获取每个slave的速率
5.mode=6(balance-alb)(适配器适应性负载均衡)
在5的tlb基础上增加了rlb(接收负载均衡receive load balance).不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的.
特点：该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。来自服务器端的接收流量也会被均衡。当本机发送ARP请求时，bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达 时，bonding驱动把它的硬件地址提取出来，并发起一个ARP应答给bond中的某个slave。使用ARP协商进行负载均衡的一个问题是：每次广播 ARP请求时都会使用bond的硬件地址，因此对端学习到这个硬件地址后，接收流量将会全部流向当前的slave。这个问题可以通过给所有的对端发送更新 （ARP应答）来解决，应答中包含他们独一无二的硬件地址，从而导致流量重新分布。当新的slave加入到bond中时，或者某个未激活的slave重新 激活时，接收流量也要重新分布。接收的负载被顺序地分布（round robin）在bond中最高速的slave上当某个链路被重新接上，或者一个新的slave加入到bond中，接收流量在所有当前激活的slave中全部重新分配，通过使用指定的MAC地址给每个 client发起ARP应答。下面介绍的updelay参数必须被设置为某个大于等于switch(交换机)转发延时的值，从而保证发往对端的ARP应答 不会被switch(交换机)阻截。
必要条件：
- 条件1：ethtool支持获取每个slave的速率；
- 条件2：底层驱动支持设置某个设备的硬件地址，从而使得总是有个slave(curr_active_slave)使用bond的硬件地址，同时保证每个bond 中的slave都有一个唯一的硬件地址。如果curr_active_slave出故障，它的硬件地址将会被新选出来的 curr_active_slave接管其实mod=6与mod=0的区别：mod=6，先把eth0流量占满，再占eth1，….ethX；而mod=0的话，会发现2个口的流量都很稳定，基本一样的带宽。而mod=6，会发现第一个口流量很高，第2个口只占了小部分流量。
bond模式小结：
mode5和mode6不需要交换机端的设置，网卡能自动聚合。mode4需要支持802.3ad。mode0，mode2和mode3理论上需要静态聚合方式。
3 配置bond测试环境：
[root@lixin ~]# cat /etc/redhat-releaseCentOS release 6.7 (Final)[root@lixin ~]# uname -r2.6.32-573.el6.x86_64[root@lixin ~]#1、配置物理网卡
[root@lixin network-scripts]# cat ifcfg-eth0 DEVICE=eth0TYPE=EthernetONBOOT=yesBOOTPROTO=noneMASTER=bond0SLAVE=yes //可以没有此字段，就需要开机执行ifenslave bond0 eth0 eth1命令了。[root@lixin network-scripts]#[root@lixin network-scripts]# cat ifcfg-eth1 DEVICE=eth1TYPE=EthernetONBOOT=yesBOOTPROTO=noneMASTER=bond0SLAVE=yes [root@lixin network-scripts]#2、配置逻辑网卡bond0
[root@lixin network-scripts]# cat ifcfg-bond0 //需要我们手工创建DEVICE=bond0TYPE=EthernetONBOOT=yesBOOTPROTO=staticIPADDR=10.0.0.10NETMASK=255.255.255.0DNS2=4.4.4.4GATEWAY=10.0.0.2DNS1=10.0.0.2[root@lixin network-scripts]#//由于没有这个配置文件我们可以使用拷贝一个ifcfg-eth1来用：cp ifcfg-{eth0,bond1}3、加载模块，让系统支持bonding
[root@lixin ~]# cat /etc/modprobe.conf //不存在的话，手动创建（也可以放在modprobe.d下面）alias bond0 bondingoptions bond0 miimon=100 mode=0[root@lixin ~]#//配置bond0的链路检查时间为100ms，模式为0。注意：
linux网卡bonging的备份模式实验在真实机器上做完全没问题（前提是linux内核支持），但是在vmware workstation虚拟中做就会出现如下图问题。
配置完成后出现如上图问题，但是bond0能够正常启动也能够正常使用，只不过没有起到备份模式的效果。当使用ifdown eth0后，网络出现不通现象。
内核文档中有说明：bond0获取mac地址有两种方式,一种是从第一个活跃网卡中获取mac地址，然后其余的SLAVE网卡的mac地址都使用该mac地址；另一种是使用fail_over_mac参数，是bond0使用当前活跃网卡的mac地址，mac地址或者活跃网卡的转换而变。
既然vmware workstation不支持第一种获取mac地址的方式，那么可以使用fail_over_mac=1参数，所以这里我们添加fail_over_mac=1参数
[root@lixin etc]# cat /etc/modprobe.d/modprobe.confalias bond0 bondingoptions bond0 miimon=100 mode=0 fail_over_mac=1[root@lixin etc]#4、加载bond module
//让系统识别bond配置[root@lixin etc]# modprobe bonding5、查看绑定结果
[root@lixin etc]# cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: load balancing (round-robin)MII Status: upMII Polling Interval (ms): 100Up Delay (ms): 0Down Delay (ms): 0 Slave Interface: eth0MII Status: upSpeed: 1000 MbpsDuplex: fullLink Failure Count: 0Permanent HW addr: 00:50:56:28:7f:51Slave queue ID: 0 Slave Interface: eth1MII Status: upSpeed: 1000 MbpsDuplex: fullLink Failure Count: 0Permanent HW addr: 00:50:56:29:9b:daSlave queue ID: 0[root@lixin etc]# 4 测试bond由于使用的是mode=0，负载均衡的方式，这时我们ping百度，然后断开一个网卡，此时ping不会中断。
[root@lixin etc]# ping baidu.comPING baidu.com (111.13.101.208) 56(84) bytes of data.64 bytes from 111.13.101.208: icmp_seq=1 ttl=128 time=10.6 ms64 bytes from 111.13.101.208: icmp_seq=2 ttl=128 time=9.05 ms64 bytes from 111.13.101.208: icmp_seq=3 ttl=128 time=11.7 ms64 bytes from 111.13.101.208: icmp_seq=4 ttl=128 time=7.93 ms64 bytes from 111.13.101.208: icmp_seq=5 ttl=128 time=9.50 ms64 bytes from 111.13.101.208: icmp_seq=6 ttl=128 time=7.17 ms64 bytes from 111.13.101.208: icmp_seq=7 ttl=128 time=21.2 ms64 bytes from 111.13.101.208: icmp_seq=8 ttl=128 time=7.46 ms64 bytes from 111.13.101.208: icmp_seq=9 ttl=128 time=7.82 ms64 bytes from 111.13.101.208: icmp_seq=10 ttl=128 time=8.15 ms64 bytes from 111.13.101.208: icmp_seq=11 ttl=128 time=6.89 ms64 bytes from 111.13.101.208: icmp_seq=12 ttl=128 time=8.33 ms64 bytes from 111.13.101.208: icmp_seq=13 ttl=128 time=8.65 ms64 bytes from 111.13.101.208: icmp_seq=14 ttl=128 time=7.16 ms64 bytes from 111.13.101.208: icmp_seq=15 ttl=128 time=9.31 ms64 bytes from 111.13.101.208: icmp_seq=16 ttl=128 time=10.5 ms64 bytes from 111.13.101.208: icmp_seq=17 ttl=128 time=7.61 ms64 bytes from 111.13.101.208: icmp_seq=18 ttl=128 time=10.2 ms^C--- baidu.com ping statistics ---18 packets transmitted, 18 received, 0% packet loss, time 17443msrtt min/avg/max/mdev = 6.899/9.417/21.254/3.170 ms//用另一个终端手动关闭eth0网卡，ping并没有中断[root@lixin etc]# !cacat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: load balancing (round-robin)MII Status: upMII Polling Interval (ms): 100Up Delay (ms): 0Down Delay (ms): 0 Slave Interface: eth0MII Status: downSpeed: UnknownDuplex: UnknownLink Failure Count: 1Permanent HW addr: 00:50:56:28:7f:51Slave queue ID: 0 Slave Interface: eth1MII Status: upSpeed: 1000 MbpsDuplex: fullLink Failure Count: 0Permanent HW addr: 00:50:56:29:9b:daSlave queue ID: 0[root@lixin etc]#//查看bond0状态，发现eth0，down了，但是bond正常
转载于:https://www.cnblogs.com/dachenzi/articles/6078219.html