分散式檔案系統JuiceFS測試總結

語言: CN / TW / HK

​前言

2021年開始,開源社群出現了一款名為JuiceFS的雲原生分散式檔案系統。這是一款由國內公司開源的分散式檔案系統,2021年1月在GitHub上開源,支援k8s原生適配及多種應用場景。本文通過一系列的測試,評估分散式檔案系統JuiceFS是否滿足G行應用場景的需求。

1.主流分散式檔案系統技術引數對比

分散式檔案系統首先是一個檔案系統,應該具備的基本要素包括:​

①遵循POSIX標準,提供標準的檔案系統API介面;

②資料強一致性,元資料組織形式可靠性以及效能;

③支援的檔案儲存及訪問量級。

結合上述要點,對NAS、CephFS、GlusterFS、JuiceFS分散式檔案系統技術引數進行簡要對比:

圖1 主流分散式技術對比

從上表可看出,GlusterFS和JuiceFS技術引數都不錯。GlusterFS是Gluster公司以GPL開源的POSIX分散式檔案系統,2007年釋出第一個公開版本,2011年被RedHat收購。實現的基本思路就是通過一個無狀態的中介軟體把多個單機檔案系統組合成一個統一的名稱空間提供給使用者。

圖2 GlusterFS示意圖

GlusterFS中介軟體由一組轉換器實現,每個轉換器實現一個功能,如:鎖、快取、複製、分佈資料等,使用者可以根據應用場景進行靈活配置。最大優點是:檔案最終以相同的目錄結構儲存在單機檔案系統上,這樣,即使GlusterFS本身故障也不會導致資料無法讀出。而這個結構最大的缺點是:缺乏獨立的元資料節點,要求所有儲存節點都有完整的資料目錄結構,導致整個檔案系統的可擴充套件性有限。而資料一致問題更加複雜,檔案目錄遍歷操作效率低下,缺乏全域性監控管理功能。

現在,物件儲存作為低成本、高持久海量的儲存服務在雲時代廣泛使用。如果分散式檔案系統能和物件儲存結合,不管是成本還是使用門檻上都將大大降低。原生GlusterFS並不支援物件儲存,後來集成了Swift物件儲存技術,將Gluster檔案系統(Volume)作為Swift的後端檔案儲存系統,用於管理磁碟級資料儲存,並提供了基於物件儲存的REST訪問介面。

相比之下,JuiceFS的核心思想是在物件儲存的基礎之上,實現獨立的基於記憶體的元資料引擎組織和管理檔案,物件儲存用來存放檔案資料本身。這種實現方式相容POSIX、HDFS、S3API訪問介面,對應用透明,無需應用大改造,使用方便。可能存在的問題是元資料引擎的可靠性,理論上存在元資料引擎損壞而導致資料無法讀出的場景,因此生產環境中必須做高可用和兜底設計。

圖3 JuiceFS架構圖

2.JuiceFS分散式檔案系統調研方案

從文件介紹看,除了支援檔案共享場景外,JuiceFS也支援非結構化資料的儲存、管理與分析場景。但是是否適合G行的使用場景和技術需求呢?

(1)調研目標:檔案共享場景

1)一次寫多次讀的情況(非交易資料),比如日誌、備份等。

2)對於一個檔案多次讀寫場景(非交易資料),區分下面2種情況:

①1個writer多次寫入同一個檔案

沒有併發,也不存在寫鎖,writer按open-write-close操作。

②存在多個writer併發寫入同一個檔案

即多個檔案先搶佔鎖檔案,獲得鎖後再對資料檔案進行open-write-close操作,此種方式風險較高,每個客戶端上的JuiceFS程序open檔案的fd中會保留檔案長度,極端情況下存在覆蓋的可能性(Bug或操作不規範),不建議此場景使用分散式檔案系統。

(2)測試方案設計

測試方案的設計基於社群版JuiceFS 0.17.1+redis元資料引擎,針對標準化功能、效能及運維需求,從元資料備份、引擎宕機、引擎恢復、引擎遷移、POSIX規範、解壓檔案、生成海量小檔案、並行讀寫、併發讀寫、網路異常、後端物件儲存異常等方面進行測試。

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

1)元資料備份

2)標準POSIX檔案系統壓測

方法一:Linux Test Project是社群標準的Linux作業系統測試套件,對應介面、定義、實現進行驗證和壓測。抽取其中檔案系統相關的測試案例進行測試。

方法二:精簡的POSIX檔案系統測試套件Pjdfstest,用於測試POSIX相容性。

3)引擎宕機

4)引擎恢復、引擎遷移

5)網路異常

6)後端物件儲存異常測試

(3)測試詳細資料

1)LTP POSIX檔案系統壓測

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

2)解壓檔案

3)並行讀寫場景

多個協程並行寫不同的檔案

4)併發讀寫場景

多個程序併發讀寫同一個檔案,讀無特殊要求;測試結果符合預期。

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

5)海量小檔案

6)異常場景

7)與現有物件儲存FIO效能資料對比

(4)初步調研結論

1)存在2個 POSIX壓測失敗:ftest04, fs_fill;

2)存在不穩定現象(latency波動、記憶體吃緊時的現象);

3)並行讀效能落後於本地fs、NAS;

4)並行寫效能落後於本地fs、NAS;

5)海量檔案場景下跨不同型別引擎做備份恢復時間較長。

(5)展望

當前版本的JuiceFS在整體併發性、檔案讀寫效能等方面暫時還無法滿足G行對共享儲存的需求,但是這種構建中物件儲存上,相容物件儲存介面又提供基於FUSE的標準POSIX檔案系統介面,還實現了元資料引擎來保障資料強一致性,其設計理念值得點贊。雖然目前與G行應用場景尚不能完全匹配,但整體而言,分散式檔案系統是一個值得長期跟蹤的技術。期待在元資料安全、資料強一致性下的讀寫效能等方面有適合G行應用場景的分散式檔案系統出現。