概述
1. Linux的网卡链路聚合
- 网卡链路聚合：将多个网卡绑定/聚合为一个虚拟逻辑网口对外提供访问，其中一个网卡坏了也不影响链路的畅通。在生产场景中是一种常用的技术；
- Linux下网卡的链路聚合常用的有bond和team两种模式；
- bond的网卡绑定功能是依靠内核"bonding"模块实现的，Kernels 2.4.12及以后的版本均供bonding模块，以前的版本可以通过patch实现。
2. 链路聚合的目的
- 消除单点故障，提供网卡冗余
- 提升网卡I/O带宽（提高并发）
配置
实现：
2个物理网口分别是：eth0,eth1
绑定后的虚拟口是：bond1
服务器IP是：192.168.5.11
功能：搭建主备模式，一个网卡坏掉另一个网卡自动工作。
1、确定内核是否支持 bonding
[root@centos ~]# cat /boot/config-3.10.0-514.el7.x86_64 |grep -i bonding //3.10.0-514.el7.x86_64为内核版本号
CONFIG_BONDING=m //说明支持这个模块
[root@centos ~]#2、加载及配置bonding模块
-
加载模块(重启系统后就不用手动再加载了)
[root@www ~]# modprobe bonding -
确认模块是否加载成功：
[root@www ~]# lsmod | grep bonding -
可以编辑/etc/modprobe.conf或者/etc/modules.conf文件，也可以直接创建一个加载bonding的专属配置文件/etc/modprobe.d/bonding.conf ，加入下面内容：
alias bond1 bonding options bond1 mode=1 miimon=100- miimon=100 用来进行链路监测的。即每100ms监测一次链路状态。bonding只监测主机与交换机之间链路。如果交换机出去的链路出问题而本身没有问题，那么bonding认为链路没有问题而继续使用。
- mode=1：主备方式
mode=1 表示提供冗余功能，工作方式是主备的工作方式
3、网卡配置
-
创建虚拟网卡ifcfg-bond1的配置文件
[root@www ~]# vim /etc/sysconfig/network-scripts/ifcfg-bond1 TYPE=Ethernet DEVICE=bond1 #设备名字 BOOTPROTO=none ONBOOT=yes IPADDR=192.168.5.11 NETMASK=255.255.255.0 GETWAY=192.168.5.1 NAME=bond1 USERCTL=no #是否允许非root用户控制该设备 -
修改被绑定的eth0和eth1的配置文件
[root@www ~]# cd /etc/sysconfig/network-scripts [root@www ~]# cp ifcfg-eth0 ifcfg-eth0.bak [root@www ~]# vim ifcfg-eth0 TYPE=Ethernet BOOTPROTO=none DEVICE=eth0 USERCTL=no ONBOOT=yes MASTER=bond1 SLAVE=yes
4、检测验证
- 重启网络服务，并确认bond1正确启动：
service network restart - 确认设备已经正确加载：
less /proc/net/bonding/bond1 - 列出所有网口：
ifconfig/ip addr
5、后续
- eh0宕掉后，接好eth0网线，不会自动切回到eth0上，除非拔出 eth1网卡。
附：模式及对应作用
目前网卡绑定mode共有七种(0~6)：mode=0、mode=1、mode=2、mode=3、mode=4、mode=5、mode=6
常用的有三种:
mode=0：平衡负载模式，有自动备援，但需要”Switch”支援及设定。
mode=1：自动备援模式，其中一条线若断线，其他线路将会自动备援。
mode=6：平衡负载模式，有自动备援，不必”Switch”支援及设定。
1、第一种模式：
-
mode=0: round robin policy（平衡轮循环策略）
-
特点：
- 所有链路处于负载均衡状态，轮循环方式（即依次传输：第1个包走eth0，下一个包就走eth1….一直循环下去，直到最后一个传输完毕）往每条链路发送报文，基于per packet方式发送。服务上ping 一个相同地址：1.1.1.1 双网卡的两个网卡都有流量发出。负载到两条链路上，说明是基于per packet方式 ，进行轮询发送。
- 这模式的特点是提供负载平衡（增加了带宽），同时支持容错能力，当有链路出问题，会把流量切换到正常的链路上。
-
注意：
如果想做成mode 0的负载均衡,需要与网卡相连的交换机必须做端口聚合，因为做bonding的这两块网卡是使用同一个MAC地址。从原理分析一下（bond运行在mode0下）：
mode 0下bond所绑定的网卡的IP都被修改成相同的mac地址，如果这些网卡都被接在同一个交换机，那么交换机的arp表里这个mac地址对应的端口就有多 个，那么交换机接受到发往这个mac地址的包应该往哪个端口转发呢？正常情况下mac地址是全球唯一的，一个mac地址对应多个端口肯定使交换机迷惑了。所以 mode0下的bond如果连接到交换机，交换机这几个端口应该采取聚合方式（cisco称为 ethernetchannel，foundry称为portgroup），因为交换机做了聚合后，聚合下的几个端口也被捆绑成一个mac地址.我们的解决办法是，两个网卡接入不同的交换机即可。
2、第二种模式：
-
mode=1: active-backup policy（主-备份策略）
-
特点：
只有一个设备处于活动状态，当一个宕掉另一个马上由备份转换为主设备。mac地址是外部可见得，从外面看来，bond的MAC地址是唯一的，以避免switch(交换机)发生混乱。此模式只提供了容错能力；但是它的资源利用率较低，只有一个接口处于工作状态，资源利用率为1/n。
这种模式接入不需要交换机端支持，随便怎么接入都行。
3、第三种模式：
-
mode=2:load balancing (xor) policy，即XOR policy（平衡策略）
-
特点：
该模式将限定流量，以保证到达特定对端的流量总是从同一个接口上发出。既然目的地是通过MAC地址来决定的，因此该模式在“本地”网络配置下可以工作得很好。如果所有流量是通过单个路由器（比如 “网关”型网络配置，只有一个网关时，源和目标mac都固定了，那么这个算法算出的线路就一直是同一条，那么这种模式就没有多少意义了。），那该模式就不是最好的选择。和balance-rr一样，交换机端口需要能配置为“port channel”。这模式是通过源和目标mac做hash因子来做xor算法来选路的。此模式提供负载平衡和容错能力。 -
注意：
同bond0一样的应用模型。这个模式也需要交换机配置聚合口。
4、第四种模式：
-
mode=3:broadcast policy（广播策略）
-
特点：
这种模式的特点是在每个slave接口上传输每个数据包,当有对端交换机失效，我们感觉不到任何downtime,但此法过于浪费资源;但是这种模式有很好的容错机制，适用于金融行业，因为他们需要高可靠性的网络，不允许出现任何问题。
5、第五种模式：
-
mode=4:IEEE 802.3ad Dynamic link aggregation（IEEE802.3ad 动态链接聚合）
-
特点：
创建一个聚合组，它们共享同样的速率和双工设定。根据802.3ad规范将多个slave工作在同一个激活的聚合体下。外出流量的slave选举是基于传输hash策略，该策略可以通过xmit_hash_policy选项从缺省的XOR策略改变到其他策略。需要注意的 是，并不是所有的传输策略都是802.3ad适应的，尤其考虑到在802.3ad标准43.2.4章节提及的包乱序问题。不同的实现可能会有不同的适应 性。
必要条件：- 条件1：ethtool支持获取每个slave的速率和双工设定
- 条件2：switch(交换机)支持IEEE802.3ad Dynamic link aggregation
- 条件3：大多数switch(交换机)需要经过特定配置才能支持802.3ad模式
6、第六种模式：
-
mode=5:(balance-tlb)Adaptive transmit load balancing（适配器传输负载均衡）
-
特点：
不需要任何特别的switch(交换机)支持的通道bonding。在每个slave上根据当前的负载（根据速度计算）分配外出流量。如果正在接受数据的slave出故障了，另一个slave接管失败的slave的MAC地址。 -
该模式的必要条件：
ethtool支持获取每个slave的速率，mode6模式下无需配置交换机，因为做bonding的这两块网卡是使用不同的MAC地址。
7、第七种模式：
-
mode=6：(balance-alb)Adaptive load balancing（适配器适应性负载均衡）
-
特点：
该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receiveload 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重新 激活时，接收流量也要重新分布。接收的负载被顺序地分布（roundrobin）在bond中最高速的slave上当某个链路被重新接上，或者一个新的slave加入到bond中，接收流量在所有当前激活的slave中全部重新分配，通过使用指定的MAC地址给每个 client发起ARP应答。下面介绍的updelay参数必须被设置为某个大于等于switch(交换机)转发延时的值，从而保证发往对端的ARP应答 不会被switch(交换机)阻截。 -
必要条件：
- 条件1：ethtool支持获取每个slave的速率；
- 条件2：底层驱动支持设置某个设备的硬件地址，从而使得总是有个slave(curr_active_slave)使用bond的硬件地址，同时保证每个 bond 中的slave都有一个唯一的硬件地址。
