vSAN存儲空間驟降

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

圖l 無法創建虛機

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

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

圖2 無法創建快照

圖3 vSAN存儲的容量

圖4 節點主機的磁盤有一半未顯示健康狀態

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

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

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

小結：對生產環境而言，存儲空間忽然就不見了，其實是非常可怕的，既不知道空間去哪了，也不知道原來的數據文件是否還在，這或許也是分布式文件系統應用道路上必修的一課。

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

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