網路基本功（六）：鏈路聚合

來自專欄計算機網路學習筆記

轉載請在文首保留原文出處：EMC中文支持論壇https://community.emc.com/go/chinese

介紹

鏈路聚合是在兩個設備間使用多個物理鏈路創建一個邏輯鏈路的功能。這種方式允許物理鏈路間共享負載。交換機網路中使用的一種鏈路聚合的方法是EtherChannel。EtherChannel可以通過思科的埠聚合協議（Port Aggregation Protocol, PAgP）或鏈路聚合協議（Link Aggregation Protocol, LACP）來配置或協商。

更多信息

EtherChannel：

EtherChannel本來是由思科開發，將若干Fast Ethernet或Gigabit Ethernet捆綁成一個邏輯通道的交換機到交換機的LAN連接技術。配置了EtherChannel之後的虛擬介面稱為一個port channel。物理介面捆綁在一起，成為一個port channel interface。思科最早稱之為EtherChannel Fast EtherChannel(FEC)，也稱為Gigabit EtherChannel(GEC)，非思科公司常將鏈路聚合簡寫為LAG。

通過EtherChannel，一個邏輯鏈路的速度等於所有物理鏈路的總和。例如，如果你用4個100 Mbps的乙太網鏈路創建1個EtherChannel，則EtherChannel的速度是400 Mbps。但是也會有一些問題，並不是在所有情況下增加的容量都確實等於物理鏈路的速度之和。例如，四個1 Gbps鏈路組成的EtherChannel，默認每一個會話的速度還是限制在1 Gbps。

默認情況下EtherChannel按照報文的目的MAC地址，給它指定一個物理鏈接。這也意味著EtherChannel上一個工作站與另一個伺服器通信，只會使用到一條物理鏈路。實際上，EtherChannel上所有目的地為該伺服器的數據流都只會走這一條物理鏈路。也就是說，一個用戶同一時刻只會得到1 Gbps。這種模式也可以更改為每一個報文在不同的物理鏈路上發送，當有多個不同的目的地址時，每一條路徑都可以得到利用。

EtherChannel創建的是一對一的關係，即一個EtherChannel連接兩個設備。可在兩台交換機之間，或在一個激活了EtherChannel的伺服器和一台交換機之間創建一個EtherChannel連接。但是，同一個EtherChannel連接無法將數據流發送到兩台交換機。

EtherChannel負載均衡：

如前所述，EtherChannel默認情況下並不真的為各鏈路速度之和，只是在特定的鏈路發送特定的報文，給人的感知速度為所有鏈路的速度總和。EtherChannel 幀分發使用 Cisco 專有的hash演算法。 該演算法是確定性演算法； 如果使用相同的地址和會話信息，則總是散列到通道中的同一埠。 此方法可避免無序傳送數據包。這一演算法中很重要的一點是，並不保證物理鏈路之間完全地均衡。

該演算法將目的MAC地址值hash成0-7的範圍。無論EtherChannel中有多少鏈路都是同樣的值。每一條物理鏈路都指定這八個值中的一個或多個，取決於EtherChannel中共有幾條鏈路。

下圖顯示了按照這種演算法報文是怎樣分布的，注意到分布並不總是均衡的。

有八條物理鏈路的EtherChannel，每條鏈路指定單一值。有六條鏈路的EtherChannel，兩條鏈路指定兩個值，剩下四條鏈路指定四個值。這意味著兩條鏈路（理論上均衡分布）會收到比剩餘四條鏈路多一倍的數據流。從這張圖很明顯的看出，要使流量在各鏈路間均衡的分布（理想情況下），應當設置1，2，4，或8條物理鏈路。無論決定鏈路的信息是什麼，演算法都會將鏈路值hash為0-7。

用戶可根據需求對演算法進行更改。默認行為是使用目的MAC地址，但是，按照軟硬體版本的不同，還可以有如下選項：

• 源MAC地址
• 目的MAC地址
• 源和目的MAC地址
• 源IP地址
• 目的IP地址
• 源和目的IP地址
• 源埠
• 目的埠
• 源和目的埠

更改默認設置的原因由應用情況而定。下圖顯示了一種相對普遍的布局：

一組用戶連接到交換機A，通過EtherChannel連接到交換機B。默認按照每一個報文的目的MAC地址做負載均衡。但是，比較常見的情況是一台伺服器的流量顯著高於其他伺服器。

讓我們假設該網路中email伺服器接收到多於1 Gbps流量，而其他伺服器大約為50Mbps。使用基於目的MAC地址的方法會導致在EtherChannel丟包，因為目的地為email 伺服器 MAC地址的報文會走同一條物理鏈路。一條鏈路發生過載時報文不會分散到其他鏈路，只會丟棄。在這種一台伺服器接收流量超大的情況下，目的MAC地址負載均衡就不合理了。而根據源MAC地址負載均衡更為合適。

另一點需要記住的是，負載均衡演算法只適用於EtherChannel上發送的報文。它並沒有雙向功能。在交換機A上使用基於源MAC地址的演算法可能比較合適，但對於交換機B不一定合適，因為email伺服器是使用最多的伺服器。當報文從email伺服器返回，源MAC地址就是它自己本身。因此，如果我們在交換機B上使用基於源MAC地址的負載均衡演算法，就會碰到一開始同樣的問題。

這種情況下，解決方法是在交換機A使用基於源MAC地址的負載均衡演算法，而在交換機B使用目的MAC地址的演算法。如果所有伺服器在一台交換機而所有用戶在另一台，這一解決方案是有效的。但現實中更常見的情況是所有這些設備都連接在一台交換機上，這時就沒那麼走運了。

下圖顯示了一個比較有趣的問題。一台伺服器通過EtherChannel連接到交換機A，一台NAS也通過EtherChannel連接到交換機A。伺服器的所有文件系統都掛在到NAS設備上，伺服器作為一台服務超過5000人的資料庫伺服器負載很大。伺服器和NAS之間的帶寬需求超過2Gbps。

目前沒有解決這一問題的簡單的方法。不能使用源MAC地址或目的MAC地址做負載均衡，因為每種情況都只有一個地址。同樣的理由，也不能用源和目的MAC地址結合，源和目的IP地址結合的方法。也不能基於源或目的埠號，因為一旦協商結束後，它們就不會改變。一種可能的方法是，驅動支持的情況下，改變伺服器和/或NAS設備，每一個link都有自己的MAC地址，但是報文還是會從其中一個地址發出另一個地址接收。

唯一的解決方法是手動負載均衡或採用更快的鏈接。將鏈路分為4個1Gbps，每一個有自己的IP網路，每個連接mount掛載不同的文件系統可以解決這一問題。有點太過複雜的話，直接使用更快的物理連接，如10 Gbps。

PS：在gitbook上看到一本好書，但是無奈gitbook不掛梯子訪問太慢了。為了方便自己查閱，也方便知識共享，將文章轉載到知乎專欄，由於沒有聯繫到作者（據說是個女神）冒昧掛上來，如果有冒犯的地方，聯繫我我隨時進行刪除。謝謝。

作者：Zhang Jiawen

來源：網路基本功系列：細說網路那些事兒