目前大模型的客戶(hù)在存儲(chǔ)系統(tǒng)的選型上可能會(huì)有以下幾種選擇：并行文件系統(tǒng)、基于對(duì)象存儲(chǔ)的存儲(chǔ)系統(tǒng)、NFS等。
首先我們看一下并行文件系統(tǒng)：
Density distribution plots of I/O activity from ML jobs using GPFS
《Characterizing Machine Learning I/O Workloads on Leadership Scale HPC Systems》中關(guān)于ML在GPFS中的IO模型示意圖，可以看到在并行文件系統(tǒng)的傳統(tǒng)科學(xué)計(jì)算領(lǐng)域IO模式，讀寫(xiě)比例基本平衡且大部分為小IO，這種GPFS適用的IO模式是否能夠完全匹配AI大模型下的場(chǎng)景呢？
這里引用Vast Data（https://vastdata.com/blog/five-reasons-why-parallel-file-systems-are-not-silver-bullet-for-ai）的數(shù)據(jù)，95%的AI Workloads是讀密集型的，當(dāng)然也有例外情況，比如大型語(yǔ)言模型的Checkpoint。并行文件系統(tǒng)在擁有高性能的同時(shí)，也引入了高復(fù)雜性，包括額外的客戶(hù)端以及較高難度的維護(hù)工作，并行文件系統(tǒng)適用的HPC科學(xué)研究場(chǎng)景需要一個(gè)對(duì)存儲(chǔ)系統(tǒng)代碼和操作系統(tǒng)有深入了解的團(tuán)隊(duì)，這在科研實(shí)驗(yàn)室中是相對(duì)常見(jiàn)的，但對(duì)于商業(yè)企業(yè)來(lái)說(shuō)，往往缺乏這種人員配置，在目前的大模型場(chǎng)景下，類(lèi)似于GPFS的并行文件系統(tǒng)并不完全適用。
根據(jù)UCloud優(yōu)刻得云平臺(tái)上的客戶(hù)IO模式來(lái)看，大模型計(jì)算的工作負(fù)載大部分場(chǎng)景下是讀密集型的，并非大部分文件系統(tǒng)面對(duì)的讀寫(xiě)比例平衡的場(chǎng)景，短時(shí)間的高讀吞吐需求較為常見(jiàn)，高吞吐讀之前會(huì)對(duì)文件進(jìn)行大量列表操作等元數(shù)據(jù)操作，以及Checkpoint時(shí)期會(huì)有大量順序?qū)懭?/strong>，對(duì)于歷史數(shù)據(jù)有一定的歸檔需求。
針對(duì)上述場(chǎng)景，目前UCloud優(yōu)刻得提供全面優(yōu)化升級(jí)的US3FS 2.0來(lái)滿(mǎn)足大模型客戶(hù)的存儲(chǔ)需求。
US3FS是基于UCloud優(yōu)刻得對(duì)象存儲(chǔ)系統(tǒng)US3的文件系統(tǒng)，支持將對(duì)象存儲(chǔ)中的Bucket直接以文件的形式掛載至客戶(hù)端，方便客戶(hù)業(yè)務(wù)通過(guò)文件的POSIX接口來(lái)訪(fǎng)問(wèn)數(shù)據(jù)，避免客戶(hù)業(yè)務(wù)層面做過(guò)多的修改適配。面向大模型場(chǎng)景，目前UCloud優(yōu)刻得對(duì)US3FS進(jìn)行了升級(jí)優(yōu)化，US3FS 2.0 整體架構(gòu)如下：
從前述大模型的存儲(chǔ)需求來(lái)看，后面將從高吞吐讀需求，大量列表操作，大量順序?qū)懭?/strong>這三方面描述UCloud優(yōu)刻得針對(duì)US3FS的優(yōu)化升級(jí)過(guò)程。
這里首先考慮高吞吐讀之前的大量列表的問(wèn)題，整體分為兩種解決思路：
1.打散后端US3的存儲(chǔ)結(jié)構(gòu)，旁路一套元數(shù)據(jù)系統(tǒng)進(jìn)行元數(shù)據(jù)的性能優(yōu)化等維護(hù)操作，不利用現(xiàn)有US3的元數(shù)據(jù)能力。
2.不打散后端US3的存儲(chǔ)結(jié)構(gòu)，優(yōu)化升級(jí)現(xiàn)有的US3元數(shù)據(jù)性能，并進(jìn)行Meta Cache等近計(jì)算端優(yōu)化。
第一種方案理論上可以規(guī)避現(xiàn)有架構(gòu)的歷史負(fù)擔(dān)，需要額外的硬件資源來(lái)提供元數(shù)據(jù)服務(wù)，改造后能夠規(guī)避業(yè)務(wù)層面文件大小等因素對(duì)US3在高并發(fā)情況下發(fā)揮高吞吐能力的限制，也可以?xún)?yōu)化元數(shù)據(jù)結(jié)構(gòu)以更貼近文件存儲(chǔ)的樹(shù)狀方式，而不是對(duì)象存儲(chǔ)的KV方式。但此方案整體改動(dòng)較大，引入的風(fēng)險(xiǎn)也較多，且無(wú)法直接利用US3對(duì)象存儲(chǔ)現(xiàn)有的增值服務(wù)，包括但不限于歸檔、低頻等廉價(jià)存儲(chǔ)的功能。
第二種方案需要對(duì)現(xiàn)有關(guān)系型數(shù)據(jù)庫(kù)的老架構(gòu)US3元數(shù)據(jù)進(jìn)行升級(jí)，這里由于US3同時(shí)正在進(jìn)行元數(shù)據(jù)UKV的升級(jí)過(guò)程，將US3整體的元數(shù)據(jù)遷移至KV的方式進(jìn)行存取，可以直接利用數(shù)據(jù)，與此同時(shí)，還需要對(duì)現(xiàn)有的對(duì)象存儲(chǔ)語(yǔ)義的ListObject進(jìn)行一定優(yōu)化來(lái)適配文件存儲(chǔ)的場(chǎng)景，進(jìn)而解決對(duì)象和文件之間元數(shù)據(jù)差異的問(wèn)題。
經(jīng)過(guò)對(duì)比，UCloud優(yōu)刻得選擇了第二種方案來(lái)實(shí)現(xiàn)US3FS2.0的元數(shù)據(jù)部分，依賴(lài)于UKV（UCloud優(yōu)刻得自研的分布式KV存儲(chǔ)系統(tǒng)）的整體存儲(chǔ)計(jì)算分離的架構(gòu)，可以支持0數(shù)據(jù)搬遷的Shard Split，快速進(jìn)行列表請(qǐng)求計(jì)算部分的壓力分?jǐn)�，底層的統(tǒng)一存儲(chǔ)層Manul也可以進(jìn)行存儲(chǔ)層面的壓力分?jǐn)偂?/strong>
這里UCloud優(yōu)刻得也會(huì)進(jìn)行近端元數(shù)據(jù)的Cache，由于對(duì)象存儲(chǔ)和文件存儲(chǔ)存在天然的區(qū)別，對(duì)象存儲(chǔ)的結(jié)構(gòu)近似于KV的方式平鋪，文件存儲(chǔ)的方式近似于樹(shù)狀結(jié)構(gòu)，客戶(hù)在文件層面的readdir操作在極端情況下會(huì)導(dǎo)致底層KV層的大量seek操作效率不高，這里我們優(yōu)化成直接進(jìn)行平鋪的ListObject操作并在近端進(jìn)行整體的元數(shù)據(jù)重構(gòu)以及Cache，保證客戶(hù)的元數(shù)據(jù)檢索效率，以在UCloud優(yōu)刻得云平臺(tái)實(shí)際上線(xiàn)的某客戶(hù)為例，30PiB的數(shù)據(jù)元數(shù)據(jù)異步Cache的整體時(shí)間可控制在10分鐘到20分鐘級(jí)別。
其次，UCloud優(yōu)刻得還綜合考慮了客戶(hù)高并發(fā)讀吞吐的需求，這里面向客戶(hù)的業(yè)務(wù)實(shí)際場(chǎng)景，大模型通常是GiB級(jí)別的文件高并發(fā)的重復(fù)讀取，UCloud優(yōu)刻得并不希望這些重復(fù)的讀取消耗后端對(duì)象存儲(chǔ)的帶寬。
UCloud優(yōu)刻得在US3FS的掛載端通過(guò)本地NVMe來(lái)提供近計(jì)算端的分布式緩存，這里的緩存會(huì)利用計(jì)算節(jié)點(diǎn)間的東西向帶寬，一般建議實(shí)際操作時(shí)，在計(jì)算網(wǎng)和存儲(chǔ)網(wǎng)做網(wǎng)絡(luò)層面的隔離，防止和計(jì)算部分的流量有干擾，UCloud優(yōu)刻得也提供獨(dú)立專(zhuān)有化部署的一整套解決方案。
后續(xù)UCloud優(yōu)刻得還會(huì)提供通過(guò)US3FS的管理節(jié)點(diǎn)US3FS Master來(lái)支持業(yè)務(wù)層主動(dòng)提前Load指定的數(shù)據(jù)至緩存中的功能，但這需要將業(yè)務(wù)層和存儲(chǔ)層做一些深度的結(jié)合才能實(shí)現(xiàn)。
在未進(jìn)行預(yù)Cache時(shí)，上層應(yīng)用從US3FS掛載點(diǎn)讀取數(shù)據(jù)時(shí)，Kernel會(huì)將上層的讀緩沖區(qū)拆分成固定大小傳遞給US3FS, 當(dāng)US3FS接收到這些讀請(qǐng)求時(shí)，會(huì)根據(jù)讀的偏移，傳入的緩沖區(qū)的大小以及設(shè)置的預(yù)讀大小來(lái)確定實(shí)際要讀的Range。默認(rèn)情況下，US3FS以1MiB一個(gè)CachePage的形式組織文件的緩存區(qū)，通過(guò)讀Range可以確定涉及的Pages，接著根據(jù)Page的狀態(tài)（Ready, Missing or Infight）, 如Pages全為Ready，則可直接向上返回，如存在Missing或者Inflight的Pages，則Missing的Pages需要向數(shù)據(jù)層發(fā)送GET_RANGE請(qǐng)求，Inflight的Pages需要等待對(duì)應(yīng)的GET_RANGE執(zhí)行完成，這里一定程度的耦合了大模型下客戶(hù)順序讀的IO模型，通過(guò)參數(shù)能夠最大優(yōu)化在這種場(chǎng)景下的讀取并發(fā)吞吐。
接下來(lái)還需要對(duì)業(yè)務(wù)Checkpoint場(chǎng)景進(jìn)行優(yōu)化。由于業(yè)務(wù)的特殊性，寫(xiě)入Checkpoint期間計(jì)算訓(xùn)練是暫停的，寫(xiě)入速度的快慢就直接影響了客戶(hù)整體的效率，又由于此時(shí)是大量順序?qū)懀?strong>對(duì)存儲(chǔ)系統(tǒng)的性能需求就明確為寫(xiě)吞吐。
這里也有兩種解決思路:
3.寫(xiě)緩存，異步的上傳到后端對(duì)象存儲(chǔ)，保證當(dāng)時(shí)寫(xiě)入的速度是近似于本地盤(pán)的速度。
4.提高并發(fā)，直接寫(xiě)至后端對(duì)象存儲(chǔ)，由于后端整體的吞吐是可以支持平行擴(kuò)展的，這里瓶頸如果能夠打滿(mǎn)掛載的網(wǎng)絡(luò)則是最優(yōu)的情況，那需要提高的就是寫(xiě)入的并發(fā)，降低整體吞吐對(duì)于寫(xiě)延遲的依賴(lài)。
綜上UCloud優(yōu)刻得選擇了兩者結(jié)合的方式。純粹寫(xiě)緩存的方式在數(shù)據(jù)一致性以及系統(tǒng)復(fù)雜度上都有不少的麻煩，且能否解決問(wèn)題強(qiáng)依賴(lài)于不可控的計(jì)算節(jié)點(diǎn)的緩存盤(pán)，而不是依賴(lài)于存儲(chǔ)系統(tǒng)自身的環(huán)境。UCloud優(yōu)刻得會(huì)在寫(xiě)入時(shí)將上層Kernel拆分下載為固定大小的IO進(jìn)行進(jìn)一步的合并整合，整合一個(gè)4MiB大小的Logic Block，用于后續(xù)并發(fā)上傳至后端US3對(duì)象存儲(chǔ)。上層的IO到達(dá)US3FS之后會(huì)直接返回成功，并逐步累積緩存對(duì)后端進(jìn)行并發(fā)的分片上傳，這里并發(fā)的大小以及緩存的度都是支持對(duì)參數(shù)隨時(shí)配置修改的。
這樣上層的串行IO通過(guò)US3FS后會(huì)變成高并發(fā)的分片上傳請(qǐng)求到US3后端，進(jìn)而提升整體的吞吐。
以上為一個(gè)實(shí)例集群US3FS Runtime的實(shí)時(shí)Stat功能展示的寫(xiě)吞吐，相較于優(yōu)化前有50%左右的吞吐提升。
本文描述了面向大模型場(chǎng)景的存儲(chǔ)需求，UCloud US3FS2.0 在元數(shù)據(jù)性能、讀緩存、寫(xiě)吞吐三個(gè)方面的優(yōu)化內(nèi)容。在AI大模型的需求推動(dòng)下，對(duì)整個(gè)存儲(chǔ)系統(tǒng)以及IaaS計(jì)算、網(wǎng)絡(luò)架構(gòu)提出了較大的挑戰(zhàn)。對(duì)于對(duì)象存儲(chǔ)來(lái)說(shuō)，前端的壓力能夠釋放到后端之后，后續(xù)，UCloud優(yōu)刻得還將在存儲(chǔ)容量與性能需求不匹配、讀緩存預(yù)熱等方面持續(xù)進(jìn)行優(yōu)化。*圖片來(lái)源由UCloud優(yōu)刻得提供授權(quán)使用
