[轉]網絡基本功06-鏈路聚合
❝本文由Zhang_Jiawen發表於Dell Technology"網絡基本功"
如有侵犯版權,還請這位頭像萌萌的大姐姐前輩聯繫我商討刪帖,道歉,賠償,下跪等事宜.
❞
鏈路聚合是在兩個設備間使用多個物理鏈路創建一個邏輯鏈路的功能。這種方式允許物理鏈路間共享負載。交換機網絡中使用的一種鏈路聚合的方法是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。
本文使用 mdnice 排版