深刻淺出分佈式存儲的設計與優化之道

隨着信息化程度的不斷提升，全球數據日益膨脹。面對當前PB級的海量數據存儲需求，傳統的存儲系統在容量和性能的擴展上存在瓶頸。雲存儲以其擴展性強、性價比高、容錯性好等優點獲得了業界的普遍認同。因爲其前瞻性，衆多企業都將其做爲進軍雲計算的第一步。分佈式文件系統和分佈式塊存儲做爲雲存儲中重要的技術，成爲奠基雲存儲發展的重要基石。

對於大多數專一於雲計算自己的IT技術人員來講，對分佈式文件系統和分佈式塊存儲未必有深刻的瞭解。爲此，UCan下午茶-武漢站，咱們邀請了分佈式文件系統、分佈式塊存儲以及雲存儲相關的技術專家，一塊兒聊聊分佈式存儲的那些事兒。

分佈式文件系統產品架構解析——UCloud 鄧瑾

分佈式存儲產品在各種產品業務中是必不可少的基礎設施，瞭解存儲產品的設計思路及使用場景，可讓用戶更好地基於存儲產品構建本身的業務邏輯。來自UCloud 文件存儲研發工程師鄧瑾，圍繞UCloud分佈式文件系統UFS的設計理念和開發實踐，分享瞭如何解決業務多樣性對存儲產品的要求、如何解決前一代產品中遇到的侷限性以及如何避免同類的開源產品的瓶頸等難題。

鄧瑾認爲，分佈式文件系統是傳統文件系統的延伸，用戶能夠經過分佈式技術手段和公有云規模效應，獲取傳統文件系統所沒有的存儲能力：1）scale out: 容量和性能的線性/近線性提高；2）fault tolerant: 屏蔽硬件故障，提高數據可靠性與系統可用性；3）lower TCO & pay-as-you-go: 這是雲計算產品所獨有的特性，它可以給應用層的用戶提供一些比較低的TCO。

UFS（UCloud File System）是UCloud徹底自主研發、面向公有云業務設計的高可用/高可靠文件存儲服務。設計之初，研發團隊主要是利用開源軟件GlusterFS快速在公有云環境中進行產品原型驗證，但在運營過程當中發現，GlusterFS在多租戶的公有云環境中有較多的痛點和難點，如規模拓展性具備瓶頸(peering開銷大)，節點數量受限；沒法進行多集羣的管理與灰度管理；索引操做容易引發高IO從而影響數據操做性能，小文件訪問和大目錄操做性能極差等等，基於這些問題，UCloud最終決定進行自研產品的設計改進。

根據開源方案運營的痛點，UCloud首先將索引和數據分離，自定義的索引結構和語義，便於後續拓展非 NFS 協議；而後獨立設計的存儲服務，支持 set 管理、灰度等策略；此外，設計支持百萬級大目錄和TB+文件大小並支持QoS，對多租戶場景下的用戶訪問進行隔離；最後，經過數據加密與切片策略，保證數據的安全性。下圖爲UFS 1.0 的方案架構。

一般，一個成熟的架構須要經歷發現問題->改造實踐->發現新問題->再改造升級的過程，經過這種不斷的迭代升級，最後趨於穩定，UFS架構亦如是。在運營過程當中，UCloud存儲研發團隊發現UFS 1.0方案仍然一些侷限性，如存儲模型比較適合小分片場景，不夠通用；固定的底層存儲分片形成了必定的空間浪費；存儲層支持的文件尺度較小；對隨機寫的支持不夠等等。所以，團隊在UFS 1.0的基礎上進行了新一輪架構升級。

新架構對存儲層作了優化，採用了append-only 模型，以下圖，Stream表明一個文件流，可在尾部追加；Extent是stream中的數據分片，分片大小不固定，每一個extent 以文件的形式落地。在數據層，由streamsvr負責維護stream和extent的索引/路由信息，extentsvr維護extent內的block索引信息，提供直連客戶端的讀寫請求。

插件式的引擎設計，能夠下降寫入毛刺，並充分利用內存buffer下降讀毛刺。此外，爲了解決底層存儲引擎隨機寫不友好的問題，系統採用了FileLayer設計，對熱點數據進行緩存，下降存儲壓力。

分佈式存儲中的數據分佈算法——奧思數據 李明宇

數據分佈算法是分佈式存儲的核心技術之一，不只僅要考慮到數據分佈的均勻性、尋址的效率，還要考慮擴充和減小容量時數據遷移的開銷，兼顧副本的一致性和可用性。奧思數據創始人兼CTO 李明宇現場分析了幾種典型的數據分佈算法的優缺點，並分享了具體實現中會遇到的一些問題。

一致性哈希算法因其不須要查表或通訊過程便可定位數據，計算複雜度不隨數據量增加而改變，且效率高、均勻性好、增長/減小節點時數據遷移量小等特性受到開發者喜好。但具體到實際應用中，這種算法也因其自身侷限性遇到了諸多挑戰，如在「存儲區塊鏈」場景下，幾乎不可能獲取全局視圖，甚至沒有一刻是穩定的；企業級IT場景下，存在多副本可靠存儲問題，數據遷移開銷巨大。

所謂存儲區塊鏈，能夠理解爲分佈式存儲（p2p存儲） + 區塊鏈，它經過token激勵，鼓勵你們貢獻存儲資源，參與構建一個全世界範圍的分佈式存儲系統。由於須要激勵大量用戶自發參與，所以會涉及上億甚至幾十億節點的尋址和路由問題，目前業界主要的解決方案主要有Chord、Kademlia等。不過，Chord算法效率較低，會產生較高延遲，能夠採用Finger table，除了記錄當前節點以及下一節點位置，同時還記錄當前節點2^i+1的位置，下降計算複雜度，最終下降延遲。

企業級IT場景下，數據分佈算法包括Dynamo、Ceph的CRUSH、Gluster的Elastic Hashing以及Swift的Ring等。這些算法都有類似的特色，首先它們都是基於/借鑑一致性哈希，增長/減小節點時數據遷移量小。其次，引入對數據中心物理拓撲的建模（Cluster Map），數據多副本 / EC分片跨故障域 / 可用區分佈。另外，這些算法還能夠對節點劃分權重，數據分佈和容量/性能匹配，輔助擴容。

整體來講，這兩類方案均是基於一致性哈希算法實現，只是由於需求不一樣，纔有了不一樣的改進方向。企業級更注重副本故障域的分佈；而對於P2P存儲，則更注重在節點隨時退出隨時加入的狀況下，保證數據可以在有效時間內尋址。

雲硬盤架構升級和性能提高——UCloud 葉恆

雲硬盤做爲雲計算的基礎存儲產品，爲雲服務器提供了高可用、高可靠、持久化的數據塊級隨機存儲。雲盤的性能和數據可靠性尤其重要，UCloud根據過去運營經驗，在過去一年裏從新設計了雲盤的底層架構，提高了普通雲盤的性能，並支持了NVME高性能存儲。UCloud塊存儲研發工程師葉恆，着重講解了UCloud雲硬盤的架構升級和性能提高實踐。

經過對現階段問題和需求的分析，UCloud存儲研發團隊首先整理了架構升級的目標：1）解決原有軟件架構不能充分發揮硬件能力的侷限；2）支持SSD雲盤，提供QoS保證，充分發揮後端NVME物理盤的IOPS和帶寬性能，單個雲盤IOPS可達2.4W；3）支持更大容量雲盤，32T甚至更大；4）充分下降IO流量的熱點問題；5）支持併發建立幾千塊雲盤，支持併發掛載幾千塊雲盤；6）支持老架構雲盤在線向新架構遷移，支持普通雲盤在線遷移至SSD雲盤。

根據上述目標，UCloud定製了IO路徑優化、元數據分片、線程模型設計、防過載策略、在線遷移五大改造方向。

IO路徑優化： 老架構中，整個IO路徑有三大層，第一層宿主Client側，第二層Proxy側，第三層存儲Chunk層。爲了下降延時，優化後的方案將 Proxy 的功能拆分，將路由獲取交給了Client，IO讀寫Client可直接訪問存儲Chunk層。整個IO路徑就變成了2層，對於讀 IO 而言，一次網絡請求可直達後端存儲節點，其時延平都可下降 0.2-1ms。

元數據分片： 老架構中，UCloud 支持的分片大小是 1G。但在特殊場景下（如業務 IO 熱點侷限在較小範圍內），1G 分片會使普通 SATA 磁盤的性能很是差。新架構中，UCloud 將元數據分片調小，支持 1M 大小的數據分片。並採用以一套統一規則計算獲取路由的方案，節省IO路徑消耗，保證1M分片下，元數據的分配和掛載暢通無阻。

線程模型設計： 傳統架構採用單線程傳輸，單個線程寫 IOPS 達 6W，讀 IOPS 達 8W，難以支持後端 NVME 硬盤幾十萬的 IOPS 以及 1-2GB 的帶寬。爲了利用 NVME 磁盤的性能，UCloud採用了多線程傳輸模型，並經過IO路徑、路由獲取等軟件細節的優化，減小CPU消耗。

防過載策略： 多線程並行工做壓測時，UCloud模擬了熱點集中在某個線程上的場景，發現該線程CPU基本處於99%-100%滿載狀態，而其它線程則處於空閒狀態。爲了解決這個問題，存儲團隊採用按期上報線程CPU以及磁盤負載狀態的方式，當知足某線程持續繁忙而有線程持續空閒時，選取部分磁盤分片的IO切換至空閒線程，來規避部分線程過載。

在線遷移： 老架構普通雲盤性能較差，部分普通雲盤用戶業務發展較快，但願從普通雲盤遷移至SSD雲盤，知足更高的業務發展須要。面對用戶訴求，UCloud採用從系統外圍支持在線遷移的方式，快速達到在線遷移的目的。

據瞭解，SSD雲盤相比普通雲盤，IOPS提高了13倍，穩定性提高了3倍，平均時延下降了10倍。新架構推出後，已服務了現網用戶的3400多個雲盤實例，總存儲容量達800TB，集羣每秒IOPS均值31萬。

基於CephFS的改進及優化——深信服科技 盧波

據IDC的調查報告顯示，企業中80%的數據都是非結構化數據，這些數據每一年都按指數增加60%。分佈式文件存儲以其靈活擴展、快速部署等特色愈來愈受到政府、教育、醫療等行業用戶的青睞。隨着OpenStack技術的發展，Ceph成爲了分佈式存儲的明星，來自深信服科技的存儲研發專家盧波結合深信服研發的分佈式存儲系統EDS，分享了深信服針對Ceph的文件存儲所作的一些改進及優化，以及將來的一些思考。

Ceph 是一個分層的架構，底層是基於 CRush（哈希）的分佈式對象存儲—Rados，上層提供對象存儲（RadosGW）、塊存儲（RDB）和文件系統（CephFS）三種訪問方式。其中，CephFS 始於 Sage Weil 的博士論文研究，目標是實現分佈式的元數據管理以支持 EB 級別數據規模。下圖爲CephFS的總體結構。

ceph-mds: 緩存文件系統元數據，並將元數據持久化到rados中，自身運行在rados之上，自己並不存儲數據。

open： 客戶端從MDS獲取文件元數據

write： 客戶端直接經過rados進行數據寫入操做

全部數據的操做時均經過客戶端直接訪問raods，多客戶端的數據訪問操做時依靠OSD來控制，元數據和數據能夠在不一樣的存儲池中。能夠看到，CephFS是一個分佈式系統，須要跨網絡訪問，所以在實際使用中，其IO路徑較長，致使延時較高，性能受限。爲了解決此問題，深信服科技基於此架構進行了系列改進。

全局緩存： 緩存是整系統全局共享的，即只要緩存在任意一個節點上的文件分條數據，其它任意節點再次收到該數據的訪問請求後均可以從一級緩存中命中該數據。經過全局緩存，實現數據合併，利用K-V存儲的高吞吐，從而大大提升系統總體性能。

FusionStorage： FusionStorage塊存儲根據業務不一樣的IO大小，智能地對不一樣大小的IO採起不一樣的處理方式。對於小塊IO，FusionStorage塊存儲採用多副本的方式寫入分佈式EC Cache中，並在Cache中作條帶聚合；而對於大塊IO，則繞過度布式EC Cache，直接提交EC寫入後端硬盤。因爲大塊IO直接下盤，系統能夠釋放原來大塊IO佔用的寶貴的Cache資源，緩存更多的隨機小塊I/O，間接的提升了隨機小塊I/O的Cache命中率，提高系統隨機小IO的性能。而HDD在寫入大塊順序IO時，寫性能差距相比SSD並無那麼明顯，加上多塊HDD併發處理，在大塊順序IO的場景下系統也能得到很好的寫入帶寬，兼顧了系統的總體性能。

因爲篇幅有限，本文僅整理了現場演講部分精彩內容，感興趣的讀者能夠點擊連接下載講師演講PPT瞭解更多技術詳情。

下載地址（提交表單後可下載）：PPT下載地址