?前言

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

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

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

①遵循POSIX標(biāo)準(zhǔn)，提供標(biāo)準(zhǔn)的文件系統(tǒng)API接口；

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

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

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

圖1 主流分布式技術(shù)對比

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

圖2 GlusterFS示意圖

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

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

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

圖3 JuiceFS架構(gòu)圖

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

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

(1)調(diào)研目標(biāo)：文件共享場景

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

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

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

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

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

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

(2)測試方案設(shè)計

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

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

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

2）標(biāo)準(zhǔn)POSIX文件系統(tǒng)壓測

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

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

3）引擎宕機(jī)

4）引擎恢復(fù)、引擎遷移

5）網(wǎng)絡(luò)異常

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

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

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

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

2）解壓文件

3）并行讀寫場景

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

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

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

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

5）海量小文件

6）異常場景

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

(4)初步調(diào)研結(jié)論

1）存在2個 POSIX壓測失?。篺test04, fs_fill；

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

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

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

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

(5)展望

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