簡(jiǎn)介《華為FusionStorage技術(shù)白皮書(shū)》是一份官方發(fā)布的技術(shù)文檔主要面向存儲(chǔ)架構(gòu)師、云運(yùn)維工程師、企業(yè)IT選型人員以及對(duì)分布式存儲(chǔ)技術(shù)感興趣的進(jìn)階學(xué)習(xí)者。資源包僅包含1個(gè)PDF文件壓縮后大小約7.52MB便于離線閱讀。文檔共分為概述、產(chǎn)品價(jià)值、產(chǎn)品架構(gòu)、數(shù)據(jù)服務(wù)、塊存儲(chǔ)、對(duì)象存儲(chǔ)、文件存儲(chǔ)七大部分系統(tǒng)梳理了FusionStorage技術(shù)從背景演進(jìn)到應(yīng)用落地的主線。其中產(chǎn)品架構(gòu)部分重點(diǎn)介紹了軟件架構(gòu)設(shè)計(jì)涵蓋存儲(chǔ)控制器、存儲(chǔ)節(jié)點(diǎn)、管理節(jié)點(diǎn)等關(guān)鍵組件的實(shí)現(xiàn)原理數(shù)據(jù)服務(wù)部分則分別對(duì)塊存儲(chǔ)、對(duì)象存儲(chǔ)、文件存儲(chǔ)的架構(gòu)概述、關(guān)鍵業(yè)務(wù)流程和特性進(jìn)行了深入拆解內(nèi)容兼顧方案全景與實(shí)現(xiàn)細(xì)節(jié)。已有338人學(xué)習(xí)了該資源適合用于技術(shù)調(diào)研、方案對(duì)比和知識(shí)體系構(gòu)建讀者可通過(guò)這份白皮書(shū)快速掌握FusionStorage在統(tǒng)一存儲(chǔ)、高性能、高可用等方面的設(shè)計(jì)思想與典型應(yīng)用方式。1. FusionStorage技術(shù)白皮書(shū)先看懂它在解決什么問(wèn)題再談性能數(shù)字FusionStorage是華為的分布式存儲(chǔ)軟件形態(tài)它的核心思路是把一批服務(wù)器自帶的本地盤(pán)聚合成一個(gè)統(tǒng)一存儲(chǔ)池對(duì)外提供塊、文件、對(duì)象等存儲(chǔ)接口。技術(shù)白皮書(shū)里最容易被翻過(guò)去的部分反而是部署決策最該看的部分IO路徑、副本與糾刪碼策略、故障域約束。很多人下載這份PDF是為了確認(rèn)“能不能用、性能多高”但拿著性能數(shù)字去投標(biāo)、去定硬件回來(lái)驗(yàn)收時(shí)才發(fā)現(xiàn)數(shù)字的測(cè)試條件和自己的業(yè)務(wù)負(fù)載對(duì)不上。下面按“架構(gòu)—配置—部署—避坑”的順序把白皮書(shū)里能直接指導(dǎo)落地的信息拆開(kāi)并補(bǔ)充白皮書(shū)不會(huì)寫(xiě)的驗(yàn)收細(xì)節(jié)。2. 白皮書(shū)的架構(gòu)主線DSFS、VBS、OSD、MDC這四個(gè)角色誰(shuí)管什么2.1 為什么先讀架構(gòu)而不是先讀性能把本地盤(pán)變成“一塊大盤(pán)”這件事最關(guān)鍵的是元數(shù)據(jù)和數(shù)據(jù)怎么分開(kāi)管理。FusionStorage的架構(gòu)核心是一個(gè)分布式文件系統(tǒng)在資料里通常被稱為DSFSDistributed Storage File System它把文件與塊語(yǔ)義和物理磁盤(pán)解耦。讀這份白皮書(shū)時(shí)先找“架構(gòu)圖”和“IO路徑”這兩節(jié)——它們比性能章節(jié)更能決定你這個(gè)集群能不能按預(yù)期工作。傳統(tǒng)雙控制器存儲(chǔ)的思路是升級(jí)機(jī)頭來(lái)獲得更多性能而分布式存儲(chǔ)的思路是加節(jié)點(diǎn)每加入一臺(tái)服務(wù)器就同時(shí)增加CPU、內(nèi)存、網(wǎng)絡(luò)和磁盤(pán)。這個(gè)區(qū)別解釋了為什么FusionStorage的擴(kuò)容是“加節(jié)點(diǎn)”而不是“換設(shè)備”也解釋了為什么白皮書(shū)會(huì)反復(fù)強(qiáng)調(diào)“橫向擴(kuò)展”。架構(gòu)圖能回答三個(gè)實(shí)際問(wèn)題數(shù)據(jù)放在哪、元數(shù)據(jù)放在哪、客戶端從哪里進(jìn)入。這三個(gè)答案直接決定故障域怎么劃分、擴(kuò)容時(shí)數(shù)據(jù)要不要重分布、以及為什么某些節(jié)點(diǎn)故障會(huì)導(dǎo)致整個(gè)集群不可用。2.2 四個(gè)核心角色一張表看清職責(zé)FusionStorage白皮書(shū)的架構(gòu)章節(jié)核心是幾個(gè)角色的分工。第一次讀的時(shí)候容易把它們混在一起我建議直接做一張對(duì)照表把每個(gè)角色對(duì)應(yīng)到自己將要部署的服務(wù)器上角色職責(zé)部署位置故障時(shí)影響DSFS分布式文件系統(tǒng)負(fù)責(zé)數(shù)據(jù)切片與全局命名空間邏輯層跨所有節(jié)點(diǎn)命名空間失效數(shù)據(jù)無(wú)法尋址VBS虛擬塊系統(tǒng)負(fù)責(zé)卷創(chuàng)建、地址映射和快照計(jì)算節(jié)點(diǎn)側(cè)該卷無(wú)法映射給主機(jī)OSD對(duì)象存儲(chǔ)設(shè)備負(fù)責(zé)數(shù)據(jù)落盤(pán)、副本寫(xiě)入和EC計(jì)算每個(gè)存儲(chǔ)節(jié)點(diǎn)觸發(fā)數(shù)據(jù)重建有冗余則業(yè)務(wù)不受影響MDC元數(shù)據(jù)控制器維護(hù)文件和對(duì)象的元數(shù)據(jù)控制節(jié)點(diǎn)新建卷、創(chuàng)建文件等控制操作失敗ZooKeeper集群協(xié)調(diào)與主節(jié)點(diǎn)選舉控制節(jié)點(diǎn)集群管理短暫不可用這個(gè)表在規(guī)劃時(shí)非常好用OSD數(shù)量決定容量和吞吐MDC和ZooKeeper所在節(jié)點(diǎn)的可靠性決定控制面是否可靠VBS決定計(jì)算節(jié)點(diǎn)的IO路徑長(zhǎng)度。讀白皮書(shū)時(shí)把架構(gòu)圖里的每個(gè)角色對(duì)應(yīng)到你的服務(wù)器清單上這是一個(gè)值得花半小時(shí)做的練習(xí)比反復(fù)看性能數(shù)字有用得多。2.3 IO請(qǐng)求從客戶端到磁盤(pán)的七步當(dāng)一臺(tái)計(jì)算節(jié)點(diǎn)上的應(yīng)用發(fā)起一次寫(xiě)請(qǐng)求數(shù)據(jù)大致要經(jīng)過(guò)應(yīng)用進(jìn)程 → 文件系統(tǒng) → VBS地址映射 → 網(wǎng)絡(luò)傳輸 → 目標(biāo)節(jié)點(diǎn)OSD → 寫(xiě)緩存 → 數(shù)據(jù)落盤(pán) → 返回確認(rèn)。前兩步消耗CPU中間兩步消耗網(wǎng)絡(luò)帶寬后兩步?jīng)Q定時(shí)延。白皮書(shū)里的IO路徑圖看的時(shí)候要特別注意“寫(xiě)請(qǐng)求是否經(jīng)過(guò)緩存”和“讀請(qǐng)求是否命中緩存”這兩處。讀請(qǐng)求和寫(xiě)請(qǐng)求的實(shí)際路徑不太一樣。寫(xiě)請(qǐng)求通常先落到緩存或日志盤(pán)再異步刷到數(shù)據(jù)盤(pán)所以時(shí)延相對(duì)低讀請(qǐng)求如果命中緩存會(huì)很快但緩存未命中時(shí)必須從HDD或SSD讀取時(shí)延一下子漲上去。如果業(yè)務(wù)是數(shù)據(jù)庫(kù)這類小IO隨機(jī)寫(xiě)瓶頸通常在OSD日志盤(pán)和網(wǎng)絡(luò)時(shí)延如果業(yè)務(wù)是視頻或備份這類大IO順序?qū)懫款i通常在HDD聚合帶寬。這一點(diǎn)直接決定你后續(xù)硬件選型看見(jiàn)“時(shí)延”數(shù)字時(shí)先問(wèn)一句這個(gè)數(shù)字是讀的還是寫(xiě)的、有沒(méi)有緩存參與。2.4 讀架構(gòu)圖最該停下來(lái)的兩個(gè)細(xì)節(jié)第一個(gè)細(xì)節(jié)是計(jì)算節(jié)點(diǎn)本地盤(pán)是否被納入存儲(chǔ)池。FusionStorage常見(jiàn)有兩種部署形態(tài)一種是獨(dú)立存儲(chǔ)節(jié)點(diǎn)專門(mén)做存儲(chǔ)一種是計(jì)算節(jié)點(diǎn)帶著本地盤(pán)一起組成存儲(chǔ)池Server SAN形態(tài)。后者是很多方案里強(qiáng)調(diào)的“融合”賣(mài)點(diǎn)但它對(duì)計(jì)算節(jié)點(diǎn)的CPU和內(nèi)存會(huì)有額外占用。遇到對(duì)可靠性要求很高的生產(chǎn)庫(kù)我一般會(huì)建議獨(dú)立存儲(chǔ)節(jié)點(diǎn)避免業(yè)務(wù)負(fù)載和存儲(chǔ)后臺(tái)任務(wù)互相搶資源。第二個(gè)細(xì)節(jié)是后臺(tái)自愈。白皮書(shū)會(huì)提到數(shù)據(jù)均衡、故障重建這類后臺(tái)任務(wù)但很少?gòu)?qiáng)調(diào)這些任務(wù)要占用CPU、IO和網(wǎng)絡(luò)資源。副本數(shù)越多、EC條帶越大重建時(shí)讀的數(shù)據(jù)量越大。規(guī)劃容量與帶寬時(shí)要按“正常業(yè)務(wù)峰值帶寬 后臺(tái)重建帶寬”預(yù)留而不是只按業(yè)務(wù)峰值算。很多集群在出現(xiàn)單節(jié)點(diǎn)故障后業(yè)務(wù)變慢不是因?yàn)楣收媳旧矶且驗(yàn)橹亟ㄟ^(guò)程把帶寬吃滿了。3. 把性能數(shù)字變成配置決策副本、EC、硬盤(pán)布局和容量計(jì)算3.1 副本還是糾刪碼白皮書(shū)給范圍選型要自己算白皮書(shū)通常會(huì)把三副本、兩副本、EC 42、EC 63等方案都列出來(lái)并給出各自的可用容量和可靠性特征。但最終選哪個(gè)要結(jié)合你的故障域半徑不能只看“數(shù)據(jù)冗余”那一頁(yè)推薦了哪個(gè)就用哪個(gè)。三副本的可靠性最高但有效容量只有約33%EC 42能把有效容量做到約67%適合容量?jī)?yōu)先的大數(shù)據(jù)、備份場(chǎng)景EC 63的校驗(yàn)計(jì)算開(kāi)銷更高適合對(duì)寫(xiě)入性能不那么敏感的對(duì)象存儲(chǔ)和歸檔場(chǎng)景。冗余方式有效容量比例可容忍節(jié)點(diǎn)故障典型場(chǎng)景3副本約33%2個(gè)節(jié)點(diǎn)核心數(shù)據(jù)庫(kù)、虛擬化2副本約50%1個(gè)節(jié)點(diǎn)開(kāi)發(fā)測(cè)試環(huán)境EC 42約67%2個(gè)節(jié)點(diǎn)視頻、備份、大數(shù)據(jù)EC 63約67%3個(gè)節(jié)點(diǎn)對(duì)象存儲(chǔ)、歸檔補(bǔ)充一個(gè)經(jīng)驗(yàn)EC 63雖然節(jié)點(diǎn)故障容忍數(shù)更高但單個(gè)節(jié)點(diǎn)失效后編碼計(jì)算壓力更大對(duì)CPU有明確要求。如果你的存儲(chǔ)節(jié)點(diǎn)CPU核數(shù)偏少EC 63重建時(shí)會(huì)明顯拖慢正常業(yè)務(wù)。白皮書(shū)給出的是能力邊界不是推薦配置選型必須用自己的硬件配置和業(yè)務(wù)模型去驗(yàn)證。3.2 容量利用率一個(gè)小腳本算清可用容量我一般會(huì)在規(guī)劃階段寫(xiě)一個(gè)小腳本把幾種冗余方案的可用容量一次性算出來(lái)方便跟業(yè)務(wù)方對(duì)齊# 計(jì)算不同冗余方案的可用容量單位TB def calc_usable(raw_capacity_tb, redundancy_type, reserve_ratio0.12): # reserve_ratio 為預(yù)留比例用于數(shù)據(jù)重建和故障轉(zhuǎn)移建議 0.10~0.15 usable_after_reserve raw_capacity_tb * (1 - reserve_ratio) if redundancy_type 3副本: return usable_after_reserve / 3 elif redundancy_type 2副本: return usable_after_reserve / 2 elif redundancy_type EC_4_2: return usable_after_reserve * 4 / (4 2) elif redundancy_type EC_6_3: return usable_after_reserve * 6 / (6 3) else: raise ValueError(未知的冗余類型) # 12臺(tái)服務(wù)器每臺(tái) 10TB 裸容量 raw 12 * 10 for rtype in [3副本, 2副本, EC_4_2, EC_6_3]: print(f{rtype}: 可用容量 {calc_usable(raw, rtype):.1f} TB)邏輯說(shuō)明先扣掉預(yù)留容量再做冗余折算。比如120TB裸容量按12%預(yù)留后是105.6TBEC 42的可用容量是105.6 × 4/6 70.4TB。這里預(yù)留比例不能省——分布式存儲(chǔ)在節(jié)點(diǎn)故障后會(huì)啟動(dòng)數(shù)據(jù)重建若容量已經(jīng)用滿到95%以上重建過(guò)程很可能因?yàn)榭臻g不足反復(fù)失敗甚至出現(xiàn)數(shù)據(jù)無(wú)法恢復(fù)的局面。參數(shù)說(shuō)明reserve_ratio是預(yù)留比例生產(chǎn)環(huán)境我見(jiàn)過(guò)留10%到15%都合理低于8%時(shí)重建翻車(chē)的概率明顯上升redundancy_type需要與存儲(chǔ)池實(shí)際配置一致腳本里四類方案覆蓋了常見(jiàn)場(chǎng)景如果廠商后續(xù)支持了自定義EC條帶自己擴(kuò)展一行即可。3.3 性能數(shù)字怎么讀先看IO模型再看硬件配置白皮書(shū)里的性能數(shù)字通常會(huì)給出好幾列4KB隨機(jī)寫(xiě)IOPS、64KB順序讀帶寬、平均時(shí)延等。這些數(shù)字來(lái)自特定硬件組合比如全閃配置、NVMe盤(pán)、RDMA網(wǎng)絡(luò)。如果業(yè)務(wù)是虛擬化場(chǎng)景優(yōu)先去看“4KB隨機(jī)讀寫(xiě)”那一列如果業(yè)務(wù)是小文件密集重點(diǎn)看“元數(shù)據(jù)操作速率”如果是視頻寫(xiě)入看“大塊順序?qū)憥挕?。最怕的是拿著全閃配置的帶寬數(shù)字去規(guī)劃HDD集群預(yù)算和容量全部按錯(cuò)。還要注意測(cè)試條件里的“并發(fā)數(shù)”同樣的數(shù)字8線程壓測(cè)和64線程壓測(cè)完全不可比。我建議把性能這一頁(yè)截圖存下來(lái)在下面標(biāo)注“該數(shù)字的IO大小、隨機(jī)順序、并發(fā)數(shù)、盤(pán)型、節(jié)點(diǎn)數(shù)”后續(xù)對(duì)照驗(yàn)收時(shí)用同一套條件復(fù)測(cè)。條件不寫(xiě)清楚性能排障就變成黑匣子誰(shuí)也沒(méi)法判斷問(wèn)題出在存儲(chǔ)還是測(cè)試方法。3.4 不同層級(jí)硬盤(pán)該放什么數(shù)據(jù)FusionStorage支持把不同類型盤(pán)納入同一個(gè)存儲(chǔ)池常見(jiàn)布局是SCM或SSD負(fù)責(zé)日志和熱數(shù)據(jù)緩存HDD負(fù)責(zé)大容量冷數(shù)據(jù)。白皮書(shū)會(huì)提到“分層”這個(gè)概念但很少告訴你每層數(shù)據(jù)占比怎么定。我的經(jīng)驗(yàn)是日志盤(pán)或緩存盤(pán)容量按業(yè)務(wù)寫(xiě)入帶寬和掉電保護(hù)窗口估算一般預(yù)留數(shù)小時(shí)到一天的寫(xiě)入量——太小會(huì)頻繁觸發(fā)寫(xiě)滿回刷太大則浪費(fèi)成本。HDD容量層按數(shù)據(jù)增長(zhǎng)曲線預(yù)留18到24個(gè)月的空間。冷熱數(shù)據(jù)比例不確定時(shí)先把熱數(shù)據(jù)層做小后續(xù)擴(kuò)容比換層簡(jiǎn)單。還有一個(gè)容易忽略的點(diǎn)不同批次、不同容量的盤(pán)混插在同一節(jié)點(diǎn)時(shí)OSD的均衡策略會(huì)把大容量盤(pán)的利用率拉低規(guī)劃節(jié)點(diǎn)時(shí)盡量保證同節(jié)點(diǎn)內(nèi)盤(pán)型一致。4. 部署與擴(kuò)容規(guī)劃從網(wǎng)絡(luò)、硬盤(pán)到故障域的落地順序4.1 部署前必須確認(rèn)的五項(xiàng)基礎(chǔ)條件讀白皮書(shū)時(shí)會(huì)看到硬件兼容性清單和部署前檢查項(xiàng)但實(shí)際落地時(shí)我建議把下面五項(xiàng)優(yōu)先級(jí)放到最前面網(wǎng)絡(luò)分布式存儲(chǔ)對(duì)網(wǎng)絡(luò)帶寬和時(shí)延非常敏感萬(wàn)兆是起步RoCE或IB更好。網(wǎng)卡隊(duì)列數(shù)、交換機(jī)流控、MTU都要在部署前確認(rèn)否則后續(xù)排查鏈路時(shí)延會(huì)非常被動(dòng)。硬盤(pán)直通存儲(chǔ)節(jié)點(diǎn)的RAID卡建議設(shè)置為HBA直通模式不要讓RAID卡再做一層虛擬化否則磁盤(pán)故障定位和SMART信息都會(huì)失真。時(shí)鐘同步整個(gè)集群的節(jié)點(diǎn)時(shí)間偏差要控制在毫秒級(jí)。時(shí)間漂移會(huì)引發(fā)心跳超時(shí)和節(jié)點(diǎn)誤判這是分布式存儲(chǔ)里很常見(jiàn)的隱性故障。兼容性清單操作系統(tǒng)內(nèi)核版本、固件版本、驅(qū)動(dòng)版本以官方兼容列表為準(zhǔn)。任何一項(xiàng)超出列表范圍后續(xù)排障都會(huì)被支持部門(mén)拒絕。電源與機(jī)柜節(jié)點(diǎn)掉電會(huì)導(dǎo)致多副本寫(xiě)入不一致UPS和雙電源接入要在規(guī)劃拓?fù)鋾r(shí)一并考慮不要等部署完成后再補(bǔ)。這五項(xiàng)里最容易“看著沒(méi)問(wèn)題出了事才后悔”的是第二條和第四條。RAID卡沒(méi)有切到直通模式掉盤(pán)時(shí)控制器可能直接把盤(pán)標(biāo)記為離線重建邏輯完全走偏固件版本超范圍可能連驅(qū)動(dòng)都加載不上。部署前花半天逐項(xiàng)核對(duì)省下的是后面幾周的排障時(shí)間。4.2 故障域怎么劃?rùn)C(jī)架、機(jī)房和控制節(jié)點(diǎn)故障域是分布式存儲(chǔ)里最容易因“看著簡(jiǎn)單”而疏忽的配置。常見(jiàn)做法是把一個(gè)機(jī)架或一個(gè)機(jī)房設(shè)為一個(gè)故障域副本或者EC的數(shù)據(jù)塊強(qiáng)制分散到不同故障域。小規(guī)模集群至少要做到容忍一個(gè)機(jī)架故障比如機(jī)架內(nèi)有兩臺(tái)存儲(chǔ)節(jié)點(diǎn)就要確保同一個(gè)卷的兩個(gè)副本不會(huì)同時(shí)落在同一個(gè)機(jī)架里?？刂乒?jié)點(diǎn)建議至少3個(gè)分布在不同的機(jī)架或電源域避免單點(diǎn)電源故障把控制面全部打掉。這里有個(gè)容易翻車(chē)的點(diǎn)如果只按“節(jié)點(diǎn)”建故障域不按“機(jī)架”建機(jī)架掉電時(shí)所有副本可能都在這個(gè)機(jī)架上服務(wù)直接不可用。白皮書(shū)的可靠性章節(jié)會(huì)畫(huà)故障域拓?fù)涫疽鈭D規(guī)劃時(shí)要把自己的機(jī)柜編號(hào)和節(jié)點(diǎn)IP填進(jìn)去真實(shí)演練一次單機(jī)架斷電。演練結(jié)果會(huì)告訴你配置里的故障域和你以為的故障域是不是一回事。4.3 中等規(guī)模集群的規(guī)劃順序以一個(gè)12節(jié)點(diǎn)、每節(jié)點(diǎn)10TB HDD加2塊NVMe SSD做緩存的集群為例我建議從到到尾按下述順序推進(jìn)確認(rèn)業(yè)務(wù)峰值容量與增長(zhǎng)曲線推算出兩年后的規(guī)模。用第3章的容量腳本確定冗余方案倒推出需要的裸容量和節(jié)點(diǎn)數(shù)。把計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)分開(kāi)畫(huà)清楚網(wǎng)絡(luò)拓?fù)錁?biāo)注每臺(tái)設(shè)備的IP和機(jī)柜位置。劃分故障域按機(jī)架分組分配節(jié)點(diǎn)角色。預(yù)留擴(kuò)容端口和IP段避免擴(kuò)容時(shí)改動(dòng)地址段。先在3節(jié)點(diǎn)小集群跑通部署、建卷、掛載、壓測(cè)的完整流程再做全量部署。順序別倒過(guò)來(lái)。有些團(tuán)隊(duì)先買(mǎi)機(jī)器再談架構(gòu)最后陷入容量不夠或者網(wǎng)絡(luò)帶寬不足的被動(dòng)局面。白皮書(shū)最前面的部署規(guī)劃部分雖然讀起來(lái)枯燥但它暗含了硬件和網(wǎng)絡(luò)的邊界條件值得逐項(xiàng)核對(duì)。還有一個(gè)建議部署完成后第一周每天看一眼存儲(chǔ)池容量、重建任務(wù)數(shù)和網(wǎng)絡(luò)錯(cuò)誤計(jì)數(shù)把基線記錄下來(lái)。沒(méi)有基線后面出現(xiàn)性能劣化時(shí)你連“變差了多少”都說(shuō)不清。5. 讀FusionStorage白皮書(shū)時(shí)容易踩的五個(gè)坑現(xiàn)象、原因與解決5.1 把“聚合帶寬”當(dāng)成了單卷性能現(xiàn)象按白皮書(shū)性能表規(guī)劃了帶寬驗(yàn)收時(shí)單個(gè)卷只能跑到標(biāo)稱值的三分之一。原因很多性能數(shù)字是多個(gè)節(jié)點(diǎn)、多個(gè)卷并行測(cè)試的聚合結(jié)果單卷受限于單個(gè)OSD節(jié)點(diǎn)的網(wǎng)卡速率和磁盤(pán)隊(duì)列深度不可能跑到整個(gè)集群的聚合值。解決驗(yàn)收時(shí)至少用3個(gè)卷并行壓測(cè)把帶寬相加后再與白皮書(shū)數(shù)字對(duì)比單卷性能按單個(gè)節(jié)點(diǎn)的能力估算再留一定余量。記錄測(cè)試結(jié)果時(shí)務(wù)必標(biāo)注“幾并發(fā)、幾個(gè)卷、什么IO大小”。5.2 預(yù)留容量不足擴(kuò)容周期比預(yù)期快一倍現(xiàn)象集群上線不到一年就容量告警而且數(shù)據(jù)重建任務(wù)反復(fù)失敗。原因預(yù)留比例設(shè)得太低比如低于8%。節(jié)點(diǎn)故障觸發(fā)重建時(shí)需要額外空間存放新副本或校驗(yàn)塊空間不足時(shí)重建任務(wù)會(huì)反復(fù)失敗。解決把預(yù)留比例固定在10%到15%并在容量監(jiān)控里設(shè)置“使用率達(dá)到85%即觸發(fā)擴(kuò)容評(píng)估”的告警線。這條經(jīng)驗(yàn)基本適用于所有分布式存儲(chǔ)白皮書(shū)會(huì)告訴你“推薦預(yù)留空間”這個(gè)參數(shù)存在但不會(huì)替你算你的業(yè)務(wù)該留多少。5.3 在虛擬機(jī)里測(cè)性能結(jié)果讓白皮書(shū)背鍋現(xiàn)象測(cè)試結(jié)果比白皮書(shū)差了將近一倍項(xiàng)目組懷疑存儲(chǔ)本身有問(wèn)題。原因測(cè)試機(jī)本身是虛擬機(jī)vCPU搶占、磁盤(pán)精簡(jiǎn)置備、虛擬化層中斷開(kāi)銷都會(huì)拖低IOPS這和存儲(chǔ)的關(guān)系不大。解決性能基線測(cè)試用裸金屬服務(wù)器或者至少在虛擬機(jī)里給vCPU做綁定、用厚置備盤(pán)而不是精簡(jiǎn)置備盤(pán)。測(cè)完對(duì)比時(shí)把主機(jī)端工具的負(fù)載模型參數(shù)一并記錄避免同類問(wèn)題反復(fù)糾纏。5.4 小集群的故障域設(shè)置過(guò)細(xì)節(jié)點(diǎn)故障后可用性反而下降現(xiàn)象一個(gè)節(jié)點(diǎn)宕機(jī)后告警不斷緊接著另一個(gè)節(jié)點(diǎn)也被標(biāo)記為疑似故障業(yè)務(wù)受損范圍擴(kuò)大。原因故障域理解有偏差。有人把每個(gè)節(jié)點(diǎn)單獨(dú)設(shè)為一個(gè)故障域單個(gè)節(jié)點(diǎn)故障就觸發(fā)大范圍數(shù)據(jù)重建重建風(fēng)暴把其他節(jié)點(diǎn)的IO和CPU打滿拖垮了第二個(gè)節(jié)點(diǎn)。也有人把副本分散到了控制節(jié)點(diǎn)上控制節(jié)點(diǎn)故障時(shí)數(shù)據(jù)可用性同時(shí)受影響。解決故障域最少按機(jī)架級(jí)規(guī)劃。節(jié)點(diǎn)數(shù)再少也要保證任意一個(gè)故障域失效時(shí)剩余副本仍然能滿足數(shù)據(jù)冗余策略的要求。小規(guī)模集群寧可減少副本數(shù)也不要讓故障域碎到單機(jī)粒度。5.5 升級(jí)固件后出現(xiàn)掉盤(pán)兼容性列表救不回來(lái)現(xiàn)象給存儲(chǔ)節(jié)點(diǎn)更換了網(wǎng)卡固件重啟后磁盤(pán)控制器識(shí)別不到部分盤(pán)。原因固件版本超出廠商兼容性矩陣?！巴吞?hào)就兼容”這種直覺(jué)在存儲(chǔ)場(chǎng)景不可靠固件微碼差異可能導(dǎo)致驅(qū)動(dòng)加載失敗或磁盤(pán)鏈路異常。解決任何硬件固件升級(jí)前先查白皮書(shū)附帶或官網(wǎng)的兼容性清單確認(rèn)當(dāng)前系統(tǒng)版本和固件版本都被支持再分批升級(jí)。每批控制在一臺(tái)節(jié)點(diǎn)觀察至少一天再繼續(xù)。這類問(wèn)題屬于翻車(chē)后基本沒(méi)有后悔藥的情況升級(jí)節(jié)奏放慢就是最大的保障。6. 把白皮書(shū)變成自己的驗(yàn)收清單驗(yàn)證一套FusionStorage配置的五個(gè)自問(wèn)白皮書(shū)不是拿來(lái)看完就合上的它應(yīng)該是一份可以對(duì)著核對(duì)的檢查清單。我在每次做存儲(chǔ)方案驗(yàn)收時(shí)會(huì)對(duì)著自己從白皮書(shū)提煉出的五個(gè)問(wèn)題逐條過(guò)一遍自問(wèn)對(duì)應(yīng)白皮書(shū)模塊驗(yàn)收動(dòng)作架構(gòu)圖里的每個(gè)角色落在哪臺(tái)服務(wù)器架構(gòu)章節(jié)在機(jī)柜拓?fù)鋱D上標(biāo)出OSD、MDC、ZooKeeper實(shí)際位置副本和EC的故障域是否與機(jī)架拓?fù)湟恢驴煽啃哉鹿?jié)停掉一個(gè)機(jī)架電源確認(rèn)數(shù)據(jù)仍可正常讀寫(xiě)性能指標(biāo)是否對(duì)應(yīng)我的IO模型性能章節(jié)用4KB隨機(jī)寫(xiě)和64KB順序讀分別壓測(cè)并記錄條件預(yù)留容量是否覆蓋重建空間容量規(guī)劃章節(jié)查看存儲(chǔ)池當(dāng)前利用率與預(yù)留比例配置是否匹配固件和驅(qū)動(dòng)是否在兼容性矩陣內(nèi)兼容性章節(jié)導(dǎo)出所有節(jié)點(diǎn)固件版本逐項(xiàng)比對(duì)這五個(gè)自問(wèn)看起來(lái)簡(jiǎn)單但多數(shù)項(xiàng)目翻車(chē)都出在其中一兩項(xiàng)上。我有一次做方案時(shí)只盯著白皮書(shū)里最亮眼的聚合性能數(shù)字忽略了IO模型差異結(jié)果業(yè)務(wù)方用4KB隨機(jī)寫(xiě)來(lái)驗(yàn)收數(shù)據(jù)差了一倍整個(gè)交付延期兩周。后來(lái)我給自己定了個(gè)習(xí)慣任何存儲(chǔ)方案的承諾書(shū)里必須寫(xiě)清楚性能數(shù)字的測(cè)試條件——幾并發(fā)、什么IO大小、什么盤(pán)型、幾個(gè)節(jié)點(diǎn)。這樣即使將來(lái)出現(xiàn)分歧雙方還有同一把尺子可以對(duì)照。FusionStorage技術(shù)白皮書(shū)的價(jià)值不在于讓你記住幾個(gè)數(shù)字而在于幫你建立一個(gè)從架構(gòu)到配置再到驗(yàn)收的思考框架。下次打開(kāi)這份PDF時(shí)直接翻到真正有用的章節(jié)先對(duì)照自己的環(huán)境和業(yè)務(wù)模型去讀再落到部署與驗(yàn)收動(dòng)作上。希望這份拆解能幫你把文檔變成可執(zhí)行的方法也希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取