解決服務器聚合中的中斷問題

引言：隨著服務的提升，廣電雙向網絡的各類服務器流量逐步提升。由于安全性及穩定性的要求，避免單點故障，網線也需要有備份。這就要求我們針對很多設備采用多網卡聚合分擔流量和單點風險。而手動聚合會導致服務器的服務中斷一小會兒。下面筆者就結合自身經驗，談一談設計網卡bonding腳本解決服務器聚合中的業務中斷問題。

手動聚合的隱患

隨著濟寧廣電雙向網業務，特別是智慧系列業務的增加，濟寧市每個縣都逐步增加了服務器的數量，每臺服務器上的流量也從幾百Mbps增加到了兩三個Gbps，這就需要對服務器的千兆網卡做聚合。由于縣區一些同事術業有專攻，對Linux可能不熟悉，需要市公司遠程進行配置。

如此操作存在隱患：手動配置比較慢，網絡調整中服務中斷的時間過長。如果加快配置速度，一旦整個配置的流程有任何地方出現失誤，就會導致服務器斷網，沒法再遠程調整，只能開車去縣公司修復，反而導致中斷時間更長。

網卡綁定方法明細

Linux服務器的網絡組件共有7種綁定方法。但在某些中文搜索引擎上搜索出來的linux網卡聚合綁定方式，內容大同小異，甚至部分搜索結果中某命令中單詞錯誤的字母都一樣，很明顯都是蜘蛛機器人（網絡爬蟲）自動采集出來的文章（各蜘蛛網站都有SEO優化，蜘蛛會自動替換同義詞以便欺騙搜索引擎的相應檢測功能）。

有可能原始文章的作者寫的非常清楚明白，但搜索頁面的前幾頁的結果都是有各種問題的，我們已經很難找到真正的實用原文了。

筆者直接到redhat官方產品手冊30.8.Specific Kernel Module Capabilities章節中找到了七種綁定模式（mode）的英文說明。

下面結合網絡運維中交換機的操作，簡略介紹各種模式的選擇。配置文件中，模式的選擇是用mode=參數，其中可以是0-6七個數字，也可以是對應的單詞。

1.Mode=0，balance-rr

輪詢容錯、負載均衡。數據從每個綁定的網卡按順序依次收發。但缺點是不同的包由于走不同的口子，到達目的地的順序可能會錯亂。交換機不用配置。

2.Mode=1，active-backup

主備容錯。數據全部走第一個口，壞掉后才走第二個口，然后是第三個。端口使用效率只有1/N。交換機不用配置。

3.Mode=2，balance-xor

異或容錯、負載均衡。用外界請求的mac地址與某個網卡運算，連接建立后數據從第一個可用的接口收發。需要交換機支持。

4.Mode=3，broadcast

廣播容錯。數據包從所有網卡都發送出去，雖然端口利用率100%，但對服務器來說只有一份數據發出去，流量利用率1/N。

5.Mode=4，802.3ad

使用IEEE 802.3ad動態鏈路聚合協議。交換機同樣需要啟用802.3ad協議。

6.Mode=5，balance-tlb

基于傳輸負載均衡TLB的容錯。發送的包根據各口的負載選擇，接收的包使用對方傳輸進來的口，如果這個口傳輸失敗，則另外一個網口通過接管故障網口的MAC來接收數據。此模式需要內核能識別的本地地址，故而不能位于橋接虛擬機之后。

7.Mode=6，balance-alb

自適應負載均衡ALB的容錯，基于IPV4流量的收發負載均衡。其中接收數據的負載均衡通過ARP協商處理。同樣不能位于橋接之后。

bonding腳本設計

腳本采用#!/bin/bash作為執行引擎。用于將服務器eth0-3或em1-4綁定到一起。

第一步：

#初始化

第二步：

#判斷服務器是eth0-3命名還是em1-4命名

第三步:

#然后設置4個網卡

第四步:

#復制模板到對應的網卡，用cat防止cp被alias綁定-i參數

第五步:

#設置聚合模板

第六步：

#用mode=4，交換機需要同樣開啟lacp active 802.3ad聚合

第七步:

#重啟網絡

第八步：

#刪除此shell腳本本身

上述腳本的完整代碼，我已經開源公布至github.com/leniy平臺

安全運行方式

第一，選擇空閑的交換機端口并shutdown掉，然后用這個網口連接服務器新網卡

第二，交換機開啟lacp none模式，即普通的聚合，默認很據目的mac和來源mac的異或運算選擇端口，但由于新加的端口屏蔽掉了，數據全部走之前在用的網口，網絡不會斷。

第三，服務器執行腳本后網卡聚合完成，采用802.3ad模式。對于交換機來說，此時交換機為普通聚合模式，會忽略802.3ad協議包直接接收數據，同時由于另外一個網口已經關閉了，所以不會出現環路或mac沖突等故障。此時網絡只在腳本執行的一瞬間閃斷一次。

第四，然后交換機開啟lacp active模 式， 即802.3ad，與服務器相同。此時新加端口shutdown數據全部走舊網卡。然后登錄交換機no shutdown對應的端口，則新數據包自動開始負載均衡。

業務中斷時間測試

上述 1、2、4 步驟網絡不中斷，第3步網絡閃斷，聚合過程中ssh連接一直正常，可以證明網絡沒有長時間中斷。同時經過10次專門的測試，ping沒有發現網絡有中斷的情況。

因為ping間隔約為1s，且連續10次測試都沒有遇到閃斷，則我們可以認為網絡閃斷時間遠遠少于1秒。且本服務器用于流媒體推流，視頻UDP切片長于1秒，則可以認為服務未斷一直正常提供服務。

結語

其實linux網卡聚合非常方便，熟悉了七種模式后直接手動輸入代碼即可，不熟悉的話修改別人的代碼挨個嘗試也行。但很多人仍不會或不敢配置，最關鍵的原因在于遠程調試時錯任何一步，網絡就斷了，開車去現場至少耗時半天才能恢復。因此一個完善的腳本就顯得尤為重要。