程 穩(wěn)，李 焱，曾令仿，王 芳，唐士程，楊力平，馮 丹，曾文君

(1.華中科技大學武漢光電國家研究中心，信息存儲系統(tǒng)教育部重點實驗室暨數(shù)據(jù)存儲系統(tǒng)與技術(shù)教育部工程研究中心，湖北 武漢 430074;2.深圳國家基因庫，廣東 深圳 518120;3.之江實驗室，浙江 杭州 311121)

1 引言

大規(guī)模集群存儲系統(tǒng)中，運行著大量應(yīng)用任務(wù)，各個應(yīng)用都有其自身的特性，如人工智能、空間/高能物理、基因工程和光子科學等應(yīng)用都具有不同的I/O模式，它們的負載表現(xiàn)多樣化，應(yīng)用的數(shù)據(jù)采集、建模、訓練、分析和輸出等階段也有其不同的I/O特征和需求，如果所有應(yīng)用均等對待、不加區(qū)分地寫入集群存儲系統(tǒng)會引發(fā)各種問題[1]，如資源競爭、性能下降和服務(wù)器宕機等。集群存儲系統(tǒng)的用戶、維護人員、上層應(yīng)用開發(fā)人員和多層存儲系統(tǒng)開發(fā)人員等需要了解當前應(yīng)用程序需求與特性[2]，獲取優(yōu)化建議，找出并消除效率低下的根源，自上而下優(yōu)化集群存儲系統(tǒng)，為將來系統(tǒng)軟硬件設(shè)計或購買提供參考[3]。

應(yīng)用的多樣性和快速迭代更新，使得人們對當前系統(tǒng)中應(yīng)用負載情況不甚明朗，不同系統(tǒng)環(huán)境中得出的觀察/結(jié)論有可能不同。比如，我們在實際應(yīng)用生產(chǎn)環(huán)境中采集了5個Lustre集群存儲連續(xù)326天的應(yīng)用日志信息，通過分析發(fā)現(xiàn)，運行在實際Lustre集群存儲中的應(yīng)用都是讀多寫少型，讀寫I/O在應(yīng)用運行期間一直同時存在，一天內(nèi)I/O讀寫量幾乎維持在一個比較穩(wěn)定的水準。我們的上述發(fā)現(xiàn)與文獻[3-5]的部分研究結(jié)論有所區(qū)別，但從宏觀角度看來，我們的發(fā)現(xiàn)在一定程度上進一步完善了對應(yīng)用負載訪問特征的探究。因此，我們認為，通過更多的探索來豐富/驗證已有研究，進一步完善已有資料庫，為系統(tǒng)開發(fā)人員和系統(tǒng)維護人員提供真實部署系統(tǒng)的特征信息與系統(tǒng)性能優(yōu)化建議，是非常有意義的；另外，在實際系統(tǒng)優(yōu)化過程中我們發(fā)現(xiàn)，系統(tǒng)具備自動優(yōu)化能力非常必要。

本文首先介紹常規(guī)應(yīng)用日志采集方案和現(xiàn)有I/O數(shù)據(jù)分析研究工作，并給出本文日志采集相關(guān)信息；然后對應(yīng)用日志進行探究與分析；對相關(guān)問題與發(fā)現(xiàn)進行歸納，并給出面向相關(guān)應(yīng)用負載的Lustre集群存儲優(yōu)化策略；最后，針對系統(tǒng)優(yōu)化過程中的自動化需求，面向Lustre集群存儲，設(shè)計并實現(xiàn)一個系統(tǒng)自動優(yōu)化框架SAOF(System Automation Optimization Framework)，初步實驗表明，SAOF能自動執(zhí)行資源預(yù)留、帶寬限定等優(yōu)化策略。

2 應(yīng)用日志相關(guān)研究

2.1 現(xiàn)有應(yīng)用日志采集與分析研究

在開發(fā)、部署和評估功能時，了解應(yīng)用特性是幫助架構(gòu)師、集成人員和維護人員識別性能、可用性、可擴展性問題根源的關(guān)鍵[6]。已有研究工作通過研究數(shù)據(jù)使用模式，利用高級I/O庫，分析并行文件系統(tǒng)客戶端的I/O，優(yōu)化HPC環(huán)境的I/O預(yù)取[7]，它們通常通過使用諸如DARSHAN[8]、LIOProf(Lustre IO Profiler)[9]這類工具對日志數(shù)據(jù)進行跟蹤分析來評估應(yīng)用的I/O負載。應(yīng)用的負載一般具有階段性和周期性[10]，利用已有日志對應(yīng)用負載進行分析處理，既可以最大程度利用已存儲的日志信息，又可以不消耗寶貴的在線計算與存儲資源。

對應(yīng)用負載進行優(yōu)化主要有2個步驟：(1)應(yīng)用I/O數(shù)據(jù)的監(jiān)控與采集；(2)I/O數(shù)據(jù)的分析。在應(yīng)用I/O數(shù)據(jù)的監(jiān)控與采集方面，已有較多優(yōu)秀的應(yīng)用I/O數(shù)據(jù)監(jiān)控與采集軟件，如應(yīng)用級I/O監(jiān)控[8,9]、存儲系統(tǒng)級I/O監(jiān)控[11]和全棧I/O監(jiān)控工具[12]。這3類工作主要關(guān)注相關(guān)軟件的開發(fā)，介紹軟件的使用，并且一般都是特有領(lǐng)域自身的監(jiān)控方案，很少涉及到I/O數(shù)據(jù)分析[3,4]。

I/O數(shù)據(jù)分析主要分為2類：(1)單個應(yīng)用的I/O行為分析[13]，其主要探究應(yīng)用的帶寬特性、I/O周期性與重復(fù)性、單個作業(yè)的I/O行為多樣性等。這些研究缺乏全局視角，效益有限，現(xiàn)階段大多研究傾向于挖掘更多的信息(如存儲服務(wù)器的信息)，來進一步優(yōu)化系統(tǒng)性能[14]。(2)整個存儲系統(tǒng)的I/O行為分析[15]，此類研究通過探索最佳文件系統(tǒng)配置或確定系統(tǒng)級拓撲瓶頸，關(guān)注存儲系統(tǒng)I/O行為，提供相應(yīng)建議，一般不會分析存儲系統(tǒng)上現(xiàn)有活動的負載，通常也沒有對元數(shù)據(jù)服務(wù)器、對象存儲服務(wù)等提供深入的分析，沒有過多考慮與HPC系統(tǒng)相關(guān)的交互，只提供了整個存儲系統(tǒng)級別的高級特征。

針對整個存儲系統(tǒng)的I/O行為分析問題，Patel等人[3]利用系統(tǒng)級I/O監(jiān)控工具LMT(Lustre Monitoring Tool)[16]對美國國家能源研究科學計算中心NERSC (National Energy Research Scientific Computing center)的Edison和Cori超級計算機共享的Lustre集群存儲一年內(nèi)(2018年)所有存儲服務(wù)器的I/O活動數(shù)據(jù)進行收集，對采集到的I/O數(shù)據(jù)的時間、空間與相關(guān)性進行了分析，發(fā)現(xiàn)了一些有趣的現(xiàn)象，如在NERSC系統(tǒng)中，HPC應(yīng)用的讀I/O負載已經(jīng)遠遠超過寫I/O負載，寫I/O比讀I/O更突發(fā)，并且對象存儲目標機之間的I/O活動存在巨大的負載不平衡，與計算節(jié)點一樣強大的對象存儲服務(wù)器一般是空閑的，并且其CPU利用率非常低。

Turner等人[5]利用LASSi(Log Analytics for Shared System resource with instrumentation)工具(Cray公司開發(fā))[17]和SAFE(Service Administration From EPCC)軟件(愛丁堡并行計算中心開發(fā))[18]來收集和分析在英國國家超級計算服務(wù)ARCHER(Advanced Research Computing High End Resource)中Lustre集群存儲上的作業(yè)I/O性能數(shù)據(jù)，分析了不同應(yīng)用程序?qū)ξ募到y(tǒng)性能的潛在影響結(jié)果，并預(yù)測其將如何影響未來的I/O需求，進一步對這項工作未來可能的發(fā)展方向進行了概述。另外，作者觀察到ARCHER上寫入的數(shù)據(jù)量大概是讀取數(shù)據(jù)量的2倍，不同應(yīng)用實際寫入量與讀取量有較大差別。

Patel等人[4]使用應(yīng)用級的采集工具Darshan[8]收集了一臺排名前500的超級計算機上4個月的I/O訪問數(shù)據(jù)進行，對應(yīng)用I/O的訪問、重用和共享特性進行了深入的挖掘和分析，作者總結(jié)了10個“發(fā)現(xiàn)”，如文件可分為讀密集型RH(Read-Heavy，占比約22%)、寫密集型WH(Write-Heavy，占比約7%)或讀寫密集型RW(Read-and Write-heavy，占比約71%)，應(yīng)用負載情況以讀為主；讀任務(wù)比寫任務(wù)多，并且傳輸更多的數(shù)據(jù)量，但單次寫任務(wù)傳輸?shù)臄?shù)據(jù)量大概是讀任務(wù)傳輸數(shù)據(jù)量的1.4倍等等。其中一個有趣的“發(fā)現(xiàn)”是：現(xiàn)代HPC應(yīng)用程序在很大程度上傾向于在單個運行期間只執(zhí)行一種類型的I/O(讀或?qū)?，但這與假設(shè)HPC應(yīng)用程序在單個運行期間同時具有讀取和寫入I/O的觀點[19]相左。

2.2 國家基因庫日志采集與集群存儲系統(tǒng)

深圳國家基因庫CNGB(China National GeneBank)集群系統(tǒng)存儲生物資源和基因數(shù)據(jù)，對遺傳信息進行讀取和合成運用。本文使用Prometheus[20]采集CNGB存儲服務(wù)器應(yīng)用日志信息，被采集的5個Lustre集群存儲的相關(guān)信息如表 1所示，其中Lustre集群存儲及其客戶端的版本信息是該Lustre集群存儲2020年6月份的主流版本信息。

Table 1 Basic information of CNGB Lustre cluster storage

5個Lustre集群存儲的應(yīng)用日志信息大小分別是34 244 KB，34 148 KB，34 216 KB，34 692 KB和34 624 KB，總大小為171 924 KB，約168 MB應(yīng)用日志信息，應(yīng)用日志實際采集時間段：2019-08-01 00:00:01至2020-06-22 00:00:01，合計326天。

3 國家基因庫應(yīng)用負載特性與相關(guān)規(guī)律分析

本文針對國家基因庫的5個Lustre集群存儲應(yīng)用日志分析，主要探究以下關(guān)鍵問題：

(1)應(yīng)用讀寫類型問題；

(2)同一生產(chǎn)環(huán)境中，不同Lustre集群存儲/應(yīng)用讀寫類型的差異性；

(3)讀寫數(shù)據(jù)量的變化規(guī)律；

(4)異常情況發(fā)生的規(guī)律性，同一生產(chǎn)環(huán)境不同Lustre集群存儲的異常情況是否一致；

(5)如何運用應(yīng)用日志的分析來優(yōu)化存儲系統(tǒng)。

對以上5個關(guān)鍵問題的探究目的是試圖彌補現(xiàn)有發(fā)現(xiàn)的不足，豐富現(xiàn)有集群系統(tǒng)優(yōu)化資料庫。

3.1 多個Lustre集群存儲應(yīng)用日志分析

圖1給出了5個Lustre集群存儲讀寫數(shù)據(jù)量柱狀圖，橫坐標是Lustre集群存儲編號，縱坐標是讀寫數(shù)據(jù)量。觀察圖 1可以發(fā)現(xiàn)，運行在5個Lustre集群存儲上的應(yīng)用主要是讀多寫少類應(yīng)用，每個Lustre集群存儲讀寫總量比分別是：3.37，4.14，2.15，2.39和5.23，平均讀取數(shù)據(jù)量是寫入數(shù)據(jù)量的3.46倍。不同應(yīng)用的讀寫數(shù)據(jù)量比有較大差異，如集群存儲L_C的讀數(shù)據(jù)量是寫數(shù)據(jù)量的2.15倍，而集群存儲L_E的則為5.23倍。從圖1中可以進一步看出，5個Lustre集群存儲應(yīng)用數(shù)據(jù)的寫入量相差不大，平均44.38 TB，而讀取數(shù)據(jù)量有較大差異。所以，在實際生產(chǎn)環(huán)境(主要是生物信息領(lǐng)域)中，應(yīng)用主要以讀應(yīng)用為主，不同應(yīng)用的讀寫數(shù)據(jù)量有較大差異。

Figure 1 Read/Write data of five Lustre cluster storages

圖 2分別給出了5個Lustre集群存儲11個月讀取和寫入數(shù)據(jù)量趨勢圖。橫向?qū)Ρ让總€Lustre集群存儲的讀取和寫入數(shù)據(jù)量，可以明顯看出，隨時間變化讀取數(shù)據(jù)量和寫入數(shù)據(jù)量無線性關(guān)系，每月的讀取和寫入數(shù)據(jù)量不可預(yù)測；縱向?qū)Ρ?個Lustre集群存儲的讀取和寫入數(shù)據(jù)量，發(fā)現(xiàn)當月的讀取和寫入數(shù)據(jù)量并無直接關(guān)系，大量的寫入數(shù)據(jù)量并不一定會帶來大量的讀取數(shù)據(jù)量。

Figure 2 Read and write data of five Lustre cluster storage systems during eleven months

總的來說，從各月讀取和寫入數(shù)據(jù)量的趨勢圖可以看出，不同Lustre集群存儲上的應(yīng)用表現(xiàn)出了一致性，即：每個月的讀取數(shù)據(jù)量之間，每個月的寫入數(shù)據(jù)量之間和每個月的讀取和寫入數(shù)據(jù)量之間都無特別規(guī)律。這也符合客觀事實，即用戶行為(如啟動應(yīng)用、暫停、停止等操作)無法預(yù)測，使得集群存儲系統(tǒng)讀寫數(shù)據(jù)量整體看毫無規(guī)律，給緩存與預(yù)取策略的設(shè)計帶來了挑戰(zhàn)。

為進一步探究Lustre集群存儲讀寫數(shù)據(jù)量之間的關(guān)系，本文對比分析了集群存儲系統(tǒng)的OST(Object Storage Target)容量、因異常而丟棄(drop)的字節(jié)數(shù)與異常數(shù)量三者之間的聯(lián)系。

圖 3分別給出了5個Lustre集群存儲異常drop次數(shù)及其對應(yīng)的數(shù)據(jù)量，可以明顯看出，異常drop次數(shù)與其對應(yīng)的數(shù)據(jù)量之間沒有明確關(guān)系，即同一生產(chǎn)環(huán)境中，異常情況的發(fā)生沒有規(guī)律，不同Lustre集群存儲的異常情況都不可預(yù)測，隨機性較強。

Figure 3 Drop number and drop data of five Lustre cluster storage systems

通過對比5個Lustre集群存儲的讀寫數(shù)據(jù)量，進一步可以看出，Lustre集群存儲異常drop次數(shù)和其對應(yīng)的數(shù)據(jù)量與Lustre集群存儲的讀寫數(shù)據(jù)量之間并無聯(lián)系。這表明，用系統(tǒng)異常來預(yù)測或優(yōu)化系統(tǒng)的讀寫操作很難獲得良好的效果。

為了進一步探究更細粒度的Lustre集群存儲應(yīng)用日志信息，接下來選取集群存儲L_A作為研究對象，進行更深入的分析。

3.2 單個Lustre集群存儲應(yīng)用日志分析

從2.1節(jié)的統(tǒng)計分析可以看出，5個Lustre集群存儲表現(xiàn)比較一致，為了更進一步探究應(yīng)用日志的特性，本節(jié)選取了集群存儲L_A的I/O數(shù)據(jù)量作為研究對象，分別針對集群存儲L_A在不同時間尺度下的讀寫數(shù)據(jù)量進行量化分析。

圖4給出了集群存儲L_A不同月份某天1小時內(nèi)的讀取數(shù)據(jù)量折線圖和當天1小時內(nèi)對應(yīng)的寫入數(shù)據(jù)量折線圖。從圖4中可以看出，9月、10月和11月讀數(shù)據(jù)量相比于其他幾個月的讀數(shù)據(jù)量偏高，但幾乎一致處于偏高水準，比較穩(wěn)定，而寫入數(shù)據(jù)量僅10月處于偏高水準，并且整個時間段10月的寫入數(shù)據(jù)量都大于其他幾個月的寫入數(shù)據(jù)量。通過以上分析可以看出，短時間內(nèi)(如1個小時)，大部分應(yīng)用的讀寫數(shù)據(jù)量大致趨于穩(wěn)定(偏高的一直處于偏高水準，偏低的一直處于偏低水準，很少呈現(xiàn)出鋸齒形)。另外，大多數(shù)應(yīng)用的讀寫比相當，僅9月和11月的平均讀數(shù)據(jù)量遠高于寫數(shù)據(jù)量。少部分應(yīng)用是讀多寫少類應(yīng)用，大部分應(yīng)用的讀寫數(shù)據(jù)量相差不大。為了排除異常drop數(shù)據(jù)量對讀寫數(shù)據(jù)量的影響，本文對相關(guān)的drop字節(jié)數(shù)數(shù)據(jù)進行了分析，僅發(fā)現(xiàn)8月的第60分鐘和10月的第40分鐘有17.33字節(jié)的數(shù)據(jù)量丟失，相比于真實讀寫數(shù)據(jù)量，基本可以忽略不計。

Figure 4 Read and Write data within one hour on a day in different months of L_A

總的來說，類似的應(yīng)用，I/O模式具有相似性，大多數(shù)應(yīng)用的讀寫需求量差別不大，僅個別應(yīng)用有較高的讀寫需求。

圖 5給出了集群存儲L_A不同月份某天內(nèi)的讀取數(shù)據(jù)量和寫入數(shù)據(jù)量折線圖。從圖5中可以明顯看出，相比于圖4，圖5的折線幅度較大。但是，讀取需求高的應(yīng)用，當天的讀取數(shù)據(jù)量一直偏高(如9月、10月和11月)，而寫入數(shù)據(jù)量卻呈現(xiàn)鋸齒形波動(如1月、2月、4月和5月)，這充分驗證了HPC領(lǐng)域常見的I/O突發(fā)寫特性，但沒有表現(xiàn)出特定時間段內(nèi)(一天中)讀寫數(shù)據(jù)量集體偏高或偏低的情形，另外，除了9月和11月，大多數(shù)應(yīng)用的讀寫數(shù)據(jù)量的比例相當，與1小時內(nèi)得到的結(jié)論相符，對相關(guān)drop字節(jié)數(shù)數(shù)據(jù)進行了分析，得出了類似1小時讀寫比例的相關(guān)結(jié)論。這從側(cè)面證明了在該環(huán)境中應(yīng)用比較穩(wěn)定，僅有少部分應(yīng)用是讀多寫少類應(yīng)用，大部分應(yīng)用的讀寫數(shù)據(jù)量相差不大。

Figure 5 Read and Write data on a day in different months of L_A

本文也對集群存儲L_A不同月份29天內(nèi)的讀寫數(shù)據(jù)量進行了分析，分析發(fā)現(xiàn)讀取數(shù)據(jù)量部分應(yīng)用波動較大，但大部分讀取數(shù)據(jù)量比較穩(wěn)定，寫入數(shù)據(jù)量雖然相比于讀取數(shù)據(jù)量較少，但與1天內(nèi)的寫入數(shù)據(jù)量類似，呈現(xiàn)鋸齒形波動，另外對相關(guān)drop字節(jié)數(shù)數(shù)據(jù)進行了分析，得出了類似1小時、1天的讀寫比例的相關(guān)結(jié)論。

總而言之，針對當前研究的Lustre集群存儲應(yīng)用，其突發(fā)性讀取操作較少(如圖4a和圖5a)，突發(fā)性寫入操作較多(圖5b)。另外，根據(jù)集群存儲L_A在1個小時內(nèi)、1天內(nèi)和29天內(nèi)的讀寫數(shù)據(jù)量的各類測試圖可以看出，同一個系統(tǒng)中，I/O一直存在，且讀取和寫入操作是同時進行的。

4 系統(tǒng)優(yōu)化與討論

本節(jié)將進一步討論5個關(guān)鍵問題，總結(jié)相關(guān)發(fā)現(xiàn)并與已有文獻進行對比，給出系統(tǒng)優(yōu)化策略和建議；同時，針對系統(tǒng)優(yōu)化的自動化需求，設(shè)計并實現(xiàn)了SAOF，且初步驗證了其有效性。

4.1 相關(guān)發(fā)現(xiàn)總結(jié)

第2節(jié)對5個Lustre集群存儲的應(yīng)用日志進行了橫向(多個Lustre集群存儲應(yīng)用日志)和縱向(單個Lustre集群存儲應(yīng)用日志)對比分析，有以下幾點發(fā)現(xiàn)：

發(fā)現(xiàn)1在國家基因庫實際生產(chǎn)環(huán)境中，應(yīng)用主要偏向讀多寫少型(5個Lustre集群存儲，平均讀取數(shù)據(jù)量是寫入數(shù)據(jù)量的3.46倍)，另外不同應(yīng)用總的讀寫數(shù)據(jù)量有較大差異(如集群存儲L_C的讀數(shù)據(jù)量是寫數(shù)據(jù)量的2.15倍，而集群存儲L_E的讀數(shù)據(jù)量是寫數(shù)據(jù)量的5.23倍)。大多數(shù)應(yīng)用的讀寫數(shù)據(jù)量相差不大，僅個別應(yīng)用負載有較高的讀寫需求。

發(fā)現(xiàn)2同一個系統(tǒng)中，I/O一直存在，并且讀取和寫入操作通常是同時進行的。短時間內(nèi)(如1個小時)，應(yīng)用的讀寫數(shù)據(jù)量大致趨于穩(wěn)定，即I/O模式具有相似性或周期性。但是，每個月的讀取數(shù)據(jù)量之間，每個月的寫入數(shù)據(jù)量之間無特別規(guī)律。

發(fā)現(xiàn)3讀取數(shù)據(jù)量偏高的應(yīng)用，其讀取數(shù)據(jù)量一直偏高，而寫入數(shù)據(jù)量卻呈現(xiàn)鋸齒形波動，主要表現(xiàn)為I/O突發(fā)寫特性，但并沒有表現(xiàn)出特定時間段內(nèi)(1天中)讀寫數(shù)據(jù)量集體偏高或偏低的情形。

發(fā)現(xiàn)4同一生產(chǎn)環(huán)境中，異常情況的發(fā)生沒有規(guī)律，不同Lustre集群存儲的異常情況都不可預(yù)測，隨機性較強。因為異常drop的數(shù)據(jù)量較少，并沒有對實際讀寫數(shù)據(jù)量產(chǎn)生較大影響。

4.2 對比分析

針對本文的“發(fā)現(xiàn)1”已有相關(guān)研究，如Patel等人[3]分析發(fā)現(xiàn)應(yīng)用的讀I/O負載遠遠超過寫I/O負載，但Turner等人[5]對應(yīng)用分析發(fā)現(xiàn)寫入數(shù)據(jù)量大概是讀取數(shù)據(jù)量的2倍。本文的“發(fā)現(xiàn)1”可以與上述研究相互印證。在本文測試的生產(chǎn)環(huán)境中，應(yīng)用偏向于讀多寫少，不同應(yīng)用讀寫負載差異較大，并且有如下補充：大多數(shù)應(yīng)用的讀寫數(shù)據(jù)量相差不大，僅個別應(yīng)用有較高的讀寫需求。本文的“發(fā)現(xiàn)1”在一定程度上進一步完善了應(yīng)用負載類型相關(guān)文獻。其中引起負載類型差異的主要原因可能是不同研究機構(gòu)/數(shù)據(jù)中心的受眾不同，在其系統(tǒng)上運行的應(yīng)用大多數(shù)具有類似性質(zhì)，使得應(yīng)用負載總體看來具有了比較偏向的需求(如讀多寫少、寫多讀少等)，但單個應(yīng)用可能表現(xiàn)并不明顯，即單個應(yīng)用的讀寫數(shù)據(jù)量差異可能并不巨大。

針對本文的“發(fā)現(xiàn)2”已有相關(guān)研究，如Patel等人[4]發(fā)現(xiàn)HPC文件讀寫表現(xiàn)出周期性，并且應(yīng)用程序在很大程度上傾向于在單個運行期間只執(zhí)行一種類型的I/O：讀或?qū)?。但是，本文的“發(fā)現(xiàn)2”通過對應(yīng)用日志進行詳細分析，卻發(fā)現(xiàn)同一個系統(tǒng)中I/O一直存在，且讀取和寫入操作通常是同時進行的，短期內(nèi)讀寫I/O都比較穩(wěn)定，具有相似性或周期性，印證了HPC應(yīng)用程序在單個運行期間同時具有讀取和寫入I/O的觀點[19]。另外，本文的“發(fā)現(xiàn)2”進一步給出了長時間讀寫數(shù)據(jù)量并無特別規(guī)律的現(xiàn)象。

針對本文的“發(fā)現(xiàn)3”也有相關(guān)研究，如Patel等人[3]觀察到寫I/O比讀I/O更突發(fā)，本文也觀察到了類似現(xiàn)象，即寫入數(shù)據(jù)量呈現(xiàn)鋸齒形波動，而且讀取數(shù)據(jù)量偏高的應(yīng)用，其讀取數(shù)據(jù)量一直偏高，比較穩(wěn)定，并且沒有表現(xiàn)出特定時間段內(nèi)(1天中)讀寫數(shù)據(jù)量集體偏高或偏低的情形。本文的“發(fā)現(xiàn)3”可以看作是對已有研究的補充。

針對本文的“發(fā)現(xiàn)4”，分析應(yīng)用日志并同時分析異常的相關(guān)研究較少，但僅對異常進行分析優(yōu)化系統(tǒng)的研究較多。本文的“發(fā)現(xiàn)4”可以作為Lustre集群存儲異常優(yōu)化的一份參考資料。

4.3 系統(tǒng)優(yōu)化策略

針對“發(fā)現(xiàn)1”，讀多寫少類應(yīng)用，并且大多數(shù)應(yīng)用的讀寫數(shù)據(jù)量相差不大，僅個別應(yīng)用有較高的讀寫數(shù)據(jù)量需求，有如下優(yōu)化建議：應(yīng)用分類，數(shù)據(jù)分級存儲，如針對讀寫數(shù)據(jù)量差異較大的應(yīng)用，可以配備高性能硬件設(shè)備或大內(nèi)存，設(shè)置預(yù)取規(guī)則，縮短應(yīng)用讀階段耗時，優(yōu)化系統(tǒng)整體性能；而對于讀寫數(shù)據(jù)量差異較小的應(yīng)用，讀寫數(shù)據(jù)量相對較少，建議采用緩存算法來優(yōu)化系統(tǒng)，既可以在一定程度上減少硬件開支，又能合理利用已有高速緩存設(shè)備，優(yōu)化系統(tǒng)讀寫性能。

針對“發(fā)現(xiàn)2”，I/O一直存在讀寫同時進行的情況，由于寫入會影響讀取操作，可以采用讀寫分流策略，另由于短時間的讀寫數(shù)據(jù)量比較穩(wěn)定，但長時間讀寫數(shù)據(jù)量之間無特別規(guī)律，可能會引起OST端存儲負載不均的問題，建議根據(jù)短時間讀寫數(shù)據(jù)量、底層硬件的讀寫速度差異與文件系統(tǒng)剩余空間，制定讀寫分流策略。這樣設(shè)計可以在保證前端應(yīng)用讀寫性能較優(yōu)的同時，減少后期因OST剩余空間不均衡而引發(fā)額外的數(shù)據(jù)遷移操作，也避免了數(shù)據(jù)遷移操作對正常I/O讀寫的干擾。

針對“發(fā)現(xiàn)3”，讀取數(shù)據(jù)量比較平穩(wěn)而I/O表現(xiàn)為突發(fā)寫的特性，可以采用PCC(Persistent Client Caching)技術(shù)[21,22]進行優(yōu)化。另外，一般應(yīng)用，如社交軟件，會出現(xiàn)白天或夜晚使用用戶較多，凌晨使用用戶較少，而引起服務(wù)器負載不均衡的現(xiàn)象。但是，根據(jù)本文的“發(fā)現(xiàn)3”，讀寫數(shù)據(jù)量未出現(xiàn)某時段集體偏高或偏低的情形，其主要原因是用戶群不同。在國家基因庫實際生產(chǎn)環(huán)境中，應(yīng)用主要面向生物信息領(lǐng)域，為了最大化資源利用率，節(jié)省經(jīng)濟開銷，用戶和運維人員都傾向于讓系統(tǒng)滿負荷運行相關(guān)任務(wù)，這在一定程度上對系統(tǒng)的可用性和可維護性提出了挑戰(zhàn)。針對以上挑戰(zhàn)，為了確保系統(tǒng)穩(wěn)定，建議部署監(jiān)控報警系統(tǒng)，并對相關(guān)文件設(shè)計數(shù)據(jù)安全策略(如File Level Redundancy和Erasure Coding等)。

針對“發(fā)現(xiàn)4”，根據(jù)Lustre集群存儲異常的隨機性與異常drop數(shù)據(jù)量的占比可知，如果僅用Lustre集群存儲異常來預(yù)測或優(yōu)化系統(tǒng)的讀寫操作可能無法獲得良好的效果。當I/O出現(xiàn)異常時，一般情況下，管理員會查看服務(wù)器節(jié)點的資源利用率，但根據(jù)本文第2節(jié)的分析可知，服務(wù)器節(jié)點的資源利用率是比較穩(wěn)定的，那么管理員通常會認為異常I/O的應(yīng)用在MDS或OSS上與其他應(yīng)用產(chǎn)生了資源爭用。針對以上異常問題，建議將服務(wù)器端日志與應(yīng)用程序I/O模式相關(guān)聯(lián)，但困難在于Lustre集群存儲實現(xiàn)了客戶端頁面緩存，在數(shù)據(jù)回寫時，客戶端頁面緩存會將非常小但連續(xù)的I/O重組為大型順序I/O寫入后端存儲系統(tǒng)，并且此過程中應(yīng)用的配置和后端存儲系統(tǒng)的監(jiān)控(只能看到寫回的數(shù)據(jù))都是透明的。因此建議針對非常小的I/O采用MOD(Data-On-Metadata)機制，在客戶端就區(qū)分I/O的大小流，在提升小文件讀寫I/O的同時，減少原有后端存儲系統(tǒng)的監(jiān)控對象，為關(guān)聯(lián)服務(wù)器端日志與應(yīng)用程序I/O模式提供便利。

4.4 面向Lustre集群存儲的系統(tǒng)自動優(yōu)化框架

從前面應(yīng)用日志分析及系統(tǒng)優(yōu)化實踐中發(fā)現(xiàn)，提升系統(tǒng)優(yōu)化的自動化水平(或者說智能性)，能降低系統(tǒng)運維人員的工作強度，提升系統(tǒng)優(yōu)化效率。

4.4.1 系統(tǒng)自動優(yōu)化需求分析

根據(jù)“發(fā)現(xiàn)1”可知，大多數(shù)應(yīng)用的讀寫數(shù)據(jù)量相差不大，僅個別應(yīng)用負載有較高的讀寫需求，那么在實際環(huán)境中，可以根據(jù)應(yīng)用特性為其提供QoS(Quality of Service)保證，設(shè)計資源利用規(guī)則，即滿足其隔離與資源需求。根據(jù)“發(fā)現(xiàn)2”可知，I/O的周期性可以為存儲系統(tǒng)資源利用提供事實依據(jù)，即在根據(jù)應(yīng)用特性進行隔離時，依據(jù)I/O周期性特性，可以估算出當前正在運行、排隊的任務(wù)的完成時間、資源需求等，并設(shè)置相應(yīng)的調(diào)度策略，進而使得資源利用更具合理性。根據(jù)“發(fā)現(xiàn)3”可知，同一應(yīng)用，長時間看，其應(yīng)用I/O需求比較穩(wěn)定，這有助于探究和利用Lustre集群存儲的系統(tǒng)狀態(tài)獲取命令(lfs/lctl)來分析/獲取負載特性，按需提供資源利用服務(wù)，并可應(yīng)對一些應(yīng)用的突發(fā)需求(如checkpoint)。根據(jù)“發(fā)現(xiàn)4”可知，對OSS端I/O讀寫數(shù)據(jù)量的探究可以較好地代表Lustre集群存儲的整體I/O狀態(tài)，一般采用Prometheus常規(guī)應(yīng)用監(jiān)控，可以避免監(jiān)控對系統(tǒng)過多影響，或者利用Lustre集群存儲提供的已有命令(lfs/lctl)，不添加其他監(jiān)控部件，能進一步減少對系統(tǒng)性能的影響，也能較好地獲得Lustre集群存儲的狀態(tài)。

通過剖析以上發(fā)現(xiàn)不難看出，不管應(yīng)用負載如何多變，對存儲系統(tǒng)資源的自動管理(特別是資源預(yù)留與限定)才是關(guān)鍵。下面將簡要介紹現(xiàn)階段Lustre集群存儲的QoS解決方案與任務(wù)調(diào)度器并分析它們的不足之處。

Lustre集群存儲已有較多的QoS解決方案，例如：Lustre集群存儲的NRS(Network Request Scheduler)[23]中采用令牌桶過濾器TBF(Token Bucket Filter)進行帶寬限制[1]并提供最小帶寬保證[24]的NRS-RBF策略；通過對Lustre集群存儲原有TBF策略進行擴展，文獻[25]提供了依賴規(guī)則TBF策略，通過手動設(shè)置優(yōu)化關(guān)聯(lián)任務(wù)的遠程過程調(diào)用RPC(Remote Procedure Call)速率，提供關(guān)聯(lián)任務(wù)QoS保障;針對原有TBF策略的一些功能缺乏問題，如只能限制RPC速率，不能對帶寬或每秒進行讀寫操作的次數(shù)IOPS(Input/Output operations Per Second)進行限制，僅針對單個OST/元數(shù)據(jù)目標MDT(MetaData Target)，無全局管理方案等問題，文獻[26]提出了LIME(Lustre Intelligent Management Engine)框架;以及近期我們提出的利用深度強化學習方法進行端到端I/O調(diào)度的方案。但是，以上方案大都未考慮資源預(yù)留與已有任務(wù)調(diào)度器相結(jié)合方面的問題。通過對SLURM(Simple Linux Utility for Resource Management)[28]和現(xiàn)有Lustre集群存儲的資源規(guī)劃方案的探究有以下發(fā)現(xiàn)：(1)當提交的任務(wù)資源請求不滿足時，SLURM 會一直等待輪詢該任務(wù)；(2)并行文件系統(tǒng)(如Lustre集群存儲或GPFS(General Parallel File System))為調(diào)度器提供讀寫時，隱藏了管理存儲性能所需的許多細節(jié)，如后端存儲服務(wù)器的數(shù)據(jù)布局策略；(3)很少有作業(yè)調(diào)度器實現(xiàn)了自動化的(資源預(yù)留)調(diào)度。

為了保證系統(tǒng)可擴展性和可用性，系統(tǒng)運維人員在執(zhí)行任務(wù)時，為減少資源競爭和任務(wù)調(diào)度器的失誤，常常采用過度分配的方式管理資源。另外，現(xiàn)有Lustre資源管理方案缺乏通過分析存儲集群中文件數(shù)據(jù)位置與工作負載并"自動按需"提供系統(tǒng)服務(wù)/優(yōu)化相關(guān)功能。

總的來說，現(xiàn)有方案在Lustre集群存儲內(nèi)部狀態(tài)的信息(如后端存儲服務(wù)的資源與數(shù)據(jù)管理等信息)、存儲帶寬管理、作業(yè)的帶寬消耗與面對周期性或臨時性任務(wù)的資源預(yù)留等方面，缺乏自動優(yōu)化能力?；谝陨戏治龊蛯嶋H應(yīng)用需求，面向Lustre集群存儲，本文設(shè)計并實現(xiàn)了一個系統(tǒng)自動化優(yōu)化框架SAOF。在實際部署中，SAOF被設(shè)計為Lustre集群存儲中的一個新實例，它接收來自job管理系統(tǒng)(如SLURM)的讀寫帶寬請求，并通過配置Lustre集群存儲的網(wǎng)絡(luò)請求調(diào)度器(NRS)，限制已注冊計算任務(wù)的帶寬，在資源滿足時保證任務(wù)QoS。具體來說，SAOF的主要功能是通過Lustre集群存儲常用命令lfs/lctl獲取集群存儲相關(guān)資源信息，并調(diào)用Lustre集群存儲的NRS-TBF調(diào)度器實現(xiàn)資源預(yù)留與限定[24]。SAOF的資源預(yù)留功能可以為數(shù)據(jù)遷移預(yù)留帶寬，緩解OST端存儲負載不均和數(shù)據(jù)遷移等問題；SAOF的資源限定可以達到應(yīng)用隔離并確保應(yīng)用QoS的目的。下面將介紹SAOF方案的具體實現(xiàn)。

4.4.2 SAOF設(shè)計

圖6給出了SAOF的系統(tǒng)架構(gòu)圖。圖6中虛線框給出了SAOF的主要組件，包括用來獲取前端用戶提交的任務(wù)信息與任務(wù)調(diào)度器交互的SAOF frontend API，更新與設(shè)置NRS-TBF策略的NRS-TBF Scheduler和當前任務(wù)狀態(tài)的JobState和當前后端集群存儲系統(tǒng)狀態(tài)的ClusterState。SAOF通過高速網(wǎng)絡(luò)與Lustre集群存儲的客戶端、服務(wù)器互聯(lián)。SAOF啟動后，會周期性的聚合來自作業(yè)調(diào)度器的請求，收集來自服務(wù)器的資源利用情況，根據(jù)相應(yīng)的規(guī)則設(shè)置NRS-TBF策略，并廣播到相應(yīng)的OSS/MDS?？偟膩碚f，SAOF的工作重心是從SLURM獲取任務(wù)信息，并組合來自集群的資源利用情況，自動構(gòu)建TBF策略。

Figure 6 Architecture of SAOF

Lustre集群存儲默認的最大RPC通常是1 MB，默認4 KB讀寫情況下，NRS-TBF的1 rate=4 KiB/s的帶寬，因此集群系統(tǒng)的總帶寬基本上可以穩(wěn)定地定義為Lbw，也可以通過設(shè)定不同的rate來確保不同的帶寬需求。圖7給出了SAOF框架流程圖，其通過剩余帶寬判斷是否接受新任務(wù)或修改已運行任務(wù)等級來減少前端調(diào)度器的試錯，即當∑iminbwi≤Lbw時，接受新任務(wù)或改變已有任務(wù)優(yōu)先級；否則把Lustre集群存儲資源信息反饋給任務(wù)調(diào)度器，減少試錯，減輕服務(wù)器計算、存儲和網(wǎng)絡(luò)壓力。其中minbwi表示第i個任務(wù)所需要的最小帶寬。下面將分別對SAOF的性能隔離、QoS保障和資源預(yù)留功能進行測試。

Figure 7 Flow of SAOF

4.4.3 SAOF功能測試與驗證

由于國家基因庫短期內(nèi)沒有新增系統(tǒng)需求，當前運行的都是生產(chǎn)系統(tǒng)，為了驗證本文提出的系統(tǒng)自動優(yōu)化框架的有效性，在實驗室構(gòu)建一個小型Lustre集群存儲對SAOF進行了初步測試。該小型Lustre集群存儲主要包括：3個客戶端，2個OSS并各自掛載了2個549.0 GB的OST，聚合容量2.1 TB，1個MDS掛載了1個261.4 GB的MDT；操作系統(tǒng)為CentOS 7.5；Lustre集群存儲版本為2.12.1；通過1 GB以太網(wǎng)互連。采用FIO(Flexible I/O tester)[29]測試工具(fio-3.7)生成相關(guān)任務(wù)負載，主要給出了寫帶寬的測試(讀帶寬、IOPS也可以通過設(shè)定相應(yīng)的TBF策略獲得類似的效果，示例中給出了對應(yīng)的IOPS測試圖)。測試如下所示：

(1) 性能隔離、QoS保障測試。

設(shè)計實驗如下：假設(shè)系統(tǒng)能提供的總寫帶寬約為500 KiB/s，現(xiàn)在有2個任務(wù)A和B，任務(wù)A大概需要300 KiB/s的最大寫帶寬，大概200 KiB/s的最小寫帶寬，需要傳輸約200 MiB的數(shù)據(jù)量，任務(wù)B的優(yōu)先級高于任務(wù)A，任務(wù)B需要保證300 KiB/s左右的寫帶寬，需要傳輸約100 MiB的數(shù)據(jù)量。

從圖 8中可以看出，測試開始時，任務(wù)A開始運行，系統(tǒng)提供大概300 KiB/s的最大寫帶寬，當任務(wù)A運行300秒后，任務(wù)B開始運行，此時，任務(wù)A的寫帶寬降到200 KiB/s左右，任務(wù)B以300 KiB/s左右的寫帶寬運行，又過了340秒左右后，任務(wù)B運行完成，任務(wù)A再度恢復(fù)300 KiB/s左右的寫帶寬運行，總共770秒左右后，任務(wù)A運行完成。實驗結(jié)果能較好地滿足預(yù)期。

通過以上實驗驗證了SAOF能對特殊任務(wù)提供性能隔離并滿足其服務(wù)質(zhì)量。

Figure 8 Performance isolation and QoS assurance

(2) 資源預(yù)留測試。

設(shè)計實驗如下：假設(shè)系統(tǒng)提供給任務(wù)的總寫帶寬約為500 KiB/s，現(xiàn)有3個任務(wù)A、B和C，任務(wù)A和任務(wù)B同優(yōu)先級，需求帶寬與傳輸數(shù)據(jù)量都相同，需要大概250 KiB/s的最大寫帶寬，100 KiB/s的最小寫帶寬，需要傳輸約200 MiB的數(shù)據(jù)量，任務(wù)C的優(yōu)先級高于任務(wù)A和任務(wù)B，任務(wù)C需要保證300 KiB/s左右的寫帶寬，需要傳輸約50 MiB的數(shù)據(jù)量，并且任務(wù)C需要周期性運行(每次傳輸50 MiB的數(shù)據(jù)量，總共需要傳輸3次)。

Figure 9 Periodic resource reservation and QoS assurance

圖9給出了周期性資源預(yù)留與QoS保障測試圖。從圖9中可以明顯看出,任務(wù)A與任務(wù)B幾乎獲得了相同的資源在運行，每當任務(wù)C開始執(zhí)行時，任務(wù)A和B的寫帶寬都會下降；另外，系統(tǒng)總的帶寬消耗Total(A+B+C)，除了在任務(wù)調(diào)度時有所下降外，其他情況下都能保證大約500 KiB/s的寫帶寬。

通過以上實驗可以驗證SAOF能對周期性應(yīng)用提供資源預(yù)留功能，確保應(yīng)用服務(wù)質(zhì)量。

5 結(jié)束語

集群存儲系統(tǒng)負責為上層應(yīng)用提供數(shù)據(jù)讀寫與存儲服務(wù)，良好的集群存儲系統(tǒng)應(yīng)自動適應(yīng)上層應(yīng)用按需訪問。針對在復(fù)雜系統(tǒng)環(huán)境以及應(yīng)用多樣性情況，對應(yīng)用負載的特性挖掘不夠完善等問題，本文對實際生產(chǎn)環(huán)境的Lustre集群存儲的應(yīng)用日志信息進行了分析。具體來說，采集了國家基因庫生產(chǎn)環(huán)境中，5個Lustre集群存儲連續(xù)326天應(yīng)用日志相關(guān)信息，通過對應(yīng)用日志信息橫向(多個Lustre集群存儲應(yīng)用日志)、縱向(單個Lustre集群存儲應(yīng)用日志)和多維度(時間與空間)的對比分析，對現(xiàn)有研究進行補充完善，也為其它系統(tǒng)/應(yīng)用負載研究提供了參考。通過對5個關(guān)鍵問題的回答與4個發(fā)現(xiàn)的分析，結(jié)合實際生產(chǎn)環(huán)境，給出了系統(tǒng)優(yōu)化策略建議與切實可行的實施方案。同時，針對系統(tǒng)性能優(yōu)化自動化需求，設(shè)計并實現(xiàn)了SAOF，SAOF通過合理利用應(yīng)用需求和集群存儲帶寬資源等信息提供資源預(yù)留、帶寬限制等功能，初步實驗驗證了SAOF的有效性。