vSphere虛擬機網絡時斷時續

■ 唐山工業職業技術學院 黃驍 孫達明 徐世英

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

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

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

故障現象及排查經歷

筆者到達現場后，逐臺檢查了虛擬機的網絡配置，沒有發現問題。

圖1 網絡拓撲圖

圖2 網絡故障說明示意圖

用ping命令檢查虛擬機之間網絡是否暢通，發現虛擬機之間的網絡有的能ping通，有的不能ping通。比較奇怪的是，有的虛擬機和其他虛擬機都不能ping通，有的虛擬機和部分虛擬機能ping通，和部分虛擬機不能ping通。

為了更直觀地描述故障現象，筆者畫出如圖2所示示意圖，用來描述這個奇怪的網絡故障。

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

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

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

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

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

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

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

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

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

4.出現“虛擬機設置”對話框后，在“硬件”清單中選擇“網絡適配器”，在對話框右側單擊“高級”按鈕（如圖 3）。

5.出現“網絡適配器高級設置”對話框后，單擊“生成”按鈕即可為故障虛擬機生成一個新的MAC地址（如圖 4）。

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

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

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

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

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

鏈路聚合和vSphere負載平衡

要解決前面所描述的網絡故障，首先應了解鏈路聚合和vSphere負載平衡。

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

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

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

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

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

基于源虛擬端口的路由：ESXi主機上運行的每個虛擬機在虛擬交換機上都有一個關聯的虛擬端口ID。基于源虛擬端口的路由策略中，虛擬交換機使用虛擬機端口ID和網卡組中的上行鏈路數目來計算虛擬機的上行鏈路，虛擬交換機為虛擬機選擇上行鏈路后，只要該虛擬機在相同的端口上運行，就會始終通過此虛擬機的同一上行鏈路轉發流量。

故障分析

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

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

排除故障

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

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

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

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

圖5 選擇“編輯設置”

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

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

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

經過一段時間運行，沒有出現前面所描述的虛擬機網絡時斷時續故障，說明故障已徹底排除。

案例說明

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