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

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

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

1 引言

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

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

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

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

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

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

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

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

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

2 背景

首先介紹本文平臺神威新一代超級計算機。雖然Beacon+主要是在神威新一代超級計算機上進行的部署測試，但是它所采用的一些方法都可以被運用到其他超級計算機平臺上。

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

Figure 1 Architecture of the Sunway next-generation supercomputer圖1 神威新一代超級計算機的架構圖

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

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

3 Beacon+的設計與實現(xiàn)

Figure 2 Architecture of Beacon+圖2 Beacon+架構圖

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

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

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

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

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

3.1 采集模塊

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

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

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

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

算法1計算結點數(shù)據(jù)壓縮算法

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

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

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

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

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

(2)代理結點：代理結點包含了I/O路徑中的多個部分。

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

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

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

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

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

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

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

3.2 存儲模塊

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

持久化存儲主要包括：MySQL數(shù)據(jù)庫存儲的作業(yè)運行信息、預處理導出的原始數(shù)據(jù)文件和存儲預處理結果的InfluxDB數(shù)據(jù)庫導出的冷數(shù)據(jù)。Beacon+通過定期對這些文件進行壓縮，來減少數(shù)據(jù)存儲開銷。根據(jù)本文的實驗評估，100 TB的總容量可以存儲5年以上的數(shù)據(jù)。

3.3 分析模塊

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

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

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

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

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

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

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

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

Figure 4 Anomaly detection based on applications圖4 基于應用的異常診斷方法

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

算法2I/O phase建模算法

輸入：應用的I/O phase的帶寬序列。

輸出：D維性能向量PV。

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

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

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

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

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

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

3.4 展示模塊

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

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

4 實驗與結果分析

4.1 準確性評估

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

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

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

4.2 開銷評估

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

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

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

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

4.3 資源占用評估

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

Table 1 Comparison of system overhead

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

4.4 性能評估

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

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

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

4.5 真實案例評估

本節(jié)展示了Beacon+在真實場景下的應用。

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

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

Figure 8 Running history of the applications圖8 應用的歷史運行信息

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

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

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

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

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

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

5 結束語

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