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

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

一、背景

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

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

1）本地BB，即SSD作為本地磁盤部署在每個計算節(jié)點上，專門為單個計算節(jié)點服務(wù)；
2）共享BB，即SSD部署在計算節(jié)點可以訪問的專用節(jié)點上 （例如 I/O 轉(zhuǎn)發(fā)節(jié)點），以支持共享數(shù)據(jù)訪問。

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

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

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

圖1SNS的架構(gòu)

二、動機問題

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

問題1：
隨著百億億級計算的壁壘被打破，超級計算機的 I/O 并發(fā)量可達數(shù)十萬，同時 AI、工作流等數(shù)據(jù)共享應(yīng)用占比提升導(dǎo)致 I/O 需求發(fā)生變化，大規(guī)模數(shù)據(jù)的高速共享存儲對 BB 架構(gòu)的可擴展性提出了挑戰(zhàn)。

現(xiàn)有超級計算機計算機采用的方案各有優(yōu)缺點，例如，F(xiàn)rontier 使用獨立硬件分別構(gòu)建本地 BB 和共享 BB，但這種方法需要很多加速設(shè)備（SSD），建設(shè)和維護成本高。

問題2：
傳統(tǒng)的文件系統(tǒng)的文件管理在目錄樹結(jié)構(gòu)中實現(xiàn)并且嚴(yán)格遵循 POSIX 協(xié)議，但在 HPC 中，計算節(jié)點通常負(fù)責(zé)讀寫數(shù)據(jù)，很少執(zhí)行目錄樹訪問，通過放寬 POSIX 協(xié)議也可以提高性能。不同應(yīng)用程序?qū)ξ募到y(tǒng)一致性的需求不同，一致性程度越高 ，它的適應(yīng)性就越強，但代價是開銷越大。靈活地選擇一致性語義來平衡應(yīng)用程序的需求并利用 BB 性能是一個很大的挑戰(zhàn)。

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

從成本控制的角度出發(fā)，共享 BB 部署更適合未來的超大規(guī)模計算節(jié)點系統(tǒng)，因為共享 BB 可以部署在計算或數(shù)據(jù)轉(zhuǎn)發(fā)節(jié)點上。為了解決上述問題，本文研究如何從共享 BB 模型開始，獲得本地 BB 模型的優(yōu)勢，以更好地滿足百億億級及以上 HPC 應(yīng)用程序的需求。

三、HadaFS的設(shè)計與實現(xiàn)

HadaFS概述

圖2 HadaFS的架構(gòu)

HadaFS 相當(dāng)于是堆疊在磁盤陣列或存儲服務(wù)器的全局文件系統(tǒng)上的一個分布式文件系統(tǒng)，HadaFS 的整體架構(gòu)如上圖所示，包括HadaFS 客戶端、HadaFS 服務(wù)器、數(shù)據(jù)管理工具 Hadash。

?Hadash 運行在用戶登錄節(jié)點上，用于管理全局文件系統(tǒng)與 HadaFS 之間的數(shù)據(jù)遷移。

?HadaFS 客戶端運行在計算節(jié)點上，作為一個靜態(tài)/動態(tài)庫，攔截應(yīng)用程序的 POSIX I/O 請求并將其重定向到 HadaFS 服務(wù)器。

?HadaFS 服務(wù)器運行在部署 NVMe SSD 的專用突發(fā)緩沖節(jié)點上，提供全局?jǐn)?shù)據(jù)和元數(shù)據(jù)分離的存儲服務(wù)。

HadaFS 作為共享突發(fā)緩沖文件系統(tǒng)，可以為每個客戶端提供全局視圖。HadaFS 中的每個文件都與兩種類型的服務(wù)器相關(guān)聯(lián)。一種是數(shù)據(jù)存儲服務(wù)器，通過 NVMe SSD 上的基礎(chǔ)文件系統(tǒng)存儲 HadaFS 文件的數(shù)據(jù)，另一種是元數(shù)據(jù)存儲服務(wù)器，通過高性能數(shù)據(jù)庫（RocksDB）存儲 HadaFS 文件的元數(shù)據(jù)。

Localized Triage Architecture（LTA，本地化分流架構(gòu)）

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

LTA 為每個計算節(jié)點匹配了一個橋接服務(wù)器以提供相當(dāng)于本地 BB 的服務(wù)，并通過所有橋接服務(wù)器之間的全互聯(lián)支持所有客戶端的共享，結(jié)合了本地 BB 和共享 BB 的優(yōu)點。

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

文件命名空間和元數(shù)據(jù)處理

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

每個 HadaFS 服務(wù)器上都維護著兩種元數(shù)據(jù)數(shù)據(jù)庫，它們的數(shù)據(jù)結(jié)構(gòu)如下圖所示。

圖3 HadaFS服務(wù)器上的兩張K-V表

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

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

數(shù)據(jù)管理工具 Hadash

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

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

圖4 Hadash的退出流程

HadaFS 其他的一些優(yōu)化設(shè)計

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

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

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

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

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

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

四、性能評估

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

圖5 HadaFS的部署

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

元數(shù)據(jù)訪問性能評估

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

圖6元數(shù)據(jù)性能比較

數(shù)據(jù)訪問性能評估

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

圖7 IO吞吐量比較

數(shù)據(jù)遷移性能評估

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

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

圖8 數(shù)據(jù)遷移吞吐量比較

下圖顯示了使用不同數(shù)量的 4 KB 小文件進行數(shù)據(jù) stage-in 和 stage-out 的實驗結(jié)果。對于 stage-in，當(dāng)小文件的數(shù)量超過 10000 時，Hadash 的性能明顯優(yōu)于 Datawarp，而 Datawarp 的性能變化較小。對于 stage-out，當(dāng)小文件數(shù)量超過 100000 時，Hadash 明顯優(yōu)于 Datawarp。

圖9每秒遷移的文件數(shù)比較

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

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

五、總結(jié)

本文提出了一種名為 HadaFS 的新型 Burst Buffer 文件系統(tǒng)，基于共享 BB 架構(gòu)為計算節(jié)點提供了本地 BB 式的訪問，結(jié)合了本地 BB 的可擴展性和性能的優(yōu)勢與共享 BB 的數(shù)據(jù)共享和部署成本的優(yōu)勢。

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