Beacon+：面向E級(jí)超級(jí)計(jì)算機(jī)的輕量級(jí)端到端I/O性能監(jiān)控與分析診斷系統(tǒng)*

楊 斌，王敬宇，劉世超，邵明山，肖 偉，陳 起,4，何曉斌，劉衛(wèi)國(guó)，薛 巍

(1.山東大學(xué)軟件學(xué)院，山東 濟(jì)南 250101；2.國(guó)家超級(jí)計(jì)算無錫中心，江蘇 無錫 214072；3.國(guó)家并行計(jì)算機(jī)工程技術(shù)研究中心，北京 100080;4.清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系，北京 100084)

1 引言

隨著世界各國(guó)在超級(jí)計(jì)算領(lǐng)域的投入不斷加大，超級(jí)計(jì)算機(jī)技術(shù)迎來了飛速的發(fā)展，計(jì)算速度快速增長(zhǎng)。一方面，計(jì)算能力的飛速提升，為人工智能、腦模擬等新興應(yīng)用，以及地球模擬、計(jì)算流體力學(xué)等傳統(tǒng)應(yīng)用的發(fā)展帶來了巨大幫助；另一方面，眾多特征各異的HPC(High Performance Computing)應(yīng)用也對(duì)超級(jí)計(jì)算機(jī)的設(shè)計(jì)和部署提出了新的挑戰(zhàn)。

超級(jí)計(jì)算機(jī)的核心存儲(chǔ)系統(tǒng)往往是一個(gè)大規(guī)模并行文件系統(tǒng)，主要用來提供計(jì)算結(jié)點(diǎn)方面統(tǒng)一和共享的文件視圖，并提供高吞吐的帶寬。例如，神威·太湖之光[1]的Lustre[2]文件系統(tǒng)，底層共有144個(gè)盤陣，能提供10 PB的存儲(chǔ)容量，最大吞吐率達(dá)到200 GB/s以上。近年來，為了匹配越來越快的計(jì)算速度，支撐不同HPC應(yīng)用的需求，以大規(guī)模共享并行文件系統(tǒng)為主的超級(jí)計(jì)算機(jī)存儲(chǔ)系統(tǒng)需要進(jìn)一步升級(jí)，為此，新一代超級(jí)計(jì)算機(jī)的存儲(chǔ)系統(tǒng)往往都會(huì)引入新型的存儲(chǔ)設(shè)備、新的存儲(chǔ)架構(gòu)和新的軟件棧，這也導(dǎo)致超級(jí)計(jì)算機(jī)的存儲(chǔ)系統(tǒng)變得越來越復(fù)雜，例如，以神威·太湖之光[1]為代表的中間轉(zhuǎn)發(fā)架構(gòu)，以Summit[3]為代表的結(jié)點(diǎn)內(nèi)Burst Buffer系統(tǒng)[4]等。多層級(jí)的存儲(chǔ)架構(gòu)、冗長(zhǎng)的I/O路徑和復(fù)雜的軟件棧一定程度上提高了系統(tǒng)的性能上限，使其可以滿足更多類型的I/O需求，但是也加劇了優(yōu)化使用和管理等方面的問題。

眾所周知，共享是超級(jí)計(jì)算機(jī)存儲(chǔ)系統(tǒng)的一個(gè)重要特點(diǎn)，其為不同計(jì)算結(jié)點(diǎn)間的及時(shí)數(shù)據(jù)傳遞提供了便捷，但也帶來了潛在的沖突和干擾。有許多研究工作[5 - 8]表明，在深共享環(huán)境下，應(yīng)用的性能常常會(huì)出現(xiàn)明顯的抖動(dòng)。首先，應(yīng)用間的沖突干擾是造成性能抖動(dòng)的一個(gè)重要原因。架構(gòu)日趨復(fù)雜使得有效地發(fā)現(xiàn)和定位沖突干擾更加困難，而系統(tǒng)的動(dòng)態(tài)變化也加大了有效地還原性能問題現(xiàn)場(chǎng)的難度。其次，系統(tǒng)由于某種部件故障導(dǎo)致的性能降級(jí)[9]也會(huì)明顯影響應(yīng)用的性能。不同于宕機(jī)等嚴(yán)重故障，部件性能降級(jí)后該部件仍然可以提供服務(wù)，所以常規(guī)的心跳監(jiān)控很難識(shí)別這類問題。系統(tǒng)規(guī)模越大，出現(xiàn)性能降級(jí)和故障的概率也大幅增加。第三，系統(tǒng)參數(shù)的錯(cuò)誤配置、資源的不合理分配也會(huì)對(duì)應(yīng)用的性能造成明顯影響[10]。這是因?yàn)椴煌拇鎯?chǔ)系統(tǒng)對(duì)應(yīng)用的最優(yōu)訪問配置可能不同，且最優(yōu)配置可能隨負(fù)載水平變化而動(dòng)態(tài)變化。綜上所述，存儲(chǔ)系統(tǒng)規(guī)模的增加和結(jié)構(gòu)的日趨復(fù)雜不僅導(dǎo)致了發(fā)現(xiàn)性能問題和診斷其原因更加困難，同時(shí)也讓資源的管理變得更加復(fù)雜。這無疑對(duì)應(yīng)用開發(fā)者優(yōu)化應(yīng)用 I/O 性能，以及系統(tǒng)管理員合理配置資源，提高系統(tǒng)利用率帶來了巨大的挑戰(zhàn)。

為了解決上述問題，近年來出現(xiàn)了一系列I/O性能采集和問題診斷的相關(guān)研究，其主要思想是通過持續(xù)抓取應(yīng)用或者系統(tǒng)的I/O行為，來幫助還原問題現(xiàn)場(chǎng)，從而進(jìn)行性能診斷分析。例如,針對(duì)應(yīng)用的Darshan[11]和ScalableIOTrace[12]；針對(duì)文件系統(tǒng)的FSMonitor[13]和LustrePerfMon[14]；跨層級(jí)的Modular Darshan[15]和Reflector[16]等。但是，這些已有的工具都存在一定局限性：針對(duì)應(yīng)用的工具可以很好地描述應(yīng)用在用戶層的表現(xiàn)，但是缺少全局視圖，無法解釋系統(tǒng)層對(duì)應(yīng)用的影響，不適用于復(fù)雜的超級(jí)計(jì)算機(jī)存儲(chǔ)架構(gòu)上的I/O性能診斷；針對(duì)文件系統(tǒng)的工具可以較好地抓取文件系統(tǒng)的行為，但是往往難以與用戶層的應(yīng)用特征結(jié)合起來，很難對(duì)應(yīng)用的優(yōu)化提供足夠的幫助。多層級(jí)監(jiān)控是一個(gè)發(fā)展趨勢(shì)，但是目前大都由于開銷問題而處于實(shí)驗(yàn)階段，正式部署還極少。Titan[17]上正式部署的多層級(jí)監(jiān)控工具GUIDE[18]采集的內(nèi)容涵蓋了多個(gè)方面，存儲(chǔ)方面主要是Lustre文件系統(tǒng)和硬盤信息的采集，這也導(dǎo)致其無法提供細(xì)致的應(yīng)用I/O分析。神威·太湖之光[1]上部署的Beacon[10]進(jìn)行了太湖之光I/O全路徑的采集，并且已經(jīng)在太湖之光上長(zhǎng)期穩(wěn)定運(yùn)行。神威新一代超級(jí)計(jì)算機(jī)在計(jì)算性能上較太湖之光提升了一個(gè)數(shù)量級(jí)，I/O信息采集總量大幅增加，Beacon已有的壓縮方法、存儲(chǔ)和處理方案需要持續(xù)改進(jìn)，以最小化開銷與資源需求，同時(shí)，在不同平臺(tái)和更多存儲(chǔ)組件上的部署，使得Beacon需要在易用性和可移植性上進(jìn)一步完善。

本文針對(duì)神威新一代超級(jí)計(jì)算機(jī)更加龐大的規(guī)模和新的架構(gòu)，設(shè)計(jì)并實(shí)現(xiàn)了面向E級(jí)超級(jí)計(jì)算機(jī)的輕量級(jí)端到端I/O性能監(jiān)控與分析診斷系統(tǒng)——Beacon+。對(duì)比神威·太湖之光上的Beacon系統(tǒng)，Beacon+在以下幾個(gè)方面具有明顯的優(yōu)勢(shì)：

(1)針對(duì)I/O性能數(shù)據(jù)的采集，Beacon+增加了多個(gè)維度的數(shù)據(jù)采集，以適應(yīng)E級(jí)超級(jí)計(jì)算機(jī)更加復(fù)雜的架構(gòu)。與此同時(shí)，還重新設(shè)計(jì)了采集程序的壓縮算法，并且增加了隨機(jī)緩沖功能，對(duì)數(shù)據(jù)的傳輸進(jìn)行了錯(cuò)峰處理，大大降低了多維度獲取數(shù)據(jù)帶來的開銷，極大地減少了網(wǎng)絡(luò)OPS(Operations Per Second)，釋放了更多網(wǎng)絡(luò)監(jiān)控資源。

(2)針對(duì)數(shù)據(jù)存儲(chǔ)，Beacon+采用了內(nèi)存數(shù)據(jù)庫(kù)來緩存實(shí)時(shí)源數(shù)據(jù)，并通過流處理的方法及時(shí)消費(fèi)。這樣不僅顯著提高了數(shù)據(jù)處理的速度，也減少了存儲(chǔ)E級(jí)超級(jí)計(jì)算機(jī)產(chǎn)生的海量數(shù)據(jù)的開銷。

(3)針對(duì)數(shù)據(jù)分析，Beacon+增加了預(yù)處理機(jī)制，將不同平臺(tái)不同層級(jí)采集的數(shù)據(jù)進(jìn)行了統(tǒng)一的格式化處理，并且抽象出通用的數(shù)據(jù)接口供后續(xù)數(shù)據(jù)分析程序調(diào)用，大大增加了整個(gè)系統(tǒng)的可移植性。同時(shí)，Beacon+改進(jìn)了異常檢測(cè)算法，較Beacon[10]提高了15%的精度。此外，Beacon+還增加了RPC(Remote Procedure Call)層來提供統(tǒng)一的分析結(jié)果輸出接口。

基于上述優(yōu)化改進(jìn)，Beacon+系統(tǒng)已經(jīng)開發(fā)完成并實(shí)現(xiàn)了在新一代神威異構(gòu)眾核超級(jí)計(jì)算機(jī)上的部署，雖然其規(guī)模數(shù)倍于神威·太湖之光，但是Beacon+存儲(chǔ)模塊占用的系統(tǒng)結(jié)點(diǎn)規(guī)模僅比太湖之光增加了不到30%，同時(shí)系統(tǒng)結(jié)點(diǎn)上的內(nèi)存占用對(duì)比Beacon的降低到了50%以下。采集程序的CPU和內(nèi)存占用對(duì)比Beacon的分別降低了70%和90%以下。整體上的開銷不到1%。

2 背景

首先介紹本文平臺(tái)神威新一代超級(jí)計(jì)算機(jī)。雖然Beacon+主要是在神威新一代超級(jí)計(jì)算機(jī)上進(jìn)行的部署測(cè)試，但是它所采用的一些方法都可以被運(yùn)用到其他超級(jí)計(jì)算機(jī)平臺(tái)上。

神威新一代超級(jí)計(jì)算機(jī)系統(tǒng)繼承和發(fā)展了太湖之光的體系架構(gòu)，基于申威新一代高性能異構(gòu)眾核處理器和互連網(wǎng)絡(luò)芯片構(gòu)建。系統(tǒng)由運(yùn)算系統(tǒng)、互連網(wǎng)絡(luò)系統(tǒng)、軟件系統(tǒng)、外圍服務(wù)系統(tǒng)、維護(hù)診斷系統(tǒng)、電源系統(tǒng)和冷卻系統(tǒng)組成，其整體架構(gòu)如圖1所示。

Figure 1 Architecture of the Sunway next-generation supercomputer圖1 神威新一代超級(jí)計(jì)算機(jī)的架構(gòu)圖

每個(gè)計(jì)算結(jié)點(diǎn)包含1個(gè)申威新一代眾核處理器,該處理器采用類似SW26010的異構(gòu)主核+眾核的架構(gòu)，這些部件通過環(huán)形網(wǎng)絡(luò)進(jìn)行互連。每256個(gè)計(jì)算結(jié)點(diǎn)組成一個(gè)超結(jié)點(diǎn)，超結(jié)點(diǎn)內(nèi)的計(jì)算結(jié)點(diǎn)通過自研網(wǎng)絡(luò)SWnet全連接。每4個(gè)超結(jié)點(diǎn)組成1個(gè)機(jī)艙，整體規(guī)模超過了100個(gè)機(jī)艙。計(jì)算結(jié)點(diǎn)通過互連網(wǎng)絡(luò)與代理結(jié)點(diǎn)進(jìn)行連接，代理結(jié)點(diǎn)提供I/O請(qǐng)求轉(zhuǎn)發(fā)或存儲(chǔ)。提供I/O請(qǐng)求轉(zhuǎn)發(fā)時(shí)，代理結(jié)點(diǎn)通過存儲(chǔ)網(wǎng)絡(luò)與存儲(chǔ)結(jié)點(diǎn)連接，由存儲(chǔ)結(jié)點(diǎn)提供最終的數(shù)據(jù)持久化。

神威新一代超級(jí)計(jì)算機(jī)的計(jì)算結(jié)點(diǎn)提供了2種文件訪問方式：與太湖之光超級(jí)計(jì)算機(jī)類似的LWFS(Light Weight File System)與Lustre[2,10]組成的全局文件系統(tǒng)和獨(dú)有的Burst Buffer[19]文件系統(tǒng)HadaFS。計(jì)算結(jié)點(diǎn)同時(shí)作為L(zhǎng)WFS的客戶端和HadaFS的客戶端，并且通過自研網(wǎng)絡(luò)SWnet與代理結(jié)點(diǎn)相連，每1 024個(gè)計(jì)算結(jié)點(diǎn)對(duì)應(yīng)6個(gè)代理結(jié)點(diǎn)。代理結(jié)點(diǎn)作為全局文件系統(tǒng)中LWFS的服務(wù)端和Lustre的客戶端，同時(shí)也作為HadaFS的服務(wù)端。每個(gè)代理結(jié)點(diǎn)上有2塊3 TB的NVMe SSD,整個(gè)HadaFS提供約4 PB的存儲(chǔ)。代理結(jié)點(diǎn)同樣通過SWnet與存儲(chǔ)結(jié)點(diǎn)相連，存儲(chǔ)結(jié)點(diǎn)作為L(zhǎng)ustre的服務(wù)端鏈接了若干存儲(chǔ)盤陣，其存儲(chǔ)容量達(dá)15 PB。此外,還有由多個(gè)元數(shù)據(jù)結(jié)點(diǎn)組成的元數(shù)據(jù)集群，用來提高全局文件系統(tǒng)的元數(shù)據(jù)服務(wù)能力。

3 Beacon+的設(shè)計(jì)與實(shí)現(xiàn)

Figure 2 Architecture of Beacon+圖2 Beacon+架構(gòu)圖

Beacon+對(duì)超級(jí)計(jì)算機(jī)進(jìn)行I/O全路徑的性能數(shù)據(jù)采集和實(shí)時(shí)分析。給應(yīng)用開發(fā)者提供了應(yīng)用畫像，便于定位應(yīng)用的I/O性能問題；給系統(tǒng)管理員提供了系統(tǒng)畫像，便于定位系統(tǒng)熱點(diǎn)，識(shí)別性能干擾與部件性能降級(jí)。圖2展示了Beacon+的4個(gè)主要模塊：

(1)采集模塊。通過輕量級(jí)后臺(tái)程序采集I/O行為信息，進(jìn)行數(shù)據(jù)清洗和壓縮后，以自主push方式向存儲(chǔ)模塊推送數(shù)據(jù)。為了避免對(duì)應(yīng)用造成影響，數(shù)據(jù)通過管理網(wǎng)絡(luò)傳輸(應(yīng)用通信主要通過高速互連網(wǎng)絡(luò))。采集模塊運(yùn)行在應(yīng)用I/O路徑的各層結(jié)點(diǎn)上，其設(shè)計(jì)目標(biāo)是盡可能降低對(duì)應(yīng)用程序的性能影響(<1%)，并最小化性能數(shù)據(jù)傳輸開銷，尤其是降低網(wǎng)絡(luò)OPS壓力，以達(dá)到不干擾原有管理網(wǎng)絡(luò)應(yīng)用的目的。

(2)存儲(chǔ)模塊。通過Logstash[20]、Redis[21]、MySQL[22]和InflulxDB[23]提供高性能數(shù)據(jù)讀寫，通過JSON(Java Script Object Notation)文件和InfluxDB導(dǎo)出文件提供持久化存儲(chǔ)。同時(shí)，為了降低存儲(chǔ)壓力，對(duì)這些文件定期進(jìn)行壓縮。存儲(chǔ)模塊主要部署在代理結(jié)點(diǎn)上，其設(shè)計(jì)目標(biāo)是支持高扇入比的海量流式數(shù)據(jù)存儲(chǔ)(計(jì)算結(jié)點(diǎn)規(guī)模超過10萬)和在線的分析任務(wù)數(shù)據(jù)查詢(秒級(jí)響應(yīng))。

(3)分析模塊。通過流式預(yù)處理實(shí)時(shí)消費(fèi)源數(shù)據(jù)，提供格式化數(shù)據(jù)的接口供后續(xù)分析程序調(diào)用，并通過RPC服務(wù)提供分析結(jié)果的輸出接口。分析模塊主要部署在專用的Beacon+服務(wù)器上，其設(shè)計(jì)目標(biāo)是提供低延遲的分析結(jié)果。

(4)展示模塊。通過命令行和可視化網(wǎng)頁(yè)客戶端展示最終的分析結(jié)果。展示模塊的設(shè)計(jì)目標(biāo)是易用性，方便用戶和管理員以熟悉的方式快速定位應(yīng)用和系統(tǒng)問題。

3.1 采集模塊

與太湖之光的Beacon相比,Beacon+增加了多個(gè)維度的數(shù)據(jù)采集，以覆蓋E級(jí)超級(jí)計(jì)算機(jī)更加復(fù)雜的架構(gòu)，對(duì)應(yīng)用實(shí)現(xiàn)了I/O全路徑采集。與此同時(shí)，Beacon+還重新設(shè)計(jì)了采集程序的壓縮算法，盡可能地合并了短消息，并且增加了隨機(jī)緩沖功能，將數(shù)據(jù)的傳輸進(jìn)行了錯(cuò)峰處理，大大降低了多維度獲取數(shù)據(jù)帶來的開銷，極大地減少了網(wǎng)絡(luò)OPS，釋放了更多網(wǎng)絡(luò)監(jiān)控資源。

(1)計(jì)算結(jié)點(diǎn)：傳統(tǒng)采集工具為了獲取應(yīng)用特征，往往通過插樁一些高層I/O庫(kù)來獲取數(shù)據(jù)，如MPI-IO(Message Passing Interface Input/Ouput)[24]和HDF5(Hierarchical Data Format)[25]等。但是，這種方法需要用戶參與，且需要重新編譯應(yīng)用源代碼或者重新鏈接外部庫(kù)，無法做到對(duì)用戶透明，使用十分不方便，也無法保證采集覆蓋率。而Beacon+采取的方法與這些傳統(tǒng)采集工具有很大的不同，它通過插樁計(jì)算結(jié)點(diǎn)上的輕量級(jí)文件系統(tǒng)LWFS，打印出應(yīng)用各進(jìn)程的I/O操作，從而提取出應(yīng)用的I/O行為。這樣既可以獲取應(yīng)用的I/O特征，也不需要用戶參與，實(shí)現(xiàn)了與用戶的松耦合。且由于神威新一代超級(jí)計(jì)算機(jī)的計(jì)算結(jié)點(diǎn)提供了LWFS和HadaFS 2條I/O路徑，所以Beacon+分別對(duì)其進(jìn)行了插樁，將文件系統(tǒng)中的I/O操作記錄在內(nèi)存日志(log)中，再通過后臺(tái)的輕量采集程序?qū)?shù)據(jù)傳輸出去。同時(shí)，考慮到E級(jí)超級(jí)計(jì)算機(jī)的規(guī)模龐大，每天的數(shù)據(jù)可達(dá)數(shù)十TB，本文對(duì)log文件做了定期回滾。采集程序通過記錄已讀取文件的偏移和當(dāng)前文件的大小來判斷l(xiāng)og文件是否發(fā)生了回滾。當(dāng)log文件大小小于記錄的已讀取文件偏移時(shí)，則認(rèn)為文件發(fā)生了回滾，需要重新讀取。

Figure 3 Diagram of data compression algorithm圖3 數(shù)據(jù)壓縮算法示意圖

與此同時(shí)，為了減少發(fā)送的數(shù)據(jù)量，降低發(fā)送數(shù)據(jù)的頻次，減少管理網(wǎng)絡(luò)中的OPS，最大化降低采集程序的開銷，本文設(shè)計(jì)了高效的壓縮算法，并且在不同層級(jí)采用了不同的壓縮策略來應(yīng)對(duì)不同的數(shù)據(jù)需求。計(jì)算結(jié)點(diǎn)是整個(gè)系統(tǒng)中采集規(guī)模最大的層級(jí)，同時(shí)也是最貼近應(yīng)用的層級(jí)。為了最大化地保留計(jì)算結(jié)點(diǎn)的信息，還原用戶的I/O行為，本文采用了細(xì)粒度Trace配合無損壓縮算法的采集方法。圖3是壓縮算法示意圖，具體的步驟見算法1。

算法1計(jì)算結(jié)點(diǎn)數(shù)據(jù)壓縮算法

輸入：LWFS和HadaFS客戶端的原始log。

輸出：壓縮后的數(shù)據(jù)。

步驟1提取并重組 log的格式。log文件中每個(gè)條目都代表一個(gè)文件操作記錄，具有固定的格式，其中除了關(guān)鍵信息外，還有很大一部分冗余信息，比如open操作的條目除了包含時(shí)間戳、目標(biāo)文件路徑和返回的文件描述符(fd)等信息外，還包含應(yīng)用名、文件名和本地進(jìn)程號(hào)等痕跡信息。采集程序通過識(shí)別操作關(guān)鍵詞，根據(jù)既定格式，對(duì)采集所涉及的open、release、read、write、create、rename和unlink等文件操作的記錄進(jìn)行關(guān)鍵信息提取，濾去一些沒有價(jià)值的信息后再重新組合。經(jīng)測(cè)試，將每一條記錄重組后，能減少70%以上的空間占用。

步驟2合并同一時(shí)間內(nèi)的連續(xù)讀寫I/O請(qǐng)求。log文件中涉及最多的是讀寫操作，應(yīng)用對(duì)于大塊數(shù)據(jù)的讀寫會(huì)在系統(tǒng)中被拆分成若干小數(shù)據(jù)塊讀寫操作，即應(yīng)用發(fā)起的一個(gè)大塊讀/寫請(qǐng)求，會(huì)在log文件中產(chǎn)生大量的讀/寫記錄，它們往往針對(duì)同一個(gè)文件，具有相同的數(shù)據(jù)塊大小，以及連貫的文件偏移。基于此特點(diǎn)，壓縮程序?qū)@些條目進(jìn)行統(tǒng)計(jì)，通過標(biāo)記起始偏移位置、數(shù)據(jù)塊大小和操作數(shù)量，把這些同時(shí)間的I/O 操作合并成一條記錄，如此能減少一個(gè)log文件中 90% 以上的條目。

步驟3建立緩沖區(qū)，合并一段時(shí)間內(nèi)的緩沖區(qū)數(shù)據(jù)。數(shù)據(jù)壓縮完畢后，不立即發(fā)送，而是將壓縮后的數(shù)據(jù)先放入緩沖區(qū)中。同時(shí)設(shè)定隨機(jī)的緩沖時(shí)間，隨機(jī)時(shí)間的取值為(0，30] s。當(dāng)緩沖區(qū)緩沖時(shí)間達(dá)到隨機(jī)設(shè)定的時(shí)間后，將緩沖區(qū)內(nèi)的數(shù)據(jù)合并成一條記錄發(fā)送出去。這種方法將原來的若干條記錄合并成了一條記錄發(fā)送，可以有效減少網(wǎng)絡(luò)中由于頻繁的短消息所導(dǎo)致的OPS過高的情況。本文通過此方法，減少了96%以上的網(wǎng)絡(luò)OPS。

(2)代理結(jié)點(diǎn)：代理結(jié)點(diǎn)包含了I/O路徑中的多個(gè)部分。

首先是LWFS的服務(wù)端，1個(gè)服務(wù)端需要服務(wù)上百個(gè)LWFS客戶端，數(shù)據(jù)量十分龐大。由于計(jì)算結(jié)點(diǎn)已經(jīng)采集了詳細(xì)的信息，所以在服務(wù)端可以去除冗余信息，進(jìn)一步減小系統(tǒng)開銷。同時(shí)，根據(jù)已有的性能分析經(jīng)驗(yàn)，服務(wù)端對(duì)應(yīng)用I/O性能的影響與服務(wù)端的負(fù)載情況有較強(qiáng)的正相關(guān)性。因此，本文在LWFS服務(wù)端通過對(duì)代碼插樁的方式進(jìn)行了統(tǒng)計(jì)分析。設(shè)定每隔1 000(默認(rèn)1 000，可配置)條I/O請(qǐng)求，就對(duì)這些I/O請(qǐng)求的執(zhí)行時(shí)間進(jìn)行統(tǒng)計(jì)分析，并輸出這些I/O請(qǐng)求的執(zhí)行時(shí)間分布情況。除了I/O請(qǐng)求的執(zhí)行時(shí)間，本文對(duì)I/O請(qǐng)求的等待時(shí)間也做了相應(yīng)的處理，并且將I/O請(qǐng)求分為元數(shù)據(jù)操作、讀操作和寫操作3類操作分別輸出。例如，LWFS的服務(wù)端收到了1 000條I/O請(qǐng)求，通過上述統(tǒng)計(jì)分析方法，壓縮后僅輸出6條記錄(所有讀請(qǐng)求等待的時(shí)間分布、寫請(qǐng)求等待的時(shí)間分布、元數(shù)據(jù)請(qǐng)求等待的時(shí)間分布、讀請(qǐng)求執(zhí)行的時(shí)間分布、寫請(qǐng)求執(zhí)行的時(shí)間分布和元數(shù)據(jù)請(qǐng)求執(zhí)行的時(shí)間分布)，壓縮比超過了160倍，極大地降低了開銷。本文對(duì)于HadaFS的服務(wù)端，也采取了類似的統(tǒng)計(jì)分析的方法。

其次是HadaFS的后端存儲(chǔ)NVMe SSD的采集。Beacon+通過nvme-cli[26]命令采樣采集了設(shè)備的smart-log信息，主要包含NVMe溫度、使用率、壽命、讀寫數(shù)據(jù)量和讀寫操作數(shù)等內(nèi)容，可以幫助系統(tǒng)管理員分析NVMe SSD的使用情況。

接著是作為全局文件系統(tǒng)的Lustre的客戶端，Beacon+采樣采集了/proc/fs/lustre下Lustre OSC(Object Storage Client)到服務(wù)端OST(Object Storage Target)的RPC信息，每個(gè)OSC-OST對(duì)的數(shù)據(jù)可以表示為(timestamp，OSC，OST，RPC size，RPC count)。此外，為了提高傳輸效率，Beacon+將同一時(shí)間內(nèi)的所有數(shù)據(jù)合并為一條記錄進(jìn)行發(fā)送。

(3)存儲(chǔ)結(jié)點(diǎn)：存儲(chǔ)結(jié)點(diǎn)上主要是Lustre的服務(wù)端OSS(Object Storage Server)和存儲(chǔ)對(duì)象OST。Beacon+采樣采集了/proc/fs/lustre下的OST的狀態(tài)表信息，例如，OST ID、Size和Count等信息。每個(gè)OST采集的數(shù)據(jù)可以表示為(timestamp，OST，RPC size，RPC count)。同樣，為了提高傳輸效率，將同一時(shí)間內(nèi)的所有數(shù)據(jù)合并為一條記錄進(jìn)行發(fā)送。

(4)元數(shù)據(jù)結(jié)點(diǎn)：元數(shù)據(jù)結(jié)點(diǎn)上采樣采集了Lustre MDT的元數(shù)據(jù)操作信息，按操作類型和操作數(shù)進(jìn)行統(tǒng)計(jì)后由采集程序傳出。

上述采樣方法的采集頻次可以根據(jù)實(shí)際需要進(jìn)行調(diào)節(jié)。目前Beacon+在神威新一代超級(jí)計(jì)算中設(shè)置為每秒1次采樣，用來應(yīng)對(duì)超級(jí)計(jì)算機(jī)多變的負(fù)載。

(5)作業(yè)信息采集：Beacon+通過作業(yè)調(diào)度器來獲取運(yùn)行的作業(yè)信息，例如，作業(yè)ID、作業(yè)提交時(shí)間、作業(yè)結(jié)束時(shí)間和作業(yè)使用的計(jì)算結(jié)點(diǎn)列表等信息，并且將作業(yè)信息按照(年-月)分表，存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)中。作業(yè)信息可以幫助針對(duì)某一具體應(yīng)用的用戶應(yīng)用畫像描述。

3.2 存儲(chǔ)模塊

存儲(chǔ)模塊主要負(fù)責(zé)數(shù)據(jù)的中間緩存和持久化存儲(chǔ)。Beacon+重新設(shè)計(jì)了存儲(chǔ)架構(gòu)，精簡(jiǎn)了軟件棧，同時(shí)采用了內(nèi)存數(shù)據(jù)庫(kù)來緩存實(shí)時(shí)源數(shù)據(jù)，并通過流處理的方法及時(shí)消費(fèi)數(shù)據(jù)。后臺(tái)采集程序?qū)Σ杉臄?shù)據(jù)進(jìn)行數(shù)據(jù)清洗和壓縮處理后，通過管理網(wǎng)絡(luò)將數(shù)據(jù)發(fā)送到Logstash和Redis中，其中Logstash 負(fù)責(zé)接收數(shù)據(jù)，Redis負(fù)責(zé)暫存數(shù)據(jù)。為了提高性能和服務(wù)的穩(wěn)定性，Redis采用了單點(diǎn)模式，這樣不僅可以顯著提高數(shù)據(jù)處理的速度，也可以減少E級(jí)超級(jí)計(jì)算機(jī)產(chǎn)生的海量數(shù)據(jù)的存儲(chǔ)開銷。Logstash和Redis的數(shù)量根據(jù)不同層級(jí)的采集數(shù)據(jù)量來確定：(1)計(jì)算結(jié)點(diǎn)上每4個(gè)超結(jié)點(diǎn)數(shù)據(jù)對(duì)應(yīng)1個(gè)Logstash+Redis中間數(shù)據(jù)緩沖。(2)代理結(jié)點(diǎn)上根據(jù)3種采集點(diǎn)類型：LWFS及HadaFS的服務(wù)端、Lustre的客戶端和NVMe SSD劃分了3個(gè)Logstash+Redis中間數(shù)據(jù)緩沖。(3)存儲(chǔ)結(jié)點(diǎn)和元數(shù)據(jù)結(jié)點(diǎn)各配置了1個(gè)Logstash+Redis中間數(shù)據(jù)緩沖。

持久化存儲(chǔ)主要包括：MySQL數(shù)據(jù)庫(kù)存儲(chǔ)的作業(yè)運(yùn)行信息、預(yù)處理導(dǎo)出的原始數(shù)據(jù)文件和存儲(chǔ)預(yù)處理結(jié)果的InfluxDB數(shù)據(jù)庫(kù)導(dǎo)出的冷數(shù)據(jù)。Beacon+通過定期對(duì)這些文件進(jìn)行壓縮，來減少數(shù)據(jù)存儲(chǔ)開銷。根據(jù)本文的實(shí)驗(yàn)評(píng)估，100 TB的總?cè)萘靠梢源鎯?chǔ)5年以上的數(shù)據(jù)。

3.3 分析模塊

分析模塊負(fù)責(zé)將Beacon+采集到的多層數(shù)據(jù)進(jìn)行組合分析。為了提高效率和增加可移植性，Beacon+增加了預(yù)處理機(jī)制，將不同平臺(tái)不同層級(jí)的采集數(shù)據(jù)進(jìn)行了統(tǒng)一格式化處理，并且抽象出通用的數(shù)據(jù)接口供后續(xù)數(shù)據(jù)分析程序調(diào)用，大大增加了整個(gè)系統(tǒng)的可移植性。同時(shí)，Beacon+還改進(jìn)了異常檢測(cè)算法，較Beacon[10]提高了15%的精度。此外，Beacon+還增加了RPC層來提供統(tǒng)一的分析結(jié)果輸出接口。

(1)數(shù)據(jù)預(yù)處理：圖2的架構(gòu)圖中展示了預(yù)處理處理流程。首先，預(yù)處理程序每隔一段時(shí)間將暫存在Redis中的原始數(shù)據(jù)批量取出，進(jìn)行反序列化。接著，將數(shù)據(jù)按結(jié)點(diǎn)劃分，對(duì)每個(gè)結(jié)點(diǎn)按秒級(jí)粒度進(jìn)行處理。經(jīng)過預(yù)處理后，數(shù)據(jù)被統(tǒng)一表示為以下結(jié)構(gòu)：(結(jié)點(diǎn)ID，timestamp，讀寫帶寬，讀寫數(shù)據(jù)量，IOPS，MDOPS(每秒元數(shù)據(jù)操作數(shù))，讀寫大小的分布，文件讀寫情況)。預(yù)處理后的數(shù)據(jù)會(huì)被存儲(chǔ)在InfluxDB中，以供后續(xù)分析使用。InfluxDB中的數(shù)據(jù)會(huì)被保留1周。與此同時(shí)，預(yù)處理程序還會(huì)將原始數(shù)據(jù)導(dǎo)出為JSON格式的文件進(jìn)行持久化存儲(chǔ)。

通過預(yù)處理可以將不同平臺(tái)不同層級(jí)的數(shù)據(jù)進(jìn)行統(tǒng)一格式化處理，得到格式化的數(shù)據(jù)。然后通過接口向后續(xù)的應(yīng)用畫像分析或者系統(tǒng)畫像分析程序提供數(shù)據(jù)支持。這樣可以避免后續(xù)分析程序針對(duì)不同采集方案的修改，提高了Beacon+的可移植性，降低了跨平臺(tái)移植成本。

(2)數(shù)據(jù)分析：數(shù)據(jù)分析主要通過接口獲取各層級(jí)預(yù)處理后的格式化數(shù)據(jù)，結(jié)合作業(yè)信息，為普通用戶和管理員用戶提供不同的視圖。

針對(duì)普通用戶想要獲取自身應(yīng)用性能詳細(xì)分析的需求，Beacon+提供了應(yīng)用畫像。應(yīng)用畫像通過對(duì)作業(yè)的I/O行為進(jìn)行詳細(xì)分析，為用戶提供：①應(yīng)用的整體I/O表現(xiàn)，例如，應(yīng)用的I/O帶寬、IOPS、MDOPS和請(qǐng)求大小分析等；②I/O模式，例如，1-1讀寫，N-1讀寫，N-N讀寫和N-M讀寫等；③資源使用情況，例如，代理結(jié)點(diǎn)使用情況和存儲(chǔ)結(jié)點(diǎn)使用情況；④可能存在的性能瓶頸，例如，低效的I/O模式(1-1讀寫，N-1讀寫)，大量小文件讀寫，沖突干擾等。其中,沖突干擾是超級(jí)計(jì)算系統(tǒng)中常見的現(xiàn)象[27]。因?yàn)槌?jí)計(jì)算系統(tǒng)是一個(gè)資源深度共享的運(yùn)行環(huán)境，同一時(shí)刻可能會(huì)運(yùn)行各種類型的應(yīng)用，數(shù)量可能十分龐大，所以沖突干擾現(xiàn)象屢見不鮮。但是，由于超級(jí)計(jì)算系統(tǒng)的環(huán)境復(fù)雜，及時(shí)發(fā)現(xiàn)沖突干擾并定位其原因一直是一個(gè)巨大的挑戰(zhàn)。Beacon+為了解決該問題，采用了基于應(yīng)用歷史數(shù)據(jù)的聚類算法[10]來診斷應(yīng)用的性能異常。

針對(duì)系統(tǒng)管理員，Beacon+提供了系統(tǒng)畫像，用來對(duì)超級(jí)計(jì)算機(jī)的各層結(jié)點(diǎn)進(jìn)行實(shí)時(shí)可視化展示。一方面，通過對(duì)各結(jié)點(diǎn)進(jìn)行實(shí)時(shí)監(jiān)控和記錄，計(jì)算并實(shí)時(shí)展示結(jié)點(diǎn)的聚合帶寬和負(fù)載均衡情況，既可以縱向?qū)Ρ葟挠?jì)算到存儲(chǔ)各類結(jié)點(diǎn)的I/O流量，也可橫向觀察某類結(jié)點(diǎn)內(nèi)部的具體I/O分布。另一方面，實(shí)時(shí)地對(duì)異常結(jié)點(diǎn)進(jìn)行告警，例如，系統(tǒng)故障的結(jié)點(diǎn)、性能降級(jí)的結(jié)點(diǎn)等。系統(tǒng)故障指結(jié)點(diǎn)由于宕機(jī)等原因停止了服務(wù)，可以通過心跳監(jiān)控的方法較為方便地捕獲。性能降級(jí)指結(jié)點(diǎn)仍然可以提供服務(wù)，但是服務(wù)能力達(dá)不到正常水平。一般情況下，性能降級(jí)的結(jié)點(diǎn)在輕負(fù)載時(shí)同正常結(jié)點(diǎn)的表現(xiàn)幾乎相同，所以很難被捕獲。

為了解決上述問題，本文根據(jù)統(tǒng)籌應(yīng)用和系統(tǒng)側(cè)采集到的2方面數(shù)據(jù)，設(shè)計(jì)了基于應(yīng)用的異常診斷方法，幫助診斷應(yīng)用的性能異常和定位性能異常的系統(tǒng)結(jié)點(diǎn)。

(3)異常診斷分析：通過Beacon+提供的多層數(shù)據(jù)，本文結(jié)合作業(yè)信息，設(shè)計(jì)了如圖4所示的從應(yīng)用出發(fā)的異常診斷分析方法。

Figure 4 Anomaly detection based on applications圖4 基于應(yīng)用的異常診斷方法

首先通過作業(yè)信息獲取作業(yè)運(yùn)行時(shí)間和使用的結(jié)點(diǎn)，然后調(diào)用預(yù)處理接口查詢獲取相關(guān)結(jié)點(diǎn)對(duì)應(yīng)時(shí)間的數(shù)據(jù)進(jìn)行整合，得到應(yīng)用的詳細(xì)I/O行為。通過離散小波變換DWT(Discret Wavelet Transform)將作業(yè)的I/O行為轉(zhuǎn)化為若干I/O phase[10]，然后對(duì)I/O phase進(jìn)行建模。模型中最重要的一步是求解出性能向量PV(Performance Vertor)。性能向量用來描述I/O phase的帶寬表現(xiàn)。然后利用DBSCAN(Density-based Spatial Clustering of Applications with Noise)對(duì)具有相同應(yīng)用名、相同并行規(guī)模、相同I/O表現(xiàn)和相同I/O類型的I/O phase的性能向量進(jìn)行聚類，識(shí)別出異常的I/O phase。算法2描述了基于I/O phase的建模算法。

算法2I/O phase建模算法

輸入：應(yīng)用的I/O phase的帶寬序列。

輸出：D維性能向量PV。

步驟1統(tǒng)計(jì)應(yīng)用的所有相似I/O phase的最大帶寬THmax和最小帶寬THmin。選擇PV的維度D。

步驟2計(jì)算劃分區(qū)間大小I=(THmax-THmin)/D。按照間隔I劃分[THmin，THmax]，即[THmin，THmin+I)，[THmin+I，THmin+2I)，…，[THmin+(D-1)*i，THmax]。

步驟3對(duì)I/O phase中的帶寬序列，按照區(qū)間進(jìn)行統(tǒng)計(jì)，得到一個(gè)N維向量Vec=[X1，X2，X3，…，XD]。表示序列中有X1個(gè)數(shù)位于[THmin，THmin+I)，有X2個(gè)數(shù)位于[THmin+I，THmin+2I)，以此類推，有XN個(gè)數(shù)位于[THmin+(D-1)*i，THmax]。Vec即為所求的性能向量PV。

根據(jù)此建模算法的結(jié)果來進(jìn)行聚類，相較文獻(xiàn)[10,27,28]的算法，精度提高了15%以上。當(dāng)前應(yīng)用出現(xiàn)異常后，本文進(jìn)一步判斷當(dāng)前應(yīng)用的相鄰應(yīng)用(相鄰應(yīng)用指共享資源的應(yīng)用)的I/O類型，是否屬于幾個(gè)典型的容易引起沖突干擾的I/O類型，如：N-1讀寫模式、高I/O帶寬和高M(jìn)DOPS等。如果存在有上述典型I/O類型的相鄰應(yīng)用，那么當(dāng)前應(yīng)用就被判斷為可能受到了典型應(yīng)用的沖突干擾而導(dǎo)致了性能異常。如果沒有這些典型類型的應(yīng)用，那么判斷同一時(shí)刻是否有許多作業(yè)都進(jìn)行了資源共享，如果有許多作業(yè)同時(shí)共享資源，那么也可能會(huì)產(chǎn)生沖突干擾。除了沖突干擾外，還會(huì)有一些其他可能的原因?qū)е聭?yīng)用性能異常，例如，系統(tǒng)結(jié)點(diǎn)參數(shù)設(shè)置不正確，系統(tǒng)結(jié)點(diǎn)降級(jí)等。

對(duì)于系統(tǒng)結(jié)點(diǎn)的異常診斷則是從大規(guī)模高負(fù)載的應(yīng)用出發(fā)來判斷。大規(guī)模應(yīng)用往往可以獨(dú)占若干存儲(chǔ)資源，這樣便于尋找出性能異常的I/O結(jié)點(diǎn)。如圖4的右側(cè)所示，同樣先采用DWT的方法進(jìn)行計(jì)算結(jié)點(diǎn)的應(yīng)用I/O phase提取。同時(shí)，對(duì)大應(yīng)用占用的代理結(jié)點(diǎn)以及存儲(chǔ)結(jié)點(diǎn)也做相應(yīng)的I/O phase提取。然后進(jìn)行建模，接著通過聚類找出性能異常的結(jié)點(diǎn)，結(jié)合結(jié)點(diǎn)的歷史記錄，判斷結(jié)點(diǎn)是否出現(xiàn)了性能降級(jí)。

(4)RPC對(duì)外接口：為了便于展示端在多平臺(tái)使用，本文通過Thrift[29]RPC框架對(duì)外提供數(shù)據(jù)分析結(jié)果。

3.4 展示模塊

展示模塊通過RPC接口獲取結(jié)果。主要提供2種方式：(1)命令行;(2)可視化網(wǎng)頁(yè)。命令行通過RPC調(diào)用獲取分析結(jié)果，結(jié)合Matplotlib[30]進(jìn)行圖像展示。可視化網(wǎng)頁(yè)采用Vue[31]+Django[32]的前后端框架，后端數(shù)據(jù)獲取同樣通過RPC調(diào)用。

Figure 6 Overhead tests on two file systems圖6 2種文件系統(tǒng)上的開銷測(cè)試

4 實(shí)驗(yàn)與結(jié)果分析

4.1 準(zhǔn)確性評(píng)估

保證采集的數(shù)據(jù)真實(shí)反映應(yīng)用的I/O行為是衡量性能分析工具的一個(gè)重要指標(biāo)。本文通過將I/O benchmark自身打印的日志的I/O帶寬與Beacon+的分析結(jié)果獲取的I/O帶寬相比較，來驗(yàn)證Beacon+的準(zhǔn)確性。實(shí)驗(yàn)采用IOR(Interleaved Or Random)[33]為測(cè)試用例，I/O模式為N-N讀寫，每個(gè)進(jìn)程讀寫200 MB的文件，并行規(guī)模從4進(jìn)程到4 096進(jìn)程，每個(gè)規(guī)模各進(jìn)行20次實(shí)驗(yàn)，其中10次運(yùn)行在全局文件系統(tǒng)上，10次運(yùn)行在Burst Buffer文件系統(tǒng)上。

圖5展示了IOR運(yùn)行在全局文件系統(tǒng)上和Burst Buffer文件系統(tǒng)上時(shí)應(yīng)用日志和Beacon+輸出的I/O帶寬對(duì)比，其中橫軸為并行規(guī)模，每個(gè)規(guī)模左側(cè)的盒須圖代表日志輸出的帶寬，右側(cè)代表Beacon+輸出的帶寬。可以看到，對(duì)比應(yīng)用原始日志輸出的真實(shí)I/O行為，Beacon+輸出的結(jié)果誤差不到4%，可以說Beacon+真實(shí)地反映了應(yīng)用的I/O行為。對(duì)比Beacon[10]的準(zhǔn)確性，兩者基本相同。

Figure 5 Performance reported by applications’ log and Beacon+ on two file systems圖5 2種文件系統(tǒng)上應(yīng)用日志和Beacon+輸出的性能

4.2 開銷評(píng)估

作為對(duì)用戶透明、與用戶松耦合的系統(tǒng)，Beacon+需要盡可能地降低生產(chǎn)環(huán)境對(duì)應(yīng)用的影響。本文通過高負(fù)載的IOR[33]來探究極限情況下Beacon+對(duì)應(yīng)用造成的性能影響。實(shí)驗(yàn)分別測(cè)試了Beacon+在全局文件系統(tǒng)和Burst Buffer文件系統(tǒng)上的開銷。

(1)全局文件系統(tǒng)：測(cè)試了IOR在未部署監(jiān)控系統(tǒng)、部署B(yǎng)eacon+和部署B(yǎng)eacon 系統(tǒng)情況下的性能對(duì)比。測(cè)試程序?yàn)? 024個(gè)進(jìn)程(每個(gè)進(jìn)程占據(jù)1個(gè)計(jì)算結(jié)點(diǎn))，每個(gè)進(jìn)程讀寫200 MB文件，進(jìn)行10次實(shí)驗(yàn)。圖6上側(cè)的盒須圖是實(shí)驗(yàn)結(jié)果，可以看到,對(duì)比Beacon，Beacon+對(duì)應(yīng)用的性能影響更小，平均不到1%。

(2)Burst Buffer文件系統(tǒng)：測(cè)試了IOR在未部署監(jiān)控系統(tǒng)、部署B(yǎng)eacon+和部署B(yǎng)eacon的系統(tǒng)情況下的性能對(duì)比。測(cè)試程序?yàn)? 144個(gè)進(jìn)程，每個(gè)進(jìn)程讀寫200 MB文件，進(jìn)行10次實(shí)驗(yàn)。圖6下側(cè)的盒須圖是實(shí)驗(yàn)結(jié)果，相比于Beacon，Beacon+下的應(yīng)用性能更加接近原生未部署監(jiān)控系統(tǒng)時(shí)的性能，對(duì)應(yīng)用帶寬的影響平均不到1%。

綜上所述，可以看到,相較于Beacon,Beacon+對(duì)應(yīng)用的I/O帶寬影響更低，多次測(cè)試帶寬的變化也更小。此外，在真實(shí)環(huán)境下，真實(shí)應(yīng)用I/O的占比較I/O測(cè)試程序會(huì)小很多，且I/O的負(fù)載也較輕，所以對(duì)應(yīng)用程序的整體運(yùn)行時(shí)間的影響會(huì)進(jìn)一步降低。

4.3 資源占用評(píng)估

由于Beacon+的某些模塊與生產(chǎn)系統(tǒng)部署在一起，所以資源占用一定要小，否則可能會(huì)影響生產(chǎn)系統(tǒng)的其他服務(wù)。表1展示了Beacon+和Beacon的資源開銷對(duì)比。

Table 1 Comparison of system overhead

從表1可以看到，Beacon+通過優(yōu)化采集算法,減少內(nèi)存拷貝,減少I/O棧深度和增加隨機(jī)緩沖發(fā)送等手段大大減少了CPU、Memory和網(wǎng)絡(luò)OPS資源的占用，使得其更加適用于E級(jí)超大規(guī)模的計(jì)算系統(tǒng)。

4.4 性能評(píng)估

Beacon+的目標(biāo)是為用戶提供實(shí)時(shí)的診斷結(jié)果，所以需要保證數(shù)據(jù)處理的實(shí)效性。本節(jié)對(duì)比了Beacon+和Beacon的數(shù)據(jù)處理能力，圖7展示了實(shí)驗(yàn)結(jié)果。

Figure 7 Data processing rate of Beacon+ and Beacon圖7 Beacon+和 Beacon數(shù)據(jù)處理速率對(duì)比

從圖7可以看到,Beacon+相比于Beacon有明顯的可擴(kuò)展優(yōu)勢(shì)，其數(shù)據(jù)處理性能基本可以隨著數(shù)據(jù)處理進(jìn)程數(shù)的增加而獲得線性提升。這是因?yàn)锽eacon+精簡(jiǎn)了I/O棧，將數(shù)據(jù)放在內(nèi)存數(shù)據(jù)庫(kù)Redis中，且采用了單點(diǎn)Redis模式，所以較Beacon[10]采用的Elasticsearch集群存儲(chǔ)方案有明顯的可擴(kuò)展優(yōu)勢(shì)。雖然Beacon+的存儲(chǔ)方案較Beacon會(huì)增加些許管理難度，但是該方案的性能提升明顯，更適用于E級(jí)超級(jí)計(jì)算機(jī)存儲(chǔ)海量數(shù)據(jù)需要實(shí)時(shí)處理的場(chǎng)景。

4.5 真實(shí)案例評(píng)估

本節(jié)展示了Beacon+在真實(shí)場(chǎng)景下的應(yīng)用。

全局文件系統(tǒng)：全局文件系統(tǒng)由于無需修改應(yīng)用代碼，且支持標(biāo)準(zhǔn)I/O接口，所以往往是許多用戶的第一選擇。

圖8a展示了某分子對(duì)接應(yīng)用[34]在神威下一代超級(jí)計(jì)算機(jī)上的歷史多次運(yùn)行情況，縱軸顯示了應(yīng)用的I/O帶寬，多次運(yùn)行的結(jié)果采用不同的線條表示。可以看到，應(yīng)用的性能抖動(dòng)十分明顯，最大可達(dá)2倍以上。借助Beacon+提供的可視化網(wǎng)頁(yè)，用戶可以方便地在應(yīng)用畫像界面獲取應(yīng)用的性能異常原因。對(duì)于本應(yīng)用來說，Beacon+發(fā)現(xiàn)同一時(shí)刻存在多道作業(yè)共享資源，且當(dāng)中存在極高I/O帶寬的應(yīng)用，從而產(chǎn)生了所謂的性能干擾。

Figure 8 Running history of the applications圖8 應(yīng)用的歷史運(yùn)行信息

與此同時(shí)，共享的I/O代理結(jié)點(diǎn)上存在大量I/O請(qǐng)求等待的現(xiàn)象，如圖8b所示，請(qǐng)求隊(duì)列的最大等待長(zhǎng)度達(dá)到了1 000以上。結(jié)合多層數(shù)據(jù)分析，Beacon+給出了本應(yīng)用性能異常的主要原因是應(yīng)用的沖突干擾。實(shí)際上對(duì)于許多的超級(jí)計(jì)算機(jī)應(yīng)用來說，應(yīng)用間沖突干擾是造成性能抖動(dòng)的一個(gè)重要因素[10]。解決應(yīng)用沖突干擾的最好辦法是進(jìn)行資源隔離，將有不同資源需求的應(yīng)用按照一定的調(diào)度策略進(jìn)行調(diào)度，盡量避免有同種資源需求的應(yīng)用分配到相同的結(jié)點(diǎn)上，學(xué)術(shù)界已有不少相關(guān)工作[35,36]。

Burst Buffer文件系統(tǒng)：Burst Buffer文件系統(tǒng)HadaFS的后端存儲(chǔ)是高性能的NVMe SSD，所以在某些場(chǎng)景下會(huì)有更好的表現(xiàn)。

圖9展示了某粒子模擬應(yīng)用在全局文件系統(tǒng)上的運(yùn)行情況。由圖9a可以看到，該應(yīng)用的I/O帶寬非常低，平均為50 MB/s。圖9b展示了該應(yīng)用的I/O請(qǐng)求大小的分布，可以看到大部分請(qǐng)求小于4 KB，且Beacon+根據(jù)I/O請(qǐng)求的偏移進(jìn)一步分析了其連續(xù)性，發(fā)現(xiàn)其I/O請(qǐng)求屬于不規(guī)則隨機(jī)讀，故Beacon+給出的性能瓶頸在于頻繁的隨機(jī)小塊讀。因?yàn)槿治募到y(tǒng)的I/O路徑較長(zhǎng)，加上后端采用了硬盤作為最終存儲(chǔ)，所以I/O請(qǐng)求的延遲相對(duì)較長(zhǎng)，對(duì)小塊I/O請(qǐng)求非常不友好。全局文件系統(tǒng)的設(shè)計(jì)適于對(duì)延遲不敏感的高并發(fā)的大塊讀寫應(yīng)用。

Figure 9 A particle simulation application running on GFS圖9 全局文件系統(tǒng)上運(yùn)行的粒子模擬應(yīng)用

基于以上考慮，本文使用HadsFS接口替換了應(yīng)用的I/O模塊，并對(duì)應(yīng)用的I/O行為重新進(jìn)行了評(píng)估。圖10展示了該應(yīng)用在相同規(guī)模配置下，分別運(yùn)行在Burst Buffer文件系統(tǒng)和全局文件系統(tǒng)上的性能對(duì)比，可以看到應(yīng)用的I/O行為雖然沒有改變，但是由于HadaFS的特性，獲得了大約1倍的性能提升。HadaFS的接口可以方便地替換標(biāo)準(zhǔn)的POSIX(Portable Operating System Interface)接口，所以可以大大減少應(yīng)用開發(fā)者重新設(shè)計(jì)實(shí)現(xiàn)I/O策略和重構(gòu)數(shù)據(jù)文件的開銷。

Figure 10 Performance comparison on two file systems圖10 2種文件系統(tǒng)上的性能對(duì)比

5 結(jié)束語(yǔ)

本文面向E級(jí)超級(jí)計(jì)算機(jī)的龐大且復(fù)雜的架構(gòu)，設(shè)計(jì)并實(shí)現(xiàn)了高可擴(kuò)展的輕量級(jí)端到端I/O采集與分析診斷系統(tǒng)——Beacon+。該系統(tǒng)具備以下特性:(1)Beacon+支持全機(jī)全路徑采集，針對(duì)不同的層級(jí)采用了多種壓縮算法，大大降低了系統(tǒng)開銷。(2)Beacon+通過流式預(yù)處理結(jié)合數(shù)據(jù)流緩沖存儲(chǔ)的方法，顯著提高了處理效率，面對(duì)E級(jí)超級(jí)計(jì)算機(jī)的海量數(shù)據(jù)也可以保證對(duì)應(yīng)用和系統(tǒng)I/O行為的實(shí)時(shí)分析。(3)Beacon+提供了基于應(yīng)用的異常診斷系統(tǒng)，可以主動(dòng)對(duì)應(yīng)用以及系統(tǒng)結(jié)點(diǎn)的性能異常進(jìn)行實(shí)時(shí)反饋，為最終的問題定位提供關(guān)鍵的基礎(chǔ)信息。(4)Beacon+具有很好的可移植性，通過預(yù)處理可以將不同平臺(tái)不同層級(jí)的數(shù)據(jù)統(tǒng)一為格式化后的數(shù)據(jù)，移植到其他平臺(tái)時(shí)，可以最大程度地減少對(duì)應(yīng)用畫像和系統(tǒng)畫像分析的修改。(5)Beacon+為了解決E級(jí)超級(jí)計(jì)算機(jī)的海量數(shù)據(jù)而采用的一些方法和采集存儲(chǔ)框架，也適用于其他平臺(tái)。