主機在vSAN中“迷失”

4節點主機組成的vSAN集群，從舊vCenter關聯到新版本vCenter下，順利添加了3個后，剩下1個節點主機因為其他緊急事情耽誤了差不多半天時間才添加進來。添加后，一條“主機位于VirtualSAN集群中，但尚未啟用VirtualSAN”的警告消息立即蹦了出來（如圖 1）。

圖1 尚未啟用vSAN告警

圖2 vSAN進群通信問題警告

第一感覺就是vSAN集群的配置信息錯亂了，因為4個節點還關聯在舊vCenter中未清除，新vCenter中又只有3個節點在一起，不一致的配置信息保持了太久時間，完全就是不嫌事多還要給自己挖坑。問題出來了還是要解決，如果拖更久，則可能影響后臺副本的同步也出現錯亂。

首先將該主機置于維護模式，萬幸此時虛機還能漂到其他節點主機，確認虛機都漂走且運行正常后，對該主機進行重啟。

本以為重啟完后就恢復正常，沒想到又換了一條警告信息“主機無法與已啟用VirtualSAN的集群中的其他一個或多個節點進行通信”（如圖2）。

比較前后不一樣的警告，感覺是重啟后已經承認在集群中了，但還是與其他節點主機孤立了。立即檢查了主機上VSAN相關的vmk配置，都還在，也沒有錯誤，但為什么說無法通信呢？眼下也只有進命令行看看主機在集群中的狀態了。

可見，主機是成功加入了vSAN集群，并且用命令再次加入進群也會提示已在集群且啟用了vSAN。

無奈，只得求助于網絡搜索，原來這可能是一個Bug。正常情況下，一旦主機恢復通信，此消息便會自動清除，而現在節點經過重新引導并重新加入群集后，消息并未自動清除。繼續查看了其他vVSAN相關指示器，均報告vSAN網絡運行正常，因此，此問題可能是個表面問題。重新啟動ESXi主機節點上的VPXA(vCenter Server)管理代理就可以清除。

小結：vSAN自身就是一個集群方式運行的分布式文件系統，與主機的HA集群有著復雜的聯系。vSAN節點的健康狀況也直接影響著存儲在其中的文件，在日常巡檢中要保持較高的警惕。

雖然vSAN經過很多嚴苛生產環境的實踐，是非常可靠的，但并非每一個場景都能與最佳實踐做到一致的部署，也未必達到高標準的運維水平。因此，為了應對vSAN發生意外導致不可逆的損壞，還要通過VDPA等備份手段將重要的虛機備份到vSAN之外的存儲中，根據業務的特點設置不同頻率的增量備份，才能高枕無憂。