事件發(fā)生

筆者單位新部署了PSC（Platform S e r v i c e s Controller）架構(gòu) 的vCenter，原計劃將一組由6臺主機(jī)構(gòu)成的vSAN集群，變更到新vCenter，按照過去的經(jīng)驗，只需要確保取消了vDS和存儲策略，或先創(chuàng)建好一致的配置，就可以直接在新vCenter下，建 好 vSAN集群，逐個添加主機(jī)即可順利完成。然而，墨菲定律總是如影隨形，我竟然還沒在新vCenter下創(chuàng)建集群，也沒有添加主機(jī)，就把舊vCenter上的vSAN集群刪除了，這一切的發(fā)生是那么的鬼使神差，一點猶豫都沒有的 點下了確定。

看到集群就這么從vCenter中消失了，腦子忽然驚醒過來，然而已不可挽回，同時，立即感受到，集群中的虛機(jī)失去了響應(yīng)，表現(xiàn)為不可操作，他們的網(wǎng)絡(luò)并沒斷，虛機(jī)狀態(tài)也是開啟，但所有服務(wù)都不可用，有如石化了一般。

緊急處置

遇到突發(fā)情況，大腦的運轉(zhuǎn)也提了速，立馬浮現(xiàn)出兩個處置辦法。第一是在原vCenter上創(chuàng)建同名集群，逐個添加主機(jī)進(jìn)行恢復(fù)；第二是在新vCenter上創(chuàng)建同名集群，逐個添加主機(jī)進(jìn)行恢復(fù)。兩者相比較，后者可以一步到位實現(xiàn)VC變更計劃，但不能確定其他的潛在影響。權(quán)衡之下，還是在原VC上進(jìn)行恢復(fù)，待穩(wěn)定后再考慮變更。

立即在原VC創(chuàng)建同名集群，開啟vSAN功能，然后直接在集群中添加主機(jī)，待6臺主機(jī)全部添加完畢，觀察虛機(jī)都保持之前的電源狀態(tài)，但虛機(jī)依然不可操作，檢查集群和主機(jī)的告警信息，發(fā)現(xiàn)6臺主機(jī)，都共同顯示一條警告：主機(jī)無法與已啟用vSAN的群集中的所有其他節(jié)點進(jìn)行通信。

看到這條告警，情緒上還是保持樂觀和淡定的，因為這個告警信息在以前的運維中也遇到過，但心里也隱約有不詳?shù)念A(yù)感。

根據(jù)曾經(jīng)的處理步驟，登錄每個主機(jī)的命令行，執(zhí) 行/etc/init.d/vpxa restart對主機(jī)的通信管理服務(wù)進(jìn)行重啟，該服務(wù)是vCenter和ESXi之間通信管理。執(zhí)行完畢后耐心等待5分鐘以上，所有提示都沒有消失。試著重啟一個狀態(tài)為已開啟的虛機(jī)，虛機(jī)立馬變成inaccessible不可用的狀態(tài)，和前面虛機(jī)不可操作的狀態(tài)相印證，典型的存儲不可用導(dǎo)致的虛機(jī)異常。這種情況下，只能登錄命令行去查看進(jìn)一步狀態(tài)。

在每個主機(jī)執(zhí)行命令esxcli vsan cluster get查看集群狀態(tài)信息，每個主機(jī)都有相同的Sub-Cluster UUID，說明所有主機(jī)都在同一個集群里，但是在Sub-Cluster Member Count信息中，卻是僅有2個主機(jī)顯示為2，其余主機(jī)均顯示為1，說明6個主機(jī)看起來在一個集群里，實際內(nèi)在卻是分裂的。對于這種分裂，準(zhǔn)確找到原因再處置更為妥當(dāng)，否則容易帶來存儲數(shù)據(jù)的丟失。

圖1 檢查vSAN網(wǎng)絡(luò)狀態(tài)

尋求幫助

聯(lián)系到原廠工程師尋求幫助，原廠工程師對刪除集群的步驟和恢復(fù)集群的操作與我反復(fù)確認(rèn)了三遍，我能猜到，當(dāng)他聽到我自己主動刪除集群時，內(nèi)心一定是波瀾的。接下來確認(rèn)ESXi的版本號是7388607，該版本可以稱作ESXi6.5u1版，也可以稱作vSAN6.6版。

首先排查的是vSAN網(wǎng)絡(luò)，用vmkping逐個Ping每個vSAN的vmk地址，這些IP都是通的。接著將一個主機(jī)置為維護(hù)模式，并設(shè)置不撤出數(shù)據(jù)，不要將關(guān)閉電源和掛起的虛擬機(jī)移動到集群中的其他主機(jī)上，然后重啟該主機(jī)，退出維護(hù)模式，觀察許久，該主機(jī)仍保持相同的警告。

通過對原廠知識庫的搜索，工程師發(fā)現(xiàn)，vSAN6.6在變更vCenter時，有一個IgnoreClusterMember ListUpdates屬性，該屬性用于將vSAN集群從一個VC移至另一個VC時使用，主動關(guān)閉集群中主機(jī)對成員列表的更新，更符合操作時不可能同時對所有集群節(jié)點同時加入集群的客觀實際，從而避免逐一添加主機(jī)到集群時更新節(jié)點成員因時間差異導(dǎo)致的影響。當(dāng)前的情況與知識庫文檔的描述并不完全一致，文檔要求的是遷移之前設(shè)置每個主機(jī)節(jié)點，而此時已類似于遷移后，如果全部設(shè)置一次，但不改變當(dāng)前VC，讓節(jié)點主機(jī)都重新刷新一次更新狀態(tài)，可能會有積極的影響。

使用命令esxcfg-advcfg-s 1 /VSAN/IgnoreCluster MemberListUpdates在 所有主機(jī)命令行執(zhí)行，忽略成員更新，重新引導(dǎo)啟動VC服務(wù)器，等待一段時間后，再到每個主機(jī)節(jié)點執(zhí)行esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMember ListUpdates命令，意為不忽略集群成員更新，讓集群重新識別成員列表，不過遺憾的是并沒有什么作用。

工程師通過命令esxcli vsan cluster unicastagent list繼續(xù)檢查vSAN網(wǎng)絡(luò)，有了新的發(fā)現(xiàn)，如圖1所示。

第一個異常表現(xiàn)為每個主機(jī)顯示的列表數(shù)量不一，正常情況下應(yīng)該每個NodeUuid顯示兩行，一行 IPv4，一行IPv6，每個主機(jī)顯示其余5個主機(jī)共10行列表，此時卻多寡不一，每個主機(jī)顯示的數(shù)量都不同；第二個異常表現(xiàn)為Iface名稱都未顯示，正常情況應(yīng)該顯示vSAN網(wǎng)絡(luò)的vmk名稱。有了這一線索，恢復(fù)的希望越來越強(qiáng)烈。

通過命令，復(fù)制每個主機(jī)查到的雙棧IP信息，做成一張對照表，如圖2所示。

根據(jù)這張表，編輯制作成腳本，如圖3所示。

準(zhǔn)備好上述腳本后，將要進(jìn)行的操作是用命令esxcli vsan cluster unicastagent clear清除現(xiàn)有vSAN網(wǎng)絡(luò)配置，用命令esxcfg-vmknic-l查看清除后結(jié)果，相應(yīng)配置均已消失，再用上述腳本批量添加，注意添加時不添加本機(jī)自己的IP。添加完畢，用命令esxcli vsan cluster unicastagent list查看，前面的異常點已不存在，如圖4所示。

圖2 vSAN單播列表

圖3 命令行添加vSAN單播網(wǎng)絡(luò)配置腳本

圖4 vSAN集群網(wǎng)絡(luò)狀態(tài)

如此重復(fù)對6個主機(jī)都進(jìn)行配置，完畢后用命令esxcli vsan cluster get查看集群狀態(tài)，Sub-Cluster Member Count終于都顯示6，頓時感覺懸在頭上的巨石落地。接著去VC上查看虛機(jī)狀態(tài)，inaccessible的狀態(tài)都已消失，主機(jī)無法與已啟用vSAN的群集中的所有其他節(jié)點進(jìn)行通信的警告也消失了。重新啟動虛機(jī)，都恢復(fù)了可操作的正常狀態(tài)。

回顧分析

回顧整個過程，在尚未遷移新vCenter時主動刪除vSAN集群，同時又很快創(chuàng)建到集群中，vSAN內(nèi)部其實發(fā)生了很多措不及防的變化，有些變化甚至沒有執(zhí)行完就被新變化影響了，從而出現(xiàn)了vSAN網(wǎng)絡(luò)物理連接上雖然通，但邏輯上已不完整的情況。表面上，這些主機(jī)節(jié)點好像相互隔離了，看起來像網(wǎng)絡(luò)分區(qū)，實際情況卻是vSAN的interface name接口都沒有關(guān)聯(lián)到vmk，vSAN主機(jī)相互之間無法進(jìn)行存儲上的通信，繼而導(dǎo)致存儲不可用，存儲之上的虛機(jī)是瞬間失去了存儲I/O，既不可讀也不可寫，并不屬于存儲連接丟失，從而出現(xiàn)虛機(jī)“石化”的情況，這種情況和FC存儲連接丟失后，還可繼續(xù)只讀的情況并不相同。當(dāng)vSAN通信網(wǎng)絡(luò)配置恢復(fù)正常后，虛擬機(jī)狀態(tài)從不可用恢復(fù)正常，之前保持已開機(jī)狀態(tài)虛機(jī)并不能自動恢復(fù)，需要人工逐一重置。

正確的遷移方法

待上述恢復(fù)的環(huán)境穩(wěn)定1至2天，觀察虛機(jī)運行和業(yè)務(wù)都正常和穩(wěn)定，還得繼續(xù)完成變更VC的動作。首先在新的VC上創(chuàng)建好vSAN集群，名稱最好和之前的一樣，并對集群開啟vSAN功能，接著SSH登錄每個主機(jī)節(jié)點，執(zhí)行命令esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMember ListUpdates將每個主機(jī)忽略成員更新，然后在新VC的集群中逐一添加主機(jī)。

全部添加完畢后，逐個查看主機(jī)摘要，在第一個添加的主機(jī)上，竟然還有警告信息：“已找到另一臺參與vSAN服務(wù)的主機(jī)，但這臺主機(jī)不是該主機(jī)的vCenter集群的成員”。立即回到舊VC查看，發(fā)現(xiàn)有4個節(jié)點處于not responding狀態(tài)，還有2個節(jié)點活著，并且活著的2個主機(jī)節(jié)點承載的虛機(jī)，也沒有出現(xiàn)在新VC中。整個人感覺頓時又不好了。

圖5 更新ESXi配置確認(rèn)對話框

正在考慮如何搜索和處理眼下的狀況，舊VC自動進(jìn)行了刷新，6個節(jié)點已經(jīng)全都顯示not responding狀態(tài)了，再去新VC中查看，之前的警告也隨之消失，6個主機(jī)節(jié)點除了開啟SSH的警告外，都表現(xiàn)正常。原來只是一場虛驚，沒有給vSAN足夠的時間完成后臺同步，待集群內(nèi)部協(xié)商同步好了所有狀態(tài)，也就恢復(fù)了正常。最后，回到每個主機(jī)的SSH會話，執(zhí)行命令esxcfgadvcfg -s 0 /VSAN/IgnoreClusterMember ListUpdate不再忽略成員更新。

繼續(xù)等待一段時間，vSAN自動進(jìn)行了運行狀況檢查，顯示“vCenter狀態(tài)具有權(quán)威性”測試失敗，給的建議是：“如果已替換vCenter Server/已從備份恢復(fù) vCenter Server，并且vCenter Server中的當(dāng)前主機(jī)列表正確，那么請執(zhí)行‘更新ESXi配置‘操作”。看來這也是新版vSAN的特性，對于遷移變更VC有了更全面的保障。

根據(jù)提示點擊“更新ESXi配置”按鈕，彈出確認(rèn)對話框，如圖5所示。

確認(rèn)后，后臺自動更新vSAN配置，隨后該警告消失。關(guān)閉每個主機(jī)SSH服務(wù)，主機(jī)和集群所有警告信息都消失，遷移動作順利完成。

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

相信很多讀者能夠通過此文，解答了直接刪除vSAN集群后果會發(fā)生什么這個好奇心理。本人也久久無法忘記原廠工程師聽到我說自己就這么把生產(chǎn)環(huán)境的vSAN集群刪除后，那種不可思議的驚詫語氣。對于這一次誤刪除事故，某種程度上似乎是是禍躲不過的，一方面是只有親自錯過，才會印象更深刻；另一方面也正是因為這些“失誤”，才千錘百煉了技術(shù)上的淡定。

在vSAN 6.6的變化上，vSAN網(wǎng)絡(luò)不再使用多播multicast，而是開始使用單播unicast來簡化vSAN群集的網(wǎng)絡(luò)要求，升級或安裝vSAN 6.6并完成通過磁盤升級之后，群集會自動切換到單播，這些細(xì)節(jié)上的變化，也使得vSAN管理和運行中越來越可控。