在 AI 模型訓(xùn)練、高性能計(jì)算等對 I/O 敏感的場景中，底層文件系統(tǒng)的架構(gòu)和性能將直接影響訓(xùn)練效率、資源利用率與整體成本。

Lustre 作為傳統(tǒng)高性能文件系統(tǒng)，以極致性能著稱；而 JuiceFS 則以云原生設(shè)計(jì)和對象存儲集成為核心，提供更高的部署靈活性與經(jīng)濟(jì)性。為了幫助用戶深入理解這兩類系統(tǒng)在架構(gòu)實(shí)現(xiàn)、性能優(yōu)化和運(yùn)維復(fù)雜度上的差異，我們撰寫了這篇對比文章，供技術(shù)選型時(shí)參考。

01 架構(gòu)對比

Lustre

Lustre 是一款專為高性能計(jì)算（HPC）環(huán)境設(shè)計(jì)的并行分布式文件系統(tǒng)，最初在美國政府資助下，由多個(gè)國家實(shí)驗(yàn)室聯(lián)合開發(fā)，旨在支持大規(guī)模科學(xué)研究和工程計(jì)算任務(wù)。當(dāng)前，Lustre 的主要開發(fā)與維護(hù)由 DDN（DataDirect Networks） 負(fù)責(zé)，廣泛應(yīng)用于超算中心、科研機(jī)構(gòu)及企業(yè)級 HPC 集群中。Lustre 文件系統(tǒng)由以下幾個(gè)核心模塊組成：

• 元數(shù)據(jù)服務(wù)器（Metadata Servers，MDS）：負(fù)責(zé)處理命名空間相關(guān)操作，如文件創(chuàng)建、刪除、權(quán)限檢查等。
• 對象存儲服務(wù)器（Object Storage Servers，OSS）：負(fù)責(zé)實(shí)際的數(shù)據(jù)讀寫，提供高性能的大規(guī)模 I/O 服務(wù)。
• 管理服務(wù)器（Management Server，MGS）：作為全局配置注冊中心，負(fù)責(zé)存儲和分發(fā) Lustre 文件系統(tǒng)的配置信息。MGS 在功能上獨(dú)立于具體的 Lustre 實(shí)例。
• 客戶端（Client）：為用戶應(yīng)用程序提供訪問 Lustre 文件系統(tǒng)的接口，實(shí)現(xiàn)標(biāo)準(zhǔn)的 POSIX 文件操作語義。

各組件通過 Lustre 專用的網(wǎng)絡(luò)協(xié)議 LNet 連接，構(gòu)成一個(gè)統(tǒng)一高效的文件系統(tǒng)整體。

JuiceFS

JuiceFS 是一個(gè)云原生分布式文件系統(tǒng)，其數(shù)據(jù)存儲在對象存儲中。社區(qū)版可與多種元數(shù)據(jù)服務(wù)集成，適用場景廣泛，于 2021 年在 GitHub 開源（11.6K star）。企業(yè)版專為高性能場景設(shè)計(jì)，廣泛應(yīng)用于大規(guī)模 AI 任務(wù)，涵蓋生成式 AI、自動駕駛、量化金融和生物科技等。

JuiceFS 文件系統(tǒng)包括三部分組成：

• 元數(shù)據(jù)引擎：用于存儲文件元數(shù)據(jù)，包括常規(guī)文件系統(tǒng)的元數(shù)據(jù)和文件數(shù)據(jù)的索引。
• 數(shù)據(jù)存儲：一般是對象存儲服務(wù)，可以是公有云的對象存儲也可以是私有部署的對象存儲服務(wù)。
• 客戶端：提供 POSIX（FUSE）、Hadoop SDK、CSI Driver、S3 網(wǎng)關(guān)等不同的接入方式。

架構(gòu)差異

可以看出，Lustre 和 JuiceFS 在模塊組成及功能劃分上較為相似，但在具體實(shí)現(xiàn)上存在較大差異。

客戶端

Lustre 采用 C 語言實(shí)現(xiàn)，其客戶端模塊運(yùn)行在內(nèi)核態(tài)；而 JuiceFS 使用 Go 語言開發(fā)，客戶端通過 FUSE（Filesystem in Userspace）暴露文件系統(tǒng)接口，運(yùn)行在用戶態(tài)。由于 Lustre 客戶端運(yùn)行于內(nèi)核空間，訪問元數(shù)據(jù)服務(wù)器（MDS）或?qū)ο蟠鎯Ψ?wù)器（OSS）時(shí)無需進(jìn)行用戶態(tài)與內(nèi)核態(tài)的上下文切換或額外的內(nèi)存拷貝，從而顯著減少了系統(tǒng)調(diào)用所帶來的性能開銷，在吞吐和延遲方面具備一定優(yōu)勢。

然而，內(nèi)核態(tài)實(shí)現(xiàn)也帶來了運(yùn)維和調(diào)試的復(fù)雜性。相比用戶態(tài)的開發(fā)環(huán)境和調(diào)試工具，內(nèi)核態(tài)工具門檻更高，不易為普通開發(fā)者所掌握。同時(shí)，與 C 語言相比，Go 語言更易于學(xué)習(xí)、維護(hù)和開發(fā)，具備更高的開發(fā)效率和可維護(hù)性。

值得注意的是，JuiceFS 企業(yè)版 5.2 中引入零拷貝等技術(shù)優(yōu)化，以減少系統(tǒng)調(diào)用開銷，進(jìn)一步提升性能。

存儲模塊

在數(shù)據(jù)存儲方面，Lustre 和 JuiceFS 也采用了不同的實(shí)現(xiàn)方式。

Lustre 在部署時(shí)通常需要配置一塊或多塊共享磁盤來存儲文件數(shù)據(jù)。這一設(shè)計(jì)源于其早期版本尚不支持文件級冗余（ File Level Redundancy，F(xiàn)LR）。為了實(shí)現(xiàn)高可用性（HA），當(dāng)某個(gè)節(jié)點(diǎn)下線時(shí)，必須將其文件系統(tǒng)掛載（mount）到對等節(jié)點(diǎn)（peer node），否則該節(jié)點(diǎn)上的數(shù)據(jù)塊（Chunk）將不可訪問。因此，數(shù)據(jù)的可靠性需依賴于共享存儲本身的高可用機(jī)制，或用戶自行配置的軟件 RAID 實(shí)現(xiàn)。

為確保高可用性和數(shù)據(jù)一致性正常運(yùn)行，部署 Lustre 前通常需要進(jìn)行詳細(xì)的規(guī)劃。盡管，新版本的 Lustre 已支持 FLR，一個(gè)文件可以具有多個(gè)副本，但副本之間的數(shù)據(jù)一致性仍需通過手動命令進(jìn)行同步和確認(rèn)。此外，Lustre 支持使用 ldiskfs 或 ZFS 作為底層本地文件系統(tǒng)，因此使用 Lustre 時(shí)還需了解并配置相應(yīng)的本地文件系統(tǒng)。

JuiceFS 利用對象存儲作為數(shù)據(jù)存儲解決方案，從而可享有對象存儲帶來的若干優(yōu)勢，如數(shù)據(jù)可靠性、一致性等。存儲模塊提供了一組用于對象操作的接口，包括 GET/PUT/HEAD/LIST 等，用戶可以根據(jù)自己的需求對接具體的存儲系統(tǒng)，既包括主流云廠商的對象存儲，也支持如 MinIO、Ceph RADOS 等私有部署的對象存儲系統(tǒng)。社區(qū)版 JuiceFS 提供本地緩存來應(yīng)對 AI 場景下的帶寬需求，JuiceFS 企業(yè)版使用分布式緩存滿足更大的聚合讀帶寬的需求。

元數(shù)據(jù)模塊

在元數(shù)據(jù)服務(wù)方面，Lustre 和 JuiceFS 都提供統(tǒng)一的命名空間和文件元數(shù)據(jù)管理功能。為了實(shí)現(xiàn)元數(shù)據(jù)訪問負(fù)載的橫向擴(kuò)展，Lustre 自 2.4 版本起引入了 Distributed Namespace（DNE）功能，支持將單個(gè)文件系統(tǒng)的不同目錄分布在多個(gè)元數(shù)據(jù)服務(wù)器（MDS）上。

Lustre 的 MDS 高可用性依賴于軟硬件協(xié)同實(shí)現(xiàn)：

• 硬件層面：MDS 使用的磁盤需配置 RAID，以避免因單點(diǎn)磁盤故障導(dǎo)致服務(wù)不可用；磁盤也需具備共享能力，以便當(dāng)主節(jié)點(diǎn)宕機(jī)時(shí)，備節(jié)點(diǎn)能接管磁盤資源。
• 軟件層面：使用 Pacemaker 與 Corosync 構(gòu)建高可用集群，確保任一時(shí)刻僅有一個(gè) MDS 實(shí)例處于活動狀態(tài)。

JuiceFS 社區(qū)版的元數(shù)據(jù)模塊，與存儲模塊類似也提供一組操作元數(shù)據(jù)的接口，可以接入不同的元數(shù)據(jù)服務(wù)，包括 Redis，TiKV ，MySQL，PostgreSQL ， FoundationDB 等不同類型的數(shù)據(jù)庫。

JuiceFS 企業(yè)版使用自研高性能元數(shù)據(jù)服務(wù)，可根據(jù)負(fù)載情況來平衡數(shù)據(jù)和熱點(diǎn)操作，以避免大規(guī)模訓(xùn)練中元數(shù)據(jù)服務(wù)熱點(diǎn)集中在某些節(jié)點(diǎn)的問題（比如頻繁操作臨近目錄文件的元數(shù)據(jù)）。目前，企業(yè)版支持的數(shù)據(jù)規(guī)模已達(dá)到千億級別，更多技術(shù)細(xì)節(jié)請點(diǎn)擊此處閱讀。

02 文件分布對比

Lustre文件分布

Normal File Layout

Lustre 早期采用的文件分布方式被稱為 Normal File Layouts。在該模式下，文件被切分為多個(gè)數(shù)據(jù)塊（Chunk），并分別存儲在多個(gè)對象存儲目標(biāo)（Object Storage Targets，OSTs）上，其策略類似于 RAID 0。

文件分布策略主要由以下兩個(gè)參數(shù)控制：

• Stripe Count：指定文件可以同時(shí)分布到多少個(gè) OST 上。該值越大，文件并行訪問能力越強(qiáng)，但也可能帶來額外的調(diào)度和管理開銷。
• Stripe Size：定義在切換到下一個(gè) OST 之前，每個(gè)數(shù)據(jù)塊的大小。也就是說，寫入達(dá)到設(shè)定的 Stripe Size 后，數(shù)據(jù)將被寫入下一個(gè) OST，這也決定了每個(gè) Chunk 的粒度。

通過合理配置這兩個(gè)參數(shù)，用戶可以在性能與資源利用之間做出權(quán)衡，優(yōu)化文件系統(tǒng)的 I/O 行為以適配具體的應(yīng)用場景。

上圖展示了一個(gè) Stripe Count 為 3、Stripe Size 為 1?MB 的文件在多個(gè) OST 上的分布方式。每個(gè)數(shù)據(jù)塊（Stripe）采用輪詢（Round-Robin）方式依次分布到不同的 OST 上。

這種文件布局方式的主要問題在于參數(shù)配置不可變：一旦文件創(chuàng)建，Stripe Count 和 Stripe Size 就無法修改。然而，文件大小在實(shí)際使用中通常是動態(tài)變化的，用戶可以通過追加寫不斷擴(kuò)展文件。這種不靈活的布局策略在實(shí)際場景中容易引發(fā)以下問題：

• 空間耗盡（ENOSPC）：由于每個(gè)文件的 Stripe 固定分布在特定的 OST 上，當(dāng)某個(gè) OST 空間耗盡時(shí)，即便其他 OST 仍有剩余空間，也會導(dǎo)致整個(gè)文件寫入失敗。
• 磁盤使用不均衡：即使初始寫入時(shí)文件數(shù)據(jù)在 OST 之間分布均勻，隨著不同文件在不同時(shí)段被追加寫入，各個(gè) OST 的使用增長速率會出現(xiàn)差異，導(dǎo)致磁盤空間不平衡。一旦形成不均衡狀態(tài)，由于文件分布不能更改，這種狀態(tài)將長期存在并持續(xù)惡化。

因此，在大規(guī)模、動態(tài)增長的數(shù)據(jù)場景中，Normal File Layouts 的靜態(tài)分布策略在靈活性和資源利用率方面存在明顯限制。

Progressive File Layouts

為了解決 Normal File Layouts 在應(yīng)對動態(tài)數(shù)據(jù)增長和資源分配方面存在的局限，Lustre 引入了一種新的文件分布機(jī)制，稱為 Progressive File Layouts（PFL）。

PFL 支持為同一個(gè)文件的不同區(qū)段定義不同的布局策略，允許根據(jù)文件大小或訪問模式的變化進(jìn)行靈活的分布控制。通過配置多個(gè)布局段（Extent），用戶可以為文件的不同范圍指定不同的 Stripe Count 和 Stripe Size，從而實(shí)現(xiàn)更加合理的資源利用和負(fù)載分擔(dān)。

這種機(jī)制具備以下優(yōu)勢：

• 動態(tài)適應(yīng)文件增長：小文件可以使用較小的 Stripe Count 降低訪問開銷，而隨著文件變大，可以啟用更高的并發(fā)度以提升帶寬利用率。
• 減緩磁盤不均衡問題：通過為文件的后續(xù)部分指定不同的 OST 分布策略，可以在一定程度上緩解因追加寫入導(dǎo)致的磁盤負(fù)載不均。
• 提高空間利用率和靈活性：PFL 支持自動選擇布局段，使得布局策略可以隨文件內(nèi)容增長而自動調(diào)整，無需用戶手動干預(yù)。

相較于傳統(tǒng)布局模式，PFL 更適用于需要高性能訪問的大型文件場景。

如上圖所示，該文件采用 Progressive File Layouts（PFL）進(jìn)行分布，共分為三個(gè)布局段（Extent）：

• 第一部分：Stripe Size 為 1?MB，Stripe Count 為 1，用于優(yōu)化小文件或文件開頭部分的訪問效率；
• 第二部分：Stripe Count 提升至 4，提高并發(fā) I/O 能力；
• 第三部分：Stripe Size 增加至 4?MB，Stripe Count 為 16，適用于大文件高吞吐量的訪問需求。

盡管 PFL 引入了更具彈性的布局策略，但在實(shí)際運(yùn)行中，仍無法完全解決磁盤使用不均衡問題。為此，Lustre 進(jìn)一步結(jié)合 Lazy Initialization 技術(shù)，以實(shí)現(xiàn)更高效的資源調(diào)度。

Lazy Initialization 是一種延遲分配機(jī)制，指的是文件在首次寫入前不分配實(shí)際的物理存儲位置。結(jié)合該機(jī)制，系統(tǒng)可在檢測到磁盤負(fù)載不均時(shí)，針對尚未分配的文件區(qū)域動態(tài)指定新的分布策略，將這些數(shù)據(jù)寫入負(fù)載較輕的 OST 上。

通過 PFL + Lazy Initialization 的聯(lián)合使用，Lustre 實(shí)現(xiàn)了更具適應(yīng)性的 I/O 分布能力，顯著緩解了由于追加寫入或文件增長帶來的磁盤空間不均衡問題，同時(shí)提升了系統(tǒng)的可維護(hù)性與數(shù)據(jù)分布的靈活性。

File Level Redundancy

如前文所述，Lustre 在實(shí)現(xiàn)高可用性（HA）時(shí)的部署和運(yùn)維流程相對復(fù)雜。為簡化 HA 架構(gòu)并提升系統(tǒng)容錯(cuò)能力，社區(qū)提出了 File Level Redundancy（FLR） 機(jī)制。

FLR 允許為每個(gè)文件配置一個(gè)或多個(gè)副本（Replica），實(shí)現(xiàn)文件級別的冗余保護(hù)。在寫入操作發(fā)生時(shí)，數(shù)據(jù)僅寫入其中一個(gè)副本，其余副本會被標(biāo)記為 STALE（過期）。隨后，系統(tǒng)通過一個(gè)稱為 Resync 的同步過程，將最新數(shù)據(jù)復(fù)制到所有 STALE 副本中，以確保數(shù)據(jù)一致性。

在讀取操作中，任何包含最新數(shù)據(jù)的副本都可以作為數(shù)據(jù)源，提高了讀性能的并發(fā)性和容錯(cuò)能力。

這種機(jī)制 在不依賴共享存儲或底層 RAID 的情況下，為 Lustre 提供了一種更加靈活和易于維護(hù)的數(shù)據(jù)冗余方案，適用于對高可用性有更高要求的大規(guī)模分布式環(huán)境。

JuiceFS 文件分布

JuiceFS 按照 Chunk、Slice、Block 的規(guī)則進(jìn)行數(shù)據(jù)塊管理。每個(gè) Chunk 的大小固定為 64M，主要用于優(yōu)化數(shù)據(jù)的查找和定位。實(shí)際的文件寫入操作則在 Slice 上執(zhí)行，每個(gè) Slice 代表一次連續(xù)的寫入過程，屬于特定的 Chunk，并且不會跨越 Chunk 的邊界，因此長度不超過 64M。Chunk 和 Slice 主要是邏輯上的劃分，而 Block（默認(rèn)大小為 4M）則是物理存儲的基本單位，用于在對象存儲和磁盤緩存中實(shí)現(xiàn)數(shù)據(jù)的最終存儲。更多細(xì)節(jié)可以參考官網(wǎng)介紹。

JuiceFS 中的 Slice 是在其他文件系統(tǒng)中不常見的一個(gè)結(jié)構(gòu)。主要功能是記錄文件的寫入操作，并在對象存儲中進(jìn)行持久化。對象存儲不支持原地文件修改，因此，JuiceFS 通過引入 Slice 結(jié)構(gòu)允許更新文件內(nèi)容，而無需重寫整個(gè)文件。這與 Journal File System 有些類似，其中寫入操作僅創(chuàng)建新對象，而不是覆蓋現(xiàn)有對象。修改文件時(shí)，系統(tǒng)會創(chuàng)建新的 Slice，并在該 Slice 上傳完畢后更新元數(shù)據(jù)，從而將文件內(nèi)容指向新的 Slice。被覆蓋的 Slice 內(nèi)容隨后通過異步壓縮過程從對象存儲中刪除，導(dǎo)致在某些時(shí)刻對象存儲的使用量會暫時(shí)超過文件系統(tǒng)實(shí)際使用量。

此外，JuiceFS 的所有 Slice 均為一次性寫入，這減少了對底層對象存儲一致性的依賴，并大大簡化了緩存系統(tǒng)的復(fù)雜度，使數(shù)據(jù)一致性更易于保證。這種設(shè)計(jì)還為實(shí)現(xiàn)文件系統(tǒng)的零拷貝語義提供了便利，支持如 copy_file_range 和 clone 等操作。

03 功能特性對比

04 小結(jié)

Lustre 是一款高性能并行分布式文件系統(tǒng)，客戶端運(yùn)行于內(nèi)核態(tài)，直接與元數(shù)據(jù)服務(wù)器（MDS）和對象存儲服務(wù)器（OSS）交互，避免了用戶態(tài)與內(nèi)核態(tài)之間的上下文切換。結(jié)合高性能存儲設(shè)備，Lustre 在高帶寬 I/O 場景下展現(xiàn)出卓越的性能。

然而，由于客戶端運(yùn)行在內(nèi)核態(tài)，這使得運(yùn)維過程更具挑戰(zhàn)性，運(yùn)維團(tuán)隊(duì)需具備深入的內(nèi)核調(diào)試經(jīng)驗(yàn)和底層系統(tǒng)故障排查能力。此外，由于 Lustre 使用固定容量的存儲方案，文件分布設(shè)計(jì)相對復(fù)雜，需要精細(xì)的規(guī)劃與配置來實(shí)現(xiàn)資源的高效利用。因此，Lustre 的部署和運(yùn)維門檻較高。

JuiceFS 是一款云原生、用戶態(tài)分布式文件系統(tǒng)，緊密集成對象存儲，并原生支持 Kubernetes CSI（Container Storage Interface），從而簡化了在云平臺上的部署和運(yùn)維。用戶無需深入關(guān)注底層存儲設(shè)備和復(fù)雜的存儲調(diào)度機(jī)制，即可在容器化環(huán)境中實(shí)現(xiàn)彈性擴(kuò)展、高可用數(shù)據(jù)服務(wù)。在性能方面，JuiceFS 企業(yè)版通過分布式緩存，有效降低對象存儲的訪問延遲，提升文件操作的響應(yīng)速度。

從成本角度看，Lustre 需要依賴高性能的專用存儲設(shè)備，初始投資和長期維護(hù)成本較高。對象存儲相則更加經(jīng)濟(jì)，具備天然的可擴(kuò)展性以及按需付費(fèi)的靈活性。

希望這篇內(nèi)容能夠?qū)δ阌幸恍椭?，如果有其他疑問歡迎加入 JuiceFS 社區(qū)與大家共同交流。