多張網路卡聚合：備援還是速度

伺服器有兩張網路卡，想要兩張都用上。到這裡為止，大家的想法都一樣。分歧從下一個問題開始：為什麼。

兩個不同的目標

備援：網路線鬆脫、網路卡故障或交換器連接埠失效時，什麼都不會停止。得到的是持續運作，而不是速度。

總頻寬：同一時間可以承載更多流量。得到的是容量，代價是交換器那一側也要做設定。

在大多數架構中，真正想要的是前者，但設定卻是為後者而做。結果通常是同時出現兩種失望：期待的速度沒有出現，設定也變得更脆弱。

分界的問題：交換器需不需要知道

有些模式不需要另一端做任何事，搭配一般的交換器就能運作。其他模式則需要在交換器上定義對應的群組。沒有先準備好交換器那一側就選用第二類模式，是失去這台機器最常見的方式之一，而且就發生在套用的那一刻。

規則很簡單：如果無法存取交換器，或無法在上面定義任何東西，就選擇不需要另一端做任何事的模式。

關於速度最常見的誤解

聚合網路卡並不會讓單一傳輸變快。單一連線始終只走單一條鏈路。效益要在同時有多條連線時才會出現。有人把兩張卡聚合起來，用複製一個檔案來測試，看到的是一張卡的速度，就認為壞掉了。它沒有壞，是量測方式錯了。

如果目標是讓一次大型傳輸更快，正確的答案是一張更快的網路卡，而不是聚合。

最不起眼、卻最實用的選擇

不需要另一端做任何事的備援模式，對大多數伺服器來說都是正確答案。它不會增加速度，但網路線被拔掉時沒有人會察覺。它常因為太無聊而被略過，偏偏它正是大多數架構所要找的東西。

沒測試過，就等於不存在

Bond 在測試之前只是一個假設。先看看實際承載流量的是哪一條鏈路，然後在自己選定的時機刻意拔掉一條網路線，確認流量真的轉移到另一條。略過這項測試的架構，會在真正發生故障的那天才發現 bond 從來沒有運作過。

順序不要弄反

Bond 是實體層，橋接器位於它之上。虛擬機器連接的是橋接器，而不是 bond。如果反過來建置，得到的會是一個看似能運作、卻在第一次故障時就崩解的結構。

Atlas 的做法

建立 bond 時，Atlas 會顯示四種模式，每種都附有說明，並且預設為不需要另一端做任何事的模式，讓最安全的選項成為起點。如果選擇需要在交換器上定義對應群組的模式，就會出現警告，警告會指出所需的技術名稱，並明白說明連線可能會中斷。即使忽略警告繼續進行，網路變更也受到回復倒數計時的保護：如果沒有確認，舊的設定會自行恢復。