恢復誤刪除的vSAN集群

事件發生

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

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

緊急處置

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

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

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

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

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

圖1 檢查vSAN網絡狀態

尋求幫助

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

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

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

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

工程師通過命令esxcli vsan cluster unicastagent list繼續檢查vSAN網絡，有了新的發現，如圖1所示。

第一個異常表現為每個主機顯示的列表數量不一，正常情況下應該每個NodeUuid顯示兩行，一行 IPv4，一行IPv6，每個主機顯示其余5個主機共10行列表，此時卻多寡不一，每個主機顯示的數量都不同；第二個異常表現為Iface名稱都未顯示，正常情況應該顯示vSAN網絡的vmk名稱。有了這一線索，恢復的希望越來越強烈。

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

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

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

圖2 vSAN單播列表

圖3 命令行添加vSAN單播網絡配置腳本

圖4 vSAN集群網絡狀態

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

回顧分析

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

正確的遷移方法

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

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

圖5 更新ESXi配置確認對話框

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

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

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

確認后，后臺自動更新vSAN配置，隨后該警告消失。關閉每個主機SSH服務，主機和集群所有警告信息都消失，遷移動作順利完成。

經驗總結

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

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