CurveFS預覽版重磅首發，Curve加速邁向雲原生軟體定義儲存

網易數帆發表於2021-12-16

今天，我們很高興地釋出Curve專案的檔案系統，以及全新的部署工具。這也是CurveFS的第一個beta版本，預示著在Curve社群同仁的共同努力之下，Curve距離更好用的雲原生軟體定義儲存又前進了一步。

版本地址：

https://github.com/opencurve/...

2021年上半年Curve團隊立項決定做分散式共享檔案系統，我們的Roadmap列出了一些打算實現的關鍵特性，其中包括：

提供基於FUSE的使用者態的檔案讀寫介面，並且相容POSIX協議

  • 支援資料儲存到物件儲存系統
  • 支援雲原生部署、運維、使用
  • 支援多檔案系統

CurveFS的首發版本當前已實現上述功能，更多的功能仍在開發當中，歡迎試用體驗。

為什麼要做CurveFS

支援多領域數字業務發展，將Curve開源的網易數帆儲存團隊，在實踐中先一步感受到了新一代分散式檔案系統的需求，並得到了Curve社群成員的共鳴。

從跟網易內部產品以及數帆商業化客戶溝通，使用者使用的分散式檔案系統主要是CephFS（配合Kubernetes做PV使用），在近幾年的使用過程中，使用者在如下幾個場景遇到了難以徹底解決的問題：

場景1：期望兼顧效能和容量的機器學習場景

某業務機器學習場景下，在使用CephFS過程中，訓練耗時期望儘量短，訓練結果期望長期儲存，但訪問頻次很低，因此希望可以主動/被動沉澱到容量型儲存池，需要用到的時候可以主動/被動觸發遷移到效能型儲存池。這裡的主動是指業務可以自行切換某個目錄的儲存型別（如容量型、效能型），被動是指通過配置一定的生命週期規則（或快取管理策略）來觸發儲存池切換。

CurveFS在這個場景下，可以通過多級快取（CurveFS client端記憶體快取、client端硬碟快取，基於CurveBS的資料快取，基於CurveBS的高效能資料池）來加速訓練樣本的讀寫，而冷資料則放到容量型的儲存池也即物件儲存上。當使用者想要訓練某個已經沉澱到冷資料池的樣本集時，可以提前主動預熱這部分資料來加速訓練過程（也可以被動載入）。這部分功能會在後續版本中支援。

場景2：期望快速跨雲彈性發布的業務B

正常情況下，私有化部署一個CephFS叢集要準備多臺儲存節點，涉及到較長時間的機器準備、上架等操作。而在公有云場景部署一個自己的儲存叢集一般是不太實際的，因此一般使用公有云提供的儲存服務。對於想要多雲統一管理的業務，則需要進行相應的開發。我們期望可以做到一鍵部署到多種公有云上，對業務提供統一的使用邏輯。

CurveFS在這個場景下可以通過已有的物件儲存服務快速的部署一套幾乎無容量上限的分散式共享檔案系統，而且部署過程非常簡單快速。另外如果物件儲存引擎的效能無法滿足需求，CurveFS還可以通過雲硬碟如EBS、ESSD等來加速讀寫（既可以做client端快取，又支援做服務端快取）。

基於物件儲存的儲存引擎，跨雲部署也非常方便，運維人員簡單的修改幾個引數就可以使用同一套部署工具搞定跨雲部署。

場景3：低成本大容量需求的業務C

容量需求是首要的，但寫入速度要快，目前都是3副本場景，成本稍高，希望能支援。CurveFS在這個場景下，可以通過客戶端的記憶體快取、硬碟快取來加速寫入速度，之後非同步上傳到低成本的物件儲存叢集（通常採用EC糾刪碼來降低副本冗餘）。對於不想採購儲存伺服器部署儲存叢集的使用者來說，使用公有云的物件儲存服務來實現低成本大容量的儲存需求是比較合算的。

場景4：ES中介軟體冷熱資料自動分離

熱資料放在高效能的儲存硬體，冷資料放在低效能容量型儲存硬體，需要手工配置，希望能自動化在底層儲存引擎做掉。CurveFS在這個場景下，可以通過熱資料放在3副本的CurveBS叢集中，冷資料根據配置好的生命週期規則，到達一定時間沒有訪問後，轉存到物件儲存叢集中。

場景5：某業務S3和POSIX統一訪問需求

期望通過掛載fuse客戶端生產資料，通過S3介面訪問資料。CurveFS後續會支援S3協議訪問檔案系統中的檔案，同時支援S3協議和POSIX協議，另外支援S3協議後，Curve將成為一個同時支援塊、檔案、物件儲存的統一儲存系統，為使用者帶來更多的便利。

未來規劃場景：

Curve作為多種儲存系統（如HDFS、S3相容物件儲存等）的統一儲存層，接管並加速各系統訪問。Curve後續將支援接管多種儲存系統，並進行統一的cache加速。

當然我們在使用CephFS過程中還遇到了一些難以通過修改配置，或者簡單的二次開發解決掉的問題，這也是促使我們自研的動力來源：

  • 部分場景下效能瓶頸嚴重：尤其是後設資料時延方面，即使啟用了多MDS+靜態目錄繫結、後設資料儲存池使用SSD盤、甚至使用核心態客戶端等前提下，仍然不能很好的滿足業務訴求
  • 可用性風險高：多MDS場景+靜態目錄繫結功能開啟後，一旦某個主MDS故障，切換時間會比較長，期間業務會中斷
  • 後設資料負載均衡問題：靜態目錄繫結勉強可用，但可運維性不足，實施困難；動態目錄遷移目前可用性較差，會造成頻繁的反覆遷移，影響後設資料訪問的穩定性
  • 後設資料鎖實現邏輯複雜、難以理解、學習門檻過高：功能全面，但效能難免會受影響，另外開發人員維護難度大增，二次開發困難，遇到問題分析起來也很吃力
  • 均衡性問題：Ceph通過crush演算法來放置物件，該演算法可能導致叢集均衡性不是特別理想，故而會形成短板效應，導致叢集可用容量較少，成本升高

CurveFS架構設計

CurveFS的架構如下圖所示：

CurveFS由三個部分組成：

  1. 客戶端curve-fuse，和後設資料叢集互動處理檔案後設資料增刪改查請求，和資料叢集互動處理檔案資料的增刪改查請求。

  2. 後設資料叢集metaserver cluster，用於接收和處理後設資料(inode和dentry)的增刪改查請求。metaserver cluster的架構和CurveBS類似，具有高可靠、高可用、高可擴的特點：

    MDS用於管理叢集拓撲結構，資源排程。

    metaserver是資料節點，一個metaserver對應管理一個物理磁碟。CurveFS使用Raft保證後設資料的可靠性和可用性，Raft複製組的基本單元是copyset。一個metaserver上包含多個copyset複製組。

  3. 資料叢集data cluster，用於接收和處理檔案資料的增刪改查。data cluster目前支援兩儲存型別：支援S3介面的物件儲存以及CurveBS（開發中）。

主要功能

概述

當前版本CurveFS主要具有如下特性：

  1. POSIX相容: 像本地檔案系統一樣使用，業務可以無縫接入
  2. 高可擴：後設資料叢集規模可以線性擴充套件
  3. 快取記憶體：客戶端有記憶體和磁碟兩級快取加速
  4. 支援資料儲存到S3介面的物件儲存和CurveBS（開發中）

Client

CurveFS的client通過對接fuse，實現完整的檔案系統功能，稱之為curve-fuse。curve-fuse支援資料儲存在兩種後端，分別是S3相容的物件儲存和Curve塊儲存中（其他塊儲存的支援也在計劃中），目前已支援S3儲存後端，儲存到CurveBS後端尚在完善中，後續還可能支援S3和Curve塊混合儲存，讓資料根據冷熱程度在S3與Curve塊之間流動。curve-fuse的架構圖如下：

curve-fuse架構圖

curve-fuse包含幾個主要模組：

  • libfuse，對接了其lowlevel fuse api，支援fuse使用者態檔案系統；
  • 後設資料cache，包含fsinfo, inode cache, dentry cache, 實現對後設資料的快取；
  • meta rpc client， 主要對接後設資料叢集，實現meta op的傳送，超時重試等功能；
  • S3 client， 通過對接S3介面，將資料儲存在s3中；
  • S3 data cache， 這是S3資料儲存的快取層，作為資料快取，加速S3資料的讀寫效能；
  • curve client 通過對接Curve塊儲存SDK，實現將資料儲存在Curve塊儲存叢集中；
  • volume data cache，這是當資料儲存在Curve塊儲存中的快取層，以加速資料讀寫效能（開發中）；

curve-fuse現已對接完整的fuse模組，基本實現POSIX的相容，目前pjdtest測試通過率100%。

S3儲存引擎支援

S3 client負責將檔案的讀寫語義轉換成S3儲存的資料讀寫（upload，download）語義。考慮到S3儲存效能較差，我們在這一層對資料做了級快取：記憶體快取（dataCache）和磁碟快取（diskCache），整體架構如下：

S3ClientAdaptor主要包含以下幾個模組：

  • FsCacheManager：負責管理整個檔案系統的快取，包括inode到FileCacheManager的對映、讀寫cache大小統計和控制
  • FileCacheManager：負責管理單個檔案的快取
  • ChunkCacheManager：負責單個檔案內某個chunk的快取
  • DataCache：快取管理的最小粒度，對應一個chunk內一段連續的資料空間。資料最終在DataCache這一層對映為S3儲存的一個或多個物件，進行upoload
  • diskCache：負責本地磁碟快取管理，資料持久化可以先寫到本地磁碟上，再非同步的寫到S3儲存上，能夠有效的降低時延，提高吞吐
  • S3Client：負責呼叫後端的S3儲存介面，目前使用的是AWS的SDK

MDS

MDS是指後設資料管理服務，CurveFS的MDS類似於CurveBS的MDS（CurveBS的MDS介紹：https://zhuanlan.zhihu.com/p/...），提供中心化的後設資料管理服務。

CurveFS的MDS有以下功能：

  • 通過topology子模組，管理的整個叢集的topo資訊，以及整個topo的生命週期管理
  • 通過fs子模組，管理fs的super block資訊；提供檔案系統的建立，刪除，掛解除安裝，查詢等功能；負責fs的inode、dentry等後設資料在metaserver的分佈
  • 通過heartbeat子模組，維持和metaserver的心跳，並收集metaserver的狀態
  • 通過排程系統進行排程。curvefs的後設資料使用一致性協議保證可靠性，當出現某副本不可用的時候，排程器會自動的進行recover。排程功能正在開發中

作為一箇中心化的後設資料管理服務，其效能、可靠性、可用性也十分重要。

  • 在效能上：首先，MDS上後設資料都會全部快取在記憶體裡，加速其查詢。其次，在fs建立之後，MDS會為fs分配用來儲存inode、dentry資訊的分片，在系統中，一個分片被稱為一個partition。完成partition分配之後，fs的後設資料操作會由client直接發向metaserver。此後的fs的inode、dentry的後設資料管理並不經過MDS
  • 在可靠性和可用性上：MDS的後設資料持久化到etcd中，依靠3副本的etcd保證後設資料的可靠性。可以選擇部署多個MDS服務，但是同時之後有一個MDS對外提供服務，當主MDS因為特殊原因掛掉之後，會在自動的在剩下的MDS中，通過選主演算法選擇一個新的主MDS繼續提供服務

MetaServer

MetaServer是分散式後設資料管理系統，為客戶端提供後設資料服務。檔案系統後設資料進行分片管理，每個後設資料分片以三副本的形式提供一致性保證，三個副本統稱為Copyset，內部採用Raft一致性協議。同時，一個Copyset可以管理多個後設資料分片。所以，整個檔案系統的後設資料管理如下所示：

圖中共有兩個Copyset，三個副本放置在三臺機器上。P1/P2/P3/P4表示檔案系統的後設資料分片，其中P1/P3屬於一個檔案系統，P2/P4屬於一個檔案系統。

後設資料管理

檔案系統的後設資料進行分片管理，每個分片稱為Partition，Partition提供了對dentry和inode的增刪改查介面，同時Partition管理的後設資料全部快取在記憶體中。

Inode對應檔案系統中的一個檔案或目錄，記錄相應的後設資料資訊，比如atime/ctime/mtime。當inode表示一個檔案時，還會記錄檔案的資料定址資訊。每個Parition管理固定範圍內的inode，根據inodeid進行劃分，比如inodeid [1-200] 由Partition 1管理，inodeid [201-400] 由Partition 2管理，依次類推。

Dentry是檔案系統中的目錄項，記錄檔名到inode的對映關係。一個父目錄下所有檔案/目錄的dentry資訊由父目錄inode所在的Partition進行管理。

一致性

檔案系統後設資料分片以三副本形式儲存，利用raft演算法保證三副本資料的一致性，客戶端的後設資料請求都由raft leader進行處理。在具體實現層面，我們使用了開源的braft(https://github.com/baidu/braft)，並且一臺server上可以放置多個複製組，即multi-raft。

高可靠

高可用的保證主要來自兩個方面。首先，raft演算法保證了資料的一致性，同時raft心跳機制也可以做到在raft leader異常的情況下，複製組內的其餘副本可以快速競選leader，並對外提供服務。

其次，Raft基於Quorum的一致性協議，在三副本的情況下，只需要兩副本存活即可 。但是長時間的兩副本執行，對可用性也是一個考驗。所以，我們在Metaserver與MDS之間加入了定時心跳，Metaserver會定期向MDS傳送自身的統計資訊，比如：記憶體使用率，磁碟容量，複製組資訊等。當某個Metaserver程式退出後，複製組資訊不再上報給MDS，此時MDS會發現一些複製組只有兩副本存活，因此會通過心跳下發Raft配置變更請求，嘗試將複製組恢復到正常三副本的狀態。

全新的部署工具 CurveAdm

為了提升 Curve 的運維便利性，我們設計開發了 CurveAdm 專案，其主要用於部署和管理 Curve 叢集，目前已支援部署 CurveFS（CurveBS 的支援正在開發中）。

專案地址：

https://github.com/opencurve/...

CurveFS部署流程：

https://github.com/opencurve/...

CurveAdm 的設計架構如下圖所示：

  • CurveAdm內嵌一個 SQLite（嵌入式資料庫，所有 DB 為一個檔案），用於儲存叢集的topology與每個service相關資訊，包括serviceId、containerId等
  • CurveAdm通過SSH登入目標機器，通過Docker CLI執行命令，對容器進行操控，容器所用映象為Curve各個發行版，預設為latest最新版本

CurveAdm與之前的ansible部署工具相比較，具有如下幾個優點：

  • CurveAdm 支援跨平臺執行，獨立打包無其他依賴，可以一鍵安裝，易用性較好
  • Curve元件執行在容器裡，解決元件依賴問題和發行版適配問題
  • 使用golang開發，開發迭代速度快，可定製化程度高
  • 可自助收集叢集日誌並打包加密上傳給Curve團隊，便於分析解決問題
  • CurveAdm 本身支援一鍵自我更新，方便升級

目前已支援功能如下所示：

如果你對CurveAdm專案感興趣，歡迎參與貢獻（提交issue或需求、開發功能、編寫文件等等）。

待解決問題

當前版本是CurveFS的第一個beta版本，不建議在生產環境使用，已知待解決的問題有：

  • 暫不支援共享讀寫（開發中）
  • 硬碟資料快取空間管理策略、流控功能
  • 隨機讀寫效能問題：這是S3引擎的特點決定的，我們會進一步優化，比如採用併發分片上傳、range讀等
  • 異常節點自動恢復功能（開發中）
  • 回收站功能：誤刪資料可以找回並恢復
  • 併發讀寫特性：後續會支援多節點共用檔案系統同時讀寫
  • 監控接入：使用prometheus收集監控資訊，使用grafana進行展示

歡迎在GitHub上提交issue和bug，或者新增微訊號opencurve邀請您入群交流。

後續版本展望

Curve整體專案的釋出節奏通常為每半年一個大版本，每個季度一個小版本，CurveFS為一個比較大的全新版本，當前首發版本還有很多功能不完備，需要繼續完善，下個大版本我們的主要開發目標為（可能會根據實際需求進行部分調整）：

  • CurveBS儲存引擎支援
  • 資料跨引擎生命週期管理
  • CSI外掛
  • 部署工具完善
  • 基於K8s叢集部署：目前已經支援helm部署方式，後續將繼續優化，支援更高等級的雲原生運維級別
  • 多寫多讀
  • 運維工具優化（監控告警、問題定位）
  • 回收站
  • HDD場景適配優化
  • NFS、S3、HDFS等相容性
  • 快照

如果有相關訴求可以與我們溝通交流。

Curve是什麼

Curve的定位

定位：高效能、易運維、支援廣泛場景的開源雲原生軟體定義儲存系統。

願景：好用的雲原生軟體定義儲存。

CurveBS介紹

CurveBS是Curve雲原生軟體定義儲存系統的核心元件之一，其具備高效能、高可靠、易運維等特點，可以與雲原生場景良好適配實現存算分離架構。CurveFS後續也會支援使用CurveBS作為儲存引擎，CurveBS的總體架構如下圖所示：

詳細的設計文件可參考往期文章：

http://www.opencurve.io/docs/...

https://github.com/opencurve/...

https://github.com/opencurve/...

https://zhuanlan.zhihu.com/p/...

近期規劃

  • PolarFS適配：已完成單pfsd+單CurveBS卷的對接，後續會支援多pfsd+單CurveBS卷特性，程式碼庫：https://github.com/skypexu/po...
  • ARM64平臺適配：已完成基本功能測試，後續會進行效能優化和穩定性驗證，程式碼庫：https://github.com/opencurve/...
  • FIO CurveBS engine：已支援，程式碼庫：https://github.com/skypexu/fi...
  • NVME/RDMA適配：近期會進行適配驗證以及效能優化
  • iSCSI介面支援：使用範圍比較廣泛，普適性較高，計劃近期支援
  • Raft優化：嘗試優化Raft的日誌管理、提升I/O併發度、支援follower讀、Raft降級（3副本只有1副本存活仍然可對外服務）等

Curve更多資訊詳見：

相關文章