伴隨著公司業(yè)務(wù)的發(fā)展，數(shù)據(jù)量持續(xù)增長，存儲平臺面臨新的挑戰(zhàn)：大圖片的高吞吐、超分辨率場景下數(shù)千萬小文件的 IOPS 問題、運維復(fù)雜等問題。除了這些技術(shù)難題，我們基礎(chǔ)團隊的人員也比較緊張，負責(zé)存儲層運維的僅有 1 名同事，因而組件的易用性，一直也是我們評估的重要維度。

我們嘗試過文件系統(tǒng)包括有 NFS、GlusterFS、Lustre 和 CephFS，最終選擇了JuiceFS。在這個案例中，我們將為大家介紹工業(yè) AI 平臺的存儲層的挑戰(zhàn)有哪些、 JuiceFS 的應(yīng)用場景、大規(guī)模數(shù)據(jù)場景為什么使用 SeaweedFS？以及 JuiceFS CSI Driver 使用中遇到的問題。希望這些分享能給社區(qū)用戶提供一些選型和運維方面的參考。

01 AI 訓(xùn)練平臺的存儲挑戰(zhàn)

思謀科技的業(yè)務(wù)主要面向工業(yè)場景，涵蓋工業(yè)質(zhì)檢、智能制造和流程優(yōu)化等領(lǐng)域。我們的團隊主要負責(zé) AI 平臺的訓(xùn)練場景，并為所有業(yè)務(wù)線提供訓(xùn)練平臺支持。我們管理整個公司的 GPU 訓(xùn)練集群。平臺中處理的數(shù)據(jù)有如下特點：

• 單個項目的數(shù)據(jù)量很小，緩存收益高，優(yōu)選帶緩存的文件系統(tǒng)。在工業(yè)場景中，與人臉識別或自然語言處理等場景相比，數(shù)據(jù)量小。一個客戶可能只提供了幾百張圖像，我們需要利用這些圖像來迭代出模型。項目圖片少，就有利于我們做本地緩存，所以支持本地緩存的文件系統(tǒng) JuiceFS，BeeGFS 等，在我們的首要選擇列表里。

• 圖像大小沒有統(tǒng)一的規(guī)格，大小文件均存在。由于我們處于工業(yè)場景，不同的工廠、產(chǎn)線與相機產(chǎn)生的圖片是千差萬別的。例如，我們使用線掃描相機收集的圖片、或者 BMP 格式的圖像大小很大，幾百MB甚至GB，而其他相機拍攝的視頻或照片可能只有幾k大小。所以我們既要面臨大文件的吞吐問題，還要面臨海量小文件的 IOPS 問題。

• 數(shù)據(jù)量與文件數(shù)增長速度非?？?#xff0c;元數(shù)據(jù)壓力大。我們曾與產(chǎn)品經(jīng)理進行容量預(yù)估，發(fā)現(xiàn)一個項目在短短一周內(nèi)就需要處理幾十T的數(shù)據(jù)務(wù)。另一個場景，超分辨率領(lǐng)域的數(shù)據(jù)集具有一個典型的特點，即將視頻轉(zhuǎn)化為圖片。因此一個視頻可能會生成上百萬、上千萬個文件，文件個數(shù)非常大。文件個數(shù)對于文件系統(tǒng)元數(shù)據(jù)壓力也很大。因此，我們訓(xùn)練平臺對存儲平臺的容量，以及元數(shù)據(jù)長時間臨界狀態(tài)的穩(wěn)定性有很高的要求。

• 同時，由于我們是自建IDC，沒有使用云，所以存儲系統(tǒng)運維與擴容是否便捷，也是我們的首要考慮點。

02 存儲選型：不只是功能與性能

為了解決上述問題，我們對一些文件系統(tǒng)進行了評估，包括 NFS、GlusterFS、Lustre 和 CephFS 等，最終選擇了 JuiceFS。由于我們團隊成員較少且需要快速支持業(yè)務(wù)上線，我們并沒有足夠的時間進行選型驗證和上線周期的評估，我們對于新組件的測試和上線需要更高效快捷。

當(dāng)進行產(chǎn)品選型時，不僅需要評估功能和性能，還需要考慮中長期成本、與業(yè)務(wù)方的溝通等因素，是一個很綜合的復(fù)雜任務(wù)，因此，我們總結(jié)了一些選型經(jīng)驗和教訓(xùn)與大家分享：

• 首先是成本、可靠性和性能之間的權(quán)衡。除非公司有充足的資金，否則只能在成本、可靠性和性能之間盡可能滿足其中兩個因素，而不可能同時滿足三個。在成本受限的情況下，我們建議將數(shù)據(jù)安全性放在高于性能的位置。

  通過維護多個集群的經(jīng)驗，我們得出一個觀點：性能達到可接受水平即可，不必追求過高的性能。我們對存儲總體擁有成本（TCO）的理解是，并非只涉及購買容量和性能方面的價格，而是指越接近資源利用上限的使用，實際持有成本越低?；舜髢r錢，買了很高的性能，但是卻用不上，其實也是一種浪費。

• 第二點，要盡早讓內(nèi)部的用戶接入，因為技術(shù)和業(yè)務(wù)工程師之間存在信息差。舉個例子，我們在上線第一套存儲系統(tǒng)后遇到了大量用戶的投訴。我們最初簡單地理解離線訓(xùn)練任務(wù)，無論是訓(xùn)練任務(wù)還是處理大數(shù)據(jù)，都是為了實現(xiàn)高利用率和高吞吐。然而，實際情況是用戶非常敏感于延遲。任務(wù)完成時間，可以參考網(wǎng)易云音樂AI 的這篇： 《網(wǎng)易云音樂機器學(xué)習(xí)平臺實踐》 。因此，我們建議需要盡早與用戶溝通，了解他們的需求和反饋，以彌補這種信息差。

• 第三點做好平臺一致性，不光是環(huán)境一致性，做好也要做到任務(wù)運行的一致性。舉一個具體例子，大型圖片任務(wù)在網(wǎng)絡(luò)上占用了大部分帶寬（大象流），從而影響了小型圖片任務(wù)的完成時間。即使是相同配置的機器，小圖片任務(wù)完成的時間也會加倍。用戶會抱怨為什么在另一臺機器上只需要3個小時，而在這臺機器上需要6個小時。因此，最好對每個任務(wù)都進行 QOS 等機制的限制，以防止出現(xiàn)該種情況，對用戶造成使用困擾。

• 除了以上三個要點外，還有一些小的注意事項。選擇具備豐富配套工具和良好集成生態(tài)的產(chǎn)品，而不僅僅看文檔的數(shù)量。我們測試了許多商業(yè)存儲，但發(fā)現(xiàn)它們的文檔與其版本也有不匹配的現(xiàn)象。因此，我們更傾向于選擇周邊工具多的產(chǎn)品，例如Debug工具，監(jiān)控工具等，因為相比依賴于他人，自己掌握更為可靠。我們選擇 JuiceFS 的原因之一是它是少數(shù)帶有性能調(diào)試工具的文件系統(tǒng)——JuiceFS stats 與access log 功能。此外，JuiceFS 還對接了持續(xù)剖析平臺 Pyroscope，提供持續(xù)查看垃圾回收時間以及占用內(nèi)存較大的塊的功能，這可能是許多人不常使用但非常實用的功能。

• 與用戶進行溝通時，使用對方易懂的“用戶語言”而非 “技術(shù)語言”。在我們交付產(chǎn)品時，我們提到在 IO Size 256k 的情況下，我們可以實現(xiàn)每秒 5GB 的帶寬，跑滿了網(wǎng)卡上限。然而，實際情況是算法用戶并不清楚這個概念。當(dāng)時我們不知道如何向用戶解釋。后來，是JuiceFS社區(qū)的一篇博客文章：《如何借助 JuiceFS 將 AI 模型訓(xùn)練速度提升 7 倍》，給我們帶來了啟發(fā)。在這篇博客中展示了在 JuiceFS 上使用 ResNet50 模型和 ImageNet 數(shù)據(jù)集進行訓(xùn)練的完成時間，并與其他文件系統(tǒng)進行了對比。這樣的比較，讓算法用戶更容易理解和評估 JuiceFS 的性能。隨后，我們告訴了用戶我們新存儲平臺上，ResNet 50 配合 ImageNet 訓(xùn)練的一些數(shù)據(jù)。在我們提供了這個對比數(shù)據(jù)后，我們與內(nèi)部用戶的溝通變得非常順利，因為算法同學(xué)也希望能夠加速訓(xùn)練過程。更短的訓(xùn)練時長使他們能夠調(diào)整更多參數(shù)、進行更多的嘗試并生成更好的模型。

• 對于一個大平臺，很難在測試場景下模擬所以的使用場景。我們需要先完成，再不斷完善。例如上線后，我們發(fā)現(xiàn)用戶的使用方式并不完全符合我們的預(yù)期，他們不僅僅存儲數(shù)據(jù)集，還將anacond等環(huán)境安裝在存儲系統(tǒng)上。這些庫都是小文件，而是對時延要求特別高，如果沒有緩存到本地，運行性能是無法接受的。而這種場景，在我們測試過程中，是不會考慮到用戶會將環(huán)境安裝到存儲里，因為在我們的思維里，大部分的環(huán)境都應(yīng)該使用容器鏡像。所以，一定要盡早的擴大測試范圍，讓更多的用戶參與測試與實際使用，這樣才能暴露更多的問題。

• 關(guān)于全內(nèi)存元數(shù)據(jù)存儲：如果元數(shù)據(jù)過大，意味著這臺機器很可能無法完成混部。機器的持有成本非常高，同時一定要測試長時間臨界狀態(tài)下的穩(wěn)定性。

03 為什么使用 SeaweedFS 作為 JuiceFS 的底層存儲

在我們的存儲層中，SeaweedFS 也是一個必不可少的重要組件，并且在以往的社區(qū)分享中，對于 SeaweedFS 的介紹比較少，因此在介紹 JuiceFS 的應(yīng)用場景前，我們需要一些篇幅來介紹為什么會引入 SeaweedFS。

• 原因一：我們團隊沒有人具備 Ceph 背景。不同于一些社區(qū)案例，如中國電信選擇的 ceph （電信案例：JuiceFS 在中國電信日均 PB 級數(shù)據(jù)場景的應(yīng)用）。

• 原因二，當(dāng)文件數(shù)量過億，原有 MinIO + JuiceFS 出現(xiàn)性能下降。我們是在 2021 年開始使用 JuiceFS，當(dāng)時底層使用的是 Miinio。但是在海量文件的情況下，在XFS 文件系統(tǒng)文件數(shù)量超過一億時，性能開始下降，已經(jīng)達不到新集群時的水平。我們進行了測試，至少有 30％ 的性能損失。

• 第三點：我們需要一個簡單的架構(gòu)。當(dāng)時團隊只有不到10個人，需要支持各種項目與任務(wù)。因此，我們希望有一個簡單的架構(gòu)，以便我們進行運維工作，對于我們小團隊來說，簡單意味著安全感。我們測試了很多開源和商業(yè)存儲方案，最終選擇了 SeaweedFS。

關(guān)于 SeaweedFS是高性能分布式存儲系統(tǒng)，用于存儲塊、對象、文件和數(shù)據(jù)湖，可制成數(shù)十億文件。

• 選擇 SeaweedFS，因為它各項功能都可以通過一個簡單的命令啟動。對于我們的團隊來說，它沒有屏蔽一些部署、架構(gòu)等細節(jié)，同時我們的開發(fā)同學(xué)也能對其進行一些修改工作。

• 第二點， SeaweedFS 是類 Haystack 架構(gòu)，它將隨機寫操作聚合成順序?qū)懖僮?#xff0c;具有對硬盤友好的特性。雖然現(xiàn)在 HDD 和 SSD 的價格差距不大，但該架構(gòu)是在 2021 年完成的，當(dāng)時因為炒幣，硬盤價格處于高點。

• 第三點 Haystack 架構(gòu)支持小文件合并。合并后的小文件不再受文件數(shù)量的限制，不會遇到像 MinIO 那樣寫入越多性能越差的情況。實際上，MinIO 對小文件有“負面優(yōu)化”，將小文件拆分為數(shù)據(jù)文件和元數(shù)據(jù)文件。在這種情況下，如果再進行EC（糾刪碼），文件會被進一步拆分。因此，對于大量小文件的使用場景，我們不推薦使用 MinIO。

• 第四點，SeaweedFS 支持 S3 接入。支持S3就可以很方便的對接JuiceFS,我們當(dāng)時看了很多案例博客，主要有兩篇文章。一篇是 《同城旅行的對象存儲》，他們就是改了 SeaweedFS ，給了我們一些信心。以及《京東登月平臺》當(dāng)時使用的小文件存儲選擇也是 SeaweedFS。

SeaweedFS 的一些不足之處是資料相對較少，文檔不太豐富。如果想了解某些功能，需要直接查看源代碼。另外，社區(qū)的維護相對薄弱，邊緣功能存在一些使用問題。在我們的實際應(yīng)用中，我們發(fā)現(xiàn)只有 IO 功能才能正常使用，例如副本機制是可行的，但副本轉(zhuǎn) EC 的機制無法正常的使用，目前還在持續(xù)研究中。另一個問題是多機房同步，想測試多機房同步與備份，在我們的測試中花費了很長時間也無法使其正常工作。此外，它還有冷熱數(shù)據(jù)轉(zhuǎn)換功能，我們也無法成功測試。這可能是由于我們的對其的了解有限，我們?nèi)栽谂鉀Q這些問題。

我們在選擇 SeaweedFS 時權(quán)衡了其優(yōu)點和缺點。總而言之，在進行架構(gòu)選型時不要過早下結(jié)論，盡可能推遲做出選擇的時間，多做場景測試，多做小范圍灰度測試，以便全面評估和考慮各種因素。做決定的時候，多考慮大局，不要局限于幾個文件系統(tǒng)，而要考慮選擇某個文件系統(tǒng)后，對團隊后續(xù)的規(guī)劃與建設(shè)是否有影響等。

04 JuiceFS 在思謀的使用場景

• 第一個場景：小容量存儲，總?cè)萘績H為百萬到千萬文件，百TB級。在這種情況下，使用 SSD 的成本并不高， 所以我們采用了 Redis + MinIO（SSD） + JuiceFS。結(jié)合 MinIO 和 Redis，你會發(fā)現(xiàn)它非常好用，而且日常無需太多關(guān)注。我們使用的是單點的 Redis，穩(wěn)定運行了一年多，從未發(fā)生過大型宕機，只要進行好內(nèi)存監(jiān)控即可，同時控制好文件個數(shù)。

• 第二個場景：大容量存儲，數(shù)據(jù)規(guī)模達到 PB 級。這時候就會面臨成本壓力，我們必須選擇 HDD。我們選擇了 SeaweedFS（HDD） + TiKV+ JuiceFS 作為該場景下的解決方案。

• 第三，多套小集群管理。每個用戶都部署了一套JuiceFS，但底層都是使用同一個SeaweedFS。我們當(dāng)時選擇這種方案有兩個原因。首先是出于歷史原因。我們從 JuiceFS v0.17 開始使用時，當(dāng)時它并不支持目錄限額功能。因此，一些算法工程師占用了大量的目錄空間。我們需要限制目錄限額，但等待功能更新或自己開發(fā)限額功能并不切實際。我們的團隊主要負責(zé)云原生調(diào)度，并沒有開發(fā)存儲系統(tǒng)的經(jīng)驗。

  因此，我們想出了一個解決辦法，管理多套小集群。我們采用了基于一個 TiKV 和一個 SeaweedFS 的模式，為每個用戶提供獨立的元數(shù)據(jù)前綴，并管理多套小集群。這種做法有一個好處，在維護集群時，如果 TiKV 規(guī)模足夠大，即使其中一半宕機也不會有太大影響。當(dāng)進行用戶 JuiceFS 維護時，實際上不會影響其他用戶，但眾多的文件系統(tǒng)數(shù)量，讓這種做法的管理過程比較繁瑣。

  這種使用方式也給我們帶來了一些問題，因為每個用戶都擁有一個 JuiceFS 目錄，所以在掛載 CSI 時，每個 Pod 都有自己的 CSI。而在容器場景下，容器的密度比物理機和虛擬機場景更高。

  隨著容器數(shù)量的不斷增加，重客戶端文件系統(tǒng)（JuiceFS 是一個典型的重客戶端文件系統(tǒng)，所有邏輯都由客戶端處理。）與工作負載之間就會爭奪有限的資源（內(nèi)存），這在我們集群已經(jīng)成為常態(tài)問題。內(nèi)存是無法壓縮的資源，所以內(nèi)存爭搶問題可能導(dǎo)致客戶投訴——為什么相同的代碼在集群的 A 節(jié)點上可以運行，而在 B 節(jié)點上卻會崩潰？用戶會質(zhì)疑為什么無法集群實現(xiàn)的環(huán)境一致性等諸多問題。去查看就會發(fā)現(xiàn)是 OOM（內(nèi)存耗盡）的問題，因為 B 節(jié)點的資源競爭更為激烈。目前，我們還沒有找到一個很好的解決方案。

  在使用中，要注意不同存儲組件在 Kubernetes 上的適配性。MinIO + Redis 在 Kubernetes上的適配性非常好，而 SeaweedFS + TiKV在 Kubernetes上的適配性就不太理想。目前，我們還沒有找到一個很好的方法將 TiKV 部署在 Kubernetes 中，因為涉及到的事務(wù)較多且管理上有些寬泛。我們曾嘗試使用 TiDB Operator 來部署 TiKV，但嘗試后發(fā)現(xiàn)存在k8s版本不適配等許多小問題。

05 一些運維實踐心得

存儲組件

首先，Redis 和 TiKV 在非臨界狀態(tài)下的延遲幾乎相當(dāng)。如果沒有進行測量，很難看出它們之間的性能差異。在 AI 場景中，當(dāng)讀取操作比寫入操作多時，像元數(shù)據(jù)的 mkdir 和 rename 等操作的性能差距可能非常大，因為需要上鎖。但在實際讀多寫少的場景中，我們在監(jiān)控中發(fā)現(xiàn) Redis 和 TiKV 的性能實際上差不多。

其次，有時我們需要根據(jù)情況做出選擇和判斷。Redis 的運維相對簡單，但存在冗余度和高可用性風(fēng)險。如果公司對 SLA 卡特別嚴(yán)格，實際上使用 TiKV 可能更合適，因為 Redis 并不是解決這個問題的最佳方案。

第三點，關(guān)于 TiKV 的文檔。盡管 TiKV 是一個非常 Nice 的開源項目，但其文檔也相對較少。文檔與 TiDB 官網(wǎng)是一起的，官網(wǎng)會列出所有參數(shù)，但沒有解釋這些參數(shù)對系統(tǒng)的影響。你需要逐個嘗試來了解它們。

第四點，關(guān)于 MinIO 和 SeaweedFS 的易用性。我們在實踐中得出結(jié)論，MinIO 在易用性和數(shù)據(jù)冗余方面優(yōu)于 SeaweedFS。在文件數(shù)量較少的情況下，我們強烈推薦使用 MinIO。事實上，我們的有些業(yè)務(wù)在一些實時性、可用性要求不強的環(huán)節(jié)中都采用了 Redis + MinIO 的組合。只有在數(shù)據(jù)量較大時，我們才切換到 TiKV+SeaweedFS 的組合。

JuiceFS CSI Driver

首先，當(dāng)我們采用 CSI 動態(tài)配置時，無法關(guān)閉 SubPath 功能。我們的初衷是能夠查看文件系統(tǒng)中的所有數(shù)據(jù)，因此我們當(dāng)時通過修改 CSI 源代碼來關(guān)閉 SubPath 功能。

其次，在將系統(tǒng)部署到預(yù)生產(chǎn)環(huán)境后，我們在短時間內(nèi)創(chuàng)建了大量的持久卷聲明（PVC）并進行掛載，導(dǎo)致系統(tǒng)卡死。經(jīng)過定位，我們發(fā)現(xiàn)在 v0.17.1 版本的控制器中存在 Create/DeleteSubPath 操作，這導(dǎo)致了在控制器容器中同時掛載/卸載多個JuiceFS文件系統(tǒng)，從而導(dǎo)致控制器的容器資源不足并進入假死狀態(tài)。我們及時通知了CSI的維護者，社區(qū)在下一個版本中進行了修復(fù)。

第三，就沒有部署 TiDB 的 TiKV 集群而言，會導(dǎo)致 TiKV 中的數(shù)據(jù)沒有進行垃圾回收（GC）。因此經(jīng)常會看到人們在 TiKV 群里詢問為什么 TiKV 的容量持續(xù)上升而不下降。但是實際上，我們并沒有遇到這種情況，可能是因為我們使用了較高版本的TiKV。我注意到JuiceFS的最新版本中也添加了 GC 功能。在 JuiceFS v1.0.0 中，設(shè)置了上傳/下載限制后，會出現(xiàn)大文件讀寫超時失敗的問題，這導(dǎo)致我們的QOS設(shè)置遇到了問題，我們目前采用的還是從網(wǎng)絡(luò)層面限制，后續(xù)會對這里進行優(yōu)化。

在本次分享中， 并沒有分享我們的架構(gòu)。如果大家對我們的架構(gòu)感興趣，可以查看云之聲的案例，大家的架構(gòu)基本上都是相似的，AI 私有化存儲方面的差異并不大。

06 未來展望

首先，處理一下重客戶端與任務(wù)進行資源爭搶的問題。因為如果遇到整機內(nèi)存超售的情況，尤其是在大型節(jié)點和高壓力任務(wù)下，往往容易導(dǎo)致任務(wù)宕機。在今年FAST 23，我們看到了阿里一個解決方案，Fisc: A Large-scale Cloud-native-oriented File System。但對于一般的公司來說，這種方法的實現(xiàn)成本確實非常高。

第二，適配 JuiceFS 的新版本 v1.1，原因是它解決了目錄配額的問題。我們目前正在探索是否可以在不遷移的數(shù)據(jù)的情況下，將多個JuiceFS 合并為一個JuiceFS，并開啟目錄限額，以此來降低我們的運維壓力。

第三，關(guān)于 Redis 和 TiKV 的延遲，在非臨界狀態(tài)下它們的延遲相近。然而，TiKV的部署運維非常復(fù)雜，鑒于我們在其他項目中使用了 CockroachDB，我們正在考慮是否可以將元數(shù)據(jù)切換到CockroachDB 上。我們的場景對元數(shù)據(jù)的性能要求并不是特別高，我們的業(yè)務(wù)主要是讀取操作，寫入操作的速度慢并不會影響后續(xù)讀取操作。

如有幫助的話歡迎關(guān)注我們項目 Juicedata/JuiceFS 喲！ (0?0?)