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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章