端口聚合(端口聚合是什么意思)

鏈路聚合是在兩個設備間使用多個物理鏈路創建一個邏輯鏈路的功能。這種方式允許物理鏈路間共享負載。交換機網絡中使用的一種鏈路聚合的方法是 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地址，但是，按照軟硬件版本的不同，還可以有如下選項：

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

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

讓我們假設該網絡中 E-mail服務器接收到多于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。