第一步：对管理IP和业务IP进行确认
查看那些是业务IP，那些地址是管理IP
由于我的服务器上有装了saltstack自动化管理工具，所以可以批量查看！
salt -E "192.168.30" cmd.run "ethtool enp130s0f0"|egrep "(192.168.30)|(Speed)"
如果没有可以分别查看
[root@localhost ~]# ethtool enp130s0f1|grep "Speed" Speed: 10000Mb/s [root@localhost ~]# ethtool enp130s0f0|grep "Speed" Speed: 10000Mb/s
第二步：预备知识
网卡（接口）绑定是将多块 网卡 逻辑地连接到一起从而允许故障转移或者提高吞吐率的方法。提高服务器网络可用性的一个方式是使用多个网卡。Linux 绑定驱动程序提供了一种将多个网卡聚合到一个逻辑的绑定接口的方法。这是个新的实现绑定的方法，并不影响 linux 内核中旧绑定驱动。
Centos6中bond网卡的支持的工作模式：
0. round robin
特点：（1）所有链路处于负载均衡状态，轮询方式往每条链路发送报文，基于per packet方式发送。服务上ping 一个相同地址：1.1.1.1 双网卡的两个网卡都有流量发出。负载到两条链路上，说明是基于per packet方式 ，进行轮询发送。（2）这模式的特点增加了带宽，同时支持容错能力，当有链路出问题，会把流量切换到正常的链路上。
1.active-backup
模式的特点：一个端口处于主状态 ，一个处于从状态，所有流量都在主链路上处理，从不会有任何流量。当主端口down掉时，从端口接手主状态。
2.load balancing (xor)
特点：该模式将限定流量，以保证到达特定对端的流量总是从同一个接口上发出。既然目的地是通过MAC地址来决定的，因此该模式在“本地”网络配置下可以工作得很好。如果所有流量是通过单个路由器（比如 “网关”型网络配置，只有一个网关时，源和目标mac都固定了，那么这个算法算出的线路就一直是同一条，那么这种模式就没有多少意义了。），那该模式就不是最好的选择。和balance-rr一样，交换机端口需要能配置为“port channel”。这模式是通过源和目标mac做hash因子来做xor算法来选路的。
3.fault-tolerance (broadcast)
特点:这种模式的特点是一个报文会复制两份往bond下的两个接口分别发送出去,当有对端交换机失效，我们感觉不到任何downtime,但此法过于浪费资源;不过这种模式有很好的容错机制。此模式适用于金融行业，因为他们需要高可靠性的网络，不允许出现任何问题。
4.lacp
特点：802.3ad模式是IEEE标准，因此所有实现了802.3ad的对端都可以很好的互操作。802.3ad 协议包括聚合的自动配置，因此只需要很少的对交换机的手动配置（要指出的是，只有某些设备才能使用802.3ad）。802.3ad标准也要求帧按顺序（一定程度上）传递，因此通常单个连接不会看到包的乱序。802.3ad也有些缺点：标准要求所有设备在聚合操作时，要在同样的速率和双工模式，而且，和除了balance-rr模式外的其它bonding负载均衡模式一样，任何连接都不能使用多于一个接口的带宽。 此外，linux bonding的802.3ad实现通过对端来分发流量（通过MAC地址的XOR值），因此在“网关”型配置下，所有外出（Outgoing）流量将使用同一个设备。进入（Incoming）的流量也可能在同一个设备上终止，这依赖于对端802.3ad实现里的均衡策略。在“本地”型配置下，路两将通过 bond里的设备进行分发。
5.transmit load balancing
特点：balance-tlb模式通过对端均衡外出（outgoing）流量。既然它是根据MAC地址进行均衡，在“网关”型配置（如上文所述）下，该模式会通过单个设备来发送所有流量，然而，在“本地”型网络配置下，该模式以相对智能的方式（不是balance-xor或802.3ad模式里提及的XOR方式）来均衡多个本地网络对端，因此那些数字不幸的MAC地址（比如XOR得到同样值）不会聚集到同一个接口上。 不像802.3ad，该模式的接口可以有不同的速率，而且不需要特别的交换机配置。不利的一面在于，该模式下所有进入的（incoming）流量会到达同一个接口；该模式要求slave接口的网络设备驱动有某种ethtool支持；而且ARP监控不可用。
6.adaptive load balancing。
bond6:adaptive load balancing特点：该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。所有端口都会收到对端的arp请求报文，回复arp回时，bond驱动模块会截获所发的arp回复报文，根据算法算到相应端口，这时会把arp回复报文的源mac，send源mac都改成相应端口mac。从抓包情况分析回复报文是第一个从端口1发，第二个从端口2发。以此类推。 (还有一个点：每个端口除发送本端口回复的报文，也同样会发送其他端口回复的报文，mac还是其他端口的mac)这样来自服务器端的接收流量也会被均衡。 当本机发送ARP请求时，bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达时，bonding驱动把它的硬件地址提取出来，并发起一个ARP应答给bond中的某个slave(这个算法和上面一样，比如算到1口，就给发送arp请求，1回复时mac用1的mac)。使用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接管。
以上值Centos6的bond支持的模式，而在Centos7以后就开始选择team，即链路聚合的方式进行双网卡的绑定。Centos7为了向后的兼容依然支持bond模式，目前红帽官方还是将Team作为备选的方案，目前team模式也出来好几年了，后来我们经过一些测试发现team的性能方面还是挺不错的，于是决定采用7中的team模式。7中的网卡工作模式，目前支持以下几种：
broadcast 传输来自所有端口的包。
random 随机分配
roundrobin 以轮循的方式传输所有端口的包。
activebakup 这是一个故障迁移程序，监控链接更改并选择活动的端口进行传输。
loadbalance 监控流量并使用哈希函数以尝试在选择传输端口的时候达到完美均衡。
loadbalance其中又分为：主动和被动模式。主动模式，是team会智能判断进行负载均衡。被动模式是进行随机的负载均衡。
lacp 实施802.3ad 链路聚合协议，可以使用与 loadbalance 运行程序相同的传输端口选择的可能性
具体选择哪一种可以根据自己的业务需要来定！我们的业务双网卡选择负载均衡的主动模式、，实现负载均衡的同时又实现了灾备。我们的管理的双网卡工作模式选择的是模式1，主从灾备。
三，开始进行业务绑定
创建team1,并选择模式，centos7以后的模式选择发生了变化，只需写到字典里面即可。
nmcli connection add con-name team1 type team ifname team1 config '{"device": "team1", "runner": {"name": "loadbalance","tx_hash": ["eth", "ipv4", "ipv6"],"tx_balancer": {"name": "basic"}}}' # 这里选择的是主动模式
添加网卡进行绑定
nmcli connection add con-name team1-port1 type team-slave ifname enp130s0f0 master team1
nmcli connection add con-name team1-port2 type team-slave ifname enp130s0f1 master team1
# 给bond设置IP地址
nmcli connection modify team1 ipv4.addresses 11.xx.8.30/24 ipv4.gateway 10.17.8.254 ipv4.method manual
nmcli connection up team1 # 启用team1
重启网络
systemctl restart network #可以省略
查看状态
teamdctl team1 state
# 列出team1的端口
teamnl team0 ports
验证：
ping 11.xx.8.31
nmcli device disconnect enp130s0f0 (禁用其中的一块)
nmcli device connect enp130s0f0（启用其中的一块）
ip link set down enp130s0f0 (关闭掉一种的一块进行测试)
四，开始进行管理ip的链路聚合
管理的链路聚合，我们选择的是主备模式
配置管理的链路聚合。我们服务器的默认网关(GATEWAY)留给了业务IP，所以管理的不要默认网关。因为服务器默认只能有一个网关，否则后续会有各种问题。这里需要这里需要把默认网关改为路由。
nmcli connection add con-name team0 type team ifname team0 config '{"device": "team0", "runner": {"name": "activebackup"}}'
nmcli connection add con-name team0-port1 type team-slave ifname enp1s0f0 master team0
nmcli connection add con-name team0-port2 type team-slave ifname enp1s0f1 master team0
nmcli connection modify team0 ipv4.addresses 192.168.30.79/24 ipv4.method manual #这里不加网关
nmcli connection up team0
teamdctl team0 state
这里面有几点需要注意：
1，聚合链路需要依赖NetworkManager，因为首先必须保证NetworkManager服务的启动，最好设置为开机自启动模式
2，如果网卡已经启动并且添加了静态的IP地址，是无法进行链路聚合的，即使添加进去也不会生效，需要将其恢复到初始状态。因为在做链路聚合的过程当中，所有的网卡都是由NetworkManager统一调度和管理的。
３，一定要注意一台服务器只能有一个网关，否则会出各种问题。
详见红帽官方文档：https://access.redhat.com/documentation/zh-CN/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/index.html
