不宜使用鏈路聚合的場景
最近碰到的一個詭異的案例，讓我對鏈路聚合有了更深入的理解，可能對你也會有所啟發。
問題
需要從多個相機採集圖片傳給電腦，總流速超過千兆，但在4千兆以下。考慮到萬兆網卡和（萬兆上行埠的）交換機都還太貴，決定還是使用鏈路聚合。
交換機上用4個千兆口連接電腦，電腦上使用一塊4口千兆網卡做聚合。
最初的測試
儘管我的目標是10個相機同時傳數據給電腦，但第一步還是用4個相機做測試。4個相機對應於4個網口，預期的效果是應該和劃分為4個子網的方式相同，即每個相機都可以跑到接近千兆。
為什麼不用4個子網呢（即一個網口一個子網，帶一個相機）？——因為聚合的方案配置簡單，且更靈活，可以適用於N個相機，能夠動態平衡負載。相當於電腦和交換機有一條4千兆的鏈路，隨便多少個相機去分這個帶寬。
聚合的缺點是有可能增加CPU負載。但這個要看聚合的模式。由於電腦主要是收數據，交換機轉發來自相機來數據，所以需要交換機端也支持聚合。
使用的交換機是支持802.3ad的，所以在電腦端也要配置為802.3ad模式。下面是Ubuntu下的配置文件。
auto enp5s0f0
iface enp5s0f0 inet manual
bond-master bond0
auto enp5s0f1
iface enp5s0f1 inet manual
bond-master bond0
auto enp5s0f2
iface enp5s0f2 inet manual
bond-master bond0
auto enp5s0f3
iface enp5s0f3 inet manual
bond-master bond0
auto bond0
iface bond0 inet static
address 10.8.5.1
netmask 255.255.255.0
mtu 9000
bond-slaves enp5s0f0 enp5s0f1 enp5s0f2 enp5s0f3
bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate 1
實際測試下來，網卡聚合驅動（bonding）的CPU佔用不高（可以通過/proc/interrupts查看）。
在交換機管理界面上可以看到數據流量的情況。
圖中可以看到連接相機的4個網口和連接電腦的4個網口流量相當，並且是均勻的。這個效果完全符合預期。
進一步的測試
於是開始增加更多的相機（當然，同時把相機的流速調低，以滿足總速度不超過4千兆），但發現4個網口的流量並不均勻！
於是減少相機，退回到4個相機的情況。———詭異的事出現了，4個相機也不正常了！表現為流量只走3個網口（當然會有一個網口超流量，表現為丟幀）。
繼續減少相機，結果，，3個相機也擠在兩個網口上。如圖（我甚至還換了一台交換機做測試）。
不斷地嘗試後，發現了一點規律。
比如說A, B, C 三個相機發數據，正常（分流到3個埠）；
加入相機D後，不正常，表現為A和D都走了交換機的同一埠。
這時，即使只接A和D，也是不常的，因為它倆還是走同一埠；
問題出在哪裡？
碰到這種問題，首先想到的是，是不是有參數配置不對？
首先看聚合模式，有好幾種流量均衡的模式，比如：balance-rr, balance-xor, balance-tlb。但它們都是說的電腦端發送數據的情況，用不同的演算法，選擇從哪個網口將數據發出。而我的情況是交換機發數據，交換機選擇從哪個埠將數據發出，那幾種模式都不是用於控制交換機的。
在交換機上，如果啟用聚合，就是使用交換機支持的802.3ad模式，這時，電腦端相應的也要配置為802.3ad模式，所以對於模式，我們沒什麼選擇的餘地。
再看802.3ad模式下，還有什麼參數可以配置？
有一個相關的參數是：transmit hash policy
在802.3ad模式下，有layer2和layer2+3可以選擇。看文檔中的說明：
xmit_hash_policy
Selects the transmit hash policy to use for slave selection in
balance-xor, 802.3ad, and tlb modes.Possible values are:
layer2
Uses XOR of hardware MAC addresses and packet type ID
field to generate the hash. The formula is
hash = source MAC XOR destination MAC XOR packet type ID
slave number = hash modulo slave count
This algorithm will place all traffic to a particular
network peer on the same slave.
This algorithm is 802.3ad compliant.
這個文檔來自於Linux Ethernet Bonding Driver HOWTO。由於是標準，我們可以認為交換機上也是使用同樣的演算法。
這個演算法的意思是：用源地址、目標地址以及包類型得到一個hash值，然後除以4（聚合的埠／網口數），根據餘數，決定數據發往哪個埠。
這裡面首先說明了，來自同一個相機的數據（這裡的應用協議是固定的，所以packet type ID固定）一定是發往同一個埠的，而不是像Round-robin這樣的策略，使用不同的埠輪流發送。
第二點說明了，它是根據hash降以總埠數的餘數來選擇埠。另一個策略 layer2+3 我沒有貼出來，它只不過是hash演算法不同，最後也是看餘數。
那麼，問題就在這裡了。
我的運氣有多好？
這是一個數學問題：隨機生成4個0～3之間的整數，它們完全不同的概率是多少？
概率組合有點忘了，好像應該是 3/4 * 2/4 * 1/4 = 3/32 = 9.375%.
這就是在交換機上隨便接4個相機，在4個埠聚合的模式下，它們的數據正好從4個不同的埠轉發出去的概率。
我最初接的4個相機正好中了這9.375%的彩。而後來回退到4個相機的時候，其實是慌亂中換了相機，接著再怎麼換相機，都有衝突。因為90.625%的概率就是會相撞，所以有衝突才是常態。
模擬實驗
為了理解什麼場景下適合使用聚合，我們可以做一個模擬實驗。
交換機使用4個埠聚合。模擬在接N個設備的情況下，每個埠會轉發多少個設備的流量。
模擬代碼（Python）如下：
import matplotlib.pyplot as plt
import random
def simulate(device, round=100):
plt.figure(figsize=(10, 7))
fof = [0 for x in range(device + 1)]
for i in range(round):
freq = [0, 0, 0, 0]
for j in range(device):
port = random.randint(0, 3)
freq[port] += 1
for f in freq:
fof[f] += 1
plt.plot(fof)
plt.title("N of device traffic to ports: {} devices {} rounds".format(device, round))
plt.show()
- 內循環用一個簡單的隨機數模擬每個設備來的流量會經哪個埠轉發出去；
- freq 統計每個埠轉發了幾個設備的流量；
- 最後的結果fof是統計頻率的頻率。
舉個例子，比如freq = [1, 2, 1, 0]表示:
- 1個設備的流量走了埠0，
- 2個走了埠1，
- 1個走了埠2，
- 沒有流量走埠3；
相應的fof的統計是：
- 0流量的情況加1次(沒有流量走埠3），
- 1流量的情況加2次（埠0和埠2各1次），
- 2流量的情況加1次（埠1）。
模擬的結果：
4個設備時，每埠轉發流量分布
在這個圖中，可以看到，只有4個設備時，經常有埠沒有流量。1萬次試驗就有1.25萬個埠沒流量，這幾乎平均每次都有一個埠沒流量，有埠沒流量就意味著有的埠會轉發來自至少兩個設備來的流量，這就是前面說的流量不均衡的情況。
40個設備時，每埠轉發流量分布
400個設備時，每埠轉發流量分布
隨著設備的增多，流量會越來越平均。比如400個設備時，一個埠大多數情況下都會轉發100個左右（80~120）設備的流量。
結語
鏈路聚合適用於終端數量多，每個終端流速不太高的情況。這樣很容易從統計上達到平衡，不至於出現某一聚合埠流速超出帶寬的情況。其實這也是伺服器上的常見場景。比如一台伺服器，要接受成千上萬的訪問，每個訪問的流量都不高，但總體上會超過單網口的帶寬，這樣就適合用多網口做鏈路聚合。
而對於我這個案例，終端數量少，每個終端的流速高（接近單網口的帶寬），加上是終端發數據為主，交換機上的聚合模式有限，這樣就很容易由於流量不平衡導致單個聚合埠超出帶寬。
通過這個例子，還理解了為什麼要有那麼多種聚合模式、hash策略。比如伺服器上的應用，可能並不能完全用Mac地址來做hash，於是有了layer3, layer4的hash，這樣才可以標識區分internet上的終端，以達到流量均衡。
另一個感受是：在技術上，再詭異的事情總會有一個合理的解釋。
