第一步：對管理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
