BeeGFS并行文件系統性能優化技術研究

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

(國防科技大學計算機學院,湖南 長沙 410073)

1 引言

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

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

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

本文對BeeGFS的 I/O堆棧各個層次進行了性能評測、性能損耗分析，分析確定了影響性能的關鍵因素，并從多個方面探索并行文件系統性能優化的關鍵技術，包括元數據管理模塊優化設計、并行I/O處理模型優化設計和網絡通信性能優化等關鍵技術。

2 相關工作與挑戰

2.1 相關工作

為HPC系統提供可靠、高效且易于使用的存儲和文件系統是當前構建高性能計算機系統面臨的主要問題之一，因為各種各樣的科學應用程序都會生成和分析大量數據。文件系統提供了到基礎存儲設備的接口，并將標識符(例如文件名)鏈接到存儲硬件的相應物理地址。在HPC系統中，通過部署并行分布式文件系統可以將數據分布在眾多存儲設備上，并結合特殊功能以提高吞吐量和系統容量。隨著存儲系統數據量的迅速增加，HPC系統需要更復雜、更高效的數據管理方法來處理大量信息。同時，如何利用功能更強大的存儲和網絡技術，如高速存儲介質、100 Gbps高速遠程直接數據讀取RDMA(Remote Direct Memory Access)網絡，也對HPC存儲系統的構建提出了挑戰。

在并行文件系統研究方面，基于閃存固態盤SSD(Solid State Drive)[1 - 5]和非易失性存儲器NVM(Non-Volatile Memory)[6 - 11]優化設計的并行文件系統軟件嘗試利用存儲硬件功能來減少軟件開銷，但系統整體性能仍不理想。

在文件系統的元數據組件上，現有工作設計了利用類似LevelDB的Key-Value來實現單機的文件系統，如TableFS[12]利用LevelDB實現了用戶空間文件系統，但TableFS只是簡單地介紹了FS層次結構到鍵值KV(Key Value)存儲的映射，沒有解決重命名以及文檔夾移動等問題。BetrFS[13]則將類似的思路搬到了內核空間，研究并設計了重命名、移動文檔夾等操作的實現。IndexFS則是將環境放到了分布式文件系統下面，主要是用KVS存儲分布式文件系統的元數據，但IndexFS仍未發揮KVS的性能，比如將一個文件的文件元數據全部存儲在單個值中，僅修改一部分值時，必須重置鍵值存儲中的所有值，這會導致不必要的(反序列化)開銷，造成性能降低[14]。Linux 5.1采用了由Jens Axboe開發的一個新的異步I/O框架io_uring[15]及實現技術，有效解決了Linux內核中原生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 改進前的BeeGFS性能測試結果

Table 3 System performance of optimized BeeGFS表3 改進后的BeeGFS性能

Table 4 System performance comparison表4 改進前后的性能對比

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

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

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

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

Figure 1 System architecture of BeeGFS圖1 BeeGFS并行分布式文件系統架構

2.2 文件系統讀寫瓶頸

BeeGFS是一款并行分布式文件系統，其核心組件MDS和OSS均是以結點內的本地文件系統來承載元數據、數據的存儲。針對BeeGFS高效組織管理本地數據是BeeGFS性能優化的關鍵點之一。

通過對NVMe SSD裸設備和文件的對比測試，我們發現如下規律：

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

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

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

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

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

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

總之，當BeeGFS處于高負載狀態時，本地文件系統的壓力依然不足，底層SSD的利用率也偏低，需要對其進行改進優化。

2.3 元數據瓶頸

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

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

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

針對BeeGFS進行元數據方面的性能測試與分析，部署5個Client端，分別測試4個和5個MDS組成的元數據集群，文件創建、查看文件狀態和文件刪除的性能測試結果如圖2所示,其中橫坐標軸表示每個Client的進程數，縱坐標軸表示IOPS。

Figure 2 Metadata performance of BeeGFS圖2 BeeGFS元數據性能測試

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

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

3 BeeGFS的優化

通過測試和分析，本文認為BeeGFS當前的主要性能瓶頸包括：

(1)BeeGFS利用本地文件系統的文件屬性來存儲元數據，存在較大的性能瓶頸，需要優化元數據IOPS。

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

(3)大量的消息傳遞和小塊數據包導致網絡性能瓶頸，遠沒有使高速網絡的帶寬飽和，還需要針對網絡進行優化。

針對上述BeeGFS性能瓶頸，本文基于KV實現元數據管理，以優化元數據的性能，更適配高速非易失存儲介質；重新設計了數據I/O處理模型，提升了數據處理并發度；借鑒多軌機制優化通信網絡，支持多網卡以提升通信帶寬。

3.1 KV元數據

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

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

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

(1)可配置目錄分布。默認情況下，目錄將隨機分布到元數據結點。支持用戶在創建目錄前設置規則策略。

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

(3)在元數據服務器內部，采用鍵值存儲KV替換低效的本地文件系統。

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

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

Figure 3 Path to /dir/file based on KV metadata圖3 基于KV元數據結構獲取/dir/file

算法1基于KV元數據結構獲取/dir/file

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

輸出：/dir/file文件內容。

步驟1root 的 inode ID為1，那么系統將 dir對象和其父對象的 inode ID進行組合，得到一個 key 〈1,dir〉。

步驟2系統根據步驟1得到的 key 〈1,dir〉，獲取dir 對象的 inode ID。從圖3可以看出,dir 對象對應的 inode ID為2，對應圖3的步驟i。

步驟3系統需要得到 file 對象的 inode ID，同樣也是構造一個key，得到 〈2,file〉，從而確定file 對象的 inode ID，這里為 3，對應圖3的步驟ii。

步驟4系統直接根據 inode ID為 3，讀取file 的內容，對應圖中的步驟iii。

3.2 多軌網絡通信機制

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

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

3.3 異步I/O模型

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

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

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

Figure 5 Optimized I/O flow in BeeGFS OSS圖5 OSS存儲服務器I/O處理優化流程

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

4 實驗與評估

本文基于驗證系統對BeeGFS并行文件系統進行了分析評測，采用IO500-dev測試項對優化前后的I/O性能進行了對比測試。BeeGFS文件系統開發驗證系統結構如圖7所示，由10個計算結點和42個存儲結點組成，同一存儲結點同時承擔元數據服務器(MDS)與對象存儲服務器(OSS)角色，通過100 Gbps Omni-Path網絡進行集群系統互連與數據傳輸，通過以太網絡對集群進行監控管理。

Figure 7 Networking configuration of BeeGFS圖7 BeeGFS組網圖

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

在上述開發驗證系統中，采用IO500-dev測試項對改進前后的BeeGFS并行文件系統進行了分析評測，測試結果分別如表2和表3所示。其中測試負載：pre_node_process=64,mdtest_create_file_nun=500000,mdtest_numtarget=1,ior_numtarget=464。

通過分析發現，本文改進方法可以有效提升BeeGFS的性能。在IOPS的測試方面，find等操作的IOPS性能提升122%，這主要是KV 元數據的改進帶來的效果，而delete 和read 的性能提升主要由異步I/O的設計優化提供，因為這些操作還需要訪問文件數據，異步I/O的優化可以提升

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

5 結束語

新興的BeeGFS并行文件系統在HPC領域具有良好的應用前景。本文對BeeGFS各個I/O棧層次進行性能評測和性能損耗分析，確定影響BeeGFS系統性能的關鍵因素，并從多方面探索并行文件系統性能優化的關鍵技術。設計實現了基于鍵值存儲的元數據管理模塊以優化元數據IOPS，基于異步I/O和多線程技術的并行I/O處理模型以提升I/O處理并發度，并采用多軌通信機制以提高網絡通信帶寬。構建了IO500性能評測環境，在相同的配置環境下，I/O帶寬和元數據2類基準測試結果表明，I/O帶寬由25 GB/s提升為93 GB/s，提高了3.7倍；IOPS由994.4 KIOPS提升為1 190.2 KIOPS，總分由157.97分提升為332.6分，改進后的并行文件系統在元數據、數據讀寫性能方面有大幅提升，IO500測分是原有系統的2倍以上。

下一步工作將探索如何進一步提升BeeGFS并行文件系統性能，一方面構建新的本地數據存儲引擎，取代通用的本地XFS文件系統；另一方面將本地文件系統放入高速存儲層，實現比分層存儲管理更好的集成管理。