應用透明的超算多層存儲加速技術研究

何曉斌，高潔，肖偉，陳起，劉鑫，陳左寧

（1.國家并行計算機工程技術研究中心，北京 100080；2.清華大學 計算機科學與技術系，北京 100084；3.中國工程院，北京 100088）

0 概述

當前高性能計算已經邁入E 級時代，隨著傳統超算與AI 的不斷融合，超算應用領域不斷擴大，應用產生的數據量也呈爆發性增長［1-3］。為此，主流高性能計算系統均構建了多層存儲體系，主要包括全局文件系統（Global File System，GFS）、突發緩沖存儲（Burst Buffer，BB）［4］、節點高速存儲層等，其中GFS 主要使用大容量磁盤構建，BB 一般使用NVMe SSD 構建。此外，近年來利用非易失性隨機訪問存儲器（Non-Volatile Random Access Memory，NVRAM）、非易失性雙列存儲模塊（Non-Volatile Dual In-line Memory Module，NVDIMM）等高速存儲介質構建節點高速存儲層也成為研究熱點［5］。最新發布的美國Frontier 超算部署了三層存儲［6］，包括計算節點本地高速存儲、全局共享的SSD 存儲和全局共享的磁盤存儲，合計存儲容量高達760 PB，數據讀帶寬達75 TB/s，數據寫帶寬達35 TB/s；日本超級計算機富岳［7］部署了兩層存儲，包括計算節點共享的SSD 存儲系統，容量達16 PB，帶寬達10 TB/s，此外還基于磁盤構建了容量達100 PB 的全局文件系統。存儲層次的不斷增加，雖然提升了存儲系統的總體性能，但是目前多層存儲系統的構建缺乏統一標準，特別是BB 層與計算節點本地存儲層，為了發揮硬件介質的性能優勢，其軟件設計與傳統存儲軟件存在顯著差異，無法與傳統文件系統形成統一名字空間，如GekkoFS［8］、UnifyFS［9］、CROSS［10］、Datawarp［11］、BeeOND［12-13］等文件系統均基于BB 構建了獨立的文件系統空間，需要應用修改數據訪問路徑，往往會導致額外的數據管理負擔。正是由于以上原因，導致存儲加速系統的利用率普遍不高［14］。業界針對以上問題研發了多款軟件，如Elevator［15］、Unistor［16］、Hermes［17］等，但是此類軟件或者針對特定的上層I/O 庫（例如HDF5 等），或者無法支持多層異構存儲介質，難以適用于下一代國產超算存儲系統。

為解決多層存儲架構無法實現統一名字空間訪問的問題，本文提出對應用透明的加速技術。針對計算節點NVDIMM 等高速存儲層設計透明的塊級數據讀寫緩存機制，提出支持數據順序讀和跨步讀的預讀算法，實現NVDIMM 層與BB 層統一名字空間管理；針對BB 層設計文件級的數據緩存機制，提出緩存副本的一致性管理方法，實現BB 層與傳統GFS 層統一名字空間管理。最終，基于神威E 級原型驗證系統對這2 種緩存技術進行測試。

1 相關工作

當前，隨著超算算力的高速增長，為支撐超算應用的數據訪問需求，超算存儲系統一般使用分層存儲架構構建，主要包括大容量全局文件系統、高性能Burst Buffer 以及計算節點本地高速NVDIMM 等層次［6-7，18-19］，其架構如圖1 所示。

圖1 超算分層存儲架構Fig.1 Tiered storage architecture of supercomputing

大容量全局文件系統一般基于磁盤存儲構建，具有容量大、數據全局共享、可靠性高、兼容標準接口、聚合帶寬較低等特點，如Lustre［20-21］、BeeGFS［12］等；而高性能BB 存儲系統一般基于SSD 構建，性能相比全局文件系統更高，具備一定的數據共享機制，但是目前這一類系統往往不能完整支持POSIX 接口，應用使用時不僅需要修改路徑，而且還需要定制數據從GFS 導入至BB（stage-in）以及從BB導出至GFS（stage-out）的管理流程，如GekkoFS［8］、DAOS［22］、UnifyFS［9］、HadaFS［23］、Datawarp［11］等；計算節點本地的NVDIMM 存儲性能更接近內存，但是容量較小，僅可作為臨時性局部存儲空間，這類存儲介質一般通過塊接口使用［24-25］，難以適用于通用的I/O 流程［26］。

分層存儲通過更多層次高速硬件的部署提升了存儲系統的基礎性能，然而卻帶來了統一名字空間的問題，如何對應用隱藏多層次存儲系統的復雜性，透明提升應用數據訪問的效率成為業界關注的難題［14，27］。Elevator提出了一種針對Burst Buffer 的透明緩存機制，可實現BB 與GFS 的透明整合，但是這種機制只能運行在HDF5 庫內部，存在適應性問題［15］；Unistor 在Elevator 的基礎上實現了對通用場景下BB 的加速機制支持，但是無法支持NVDIMM存儲環境［16］；IBM 在Summit 中分別提出了面向計算節點本地SSD 的塊和文件級緩存機制，但是僅支持透明的寫緩存［28］；LPCC 基于Lustre 文件系統實現了BB 與GFS 的數據緩存［20］，但是其要求BB 中的數據必須寫回GFS 以支持數據共享，數據共享效率較低；Hermes 提出多級存儲融合使用的方法，但是其緩存管理和分配機制需要統計大量I/O 事件信息，在大規模超算中存在擴展性差的問題［17］。

神威E 級原型驗證系統是我國面向E 級超算關鍵技術挑戰構建的驗證平臺［29］，配置了全局文件系統、BB 存儲系統，并且具備利用節點內存進行I/O 加速的基礎。該系統中的全局文件系統基于Lustre+LWFS 構建，與神威·太湖之光全局存儲相似［19］；BB存儲系統基于全新研制的HadaFS 構建，該系統實現了用戶層、松耦合的文件訪問語義。面向下一代超算的I/O 挑戰，本文針對NVDIMM 的塊訪問和BB 的文件訪問優勢分別提出不同的數據緩存機制，從而支持多層存儲加速的統一名字空間，實現對應用透明的I/O 加速。相關技術在神威E 級原型驗證系統中進行部署，為神威下一代超算存儲系統的研發提供參考。

2 透明存儲加速技術的設計

為解決當前超算多層存儲異構軟件堆疊帶來的多種名字空間統一的問題，本文提出面向下一代超算的透明存儲加速技術，如圖2 所示，該技術嵌入在超算多層存儲軟件棧中，支持POSIX 標準的文件讀寫接口，主要包括基于NVDIMM 的塊級緩存和基于BB 的文件級緩存兩個方面。基于NVDIMM 的塊級緩存以計算節點高速NVDIMM 存儲介質為基礎，通過NVDIMM 高速塊訪問協議實現對傳統文件數據塊的緩存；基于BB 的文件級緩存通過文件級的動態數據遷移，解決BB 層與全局文件系統無法實現名字空間統一的問題。

圖2 面向下一代超算的透明存儲加速技術架構Fig.2 Transparent storage acceleration technology architecture for next-generation supercomputing

2.1 基于NVDIMM 的塊級緩存

基于NVDIMM 的塊級緩存運行在超算BB 層存儲之上，針對計算節點本地讀寫的數據流進行加速，其利用計算節點NVDIMM 實現對文件的數據塊級緩存，原理如圖3 所示。NVDIMM 層塊級緩存功能作為一個獨立模塊嵌入超算存儲客戶端內部，自動截獲應用文件讀寫的數據塊地址、大小等信息，并為存儲客戶端提供塊級寫數據緩存和數據預讀功能。

圖3 NVDIMM 塊級緩存的工作原理Fig.3 Principle of NVDIMM block-level cache

NVDIMM 塊級緩存模塊在NVDIMM 介質中以文件為單位分別維護了讀寫兩個先進先出（FIFO）隊列，此外還包括數據一致性控制、數據異步寫引擎和數據預讀引擎等部分。應用進程產生的文件操作如讀（read）、寫（write）、刷新（flush）、獲取狀態（stat）等將按照時間順序依次進入隊列，并由數據一致性控制部件決定是否立即向上層應用返回成功。對于寫操作，若NVDIMM 中事先設定的緩存窗口沒有溢出，則設置為異步操作，否則設置為同步操作。異步操作意味著該寫請求的數據塊將被緩存至NVDIMM，同時客戶端將立即向應用返回寫成功，而同步操作意味著客戶端需要等待該請求刷新至BB 層文件系統后才能向應用返回結果。寫操作緩存的數據塊由數據異步寫引擎負責刷新至BB 層文件系統中。

對于讀操作，系統將盡可能多地預讀數據塊并緩存在讀數據隊列中，以減少從服務端直接讀數據的次數。數據讀引擎根據讀緩存隊列中緩存的數據塊大小和偏移位置決定預讀數據起始位置和大小，目前有可探測順序（Sequential）讀和跨步（Stride）讀兩種模式，對于隨機讀默認按照順序讀的方式預取數據，數據預取塊大小為事先設定的大數據塊，以提升命中概率。數據預讀算法如算法1 所示。

算法1數據預讀算法

輸入最近兩次讀請求q1（offset，size）、q2（offset，size），以及記錄的跨步偏移量stride_offset

輸出預讀的數據塊請求q_preread（offset，size）

NVDIMM 塊緩存模塊收到應用讀數據請求后，將在文件預讀數據塊列表中查找對應的數據塊，具體算法如算法2 所示。此外，為了保證緩存的利用率，緩存塊搜索的過程也需要同步進行緩存塊清理，以實現后續更多數據的預讀。

算法2預讀數據塊的搜索和管理算法

輸入已經預讀的數據塊（offset，size，buffer）組成的順序列表list，以及應用的讀請求rq（offset，size）

輸出命中返回hitbuf，以及剩余未命中部分的left_offset和left_size；未命中返回NULL

高性能計算應用數據讀寫類型較為單一，幾乎不存在多進程對同一文件同一區域進行可覆蓋寫以及讀寫交叉的應用場景，因此，NVDIMM 塊級緩存對讀、寫隊列分開處理，且不支持對同一文件進行緩存寫與預讀。讀寫一致性模塊對于請求隊列中的數據一致性進行檢查，發現對同一文件同時進行緩存寫與預讀的I/O行為后將對該文件強制禁用寫緩存和預讀功能。

由于NVDIMM 是一種非易失的存儲介質，因此基于NVDIMM 的塊緩存機制理論上具備節點故障后恢復數據的能力，為此，讀寫一致性處理部件在數據寫入的同時還保留了文件數據塊緩存的日志，以在節點故障恢復后快速恢復數據，同時由于底層文件系統存儲了文件的真實大小和訪問時間，因此故障狀態下應用可根據文件大小、訪問時間等檢索受影響的文件，以在應用層做出補救。對于讀緩存，由于本身不涉及數據一致性問題，因此無需特殊處理。

NVDIMM 層塊級緩存支持兩種管理方式：一種是用戶通過環境變量設置加速目錄和緩存窗口大小，該模塊自動為目錄中文件讀寫的全流程進行NVDIMM 緩存；另一種是應用通過標準的ioctl 接口以文件為單位進行緩存的動態開關，實現對數據緩存更加精確的控制。

2.2 基于BB 的文件級緩存

基于BB 的文件級緩存模塊運行在超算存儲服務端，對上兼容POSIX 接口，也作為NVDIMM 塊級緩存數據導出和預讀的支撐平臺，對下訪問GFS 和BB 文件系統，支持BB 與GFS 統一名字空間，應用的所有目錄操作均由GFS 完成，而對文件數據訪問，則提供寫緩存和預加載兩種策略。在寫緩存策略中，應用產生的數據默認寫入BB 中，系統將在收到close 操作后將數據由BB 遷移至GFS；而在預加載策略中，文件將在首次讀或者收到用戶預加載命令后，將文件由GFS 預加載至BB。圖4 以文件預加載為例子，說明了文件級透明緩存的流程。

圖4 BB 文件級緩存的文件預加載流程Fig.4 Procedure of file proload in BB file-level cache

BB 與GFS 之間的文件遷移完成后，同一個文件在GFS 和BB 中存在兩個副本。對于寫緩存策略，BB 中的副本在遷移完成后數據將被刪除或者設置為只讀權限，而對于預加載策略，BB 中的副本只有讀權限，文件緩存管理利用一個K-V 庫監控存儲副本信息，并由緩存文件的屬性檢查和更新模塊監控管理BB 中只讀副本與GFS 中副本的屬性變化，一旦發現GFS 中的數據被更改或者BB中副本的存儲時間超過預設時間，則BB中的只讀副本將被刪除，從而減少文件副本占用的BB空間，具體原理如圖5 所示。

圖5 BB 層緩存文件副本的管理流程Fig.5 Management procedure of cache file copies in BB layer

BB 層文件級緩存支持用戶通過特定的工具以目錄為單位設置緩存管理策略，包括數據遷移的觸發條件、副本在BB 中的留存時間等，系統將以目錄為單位按照策略進行緩存文件的自動管理，緩存文件管理的過程對應用I/O 過程透明。

3 測試與結果分析

3.1 測試環境

神威系列超算是具有世界影響力的超算平臺［30-31］，神威E 級原型驗證系統是神威面向E 級時代超算技術研制的驗證系統，部署于國家超級計算濟南中心，其基于國產SW26010Pro 處理器構建［32］，每個處理器包含6 個核組，可支持6 路I/O 并發進程，節點之間使用神威網絡互連［29］，單節點上網帶寬達到400 Gb/s以上，可用于I/O的網絡帶寬超過200 Gb/s。神威E 級原型驗證系統的存儲系統符合圖1 所示的超算存儲架構，其中數據轉發節點配置了雙路服務器CPU，單節點網絡帶寬為200 Gb/s，并部署了兩塊NVMe SSD（單塊容量為3.2 TB）以構建突發緩沖存儲（BB）。全局存儲方面利用Lustre 構建了全局文件系統（GFS），利用LWFS 實現了全局文件系統的數據轉發。在本文的測試中，由于NVDIMM 硬件針對國產處理器環境的適配仍在實驗階段，因此使用節點DRAM 內存模擬NVDIMM 構建塊級緩存。

3.2 測試方法

本文使用IOR Benchmark［33］在神威原型驗證系統中測試存儲加速技術使用后的帶寬變化情況。IOR 測試進程運行在計算節點中，每個測試進程通過本文提出的加速技術讀寫獨立的文件。測試在不修改應用程序數據訪問路徑的前提下進行，分別測試加速技術啟用和不啟用時的性能，以對比本文所提技術的透明加速效果。此外，還使用超算典型應用對本文提出的加速技術進行測試。

3.3 測試結果分析

3.3.1 計算節點NVDIMM 塊級緩存的測試

NVDIMM 塊緩存機制運行在存儲系統客戶端，由于在高性能應用運行時，NVDIMM 可能有SWAP 空間、應用直接存儲數據等多種其他用途，同時為了測試NVDIMM 緩存機制在緩存溢出時的加速效果，選擇16 MB 緩存窗口進行測試（單節點4 進程運行時占據的內存為64 MB，考慮常用的國產NVDIMM 單根大小為16 GB，占比為1/256），對比技術為未使用NVDIMM 塊緩存的BB 文件系統HadaFS 的常規讀寫機制，內存刷新和預讀塊大小為1 MB，選擇128 KB 塊順序讀寫和8 KB 塊隨機讀寫兩種典型模式，128 KB 塊順序讀寫單進程數據量為1 GB，8 KB 塊隨機讀寫單進程數據量為80 MB，由于NVDIMM 塊緩存機制僅作用在客戶端，因此測試中服務端固定為一個轉發節點。

緩存窗口大小為16 MB 時128 KB 順序讀寫帶寬的測試結果如圖6 所示。隨著測試進程數的不斷增加，塊緩存機制實現了讀寫帶寬的加速。對于寫操作：當1、4、16 進程時，塊緩存模式寫帶寬增幅超過40%；當進程超過64 個時，寫帶寬增幅逐漸降低；當1 024 個進程并發時，增幅為12%；不同進程規模下的平均增幅為36%。出現這種現象的主要原因在于塊緩存機制啟用后雖然數據寫入本地緩存，但是由于緩存窗口大小的限制，并未實現完全的緩存命中。以64 進程為例，寫緩存命中率為89%，一旦寫緩存未命中，則該請求必須等待緩存隊列清空后才能向應用返回，因此影響了性能。此外，測試中計算了文件的close 時間，由于寫文件完成后的close 操作需要刷新元數據等信息，因此耗時較長，也一定程度影響了寫緩存的總體效果。對于讀操作：由于數據預讀的塊大小為1 MB，128 KB 塊讀寫時緩存命中率最高為87.5%，命中率低于寫操作，因此測試的不同進程規模下的平均增幅更小，為27%；隨著進程數的不斷增加，加速幅度降低的主要原因在于底層存儲的性能已經達到峰值，因此每個計算節點端可見的緩存刷新或者預讀的速率降低，從而導致緩存命中率降低。

圖6 16 MB 緩存窗口時128 KB 塊的順序讀寫性能Fig.6 Sequential read/write performance of a 128 KB block when the cache window is set to 16 MB

緩存窗口大小為16 MB 時8 KB 隨機讀寫帶寬如圖7 所示。隨著測試進程數的增加，8 KB 隨機讀寫的帶寬不斷增加，相對HadaFS 常規操作的性能增幅變化與128 KB 塊大小順序讀寫帶寬增幅變化規律相似，在64 進程規模下讀寫帶寬分別提升19%和39%，不同進程規模下的平均增幅分別為20% 和37%。雖然8 KB 隨機場景下NVDIMM 緩存機制難以準確預測出讀請求的偏移量，但是由于緩存窗口相對于8 KB 塊大小比例較高，因此提前讀入的數據量大，一定程度上增加了緩存命中的概率，由此保證了讀帶寬相比未使用緩存機制有所提升。

圖7 16 MB 緩存窗口8 KB 塊的隨機讀寫性能Fig.7 Random read/write performance of an 8 KB block when the cache window is set to 16 MB

固定進程數為1 024，數據塊大小為128 KB，每個進程順序讀寫1 GB 數據，并按照4 倍比例逐漸增加緩存窗口和數據預讀塊，測試得到的帶寬數據歸一化后如圖8 所示。隨著緩存窗口的不斷增大，寫緩存命中率不斷提升，因此寫帶寬加速比也不斷增加，一旦緩存窗口大小超過寫入的數據總量，寫緩存的命中率達到100%，寫帶寬達到峰值，1 GB 窗口下寫帶寬相比16 MB提升達到10 倍以上。隨著緩存窗口、預讀數據塊大小的不斷增加，讀帶寬也呈現增加趨勢，但是增加幅度相對緩慢，這是由于預讀數據塊大小始終沒有超過文件大小。固定測試的進程規模，單進程以8 KB 塊隨機讀寫80 MB 數據，在增加緩存窗口時呈現出完全相同的規律，且加速效果更加明顯，此處不再贅述。

圖8 增加緩存窗口時128 KB 塊的順序讀寫性能Fig.8 Sequential read/write performance of a 128 KB block when increasing cache window size

以上測試表明，未來隨著NVDIMM 等新型存儲介質的大規模應用，對于文件大小在NVDIMM 緩存空間內的應用，塊緩存機制有望大幅提升應用的數據讀寫性能，對于那些文件大小超過緩存空間的應用，該機制也具有一定的加速效果。

3.3.2 基于BB 的文件級緩存測試

基于Burst Buffer 的文件級緩存機制運行在BB節點上，負責實現BB 存儲的HadaFS 文件系統與底層全局文件系統（GFS）之間的數據統一管理和透明加速。測試使用IOR 程序，分別測試128 KB 順序讀寫和8 KB 隨機讀寫兩種模式，對比技術為使用磁盤構建的GFS。測試中關閉了計算節點NVDIMM 緩存，測試程序運行在計算節點，分別測試1、16、256、1 024、4 096、8 192 進程規模，128 KB 塊順序讀寫測試每個進程讀寫數據量為1 GB，8 KB 塊隨機讀寫測試每個進程讀寫數據量為80 MB，服務端運行在8個轉發節點，每個轉發節點包含2個NVMe SSD，對比本文提出的BB 級文件緩存功能打開和關閉（相當于使用底層GFS 進行數據讀寫）時的聚合帶寬變化，以測試加速效果。

128 KB 塊順序讀寫性能如圖9 所示。隨著進程規模的不斷增加，GFS 模式和BB 文件級緩存模式均實現了性能增長，最終在8 192 進程規模下BB 文件級緩存模式的讀寫帶寬相比GFS 提升90%和147%，不同測試規模讀寫帶寬的平均增幅分別為55%和141%。BB 文件級緩存機制使用后，由于BB 文件級緩存空間達到51.2 TB，遠大于測試程序產生的數據量，確保了測試中讀寫數據均實現緩存命中，測試程序產生的文件全部通過SSD 讀寫，因此，測試程序實際使用的帶寬即為BB 層HadaFS 的峰值帶寬。事實上，當前幾乎所有主流超算在設計時，其BB 層緩存空間基本都能滿足應用突發數據的多次寫入，可基本保證突發數據的緩存能通過BB 層的要求，提升系統總體I/O 性能。

圖9 BB 文件級緩存128 KB 塊順序讀寫性能Fig.9 Sequential read/write performance of a 128 KB block in BB layer file-level cache

文件級緩存8 KB 塊隨機讀寫性能如圖10 所示，隨著進程數的不斷增加，8 KB 塊隨機讀寫帶寬的變化規律與128 KB 順序寫相似。8 192 進程時8 KB 隨機寫帶寬提升240%，隨機讀帶寬提升220%，不同測試規模下讀寫帶寬的平均增幅分別為163% 和209%，主要原因在于BB 基于SSD 構建，其小塊隨機讀寫性能相對于基于磁盤構建的GFS 更具優勢。

圖10 BB 文件級緩存8 KB 隨機讀寫性能Fig.10 Random read/write performance of an 8 KB block in BB layer file-level cache

3.3.3 實際應用測試

本文提出的透明存儲加速機制在神威E 級原型驗證系統部署后，為多道應用課題提供了數據加速服務，典型的包括WRF［34］、H5bench［35］等。

WRF 是一種經典的區域數字天氣預報系統，通過單進程寫出數據。使用本文提出的塊級數據緩存技術后，WRF 寫數據I/O 帶寬提升50%。H5bench 是一種多個進程寫同一個文件的經典程序，模擬了VPIC 應用的I/O 流程，需要進行大量數據的讀寫。使用基于BB 的文件級緩存后，H5bench 性能變化如圖11 所示。可以看出：使用BB 文件級緩存后，H5bench 的寫性能相比GFS 平均提升3.6 倍，讀性能提升1.3 倍，這是由于H5bench 是典型的多進程讀寫同一文件的應用場景，GFS 在這種場景下由于需要維護嚴格數據一致性，因此性能開銷較大；此外，BB文件緩存的H5bench 最高寫帶寬為圖9 中BB 峰值性能的一半，而讀性能達到圖9 中BB 所能實現的最高讀帶寬，原因在于H5bench 是多個進程寫同一個文件，在底層BB 端也面臨著多個進程寫同一個文件的場景，因此性能不如每個進程寫獨立的文件，由于多個進程讀同一個文件時NVMe SSD 底層文件系統緩存作用明顯，因此能實現較高讀性能。

圖11 H5bench 的讀寫性能Fig.11 Read/write performance of H5bench

4 結束語

E 級時代超算利用不同的存儲介質構建了大容量、高性能的多層存儲系統，雖然一定程度上滿足了應用對于存儲容量和性能的需求，但是由于多層存儲異構軟件使用方式上的差異，難以實現統一名字空間管理和對應用透明的緩存機制。本文針對這一問題提出基于NVDIMM 的塊級緩存和基于Burst Buffer 的文件級緩存機制，并在神威E 級原型驗證系統中進行部署和測試。測試結果表明，本文提出的技術可以實現應用透明的存儲加速。下一步將繼續研究多層存儲面向應用的資源協調與分配機制，實現多應用共享的存儲加速資源動態管理。