深入淺出分布式存儲的設計與優化之道

隨著信息化程度的不斷提高，全球數據日益膨脹。面對當前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下載地址