常見開源分布式檔案系統架構對比

什么是檔案系統？

檔案系統是計算機中一個非常重要的組件，為存盤設備提供一致的訪問和管理方式，在不同的作業系統中，檔案系統會有一些差別，但也有一些共性幾十年都沒怎么變化：

1. 資料是以檔案的形式存在，提供 Open、Read、Write、Seek、Close 等API 進行訪問；
2. 檔案以樹形目錄進行組織，提供原子的重命名（Rename）操作改變檔案或者目錄的位置，

檔案系統提供的訪問和管理方法支撐了絕大部分的計算機應用，Unix 的“萬物皆檔案”的理念更是凸顯了它的重要地位，檔案系統的復雜性使得它的可擴展性未能跟得上互聯網的高速發展，極大簡化了的物件存盤及時填補了空缺得以快速發展起來，因為物件存盤缺乏樹狀結構也不支持原子重命名操作，跟檔案系統有很大的差別，本文暫不討論，

單機檔案系統的挑戰

絕大多數檔案系統都是單機的，在單機作業系統內為一個或者多個存盤設備提供訪問和管理，隨著互聯網的高速發展，單機檔案系統面臨很多的挑戰：

• 共享：無法同時為分布在多個機器中的應用提供訪問，于是有了 NFS 協議，可以將單機檔案系統通過網路的方式同時提供給多個機器訪問，
• 容量：無法提供足夠空間來存盤資料，資料只好分散在多個隔離的單機檔案系統里，
• 性能：無法滿足某些應用需要非常高的讀寫性能要求，應用只好做邏輯拆分同時讀寫多個檔案系統，
• 可靠性：受限于單個機器的可靠性，機器故障可能導致資料丟失，
• 可用性：受限于單個作業系統的可用性，故障或者重啟等運維操作會導致不可用，

隨著互聯網的高速發展，這些問題變得日益突出，涌現出了一些分布式檔案系統來應對這些挑戰，

下面介紹幾個我了解過的分布式檔案系統的基本架構，并比較不同架構的優點和局限，

GlusterFS

GlusterFS 是由美國的 Gluster 公司開發的 POSIX 分布式檔案系統（以 GPL 開源），2007年發布第一個公開版本，2011年被 Redhat 收購，

它的基本思路就是通過一個無狀態的中間件把多個單機檔案系統融合成統一的名字空間（namespace）提供給用戶，這個中間件是由一系列可疊加的轉換器（Translator）實作，每個轉換器解決一個問題，比如資料分布、復制、拆分、快取、鎖等等，用戶可以根據具體的應用場景需要靈活配置，比如一個典型的分布式卷如下圖所示：

Server1 和 Server2 構成有 2 副本的 Volume0，Server3 和 Server4 構成 Volume1，它們再融合成有更大空間的分布式卷，

優點：
資料檔案最終以相同的目錄結構保存在單機檔案系統上，不用擔心 GlusterFS 的不可用導致資料丟失，

沒有明顯的單點問題，可線性擴展，

對大量小檔案的支持估計還不錯，

挑戰：
這種結構是相對靜態的，不容易調整，也要求各個存盤節點有相同的配置，當資料或者訪問不均衡時沒法進行空間或者負載調整，故障恢復能力也比較弱，比如 Server1 故障時，Server2 上的檔案就沒辦法在健康的 3 或者 4上增加拷貝保障資料可靠，

因為缺乏獨立的元資料服務，要求所有存盤節點都會有完整的資料目錄結構，遍歷目錄或者做目錄結構調整時需要訪問所有節點才能得到正確結果，導致整個系統的可擴展能力有限，擴展到幾十個節點時還行，很難有效地管理上百個節點，

CephFS

CephFS 始于 Sage Weil 的博士論文研究，目標是實作分布式的元資料管理以支持 EB 級別資料規模，2012年，Sage Weil 成立了 InkTank 繼續支持 CephFS 的開發，于 2014年被 Redhat 收購，直到 2016 年，CephFS 才發布可用于生產環境的穩定版（CephFS 的元資料部分仍然是單機的），現在，CephFS 的分布式元資料仍然不成熟，

Ceph 是一個分層的架構，底層是一個基于 CRUSH（哈希）的分布式物件存盤，上層提供物件存盤（RADOSGW）、塊存盤（RDB）和檔案系統（CephFS）三個API，如下圖所示：

用一套存盤系統來滿足多個不同場景的存盤需求（虛擬機鏡像、海量小檔案和通用檔案存盤）還是非常吸引人的，但因為系統的復雜性需要很強的運維能力才能支撐，實際上目前只有塊存盤還是比較成熟應用得比較多，物件存盤和檔案系統都不太理想，聽到一些使用案例用過一段時間后就放棄了，

CephFS 的架構如下圖所示：

CephFS 是由 MDS（Metadata Daemon) 實作的，它是一個或者多個無狀態的元資料服務，從底層的 OSD 加載檔案系統的元資訊，并快取到記憶體中以提高訪問速度，因為 MDS 是無狀態的，可以配置多個備用節點來實作 HA，相對比較容易，不過備份節點沒有快取，需要重新預熱，有可能故障恢復時間會比較長，

因為從存盤層加載或者寫入資料會比較慢，MDS 必須使用多執行緒來提高吞吐量，各種并發的檔案系統操作導致復雜度大大上升，容易發生死鎖，或者因為 IO 比較慢導致的性能大幅下降，為了獲得比較好的性能，MDS 往往需要有足夠多的記憶體來快取大部分元資料，這也限制了它實際的支撐能力，

當有多個活躍的 MDS 時，目錄結構中的一部分（子樹）可以動態的分配到某個MDS并完全由它來處理相關請求，以達到水平擴展的目的，多個活躍之前，不可避免地需要各自鎖機制來協商對子樹的所有權，以及通過分布式事務來實作跨子樹的原子重命名，這些實作起來都是非常復雜的，目前最新的官方檔案仍然不推薦使用多個 MDS（作為備份是可以的），

GFS

Google 的 GFS 是分布式檔案系統中的先驅和典型代表，由早期的 BigFiles 發展而來，在 2003 年發表的論文中詳細闡述了它的設計理念和細節，對業界影響非常大，后來很多分布式檔案系統都是參照它的設計，

顧名思義，BigFiles/GFS 是為大檔案優化設計的，并不適合平均檔案大小在 1MB 以內的場景，GFS的架構入下圖所示：

GFS 有一個 Master 節點來管理元資料（全部加載到記憶體，快照和更新日志寫到磁盤），檔案劃分成 64MB 的 Chunk 存盤到幾個 ChunkServer 上（直接使用單機檔案系統），檔案只能追加寫，不用擔心 Chunk 的版本和一致性問題（可以用長度當做版本），這個使用完全不同的技術來解決元資料和資料的設計使得系統的復雜度大大簡化，也有足夠的擴展能力（如果平均檔案大小大于 256MB，Master 節點每 GB 記憶體可以支撐約 1PB 的資料量），放棄支持 POSIX 檔案系統的部分功能（比如隨機寫、擴展屬性、硬鏈接等）也進一步簡化了系統復雜度，以換取更好的系統性能、魯棒性和可擴展性，

因為 GFS 的成熟穩定，使得 Google 可以更容易地構建上層應用（MapReduce、BigTable等），后來，Google 開發了擁有更強可擴展能力的下一代存盤系統 Colossus，把元資料和資料存盤徹底分離，實作了元資料的分布式（自動 Sharding），以及使用Reed Solomon 編碼來降低存盤空間占用從而降低成本，

HDFS

出自 Yahoo 的 Hadoop 算是 Google 的 GFS、MapReduce 等的開源Java實作版，HDFS 也是基本照搬 GFS 的設計，這里就不再重復了，下圖是HDFS的架構圖：

HDFS的可靠性和可擴展能力還是非常不錯的，有不少幾千節點和 100PB 級別的部署，支撐大資料應用表現還是很不錯的，少有聽說丟資料的案例（因為沒有配置回收站導致資料被誤刪的除外），

HDFS 的 HA 方案是后來補上的，做得比較復雜，以至于最早做這個 HA 方案的 Facebook 在很長一段時間（至少 3 年）內都是手動做故障切換（不信任自動故障切換），

因為 NameNode 是 Java 實作的，依賴于預先分配的堆記憶體大小，分配不足容易觸發 Full GC 而影響整個系統的性能，有一些團隊嘗試把它用 C++ 重寫了，但還沒看到有成熟的開源方案，

HDFS 也缺乏成熟的非 Java 客戶端，使得大資料（Hadoop等工具）以外的場景（比如深度學習等）使用起來不太方便，

MooseFS

MooseFS 是來自波蘭的開源分布式 POSIX 檔案系統，也是參照了 GFS 的架構，實作了絕大部分 POSIX 語意和 API，通過一個非常成熟的 FUSE 客戶端掛載后可以像本地檔案系統一樣訪問，MooseFS 的架構如下圖所示：

MooseFS 支持快照，用它來做資料備份或者備份恢復等還是恢復方便的，

MooseFS 是由 C 實作的，Master 是個異步事件驅動的單執行緒，類似于 Redis，不過網路部分使用的是 poll 而不是更高效的 epoll，導致并發到 1000 左右時 CPU 消耗非常厲害，

開源的社區版沒有HA，是通過 metalogger 來實作異步冷備，閉源的收費版有 HA，

為了支持隨機寫操作，MooseFS 中的 chunk 是可以修改的，通過一套版本管理機制來保證資料一致性，這個機制比較復雜容易出現詭異問題（比如集群重啟后可能會有少數 chunk 實際副本數低于預期），

JuiceFS

上面說的 GFS、HDFS 和 MooseFS 都是針對自建機房這種軟硬體環境設計的，將資料的可靠性和節點可用性合在一起用多機多副本的方式解決，但是在公有云或者私有云的虛擬機里，塊設備已經是具有三副本可靠性設計的虛擬塊設備，如果再通過多機多副本的方式來做，會導致資料的成本居高不下（實際上是 9 個拷貝），

于是我們針對公有云，改進 HDFS 和 MooseFS 的架構，設計了 JuiceFS，架構如下圖所示：

JuiceFS 使用公有云中已有的物件存盤來替換 DataNode 和 ChunkServer，實作一個完全彈性的 Serverless 的存盤系統，公有云的物件存盤已經很好地解決了大規模資料的安全高效存盤，JuiceFS 只需要專注元資料的管理，也大大降低了元資料服務的復雜度（GFS 和 MooseFS 的 master 要同時解決元資料的存盤和資料塊的健康管理），我們也對元資料部分做了很多改進，從一開始就實作了基于 Raft 的高可用，要真正提供一個高可用高性能的服務，元資料的管理和運維仍然是很有挑戰的，元資料是以服務的形式提供給用戶，因為 POSIX 檔案系統 API 是應用最最廣泛的 API，我們基于 FUSE 實作了高度 POSIX 兼容的客戶端，用戶可以通過一個命令列工具把 JuiceFS 掛載到 Linux 或者 macOS 中，像本地檔案系統一樣快速訪問，

上圖中右邊虛線部分是負責資料存盤和訪問的部分，涉及用戶的資料隱私，它們是完全在客戶自己的賬號和網路環境中，不會跟元資料服務接觸，我們（Juicedata）沒有任何方法接觸到客戶的內容（元資料除外，請不要把敏感內容放到檔案名里），

小結

簡要介紹了下我所了解的幾個分布式檔案系統的架構，把他們按照出現的時間順序放在下面的圖里（箭頭表示后參考了前者或者是新一代版本）：

上圖中上部分藍色的幾個檔案下主要是給大資料場景使用的，實作的是 POSIX 的子集，而下面綠色的幾個是 POSIX 兼容的檔案系統，

他們中以 GFS 為代表的元資料和資料分離的系統設計能夠有效平衡系統的復雜度，有效解決大規模資料的存盤問題（通常也都是大檔案），有更好的可擴展性，這個架構下支持元資料的分布式存盤的 Colossus 和 WarmStorage 更是具有無限的可擴展能力，

JuiceFS 作為后來者，學習了 MooseFS 實作分布式 POSIX 檔案系統的方式，也學習了 Facebook 的 WarmStorage 等元資料和資料徹底分開的思路，希望為公有云或者私有云等場景下提供最好的分布式存盤體驗，JuiceFS 通過將資料存盤到物件存盤的方式，有效避免了使用以上分布式檔案系統時的雙層冗余（塊存盤的冗余和分布式系統的多機冗余）導致的成本過高問題，JuiceFS 還支持所有的公有云，不用擔心某個云服務鎖定，還能平滑地在公有云或者區之間遷移資料，

推薦閱讀：

如何借助 JuiceFS 為 AI 模型訓練提速 7 倍

標籤：架構設計

上一篇：2021SC@SDUSC amis-低代碼前端框架綜述

下一篇：常見開源分布式檔案系統架構對比