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