AI 模型的訓(xùn)練與推理對存儲系統(tǒng)提出了極為嚴(yán)苛的要求，特別是在高吞吐、高并發(fā)以及對海量小文件的高效處理方面，已成為三大主要挑戰(zhàn)。盡管基于 Lustre 或 GPFS 的并行文件系統(tǒng)具備出色的性能，但其成本高昂、吞吐能力與容量強(qiáng)耦合，可能導(dǎo)致硬件資源的浪費(fèi)。隨著數(shù)據(jù)規(guī)模的急劇增長，這些問題變得更加突出。

我們將通過一個客戶從并行文件系統(tǒng)架構(gòu)遷移至 JuiceFS 的案例，同時利用其閑置資源打造 70GB/s 吞吐，360 TB 緩存池的案例，深入探討 JuiceFS 如何實(shí)現(xiàn)高效的數(shù)據(jù)處理、低成本存儲與靈活的擴(kuò)展能力。

01 早期存儲架構(gòu)：資源利用不足與高昂的成本

該客戶是一家從事大語言模型訓(xùn)練的企業(yè)，數(shù)據(jù)存儲在 AWS S3 上，最初通過 AWS FSx for Lustre 提供的并行文件系統(tǒng)訪問數(shù)據(jù)，確保計(jì)算資源能夠高效地訪問存儲在 S3 中的數(shù)據(jù)。FSx 和類似的并行文件系統(tǒng)，如阿里云 CPFS、火山引擎 vePFS 通常提供協(xié)議轉(zhuǎn)換、緩存加速以及文件生命周期管理這些功能。

為了支撐大規(guī)模的數(shù)據(jù)處理和計(jì)算，客戶采購了多臺裸金屬服務(wù)器，每臺配備了大量的本地 NVMe 磁盤。然而，這些磁盤長時間處于閑置狀態(tài)，造成了資源浪費(fèi)。

盡管并行文件系統(tǒng)具有優(yōu)異的性能，但其成本較高，并且吞吐性能與存儲容量緊密相關(guān)。如果要獲得更高的吞吐，必須購買更大容量的存儲，這導(dǎo)致了開銷的增加。考慮到未來數(shù)據(jù)量的增長，繼續(xù)擴(kuò)展該系統(tǒng)將帶來巨大的成本壓力。

02 引入 JuiceFS 后的新架構(gòu)：提升高吞吐與擴(kuò)展性

在經(jīng)過充分的技術(shù)選型和評估后，該客戶決定從原有架構(gòu)遷移到 JuiceFS，以更好地滿足其高吞吐量和擴(kuò)展性需求。

JuiceFS 架構(gòu)特點(diǎn)

JuiceFS 采用數(shù)據(jù)和元數(shù)據(jù)分離的架構(gòu)，數(shù)據(jù)存儲于對象存儲。企業(yè)版通過 Raft 協(xié)議構(gòu)建元數(shù)據(jù)集群，社區(qū)版則支持 Redis、TiKV 等數(shù)據(jù)庫作為元數(shù)據(jù)引擎。

為了提高性能，JuiceFS 將數(shù)據(jù)切塊，每次更新限制為最小的 4MB，從而大幅減少文件寫入的浪費(fèi)，顯著提升了在對象存儲上的寫入效率。初次使用 JuiceFS 的用戶可能會擔(dān)心，數(shù)據(jù)切塊后是否會影響文件的可用性，或是脫離 JuiceFS 產(chǎn)品后，JuiceFS 的分塊格式無法被正常讀取，造成產(chǎn)品的強(qiáng)綁定。事實(shí)上，JuiceFS 設(shè)計(jì)將對象存儲視作本地磁盤使用，避免了與文件系統(tǒng)的緊密耦合，同時解決了對象存儲在隨機(jī)寫入效率上的瓶頸。此外，JuiceFS 提供接口支持輕松將數(shù)據(jù)遷移回 S3 對象存儲，避免了對特定存儲產(chǎn)品的依賴。

部署方案

與之前的托管文件系統(tǒng)集中式的架構(gòu)不同，基于 JuiceFS 的新架構(gòu)利用每個業(yè)務(wù)節(jié)點(diǎn)上的客戶端來提供協(xié)議轉(zhuǎn)換和緩存加速功能。無論是通過 JuiceFS CSI 與 Kubernetes 集成，還是直接通過主機(jī)訪問，部署完成后，業(yè)務(wù)節(jié)點(diǎn)便能高效地訪問元數(shù)據(jù)和對象存儲，極大提升了存儲系統(tǒng)的性能與靈活性。這種架構(gòu)的優(yōu)勢在于，可以靈活地擴(kuò)展系統(tǒng)，避免單點(diǎn)故障，同時提升存儲和計(jì)算資源的利用效率。

此外，JuiceFS 能夠充分利用閑置硬件資源，如 NVMe 本地磁盤和內(nèi)存。JuiceFS 將這些閑置磁盤整合為一個分布式緩存池，從而提升緩存性能和吞吐能力。對于社區(qū)版用戶，可以將緩存目錄設(shè)置到分布式文件系統(tǒng)中，如 BeeGFS 等，以構(gòu)建分布式緩存層。

最終，使用 JuiceFS，該客戶構(gòu)建了一個 360TB 的分布式緩存池，6 臺服務(wù)器提供了 600Gbps 的聚合帶寬，該緩存池的瞬時吞吐已達(dá)到 10GB/s，JuiceFS 在 TCP 網(wǎng)絡(luò)利用率方面表現(xiàn)出色，100Gbps 以下帶寬的利用率可達(dá) 95%。若 GPU 節(jié)點(diǎn)沒有額外磁盤資源，也可利用內(nèi)存來構(gòu)建緩存池。

03 JuiceFS 讀性能測試

為了評估和展示 JuiceFS 使用分布式緩存后的讀性能，我們進(jìn)行了內(nèi)部測試，使用了 JuiceFS 企業(yè)版 5.2，測試大文件順序讀性能。

測試結(jié)果顯示，在 100 臺機(jī)器聚合成的 10Tbps 網(wǎng)絡(luò)環(huán)境下，JuiceFS 分布式緩存的聚合吞吐量達(dá)到了 1.23 TB/s，證明在 100Gbps TCP 網(wǎng)絡(luò)條件下，網(wǎng)絡(luò)利用率可達(dá)到 95%以上；即使在 200Gbps 網(wǎng)絡(luò)下，利用率也可達(dá)到約 70%。本次測試使用 100Gbps 網(wǎng)卡，在 TCP 環(huán)境下成功實(shí)現(xiàn)了較高的整體聚合吞吐率。

在測試過程中，我們結(jié)合了磁盤和內(nèi)存資源，確保充分利用 100Gbps 網(wǎng)卡的帶寬上限，達(dá)到每秒 12.5GB 的吞吐量。

在緩存服務(wù)節(jié)點(diǎn)的測試中，每秒從本地磁盤讀取 11GB 數(shù)據(jù)并通過網(wǎng)絡(luò)傳輸?shù)较M(fèi)節(jié)點(diǎn)時，CPU 消耗不到一個核，平均每提供 10GB/s 帶寬，僅消耗一個核。

在客戶端節(jié)點(diǎn)方面，每 GB/s 的讀取僅消耗 0.8 個 CPU 核。如果要充分利用 100Gbps 網(wǎng)卡帶寬，使用 JuiceFS FUSE 客戶端存儲需占用 10 個 CPU 核。TCP 網(wǎng)絡(luò)對用戶來說應(yīng)用更為廣泛，因此，基于 TCP 網(wǎng)絡(luò) 的優(yōu)化方案能夠廣泛適用于多種場景，滿足不同需求。

04 總結(jié)

本文介紹了 JuiceFS 在 AI 訓(xùn)練與推理場景中的應(yīng)用。在這些場景中，雖然延遲和 IOPS 重要，但吞吐性能和性價比同樣不可忽視。針對傳統(tǒng)并行文件系統(tǒng)（PFS）成本高且吞吐量與存儲容量綁定的問題，JuiceFS 提供了一種低成本、高效益的解決方案。其通過數(shù)據(jù)與元數(shù)據(jù)分離的架構(gòu)，能夠?qū)I(yè)務(wù)節(jié)點(diǎn)上的閑置磁盤、內(nèi)存和網(wǎng)絡(luò)資源池化，按需構(gòu)建高性能的分布式緩存集群，避免了容量綁定的限制。如文中案例所示，采用該方案能夠?qū)⒋鎯倱碛谐杀窘档徒叮瑫r實(shí)現(xiàn)高達(dá) TB/s 級別的吞吐量，并保持較低的客戶端 CPU 開銷。