基于ESXi5.5由三節(jié)點組成的vSAN集群環(huán)境，運行了三年一直未出現(xiàn)問題。某日創(chuàng)建新虛機，不僅無法創(chuàng)建成功，還出現(xiàn)了無法快照的奇怪現(xiàn)象（如圖 l，2）。這些現(xiàn)象都是多年虛擬化運維所未見的。

圖l 無法創(chuàng)建虛機

仔細看這些報錯詳細信息，說“the policy requires 3 hosts contributing storage ,only found 2 in the cluster.”，可明明三個主機節(jié)點都在線，為什么會說只找到2個呢？進一步看vSAN空間，vSAN總容量只有24.56TB（如圖3），這跟記憶中的49.14TB正好少了一半。進一步查看磁盤信息，發(fā)現(xiàn)有一個節(jié)點的磁盤全部沒顯示健康狀態(tài)，一個節(jié)點的磁盤有一半沒顯示健康狀態(tài)，這正好符合磁盤空間減少一半的特征（如圖 4）。

近期即沒有忽然斷電，也沒有人為調(diào)整，用的好好的vSAN，為什么忽然就少了一半空間呢？就算是磁盤壞了，也不太可能同時壞這么多呀。聯(lián)系官方客服后收集日志信息分析，在主機的VMkernel中可以看到掛載的磁盤出現(xiàn)Not supported的報錯：

圖2 無法創(chuàng)建快照

圖3 vSAN存儲的容量

圖4 節(jié)點主機的磁盤有一半未顯示健康狀態(tài)

2016-09-26T11:12:29.950Z cpu10:33318)ScsiDeviceIO:7493:Get VPD 86 Inquiry for device"naa.5000c5006551e243"from Plugin "NMP"failed. Not supported

2016-09-26T11:12:30.112Z cpu10:33318)ScsiDeviceIO:6710:Could not detect setting of sitpua for device naa.5000c5006551e243.Error Not supported.

由于這些不支持的報錯，又導致很多I/O的報錯：

2016-09-26T11:14:25.466Z cpu22:34304)Vol3:731:Couldn't read volume header from naa.5000c5006553efea:1:I/O error

2016-09-26T11:14:25.796Z cpu22:34304)Vol3:731:Couldn't read volume header from naa.5000c50065556981:1:I/O error

依據(jù)上面的情況，懷疑磁盤陣列卡有兼容性或驅動的問題。查詢后確認，這款陣列卡已經(jīng)不在vSAN的兼容性列表中，正是由于陣列卡不兼容，導致vSAN不穩(wěn)定，系統(tǒng)自動將磁盤組卸載，同時官方建議更換到符合兼容性的陣列卡。

是否需要換卡需要從長計議，眼下的“亞健康”也不能直接換卡，讓vSAN存儲恢復正常是更緊迫的任務。登錄任一節(jié)點主機的ssh命令行，通過命令esxcli vsan storage list可觀察到標記為“In CMMDS:false”的磁盤組就是WebClient上看到健康狀態(tài)未標記正常的部分，還是通過命令將磁盤組掛載，注意是用vsan disk group uuid，掛載完成后回到vCenter，終于看到存儲空間恢復了正常數(shù)值，創(chuàng)建虛機和快照也都不再報錯。

小結：對生產(chǎn)環(huán)境而言，存儲空間忽然就不見了，其實是非?？膳碌?，既不知道空間去哪了，也不知道原來的數(shù)據(jù)文件是否還在，這或許也是分布式文件系統(tǒng)應用道路上必修的一課。

vSAN的第一個版本就是運行在ESXi 5.5，而這一環(huán)境也持續(xù)用了3年，對于3年前還在兼容列表的陣列卡而言，3年后發(fā)生的變化也是始料未及的，幸運的是都還能找回來。

反觀現(xiàn)在vSAN 2.0，增加了HCL數(shù)據(jù)庫，能夠經(jīng)常檢查硬件是否符合兼容性，隨著ESXi的升級，原本兼容的硬件變得不兼容也更容易掌握了。