? ????????鏈路聚合是在兩個設備間使用多個物理鏈路創(chuàng)建一個邏輯鏈路的功能。這種方式允許物理鏈路間共享負載。交換機網(wǎng)絡中使用的一種鏈路聚合的方法是EtherChannel。EtherChannel可以通過思科的端口聚合協(xié)議（Port Aggregation Protocol, PAgP）或鏈路聚合協(xié)議（Link Aggregation Protocol, LACP）來配置或協(xié)商。
EtherChannel：
????????EtherChannel本來是由思科開發(fā)，將若干Fast Ethernet或Gigabit Ethernet捆綁成一個邏輯通道的交換機到交換機的LAN連接技術。配置了EtherChannel之后的虛擬接口稱為一個port channel。物理接口捆綁在一起，成為一個port channel interface。思科最早稱之為EtherChannel Fast EtherChannel(FEC)，也稱為Gigabit EtherChannel(GEC)，非思科公司常將鏈路聚合簡寫為LAG。
????????通過EtherChannel，一個邏輯鏈路的速度等于所有物理鏈路的總和。例如，如果你用4個100 Mbps的以太網(wǎng)鏈路創(chuàng)建1個EtherChannel，則EtherChannel的速度是400 Mbps。但是也會有一些問題，并不是在所有情況下增加的容量都確實等于物理鏈路的速度之和。例如，四個1 Gbps鏈路組成的EtherChannel，默認每一個會話的速度還是限制在1 Gbps。
????????默認情況下EtherChannel按照報文的目的MAC地址，給它指定一個物理鏈接。這也意味著EtherChannel上一個工作站與另一個服務器通信，只會使用到一條物理鏈路。實際上，EtherChannel上所有目的地為該服務器的數(shù)據(jù)流都只會走這一條物理鏈路。也就是說，一個用戶同一時刻只會得到1 Gbps。這種模式也可以更改為每一個報文在不同的物理鏈路上發(fā)送，當有多個不同的目的地址時，每一條路徑都可以得到利用。
????????EtherChannel創(chuàng)建的是一對一的關系，即一個EtherChannel連接兩個設備。可在兩臺交換機之間，或在一個激活了EtherChannel的服務器和一臺交換機之間創(chuàng)建一個EtherChannel連接。但是，同一個EtherChannel連接無法將數(shù)據(jù)流發(fā)送到兩臺交換機。
EtherChannel負載均衡：
????????如前所述，EtherChannel默認情況下并不真的為各鏈路速度之和，只是在特定的鏈路發(fā)送特定的報文，給人的感知速度為所有鏈路的速度總和。EtherChannel幀分發(fā)使用Cisco專有的hash算法。 該算法是確定性算法； 如果使用相同的地址和會話信息，則總是散列到通道中的同一端口。 此方法可避免無序傳送數(shù)據(jù)包。這一算法中很重要的一點是，并不保證物理鏈路之間完全地均衡。
????????該算法將目的MAC地址值hash成0-7的范圍。無論EtherChannel中有多少鏈路都是同樣的值。每一條物理鏈路都指定這八個值中的一個或多個，取決于EtherChannel中共有幾條鏈路。
????????下圖顯示了按照這種算法報文是怎樣分布的，注意到分布并不總是均衡的。
????????有八條物理鏈路的EtherChannel，每條鏈路指定單一值。有六條鏈路的EtherChannel，兩條鏈路指定兩個值，剩下四條鏈路指定四個值。這意味著兩條鏈路（理論上均衡分布）會收到比剩余四條鏈路多一倍的數(shù)據(jù)流。從這張圖很明顯的看出，要使流量在各鏈路間均衡的分布（理想情況下），應當設置1，2，4，或8條物理鏈路。無論決定鏈路的信息是什么，算法都會將鏈路值hash為0-7。
????????用戶可根據(jù)需求對算法進行更改。默認行為是使用目的MAC地址，但是，按照軟硬件版本的不同，還可以有如下選項：
????????·源MAC地址
????????·目的MAC地址
????????·源和目的MAC地址
????????·源IP地址
????????·目的IP地址
????????·源和目的IP地址
????????·源端口
????????·目的端口
????????·源和目的端口
????????更改默認設置的原因由應用情況而定。下圖顯示了一種相對普遍的布局：
????????一組用戶連接到交換機A，通過EtherChannel連接到交換機B。默認按照每一個報文的目的MAC地址做負載均衡。但是，比較常見的情況是一臺服務器的流量顯著高于其他服務器。
????????讓我們假設該網(wǎng)絡中email服務器接收到多于1 Gbps流量，而其他服務器大約為50Mbps。使用基于目的MAC地址的方法會導致在EtherChannel丟包，因為目的地為email服務器MAC地址的報文會走同一條物理鏈路。一條鏈路發(fā)生過載時報文不會分散到其他鏈路，只會丟棄。在這種一臺服務器接收流量超大的情況下，目的MAC地址負載均衡就不合理了。而根據(jù)源MAC地址負載均衡更為合適。
????????另一點需要記住的是，負載均衡算法只適用于EtherChannel上發(fā)送的報文。它并沒有雙向功能。在交換機A上使用基于源MAC地址的算法可能比較合適，但對于交換機B不一定合適，因為email服務器是使用最多的服務器。當報文從email服務器返回，源MAC地址就是它自己本身。因此，如果我們在交換機B上使用基于源MAC地址的負載均衡算法，就會碰到一開始同樣的問題。
????????這種情況下，解決方法是在交換機A使用基于源MAC地址的負載均衡算法，而在交換機B使用目的MAC地址的算法。如果所有服務器在一臺交換機而所有用戶在另一臺，這一解決方案是有效的。但現(xiàn)實中更常見的情況是所有這些設備都連接在一臺交換機上，這時就沒那么走運了。
????????下圖顯示了一個比較有趣的問題。一臺服務器通過EtherChannel連接到交換機A，一臺NAS也通過EtherChannel連接到交換機A。服務器的所有文件系統(tǒng)都掛在到NAS設備上，服務器作為一臺服務超過5000人的數(shù)據(jù)庫服務器負載很大。服務器和NAS之間的帶寬需求超過2Gbps。
????????目前沒有解決這一問題的簡單的方法。不能使用源MAC地址或目的MAC地址做負載均衡，因為每種情況都只有一個地址。同樣的理由，也不能用源和目的MAC地址結合，源和目的IP地址結合的方法。也不能基于源或目的端口號，因為一旦協(xié)商結束后，它們就不會改變。一種可能的方法是，驅(qū)動支持的情況下，改變服務器和/或NAS設備，每一個link都有自己的MAC地址，但是報文還是會從其中一個地址發(fā)出另一個地址接收。
????????唯一的解決方法是手動負載均衡或采用更快的鏈接。將鏈路分為4個1Gbps，每一個有自己的IP網(wǎng)絡，每個連接mount掛載不同的文件系統(tǒng)可以解決這一問題。有點太過復雜的話，直接使用更快的物理連接，如10 Gbps。
