BeeGFS并行文件系統(tǒng)性能優(yōu)化技術(shù)研究

宋振龍，李小芳，李 瓊，謝徐超，魏登萍，董 勇，王睿伯

(國防科技大學(xué)計(jì)算機(jī)學(xué)院,湖南 長沙 410073)

1 引言

超級計(jì)算機(jī)的發(fā)展已進(jìn)入E級時(shí)代。E級計(jì)算機(jī)的存儲系統(tǒng)總空間將達(dá)到500～3 000 PB，峰值聚合I/O帶寬將達(dá)到100～200 TB/s，持續(xù)I/O帶寬也將超過10 TB/s，同時(shí)支持?jǐn)?shù)億并發(fā)度的I/O需求。大數(shù)據(jù)和人工智能時(shí)代，大數(shù)據(jù)和人工智能應(yīng)用程序開始在高性能計(jì)算HPC(High Performance Computing)系統(tǒng)上運(yùn)行。新興的深度學(xué)習(xí)應(yīng)用程序具有批量小文件隨機(jī)輸入特點(diǎn)，導(dǎo)致HPC存儲系統(tǒng)的I/O模式更趨復(fù)雜，I/O瓶頸問題日益突出。

超級計(jì)算機(jī)的存儲系統(tǒng)和I/O性能越來越引起重視，2017年世界超算大會首次發(fā)布了對高性能存儲系統(tǒng)進(jìn)行排名的IO500排行榜。為了綜合反映存儲系統(tǒng)I/O性能，IO500測試分為2部分，一部分采用IOR程序測試I/O帶寬，另一部分采用mdtest程序和find等命令進(jìn)行元數(shù)據(jù)測試。測試又分為easy和hard 2種模式，其中easy模式觀察存儲系統(tǒng)最容易滿足的I/O模式，hard模式則用來反映當(dāng)前存儲系統(tǒng)最不適應(yīng)的I/O模式。IO500的推出倡導(dǎo)業(yè)界更加關(guān)注存儲系統(tǒng)性能，基于IO500的I/O性能已成為衡量超級計(jì)算機(jī)性能的重要指標(biāo)。

近兩年IO500排名前10的系統(tǒng)中，Lustre、BeeGFS 和GPFS(General Paralle File System) 3種并行文件系統(tǒng)占有明顯的優(yōu)勢。Lustre文件系統(tǒng)采用基于對象存儲的集中共享式并行存儲架構(gòu)，通過客戶端Cache和大數(shù)據(jù)塊傳輸協(xié)議提高文件訪問帶寬，在HPC領(lǐng)域應(yīng)用最為廣泛。IBM公司研發(fā)的GPFS文件系統(tǒng)，廣泛應(yīng)用于IBM公司研發(fā)的超級計(jì)算機(jī)中。新興的BeeGFS文件系統(tǒng)由歐洲的E級計(jì)算項(xiàng)目DEEP-ER研發(fā)，提供開放源代碼和免費(fèi)軟件，在HPC領(lǐng)域具有良好的應(yīng)用前景。業(yè)界對Lustre和GPFS等不同的并行文件系統(tǒng)進(jìn)行了長期深入的研究，但對新興的BeeGFS的研究卻很少。

本文對BeeGFS的 I/O堆棧各個(gè)層次進(jìn)行了性能評測、性能損耗分析，分析確定了影響性能的關(guān)鍵因素，并從多個(gè)方面探索并行文件系統(tǒng)性能優(yōu)化的關(guān)鍵技術(shù)，包括元數(shù)據(jù)管理模塊優(yōu)化設(shè)計(jì)、并行I/O處理模型優(yōu)化設(shè)計(jì)和網(wǎng)絡(luò)通信性能優(yōu)化等關(guān)鍵技術(shù)。

2 相關(guān)工作與挑戰(zhàn)

2.1 相關(guān)工作

為HPC系統(tǒng)提供可靠、高效且易于使用的存儲和文件系統(tǒng)是當(dāng)前構(gòu)建高性能計(jì)算機(jī)系統(tǒng)面臨的主要問題之一，因?yàn)楦鞣N各樣的科學(xué)應(yīng)用程序都會生成和分析大量數(shù)據(jù)。文件系統(tǒng)提供了到基礎(chǔ)存儲設(shè)備的接口，并將標(biāo)識符(例如文件名)鏈接到存儲硬件的相應(yīng)物理地址。在HPC系統(tǒng)中，通過部署并行分布式文件系統(tǒng)可以將數(shù)據(jù)分布在眾多存儲設(shè)備上，并結(jié)合特殊功能以提高吞吐量和系統(tǒng)容量。隨著存儲系統(tǒng)數(shù)據(jù)量的迅速增加，HPC系統(tǒng)需要更復(fù)雜、更高效的數(shù)據(jù)管理方法來處理大量信息。同時(shí)，如何利用功能更強(qiáng)大的存儲和網(wǎng)絡(luò)技術(shù)，如高速存儲介質(zhì)、100 Gbps高速遠(yuǎn)程直接數(shù)據(jù)讀取RDMA(Remote Direct Memory Access)網(wǎng)絡(luò)，也對HPC存儲系統(tǒng)的構(gòu)建提出了挑戰(zhàn)。

在并行文件系統(tǒng)研究方面，基于閃存固態(tài)盤SSD(Solid State Drive)[1 - 5]和非易失性存儲器NVM(Non-Volatile Memory)[6 - 11]優(yōu)化設(shè)計(jì)的并行文件系統(tǒng)軟件嘗試?yán)么鎯τ布δ軄頊p少軟件開銷，但系統(tǒng)整體性能仍不理想。

在文件系統(tǒng)的元數(shù)據(jù)組件上，現(xiàn)有工作設(shè)計(jì)了利用類似LevelDB的Key-Value來實(shí)現(xiàn)單機(jī)的文件系統(tǒng)，如TableFS[12]利用LevelDB實(shí)現(xiàn)了用戶空間文件系統(tǒng)，但TableFS只是簡單地介紹了FS層次結(jié)構(gòu)到鍵值KV(Key Value)存儲的映射，沒有解決重命名以及文檔夾移動等問題。BetrFS[13]則將類似的思路搬到了內(nèi)核空間，研究并設(shè)計(jì)了重命名、移動文檔夾等操作的實(shí)現(xiàn)。IndexFS則是將環(huán)境放到了分布式文件系統(tǒng)下面，主要是用KVS存儲分布式文件系統(tǒng)的元數(shù)據(jù)，但I(xiàn)ndexFS仍未發(fā)揮KVS的性能，比如將一個(gè)文件的文件元數(shù)據(jù)全部存儲在單個(gè)值中，僅修改一部分值時(shí)，必須重置鍵值存儲中的所有值，這會導(dǎo)致不必要的(反序列化)開銷，造成性能降低[14]。Linux 5.1采用了由Jens Axboe開發(fā)的一個(gè)新的異步I/O框架io_uring[15]及實(shí)現(xiàn)技術(shù)，有效解決了Linux內(nèi)核中原生AIO低效的問題，更適合高性能NVMe SSD，在部分場景性能高于Intel 的SPDK(Storage Performance Development Kit)的性能。

Table 1 Key-value used by/dir/file表1 獲取/dir/file過程中的Key和Value

Table 2 System performance of original BeeGFS表2 改進(jìn)前的BeeGFS性能測試結(jié)果

Table 3 System performance of optimized BeeGFS表3 改進(jìn)后的BeeGFS性能

Table 4 System performance comparison表4 改進(jìn)前后的性能對比

LocoFS[16]可以看作是從IndexFS改進(jìn)而來的一個(gè)架構(gòu)。架構(gòu)上一個(gè)主要的變化就是目錄的元數(shù)據(jù)和文檔的元數(shù)據(jù)分開保存，但目錄元數(shù)據(jù)結(jié)點(diǎn)存在擴(kuò)展性問題，同時(shí)這類方案還面臨rename效率問題。Intel的分布式異步對象存儲DAOS(Distributed Asynchronous Object Storage)[17]采用了SPDK Bulk數(shù)據(jù)并且在用戶空間中完全繞開操作系統(tǒng)。I/O操作繞過Linux內(nèi)核，從而節(jié)省了時(shí)間。而元數(shù)據(jù)構(gòu)建在Optane DIMM非易失內(nèi)存上，通過PMDK(Persistent Memory Development Kit)提供低延時(shí)的元數(shù)據(jù)索引與查詢。在Lustre 2.10.X中實(shí)現(xiàn)了多軌MR(Multi-Rail)[18]功能，它允許結(jié)點(diǎn)上的多個(gè)相同類型的接口在同一個(gè)網(wǎng)絡(luò)(例如tcp0、o2ib0等)下分組一起使用。

當(dāng)前最流行和廣泛使用的并行分布式文件系統(tǒng)包括Lustre、GPFS、OrangeFS、Ceph和GlusterFS，主要是面向帶寬型業(yè)務(wù)和磁盤介質(zhì)，存在性能缺陷。Lustre文件系統(tǒng)的主要缺點(diǎn)是其使用串行元數(shù)據(jù)訪問模型，使得超量的并發(fā)文件操作非常慢，即便新版本提供分布式命名空間模型仍未完全解決并發(fā)文件操作在所有應(yīng)用場景中存在的問題。Ceph以對象存儲為核心，復(fù)雜的軟件棧影響性能。GlusterFS在寫入較小時(shí)存在嚴(yán)重問題，包括寫小文件和小寫大文件，另外GlusterFS在遞歸操作(ls，du，find，grep等)上非常慢，使得它幾乎無法用于大型文件系統(tǒng)上的交互操作。當(dāng)前這些并行分布式文件系統(tǒng)已很難滿足未來E級計(jì)算高性能存儲的需求。

近幾年BeeGFS嘗試解決性能問題，BeeGFS的優(yōu)點(diǎn)是可以分離元數(shù)據(jù)，提供更快的元數(shù)據(jù)訪問，同時(shí)還能夠以簡化的方式跨元數(shù)據(jù)結(jié)點(diǎn)分配每個(gè)目錄和子目錄的元數(shù)據(jù)操作。與GPFS一樣，BeeGFS可以根據(jù)需要添加更多元數(shù)據(jù)目標(biāo)(服務(wù)器)，提供了很好的系統(tǒng)擴(kuò)展性，且設(shè)置比Lustre MDS(Meta Data Server)更簡單。另外，BeeGFS能夠使用內(nèi)置隊(duì)列來線程化元數(shù)據(jù)/對象請求服務(wù)器，并能夠根據(jù)需要指定在每個(gè)元數(shù)據(jù)/對象服務(wù)器上產(chǎn)生多少線程。當(dāng)對文件系統(tǒng)上的小文件進(jìn)行數(shù)百萬次的超量請求時(shí)，可以避免串行請求瓶頸。

圖1為BeeGFS的系統(tǒng)架構(gòu)，包含元數(shù)據(jù)服務(wù)器MDS、對象存儲服務(wù)器OSS (Object Storage Server)、客戶端和網(wǎng)絡(luò)模塊 4個(gè)重要組件。當(dāng)前，盡管BeeGFS在小塊I/O以及元數(shù)據(jù)訪問方面具有優(yōu)勢，但實(shí)際測試表明BeeGFS仍存在性能瓶頸，有待進(jìn)一步深入改進(jìn)優(yōu)化性能。

Figure 1 System architecture of BeeGFS圖1 BeeGFS并行分布式文件系統(tǒng)架構(gòu)

2.2 文件系統(tǒng)讀寫瓶頸

BeeGFS是一款并行分布式文件系統(tǒng)，其核心組件MDS和OSS均是以結(jié)點(diǎn)內(nèi)的本地文件系統(tǒng)來承載元數(shù)據(jù)、數(shù)據(jù)的存儲。針對BeeGFS高效組織管理本地?cái)?shù)據(jù)是BeeGFS性能優(yōu)化的關(guān)鍵點(diǎn)之一。

通過對NVMe SSD裸設(shè)備和文件的對比測試，我們發(fā)現(xiàn)如下規(guī)律：

(1) 單盤SSD的帶寬性能與單盤上的文件系統(tǒng)的性能相當(dāng)；

(2) 單盤文件系統(tǒng)XFS 的IOPS是SSD性能的38%(讀取)和36%(寫入)；

(3) 10個(gè)盤文件系統(tǒng)(XFS)的帶寬是SSD性能的77%(讀取)和93%(寫入)；

(4) 10個(gè)盤文件系統(tǒng)(XFS)的IOPS是SSD性能的16%(讀取)和31%(寫入)。

從上面的數(shù)據(jù)可以看出，XFS在帶寬上相對SSD裸設(shè)備損耗較少，而IOPS只有裸盤SSD的31%以下，IOPS性能損失巨大，如何針對閃存構(gòu)建高IOPS、高帶寬文件系統(tǒng)是性能提升的一個(gè)研究方向，如果針對BeeGFS的數(shù)據(jù)存儲格式進(jìn)一步構(gòu)建私有文件系統(tǒng)，則能進(jìn)一步提升性能。

為了分析并行文件系統(tǒng)BeeGFS對性能的影響，本文構(gòu)建了5個(gè)客戶端同時(shí)訪問1個(gè)存儲端的環(huán)境，客戶端與存儲端均通過單個(gè)Intel公司的Omni-Path 100 Gbps網(wǎng)卡進(jìn)行通信。測試結(jié)果表明，單個(gè)客戶端帶寬最高為2.8 GB/s，不到物理帶寬11 GB/s的25%，一方面BeeGFS自身網(wǎng)絡(luò)處理影響了帶寬，另一方面單網(wǎng)卡限制了帶寬；并行文件系統(tǒng)的讀寫IOPS僅為本地文件系統(tǒng)的18.6%(讀取)和18%(寫入)。底層SSD繁忙度只有20%。而在BeeGFS的loop模式下，也就是數(shù)據(jù)并未寫入或未從本地文件系統(tǒng)讀取，loop模式與本地文件系統(tǒng)的帶寬相當(dāng)，但此時(shí)的IOPS僅為本地文件系統(tǒng)的48%(讀取)和42%(寫入)。

總之，當(dāng)BeeGFS處于高負(fù)載狀態(tài)時(shí)，本地文件系統(tǒng)的壓力依然不足，底層SSD的利用率也偏低，需要對其進(jìn)行改進(jìn)優(yōu)化。

2.3 元數(shù)據(jù)瓶頸

分布式文件系統(tǒng)中主要有4種元數(shù)據(jù)管理方案：單個(gè)元數(shù)據(jù)服務(wù)器(單MDS)方案(例如HDFS)、具有基于哈希分布的多元數(shù)據(jù)服務(wù)器方案(multi-MDS)(例如Gluster[19])、基于目錄的方案(例如CephFS[20])和基于條帶的方案(例如Lustre DNE，Giga+[21])。

與基于目錄的方案相比，基于散列和基于條帶的方案具有更好的可伸縮性，但犧牲了單個(gè)結(jié)點(diǎn)上的本地性。原因之一是，即使這些請求位于同一服務(wù)器中，多MDS方案也會向MDS發(fā)出多個(gè)請求，那么文件系統(tǒng)中的遞歸操作(ls,du,find,grep等)非常慢，嚴(yán)重情況下將使得它幾乎無法用于大型文件系統(tǒng)上的交互操作。

另外，在分布式文件系統(tǒng)中，經(jīng)常出現(xiàn)熱點(diǎn)數(shù)據(jù)，主要包括：(1)文件系統(tǒng)中的某個(gè)目錄是大目錄，該目錄下有幾萬、幾十萬甚至上百萬個(gè)文件。(2)文件系統(tǒng)同時(shí)出現(xiàn)多個(gè)熱點(diǎn)目錄和熱點(diǎn)文件，在該目錄下頻繁地進(jìn)行文件和子目錄的創(chuàng)建、刪除、修改、查找等操作。當(dāng)文件系統(tǒng)的這些熱點(diǎn)數(shù)據(jù)同時(shí)出現(xiàn)在某個(gè)服務(wù)器上時(shí)，將會導(dǎo)致該服務(wù)器負(fù)荷非常重，而其他服務(wù)器負(fù)荷很輕，從而出現(xiàn)嚴(yán)重的負(fù)載不均，大幅降低整個(gè)文件系統(tǒng)的總體性能。

針對BeeGFS進(jìn)行元數(shù)據(jù)方面的性能測試與分析，部署5個(gè)Client端，分別測試4個(gè)和5個(gè)MDS組成的元數(shù)據(jù)集群，文件創(chuàng)建、查看文件狀態(tài)和文件刪除的性能測試結(jié)果如圖2所示,其中橫坐標(biāo)軸表示每個(gè)Client的進(jìn)程數(shù)，縱坐標(biāo)軸表示IOPS。

Figure 2 Metadata performance of BeeGFS圖2 BeeGFS元數(shù)據(jù)性能測試

測試結(jié)果表明，文件創(chuàng)建性能最高為98 341 IOPS，查看文件狀態(tài)最大性能為384 449 IOPS，文件刪除最高性能為20 510 IOPS，根據(jù)BeeGFS的元數(shù)據(jù)分布方式：目錄隨機(jī)分布到元數(shù)據(jù)結(jié)點(diǎn)，文件仍然由父目錄所在的服務(wù)器處理，這些元數(shù)據(jù)操作大部分發(fā)生在單結(jié)點(diǎn)中，是利用本地文件系統(tǒng)的文件attr屬性來存儲約128字節(jié)的元數(shù)據(jù)。而在鍵值存儲中，比如著名的RocksDB，在單結(jié)點(diǎn)中對100萬條記錄對(Key：16 Bytes，Value：100 Bytes)進(jìn)行處理，其性能為隨機(jī)寫631 222 IOPS，隨機(jī)讀2 577 505 IOPS，而在pmemkv這類鍵值存儲中，性能更高。

對比KV存儲的隨機(jī)性能，分布式文件系統(tǒng)BeeGFS的元數(shù)據(jù)操作性能不到KV存儲性能的16%，因此BeeGFS利用本地文件系統(tǒng)的文件屬性來存儲元數(shù)據(jù)，存在較大的性能瓶頸。

3 BeeGFS的優(yōu)化

通過測試和分析，本文認(rèn)為BeeGFS當(dāng)前的主要性能瓶頸包括：

(1)BeeGFS利用本地文件系統(tǒng)的文件屬性來存儲元數(shù)據(jù)，存在較大的性能瓶頸，需要優(yōu)化元數(shù)據(jù)IOPS。

(2)本地文件系統(tǒng)的IOPS能力不足，需要BeeGFS的OSS組件提升文件并行讀寫效率，需要優(yōu)化I/O處理流程。

(3)大量的消息傳遞和小塊數(shù)據(jù)包導(dǎo)致網(wǎng)絡(luò)性能瓶頸，遠(yuǎn)沒有使高速網(wǎng)絡(luò)的帶寬飽和，還需要針對網(wǎng)絡(luò)進(jìn)行優(yōu)化。

針對上述BeeGFS性能瓶頸，本文基于KV實(shí)現(xiàn)元數(shù)據(jù)管理，以優(yōu)化元數(shù)據(jù)的性能，更適配高速非易失存儲介質(zhì)；重新設(shè)計(jì)了數(shù)據(jù)I/O處理模型，提升了數(shù)據(jù)處理并發(fā)度；借鑒多軌機(jī)制優(yōu)化通信網(wǎng)絡(luò)，支持多網(wǎng)卡以提升通信帶寬。

3.1 KV元數(shù)據(jù)

對于BeeGFS的一個(gè)元數(shù)據(jù)結(jié)點(diǎn)而言：目錄和文件的創(chuàng)建、刪除、stat等操作基于本地文件系統(tǒng)，效率低下，原因一是遵循POSIX語義而頻繁進(jìn)行文件open、close等系統(tǒng)調(diào)用，元數(shù)據(jù)存取進(jìn)行g(shù)etattr、setattr系統(tǒng)調(diào)用，頻繁的用戶態(tài)、內(nèi)核態(tài)切換導(dǎo)致性能低下；二是傳統(tǒng)I/O軟件棧和塊設(shè)備文件系統(tǒng)產(chǎn)生的系統(tǒng)開銷，塊設(shè)備文件系統(tǒng)(如EXT4)需要經(jīng)過諸多針對塊設(shè)備的軟件層次，例如I/O調(diào)度層、通用塊層和塊設(shè)備驅(qū)動層，而且文件系統(tǒng)自身定位數(shù)據(jù)復(fù)雜，諸多軟件層次會造成數(shù)據(jù)在各級緩沖區(qū)中的多次拷貝，造成大量額外的系統(tǒng)管理開銷及性能損失，特別是在新型存儲介質(zhì)上，比如NVDIMM，不能發(fā)揮非易失性內(nèi)存的性能。

當(dāng)前有一些解決方案引入KV store來構(gòu)建文件系統(tǒng)[23-26]。它們不僅向用戶導(dǎo)出簡單的接口(即get和put)，而且在存儲中使用有效的數(shù)據(jù)組織(例如日志結(jié)構(gòu)化的合并樹[27])。由于數(shù)據(jù)值是獨(dú)立的并且以這種簡單的方式進(jìn)行組織，因此KV存儲使小對象能夠被有效地訪問并提供出色的可伸縮性，這使其成為了文件系統(tǒng)元數(shù)據(jù)服務(wù)器最有前景的技術(shù)。在小型對象的文件系統(tǒng)元數(shù)據(jù)(例如inode和dirent)中已經(jīng)利用了KV存儲的優(yōu)點(diǎn)[23,24]。

本文采用鍵值KV存儲來存取元數(shù)據(jù)，并采用策略性的目錄、文件元數(shù)據(jù)放置方法，有如下3點(diǎn)：

(1)可配置目錄分布。默認(rèn)情況下，目錄將隨機(jī)分布到元數(shù)據(jù)結(jié)點(diǎn)。支持用戶在創(chuàng)建目錄前設(shè)置規(guī)則策略。

(2)充分利用本地性，文件仍然由父目錄所在的元數(shù)據(jù)服務(wù)器處理。

(3)在元數(shù)據(jù)服務(wù)器內(nèi)部，采用鍵值存儲KV替換低效的本地文件系統(tǒng)。

對比基于散列的元數(shù)據(jù)分布方式，散列方式雖可以有效地利用鍵值訪問性能，但是目錄列表、重命名目錄等操作引發(fā)了這種基于散列設(shè)計(jì)的性能問題。本文選擇RocksDB鍵值存儲，因?yàn)镽ocksDB可以將磁盤寫入與prefix查找和范圍掃描結(jié)合在一起，同時(shí)可以更好地發(fā)揮高速存儲介質(zhì)的性能。

文件系統(tǒng)樹表示為索引結(jié)點(diǎn)和邊緣的圖。索引結(jié)點(diǎn)包含有關(guān)文件或目錄的元數(shù)據(jù)，并由64位ID鍵索引。邊緣在文件系統(tǒng)樹中定義父子關(guān)系。key是父級的64位inode ID,與孩子的名稱串聯(lián)在一起，而值是孩子的inode ID。 這種表示方式允許高效地創(chuàng)建、刪除和重命名。根據(jù)上述規(guī)則，基于 KV 元數(shù)據(jù)結(jié)構(gòu)獲取/dir/file路徑，解析過程如表1和圖3所示。

Figure 3 Path to /dir/file based on KV metadata圖3 基于KV元數(shù)據(jù)結(jié)構(gòu)獲取/dir/file

算法1基于KV元數(shù)據(jù)結(jié)構(gòu)獲取/dir/file

輸入：/dir/file文件路徑。

輸出：/dir/file文件內(nèi)容。

步驟1root 的 inode ID為1，那么系統(tǒng)將 dir對象和其父對象的 inode ID進(jìn)行組合，得到一個(gè) key 〈1,dir〉。

步驟2系統(tǒng)根據(jù)步驟1得到的 key 〈1,dir〉，獲取dir 對象的 inode ID。從圖3可以看出,dir 對象對應(yīng)的 inode ID為2，對應(yīng)圖3的步驟i。

步驟3系統(tǒng)需要得到 file 對象的 inode ID，同樣也是構(gòu)造一個(gè)key，得到 〈2,file〉，從而確定file 對象的 inode ID，這里為 3，對應(yīng)圖3的步驟ii。

步驟4系統(tǒng)直接根據(jù) inode ID為 3，讀取file 的內(nèi)容，對應(yīng)圖中的步驟iii。

3.2 多軌網(wǎng)絡(luò)通信機(jī)制

在高性能計(jì)算系統(tǒng)中，網(wǎng)絡(luò)通常為高速以太網(wǎng)、IB(InfiniBand)、Omni-Path等，由于結(jié)點(diǎn)間大量的消息傳遞，通常采用RDMA技術(shù)實(shí)現(xiàn)零拷貝通信。對于分布式并行文件系統(tǒng)，同樣如此，通過RMDA啟動多個(gè)數(shù)據(jù)服務(wù)器的讀寫操作，這使得客戶端能夠以接近RDMA峰值帶寬的速率訪問數(shù)據(jù)。因此，提升網(wǎng)絡(luò)帶寬有利于提升文件系統(tǒng)的性能，但是，添加更快的接口意味著要替換大部分或全部網(wǎng)絡(luò)。本文采用多軌網(wǎng)絡(luò)通信機(jī)制向服務(wù)器添加更多的網(wǎng)絡(luò)接口來增加帶寬和IOPS。

BeeGFS支持TCP/IP網(wǎng)絡(luò)，并基于OFED(Open Fabrics Enterprise Distribution) ibverbs API實(shí)現(xiàn)了對Infiniband、RoCE (RDMA over Converged Ethernet)和Omni-Path的RDMA協(xié)議的支持。但是， BeeGFS僅支持單網(wǎng)卡的并發(fā)數(shù)據(jù)傳輸和網(wǎng)絡(luò)通信，從測試數(shù)據(jù)來看，這嚴(yán)重限制了系統(tǒng)的網(wǎng)絡(luò)帶寬。本文通過增加網(wǎng)絡(luò)接口卡和修改客戶端模塊，支持客戶端到元數(shù)據(jù)服務(wù)器、對象存儲服務(wù)器的多網(wǎng)卡并行數(shù)據(jù)傳輸和多軌通信。同時(shí)，通過設(shè)置配置文件，靈活實(shí)現(xiàn)了使用多個(gè)網(wǎng)絡(luò)接口連接到同一個(gè)網(wǎng)絡(luò)、使用多個(gè)網(wǎng)絡(luò)接口連接到多個(gè)網(wǎng)絡(luò)、接口可以同時(shí)使用3種功能。

3.3 異步I/O模型

在BeeGFS系統(tǒng)中，OSS服務(wù)構(gòu)建在用戶態(tài)上，通過多線程策略來提升I/O并發(fā)度，但這些線程的處理步驟比較冗長，而且由于每個(gè)階段的結(jié)果與下一階段的執(zhí)行有關(guān)系，效率仍然低下，并未實(shí)現(xiàn)流水線操作。BeeGFS的OSS對文件數(shù)據(jù)的I/O處理流程如圖4所示。對于大量的小文件I/O，消息傳遞會創(chuàng)建許多小的請求，每個(gè)工作線程的處理步驟很多，同步處理這些請求資源開銷很大。

Figure 4 Original I/O flow in BeeGFS OSS圖4 BeeGFS原有OSS文件I/O處理流程

一種優(yōu)化思路是將任務(wù)的處理分解為若干個(gè)處理階段，將其中緩慢的讀寫文件系統(tǒng)步驟通過異步I/O分離出來，上一個(gè)階段任務(wù)的結(jié)果交給下一個(gè)階段線程來處理，這樣每個(gè)線程的處理是并行的，可以充分利用時(shí)間重疊和分時(shí)共享資源，提高并行處理效率。優(yōu)化后的I/O處理流程如圖5所示。優(yōu)化I/O處理模型摒棄了傳統(tǒng)的aio調(diào)用，采用了io_uring全新的syscall和全新的異步async API接口來對接高性能NVMe SSD，以獲得更高的IOPS性能和更好的兼容性。高吞吐異步I/O模型如圖6所示?？梢赃M(jìn)一步地分離讀寫I/O請求，構(gòu)建不同的sq_ring/cq_ring對來提升整體性能。同時(shí)針對多核CPU對線程進(jìn)行分組綁核，減小在不同的核上切換調(diào)度造成的開銷，進(jìn)而提升線程的運(yùn)行效率。

Figure 5 Optimized I/O flow in BeeGFS OSS圖5 OSS存儲服務(wù)器I/O處理優(yōu)化流程

Figure 6 Asynchronous I/O parallel processing model圖6 異步I/O并行處理模型

4 實(shí)驗(yàn)與評估

本文基于驗(yàn)證系統(tǒng)對BeeGFS并行文件系統(tǒng)進(jìn)行了分析評測，采用IO500-dev測試項(xiàng)對優(yōu)化前后的I/O性能進(jìn)行了對比測試。BeeGFS文件系統(tǒng)開發(fā)驗(yàn)證系統(tǒng)結(jié)構(gòu)如圖7所示，由10個(gè)計(jì)算結(jié)點(diǎn)和42個(gè)存儲結(jié)點(diǎn)組成，同一存儲結(jié)點(diǎn)同時(shí)承擔(dān)元數(shù)據(jù)服務(wù)器(MDS)與對象存儲服務(wù)器(OSS)角色，通過100 Gbps Omni-Path網(wǎng)絡(luò)進(jìn)行集群系統(tǒng)互連與數(shù)據(jù)傳輸，通過以太網(wǎng)絡(luò)對集群進(jìn)行監(jiān)控管理。

Figure 7 Networking configuration of BeeGFS圖7 BeeGFS組網(wǎng)圖

存儲服務(wù)器配置：2個(gè)Intel Xeon Gold 6134 CPU，16核，主頻 3.20 GHz，396 GB DDR4內(nèi)存，配置12塊紫光NVMe SSD硬盤，單盤容量1.6 TB，單盤讀寫帶寬可分別達(dá)到2.8 GB/s和1.4 GB/s。操作系統(tǒng)為CentOS Linux 7.7，內(nèi)核版本為3.10.0- 1062.4.3.el7。

在上述開發(fā)驗(yàn)證系統(tǒng)中，采用IO500-dev測試項(xiàng)對改進(jìn)前后的BeeGFS并行文件系統(tǒng)進(jìn)行了分析評測，測試結(jié)果分別如表2和表3所示。其中測試負(fù)載：pre_node_process=64,mdtest_create_file_nun=500000,mdtest_numtarget=1,ior_numtarget=464。

通過分析發(fā)現(xiàn)，本文改進(jìn)方法可以有效提升BeeGFS的性能。在IOPS的測試方面，find等操作的IOPS性能提升122%，這主要是KV 元數(shù)據(jù)的改進(jìn)帶來的效果，而delete 和read 的性能提升主要由異步I/O的設(shè)計(jì)優(yōu)化提供，因?yàn)檫@些操作還需要訪問文件數(shù)據(jù)，異步I/O的優(yōu)化可以提升

此操作。但是,easy_stat和hard_stat性能稍有下降，在3%以內(nèi)，可能是測試差異造成的，也可能是KV元數(shù)據(jù)的設(shè)計(jì)中路徑尋找開銷過大造成的，后期將會繼續(xù)進(jìn)行相關(guān)的研究。另外,在帶寬方面引入的多軌的設(shè)計(jì)，使得文件系統(tǒng)的帶寬提升非常明顯，如表4所示分別提升了55%，3 600%，41%和126%。

5 結(jié)束語

新興的BeeGFS并行文件系統(tǒng)在HPC領(lǐng)域具有良好的應(yīng)用前景。本文對BeeGFS各個(gè)I/O棧層次進(jìn)行性能評測和性能損耗分析，確定影響B(tài)eeGFS系統(tǒng)性能的關(guān)鍵因素，并從多方面探索并行文件系統(tǒng)性能優(yōu)化的關(guān)鍵技術(shù)。設(shè)計(jì)實(shí)現(xiàn)了基于鍵值存儲的元數(shù)據(jù)管理模塊以優(yōu)化元數(shù)據(jù)IOPS，基于異步I/O和多線程技術(shù)的并行I/O處理模型以提升I/O處理并發(fā)度，并采用多軌通信機(jī)制以提高網(wǎng)絡(luò)通信帶寬。構(gòu)建了IO500性能評測環(huán)境，在相同的配置環(huán)境下，I/O帶寬和元數(shù)據(jù)2類基準(zhǔn)測試結(jié)果表明，I/O帶寬由25 GB/s提升為93 GB/s，提高了3.7倍；IOPS由994.4 KIOPS提升為1 190.2 KIOPS，總分由157.97分提升為332.6分，改進(jìn)后的并行文件系統(tǒng)在元數(shù)據(jù)、數(shù)據(jù)讀寫性能方面有大幅提升，IO500測分是原有系統(tǒng)的2倍以上。

下一步工作將探索如何進(jìn)一步提升BeeGFS并行文件系統(tǒng)性能，一方面構(gòu)建新的本地?cái)?shù)據(jù)存儲引擎，取代通用的本地XFS文件系統(tǒng)；另一方面將本地文件系統(tǒng)放入高速存儲層，實(shí)現(xiàn)比分層存儲管理更好的集成管理。