文章轉自Live空間(http://delxu.spaces.live.com/blog/cns!D04F87F9ED029F69!2583.entry)和51cto技術博客(http://delxu.blog.51cto.com)首發。轉發時務必表明出處，順便給博主做個廣告，文章寫的真的很好，深入淺出，期待看到更好的博文，再次表示對博主的感謝！！！
2/14/2010
2/14/2010
delxu原創文檔，如需轉帖請務必說明出處：http://delxu.spaces.live.com/blog/cns!D04F87F9ED029F69!2616.entry首先，說明幾個知識要點：
(1) 所有3種類型的VMware網絡都支持NIC Teaming （複習提問：哪3種類型？答：VMkernel, Service Console和VM port group）
(2) uplink連接到那些物理交換機的端口都必須在同一個Broadcast domain中。（也就是必須在同一個VLAN中，不能跨路由）
(3) 如果uplink要配置VLAN，則每個uplink必須都配置成VLAN Trunk並且具有相同的VLAN配置。
(4) VMware的負載均衡(Load Balancing)只是出站(Outbound)的負載均衡。（概念類似於HP術語中的TLB。關於HP負載均衡的術語詳見拙文《HP NIC Teaming技術探討》，但是它和TLB其實不同，關於這一點，請看後文解釋）
(參考：p192. Scott Lowe, 《Mastering VMware vSphere 4.0》)
(5) NIC Teaming的Load Balancing和一些高級路由算法的Load Balancing不同，它不是按照Teaming中網卡上通過的數據流量來負載均衡，而是根據網卡上的連接(connection)來進行負載均衡。
【VMware的3種負載均衡】
VMware的NIC Teaming Load Balancing策略有3種。
(1) 基於端口的負載均衡(默認)
(2) 基於源MAC的負載均衡
(3) 基於IP hash的負載均衡
(1) 所有3種類型的VMware網絡都支持NIC Teaming （複習提問：哪3種類型？答：VMkernel, Service Console和VM port group）
(2) uplink連接到那些物理交換機的端口都必須在同一個Broadcast domain中。（也就是必須在同一個VLAN中，不能跨路由）
(3) 如果uplink要配置VLAN，則每個uplink必須都配置成VLAN Trunk並且具有相同的VLAN配置。
(4) VMware的負載均衡(Load Balancing)只是出站(Outbound)的負載均衡。（概念類似於HP術語中的TLB。關於HP負載均衡的術語詳見拙文《HP NIC Teaming技術探討》，但是它和TLB其實不同，關於這一點，請看後文解釋）
(參考：p192. Scott Lowe, 《Mastering VMware vSphere 4.0》)
(5) NIC Teaming的Load Balancing和一些高級路由算法的Load Balancing不同，它不是按照Teaming中網卡上通過的數據流量來負載均衡，而是根據網卡上的連接(connection)來進行負載均衡。
【VMware的3種負載均衡】
VMware的NIC Teaming Load Balancing策略有3種。
(1) 基於端口的負載均衡(默認)
(2) 基於源MAC的負載均衡
(3) 基於IP hash的負載均衡
基於端口的負載均衡 (Route based on the originating virtual port ID)
這種方式下，負載均衡是基於vPort ID的。一個vPort和Host上的一個pNIC(從vSwitch角度看就是某個uplink)捆綁在一起，只有當這個pNIC失效的時候，才切到另外的pNIC鏈路上。這種方式的負載均衡只有在vPort數量大於pNIC的數量時才生效。
什麼是vport？一個VM上的vNIC或者某一個VMKernel或者Service Console的某個vswif。用一個圖來直觀的表述，vPort在下圖中顯示爲vSwitch上左側的那些綠點。而pNIC在圖中顯示爲右邊的vmnicX。(還記得創建一個vSwitch時候，默認的port數是56嗎？你可以設置一個vSwitch的Port數爲8，24，56，120，248，504或1016，看出什麼規律來了沒？對的，是2的某次方減8。這是因爲VMKernel需要保留8個port的緣故)
對於VM來說，因爲某臺VM的vNIC是捆綁在某一個pNIC上的，也就是說這臺VM(如果只有一個vNIC的話)對外的數據流量將固定在某一個pNIC上。這種負載均衡是在VM之間的均衡，對於某一臺VM而言，其uplink的速率不可能大於單個pNIC的速率。此外，只有當VM的數量足夠多，並且這些VM之間的數據流量基本一致的情況下，Host上的NIC Teaming的Load Balancing才較爲有效。對於以下這些極端情況，基於端口方式的負載均衡根本不起作用或者效果很差，充其量只能說是一種端口冗餘。
(1)Host上只有一臺只具有單vNIC的VM (此時完全沒有Load balancing)
(2)Host上的VM數量比pNIC少(比如有4臺VM但是Teaming中有5塊pNIC，此時有一塊pNIC完全沒用上，其他每個vNIC各自使用一塊pNIC，此時也沒有任何負載均衡實現)
(3)Host上雖然有多臺VM，但是99%的網絡流量都是某一臺VM產生的
基於源MAC地址的負載均衡 Route based on source MAC hash
這種方式下，負載均衡的實現是基於源MAC地址的。因爲每個vNIC總是具有一個固定的MAC地址，因此這種方式的負載均衡同基於端口的負載均衡具有同樣的缺點。同樣是要求vPort數量大於pNIC的時候纔會有效。同樣是vNIC的速率不會大於單個pNIC的速率。
基於IP Hash的負載均衡 Route based on IP hash
這種方式下，負載均衡的實現是根據源IP地址和目的IP地址的。因此同一臺VM(源IP地址總是固定的)到不同目的的數據流，就會因爲目的IP的不同，走不同的pNIC。只有這種方式下，VM對外的流量的負載均衡才能真正實現。
不要忘記，VMware是不關心對端物理交換機的配置的，VMware的負載均衡只負責從Host出站的流量(outbound)，因此要做到Inbound的負載均衡，必須在物理交換機上做同樣IP Hash方式的配置。此時，pNIC必須連接到同一個物理交換機上。
需要注意的是，VMware不支持動態鏈路聚合協議(例如802.3ad LACP或者Cisco的PAgP)，因此只能實現靜態的鏈路聚合。(類似於HP的SLB)。不僅如此，對端的交換機設置靜態鏈路聚合的時候也要設置成IP Hash的算法。否則這種方式的負載均衡將無法實現。
這種方式下，負載均衡是基於vPort ID的。一個vPort和Host上的一個pNIC(從vSwitch角度看就是某個uplink)捆綁在一起，只有當這個pNIC失效的時候，才切到另外的pNIC鏈路上。這種方式的負載均衡只有在vPort數量大於pNIC的數量時才生效。
什麼是vport？一個VM上的vNIC或者某一個VMKernel或者Service Console的某個vswif。用一個圖來直觀的表述，vPort在下圖中顯示爲vSwitch上左側的那些綠點。而pNIC在圖中顯示爲右邊的vmnicX。(還記得創建一個vSwitch時候，默認的port數是56嗎？你可以設置一個vSwitch的Port數爲8，24，56，120，248，504或1016，看出什麼規律來了沒？對的，是2的某次方減8。這是因爲VMKernel需要保留8個port的緣故)
對於VM來說，因爲某臺VM的vNIC是捆綁在某一個pNIC上的，也就是說這臺VM(如果只有一個vNIC的話)對外的數據流量將固定在某一個pNIC上。這種負載均衡是在VM之間的均衡，對於某一臺VM而言，其uplink的速率不可能大於單個pNIC的速率。此外，只有當VM的數量足夠多，並且這些VM之間的數據流量基本一致的情況下，Host上的NIC Teaming的Load Balancing才較爲有效。對於以下這些極端情況，基於端口方式的負載均衡根本不起作用或者效果很差，充其量只能說是一種端口冗餘。
(1)Host上只有一臺只具有單vNIC的VM (此時完全沒有Load balancing)
(2)Host上的VM數量比pNIC少(比如有4臺VM但是Teaming中有5塊pNIC，此時有一塊pNIC完全沒用上，其他每個vNIC各自使用一塊pNIC，此時也沒有任何負載均衡實現)
(3)Host上雖然有多臺VM，但是99%的網絡流量都是某一臺VM產生的
基於源MAC地址的負載均衡 Route based on source MAC hash
這種方式下，負載均衡的實現是基於源MAC地址的。因爲每個vNIC總是具有一個固定的MAC地址，因此這種方式的負載均衡同基於端口的負載均衡具有同樣的缺點。同樣是要求vPort數量大於pNIC的時候纔會有效。同樣是vNIC的速率不會大於單個pNIC的速率。
基於IP Hash的負載均衡 Route based on IP hash
這種方式下，負載均衡的實現是根據源IP地址和目的IP地址的。因此同一臺VM(源IP地址總是固定的)到不同目的的數據流，就會因爲目的IP的不同，走不同的pNIC。只有這種方式下，VM對外的流量的負載均衡才能真正實現。
不要忘記，VMware是不關心對端物理交換機的配置的，VMware的負載均衡只負責從Host出站的流量(outbound)，因此要做到Inbound的負載均衡，必須在物理交換機上做同樣IP Hash方式的配置。此時，pNIC必須連接到同一個物理交換機上。
需要注意的是，VMware不支持動態鏈路聚合協議(例如802.3ad LACP或者Cisco的PAgP)，因此只能實現靜態的鏈路聚合。(類似於HP的SLB)。不僅如此，對端的交換機設置靜態鏈路聚合的時候也要設置成IP Hash的算法。否則這種方式的負載均衡將無法實現。
|
比如Cisco 3560上的默認Etherchannel的算法是源MAC，因此需要將其修改成源和目的IP。
首先查看交換機的負載均衡的算法： show etherchannel load-balance 然後用修改負載均衡算法爲src-dst-ip port-channel load-balance src-dst-ip |
要點：配置IP Hash方式pNIC對端的物理交換機端口，要記得關閉802.3ad LACP和PAgP以減少這些動態協議帶來的不必要網絡開銷，加快鏈路在failover時的轉換速度。
這種方式的缺點是，因爲pNIC是連接到同一臺物理交換機的，因此存在交換機的單點失敗問題。（這和HP SLB的缺點一樣，詳見拙文《HP NIC Teaming技術探討》）。此外，在點對點的鏈路中（比如VMotion），2端地址總是固定的，所以基於IP Hash的鏈路選擇算法就失去了意義。
不管採用以上哪一種方法的Load Balancing，它會增加總聚合帶寬，但不會提升某單個連接所獲的帶寬。爲啥會這樣？同一個Session中的數據包爲啥不能做到Load Balancing？這是因爲網絡的7層模型中，一個Session在傳輸過程中會被拆分成多個數據包，並且到目的之後再重組，他們必須具有一定的順序，如果這個順序弄亂了，那麼到達目的重組出來的信息就是一堆無意義的亂碼。這就要求同一個session的數據包必須在同一個物理鏈路中按照順序傳輸過去。所以，10條1Gb鏈路組成的10Gb的聚合鏈路，一定不如單條10Gb鏈路來的高速和有效。（詳見Fraizer: IEEE 802.3ad Link Aggregation)
【選擇】
那麼應該選擇哪種NIC Teaming方式呢？大拿Scott Lowe建議： (LAG) - What it is, and what it is not
· 如果使用鏈路聚合，必須設爲“Route based on IP hash”
· 如果不是使用鏈路聚合，可以設爲任何其它設置。大多數情況下，接受默認設置“Route based on originating virtual port ID”是最好的。
【更好的選擇及其缺陷】
還有沒有更好選擇？答案是有。Cross-Stack Link Aggregation，跨堆疊交換機的鏈路聚合。
堆疊交換機通過堆疊線連接在一起，組成一個交換機堆疊棧。堆疊棧中的交換機共享同一個Forwarding Table。
堆疊交換機組在邏輯上被視作1臺交換機，但是在物理上則是2臺或多臺不同的設備。
這和NIC Teaming是不是很像？
Teamport 在邏輯上是一個端口，但是在物理上卻是2個或多個端口。
(突然想到，在一切都套上“虛擬化”的帽子的今日，不知道以後交換機堆疊技術會不會改名爲交換機虛擬化？就像存在了多少年的RAID突然被套上了磁盤虛擬化的帽子一樣，笑~~)
如圖，SLB中的2條鏈路就可以不侷限在同一臺物理交換機上了，而可以分別連接到2臺堆疊在一起的物理交換機上(切記，交換機堆疊必須連成環以保證冗餘性)。此時，SLB的最大缺陷——交換機的單點失敗就被克服了。這樣，就可以既達到容錯又達到雙向負載均衡的目的了。
但是，這種方式的缺點是要求物理交換機具有堆疊能力。很遺憾的是，HP支持工程師告訴我，到目前爲止，HP用於c-class刀片服務器機箱的所有以太網交換機都不支持堆疊。(信息獲取時間2010年1月，不排除以後HP會提供支持堆疊的刀片交換機)
【參考文檔】
本文的主要參考的文檔如下：
(1) Scott Lowe, 《Mastering VMware vSphere 4.0》
(2) VMware Infrastructure 3環境下的物理網絡設計 (Scott Lowe)
http://www.searchsv.com.cn/showcontent_14740.htm?lg=t
(3)如何在VMware ESX上實現網卡聚合？
http://www.searchsv.com.cn/showcontent_24716.htm
(4) ESX Server, NIC Teaming, and VLAN Trunking （Scott Lowe)
http://blog.scottlowe.org/2006/12/04/esx-server-nic-teaming-and-vlan-trunking/
(5) IEEE 802.3ad Link Aggregation
http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf (LAG) - What it is, and what it is not
(1) Scott Lowe, 《Mastering VMware vSphere 4.0》
(2) VMware Infrastructure 3環境下的物理網絡設計 (Scott Lowe)
http://www.searchsv.com.cn/showcontent_14740.htm?lg=t
(3)如何在VMware ESX上實現網卡聚合？
http://www.searchsv.com.cn/showcontent_24716.htm
(4) ESX Server, NIC Teaming, and VLAN Trunking （Scott Lowe)
http://blog.scottlowe.org/2006/12/04/esx-server-nic-teaming-and-vlan-trunking/
(5) IEEE 802.3ad Link Aggregation
http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf (LAG) - What it is, and what it is not
2/6/2010
原創文檔，轉載請註明出處http://delxu.spaces.live.com
NIC Teaming技術將2個或更多個網卡(HP NIC Teaming最多可達8個)捆綁在一起使用，以達到增加總的帶寬(Load Balance，負載均衡)或者線路容錯(Fault Tolerance)的目的。由2個或多個網卡組成一個邏輯網絡端口Teamport，IP地址和網絡設置綁定在這個邏輯的Teamport上，這樣，無論哪一個物理網卡或者其相連的鏈路單獨出現故障，Teamport還是能正常工作，服務器對外的網絡連接不會中斷。
爲了方便說明，除非特別說明，本文以下部分的例子中將2個或多個網卡一律寫成2個網卡，示意圖也只畫2個網卡。
HP服務器的NIC Teaming分三大類共7個選項，這三大類是指NFT、TLB和SLB。（7個選項後文會說明）
【NFT】
NFT 就是Network Fault Tolerant的縮寫，這種模式下一個網卡處於活動(Active)狀態，而另外一個網卡處於待機(standby)狀態，平時只有一個網卡在用。NFT模式下，組成Teamport的2個1Gb的網卡分別連到2個不同的交換機，Teamport總帶寬只有1Gb，這種模式具有容錯能力，但是不具有增加帶寬和負載均衡的能力。
【TLB】
TLB就是Transmit Load Balance，從字面上理解，就是傳出(Tx)的負載均衡，也就是說，從服務器向外部發送的數據包，根據一定的規則，分別從Teamport中的2個網卡傳出去，但是這種方式，不能保證接受(Rx)的數據包也同樣能夠負載均衡。簡單的說，TLB可以做到網絡容錯，Teamport的Tx是2Gb帶寬，Rx還是隻有1Gb（除非有另外的方法來做負載均衡）
【SLB】
SLB是Switch-assist Load Balance，顧名思義，交換機協助的負載均衡，就是需要在交換機上進行相應的配置以後才能實現。SLB Team中的2個網卡必須連接到同一個交換機，這2個網卡到同一交換機的2個端口之間的鏈路就合併組成一個通道，這個通道Cisco交換機術語叫Etherchannel，其他廠商的交換機則常稱這個爲Port Trunk。這種組成聯合通道的方式也稱之爲靜態的鏈路聚合(SLA, Static Link Aggregation)。SLB方式的Teamport是雙向2Gb，Tx和Rx的數據流都可以做到負載均衡，但是它只能保證網卡的容錯，做不到交換機的容錯。
注意(1)：應用SLB時還要特別注意SLB的負載均衡實現方式和對端交換機的限制。一般而言，很多廠商的交換機，都要求同一個聚合鏈路中的每個端口都必須是一致的，例如千兆端口不能和百兆端口聚合，百兆全雙工的端口不能和百兆半雙工的端口聚合。
注意(2): 不同廠商的負載均衡的算法有所不同，比如某些型號的Cisco交換機的Etherchannel是Layer 2的，有3種Load Balancing方式：基於源MAC，基於目的MAC和XOR方式；而其他一些型號或其他廠商的交換機還可以根據源IP，IP Hash或者TCP Session等的方式。如要繼續深入研究並理解這些算法的優劣，請參考相關交換機廠商的文檔。
(關於不同型號思科交換機的Etherchannel的異同和負載均衡的算法，請參考：http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml
【NFT/TLB/SLB比較】
這三種方式的比較如下：)
爲了方便說明，除非特別說明，本文以下部分的例子中將2個或多個網卡一律寫成2個網卡，示意圖也只畫2個網卡。
HP服務器的NIC Teaming分三大類共7個選項，這三大類是指NFT、TLB和SLB。（7個選項後文會說明）
【NFT】
NFT 就是Network Fault Tolerant的縮寫，這種模式下一個網卡處於活動(Active)狀態，而另外一個網卡處於待機(standby)狀態，平時只有一個網卡在用。NFT模式下，組成Teamport的2個1Gb的網卡分別連到2個不同的交換機，Teamport總帶寬只有1Gb，這種模式具有容錯能力，但是不具有增加帶寬和負載均衡的能力。
【TLB】
TLB就是Transmit Load Balance，從字面上理解，就是傳出(Tx)的負載均衡，也就是說，從服務器向外部發送的數據包，根據一定的規則，分別從Teamport中的2個網卡傳出去，但是這種方式，不能保證接受(Rx)的數據包也同樣能夠負載均衡。簡單的說，TLB可以做到網絡容錯，Teamport的Tx是2Gb帶寬，Rx還是隻有1Gb（除非有另外的方法來做負載均衡）
【SLB】
SLB是Switch-assist Load Balance，顧名思義，交換機協助的負載均衡，就是需要在交換機上進行相應的配置以後才能實現。SLB Team中的2個網卡必須連接到同一個交換機，這2個網卡到同一交換機的2個端口之間的鏈路就合併組成一個通道，這個通道Cisco交換機術語叫Etherchannel，其他廠商的交換機則常稱這個爲Port Trunk。這種組成聯合通道的方式也稱之爲靜態的鏈路聚合(SLA, Static Link Aggregation)。SLB方式的Teamport是雙向2Gb，Tx和Rx的數據流都可以做到負載均衡，但是它只能保證網卡的容錯，做不到交換機的容錯。
注意(1)：應用SLB時還要特別注意SLB的負載均衡實現方式和對端交換機的限制。一般而言，很多廠商的交換機，都要求同一個聚合鏈路中的每個端口都必須是一致的，例如千兆端口不能和百兆端口聚合，百兆全雙工的端口不能和百兆半雙工的端口聚合。
注意(2): 不同廠商的負載均衡的算法有所不同，比如某些型號的Cisco交換機的Etherchannel是Layer 2的，有3種Load Balancing方式：基於源MAC，基於目的MAC和XOR方式；而其他一些型號或其他廠商的交換機還可以根據源IP，IP Hash或者TCP Session等的方式。如要繼續深入研究並理解這些算法的優劣，請參考相關交換機廠商的文檔。
(關於不同型號思科交換機的Etherchannel的異同和負載均衡的算法，請參考：http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml
【NFT/TLB/SLB比較】
這三種方式的比較如下：)
|
|
NFT
|
TLB
|
SLB
|
|
網卡容錯
|
支持
|
支持
|
支持
|
|
交換機容錯
|
支持
|
支持
|
不支持
|
|
Tx負載均衡
|
不支持
|
支持
|
支持
|
|
Rx負載均衡
|
不支持
|
不支持
|
支持
|
【HP的NIC Teaming】
HP Proliant系列服務器的NIC Teaming是通過其PSP(Proliant Support Pack)中的NCU (Network Configuration Utility)來實現的。雙擊右下Systray中的HP網絡工具的小圖標，就能打開NCU配置界面。
從下面的截圖我們可以看見，HP Network Team #1是一個Teamport，它由2個HP NC7782千兆端口組成。Teamport左邊的綠色圖標說明它目前工作正常。端口1是實線，說明其處於Active狀態，端口2有一部分虛灰的顏色，表明這個鏈路是Standby的。
點擊Teamport，然後點Property按鈕，就可以打開Teamport的屬性配置界面，在這裏，我們可以選擇HP NIC Teaming的類型。
從圖中我們可以看到，HP的Team類型有7個選擇，分別是
HP Proliant系列服務器的NIC Teaming是通過其PSP(Proliant Support Pack)中的NCU (Network Configuration Utility)來實現的。雙擊右下Systray中的HP網絡工具的小圖標，就能打開NCU配置界面。
從下面的截圖我們可以看見，HP Network Team #1是一個Teamport，它由2個HP NC7782千兆端口組成。Teamport左邊的綠色圖標說明它目前工作正常。端口1是實線，說明其處於Active狀態，端口2有一部分虛灰的顏色，表明這個鏈路是Standby的。
點擊Teamport，然後點Property按鈕，就可以打開Teamport的屬性配置界面，在這裏，我們可以選擇HP NIC Teaming的類型。
從圖中我們可以看到，HP的Team類型有7個選擇，分別是
· Automatic (Recommended)
· 802.3ad Dynamic with Fault Tolerance
· Switch-assisted Load Balancing with Fault Tolerance (SLB)
· Transmit Load Balancing with Fault Tolerance (TLB)
· Transmit Load Balancing with Fault Tolerance and Preference Order
· Network Fault Tolerance Only (NFT)
· Network Fault Tolerance with Preference Order
我們發現上面這些選擇中毫無例外的都註明了Fault Tolerance，這恰恰說明了NIC Teaming的最重要的目的：容錯。
這其中的SLB, TLB, NFT前文已經介紹過了。這裏再解釋下其他幾個。
【NFT with PO和TLB with PO】
Preference Order就是指一種優先順序，這種順序往往是根據鏈路類型、速率等方式決定的。
NFT with Preference Order就是帶有優先順序的NFT。舉例說明，比如一臺NFT的Teamport是由一個千兆的Port A和一個百兆的Port B組成的，則Port A由於傳輸速率快，優於Port B，所以Port A會成爲Active，而Port B則爲Standby。TLB with Preference Order同理，通常用於將不同速率端口綁定在一起的情況下。
【802.3ad Dynamic】
和SLB類似，802.3ad Dynamic 方式也是到同一臺交換機的鏈路聚合，只不過不是手工配置(靜態)的，而是自動協商(動態構成)的。它是通過一種智能的鏈路協商協議LACP (Link Aggregation Control Protocol)來實現的。LACP原本用於交換機和交換機之間的鏈路聚合，啓用了LACP協議的2臺交換機會相互發送LACP的協商報文，當發現2者之間有多條可用的鏈路的時候，自動將這些鏈路組合成一條帶寬更大的邏輯鏈路，從而利用負載均衡來實現加寬交換機間鏈路帶寬的目的。HP的NIC Teaming也支持動態鏈路聚合，可以實現在HP服務器和支持802.3ad 動態LACP的交換機之間自動創建聚合鏈路。
【Automatic】
Automatic (Recommended) 其實不是一種單獨的模式，當選擇Automatic的時候，會判斷Team中的這些port是不是連接到同一個支持802.3ad Dynamic LACP協議的交換機，如果是，則選擇802.3ad Dynamic方式；如果不是，則使用TLB方式。
如想繼續深入HP的NIC Teaming技術，比如研究Load Balancing算法、檢測鏈路失敗的方法和鏈路恢復等，請閱讀HP NIC Teaming White Paper (英文) 。
【參考文檔】
(1) HP NIC Teaming White Paper (英文)
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01415139/c01415139.pdf
這其中的SLB, TLB, NFT前文已經介紹過了。這裏再解釋下其他幾個。
【NFT with PO和TLB with PO】
Preference Order就是指一種優先順序，這種順序往往是根據鏈路類型、速率等方式決定的。
NFT with Preference Order就是帶有優先順序的NFT。舉例說明，比如一臺NFT的Teamport是由一個千兆的Port A和一個百兆的Port B組成的，則Port A由於傳輸速率快，優於Port B，所以Port A會成爲Active，而Port B則爲Standby。TLB with Preference Order同理，通常用於將不同速率端口綁定在一起的情況下。
【802.3ad Dynamic】
和SLB類似，802.3ad Dynamic 方式也是到同一臺交換機的鏈路聚合，只不過不是手工配置(靜態)的，而是自動協商(動態構成)的。它是通過一種智能的鏈路協商協議LACP (Link Aggregation Control Protocol)來實現的。LACP原本用於交換機和交換機之間的鏈路聚合，啓用了LACP協議的2臺交換機會相互發送LACP的協商報文，當發現2者之間有多條可用的鏈路的時候，自動將這些鏈路組合成一條帶寬更大的邏輯鏈路，從而利用負載均衡來實現加寬交換機間鏈路帶寬的目的。HP的NIC Teaming也支持動態鏈路聚合，可以實現在HP服務器和支持802.3ad 動態LACP的交換機之間自動創建聚合鏈路。
【Automatic】
Automatic (Recommended) 其實不是一種單獨的模式，當選擇Automatic的時候，會判斷Team中的這些port是不是連接到同一個支持802.3ad Dynamic LACP協議的交換機，如果是，則選擇802.3ad Dynamic方式；如果不是，則使用TLB方式。
如想繼續深入HP的NIC Teaming技術，比如研究Load Balancing算法、檢測鏈路失敗的方法和鏈路恢復等，請閱讀HP NIC Teaming White Paper (英文) 。
【參考文檔】
(1) HP NIC Teaming White Paper (英文)
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01415139/c01415139.pdf