筆者單位新部署了PSC(Platform S e r v i c e s Controller)架構(gòu) 的vCenter,原計(jì)劃將一組由6臺(tái)主機(jī)構(gòu)成的vSAN集群,變更到新vCenter,按照過去的經(jīng)驗(yàn),只需要確保取消了vDS和存儲(chǔ)策略,或先創(chuàng)建好一致的配置,就可以直接在新vCenter下,建 好 vSAN集群,逐個(gè)添加主機(jī)即可順利完成。然而,墨菲定律總是如影隨形,我竟然還沒在新vCenter下創(chuàng)建集群,也沒有添加主機(jī),就把舊vCenter上的vSAN集群刪除了,這一切的發(fā)生是那么的鬼使神差,一點(diǎn)猶豫都沒有的 點(diǎn)下了確定。
看到集群就這么從vCenter中消失了,腦子忽然驚醒過來,然而已不可挽回,同時(shí),立即感受到,集群中的虛機(jī)失去了響應(yīng),表現(xiàn)為不可操作,他們的網(wǎng)絡(luò)并沒斷,虛機(jī)狀態(tài)也是開啟,但所有服務(wù)都不可用,有如石化了一般。
遇到突發(fā)情況,大腦的運(yùn)轉(zhuǎn)也提了速,立馬浮現(xiàn)出兩個(gè)處置辦法。第一是在原vCenter上創(chuàng)建同名集群,逐個(gè)添加主機(jī)進(jìn)行恢復(fù);第二是在新vCenter上創(chuàng)建同名集群,逐個(gè)添加主機(jī)進(jìn)行恢復(fù)。兩者相比較,后者可以一步到位實(shí)現(xiàn)VC變更計(jì)劃,但不能確定其他的潛在影響。權(quán)衡之下,還是在原VC上進(jìn)行恢復(fù),待穩(wěn)定后再考慮變更。
立即在原VC創(chuàng)建同名集群,開啟vSAN功能,然后直接在集群中添加主機(jī),待6臺(tái)主機(jī)全部添加完畢,觀察虛機(jī)都保持之前的電源狀態(tài),但虛機(jī)依然不可操作,檢查集群和主機(jī)的告警信息,發(fā)現(xiàn)6臺(tái)主機(jī),都共同顯示一條警告:主機(jī)無法與已啟用vSAN的群集中的所有其他節(jié)點(diǎn)進(jìn)行通信。
看到這條告警,情緒上還是保持樂觀和淡定的,因?yàn)檫@個(gè)告警信息在以前的運(yùn)維中也遇到過,但心里也隱約有不詳?shù)念A(yù)感。
根據(jù)曾經(jīng)的處理步驟,登錄每個(gè)主機(jī)的命令行,執(zhí) 行/etc/init.d/vpxa restart對(duì)主機(jī)的通信管理服務(wù)進(jìn)行重啟,該服務(wù)是vCenter和ESXi之間通信管理。執(zhí)行完畢后耐心等待5分鐘以上,所有提示都沒有消失。試著重啟一個(gè)狀態(tài)為已開啟的虛機(jī),虛機(jī)立馬變成inaccessible不可用的狀態(tài),和前面虛機(jī)不可操作的狀態(tài)相印證,典型的存儲(chǔ)不可用導(dǎo)致的虛機(jī)異常。這種情況下,只能登錄命令行去查看進(jìn)一步狀態(tài)。
在每個(gè)主機(jī)執(zhí)行命令esxcli vsan cluster get查看集群狀態(tài)信息,每個(gè)主機(jī)都有相同的Sub-Cluster UUID,說明所有主機(jī)都在同一個(gè)集群里,但是在Sub-Cluster Member Count信息中,卻是僅有2個(gè)主機(jī)顯示為2,其余主機(jī)均顯示為1,說明6個(gè)主機(jī)看起來在一個(gè)集群里,實(shí)際內(nèi)在卻是分裂的。對(duì)于這種分裂,準(zhǔn)確找到原因再處置更為妥當(dāng),否則容易帶來存儲(chǔ)數(shù)據(jù)的丟失。
圖1 檢查vSAN網(wǎng)絡(luò)狀態(tài)
聯(lián)系到原廠工程師尋求幫助,原廠工程師對(duì)刪除集群的步驟和恢復(fù)集群的操作與我反復(fù)確認(rèn)了三遍,我能猜到,當(dāng)他聽到我自己主動(dòng)刪除集群時(shí),內(nèi)心一定是波瀾的。接下來確認(rèn)ESXi的版本號(hào)是7388607,該版本可以稱作ESXi6.5u1版,也可以稱作vSAN6.6版。
首先排查的是vSAN網(wǎng)絡(luò),用vmkping逐個(gè)Ping每個(gè)vSAN的vmk地址,這些IP都是通的。接著將一個(gè)主機(jī)置為維護(hù)模式,并設(shè)置不撤出數(shù)據(jù),不要將關(guān)閉電源和掛起的虛擬機(jī)移動(dòng)到集群中的其他主機(jī)上,然后重啟該主機(jī),退出維護(hù)模式,觀察許久,該主機(jī)仍保持相同的警告。
通過對(duì)原廠知識(shí)庫的搜索,工程師發(fā)現(xiàn),vSAN6.6在變更vCenter時(shí),有一個(gè)IgnoreClusterMember ListUpdates屬性,該屬性用于將vSAN集群從一個(gè)VC移至另一個(gè)VC時(shí)使用,主動(dòng)關(guān)閉集群中主機(jī)對(duì)成員列表的更新,更符合操作時(shí)不可能同時(shí)對(duì)所有集群節(jié)點(diǎn)同時(shí)加入集群的客觀實(shí)際,從而避免逐一添加主機(jī)到集群時(shí)更新節(jié)點(diǎn)成員因時(shí)間差異導(dǎo)致的影響。當(dāng)前的情況與知識(shí)庫文檔的描述并不完全一致,文檔要求的是遷移之前設(shè)置每個(gè)主機(jī)節(jié)點(diǎn),而此時(shí)已類似于遷移后,如果全部設(shè)置一次,但不改變當(dāng)前VC,讓節(jié)點(diǎn)主機(jī)都重新刷新一次更新狀態(tài),可能會(huì)有積極的影響。
使用命令esxcfg-advcfg-s 1 /VSAN/IgnoreCluster MemberListUpdates在 所有主機(jī)命令行執(zhí)行,忽略成員更新,重新引導(dǎo)啟動(dòng)VC服務(wù)器,等待一段時(shí)間后,再到每個(gè)主機(jī)節(jié)點(diǎn)執(zhí)行esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMember ListUpdates命令,意為不忽略集群成員更新,讓集群重新識(shí)別成員列表,不過遺憾的是并沒有什么作用。
工程師通過命令esxcli vsan cluster unicastagent list繼續(xù)檢查vSAN網(wǎng)絡(luò),有了新的發(fā)現(xiàn),如圖1所示。
第一個(gè)異常表現(xiàn)為每個(gè)主機(jī)顯示的列表數(shù)量不一,正常情況下應(yīng)該每個(gè)NodeUuid顯示兩行,一行 IPv4,一行IPv6,每個(gè)主機(jī)顯示其余5個(gè)主機(jī)共10行列表,此時(shí)卻多寡不一,每個(gè)主機(jī)顯示的數(shù)量都不同;第二個(gè)異常表現(xiàn)為Iface名稱都未顯示,正常情況應(yīng)該顯示vSAN網(wǎng)絡(luò)的vmk名稱。有了這一線索,恢復(fù)的希望越來越強(qiáng)烈。
通過命令,復(fù)制每個(gè)主機(jī)查到的雙棧IP信息,做成一張對(duì)照表,如圖2所示。
根據(jù)這張表,編輯制作成腳本,如圖3所示。
準(zhǔn)備好上述腳本后,將要進(jìn)行的操作是用命令esxcli vsan cluster unicastagent clear清除現(xiàn)有vSAN網(wǎng)絡(luò)配置,用命令esxcfg-vmknic-l查看清除后結(jié)果,相應(yīng)配置均已消失,再用上述腳本批量添加,注意添加時(shí)不添加本機(jī)自己的IP。添加完畢,用命令esxcli vsan cluster unicastagent list查看,前面的異常點(diǎn)已不存在,如圖4所示。
圖2 vSAN單播列表
圖3 命令行添加vSAN單播網(wǎng)絡(luò)配置腳本
圖4 vSAN集群網(wǎng)絡(luò)狀態(tài)
如此重復(fù)對(duì)6個(gè)主機(jī)都進(jìn)行配置,完畢后用命令esxcli vsan cluster get查看集群狀態(tài),Sub-Cluster Member Count終于都顯示6,頓時(shí)感覺懸在頭上的巨石落地。接著去VC上查看虛機(jī)狀態(tài),inaccessible的狀態(tài)都已消失,主機(jī)無法與已啟用vSAN的群集中的所有其他節(jié)點(diǎn)進(jìn)行通信的警告也消失了。重新啟動(dòng)虛機(jī),都恢復(fù)了可操作的正常狀態(tài)。
回顧整個(gè)過程,在尚未遷移新vCenter時(shí)主動(dòng)刪除vSAN集群,同時(shí)又很快創(chuàng)建到集群中,vSAN內(nèi)部其實(shí)發(fā)生了很多措不及防的變化,有些變化甚至沒有執(zhí)行完就被新變化影響了,從而出現(xiàn)了vSAN網(wǎng)絡(luò)物理連接上雖然通,但邏輯上已不完整的情況。表面上,這些主機(jī)節(jié)點(diǎn)好像相互隔離了,看起來像網(wǎng)絡(luò)分區(qū),實(shí)際情況卻是vSAN的interface name接口都沒有關(guān)聯(lián)到vmk,vSAN主機(jī)相互之間無法進(jìn)行存儲(chǔ)上的通信,繼而導(dǎo)致存儲(chǔ)不可用,存儲(chǔ)之上的虛機(jī)是瞬間失去了存儲(chǔ)I/O,既不可讀也不可寫,并不屬于存儲(chǔ)連接丟失,從而出現(xiàn)虛機(jī)“石化”的情況,這種情況和FC存儲(chǔ)連接丟失后,還可繼續(xù)只讀的情況并不相同。當(dāng)vSAN通信網(wǎng)絡(luò)配置恢復(fù)正常后,虛擬機(jī)狀態(tài)從不可用恢復(fù)正常,之前保持已開機(jī)狀態(tài)虛機(jī)并不能自動(dòng)恢復(fù),需要人工逐一重置。
待上述恢復(fù)的環(huán)境穩(wěn)定1至2天,觀察虛機(jī)運(yùn)行和業(yè)務(wù)都正常和穩(wěn)定,還得繼續(xù)完成變更VC的動(dòng)作。首先在新的VC上創(chuàng)建好vSAN集群,名稱最好和之前的一樣,并對(duì)集群開啟vSAN功能,接著SSH登錄每個(gè)主機(jī)節(jié)點(diǎn),執(zhí)行命令esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMember ListUpdates將每個(gè)主機(jī)忽略成員更新,然后在新VC的集群中逐一添加主機(jī)。
全部添加完畢后,逐個(gè)查看主機(jī)摘要,在第一個(gè)添加的主機(jī)上,竟然還有警告信息:“已找到另一臺(tái)參與vSAN服務(wù)的主機(jī),但這臺(tái)主機(jī)不是該主機(jī)的vCenter集群的成員”。立即回到舊VC查看,發(fā)現(xiàn)有4個(gè)節(jié)點(diǎn)處于not responding狀態(tài),還有2個(gè)節(jié)點(diǎn)活著,并且活著的2個(gè)主機(jī)節(jié)點(diǎn)承載的虛機(jī),也沒有出現(xiàn)在新VC中。整個(gè)人感覺頓時(shí)又不好了。
圖5 更新ESXi配置確認(rèn)對(duì)話框
正在考慮如何搜索和處理眼下的狀況,舊VC自動(dòng)進(jìn)行了刷新,6個(gè)節(jié)點(diǎn)已經(jīng)全都顯示not responding狀態(tài)了,再去新VC中查看,之前的警告也隨之消失,6個(gè)主機(jī)節(jié)點(diǎn)除了開啟SSH的警告外,都表現(xiàn)正常。原來只是一場虛驚,沒有給vSAN足夠的時(shí)間完成后臺(tái)同步,待集群內(nèi)部協(xié)商同步好了所有狀態(tài),也就恢復(fù)了正常。最后,回到每個(gè)主機(jī)的SSH會(huì)話,執(zhí)行命令esxcfgadvcfg -s 0 /VSAN/IgnoreClusterMember ListUpdate不再忽略成員更新。
繼續(xù)等待一段時(shí)間,vSAN自動(dòng)進(jìn)行了運(yùn)行狀況檢查,顯示“vCenter狀態(tài)具有權(quán)威性”測試失敗,給的建議是:“如果已替換vCenter Server/已從備份恢復(fù) vCenter Server,并且vCenter Server中的當(dāng)前主機(jī)列表正確,那么請(qǐng)執(zhí)行‘更新ESXi配置‘操作”。看來這也是新版vSAN的特性,對(duì)于遷移變更VC有了更全面的保障。
根據(jù)提示點(diǎn)擊“更新ESXi配置”按鈕,彈出確認(rèn)對(duì)話框,如圖5所示。
確認(rèn)后,后臺(tái)自動(dòng)更新vSAN配置,隨后該警告消失。關(guān)閉每個(gè)主機(jī)SSH服務(wù),主機(jī)和集群所有警告信息都消失,遷移動(dòng)作順利完成。
相信很多讀者能夠通過此文,解答了直接刪除vSAN集群后果會(huì)發(fā)生什么這個(gè)好奇心理。本人也久久無法忘記原廠工程師聽到我說自己就這么把生產(chǎn)環(huán)境的vSAN集群刪除后,那種不可思議的驚詫語氣。對(duì)于這一次誤刪除事故,某種程度上似乎是是禍躲不過的,一方面是只有親自錯(cuò)過,才會(huì)印象更深刻;另一方面也正是因?yàn)檫@些“失誤”,才千錘百煉了技術(shù)上的淡定。
在vSAN 6.6的變化上,vSAN網(wǎng)絡(luò)不再使用多播multicast,而是開始使用單播unicast來簡化vSAN群集的網(wǎng)絡(luò)要求,升級(jí)或安裝vSAN 6.6并完成通過磁盤升級(jí)之后,群集會(huì)自動(dòng)切換到單播,這些細(xì)節(jié)上的變化,也使得vSAN管理和運(yùn)行中越來越可控。