【LINUX】Linux網路卡繫結探析

現在很多伺服器都自帶雙千兆網口，利用網路卡繫結既能增加網路頻寬，同時又能做相應的冗餘，目前應用於很多的場景。下自帶的網路卡繫結模式， bonding驅動提供了一個把多個網路介面裝置捆綁為單個網路介面設定來使用，用於網路負載均衡及網路冗餘。當然現在網路卡產商也會出一些針對windows作業系統網路卡管理軟體來做網路卡繫結（windows作業系統沒有網路卡繫結功能 需要第三方支援）。

一、 Bonding的應用

1、 網路負載均衡

對於bonding的網路負載均衡是我們在檔案伺服器中常用到的，比如把三塊網路卡，當做一塊來用，解決一個IP地址，流量過大，伺服器網路壓力過大的問題。如果在內網中，檔案伺服器為了管理和應用上的方便，大多是用同一個IP地址。對於一個百M的本地網路來說，檔案伺服器在多個使用者同時使用的情況下，網路壓力是極大的，為了解決同一個IP地址，突破流量的限制，畢竟網線和網路卡對資料的吞吐量是有限制的。如果在有限的資源的情況下，實現網路負載均衡，最好的辦法就是bonding 。

2、 網路冗餘

對於伺服器來說，網路裝置的穩定也是比較重要的，特別是網路卡。大多透過硬體裝置的冗餘來提供伺服器的可靠性和安全性，比如電源。bonding 也能為網路卡提供冗餘的支援。把網個網路卡繫結到一個IP地址，當一塊網路卡發生物理性損壞的情況下，另一塊網路卡也能提供正常的服務。

二、 Bonding的原理

什麼是bonding需要從網路卡的混雜(promisc)模式說起。我們知道，在正常情況下，網路卡只接收目的硬體地址(MAC Address)是自身Mac的乙太網幀，對於別的資料幀都濾掉，以減輕驅動程式的負擔。但是網路卡也支援另外一種被稱為混雜promisc的模式，可以接 收網路上所有的幀，比如說tcpdump，就是執行在這個模式下。bonding也執行在這個模式下，而且修改了驅動程式中的mac地址，將兩塊網路卡的 Mac地址改成相同，可以接收特定mac的資料幀。然後把相應的資料幀傳送給bond驅動程式處理。

三、 Bonding的模式

linux有七種網路卡繫結模式：

模式代號	模式名稱	模式方式	說明
0	(balance-rr) Round-robin policy	輪詢策略	該策略是按照裝置順序依次傳輸資料包，直到最後一個裝置。這種模式提供負載均衡和容錯能力。
1	(active-backup) Active-backup policy	主備策略	該策略只有一個裝置處於活動狀態。 一個宕掉另一個馬上由備份轉換為主裝置。mac地址是外部可見的。 此模式提供了容錯能力。
2	(balance-xor) XOR policy	異或策略	該策略是根據MAC地址異或運算的結果來選擇傳輸裝置，提供負載均衡和容錯能力。
3	Broadcast policy	廣播策略	該策略將所有資料包傳輸給所有介面透過全部裝置來傳輸所有資料，提供容錯能力。
4	(802.3ad) IEEE 802.3ad Dynamic link aggregation	動態連結聚合	該策略透過建立聚合組來共享相同的傳輸速度，需要也支援 802.3ad 模式，提供容錯能力。
5	(balance-tlb) Adaptive transmit load balancing	介面卡傳輸負載均衡	該策略是根據當前的負載把發出的資料分給每一個裝置，由當前使用的裝置處理收到的資料。本策略的通道聯合不需要專用的交換機支援，提供負載均衡和容錯能力。
6	(balance-alb) Adaptive load balancing	介面卡負載均衡	該策略在IPV4情況下包含介面卡傳輸負載均衡策略，由ARP協商完成接收的負載，通道聯合驅動程式截獲ARP在本地系統傳送出的請求，用其中一個裝置的硬體地址覆蓋從屬裝置的原地址。

 

第一種：bond0:round robin

1、 標準文件描述

round-robin policy: Transmit packets in sequential order from the first available slave through the last. This mode provides load balancing and fault tolerance.

2、 特點

• ? 負載均衡---所有鏈路處於負載均衡狀態，輪詢方式往每條鏈路傳送報文，基於per packet方式傳送。傳輸資料包順序是依次傳輸（即：第1個包走eth0，下一個包就走eth1....一直迴圈下去，直到最後一個傳輸完畢）。在一個雙網路卡繫結的機器上ping一個地址，你會發現兩個網路卡都有流量發出。負載到兩條鏈路上，說明是基於per packet方式進行輪詢傳送。
• ? 容錯能力---這模式的特點增加了頻寬，同時支援容錯能力，當有鏈路出問題，會把流量切換到正常的鏈路上。
• ? 效能問題---一個連線或者會話的資料包如果從不同的介面發出的話，中途再經過不同的鏈路，在客戶端很有可能會出現資料包無序到達的問題，而無序到達的資料包需要重新要求被髮送，這樣網路的吞吐量就會下降。Bond0在大壓力的網路傳輸下，效能增長的並不是很理想。
• ? 交換機支援---該模式下，由於繫結的所有網路卡的IP都被修改為同一個MAC地址。此時交換機收到發往該MAC地址的資料包時，將不知道從對應的哪個埠轉發該資料，為了解決交換機的這個問題，交換機應做埠繫結，將資料發往邏輯聚合埠，之後由聚合埠從多個埠轉發資料。

 

第二種：bond1:active-backup

1、 標準文件描述

Active-backup policy: Only one slave in the bond is active. A different slave becomes active if， and only if， the active slave fails. The bond’s MAC address is externally visible on only one port (network adapter) to avoid confusing the switch. This mode provides fault tolerance. The primary option affects the behavior of this mode.

2、 特點

• ? 容錯能力---只有一個slave是啟用的(active)。也就是說同一時刻只有一個網路卡處於工作狀態，其他的slave都處於備份狀態，只有在當前啟用的slave故障後才有可能會變為啟用的(active)。在bonding 2.6.2和以後的版本中，如果在active-backup模式下出現failover【譯註：指一個slave發生故障，另一個slave變為啟用的裝置】，bonding將會在新的slave上發出一個或多個ARP請求，其中一個ARP請求針對bonding master介面及它上面配置的每個VLAN介面，從而保證該介面至少配置了一個IP地址。針對VLAN介面的ARP請求將會被打上相應的VLAN id。
• ? 無負載均衡---此演算法的優點是可以提供高網路連線的可用性，但是它的資源利用率較低，只有一個介面處於工作狀態，在有 N 個網路介面的情況下，資源利用率為1/N。
• ? 無需交換機支援--- MAC地址是外部可見得，從外面看來，bond的MAC地址是唯一的，以避免switch(交換機)發生混亂。

第三種：bond2:load balancing (xor)

1、 標準文件描述

XOR policy: Transmit based on [(source MAC address XOR'd with destination MAC address) modulo slave count]. This selects the same slave for each destination MAC address. This mode provides load balancing and fault tolerance.

2、 特點

• ? 負載均衡和容錯能力---基於指定的傳輸HASH策略傳輸資料包。預設的策略是：(源MAC地址 XOR 目標MAC地址) % slave數量。其他的傳輸策略可以透過xmit_hash_policy選項指定。
• ? 效能問題---該模式將限定流量，以保證到達特定對端的流量總是從同一個介面上發出。既然目的地是透過MAC地址來決定的，因此該模式在“本地”網路配置下可以工作得很好。如果所有流量是透過單個路由器（比如 “閘道器”型網路配置，只有一個閘道器時，源和目標mac都固定了，那麼這個演算法算出的線路就一直是同一條，那麼這種模式就沒有多少意義了。），那該模式就不是最好的選擇。
• ? 交換機支援---和balance-rr一樣，交換機埠需要能配置為“port channel”。這模式是透過源和目標mac做hash因子來做xor演算法來選路的。

第四種：bond3:fault-tolerance (broadcast)

1、 標準文件描述

Broadcast policy: transmits everything on all slave interfaces. This mode provides fault tolerance.

2、 特點

這種模式的特點是一個報文會複製兩份往bond下的兩個介面分別傳送出去，當有對端交換機失效，我們感覺不到任何downtime，但此法過於浪費資源；不過這種模式有很好的容錯機制。此模式適用於金融行業，因為他們需要高可靠性的網路，不允許出現任何問題。

 

第五種：bond4:lacp

1、 標準文件描述

IEEE 802.3ad Dynamic link aggregation. Creates aggregation groups that share the same speed and duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad specification. Pre-requisites: 1. Ethtool support in the base drivers for retrieving.the speed and duplex of each slave. 2. A switch that supports IEEE 802.3ad Dynamic link aggregation. Most switches will require some type of configuration to enable 802.3ad mode.

2、 特點

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裡的裝置進行分發。

band4是要求參與繫結的埠都執行802.3ad協議。該方式與band0很相似，但是又有區別。在IEEE802.3ad中，“鏈路聚合控制協議（LACP）”自動通知交換機應該聚合哪些埠，IEEE802.3ad聚合配置之後，鏈路聚合控制協議單元（LACPDU）就會在伺服器和交換機之間進行交換，LACP會通知交換機在聚合中配置的介面卡應作為交換機上的一個介面卡來考慮，而不再有使用者的干預。（按照協議應當如此，但是H3C5500-EI交換機上並未發現有單獨啟用802.3ad或LACP的命令，而聚合組中的靜態聚合的所有埠均不啟用LACP協議，所以如果按照band4的模式操作的話，建議在交換機上手工做動態埠聚合，且手工指定全域性報文按照源MAC和目的MAC地址進行聚合負載分擔。）根據IEEE802.3ad的規範，前往相同IP地址的資料包都會透過相同的介面卡進行傳送。因此當在802.3ad方式下操作時，資訊包會始終按照標準（standard）的方式進行分發，而不會按照輪詢（Round-Robin）方式進行分發。

 

 

3、 交換機端配置

interface AggregatePort 1 配置聚合口 interface GigabitEthernet 0/23 port-group 1 mode active 介面下開啟lacp 主動模式 interface GigabitEthernet 0/24 port-group 1 mode active

4、 必要條件

條件1：ethtool支援獲取每個slave的速率和雙工設定 條件2：switch(交換機)支援IEEE 802.3ad Dynamic link aggregation 條件3：大多數switch(交換機)需要經過特定配置才能支援802.3ad模式

第六種：bond5: transmit load balancing

1、 標準文件描述

Adaptive transmit load balancing: channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load (computed relative to the speed) on each slave. Incoming traffic is received by the current slave. If the receiving slave fails， another slave takes over the MAC address of the failed receiving slave. Prerequisite: Ethtool support in the base drivers for retrieving the speed of each slave.

2、 特點

balance-tlb模式透過對端均衡外出（outgoing）流量。既然它是根據MAC地址進行均衡，在“閘道器”型配置（如上文所述）下，該模式會透過單個裝置來傳送所有流量，然而，在“本地”型網路配置下，該模式以相對的方式（不是balance-xor或802.3ad模式裡提及的XOR方式）來均衡多個本地網路對端，因此那些數字不幸的MAC地址（比如XOR得到同樣值）不會聚集到同一個介面上。

不像802.3ad，該模式的介面可以有不同的速率，而且不需要特別的交換機配置。不利的一面在於，該模式下所有進入的（incoming）流量會到達同一個介面；該模式要求slave介面的網路裝置驅動有某種ethtool支援；而且ARP監控不可用。

 

第七種：bond6:adaptive load balancing

1、 
特點

該模式包含了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(交換機)阻截。

當叢集的機器數量較少，或者機器跨VLAN或者經過路由時，模式6就起不到很好的效果。mod=6與mod=0的區別：mod=6，先把eth0流量佔滿，再佔eth1，....ethX；而mod=0的話，會發現2個口的流量都很穩定，基本一樣的頻寬。而mod=6，會發現第一個口流量很高，第2個口只佔了小部分流量。

2、 必要條件

條件1：ethtool支援獲取每個slave的速率；

條件2：底層驅動支援設定某個裝置的硬體地址，從而使得總是有個slave(curr_active_slave)使用bond的硬體地址，同時保證每個bond 中的slave都有一個唯一的硬體地址。如果curr_active_slave出故障，它的硬體地址將會被新選出來的 curr_active_slave接管。

四、 Bonding引數介紹

引數	說明
max_bonds	為bonding驅動指定建立bonding裝置的數量。比如，如果max_bonds為3，而且bonding驅動還沒有載入，那麼bond0，bond1，bond2將會被建立。預設值為1。
lacp_rate	指定在802.3ad模式下，我們希望的連結對端傳輸LACPDU包的速率。可能的選項： slow 或者 0 請求對端每30s傳輸LACPDU fast 或者 1 請求對端每1s傳輸LACPDU 預設值是slow
downdelay	指定一個時間，用於在發現鏈路故障後，等待一段時間然後禁止一個slave，單位是毫秒(ms)。該選項只對miimon監控有效。downdelay值應該是miimon值的整數倍，否則它將會被取整到最接近的整數倍。預設值為0。
arp_ip_target	指定一組IP地址用於ARP監控的目標，它只在arp_interval > 0時有效。這些IP地址是ARP請求傳送的目標，用於判定到目標地址的鏈路是否工作正常。多個IP地址透過逗號分隔。至少指定一個IP地址。最多可以指定16個IP地址。預設值是沒有IP地址。
arp_interval	指定ARP鏈路監控頻率，單位是毫秒(ms)。如果APR監控工作於以太相容模式（模式0和模式2）下，需要把switch(交換機)配置為在所有鏈路上均勻的分發網路包。如果switch(交換機)被配置為以XOR方式分發網路包，所有來自ARP目標的應答將會被同一個鏈路上的其他裝置收到，這將會導致其他裝置的失敗。ARP監控不應該和miimon同時使用。設定為0將禁止ARP監控。預設值為0。
miimon	指定MII鏈路監控頻率，單位是毫秒(ms)。這將決定驅動檢查每個slave鏈路狀態頻率。0表示禁止MII鏈路監控。100可以作為一個很好的初始參考值。預設值為0。
mode	指定bonding的策略。預設是balance-rr （round robin，輪詢策略）。
primary	指定哪個slave成為主裝置（primary device），取值為字串，如eth0，eth1等。只要指定的裝置可用，它將一直是啟用的slave。只有在主裝置（primary device）斷線時才會切換裝置。這在希望某個slave裝置優先使用的情形下很有用，比如，某個slave裝置有更高的吞吐率。 primary選項只對active-backup模式有效。
updelay	指定當發現一個鏈路恢復時，在啟用該鏈路之前的等待時間，以毫秒計算。該選項只對miimon鏈路偵聽有效。updelay應該是miimon值的整數倍，如果不是，它將會被向下取整到最近的整數。預設值為0。
use_carrier	指定miimon是否需要使用MII或者ETHTOOL ioctls還是netif_carrier_ok()來判定鏈路狀態。MII或ETHTOOL ioctls更低效一些，而且使用了核心裡廢棄的舊呼叫序列；而netif_carrier_ok()依賴於裝置驅動來維護狀態（判斷載波），在本文寫作時，大多數但不是全部裝置驅動支援這個特性。 如果bonding總是認為鏈路是通的，但實際上是斷的，這有可能是由於你的網路裝置驅動不支援netif_carrier_on/off。因為 netif_carrier的預設狀態是"carrier on"，因此如果驅動不支援netif_carrier，則會顯示鏈路永遠正常。在這種情況下，把use_carrier設為0，從而讓bonding使用MII/ETHTOOL ictl來判定鏈路狀態。 該選項設為1會使用netif_carrier_ok()，而設為0則會使用廢棄的MII/ETHTOOL ioctls，預設值是1。
xmit_hash_policy	在balance-xor和802.3ad模式下選擇不同的hash模式，以用於slave選舉。可能的取值有： layer2 使用硬體MAC地址的XOR來生成hash。公式為： (源MAC地址 XOR 目的MAC地址）% slave數目 該演算法會將某個網路對（network peer）上所有的流量全部分配到同一個slave上。 layer3+4 該策略在可能的時候使用上層協議的資訊來生成hash。這將允許特定網路對（network peer）的流量分攤到多個slave上，儘管同一個連線（connection）不會分攤到多個slave上。 針對未分片的TCP和UDP包的計算公式為： ((源埠 XOR 目的埠) XOR ((源IP XOR 目的IP) AND 0xFFFF) % slave數目 對於已分片TCP或UDP包，以及其他的IP包，源埠和目的埠的資訊被忽略了；對於非IP流量，採用和layer2一樣的hash策略。 該策略期望模仿某些交換機的行為，比如帶PFC2的Cisco交換機，以及某些Foundry和IBM的產品。 該演算法不完全適應802.3ad，一個單一的TCP或UDP會話同時包含有分片和未分片的包將會導致包在兩個介面上傳遞，這將會導致投遞亂序。大多數流量不會滿足這種條件，正如TCP很少分片，而大多數UDP流量不會在長期的會話中存在。其他的802.3ad實現有可能不能容忍這樣的不適應性。 預設設定是layer2。該選項在bonding 2.6.3加入，在早期版本中，該引數不存在，只只是layer2策略。

轉載其他網路，具體出處未知，如有侵犯原作者版權，請聯絡，在此也感謝原作者的分享。