面向Lustre集群存儲的應用日志分析及系統自動優化框架*

程 穩，李 焱，曾令仿，王 芳，唐士程，楊力平，馮 丹，曾文君

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

1 引言

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

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

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

2 應用日志相關研究

2.1 現有應用日志采集與分析研究

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

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

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

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

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

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

2.2 國家基因庫日志采集與集群存儲系統

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

Table 1 Basic information of CNGB Lustre cluster storage

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

3 國家基因庫應用負載特性與相關規律分析

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

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

(2)同一生產環境中，不同Lustre集群存儲/應用讀寫類型的差異性；

(3)讀寫數據量的變化規律；

(4)異常情況發生的規律性，同一生產環境不同Lustre集群存儲的異常情況是否一致；

(5)如何運用應用日志的分析來優化存儲系統。

對以上5個關鍵問題的探究目的是試圖彌補現有發現的不足，豐富現有集群系統優化資料庫。

3.1 多個Lustre集群存儲應用日志分析

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

Figure 1 Read/Write data of five Lustre cluster storages

圖 2分別給出了5個Lustre集群存儲11個月讀取和寫入數據量趨勢圖。橫向對比每個Lustre集群存儲的讀取和寫入數據量，可以明顯看出，隨時間變化讀取數據量和寫入數據量無線性關系，每月的讀取和寫入數據量不可預測；縱向對比5個Lustre集群存儲的讀取和寫入數據量，發現當月的讀取和寫入數據量并無直接關系，大量的寫入數據量并不一定會帶來大量的讀取數據量。

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

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

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

圖 3分別給出了5個Lustre集群存儲異常drop次數及其對應的數據量，可以明顯看出，異常drop次數與其對應的數據量之間沒有明確關系，即同一生產環境中，異常情況的發生沒有規律，不同Lustre集群存儲的異常情況都不可預測，隨機性較強。

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

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

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

3.2 單個Lustre集群存儲應用日志分析

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

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

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

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

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

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

本文也對集群存儲L_A不同月份29天內的讀寫數據量進行了分析，分析發現讀取數據量部分應用波動較大，但大部分讀取數據量比較穩定，寫入數據量雖然相比于讀取數據量較少，但與1天內的寫入數據量類似，呈現鋸齒形波動，另外對相關drop字節數數據進行了分析，得出了類似1小時、1天的讀寫比例的相關結論。

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

4 系統優化與討論

本節將進一步討論5個關鍵問題，總結相關發現并與已有文獻進行對比，給出系統優化策略和建議；同時，針對系統優化的自動化需求，設計并實現了SAOF，且初步驗證了其有效性。

4.1 相關發現總結

第2節對5個Lustre集群存儲的應用日志進行了橫向(多個Lustre集群存儲應用日志)和縱向(單個Lustre集群存儲應用日志)對比分析，有以下幾點發現：

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

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

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

發現4同一生產環境中，異常情況的發生沒有規律，不同Lustre集群存儲的異常情況都不可預測，隨機性較強。因為異常drop的數據量較少，并沒有對實際讀寫數據量產生較大影響。

4.2 對比分析

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

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

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

針對本文的“發現4”，分析應用日志并同時分析異常的相關研究較少，但僅對異常進行分析優化系統的研究較多。本文的“發現4”可以作為Lustre集群存儲異常優化的一份參考資料。

4.3 系統優化策略

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

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

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

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

4.4 面向Lustre集群存儲的系統自動優化框架

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

4.4.1 系統自動優化需求分析

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

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

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

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

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

4.4.2 SAOF設計

圖6給出了SAOF的系統架構圖。圖6中虛線框給出了SAOF的主要組件，包括用來獲取前端用戶提交的任務信息與任務調度器交互的SAOF frontend API，更新與設置NRS-TBF策略的NRS-TBF Scheduler和當前任務狀態的JobState和當前后端集群存儲系統狀態的ClusterState。SAOF通過高速網絡與Lustre集群存儲的客戶端、服務器互聯。SAOF啟動后，會周期性的聚合來自作業調度器的請求，收集來自服務器的資源利用情況，根據相應的規則設置NRS-TBF策略，并廣播到相應的OSS/MDS。總的來說，SAOF的工作重心是從SLURM獲取任務信息，并組合來自集群的資源利用情況，自動構建TBF策略。

Figure 6 Architecture of SAOF

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

Figure 7 Flow of SAOF

4.4.3 SAOF功能測試與驗證

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

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

設計實驗如下：假設系統能提供的總寫帶寬約為500 KiB/s，現在有2個任務A和B，任務A大概需要300 KiB/s的最大寫帶寬，大概200 KiB/s的最小寫帶寬，需要傳輸約200 MiB的數據量，任務B的優先級高于任務A，任務B需要保證300 KiB/s左右的寫帶寬，需要傳輸約100 MiB的數據量。

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

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

Figure 8 Performance isolation and QoS assurance

(2) 資源預留測試。

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

Figure 9 Periodic resource reservation and QoS assurance

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

通過以上實驗可以驗證SAOF能對周期性應用提供資源預留功能，確保應用服務質量。

5 結束語

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