技術文章 » 淺析 GlusterFS 與 JuiceFS 的架構異同

淺析 GlusterFS 與 JuiceFS 的架構異同

2023-08-25 12:00:46

在進行分散式檔案儲存解決方案的選型時，GlusterFS 無疑是一個不可忽視的考慮物件。作為一款開源的軟體定義分散式儲存解決方案，GlusterFS 能夠在單個叢集中支援高達 PiB 級別的資料儲存。自從首次釋出以來，已經有超過十年的發展歷程。目前，該專案主要由 Red Hat 負責維護，並且在全球範圍內擁有龐大的使用者群體。本文旨在通過對比分析的方式，介紹 GlusterFS 與 JuiceFS 的區別，為您的團隊在技術選型過程中提供一些參考。

系統架構對比

GlusterFS

GlusterFS 採用的是全分散式的架構，沒有中心化節點。GlusterFS 叢集主要由伺服器端和使用者端兩大部分組成。其中伺服器端負責管理和儲存資料，通常被稱為可信儲存池（Trusted Storage Pool）。這個儲存池由一系列對等的 Server 節點組成，一般會執行兩類程序：

  • glusterd：每個節點一個，負責設定管理和分發等。
  • glusterfsd：每個 Brick 一個，負責處理資料請求和對接底層檔案系統。

每個 Brick 上的所有檔案可以看成是 GlusterFS 的一個子集，就檔案內容而言，通過 Brick 直接存取和通過 GlusterFS 使用者端存取看到的結果通常是一致的。因此，在 GlusterFS 異常情況下，使用者通過整合多個 Bricks 內容就能一定程度上恢復出原有資料。另外在部署時，為了確保某臺機器故障時，整個檔案系統的存取不受影響，通常會對資料做冗餘保護。在 GlusterFS 中，多個 Bricks 會組成一個冗餘組，互相之間通過副本或糾刪碼的方式實現資料保護。當某個節點故障時，只能在冗餘組內做恢復，恢復的時間會比較長。在 GlusterFS 叢集擴容時，需要以冗餘組為單位整體擴容。

使用者端是掛載了 GlusterFS 的節點，負責對應用程式展示統一的名稱空間。其架構圖如下（來自 https://docs.gluster.org/en/latest/Quick-Start-Guide/Architecture/）：

JuiceFS

JuiceFS 採用「資料」與「後設資料」分離儲存的架構，檔案資料本身會被切分儲存在物件儲存（如 Amazon S3）當中，而後設資料則是會被儲存在使用者自行選擇的資料庫裡（如 Redis、MySQL）。通過共用同一個份資料庫與物件儲存，JuiceFS 實現了一個強一致性保證的分散式檔案系統，同時還具有「POSIX 完全相容」、「高效能」等諸多特性。JuiceFS 的架構，在其檔案有更詳細的介紹。

後設資料管理對比

GlusterFS 後設資料是純分散式的，沒有集中的後設資料服務。使用者端通過對檔名雜湊確定其所屬的 Brick；當請求需要跨多個 Bricks 存取（如 mv，ls 等）時，由使用者端負責協調。這種設計架構上比較簡單，但當系統規模擴大時，往往會帶來效能瓶頸。比如，ls 一個大目錄時可能會需要存取多個 Bricks 來獲得完整的結果，其中任何一個的卡頓都會導致整個請求變慢。另外，跨 Bricks 修改操作在途中遇到故障時，後設資料一致性也比較難保證。在嚴重故障時，還可能出現腦裂，需要手動恢復資料到統一版本。

JuiceFS 的後設資料儲存在一個獨立的資料庫（稱為後設資料引擎）中，使用者端會將檔案後設資料操作轉換成此資料庫的一個事務，藉助資料庫的事務能力來保證操作的原子性。這種設計使得 JuiceFS 的實現變得簡單，但對後設資料引擎提出了較高的要求。目前 JuiceFS 支援三大類 10 種事務型資料庫，具體可參見後設資料引擎檔案。

資料管理對比

GlusterFS 通過整合多個伺服器端節點的 Bricks（一般構建在本地檔案系統之上，如 XFS）來儲存資料。因此，它本身提供了一定的資料管理功能，如分佈管理、冗餘保護、故障切換、靜默錯誤檢測等。JuiceFS 則不直接使用硬碟，而是通過對接各種物件儲存來管理資料，大部分特性都依賴於物件儲存自身的實現。

大檔案拆分

在分散式系統中，將大檔案拆分成多個小塊雜湊儲存在不同節點中是一種常見的優化手段。這往往能讓應用在存取此檔案時有更高的並行度和整體頻寬。

  • GlusterFS：不拆分（曾有過 Striped Volume 會拆分大檔案，現已不再支援）。
  • JuiceFS：檔案先按大小拆成 64 MiB 的 Chunks，每個 Chunk 再根據寫入模式進一步拆成預設 4 MiB 的 Blocks；具體可參見架構檔案。

冗餘保護

  • GlusterFS：支援副本（Replicated Volume）和糾刪碼（Dispersed Volume）兩種型別。
  • JuiceFS：依賴於使用的物件儲存。

資料壓縮

  • GlusterFS：

    • 僅支援傳輸層壓縮，檔案由使用者端執行壓縮，傳輸到伺服器端後再由 Brick 負責解壓縮。
    • 不直接實現儲存層壓縮，而是依賴於 Brick 使用的底層檔案系統，如 ZFS。

  • JuiceFS：同時支援傳輸層壓縮和儲存層壓縮，資料的壓縮和解壓縮都在使用者端執行。

資料加密

存取協定

POSIX 相容性

NFS 協定

CIFS 協定

  • GlusterFS：內嵌支援 Windows，Linux Samba client 和 macOS 的 CLI 存取，不支援 macOS Finder。然而，檔案中建議用通過 Samba 將掛載點匯出的方式使用。
  • JuiceFS：不直接支援，需要掛載後通過 Samba 匯出。

S3 協定

HDFS 相容性

CSI 驅動

  • GlusterFS：曾支援過，但最近版本釋出於 2018 年 11 月，且倉庫已被標記 DEPRECATED。
  • JuiceFS：支援，具體可參見 JuiceFS CSI 驅動檔案。

擴充套件功能

POSIX ACLs

Linux 下對檔案的存取許可權控制一般有三類實體，即檔案擁有者（owner）、擁有組（group）和其他（other）。當我們有更復雜的需求，比如要給本屬於 other 的某個特定使用者單獨賦予許可權時，這套機制就做不到了。POSIX Access Control Lists (ACLs) 提供增強的許可權管理功能，可用來為任意使用者/使用者組指定許可權。

  • GlusterFS：支援，且支援 access ACLs 和 default ACLs。
  • JuiceFS：不支援。

跨域複製

跨域複製是指在兩套獨立的叢集間進行資料複製，一般被用來實現異地災備。

  • GlusterFS：支援單向的非同步增量複製，但需要兩邊是同版本的 Gluster 叢集。
  • JuiceFS：依賴後設資料引擎和物件儲存自身的複製能力，可以做單向複製。

目錄配額

  • GlusterFS：支援，且支援限制容量和/或檔案數。
  • JuiceFS：支援，且支援限制容量和/或檔案數。

快照

  • GlusterFS：僅支援儲存卷級別的快照，而且需要所有 Bricks 部署在 LVM 精簡卷（Thinly-Provisioned LVM）上。
  • JuiceFS：不支援快照，但支援目錄級別的克隆。

回收站

  • GlusterFS：支援，且預設關閉。
  • JuiceFS：支援，且預設開啟。

對比清單

GlusterFS JuiceFS
後設資料 純分散式 獨立資料庫服務
資料儲存 自主管理 依賴物件儲存服務
大檔案拆分 不拆分 拆分
冗餘保護 副本、糾刪碼 依賴物件儲存服務
資料壓縮 部分支援 支援
資料加密 部分支援 支援
POSIX 相容性 完整 完整
NFS 協定 不直接支援 不直接支援
CIFS 協定 不直接支援 不直接支援
S3 協定 支援（久未更新） 支援
HDFS 相容性 支援（久未更新） 支援
CSI 驅動 支援 支援
POSIX ACLs 支援 不支援
跨域複製 支援 依賴外部服務
目錄配額 支援 支援
快照 支援 不支援（但支援克隆）
回收站 支援 支援
主要維護者 Red Hat, Inc Juicedata, Inc
開發語言 C Go
開源協定 GPLV2 and LGPLV3+ Apache License 2.0

更多閱讀