■ 唐山工業(yè)職業(yè)技術(shù)學(xué)院 黃驍 孫達明 徐世英

編者按： 筆者某客戶在部署教育資源公共服務(wù)平臺遷移到新服務(wù)器時，總是出現(xiàn)無法訪問的現(xiàn)象，對此，筆者進行了一系列故障分析和排查，本文正是對此次故障排查進行的總結(jié)，其中部分內(nèi)容進行了簡化和模糊處理，希望能對讀者有所幫助。

某單位新上了一組服務(wù)器，服務(wù)器虛擬化使用的軟件是VMware vSphere是6.7，該單位將筆者為其部署的教育資源公共服務(wù)平臺遷移到了新服務(wù)器后，該平臺總出現(xiàn)無法訪問的現(xiàn)象，于是該單位平臺運維人員找到筆者，讓筆者幫忙解決這個問題。

為了增加同時在線用戶數(shù)量，該單位的教育資源公共服務(wù)平臺使用了34臺虛擬機，虛擬機上安裝的服務(wù)器操作系統(tǒng)既有Windows系統(tǒng)，也有Linux系統(tǒng)，34臺虛擬機獨立組網(wǎng)，這些虛擬機使用的vShere網(wǎng)絡(luò)沒有使用默認的 “VM Network”網(wǎng)絡(luò)，而是單獨添加的“InfoPM” 網(wǎng)絡(luò)，其網(wǎng)絡(luò)拓撲如圖1所示。

故障現(xiàn)象及排查經(jīng)歷

筆者到達現(xiàn)場后，逐臺檢查了虛擬機的網(wǎng)絡(luò)配置，沒有發(fā)現(xiàn)問題。

圖1 網(wǎng)絡(luò)拓撲圖

圖2 網(wǎng)絡(luò)故障說明示意圖

用ping命令檢查虛擬機之間網(wǎng)絡(luò)是否暢通，發(fā)現(xiàn)虛擬機之間的網(wǎng)絡(luò)有的能ping通，有的不能ping通。比較奇怪的是，有的虛擬機和其他虛擬機都不能ping通，有的虛擬機和部分虛擬機能ping通，和部分虛擬機不能ping通。

為了更直觀地描述故障現(xiàn)象，筆者畫出如圖2所示示意圖，用來描述這個奇怪的網(wǎng)絡(luò)故障。

假設(shè)有 A、B、C、D、E五臺虛擬機，在A上不能ping通其他四臺虛擬機；在E上能 ping通 C、D，但不能ping通A、B；本次遇到的故障奇怪的地方就是，B、E之間不能通信，但 E、D 之間、B、D之間卻能通信。

除此之外，還有更離奇的現(xiàn)象，在E上不能ping通B，在B上卻能ping通E。在B上ping通E以后，反過來，在E上重新ping B，此時可以ping通B。

面對如此復(fù)雜、奇怪的網(wǎng)絡(luò)故障，筆者就從和其他虛擬機都不能通信的虛擬機A著手。按照慣例，筆者首先懷疑虛擬機A可能和其他計算機存在IP地址沖突，于是筆者為其更換了IP地址，在用ping命令做通信測試，故障依舊，仍不能和其他虛擬機通信。

難道是計算機名重復(fù)引起的網(wǎng)絡(luò)故障？為虛擬機A更換計算機名后，在用Ping命令做通信測試，測試結(jié)果是，它能和虛擬機E、D、C通信，不能和B通信。

虛擬機A能和其他部分虛擬機通信，是虛擬機A和其他虛擬機MAC地址重復(fù)了？還是克隆虛擬機或從模板部署虛擬機時，新虛擬機仍用了原來的MAC地址?筆者檢查了各虛擬機的MAC地址，沒有發(fā)現(xiàn)MAC地址沖突。盡管如此，筆者還是想更換故障虛擬機的MAC地址。為了方便修改虛擬機MAC地址，筆者決定用VMware Workstation連接到vCenter Server。具體操作如下：

1.打開VMware Workstation后，依次單擊“文件”菜單→“連接服務(wù)器”。

2.出現(xiàn)“連接服務(wù)器”對話框后，在“服務(wù)器名稱”文本框輸入vCenter Server的名稱或IP地址，在用戶名和密碼文本框中輸入登錄vCenter Server所需的用戶名和密碼。

圖3 單擊“高級”按鈕進行配置

3.用VMware Workstation登錄到vCenter Server后，找到故障虛擬機，右擊故障虛擬機，在右鍵菜單中選擇“設(shè)置”。

4.出現(xiàn)“虛擬機設(shè)置”對話框后，在“硬件”清單中選擇“網(wǎng)絡(luò)適配器”，在對話框右側(cè)單擊“高級”按鈕（如圖 3）。

5.出現(xiàn)“網(wǎng)絡(luò)適配器高級設(shè)置”對話框后，單擊“生成”按鈕即可為故障虛擬機生成一個新的MAC地址（如圖 4）。

更換虛擬機A的MAC地址后，用ping命令做通信測試，發(fā)現(xiàn)這個方法很有效，基本上可以ping通其他虛擬機了。

以此類推，筆者將凡有網(wǎng)絡(luò)故障的虛擬機都重新生成了一個新MAC地址，經(jīng)過一段時間努力，終于讓該單位的教育資源公共服務(wù)平臺下所有虛擬機之間都能互相通信了，該單位的教育資源公共服務(wù)平臺也能正常訪問了。

圖4 為故障虛擬機生成新的MAC地址

可是好景不長，不到一天，客戶單位的這名運維人員又找到筆者，該單位的教育資源公共服務(wù)平臺又不能訪問了。筆者再次檢查了虛擬機網(wǎng)絡(luò)，發(fā)現(xiàn)虛擬機之間確實有不能通信的現(xiàn)象，問題出現(xiàn)在哪里呢？原來平臺能正常運行，現(xiàn)在只是將平臺遷移到新服務(wù)器上，難道是ESXi主機網(wǎng)絡(luò)問題。

筆者檢查了新服務(wù)器所連接的網(wǎng)絡(luò)，通過檢查發(fā)現(xiàn)，該單位為實現(xiàn)網(wǎng)絡(luò)冗余和負載平衡，在物理交換機上啟用了鏈路聚合。而vSphere標準交換機和vSphere Distributed Switch上的默認負載平衡策略是“基于源虛擬端口的路由”，看來問題就出現(xiàn)在這里。

鏈路聚合和vSphere負載平衡

要解決前面所描述的網(wǎng)絡(luò)故障，首先應(yīng)了解鏈路聚合和vSphere負載平衡。

鏈路聚合是將多個物理端口匯聚在一起，形成一個邏輯端口，各端口分擔(dān)出/入口流量，當(dāng)交換機檢測到其中一個成員端口的鏈路發(fā)生故障時，就停止在此端口上發(fā)送封包，并根據(jù)負荷分擔(dān)策略在剩下的鏈路中重新計算報文的發(fā)送端口，故障端口恢復(fù)后再次擔(dān)任收發(fā)端口。

可見，鏈路聚合既可以達到負載平衡的目的，還可以實現(xiàn)鏈路冗余。鏈路聚合的應(yīng)用場景一般是一個IP到多個IP連接，或者是多個IP到多個IP的連接。

vShere提供的負載平衡策略主要有“基于IP哈希的路由”“基于源MAC哈希的路由”“基于源虛擬端口的路由”“使用明確故障切換順序”等四種策略。

基于IP哈希的路由：虛擬交換機可根據(jù)每個數(shù)據(jù)包的源和目標IP地址選擇虛擬機的上行鏈路。在基于IP哈希的路由策略中，任何虛擬機都可以根據(jù)源和目標IP地址，使用網(wǎng)卡組中的任何一條上行鏈路。如果虛擬機在包含大量獨立虛擬機的環(huán)境中運行，則IP哈希算法可在組中的網(wǎng)卡之間均勻地分布流量。當(dāng)虛擬機與多個目標IP地址通信時，虛擬交換機可為每個目標IP生成不同的哈希。因此，數(shù)據(jù)包可以使用虛擬交換機上的不同上行鏈路，從而實現(xiàn)更高的吞吐量。如果環(huán)境中包含的IP地址較少，則虛擬交換機可能會始終通過組中的一條上行鏈路傳遞流量。

基于源MAC哈希的路由：虛擬交換機可以基于虛擬機MAC地址選擇虛擬機的上行鏈路。在基于源MAC哈希的路由負載平衡策略中，虛擬交換機使用虛擬機MAC地址和網(wǎng)卡組中的上行鏈路數(shù)目來計算虛擬機的上行鏈路。

基于源虛擬端口的路由：ESXi主機上運行的每個虛擬機在虛擬交換機上都有一個關(guān)聯(lián)的虛擬端口ID?；谠刺摂M端口的路由策略中，虛擬交換機使用虛擬機端口ID和網(wǎng)卡組中的上行鏈路數(shù)目來計算虛擬機的上行鏈路，虛擬交換機為虛擬機選擇上行鏈路后，只要該虛擬機在相同的端口上運行，就會始終通過此虛擬機的同一上行鏈路轉(zhuǎn)發(fā)流量。

故障分析

前面所描述的網(wǎng)絡(luò)故障就是因為在物理交換機上做了鏈路聚合，而鏈路聚合的應(yīng)用場景應(yīng)該是一個IP到多個IP連接，或者是多個IP到多個IP的連接。

在此場景下，應(yīng)該選擇vShere提供的“基于 IP 哈希的路由”負載平衡策略，而不是vShere默認的“基于源虛擬端口的路由”負載平衡策略。因“基于源虛擬端口的路由”負載平衡策略和物理交換機上所做的鏈路聚合不匹配，在此種情況下，鏈路選擇很容易失敗，虛擬機網(wǎng)絡(luò)也就會出現(xiàn)時斷時續(xù)故障，其實，在圖2所描述的奇怪的網(wǎng)絡(luò)故障，就是因為網(wǎng)絡(luò)時斷時續(xù)引起。

排除故障

為降低發(fā)生網(wǎng)絡(luò)連接中斷的可能性，需要正確配置ESXi主機的vShere負載平衡策略。在本例中，客戶單位連接ESXi主機的物理交換機啟用了鏈路聚合，就應(yīng)該將虛擬機所連接的網(wǎng)絡(luò)“負載平衡”設(shè)置為“基于IP 哈希的路由”，具體方法如下：

登 錄vCenter Server后，選擇一臺主機，在頁面右側(cè)選擇“配置”選項卡，在設(shè)備清單中選擇“網(wǎng)絡(luò)”→“交換機”，在虛擬交換機下拉列表中選擇虛擬機網(wǎng)絡(luò)所連交換機，在本例中，虛擬機網(wǎng)絡(luò)所連交換機為“標準交換機：vSwitch0”。

如果所選虛擬交換機下面有多個網(wǎng)絡(luò)，此時應(yīng)選擇故障虛擬機所在網(wǎng)絡(luò)，在本例中，該單位的教育資源公共服務(wù)平臺所在網(wǎng)絡(luò)是默認的“VM Network”,單擊“VM Network”網(wǎng)絡(luò)右側(cè)的“…”按鈕，在彈出菜單中選擇“編輯設(shè)置”（如圖5）。

出現(xiàn)“VM Network編輯設(shè)置”對話框后，單擊左側(cè)“綁定和故障切換”，勾選“負載平衡”右側(cè)的“替代”復(fù)選框，在其右側(cè)的下拉列表框中選擇“基于IP哈希的路由”（如圖6）。

圖5 選擇“編輯設(shè)置”

圖6 選擇“基于IP哈希的路由”

需要說明的是，前面盡管通過配置ESXi主機網(wǎng)絡(luò)“綁定和故障切換”，將負載平衡策略設(shè)置為“基于IP哈希的路由”。但這個配置不會傳播到管理網(wǎng)絡(luò)端口組。因此還需要按同樣的方法配置管理網(wǎng)絡(luò)“Management Network”，將管理網(wǎng)絡(luò)的負載平衡策略也設(shè)置為“基于IP哈希的路由”。

以此類推，筆者將新部署的幾臺主機ESXi主機的“綁定和故障切換”策略都從默認的“基于源虛擬端口的路由”更改為“基于IP哈希的路由”后，該單位教育資源公共服務(wù)平臺下虛擬機相互之間全都能通信了，平臺也能訪問了。

經(jīng)過一段時間運行，沒有出現(xiàn)前面所描述的虛擬機網(wǎng)絡(luò)時斷時續(xù)故障，說明故障已徹底排除。

案例說明

本案例是真實案例，故障排查過程也是真實過程，為了維護客戶單位信息網(wǎng)絡(luò)安全，筆者對上述文字和圖片做了技術(shù)處理，如有雷同，純屬巧合。