【Linux】Bonding驅動選項

楊奇龍發表於2011-11-27
Bonding驅動的選項是透過在載入時指定引數來設定的。可以透過insmod或modprobe命令的命令列引數來指定,但通常在/etc/modules.conf或/etc/modprobe.conf配置檔案中指定!
下面列出可用的bonding驅動引數。如果引數沒有指定,驅動會使用預設引數。剛開始配置bond的時候,建議在一個終端視窗中執行"tail -f /var/log/messages"來觀察bonding驅動的錯誤資訊
有些引數必須要正確的設定,比如miimon、arp_interval和arp_ip_target,否則在連結故障時會導致嚴重的網路效能退化。很少的裝置不支援miimon,因此沒有任何理由不使用它們。 
有些選項不僅支援文字值的設定,出於相容性的考慮,也支援數值的設定,比如,"mode=802.3ad"和"mode=4"效果是一樣的。 
具體的引數列表: 
arp_interval 
  指定ARP鏈路監控頻率,單位是毫秒(ms)。如果APR監控工作於以太相容模式(模式0和模式2)下,需要把switch(交換機)配置為在所有鏈路上均勻的分發網路包。如果switch(交換機)被配置為以XOR方式分發網路包,所有來自ARP目標的應答將會被同一個鏈路上的其他裝置收到,這將會導致其他裝置的失敗。ARP監控不應該和miimon同時使用。設定為0將禁止ARP監控。預設值為0。 
arp_ip_target 
  指定一組IP地址用於ARP監控的目標,它只在arp_interval > 0時有效。這些IP地址是ARP請求傳送的目標,用於判定到目標地址的鏈路是否工作正常。該設定值為ddd.ddd.ddd.ddd格式。多個IP地址透過逗號分隔。至少指定一個IP地址。最多可以指定16個IP地址。預設值是沒有IP地址。 
downdelay 
  指定一個時間,用於在發現鏈路故障後,等待一段時間然後禁止一個slave,單位是毫秒(ms)。該選項只對miimon監控有效。downdelay值應該是miimon值的整數倍,否則它將會被取整到最接近的整數倍。預設值為0。 
lacp_rate 
  指定在802.3ad模式下,我們希望的連結對端傳輸LACPDU包的速率。可能的選項: 
  slow 或者 0 
    請求對端每30s傳輸LACPDU 
  fast 或者 1 
    請求對端每1s傳輸LACPDU 
  預設值是slow 
max_bonds 
  為bonding驅動指定建立bonding裝置的數量。比如,如果max_bonds為3,而且bonding驅動還沒有載入,那麼bond0,bond1,bond2將會被建立。預設值為1。 
miimon 
  指定MII鏈路監控頻率,單位是毫秒(ms)。這將決定驅動檢查每個slave鏈路狀態頻率。0表示禁止MII鏈路監控。100可以作為一個很好的初始參考值。下面的use_carrier選項將會影響如果檢測鏈路狀態。更多的資訊可以參考“高可靠性”章節。預設值為0。 
mode 
  指定bonding的策略。預設是balance-rr (round robin,迴圈賽)。可選的mode包括: 
  balance-rr 或者 0 
    Round-robin(迴圈賽)策略:按順序傳輸資料包,從第一個可用的slave到最後一個可用的slave。該模式提供了負載均衡和容錯機制。 
  active-backup 或者 1 
    Active-backup(啟用-備份)策略:只有一個slave是啟用的(active)。其他的slave只有在當前啟用的slave故障後才會變為啟用的(active)。從外面看來,bond的MAC地址是唯一的,以避免switch(交換機)發生混亂。 
    在bonding 2.6.2和以後的版本中,如果在active-backup模式下出現failover---指一個slave發生故障,另一個slave變為啟用的裝置,bonding將會在新的slave上發出一個或多個ARP請求,其中一個ARP請求針對bonding master介面及它上面配置的每個VLAN介面,從而保證該介面至少配置了一個IP地址。針對VLAN介面的ARP請求將會被打上相應的VLAN id。 
---------------------------------------------------------------------------------------- 
In bonding version 2.6.2 or later, when a failover occurs in active-backup mode, bonding will issue one or more gratuitous ARPs on the newly active slave. 
One gratuitous ARP is issued for the bonding master interface and each VLAN interfaces configured above it, provided that the interface has at least one IP 
address configured.  Gratuitous ARPs issued for VLAN interfaces are tagged with the appropriate VLAN id. 
---------------------------------------------------------------------------------------- 
 該模式提供了容錯機制。下面的primary選項將會影響該工作模式的行為。 
balance-xor 或者 2 
 XOR策略:基於指定的傳輸HASH策略傳輸資料包。預設的策略是:(源MAC地址 XOR 目標MAC地址) % slave數量。其他的傳輸策略可以透過xmit_hash_policy選項指定,下文將會對之介紹。該模式提供了負載均衡和容錯機制。 
broadcast 或者 3 
 Broadcase(廣播)策略:在每個slave介面上傳輸每個資料包。該模式提供了容錯機制。 
  802.3ad 或者 4 
 IEEE 802.3ad Dynamic link aggregation(動態連結聚合)。建立一個聚合組,它們共享同樣的速率和雙工設定。根據802.3ad規範將多個slave工作在同一個啟用的聚合體下。 
 外出流量的slave選舉是基於傳輸hash策略,該策略可以透過xmit_hash_policy選項從預設的XOR策略改變到其他策略。需要注意的是,並不是所有的傳輸策略都是802.3ad適應的,尤其考慮到在802.3ad標準43.2.4章節提及的包亂序問題。不同的實現可能會有不同的適應性。 
必要條件: 
 1. ethtool支援獲取每個slave的速率和雙工設定; 
 2. switch(交換機)支援IEEE 802.3ad Dynamic link aggregation。 
    大多數switch(交換機)需要經過特定配置才能支援802.3ad模式。 
 balance-tlb 或者 5 
  自適應的傳輸負載均衡:不需要任何特別的switch(交換機)支援的通道bonding。在每個slave上根據當前的負載(根據速度計算)分配外出流量。如果正在接受資料的slave出故障了,另一個slave接管失敗的slave的MAC地址。 
  必要條件: 
  ethtool支援獲取每個slave的速率。 
  balance-alb 或者 6 
  自適應均衡負載:該模式包含了balance-tlb模式,同時加上針對IPV4流量的接收負載均衡(receive load 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重新啟用時,接收流量也要重新分佈。接收的負載被順序地分佈(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接管。 
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策略。 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22664653/viewspace-712168/,如需轉載,請註明出處,否則將追究法律責任。

相關文章