驚艷的vSAN硬件配置錯誤，你見過幾個？
每年年底和同事聊天時候都會討論這一年遇到的奇葩故障，這次也不例外。想想這幾年處理過或者看過的vSAN故障怎么也得好幾千個了，其中真的有一些比較奇葩的vSAN硬件配置錯誤。雖然現在回想起來都比較有意思，但是處理故障時候真的是吃驚到下巴都掉了下來。(畫外音：也不得不說vSAN還是很皮實的，有些用戶就在這種非官方支持的配置下跑了幾年的生產業務而平安無事)。
驅動固件不在兼容列表
驚艷指數：🌟
平時最常見到的就是驅動固件不在兼容列表了，所以驚艷指數只有一顆星。雖然這個常見問題從vSAN發布以來一直到現在依舊在發生，但是在2018年可以很明顯的感覺到由于用戶維護水平的提高以及vSAN健康檢查工具的完善，這類的問題發生的頻率已經明顯降低。還清楚的記得頭幾年處理過一個故障，客戶的使用的驅動/固件，不僅在VMware和硬件廠商的官網上找不到，連google都搜不到。后來客戶說這是硬件廠商給客戶提供的是硬件廠商內部的debug版本的驅動/固件...debug版本...debug...
這里再次需要說明下vSAN的硬件兼容測試的流程：為了修復已知問題，硬件廠商會發布新版本的驅動/固件，然后按照vSAN的統一的兼容性測試的流程進行測試，并且把結果反饋給VMware，VMware對結果進行確認后會更新到HCL網站。
下面是用戶經常問我的問題，我把答案就列出來吧...
- 為什么驅動和固件老有問題?
除了一小部分inbox驅動，VMware不發布任何硬件驅動，更不發布硬件固件...其實你問我的這個問題我也一直想問...
- 為什么HCL一直在更新?
硬件廠商會在新的版本驅動和固件修復已知問題，發布出來后如果經過vSAN兼容性測試就可以更新到在HCL網站上。VMware無法控制硬件廠商發布驅動/固件的頻率，只能確保每一個版本驅動/固件都通過兼容性測試。
- 為什么經過驗證的驅動/固件還有問題?是不是VMware兼容性測試質量不過關?
這個問題大概有幾個方面可以回答：首先是兼容性測試的方法無法完全模擬出每個用戶的實際生產模式。兼容性測試的方案是統一的，但是每個真實用戶的業務類型，使用特點都不一樣。因此非常有可能在實際使用過程中觸發新的驅動/固件相關的問題。其次就是做兼容性測試時候采樣的范圍，硬件廠商無法提供大量的測試樣本，比如讓硬件廠商提供100臺主機進行兼容性測試明顯是不現實的，人力和財力都無法滿足。最后就是硬件的質量的控制，像一些比較大的國際廠商，基本上每批次的硬件質量都很穩定，所以運行起來也會比較穩定;但是有一些國內的硬件廠商，批次和批次之間的硬件質量水平都不一致，再加上有些做兼容性驗證測試的硬件廠商工程師責任心問題，所以經常會出現比較惡心的事情。這真的不是說笑，而是客觀存在的事實...
基于上面的描述，那么最穩妥的方法是什么呢?
最最最簡單的方法就是根據vSAN健康檢查的提示進行升級/降級。VMware要求使用的驅動和固件必須在HCL列表里，并且兩者的搭配關系也必須符合在HCL的要求，并且非常強烈強烈強烈使用HCL里列出的最新的版本。
硬件不在兼容列表
驚艷指數：🌟🌟
這個很好理解，但是我還是見過一些比較有意思的案例：
- 使用家用臺式機級別的SSD/HDD提供給vSAN使用：不可否認，這種情況下vSAN可以使用的，但是這些硬件的性能以及使用壽命都無法滿足生產環境下的需要，尤其是作為緩存層的SSD，時刻進行大量的讀寫操作，這些負載不是非企業級的磁盤可以長時間承受的。
- 把容量層SSD作為緩存層SSD使用：這也是一個比較666的操作，有一些用戶把僅能用于全閃環境下容量層磁盤的SSD當作混合模式的緩存層磁盤使用。實際上這兩種不同用途的SSD的性能和使用壽命是完全不同的，因此如果把容量層的SSD用作緩存層的SSD后會經常遇到遇到一些性能相關的問題。
- 忘記帶Cache模塊的Raid卡：比如聯想的M5210這塊卡。我清楚記得在愛爾蘭的時候被這塊卡搞的死去活來：主機經常發生磁盤擁堵的問題，把能檢查的地方都檢查了一遍卻找不到原因。后來發現客戶使用的這塊卡忘記安裝了Cache模塊。不安裝Cache模塊的話卡的隊列深度只有260，然后安裝了Cache模塊后隊列深度達到將近900。而且VMware只驗證過了安裝了Cache模塊的M5210...后來客戶解釋說，他們在購買主機的時候忽略掉這個細節了...
- HBA330和H330，傻傻分不清楚：Dell針對vSAN推出一塊叫做HBA330的Raid卡，穩定性非常好。但是比較有意思的是Dell有另外一個卡叫做H330(H330沒有經過vSAN的兼容性測試)。有些用戶為了省事習慣把HBA330叫做H330...后面的故事的你應該可以想象的到：客戶想配置一個HBA330，于是說：“給我一個H330(HBA330)”。結果就是一個真的H330到了...
過小的緩存層磁盤
驚艷指數：🌟🌟🌟
關于緩存層磁盤與容量層磁盤的容量比，VMware的目前官方的介紹是按照使用容量的來計算的10%。但是根據經驗，如果按照物理容量來計算的10%以上會更穩定，尤其是在業務高峰期時可以有效避免擁堵現象的發生。目前為止，我遇到過的最小的比例是不到1%，也就是說每個磁盤組20T的容量層磁盤配置了一個200G的緩存層的SSD。因此在業務繁忙期間根本無法承載過高的負載....
充滿想象的底層Raid配置
驚艷指數：🌟🌟🌟🌟
根據vSAN的設計，vSAN會根據存儲策略的不同設置來保護不同的對象。例如FTT=1可以容忍一個節點故障，FTT=2可以容忍兩個節點故障。這些都是在vSAN軟件層面上定義并且執行的。有一些用戶也許是還停留在傳統的硬件配置的影響下，于是乎出現來這類謎一般的配置：
- 兩個SSD先做底層硬件Raid1，然后再作為緩存層磁盤使用...
- 多個HDD先做底層硬件Raid5，然后再作為容量層使用...
是嫌硬盤太便宜?還是覺得硬盤槽位太多?
這么土(lang)豪(fei)的使用方式既不是VMware支持的配置方式，也得不到任何額外的益處，還會增加排錯的難度。
那么vSAN要求的配置方式是什么樣子呢?大體流程如下：
- 確保使用硬件硬件/驅動/固件符合vSAN的HCL要求。
- 按照HCL要求使用Raid卡正確的模式：直通 或者 Raid
- 禁用掉Raid卡的寫緩存(或者調整為100%讀)
- 所有的磁盤按照HCL的要求進行配置：
- 直通模式的話就直接提供給ESXi使用
- Raid模式的話就每單個磁盤做為一個Raid0再提供給ESXi使用
沒有SSD?我們有HDD啊!!
驚艷指數：🌟🌟🌟🌟🌟
前方預警：
vSAN配置大魔王來了!!!
vSAN配置大魔王來了!!!
vSAN配置大魔王來了!!!
上個月我的同事在檢查一個日志的時候發現來這幾年以來最厲害的配置...vSAN主機上根本沒有配置緩存層SSD!沒有SSD!沒有SSD!
是的，你沒有看錯...客戶使用的所有vSAN磁盤都是機械硬盤，然后把其中一塊機械硬盤標示為SSD作為緩存層磁盤使用...而且這套系統客戶已經用了很長時間，至于vSAN健康檢查的報警嘛...直接忽略掉就好。這一波騷操作讓我著實驚訝來好久才緩過神...真是藝高人膽大啊...
以上就是目前我總結的比較驚艷的vSAN硬件配置，我相信肯定還有一些案例疏漏了，以后隨著想到隨著更新進來。
我一直相信任何一個優秀的解決方案應該包括：高質量的產品+正確的使用方法+堅實技術支持保障，只有這3點全部滿足，使用者才可以放心大膽的使用，也有時間去享受自己的生活。
