云知聲是一家專注于語音及語言處理的技術(shù)公司椿息。Atlas 超級計算平臺是云知聲的計算底層基礎(chǔ)架構(gòu)枫耳，為云知聲在 AI 各個領(lǐng)域（如語音、自然語言處理、視覺等）的模型迭代提供訓練加速等基礎(chǔ)計算能力痒给。Atlas 平臺深度學習算力超過 57 PFLOPS（5.7 億億次／秒试吁，是的你沒有看錯母怜，是億億次]

）船惨，深度學習算力是衡量一個 AI 平臺計算性能的核心指標怜浅。除了滿足公司內(nèi)部的業(yè)務(wù)需求沥阳，平臺也為外部企業(yè)和院校機構(gòu)提供定制化計算服務(wù)。

本文主要分享云知聲 Atlas 超算平臺（以下簡稱 Atlas）的存儲建設(shè)歷程以及基于 JuiceFS 建設(shè)高效存儲的實踐滚澜。

存儲建設(shè)歷程

一個性能卓越的超算平臺挡育，不僅需要充足的算力支持，也離不開高效的存儲系統(tǒng)。結(jié)合 Atlas 上的任務(wù)特點和類型，高效存儲系統(tǒng)應具備幾個特點显拳，如：滿足多種類型的結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)存儲需求揍移、兼容 POSIX 接口读规、海量小文件場景下具有較好的性能等燃少。

在最早期進行 Atlas 超算平臺建設(shè)的時候束亏，我們嘗試部署過 CephFS，開源版的 CephFS 在存儲規(guī)模達到幾千萬小文件的時候阵具，開始出現(xiàn)較為嚴重的性能問題碍遍，用戶在操作文件時會遇到卡頓甚至在高 IO 的場景下整套存儲系統(tǒng)會直接卡死，用戶體驗不太好阳液。

后期怕敬，我們轉(zhuǎn)到了 HPC 領(lǐng)域使用較為廣泛的 Lustre 分布式文件存儲系統(tǒng)， 構(gòu)建了多套不同規(guī)模的 Lustre 集群帘皿，作為平臺核心的存儲系統(tǒng)东跪，生產(chǎn)環(huán)境上目前主要有 40G 以太網(wǎng)與 100G InfiniBand 類型的集群，Lustre 分布式存儲支持著用戶在 Atlas 超算集群中進行數(shù)據(jù)處理鹰溜、模型訓練虽填、源碼編譯與調(diào)試、數(shù)據(jù)歸檔等一系列數(shù)據(jù)操作曹动。但是受限于 Lustre 在高并發(fā)請求下的性能瓶頸斋日，無法滿足對帶寬與 IOPS 要求較高的場景需求。因此我們采用 Alluxio + Fluid 進行 IO 加速墓陈，分布式緩存給我們帶來了 AI 模型訓練速度上的提升以及存儲系統(tǒng)總帶寬的下降恶守。

但是以上方案依然不是我們認為的最終方案第献，因此我們也在探索新的存儲系統(tǒng)。在我們的場景上對這個新存儲系統(tǒng)的核心需求是：

運維要足夠簡單：存儲研發(fā)人員要能夠較快的上手兔港，運維人員后期的擴容庸毫、故障處理足夠簡單。Lustre 提供了 IML 一系列的自動化部署與監(jiān)控工具押框，在運維方面較為方便岔绸。但是由于 Lustre 的軟件代碼是在內(nèi)核上運行，如果出現(xiàn)故障橡伞，問題定位就顯得不那么直觀盒揉，需要從內(nèi)核消息這邊定位，大部分操作涉及重啟操作系統(tǒng)兑徘；

數(shù)據(jù)可靠性：數(shù)據(jù)是 AI 公司寶貴的資產(chǎn)刚盈，算法工程師在存儲上的數(shù)據(jù)要足夠穩(wěn)定與安全挂脑。Lustre 目前不支持文件系統(tǒng)級的冗余，只能通過硬件的 RAID 來抵御硬盤故障崭闲；

客戶端多級緩存功能：構(gòu)建大規(guī)模數(shù)據(jù)存儲系統(tǒng)（PB 量級以上）為了考慮成本數(shù)據(jù)大部分會存儲在 HDD 上，為了自動區(qū)分冷熱數(shù)據(jù)刁俭，并充分利用我們 GPU 服務(wù)器的接近 TB 級的內(nèi)存與大量的獨立 SSD 盤，我們希望具備客戶端多級自動緩存功能 侮繁，以應對高密集 I/O 的讀寫場景；

社區(qū)活躍度：社區(qū)活躍度也是我們考慮的因素宪哩，活躍的社區(qū)在功能版本的迭代與 bug 的解決方面能有更快的響應。

初識 JuiceFS

云知聲團隊在 2021 年初了解到了 JuiceFS第晰，并跟 Juicedata 團隊進行了早期的方案對接锁孟、PoC 測試，目前 JuiceFS 已經(jīng)上線到生產(chǎn)環(huán)境茁瘦，我們也參與到 JuiceFS 開源社區(qū)的建設(shè)中罗岖。

JuiceFS 的架構(gòu)與優(yōu)勢

JuiceFS 整體的架構(gòu)由元數(shù)據(jù)引擎、對象存儲集群以及 JuiceFS 客戶端組成腹躁，其中元數(shù)據(jù)引擎與對象存儲提供了多種方案供用戶選擇。通過 JuiceFS 存儲的數(shù)據(jù)將持久化到對象存儲（如 Amazon S3）中南蓬，相應的元數(shù)據(jù)可以根據(jù)場景和需求持久化到 Redis纺非、MySQL哑了、SQLite 以及 TiKV 等各種數(shù)據(jù)庫引擎中换怖。

不管是元數(shù)據(jù)引擎還是對象存儲都有很多成熟的方案可以選擇掂墓，如果是在公有云上使用通常也有全托管的服務(wù)開箱即用。JuiceFS 的元數(shù)據(jù)自動備份棘钞、回收站等特性一定程度上保障了數(shù)據(jù)的可靠性炕淮，避免一些意外情況導致數(shù)據(jù)丟失拆火，當然如果是自己運維元數(shù)據(jù)引擎和對象存儲依然需要做好數(shù)據(jù)備份。JuiceFS 的本地緩存特性可以自動將頻繁訪問的數(shù)據(jù)緩存到內(nèi)存以及磁盤中涂圆，同時也會對文件的元數(shù)據(jù)進行緩存们镜。

PoC 測試

PoC 測試我們主要是在小規(guī)模環(huán)境上做可行性驗證，關(guān)注的點是產(chǎn)品特性润歉、運維方式模狭、與上游調(diào)度、業(yè)務(wù)框架對接是否可行等踩衩。

PoC 測試環(huán)境我們搭建了一個單節(jié)點的 Redis + 3 節(jié)點的 Ceph 對象存儲集群嚼鹉，在環(huán)境搭建方面因為 Redis 跟 Ceph 都比較成熟，部署運維方案可以參考的資料也比較全驱富，而 JuiceFS 客戶端能夠以較為簡單的方式對接元數(shù)據(jù)引擎跟對象存儲锚赤。

業(yè)務(wù)的適配方面，JuiceFS 完全兼容 POSIX 協(xié)議褐鸥，我們上層的業(yè)務(wù)可以無縫切換與對接，業(yè)務(wù)使用無感酒贬，JuiceFS 也支持以 CSI Driver 這種云原生的方式調(diào)度锭吨，與我們整個平臺的技術(shù)棧契合零如。

在性能測試方面考蕾，我們在測試環(huán)境進行了文字識別模型的訓練肖卧，實驗環(huán)境為：模型采用服務(wù)器版中文識別模型 backbone 為 ResNet-18塞帐，數(shù)據(jù)整體總量是 98G 采用 LMDB 格式存儲，在 6 張 NVIDIA Tesla V100 進行了三組實驗荷鼠，分別是：

• 直接在 Lustre 讀
• 在帶有 200G 內(nèi)存緩存的 JuiceFS 讀
• 在帶有 960G SSD 緩存的 JuiceFS 上讀

JuiceFS 客戶端擁有多級緩存功能，因而在性能測試中削咆，在數(shù)據(jù)讀方面有較大性能提升态辛，相比 Lustre 性能有1倍以上的提升奏黑，這與我們的業(yè)務(wù)特點比較契合熟史。

綜合考慮運維方式蹂匹、業(yè)務(wù)契合度以及性能表現(xiàn)限寞，我們決定將 JuiceFS 帶上生產(chǎn)履植。

JuiceFS 在 Atlas 的使用場景與收益

JuiceFS 客戶端多級緩存目前主要應用在我們的文字識別玫霎、語音降噪以及語音識別場景庶近。由于 AI 模型訓練的數(shù)據(jù)讀取特點是讀多寫少鼻种，我們充分利用 JuiceFS 客戶端的緩存帶來 IO 讀取的加速收益。

收益一：加速 AI模型訓練

語音降噪測試
降噪場景模型的測試中使用的是散文件校读，每個數(shù)據(jù)都是 wav 格式的小于 100k 的語音小文件，在降噪場景我們測試了數(shù)據(jù) dataload 階段的 I/O 數(shù)據(jù)养铸，JuiceFS 客戶端節(jié)點的內(nèi)存緩存為 512G钞螟，在 500h 規(guī)模的數(shù)據(jù)下鳞滨、以 40 的 batch size 進行測試拯啦。

從測試結(jié)果來看褒链，單從數(shù)據(jù)讀取效率上甫匹，在 wav 小文件方面兵迅，JuiceFS 為 6.45 it/s恍箭，而 Lustre 為 5.15 it/s季惯，性能提升25%勉抓。JuiceFS 有效加速了我們端到端的模型訓練藕筋，整體縮短了模型的產(chǎn)出時間隐圾。

文字識別場景
在文字識別場景中，模型為 CRNN backbone 為 MobileNet v2 蜜笤，測試環(huán)境如下：

在這個測試中把兔，主要做了 JuiceFS 跟 Lustre 的速度對比县好，從實驗的結(jié)果來看從 Lustre 讀每個 batch 耗時 1.5s缕贡，從 JuiceFS 讀每個 batch 耗時為 1.1s晾咪，提升36%禀酱。從模型收斂的時間來看剂跟，從 Lustre 的 96 小時下降到 JuiceFS 的 86 小時曹洽，使用 JuiceFS 能夠?qū)?CRNN 模型的產(chǎn)出時間縮短 10 小時送淆。

收益二：加速 AI模型開發(fā)

在算法工程師將 AI 模型訓練任務(wù)正式提交到超算集群之前偷崩，其模型需要經(jīng)過大量的調(diào)試阐斜，我們?yōu)橛脩籼峁┝苏{(diào)試環(huán)境谒出，Dev Node 跟 Atlas 正式訓練集群一樣都是使用相同的存儲为居，開發(fā)節(jié)點與訓練節(jié)點都掛載 JuiceFS 客戶端蒙畴，因此在開發(fā)機的修改能夠無縫遷移到 Atlas 訓練集群忍抽。

用戶在開發(fā)機上可以靈活地選擇開發(fā)環(huán)境，既可以在宿主機搭配 Anaconda 進行遠程調(diào)試干跛，也可以使用容器的方式運行開發(fā)環(huán)境楼入。用戶的調(diào)試模型大部分是 PyTorch 跟 TensorFlow 類型的框架嘉熊，我們發(fā)現(xiàn)在調(diào)試的時候需要頻繁地 import Python 包阐肤，例如 numpy孕惜、torch 等衫画，這種包都是大量的小文件組成的削罩，基于舊的存儲系統(tǒng)，用戶 import 包的耗時需要幾秒或者幾十秒进陡。算法人員反饋模型調(diào)試的效率比較低四濒。作為統(tǒng)一開發(fā)環(huán)境戈二，伴隨著大量的安裝包導入喳资、代碼編譯、日志讀寫鲜滩、樣本下載徙硅，這要求調(diào)試機既能有較高的吞吐量嗓蘑，又能快速處理大量小文件桩皿。

通過引入 JuiceFS幢炸，我們在開發(fā)機上掛載了 JuiceFS 客戶端，客戶端掛載時候使用元數(shù)據(jù)緩存以及數(shù)據(jù)讀緩存機制佛嬉。在元數(shù)據(jù)緩存方面巷燥，當 JuiceFS 客戶端使用 open() 操作打開一個文件的時候缰揪，其文件屬性（attribute）就會自動緩存在客戶端內(nèi)存中钝腺，只要緩存未失效則隨后執(zhí)行的 getattr() 跟 open() 操作都會從內(nèi)存緩存中立即返回結(jié)果艳狐。在執(zhí)行 read() 操作的時候文件的 chunk 和 slice 信息也會自動緩存在客戶端內(nèi)存毫目。數(shù)據(jù)緩存方面我們使用內(nèi)存作為緩存介質(zhì)，采用該方式用戶調(diào)試的 Python 包在經(jīng)過第一次 import 之后會全部緩存在內(nèi)存上箱蟆，第二次調(diào)試的時候空猜，直接從內(nèi)存緩存讀取文件辈毯。相比之前的方式谆沃，整體速度有 2-4 倍的提速 管毙，極大地提高了用戶的調(diào)試效率，用戶的體驗也更加好啃炸。

JuiceFS 在 Atlas 的使用方式

在數(shù)據(jù)的存放管理方式上南用，我們采用兼容現(xiàn)有分布式存儲系統(tǒng)的管理方式裹虫，JuiceFS 集群的節(jié)點也都是對接 LDAP筑公，每個節(jié)點會通過 LDAP 的客戶端與 LDAP Server 集群進行交互認證匣屡。

超算平臺上的每個組歸屬于不同的目錄捣作，每個目錄下是各自組內(nèi)或者部門內(nèi)的成員券躁，不同組之間的目錄是不可見的。目錄的權(quán)限是基于 Linux 的權(quán)限管控機制以舒。用戶在 Atlas 集群提交訓練任務(wù)的時候稀轨，集群的任務(wù)提交工具會自動讀取系統(tǒng)上用戶的 UID 與 GID 信息然后將其注入用戶提交的任務(wù) Pod 的 securityContext 字段奋刽，則 Atlas 集群上運行的容器 Pod 內(nèi)所有容器的進程運行的 UID 與存儲系統(tǒng)上的信息一致佣谐，保證權(quán)限不越界狭魂。

在數(shù)據(jù)的訪問方式上斋泄，云知聲目前有 2 種使用方式：

• 一種是通過計算節(jié)點的 HostPath 訪問數(shù)據(jù)炫掐；
• 另一種是更加云原生的方式睬涧，通過結(jié)合 Fluid + JuiceFS 對利用 JuiceFS 客戶端為 Atlas 的應用提供數(shù)據(jù)的訪問與加速畦浓。

HostPath Volume

第 1 種還是沿用之前的訪問分布式文件存儲系統(tǒng)的方式祷嘶，通過 Kubernetes HostPath 的方式直接訪問本地的存儲系統(tǒng)客戶端秽梅，我們在所有的 CPU 與 GPU 計算節(jié)點都部署了 JuiceFS 的客戶端企垦，用戶提交計算任務(wù)的時候需要指定 Kubernetes volume 為 HostPath 的方式钞诡，將 JuiceFS 的目錄映射湃崩。這種方式的緩存管理就比較裸攒读，在用戶側(cè)是無法對緩存進行管理的薄扁。

** Fluid + JuiceFS**

第 2 種方式是結(jié)合 Fluid + JuiceFS 的方式邓梅，關(guān)于如何使用的具體方式可以參考我們之前的文章（點擊此處查看） 日缨，這里僅對架構(gòu)做個簡單的說明匣距。

Fluid 會啟動 JuiceFS 相關(guān)的組件包括 FUSE 跟 Worker pod毅待，其中 FUSE Pod 提供了 JuiceFS 客戶端的緩存能力恩静，Worker Pod 則實現(xiàn)了對緩存生命周期的管理蹲坷，Atlas 平臺的 AI 離線訓練任務(wù)通過與 FUSE Pod 客戶端交互循签，進行 AI 訓練數(shù)據(jù)的讀取县匠，通過 Fluid 提供的緩存調(diào)度能力以及數(shù)據(jù)集的可觀測性乞旦，平臺的用戶可以通過親和調(diào)度將緩存部署在特定的計算節(jié)點上兰粉，同時用戶能夠直觀的看到緩存的使用情況（例如緩存數(shù)據(jù)集的大小玖姑、緩存的百分比、緩存的容量等）戴甩。

JuiceFS 存儲生產(chǎn)環(huán)境建設(shè)

元數(shù)據(jù)引擎

目前我們生產(chǎn)環(huán)境的元數(shù)據(jù)引擎采用 Redis甜孤，Redis 節(jié)點的系統(tǒng)盤做了 RAID1缴川，同時 Redis 持久化的數(shù)據(jù)會定期同步到另一臺備份節(jié)點上二跋。Redis 的數(shù)據(jù)持久化我們采用 AOF + RDB 的方案流昏，每秒進行一次數(shù)據(jù)持久化况凉，相關(guān)配置如下：

appendonly yes 
appendfsync everysec 
aof-load-truncated yes

由于我們節(jié)點采用的是 100G InifiBand刁绒，IB 的 網(wǎng)卡驅(qū)動[3] 需要用戶根據(jù)自己的操作系統(tǒng)版本下載對應的 ISO知市。目前我們的節(jié)點是采用 Kernel 5.4 的版本，由于 IB 驅(qū)動跟操作系統(tǒng)還有 Kernel 版本有較強的耦合性娘赴，當我們 Kernel 升級到 5.4 版本诽表，驅(qū)動需要重新編譯安裝隅肥，驅(qū)動版本 MLNX_OFED_LINUX-5.5-1.0.3.2-rhel7.6-x86_64.iso 注意 GCC 的版本一定要是 GCC 9 的才行泛啸，否則編譯過程會出現(xiàn)各種莫名其妙的問題汞舱。

# 安裝 gcc9 yum --enablerepo=extras install centos-release-scl-rh yum install devtoolset-9-gcc scl enable devtoolset-9 bash # 進行 IB 驅(qū)動編譯 mount /dev/sr0 ib ./mlnx_add_kernel_support.sh -m /root/ib -k (kernel 版本)

對象存儲

對象存儲采用自建的 Ceph 集群泌神，Ceph 集群采用 Cephadm 進行部署损趋，目前生產(chǎn)環(huán)境用的是 Octopus 版本桐玻。Cephadm 是隨著 Ceph 新版本 v15.2.0（Octopus）發(fā)布的安裝工具，并且不支持 Ceph 的舊版本，Cephadm 不依賴于外部配置工具苫耸，如 Ansible呀枢、 Rook 和 Salt缨伊，它通過 SSH 將管理器守護進程連接到主機來實現(xiàn)這一點党晋。管理器守護進程可以添加、刪除和更新 Ceph 容器庇绽。通過 Cephadm 引導一個單節(jié)點的集群余爆，Cephadm 會在執(zhí)行 bootstrap 引導的節(jié)點部署 mgr 跟 mon 服務(wù)桩砰，當添加其他節(jié)點的時候庶溶，會自動在其中一臺部署 mgr 管理節(jié)點行疏，目前我們生產(chǎn)采用 2 個管理節(jié)點 3 個監(jiān)控節(jié)點。在 Ceph 調(diào)優(yōu)方面我們借鑒了社區(qū)其他用戶分享的方案，感謝攜程的工程師在我們調(diào)優(yōu)過程中提供的幫助 （點擊此處查看），主要做了以下實踐：

服務(wù)器層面：

• 42Cores 256GB 24*18T HDD
• 系統(tǒng)盤: 2* 960G SAS SSD
• BlueStore
• 關(guān)閉 NUMA
• 升級 kernel: 5.4.146 開啟 io_uring
• Kernel pid max，修改 /proc/sys/kernel/pid_max

Ceph 配置方面：

• Ceph RADOS：直接調(diào)用 librados 接口，不走 S3 協(xié)議
• Bucket shard
• 關(guān)閉 pg 的自動調(diào)整功能
• OSD 日志存儲（采用 bluestore，建議裸容量配比—— block : block.db :
• block.wal = 100:1:1，后兩者建議采用 SSD 或 NVMe SSD）
• 3 副本

JuiceFS 客戶端

我們環(huán)境中 JuiceFS 對接的對象存儲是 Ceph RADOS，JuiceFS 采用 librados 與 Ceph 進行交互，因此需要重新編譯 JuiceFS 客戶端坷备，建議 librados 的版本要跟 Ceph 的對應，例如在我們的環(huán)境 Ceph 版本是 Octopus（v15.2.）鸿摇，librados 的版本建議為 v15.2.，CentOS 自帶的 librados 版本比較低佛舱，因此我們可以在官網(wǎng)自己下載對應的包，我們的環(huán)境上只需要下載 librados2-15.2.10-0.el7.x86_64.rpm 和 librados-devel-15.2.10-0.el7.x86_64.rpm慎陵。然后運行如下命令安裝：

yum localinstall -y librad*

安裝 librados 后即可編譯 JuiceFS 客戶端了（推薦 Go 1.17+ 、GCC 5.4+）：

make juicefs.ceph

編譯完 JuiceFS 即可創(chuàng)建文件系統(tǒng)并在計算節(jié)點進行 JuiceFS 客戶端的掛載了。目前 JuiceFS 在我們的生產(chǎn)環(huán)境使用還是有一大部分是直接通過 Kubernetes 的 HostPath 進行掛載抒和，因此我們在各個 GPU、CPU 節(jié)點中都掛載了 JuiceFS 客戶端，并通過 systemctl 管理 JuiceFS 的掛載進程，實現(xiàn)開機自動掛載與故障的恢復卖哎。

未來展望與規(guī)劃

最后歸納下 Lustre 與 JuiceFS 的特點與適用場景，企業(yè)可以根據(jù)自身的業(yè)務(wù)場景它掂、運維能力以及存儲規(guī)模做出相應的選擇。

• Lustre 作為老牌 HPC 領(lǐng)域的存儲系統(tǒng)，為許多全球最大的超算系統(tǒng)提供動力，具有多年的生產(chǎn)環(huán)境經(jīng)驗抬虽。其具有符合 POSIX 標準咱圆、支持各種高性能低時延的網(wǎng)絡(luò)，允許 RDMA 訪問的優(yōu)點，適用于傳統(tǒng) HPC 領(lǐng)域的高性能計算，但是在云原生場景的適配上還不夠完善，目前只能采用 HostPath Volume 對接，而且其軟件運行在 Linux 內(nèi)核之上虐译，對運維人員要求更高撇叁；

• JuiceFS 是一款云原生領(lǐng)域的分布式存儲系統(tǒng)產(chǎn)品，提供了 CSI Driver 以及 Fluid 等方式使用能夠更好地與 Kubernetes 進行結(jié)合。在運維部署方面為用戶提供了更多靈活的選擇哨啃，用戶既可以選擇在云上也可以選擇私有化部署祝峻，在存儲擴容運維方面較為簡單奥溺。完全兼容 POSIX 標準使得深度學習的應用可以無縫遷移层亿，但是由于后端對象存儲的特點其在隨機寫方面會有較高的延遲，在只讀的場景可以使用客戶端的多級緩存進行加速較為符合我們的業(yè)務(wù)特點。

Atlas 平臺未來與 JuiceFS 相關(guān)的規(guī)劃是：

• 元數(shù)據(jù)引擎升級：TiKV 適合在 1 億以上文件數(shù)量（最多可以支撐到百億級文件），對性能以及數(shù)據(jù)安全都有較高要求的場景，目前我們已經(jīng)完成了 TiKV 的內(nèi)部測試也在積極跟進社區(qū)的進展，后續(xù)要將元數(shù)據(jù)引擎遷移到 TiKV坪郭。

• 基于目錄（項目）的文件配額：開源版本目前還不支持基于目錄的配額沪曙，目前我們每個部門是歸屬在 JuiceFS 的不同的目錄下缘眶，需要對目錄的配額做限制砸喻。JuiceFS 社區(qū)版已經(jīng)在規(guī)劃實現(xiàn)這個特性犯助，會在 v1.0.0 之后的版本正式發(fā)布瞬哼。

感謝 JuiceFS 開源社區(qū)在云知聲 Atlas 計算平臺高效存儲建設(shè)的過程中提供的技術(shù)支持赞咙，云知聲也在積極地進行內(nèi)部測試，爭取后續(xù)將開發(fā)的功能以及改進回饋到開源社區(qū)。

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