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