本篇文章發表于頂級會議 FAST 2023，由無錫國家超級計算中心、清華大學、山東大學、中國工程院的學者為我們分享了他們在尖端超級計算機和高性能計算領域的最新的成果，提出了一種名為 HadaFS 的新型 Burst Buffer 文件系統，實現了可擴展性和性能的優勢與數據共享和部署成本的優勢的良好結合。

相關文章： 收藏：多家Burst Buffer存儲技術解析（附下載） Burst Buffer技術為何在HPC如此盛行

一、背景

高性能計算（HPC）正在經歷計算規模和數據爆發式增長的時代。為了滿足 HPC 應用不斷增長的 I/O 需求或突發流量 I/O 性能需求，研究人員提出 Burst Buffer（BB）技術，通過 SSD 等新型存儲介質構建數據加速層，作為前端計算和后端存儲之間的緩沖區，為 HPC 應用提供高速 I/O 服務，提高了系統的性能。

取決于 SSD 陣列的部署位置 ，BB可以分為兩種類型：

1）本地BB，即SSD作為本地磁盤部署在每個計算節點上，專門為單個計算節點服務；
2）共享BB，即SSD部署在計算節點可以訪問的專用節點上 （例如 I/O 轉發節點），以支持共享數據訪問。

本地 BB 具有良好的可擴展性和性能優勢，系統性能可以隨著計算節點的數量線性增長。但本地 BB 數據共享不友好，要么以靜態數據遷移方式運行，要么需要應用程序通過計算節點遷移數據，遷移效率低下，造成計算資源浪費。本地 BB 還會造成嚴重的資源浪費，因為 HPC 應用程序之間 I/O 負載的差異巨大，數據密集型應用程序相對較少。未來隨著超級計算機規模的迅速擴大，本地BB的部署成本將急劇上升。

共享 BB 天然具有數據共享和部署成本的優勢，但難以為數十萬規模的客戶端提供高效的數據訪問處理性能。如何統一本地BB和共享BB的優勢，滿足多樣化的應用需求，降低BB的建設成本，支持大規模的BB數據管理和遷移，是亟待解決的問題。BB 雖然具有高性能的優勢，但具有容量小的缺點，所以 BB 必須與 GFS（如 Lustre 等全局文件系統）協同工作才能滿足容量要求。

SNS基于神威新一代異構高性能眾核處理器和互聯網絡芯片構建，采用與神威太湖之光相似的架構。超級計算機由計算系統、互聯網絡系統、軟件系統、存儲系統、維護診斷系統、供電系統和冷卻系統組成。下圖顯示了總體架構。

圖1SNS的架構

二、動機問題

BB 技術已被廣泛引入尖端超級計算機，但現有的主流 BB 技術仍然存在許多局限性。

問題1：
隨著百億億級計算的壁壘被打破，超級計算機的 I/O 并發量可達數十萬，同時 AI、工作流等數據共享應用占比提升導致 I/O 需求發生變化，大規模數據的高速共享存儲對 BB 架構的可擴展性提出了挑戰。

現有超級計算機計算機采用的方案各有優缺點，例如，Frontier 使用獨立硬件分別構建本地 BB 和共享 BB，但這種方法需要很多加速設備（SSD），建設和維護成本高。

問題2：
傳統的文件系統的文件管理在目錄樹結構中實現并且嚴格遵循 POSIX 協議，但在 HPC 中，計算節點通常負責讀寫數據，很少執行目錄樹訪問，通過放寬 POSIX 協議也可以提高性能。不同應用程序對文件系統一致性的需求不同，一致性程度越高 ，它的適應性就越強，但代價是開銷越大。靈活地選擇一致性語義來平衡應用程序的需求并利用 BB 性能是一個很大的挑戰。

問題3：
大多數應用程序都可以使用 BB 來加快 I/O 性能，但 BB 的利用率較低，需要為用戶開發靈活的數據管理工具。BB 作為高速緩沖區，并不是應用程序持久化存儲數據的地方，因此 BB 系統需要考慮高效便捷地在 BB 和 GFS 之間遷移數據。目前還不支持用戶在應用運行過程中動態管理 BB 的數據遷移，非常不利于 BB 的高效利用。

從成本控制的角度出發，共享 BB 部署更適合未來的超大規模計算節點系統，因為共享 BB 可以部署在計算或數據轉發節點上。為了解決上述問題，本文研究如何從共享 BB 模型開始，獲得本地 BB 模型的優勢，以更好地滿足百億億級及以上 HPC 應用程序的需求。

三、HadaFS的設計與實現

HadaFS概述

圖2 HadaFS的架構

HadaFS 相當于是堆疊在磁盤陣列或存儲服務器的全局文件系統上的一個分布式文件系統，HadaFS 的整體架構如上圖所示，包括HadaFS 客戶端、HadaFS 服務器、數據管理工具 Hadash。

?Hadash 運行在用戶登錄節點上，用于管理全局文件系統與 HadaFS 之間的數據遷移。

?HadaFS 客戶端運行在計算節點上，作為一個靜態/動態庫，攔截應用程序的 POSIX I/O 請求并將其重定向到 HadaFS 服務器。

?HadaFS 服務器運行在部署 NVMe SSD 的專用突發緩沖節點上，提供全局數據和元數據分離的存儲服務。

HadaFS 作為共享突發緩沖文件系統，可以為每個客戶端提供全局視圖。HadaFS 中的每個文件都與兩種類型的服務器相關聯。一種是數據存儲服務器，通過 NVMe SSD 上的基礎文件系統存儲 HadaFS 文件的數據，另一種是元數據存儲服務器，通過高性能數據庫（RocksDB）存儲 HadaFS 文件的元數據。

Localized Triage Architecture（LTA，本地化分流架構）

HadaFS 遵循繞過內核的思路，直接將客戶端掛載到應用程序中使用，避免引入內核的I/O請求stage-in和stage-out開銷。為了更好地給應用程序提高全局文件視圖，HadaFS 提出了名為 LTA 的新方法，每個 HadaFS 客戶端只連接一臺HadaFS 服務器（橋接服務器），橋接服務器負責處理客戶端產生的所有I/O請求，并將數據寫入底層文件。當客戶端需要訪問另一臺服務器上的數據時，必須通過橋接服務器進行轉發。因此，服務器是一個全連接結構。

LTA 為每個計算節點匹配了一個橋接服務器以提供相當于本地 BB 的服務，并通過所有橋接服務器之間的全互聯支持所有客戶端的共享，結合了本地 BB 和共享 BB 的優點。

LTA 還提供了新的掛載接口，應用程序可以指定客戶端到服務器的映射，這有助于減少數據轉發。HadaFS 掛載后，應用程序可以通過與 POSIX 文件操作完全一樣的接口進行 I/O 操作。

文件命名空間和元數據處理

在 HPC 中計算節點通常負責讀寫數據，很少執行目錄樹訪問。為了提高可擴展性和性能，HadaFS 放棄了目錄樹的思想，采用了全路徑索引方法。數據存儲在生成該文件的 HadaFS 客戶端對應的橋接服務器上，文件元數據以 key-value 方式存儲，文件路徑的哈希值是一個全局唯一ID（key）。

每個 HadaFS 服務器上都維護著兩種元數據數據庫，它們的數據結構如下圖所示。

圖3 HadaFS服務器上的兩張K-V表

本地元數據數據庫（LMDB）存儲了文件在本地讀寫過程中會變化的一些元信息，全局元數據數據庫（GMDB）存儲文件在所有服務器讀寫訪問過程中會變化的一些元信息。GMDB 負責維護文件數據段位置的全局列表，以支持 HadaFS 服務器之間數據的全局共享。注意：每個服務器都會維護本地文件的 GMDB。

元數據數據庫的 key 由用戶的 UID、GID 和 PATH 組成，GID 和 UID 用于控制字符串檢索的范圍，因為 HadaFS 使用字符串前綴匹配來檢索文件。

數據管理工具 Hadash

Hadash 支持用戶在目錄樹視圖中檢索和管理文件，按功能分為兩類：元數據信息查詢和數據遷移。

元數據信息查詢主要提供 ls、du、find、grep 等命令，Hadash 從元數據庫中獲取這些查詢類型操作的信息。其中 ls、find 支持目錄樹視圖的文件信息查詢，Hadash 采用前綴匹配的方式來呈現一個虛擬的目錄樹，前綴匹配的方式可以通過 LMDB 在本地執行。其他涉及數據遷移的命令，Hadash 通過特定的 Redis 管道將命令發送到 HadaFS 服務器上的數據管理模塊執行。下圖顯示了從 HadaFS 到 GFS 的數據遷移流程示例。

圖4 Hadash的退出流程

HadaFS 其他的一些優化設計

HadaFS 采用了寬松的一致性語義，依賴于基本文件系統（ext4）的緩存機制來提高性能，其一致性語義主要依賴于元數據同步，不支持在客戶端和服務端緩存數據。為此，HadaFS針對不同的應用場景提出了三種元數據同步策略。

?mode1: 是異步更新所有元數據（對應最終一致性語義）。文件的所有操作都先在橋接服務器本地執行，之后元數據會從 LMDB 異步更新到 GMDB，適用于無數據依賴的場景。

?mode2: 是同步更新部分元數據，異步更新部分元數據（對應會話一致性語義和提交一致性語義）。文件創建時同步更新元數據，文件讀寫時異步更新元數據，或者通過 flush 操作同步更新。

?mode3: 是在文件訪問過程中同步所有打開、讀取和寫入操作的元數據（比強一致性語義略弱）。

HadaFS 沒有使用分布式鎖機制，因此HadaFS 本身很難保證數據的一致性，只有在第三種元數據同步策略下才支持原子寫。為了保證數據的一致性，用戶至少要了解應用程序的文件共享模式，可以通過 Darshan、Beacon 等獲得，自行保證數據一致性。

眾所周知，超級計算機上同時運行著很多作業。這些作業往往會爭奪共享資源，從而導致 I/O 干擾。將客戶端動態映射到服務器也有助于提高應用程序性能。得益于HadaFS靈活的設計，用戶可以動態制定 HadaFS 客戶端到 HadaFS 服務器的連接關系，可以有效幫助隔離不同應用的BB資源，解決作業間的 I/O 干擾，缺點是對運維人員的要求略高。

四、性能評估

本文在神威新一代超級計算機（SNS）上進行評估，以測試 HadaFS 的性能。下圖顯示了 HadaFS 的部署。SNS 包含超過 10 萬個計算節點，每個節點最多可以啟動 6 個 MPI 進程和 6 個 HadaFS 客戶端。也就是說整機可以支持超過 60 萬個 MPI 進程和 60 萬個 HadaFS 客戶端。共有 600 個 I/O 轉發節點，每個 I/O 轉發節點配置兩塊 3.2TB 的 NVMe SSD（每塊NVMe SSD對應一臺 HadaFS 服務器，支持 HadaFS 文件的數據和元數據的存儲）。所有節點使用 SWnet 網絡互連，HadaFS 使用基于 SWne t的 RDMA 協議傳輸數據。

圖5 HadaFS的部署

評估的對比對象為：BeeGFS（許多超級計算機用來管理 BB 的并行文件系統）和 GFS（SNS 中基于LWFS 和 Lustre 的傳統并行文件系統)。

元數據訪問性能評估

首先使用 MDTest（元數據性能評估基準）來比較 HadaFS、GFS 和 BeeGFS 在 1024、4096、16384 和 65536 個進程的并行規模下的元數據性能差異。下圖(a)、(b) 和 (c) 分別顯示了 Create、Stat 和 Remove 的 OPS 比較。Mode1 具有最高的性能，Mode2 的性能與 Mode3 相當，因為在 MDTest 設置中沒有讀/寫操作。但 BeeGFS 無法擴展到 65536 個進程，需要掛載 16384 個客戶端節點，但超過 10000 個節點后批量掛載不容易成功。由于 LWFS 數據轉發造成的性能開銷和 Lustre 的元數據服務器有限，傳統文件系統 GFS 的性能最差。

圖6元數據性能比較

數據訪問性能評估

接下來使用 IOR（數據性能評估基準）來比較并行規模為 1024、4096、16384 和 65536 進程的 HadaFS、GFS 和 BeeGFS 之間的 I/O 帶寬差異。HadaFS 和 BeeGFS 分別使用 4、16、64、256 個 I/O 轉發節點。下圖顯示了結果。對于 HadaFS，Mode1 性能最高，其次是 Mode2，最后是 Mode3。當規模達到 65536 個進程時，HadaFS 的性能比其他文件系統要好得多。對于讀取操作，HadaFS 的表現十分接近 SSD 的理論性能極限。對于寫操作，由于無法利用內核緩存機制，隨機寫不利于 HadaFS 的性能。BeeGFS 的性能表現略差于 HadaFS，但仍然無法擴展到 65536 個進程。由于轉發開銷和存儲介質問題（數據存儲由 HDD 構建），GFS 的性能依舊最低。

圖7 IO吞吐量比較

數據遷移性能評估

接下來評估 Hadash 的 I/O 吞吐量和遷移超小文件的能力，對比對象是 Datawarp。HadaFS 配置了 256 臺數據服務器和 256 臺元數據服務器，Datawrap 配置了 4096 個數據遷移進程。

首先，使用 4096 個文件進行數據stage-in 和 stage-out實驗，文件的總數據量在 256 MB 到 64 TB 之間。實驗結果如下圖所示，當需要遷移的文件總量較小時（stage-in 小于 64GB，stag-out 小于 16GB），Hadash 的性能略差于 Datawarp，因為單個文件較小會導致基于 Redis 管道的命令分發和結果獲取機制占用了較大比例的時間。隨著總體積和單個文件大小的變大，Hadash 的 I/O 吞吐量穩定在 100 GB/s（stage-in）和 140 GB/s（stage-out）左右，遠高于 Datawarp。

圖8 數據遷移吞吐量比較

下圖顯示了使用不同數量的 4 KB 小文件進行數據 stage-in 和 stage-out 的實驗結果。對于 stage-in，當小文件的數量超過 10000 時，Hadash 的性能明顯優于 Datawarp，而 Datawarp 的性能變化較小。對于 stage-out，當小文件數量超過 100000 時，Hadash 明顯優于 Datawarp。

圖9每秒遷移的文件數比較

可以看到 stage-out 性能明顯優于 stage-in 性能。首先 GFS 的寫性能和 BB 的讀性能決定了 stage-out 的性能，而 GFS 的讀性能和 BB 的寫性能決定了 stage-in 的性能。因為 GFS（Lustre）客戶端有寫緩存，所以 GFS 的寫性能高于讀性能，BB 的讀性能也高于寫性能，這就導致了 stage-out 的性能更高。并且在 stage-in 流程中，Hadash 需要從GFS中讀取單個目錄下的所有文件，隨著單個目錄下文件數量的增加，這個過程需要的時間會更長。

綜合來看，HadaFS 已經可以穩定服務于數百個應用程序，支持最大 600000 個客戶端擴展，I/O 聚合帶寬達到 3.1 TB/s。

五、總結

本文提出了一種名為 HadaFS 的新型 Burst Buffer 文件系統，基于共享 BB 架構為計算節點提供了本地 BB 式的訪問，結合了本地 BB 的可擴展性和性能的優勢與共享 BB 的數據共享和部署成本的優勢。

HadaFS 提出的 LTA 架構通過橋接服務器處理計算節點的 I/O 請求，實現了與節點本地 BB 相當的可擴展性，并提供新的接口以減少單個服務器上大量連接帶來的干擾。HadaFS 提出了三種元數據同步策略，以解決傳統文件系統復雜的元數據管理與 HPC 應用程序的各種一致性語義需求之間的不匹配問題。此外，HadaFS內部集成了名為Hadash的數據管理工具，可以為用戶提供全局的數據視圖和高效的數據遷移。最后，HadaFS 已經部署在 SNS 上（超過 100000 個計算節點）并支持數百個應用程序，可以為多種超大規模應用提供穩定、高性能的I/O服務。
責任編輯：彭菁