分布式虛擬交換宕了

故障緣起

筆者一直以來都對虛擬化環(huán)境中的“暗流量”抱有興趣，很想真切觀察同一個VLAN內(nèi)虛機之間通信是否真的不被送到uplink網(wǎng)卡的物理交換機，也很想看看管理流量的規(guī)律，以及vMotion流量的峰值。帶著這些好奇，筆者配置了ntopng，計劃使用VDS（Virtual Distribution Switch）所自帶的端口鏡像功能將流量轉(zhuǎn)發(fā)到ntopng進(jìn)行觀察。

故障現(xiàn)象

配置過程并不順利，不管是單個或多個端口流量鏡像到ntopng網(wǎng)卡，還是VLAN流量鏡像到ntopng網(wǎng)卡，在ntopng上都不能觀察到流量的明顯增加，同時ntopng主機上監(jiān)控網(wǎng)卡流量也未能看到明顯的變化，讓我分不清到底是ntopng收不到流量還是VDS未轉(zhuǎn)發(fā)流量。

在不斷的反復(fù)調(diào)試中，我見端口和VLAN都不能抓取流量，可被鏡像的對象還有vmk0可選擇，于是，未經(jīng)縝密的思考，就將集群中8個ESXi的vmk0全都鏡像到了ntopng的網(wǎng)卡上，在點擊確定的一瞬間，ntopng及其主機馬上觀察到了明顯的流量，心中頓時一喜，然而接下去的幾秒鐘中里，不安感立即超過了欣喜，因為流量大得驚人，從第一眼看到的100多Mbps，到短短5秒內(nèi)，流量超過900Mbps，腦海里還想著整個群集的流量不可能這么大的同時，虛機也隨之失去了響應(yīng)，迷茫了幾秒鐘后，vCenter的連接也丟失了，我忽然意識到，這下犯了大錯誤了，整個虛擬化環(huán)境都受到影響了。

理清處置思路

vCenter的忽然中斷從來就不是好事。在當(dāng)前情況下，下意識間去做的，就是檢查運行在虛擬化集群中重要服務(wù)的狀態(tài)，結(jié)果是一部分服務(wù)打不開了，另一部分能打開的速度也非常慢，可謂是喜憂參半。喜的是虛機自身的狀態(tài)可以確定都還是保持開機的，也就是并未造成所有虛機集體重啟，那么只要恢復(fù)了網(wǎng)絡(luò)就能快速恢復(fù)受影響的業(yè)務(wù)；憂的是vCenter的網(wǎng)絡(luò)也已經(jīng)不可連接，8個ESXi中有7個都無法連接，加之集群所用的VDS配置并未事先備份，網(wǎng)絡(luò)受損的程度及恢復(fù)時間仍難以估量。

根據(jù)對當(dāng)前情況的初步判定，首先確定處置的第一原則，要在保持所有虛機不異常重啟的狀態(tài)下去嘗試恢復(fù)網(wǎng)絡(luò)，因為只要不強制關(guān)閉或重啟任一虛機，一旦網(wǎng)絡(luò)可用，業(yè)務(wù)就能最短時間內(nèi)恢復(fù)，且不會造成虛機內(nèi)文件損壞或服務(wù)非正常停止等異常，若造成虛機內(nèi)的異常，可能會比分布式虛擬網(wǎng)絡(luò)的恢復(fù)更麻煩。

恢復(fù)虛機網(wǎng)絡(luò)的嘗試

登錄還存活的惟一一個ESXi，查看其狀態(tài)沒有明顯的異常，其上虛機的響應(yīng)速度也正常，除此之外也找不到其他線索來定位網(wǎng)絡(luò)問題所在。

從無法登錄的7個ESXi中隨機挑選一個ESXi，在服務(wù)器控制臺登錄SHELL，使用命令vim-cmd vmsvc/getallvms查看虛機清單列表，然而卻得到“503 service unavailable”的提示。使用命令uptime查看平均負(fù)載，可以看到load average非常高，比平時虛機高峰負(fù)載觀察到的平均負(fù)載還要高出數(shù)倍。又挑選了另2個ESXi進(jìn)行同樣的觀察也是相同的現(xiàn)象。基于此分析，出問題的7個ESXi一定都跟超大的鏡像流量是有關(guān)系的，鏡像的vmk0除了處理自身的業(yè)務(wù)流量，還會不斷疊加這些流量，從而可以印證ntopng接收到的流量是幾何倍數(shù)快速增加，故而vmk0無論多強大，都無法處理不斷疊加的鏡像包，CPU資源也會被快速疊加的流量消耗完，于是有的虛機網(wǎng)絡(luò)非常慢，有的甚至完全中斷。

那么，是否重啟ESXi的網(wǎng)絡(luò)就會恢復(fù)呢？帶著疑問，挑選了一個ESXi在SHELL下執(zhí)行了/sbin/services.sh restart命令，等待許久卻是個執(zhí)行失敗的回復(fù)。回到ESXi Console，在圖形界面下重啟Management Agents，提示成功，立即用vsphere client登錄該ESXi，以非常慢的速度登錄成功，不過又很快失去了連接。利用重啟管理網(wǎng)絡(luò)的方法嘗試了另幾個ESXi，要么很快失去了連接，要么還是網(wǎng)絡(luò)不通，惟一的收獲，是定位到了vCenter所在ESXi節(jié)點。

基于上述判斷再次梳理思路，當(dāng)前的VMkernel其實沒有別的錯誤，問題應(yīng)在vmk0保持了流量鏡像指令的執(zhí)行而無法正常響應(yīng)，如果有命令能停止vmk0的流量鏡像，網(wǎng)絡(luò)應(yīng)該是馬上可以得到恢復(fù)的。不過，經(jīng)過一番搜索努力，一方面沒能找到相關(guān)的資料，另一方面網(wǎng)絡(luò)的恢復(fù)也不能無限制地等待下去，需要果斷采取一些措施。

挑選一個ESXi主機，進(jìn)入控制臺界面，選擇Restore vDS菜單，勾選所有uplinks接口和Restore to default blocked setting，將該ESXi的VDS進(jìn)行初始化，隨即測試該ESXi上的業(yè)務(wù)訪問已經(jīng)恢復(fù)正常，這一結(jié)果讓原本焦躁的心情得以稍稍平靜，查看uptime負(fù)載，也下降到正常時極低的數(shù)值，于是又連續(xù)初始化了3個ESXi的VDS。此時，忽然想起vCenter上ESXi的狀態(tài)到底如何，查看之下，這4個初始化了VDS的ESXi在vCenter上都是警告狀態(tài)，網(wǎng)絡(luò)配置里也找不到初始化之后的分布式虛擬交換機，尤其是物理網(wǎng)卡在vSphere Client上怎么都找不到了，也就無法劃分物理網(wǎng)卡到虛擬交換機了，心中頓時涼了一半，難道這樣處置仍存在未考慮周全的地方？

為避免恢復(fù)過程造成次生破壞，同時驗證分析的網(wǎng)絡(luò)問題和實際是否相一致，決定對剩下的3個ESXi初始化為標(biāo)準(zhǔn)虛擬交換機。根據(jù)已有的知識積累，初始化為標(biāo)準(zhǔn)的vswitch會清理該ESXi上所有網(wǎng)絡(luò)的配置，初始化結(jié)束后需要登錄到ESXi上重新配置ESXi的管理和業(yè)務(wù)VLAN，并將虛機劃分到新建的VLAN中才能恢復(fù)網(wǎng)絡(luò)，同時也需要在vCenter的清單中先刪除這3個ESXi，待管理網(wǎng)絡(luò)配置后再重新添加到vCenter，步驟相對麻煩許多，但這樣恢復(fù)后是可以完全查看和管控虛擬網(wǎng)絡(luò)配置的。此時，在vCenter中可看到集群的狀態(tài)仍在警告，僅初始化VDS的ESXi也提示：“與主機上的代理交換機對應(yīng)的vSphere Distributed Switch在vCenter Server中不存在或不包含此主機”。

由此分析，僅初始化VDS應(yīng)該是系統(tǒng)生成了新的VDS和vmk0取代了原有故障，但這個新的VDS并未注冊到vCenter，故而在vCenter中不可查看和管理物理網(wǎng)卡及虛擬網(wǎng)絡(luò)，在當(dāng)前所有虛機網(wǎng)絡(luò)都已恢復(fù)的情況下，可以松一口氣，但完全恢復(fù)健康的VDS狀態(tài)仍需小心謹(jǐn)慎。

恢復(fù)分布式虛擬網(wǎng)絡(luò)

基于前面的努力，當(dāng)前環(huán)境中實際存在兩個VDS，一個是舊的，另一個則是系統(tǒng)生成但卻不可見，這兩個VDS已都不可恢復(fù)到正常健康的狀態(tài)，因此需要新建一個VDS來取代現(xiàn)有的兩個。

創(chuàng)建VDS，創(chuàng)建VLAN的端口組，遷移物理網(wǎng)卡到VDS的uplink，初始化為vSwitch的網(wǎng)絡(luò)都順利遷移成功，但初始化為VDS的ESXi仍無法找到物理網(wǎng)卡，在此情況下，4個ESXi逐一創(chuàng)建vSwitch仍會存在找不到物理網(wǎng)卡的情況，能想到的惟一解決辦法只有繼續(xù)初始化到vSwitch，這樣一來，這4個ESXi上虛機仍會面臨短時的斷網(wǎng)，所能做的只是如何縮短中斷的時間。

由于每個ESXi都有4個物理網(wǎng)卡作為uplink，重置到標(biāo)準(zhǔn)虛擬交換機后，先劃分2個物理網(wǎng)卡給VDS，保留2個網(wǎng)卡在vmk0上，這樣就可以馬上批量遷移虛機的端口組到新的VDS上，并且能夠連通業(yè)務(wù)網(wǎng)絡(luò)，只要動作熟練，每個ESXi上虛機斷網(wǎng)時間可以控制在3-5分鐘內(nèi)，待確保虛機網(wǎng)絡(luò)暢通后，再來遷移剩下的2個物理網(wǎng)卡和vmk0到VDS，既不影響在vCenter上的操作，也縮短了處理過程的斷網(wǎng)時間。

如此處理完后，每個ESXi逐一檢查網(wǎng)絡(luò)的配置和狀態(tài)，確定每個虛機都正常，逐一重啟每個ESXi，確保重啟后運行正常，且在vCenter上沒有報錯信息，然后重啟一次vCenter并確認(rèn)不再有報錯信息，分布式虛擬網(wǎng)絡(luò)和集群都恢復(fù)正常，最后再刪除舊的VDS和恢復(fù)過程產(chǎn)生的vSwitch。此時距離故障發(fā)生，已過去6小時。

經(jīng)驗總結(jié)

雖然每次都是這樣被自己“手賤”搞出事情，但也不得不承認(rèn)在這樣的經(jīng)歷中進(jìn)步得更快，對知識的理解和運用更為深刻。

首先，除了上述的主要問題，次生了兩個問題。一是vCenter里配置的虛機管理權(quán)限存在部分丟失情況，需要重新給相應(yīng)的用戶配置虛機管理的授權(quán)；二是vcops的vapp發(fā)生了解體，當(dāng)然這個直接把虛機拖回到vapp里即可。

其次，之所以在ntopng里沒看到期望的流量，原因不在VDS，而是ntopng沒有安裝收費的流量分析插件，僅安裝了免費的ntopng程序僅能查看本機網(wǎng)卡上的流量，而不能過濾轉(zhuǎn)發(fā)過來的鏡像流量，這也就導(dǎo)致了我因看不到流量而不斷調(diào)整鏡像端口引發(fā)了本次故障。

最后，對于vmk0應(yīng)引起足夠的重視，它不僅是虛擬網(wǎng)絡(luò)運行的內(nèi)核，也是物理網(wǎng)絡(luò)與虛擬網(wǎng)絡(luò)的處理核心，同時它也是軟件。本次故障的根源還是在片面的知道vmk0會擁有所有的虛機流量，簡單的把它當(dāng)作了uplink，卻忘記了轉(zhuǎn)發(fā)層也是它自身。