4節(jié)點主機組成的vSAN集群,從舊vCenter關聯(lián)到新版本vCenter下,順利添加了3個后,剩下1個節(jié)點主機因為其他緊急事情耽誤了差不多半天時間才添加進來。添加后,一條“主機位于VirtualSAN集群中,但尚未啟用VirtualSAN”的警告消息立即蹦了出來(如圖 1)。
圖1 尚未啟用vSAN告警
圖2 vSAN進群通信問題警告
第一感覺就是vSAN集群的配置信息錯亂了,因為4個節(jié)點還關聯(lián)在舊vCenter中未清除,新vCenter中又只有3個節(jié)點在一起,不一致的配置信息保持了太久時間,完全就是不嫌事多還要給自己挖坑。問題出來了還是要解決,如果拖更久,則可能影響后臺副本的同步也出現(xiàn)錯亂。
首先將該主機置于維護模式,萬幸此時虛機還能漂到其他節(jié)點主機,確認虛機都漂走且運行正常后,對該主機進行重啟。
本以為重啟完后就恢復正常,沒想到又換了一條警告信息“主機無法與已啟用VirtualSAN的集群中的其他一個或多個節(jié)點進行通信”(如圖2)。
比較前后不一樣的警告,感覺是重啟后已經承認在集群中了,但還是與其他節(jié)點主機孤立了。立即檢查了主機上VSAN相關的vmk配置,都還在,也沒有錯誤,但為什么說無法通信呢?眼下也只有進命令行看看主機在集群中的狀態(tài)了。
可見,主機是成功加入了vSAN集群,并且用命令再次加入進群也會提示已在集群且啟用了vSAN。
無奈,只得求助于網絡搜索,原來這可能是一個Bug。正常情況下,一旦主機恢復通信,此消息便會自動清除,而現(xiàn)在節(jié)點經過重新引導并重新加入群集后,消息并未自動清除。繼續(xù)查看了其他vVSAN相關指示器,均報告vSAN網絡運行正常,因此,此問題可能是個表面問題。重新啟動ESXi主機節(jié)點上的VPXA(vCenter Server)管理代理就可以清除。
小結:vSAN自身就是一個集群方式運行的分布式文件系統(tǒng),與主機的HA集群有著復雜的聯(lián)系。vSAN節(jié)點的健康狀況也直接影響著存儲在其中的文件,在日常巡檢中要保持較高的警惕。
雖然vSAN經過很多嚴苛生產環(huán)境的實踐,是非常可靠的,但并非每一個場景都能與最佳實踐做到一致的部署,也未必達到高標準的運維水平。因此,為了應對vSAN發(fā)生意外導致不可逆的損壞,還要通過VDPA等備份手段將重要的虛機備份到vSAN之外的存儲中,根據(jù)業(yè)務的特點設置不同頻率的增量備份,才能高枕無憂。