Linux網卡綁定探析

2013-08-20 15:39:31

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

我們公司是做Distributed File System的，很多項目都用到網卡綁定來提高效能。在網路找了很多資料，也做了大量的測試，下面就網卡綁定談一下自己的看法。

Bonding的應用

網路負載平衡

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

網路冗餘

對於伺服器來說，網路裝置的穩定也是比較重要的，特別是網卡。大多通過硬體裝置的冗餘來提供伺服器的可靠性和安全性，比如電源。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)	異或策略	該策略是根據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

標準文檔描述

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

特點

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

 

第二種：bond1:active-backup

標準文檔描述

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.

特點

• 容錯能力---只有一個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)

標準文檔描述

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.

特點

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

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

標準文檔描述

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

特點

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

 

第五種：bond4:lacp

標準文檔描述

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.

特點

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實現裡的均衡策略。在“本地”型配置下，路兩將通過 裡的裝置進行分發。

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

必要條件

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

第六種：bond5: transmit load balancing

標準文檔描述

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.

特點

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

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

 

第七種：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(交換器)阻截。

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