近年來(lái)，Lustre作為一個(gè)開(kāi)源的高性能分布式集群文件系統(tǒng)，以其PB級(jí)的共享存儲(chǔ)容量和上百吉字節(jié)每秒的聚合 I/O帶寬被廣泛應(yīng)用于HPC領(lǐng)域。有數(shù)據(jù)[1]表明Lustre在HPC領(lǐng)域占有最大的市場(chǎng)份額，已成為構(gòu)建HPC集群的事實(shí)上的標(biāo)準(zhǔn)。將Lustre引入到傳統(tǒng)的MPI集群解決I/O瓶頸,可提升并行計(jì)算速度。但是簡(jiǎn)單地將Lustre移植到MPI集群中并不能獲得預(yù)期的效果。其主要原因是，運(yùn)行MPI的并行程序需要進(jìn)行大量的I/O訪問(wèn)，而在這些I/O訪問(wèn)中基于小數(shù)據(jù)（細(xì)粒度）的I/O訪問(wèn)往往占據(jù)著相當(dāng)大的比率，雖然Lustre能在連續(xù)大數(shù)據(jù)（粗粒度）傳輸上達(dá)到很高的I/O帶寬，但在不連續(xù)小數(shù)據(jù)傳輸上并沒(méi)有獲得顯著的性能提升。當(dāng)大量小數(shù)據(jù)I/O頻繁訪問(wèn)時(shí)，就會(huì)使該文件系統(tǒng)的整體性能迅速下降，以至實(shí)際I/O帶寬遠(yuǎn)低于所提供的最大帶寬。

    為解決這一問(wèn)題,通常的方法是在Lustre的上層加入一個(gè)并行I/O庫(kù),通過(guò)該庫(kù)將多個(gè)不連續(xù)小數(shù)據(jù)塊的I/O操作轉(zhuǎn)化為對(duì)并行文件系統(tǒng)中的少量連續(xù)大數(shù)據(jù)塊的實(shí)際I/O操作，最大程度地利用并行文件系統(tǒng)所提供的帶寬，減少I/O瓶頸對(duì)程序性能的影響，在庫(kù)的級(jí)別上優(yōu)化并行I/O的訪問(wèn)效率。本文提出了一種基于MPI-IO庫(kù)（并行I/O庫(kù)）編程接口的改進(jìn)方案，以保證在小數(shù)據(jù)整合為大數(shù)據(jù)的過(guò)程中進(jìn)一步減少進(jìn)程間的通信量和時(shí)間消耗，從而提升集群并行效率，為傳統(tǒng)MPI集群的升級(jí)改造提供新的思路或新的方法。
1 Lustre文件系統(tǒng)性能介紹
    Lustre是面向集群的存儲(chǔ)架構(gòu)，是基于Linux平臺(tái)的開(kāi)源集群（并行）文件系統(tǒng)。由于其提供了與POSIX兼容的文件系統(tǒng)接口，從而使其擴(kuò)展了應(yīng)用領(lǐng)域。Lustre擁有高性能和高擴(kuò)展性兩個(gè)最大特征。高性能是指它能夠支持?jǐn)?shù)萬(wàn)客戶端系統(tǒng)、PB級(jí)存儲(chǔ)容量和數(shù)百GB的聚合I/O吞吐量;高擴(kuò)展性是指由于Lustre是Scale-Out存儲(chǔ)架構(gòu)，由此可以借助強(qiáng)大的橫向擴(kuò)展能力，只要以增加服務(wù)器的方式便可擴(kuò)展系統(tǒng)總存儲(chǔ)容量和系統(tǒng)總性能。
     Lustre文件系統(tǒng)主要由元數(shù)據(jù)服務(wù)器MDS（Metadata Server）、對(duì)象存儲(chǔ)服務(wù)器OSS（Object Storage Server）、客戶端（Lustre Client）三部分組成。MDS用于存儲(chǔ)數(shù)據(jù)描述信息，管理命名空間和目標(biāo)存儲(chǔ)地址；OSS進(jìn)行實(shí)際的數(shù)據(jù)存儲(chǔ)，提供文件I/O服務(wù)；Lustre Client則運(yùn)行Lustre文件系統(tǒng),并作為集群計(jì)算端與MDS和OSS進(jìn)行信息交互[2]。如圖1所示。

     由于Lustre設(shè)計(jì)的初衷是要提高數(shù)據(jù)訪問(wèn)的并行性和擴(kuò)展聚合I/O帶寬，所以在設(shè)計(jì)過(guò)程中廣泛采用了元數(shù)據(jù)與數(shù)據(jù)分離、數(shù)據(jù)分片策略、數(shù)據(jù)緩存和LNET網(wǎng)絡(luò)等技術(shù)。而在這些設(shè)計(jì)中，數(shù)據(jù)分片設(shè)計(jì)和后端改進(jìn)的EXT3文件系統(tǒng)非常適合大數(shù)據(jù)連續(xù)I/O訪問(wèn)，所以Lustre在大數(shù)據(jù)應(yīng)用中其性能表現(xiàn)得非常好。但對(duì)于不連續(xù)小數(shù)據(jù)I/O而言，由于Lustre在讀寫(xiě)文件前需要與MDS進(jìn)行交互,以獲得相關(guān)的屬性和對(duì)象位置信息，從而增加了一次額外的網(wǎng)絡(luò)傳輸和元數(shù)據(jù)訪問(wèn)的開(kāi)銷（與傳統(tǒng)本地文件系統(tǒng)相比）。若有大量頻繁的小數(shù)據(jù)讀寫(xiě)時(shí)，Lustre客戶端上Cache的作用將失效，其命中率也會(huì)大大降低。如果數(shù)據(jù)小于物理頁(yè)大小，則還會(huì)產(chǎn)生額外的網(wǎng)絡(luò)通信量，小數(shù)據(jù)訪問(wèn)越頻繁，則網(wǎng)絡(luò)開(kāi)銷也就越大，進(jìn)而影響Lustrer的總體I/O性能。OST（對(duì)象存儲(chǔ)目標(biāo)服務(wù)器）后端雖然采用了改進(jìn)的EXT3文件系統(tǒng)，但它對(duì)小數(shù)據(jù)的讀寫(xiě)性能存在先天的缺陷，其元數(shù)據(jù)訪問(wèn)效率也不高，且磁盤(pán)尋址延遲和磁盤(pán)碎片問(wèn)題嚴(yán)重。所以，Lustre的設(shè)計(jì)決定了它對(duì)小數(shù)據(jù)I/O的表現(xiàn)，其實(shí)際I/O帶寬遠(yuǎn)低于所提供的最大帶寬。
    因此Lustre集群及其并行架構(gòu)非常適合眾多客戶端并發(fā)進(jìn)行大數(shù)據(jù)讀寫(xiě)的場(chǎng)合，但對(duì)于不連續(xù)小數(shù)據(jù)的應(yīng)用是不適合的,尤其是海量小文件應(yīng)用LOSF（Lots Of Small Files）。
2 MPI-IO對(duì)并行I/O的實(shí)現(xiàn)
    MPI-IO是一個(gè)并行I/O庫(kù),作為 MPI-2 規(guī)范的一部分，提供了執(zhí)行可移植的、用戶級(jí)的I/O 操作接口。MPI可以通過(guò)該接口在文件和進(jìn)程間傳送數(shù)據(jù),如圖2所示。ROMIO是MPI-IO的一個(gè)具體實(shí)現(xiàn),而ADIO是位于并行文件系統(tǒng)和上層I/O庫(kù)ROMIO之間的軟件層，它的作用是使得上層并行I/O庫(kù)的實(shí)現(xiàn)具有更好的移植性和更好的I/O訪問(wèn)效率。由于ADIO可以在不同的并行文件系統(tǒng)上實(shí)現(xiàn)，提供了一組最基本的并行I/O訪問(wèn)的函數(shù)，所以I/O庫(kù)只需要在ADIO上實(shí)現(xiàn)一次，就可以通過(guò)ADIO實(shí)現(xiàn)對(duì)所有底層文件系統(tǒng)的訪問(wèn)。一些特定的并行文件系統(tǒng)的優(yōu)化通常也在ADIO層上實(shí)現(xiàn)，所以ADIO的實(shí)現(xiàn)使得上層庫(kù)可以透明訪問(wèn)底層并行文件系統(tǒng)，而不必考慮底層并行文件系統(tǒng)方面的細(xì)節(jié)。正基于此，本文所提出的改進(jìn)策略也是在ADIO上實(shí)現(xiàn)的[3]。

    MPI-IO可分為非集中式(noncollective I/O)和集中式(collective I/O)兩種I/O操作。
    非集中式I/O操作，是MPI-IO的普通I/O操作方式。在此操作下，若每個(gè)進(jìn)程訪問(wèn)文件中存放位置不連續(xù)的小片數(shù)據(jù)時(shí)，往往是對(duì)每一個(gè)小片連續(xù)的數(shù)據(jù)使用單個(gè)獨(dú)立函數(shù)來(lái)讀寫(xiě)數(shù)據(jù)，就像在Unix或Linux中一樣，所以這種方法I/O延遲較大，系統(tǒng)開(kāi)銷也較大。但對(duì)于連續(xù)大數(shù)據(jù)的讀寫(xiě)，此種方式可以利用操作系統(tǒng)緩存和Lustre數(shù)據(jù)分片等技術(shù),充分發(fā)揮并行I/O的優(yōu)勢(shì)。
    而對(duì)于集中式I/O操作,由于集中式I/O具有并行程序的對(duì)稱性，當(dāng)I/O發(fā)生時(shí)集群中所有節(jié)點(diǎn)均運(yùn)行到各自子進(jìn)程的相同位置，所以各子進(jìn)程會(huì)在一個(gè)很短的時(shí)間間隔內(nèi)各自發(fā)出I/O 請(qǐng)求，集中式I/O便合并這些小的讀寫(xiě)請(qǐng)求，使之整合成為大的讀寫(xiě)請(qǐng)求，從而減少磁盤(pán)磁頭移動(dòng)和I/O次數(shù)，提高I/O讀寫(xiě)速度。本文的改進(jìn)型編程接口也正是基于此類I/O方式將多個(gè)不連續(xù)的小數(shù)據(jù)I/O整合為少量的大數(shù)據(jù)I/O，進(jìn)而再利用底層的Lustre并行文件系統(tǒng)對(duì)大數(shù)據(jù)I/O的優(yōu)勢(shì)，使得集群的整體并行效率得到提升。集中式I/O有很多實(shí)現(xiàn)方案，ROMIO是采用基于Client-level的兩階段法來(lái)實(shí)現(xiàn)集中式I/O的。
    兩階段法通過(guò)分析集中式I/O請(qǐng)求對(duì)數(shù)據(jù)的總體需求，將一次I/O操作分成兩個(gè)階段來(lái)完成。第一個(gè)階段是所有計(jì)算進(jìn)程交換彼此I/O信息，確定每個(gè)進(jìn)程的文件域，從磁盤(pán)上讀取相應(yīng)I/O數(shù)據(jù)；第二個(gè)階段是按照應(yīng)用需求將緩沖區(qū)的數(shù)據(jù)交換分配到各進(jìn)程的用戶緩沖區(qū)，寫(xiě)操作與讀操作類似。在這兩個(gè)階段中，進(jìn)程之間需要進(jìn)行相互通信，同步同一通信域中的相關(guān)進(jìn)程的數(shù)據(jù)信息，從而得到程序總體的I/O行為信息，以便整合各個(gè)進(jìn)程獨(dú)立的I/O請(qǐng)求。如圖3所示。

       第一階段：
       (1) 確定參加讀操作的通信域中所有進(jìn)程，并進(jìn)行同步；
       (2) 確定每個(gè)進(jìn)程各自需要讀取的一個(gè)包含所請(qǐng)求數(shù)據(jù)的連續(xù)的文件區(qū)域；
       (3) 每個(gè)進(jìn)程根據(jù)自己的文件區(qū)域進(jìn)行I/O訪問(wèn)，并將這些數(shù)據(jù)存放在一個(gè)臨時(shí)緩沖中，同步所有進(jìn)程到每個(gè)進(jìn)程的I/O操作結(jié)束。
      第二階段：
      (1) 進(jìn)行I/O數(shù)據(jù)的置換，將緩存中數(shù)據(jù)發(fā)送給目標(biāo)進(jìn)程；
      (2) 同步所有進(jìn)程到數(shù)據(jù)置換結(jié)束。
    寫(xiě)操作類似于讀操作。兩階段I/O整合了多個(gè)進(jìn)程所請(qǐng)求的數(shù)據(jù)范圍，訪問(wèn)到稠密的數(shù)據(jù)區(qū)域的可能性比較大，因此對(duì)于非連續(xù)數(shù)據(jù)分布比較分散情況，該算法有明顯的性能優(yōu)勢(shì)。但是，兩階段I/O的性能很大程度上依賴于MPI所提供的高效的數(shù)據(jù)傳遞機(jī)制，即消息傳遞機(jī)制。如果MPI無(wú)法提供比底層文件的聚合帶寬更快的速度，那么在兩階段I/O中數(shù)據(jù)傳遞所帶來(lái)的額外開(kāi)銷將會(huì)大大降低該I/O方式的性能[4]。
3 改進(jìn)的并行I/O編程接口
    從上述分析可知，MPI-IO在整個(gè)集群系統(tǒng)中起到了承上啟下的作用，向上連接MPI計(jì)算系統(tǒng)，向下連接Lustre并行文件系統(tǒng)，所以其效率的高低一直影響到集群的整體并行I/O效率。為此，本文所提方案需要對(duì)以下三個(gè)方面進(jìn)行改進(jìn)。
    (1) 如何界定數(shù)據(jù)塊的大小
    在Linux 32 bit的操作系統(tǒng)中,一個(gè)頁(yè)面大小為4 KB，同時(shí)也是Lustre網(wǎng)絡(luò)傳輸?shù)幕締挝?。由參考文獻(xiàn)[4]可知，當(dāng)數(shù)據(jù)大小不到一頁(yè)或不同進(jìn)程同時(shí)讀寫(xiě)一個(gè)頁(yè)面中數(shù)據(jù)的時(shí)候，Lustre的I/O性能最差，甚至不如傳統(tǒng)的本地文件系統(tǒng)；若數(shù)據(jù)塊的大小不足一個(gè)條塊(數(shù)據(jù)分片)，則客戶端每次讀寫(xiě)只與一個(gè)OST交互信息，沒(méi)有從真正意義上實(shí)現(xiàn)Lustre并發(fā)I/O的功能。
    所以如何界定數(shù)據(jù)塊的大小，是提高系統(tǒng)并行效率的關(guān)鍵。本文依據(jù)參考文獻(xiàn)[4]所提供的實(shí)驗(yàn)數(shù)據(jù)，設(shè)定Lustre條塊大小為64 KB，若數(shù)據(jù)塊小于該值，則視為小數(shù)據(jù)，按本文改進(jìn)的集中式MPI-IO編程接口操作；若數(shù)據(jù)塊大于該值，則視為大數(shù)據(jù)，按非集中式MPI-IO接口操作。
    (2) 采用直接I/O模式以減少內(nèi)核消耗
    Lustre文件系統(tǒng)底層采用Portals協(xié)議進(jìn)行數(shù)據(jù)傳輸，上層則連接Linux操作系統(tǒng)的VFS（虛擬文件系統(tǒng)）。應(yīng)用程序所有的I/O操作都必須通過(guò)Linux的VFS才能進(jìn)入Lustre。在Linux操作系統(tǒng)中，讀寫(xiě)模式分為文件緩存（Cache）模式和直接（Direct）模式。
    對(duì)于Lustre文件系統(tǒng)而言，由于該文件系統(tǒng)是以頁(yè)面為I/O的基本單位，所以當(dāng)n個(gè)進(jìn)程去讀取僅需一個(gè)頁(yè)面的數(shù)據(jù)流量時(shí)，若采用緩存機(jī)制，則實(shí)際系統(tǒng)需要n個(gè)頁(yè)面的I/O流量才可完成，而隨著I/O請(qǐng)求的增加，這種額外的開(kāi)銷將會(huì)越來(lái)越大；而對(duì)于寫(xiě)操作，緩存機(jī)制在小數(shù)據(jù)I/O的問(wèn)題則更加突出。在寫(xiě)操作時(shí)，由于每個(gè)進(jìn)程必須獲得該頁(yè)面上的文件鎖才能進(jìn)行，以保證對(duì)這個(gè)文件寫(xiě)操作的獨(dú)占性。但是當(dāng)一個(gè)進(jìn)程獲得鎖后，其他進(jìn)程只有等待該進(jìn)程結(jié)束操作，所以對(duì)于同一個(gè)頁(yè)面的寫(xiě)操作是串行的，系統(tǒng)不能發(fā)揮程序的并行作用而造成性能下降。并且，當(dāng)數(shù)據(jù)塊小于4 KB時(shí)（不足一個(gè)頁(yè)面），文件緩存的作用已經(jīng)不明顯，反而使得I/O調(diào)用的開(kāi)銷越來(lái)越突出。因此， Lustre在非連續(xù)小數(shù)據(jù)I/O時(shí)，采用可以繞過(guò)系統(tǒng)緩存的直接I/O方式，直接將文件數(shù)據(jù)傳遞到進(jìn)程的內(nèi)存空間則是一個(gè)可行的辦法。
    (3) 減少集中式I/O第一階段的通信量
    由前述可知，MPI-IO中的集中式I/O操作是采用兩階段法來(lái)進(jìn)行的。該算法第一階段，通信域中所有進(jìn)程同步操作方式采用廣播的形式，即每個(gè)進(jìn)程的數(shù)據(jù)信息通過(guò)廣播的方式發(fā)送給通信域里的所有進(jìn)程。也就是說(shuō)，若有n個(gè)進(jìn)程參與此次集中I/O操作，則整個(gè)過(guò)程中進(jìn)程間需要n×(n-1)次點(diǎn)對(duì)點(diǎn)通信才能完成。這樣，隨著集群節(jié)點(diǎn)數(shù)的增加， 進(jìn)程間的通信次數(shù)勢(shì)必會(huì)給I/O性能造成較大影響。所以，本文的優(yōu)化方案就是以減少進(jìn)程間的通信量為目的，盡量減少進(jìn)程間的通信次數(shù)，以提高整體的I/O性能。這里，選取通信域中的一個(gè)進(jìn)程作為主進(jìn)程，通過(guò)它從其他進(jìn)程收集各自的I/O信息進(jìn)行相關(guān)的計(jì)算，并匯總整合本通信域中的所有I/O信息，再將其進(jìn)行廣播，以達(dá)到進(jìn)程間I/O信息同步的目的。若還是n個(gè)進(jìn)程參與此次集中式I/O操作，則進(jìn)程間的點(diǎn)到點(diǎn)通信次數(shù)將會(huì)降到2×(n-1)次。顯然，改進(jìn)后的策略可以明顯降低進(jìn)程之間的通信次數(shù)，進(jìn)而提高了整個(gè)集中操作的I/O性能。
4 實(shí)驗(yàn)與分析
    為驗(yàn)證改進(jìn)方案的可行性，在傳統(tǒng)的MPI集群上做了相應(yīng)的測(cè)試。測(cè)試環(huán)境為7個(gè)節(jié)點(diǎn)的集群系統(tǒng)（3臺(tái)OST，3臺(tái)客戶端，1臺(tái)MDS），每個(gè)節(jié)點(diǎn)包含一顆PIV處理器和2 GB內(nèi)存，40 GB的硬盤(pán)，操作系統(tǒng)采用Redhat Linux Enterprise 5（內(nèi)核為2.6.18），并行集群軟件為MPICH2.1，并行文件系統(tǒng)為L(zhǎng)ustre 1.0.2。在測(cè)試程序中，在3個(gè)客戶端上同時(shí)運(yùn)行3個(gè)進(jìn)程讀寫(xiě)一個(gè)文件的不同部分，測(cè)試文件為2 GB，其他的什么都不做，來(lái)測(cè)試改進(jìn)前后的I/O 讀寫(xiě)帶寬（改進(jìn)前的讀寫(xiě)方式為L(zhǎng)ustre系統(tǒng)的普通讀寫(xiě)方式）。
    如圖4所示,先分析改進(jìn)前Lustre系統(tǒng)的讀寫(xiě)情況：數(shù)據(jù)塊為64 KB時(shí)，由于大部分RPC數(shù)據(jù)包中都包含了數(shù)十個(gè)頁(yè)，從而減少了I/O調(diào)用的次數(shù)，效率達(dá)到最高；而當(dāng)數(shù)據(jù)塊小于64 KB（一個(gè)分片的大?。r(shí)，此時(shí)客戶端每次讀寫(xiě)只能與一個(gè)OST交互信息，從而無(wú)法使用Lustre分片技術(shù)的并發(fā)功能，造成這一階段讀寫(xiě)性能不佳；而當(dāng)數(shù)據(jù)塊大小為4 KB或者小于4 KB時(shí)，性能則快速下降，特別是寫(xiě)操作，性能下降得更為嚴(yán)重，這主要是因?yàn)閿?shù)據(jù)塊的大小不足1個(gè)頁(yè)面（4 KB），此時(shí)大部分的RPC數(shù)據(jù)包僅僅包含1個(gè)頁(yè)面而導(dǎo)致I/O效率不高，特別是在不同進(jìn)程同時(shí)讀寫(xiě)一個(gè)頁(yè)面中的數(shù)據(jù)的時(shí)候，則性能更糟。

    由于改進(jìn)后的方案采用了MPI-IO中的改進(jìn)集中式操作和直接I/O技術(shù)，使得數(shù)據(jù)塊在64 KB以下區(qū)段性能差異較大。但對(duì)于數(shù)據(jù)塊大于64 KB時(shí),改進(jìn)前后的差異不大，這是因?yàn)楦倪M(jìn)后的編程接口將大于64 KB的數(shù)據(jù)包均視為大數(shù)據(jù)，不做修改，所以與改進(jìn)前基本一致；對(duì)于數(shù)據(jù)包小于64 KB時(shí)，改進(jìn)后的讀寫(xiě)明顯放緩了I/O讀寫(xiě)下降的速度，且讀操作和寫(xiě)操作的速度基本持平，這主要是因?yàn)楦倪M(jìn)后的方案中使用了MPI-IO中的改進(jìn)集中式操作，由于MPI-IO中可以使用單個(gè)函數(shù)來(lái)訪問(wèn)非連續(xù)數(shù)據(jù)，且可多次使用，同時(shí)MPI-IO也允許一組進(jìn)程在同一時(shí)間訪問(wèn)一個(gè)普通文件，在進(jìn)行多次讀寫(xiě)時(shí)，I/O的訪問(wèn)開(kāi)銷不但可以降低，而且還可將定義開(kāi)銷分?jǐn)偟礁鞔卧L問(wèn)， 從而改善了小數(shù)據(jù)I/O操作的性能。
    總之，基于Lustre的MPI-IO編程接口的改進(jìn)方案是可行的。在該機(jī)制下構(gòu)建的MPI集群系統(tǒng)能夠有效解決I/O瓶頸，提升并行計(jì)算速度，與傳統(tǒng)的MPI集群相比性能提高空間很大。但是由于研究剛剛起步，還需要在總結(jié)現(xiàn)有不足的基礎(chǔ)上，繼續(xù)實(shí)踐、改進(jìn)和完善。
參考文獻(xiàn)
[1] 錢迎進(jìn),金士堯,肖儂. Lustre文件系統(tǒng)I/O鎖的應(yīng)用與優(yōu)化[J]. 計(jì)算機(jī)工程與應(yīng)用, 2011,47(03):1-5.
[2] BRAAM P J. Lustre: A scable, high-performance file  systme[M]. Lustre Whitepaper Version 1.0, 2002.
[3] 劉輝, 胡靜, 王振飛，等.MPI-2中的并行I/O的使用分析[J].計(jì)算機(jī)工程, 2003,29(2):229-232.
[4] 林松濤. 基于Lustre文件系統(tǒng)的并行I/O技術(shù)研究[D].國(guó)防科學(xué)技術(shù)大學(xué), 2004.