?前言

2021年開始，開源社區(qū)出現(xiàn)了一款名為JuiceFS的云原生分布式文件系統(tǒng)。這是一款由國內公司開源的分布式文件系統(tǒng)，2021年1月在GitHub上開源，支持k8s原生適配及多種應用場景。本文通過一系列的測試，評估分布式文件系統(tǒng)JuiceFS是否滿足G行應用場景的需求。

1.主流分布式文件系統(tǒng)技術參數(shù)對比

分布式文件系統(tǒng)首先是一個文件系統(tǒng)，應該具備的基本要素包括：?

①遵循POSIX標準，提供標準的文件系統(tǒng)API接口；

②數(shù)據(jù)強一致性，元數(shù)據(jù)組織形式可靠性以及性能；

③支持的文件存儲及訪問量級。

結合上述要點，對NAS、CephFS、GlusterFS、JuiceFS分布式文件系統(tǒng)技術參數(shù)進行簡要對比：

圖1 主流分布式技術對比

從上表可看出，GlusterFS和JuiceFS技術參數(shù)都不錯。GlusterFS是Gluster公司以GPL開源的POSIX分布式文件系統(tǒng)，2007年發(fā)布第一個公開版本，2011年被RedHat收購。實現(xiàn)的基本思路就是通過一個無狀態(tài)的中間件把多個單機文件系統(tǒng)組合成一個統(tǒng)一的命名空間提供給用戶。

圖2 GlusterFS示意圖

GlusterFS中間件由一組轉換器實現(xiàn)，每個轉換器實現(xiàn)一個功能，如：鎖、緩存、復制、分布數(shù)據(jù)等，使用者可以根據(jù)應用場景進行靈活配置。最大優(yōu)點是：文件最終以相同的目錄結構保存在單機文件系統(tǒng)上，這樣，即使GlusterFS本身故障也不會導致數(shù)據(jù)無法讀出。而這個結構最大的缺點是：缺乏獨立的元數(shù)據(jù)節(jié)點，要求所有存儲節(jié)點都有完整的數(shù)據(jù)目錄結構，導致整個文件系統(tǒng)的可擴展性有限。而數(shù)據(jù)一致問題更加復雜，文件目錄遍歷操作效率低下，缺乏全局監(jiān)控管理功能。

現(xiàn)在，對象存儲作為低成本、高持久海量的存儲服務在云時代廣泛使用。如果分布式文件系統(tǒng)能和對象存儲結合，不管是成本還是使用門檻上都將大大降低。原生GlusterFS并不支持對象存儲，后來集成了Swift對象存儲技術，將Gluster文件系統(tǒng)（Volume）作為Swift的后端文件存儲系統(tǒng)，用于管理磁盤級數(shù)據(jù)存儲，并提供了基于對象存儲的REST訪問接口。

相比之下，JuiceFS的核心思想是在對象存儲的基礎之上，實現(xiàn)獨立的基于內存的元數(shù)據(jù)引擎組織和管理文件，對象存儲用來存放文件數(shù)據(jù)本身。這種實現(xiàn)方式兼容POSIX、HDFS、S3API訪問接口，對應用透明，無需應用大改造，使用方便。可能存在的問題是元數(shù)據(jù)引擎的可靠性，理論上存在元數(shù)據(jù)引擎損壞而導致數(shù)據(jù)無法讀出的場景，因此生產(chǎn)環(huán)境中必須做高可用和兜底設計。

圖3 JuiceFS架構圖

2.JuiceFS分布式文件系統(tǒng)調研方案

從文檔介紹看，除了支持文件共享場景外，JuiceFS也支持非結構化數(shù)據(jù)的存儲、管理與分析場景。但是是否適合G行的使用場景和技術需求呢？

(1)調研目標：文件共享場景

1）一次寫多次讀的情況(非交易數(shù)據(jù))，比如日志、備份等。

2）對于一個文件多次讀寫場景(非交易數(shù)據(jù))，區(qū)分下面2種情況：

①1個writer多次寫入同一個文件

沒有并發(fā)，也不存在寫鎖，writer按open-write-close操作。

②存在多個writer并發(fā)寫入同一個文件

即多個文件先搶占鎖文件，獲得鎖后再對數(shù)據(jù)文件進行open-write-close操作，此種方式風險較高，每個客戶端上的JuiceFS進程open文件的fd中會保留文件長度，極端情況下存在覆蓋的可能性(Bug或操作不規(guī)范)，不建議此場景使用分布式文件系統(tǒng)。

(2)測試方案設計

測試方案的設計基于社區(qū)版JuiceFS 0.17.1+redis元數(shù)據(jù)引擎，針對標準化功能、性能及運維需求，從元數(shù)據(jù)備份、引擎宕機、引擎恢復、引擎遷移、POSIX規(guī)范、解壓文件、生成海量小文件、并行讀寫、并發(fā)讀寫、網(wǎng)絡異常、后端對象存儲異常等方面進行測試。

因為G行強一致性場景要求，測試不開啟JuiceFS cache功能。JuiceFS對接對象存儲obj bucket并mount到本地/mnt/juicefs-load目錄。所有測試驗證操作均在juicefs-load目錄進行。

1）元數(shù)據(jù)備份

2）標準POSIX文件系統(tǒng)壓測

方法一：Linux Test Project是社區(qū)標準的Linux操作系統(tǒng)測試套件，對應接口、定義、實現(xiàn)進行驗證和壓測。抽取其中文件系統(tǒng)相關的測試案例進行測試。

方法二：精簡的POSIX文件系統(tǒng)測試套件Pjdfstest，用于測試POSIX兼容性。

3）引擎宕機

4）引擎恢復、引擎遷移

5）網(wǎng)絡異常

6）后端對象存儲異常測試

(3)測試詳細數(shù)據(jù)

1）LTP POSIX文件系統(tǒng)壓測

Pjdtest精簡POSIX測試套件全部通過。

2）解壓文件

3）并行讀寫場景

多個協(xié)程并行寫不同的文件

4）并發(fā)讀寫場景

多個進程并發(fā)讀寫同一個文件，讀無特殊要求；測試結果符合預期。

并發(fā)寫需要先locklockfile并嚴格遵循open-write-close流程，寫入的內容在其他客戶端可見，測試結果符合預期。

5）海量小文件

6）異常場景

7）與現(xiàn)有對象存儲FIO性能數(shù)據(jù)對比

(4)初步調研結論

1）存在2個 POSIX壓測失敗：ftest04, fs_fill；

2）存在不穩(wěn)定現(xiàn)象(latency波動、內存吃緊時的現(xiàn)象)；

3）并行讀性能落后于本地fs、NAS；

4）并行寫性能落后于本地fs、NAS；

5）海量文件場景下跨不同類型引擎做備份恢復時間較長。

(5)展望

當前版本的JuiceFS在整體并發(fā)性、文件讀寫性能等方面暫時還無法滿足G行對共享存儲的需求，但是這種構建中對象存儲上，兼容對象存儲接口又提供基于FUSE的標準POSIX文件系統(tǒng)接口，還實現(xiàn)了元數(shù)據(jù)引擎來保障數(shù)據(jù)強一致性，其設計理念值得點贊。雖然目前與G行應用場景尚不能完全匹配，但整體而言，分布式文件系統(tǒng)是一個值得長期跟蹤的技術。期待在元數(shù)據(jù)安全、數(shù)據(jù)強一致性下的讀寫性能等方面有適合G行應用場景的分布式文件系統(tǒng)出現(xiàn)。