突破I/O瓶頸 五種解決方案各有利弊

HPC(高性能計(jì)算High Performance Computing，也稱超級(jí)計(jì)算)歷來是石油、生物、氣象、科研等計(jì)算密集型應(yīng)用中的首要技術(shù)問題。早期的HPC系統(tǒng)，主要以IBM、Cray、SGI等廠商的大型機(jī)或并行機(jī)為硬件系統(tǒng)平臺(tái)。隨著Linux并行集群技術(shù)的成熟和普及，目前HPC技術(shù)主流已經(jīng)轉(zhuǎn)向以IA架構(gòu)為硬件平臺(tái)，以Linux并行集群為系統(tǒng)平臺(tái)的廉價(jià)系統(tǒng)為主。近年來，這一技術(shù)又進(jìn)一步發(fā)展，各廠商目前競(jìng)相追捧的網(wǎng)格計(jì)算技術(shù)，從某種意義上說，就是這一架構(gòu)的延伸。鑒于Linux并行集群技術(shù)在HPC應(yīng)用中的主流地位及快速發(fā)展趨勢(shì)，本文主要討論的也是這一架構(gòu)中的存儲(chǔ)系統(tǒng)問題。

當(dāng)前Linux并行集群的困惑----遭遇I/O瓶頸

　　Linux并行集群中的計(jì)算資源按其功能角色不同，通常被分為兩種：“計(jì)算節(jié)點(diǎn)”和“I/O節(jié)點(diǎn)”。其中計(jì)算節(jié)點(diǎn)負(fù)責(zé)運(yùn)行計(jì)算任務(wù)，I/O節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)并響應(yīng)計(jì)算節(jié)點(diǎn)的存儲(chǔ)請(qǐng)求。目前Linux并行集群一般采用單I/O節(jié)點(diǎn)服務(wù)多計(jì)算節(jié)點(diǎn)的模式。從硬件角度看，I/O節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)都是標(biāo)準(zhǔn)的IA架構(gòu)，沒有本質(zhì)區(qū)別。計(jì)算所需要的初始數(shù)據(jù)、計(jì)算得出的最終數(shù)據(jù)以及并行計(jì)算平臺(tái)本身，都存儲(chǔ)于I/O節(jié)點(diǎn)上。計(jì)算節(jié)點(diǎn)與I/O節(jié)點(diǎn)間一般采用標(biāo)準(zhǔn)NFS協(xié)議交換數(shù)據(jù)。

　　當(dāng)一個(gè)計(jì)算任務(wù)被加載到集群系統(tǒng)時(shí)，各個(gè)計(jì)算節(jié)點(diǎn)首先從I/O節(jié)點(diǎn)獲取數(shù)據(jù)，然后進(jìn)行計(jì)算，最后再將計(jì)算結(jié)果寫入I/O節(jié)點(diǎn)。在這個(gè)過程中，計(jì)算的開始階段和結(jié)束階段I/O節(jié)點(diǎn)的負(fù)載非常大，而在計(jì)算處理過程中，卻幾乎沒有任何負(fù)載。

　　提高各計(jì)算節(jié)點(diǎn)CPU頻率和增加計(jì)算節(jié)點(diǎn)數(shù)量，可以提高集群整體的計(jì)算處理能力，進(jìn)一步縮短處理階段的時(shí)間。在當(dāng)前的Linux并行集群系統(tǒng)中，集群系統(tǒng)的處理能力越來越強(qiáng)，每秒運(yùn)算次數(shù)在迅速增長，于是集群系統(tǒng)真正用于計(jì)算處理的時(shí)間越來越短。然而，由于I/O能力改進(jìn)不大，集群系統(tǒng)工作中的I/O效率沒有明顯進(jìn)步，甚至?xí)S著計(jì)算節(jié)點(diǎn)數(shù)的增加而明顯降低。

實(shí)際監(jiān)測(cè)結(jié)果顯示，當(dāng)原始數(shù)據(jù)量較大時(shí)，開始階段和結(jié)束階段所占用的整體時(shí)間已經(jīng)相當(dāng)可觀，在有些系統(tǒng)中甚至可以占到50%左右。I/O效率的改進(jìn)，已經(jīng)成為今天大多數(shù)Linux并行集群系統(tǒng)提高效率的首要任務(wù)。

　　解決I/O瓶頸的初步探討----瓶頸到底在哪里?

　　在上面的系統(tǒng)結(jié)構(gòu)圖中可以看出，如果把“以太網(wǎng)交換”以下的部分統(tǒng)統(tǒng)看作存儲(chǔ)系統(tǒng)的話，那么可能的瓶頸無外乎以下三種：

存儲(chǔ)設(shè)備本身性能，姑且稱之為“存儲(chǔ)設(shè)備瓶頸”

　　I/O節(jié)點(diǎn)與存儲(chǔ)設(shè)備間的連接，姑且稱之為“存儲(chǔ)通道瓶頸”

　　計(jì)算節(jié)點(diǎn)與I/O節(jié)點(diǎn)間的網(wǎng)絡(luò)交換，姑且稱之為“網(wǎng)絡(luò)交換瓶頸”

　　究竟哪一環(huán)節(jié)是最為關(guān)鍵的問題呢?讓我們結(jié)合實(shí)際情況，逐一的分析一下。

　　目前的存儲(chǔ)設(shè)備類型豐富，種類繁多。僅中端設(shè)備中，容量擴(kuò)展能力在幾十TB，每秒處理數(shù)萬次I/O，數(shù)據(jù)吞吐帶寬在數(shù)百M(fèi)B/s的設(shè)備就有很多種選擇。以勘探數(shù)據(jù)處理系統(tǒng)為例，在一個(gè)32計(jì)算節(jié)點(diǎn)的疊前處理系統(tǒng)中，如果需要使每個(gè)計(jì)算節(jié)點(diǎn)得到15～20MB/s的帶寬，那么集群對(duì)后端存儲(chǔ)的總體帶寬(即聚合帶寬)要求大約為500～650MB/s。目前的中端磁盤陣列產(chǎn)品基本都可以達(dá)到這一性能指標(biāo)。如果考慮64個(gè)或更多計(jì)算節(jié)點(diǎn)，后端帶寬要求需要達(dá)到1～1.3GB/s甚至更大，這一性能是目前單一中端磁盤陣列系統(tǒng)難以達(dá)到的。然而通過引入多臺(tái)存儲(chǔ)設(shè)備，這一問題也不難解決。

　　目前的存儲(chǔ)設(shè)備通道技術(shù)主要以SCSI和FC為主。目前單條FC通道可保證200MB/s的傳輸帶寬，以4條通道并行工作就可以達(dá)到800MB/s的帶寬保證。這一指數(shù)已經(jīng)完全可以滿足32個(gè)計(jì)算節(jié)點(diǎn)并行工作的帶寬要求。此外IB(InfiniBand)技術(shù)作為新興通道技術(shù)，更進(jìn)一步保證了通道帶寬。目前已經(jīng)產(chǎn)品化的IB交換技術(shù)已經(jīng)可以達(dá)到10~30Gb/s的帶寬，是目前FC技術(shù)的5～15倍。在這樣的帶寬保證下，既便是256或512節(jié)點(diǎn)的集群也可以與存儲(chǔ)設(shè)備從容交換數(shù)據(jù)。 #p#page_title#e#

這樣看來，“存儲(chǔ)設(shè)備瓶頸”和“存儲(chǔ)通道瓶頸”似乎都不是難以解決的問題，那么“網(wǎng)絡(luò)交換瓶頸”的情況又如何呢?

　　照搬前面的計(jì)算方法，如果要為前端32個(gè)計(jì)算節(jié)點(diǎn)提供15～20MB/s的帶寬，I/O節(jié)點(diǎn)需要提供至少500～650MB/s的網(wǎng)絡(luò)帶寬。這就是說，既便完全不考慮以太網(wǎng)交換的額外損耗，也需要安裝6～7片千兆以太網(wǎng)卡。而一般的PC或PC服務(wù)器最多只有兩個(gè)PCI控制器，要想保證這6～7片千兆以太網(wǎng)卡都以最高效率工作，完全是不可能的。更何況一般以太網(wǎng)的效率，只有理論帶寬的50%左右。就是說實(shí)際上要想達(dá)到500～650MB/s的實(shí)際帶寬，需要13～15片千兆以太網(wǎng)卡，十幾個(gè)64位PCI插槽!這大概是目前最高端的PC服務(wù)器所能提供的PCI插槽數(shù)目的二倍。

　　照此看來，單一I/O節(jié)點(diǎn)架構(gòu)無疑是整個(gè)集群系統(tǒng)性能死結(jié)。那么考慮多I/O節(jié)點(diǎn)的架構(gòu)會(huì)如何呢?筆者的觀點(diǎn)是：多I/O節(jié)點(diǎn)架構(gòu)困難重重，但勢(shì)在必行。

　　解決I/O瓶頸的途徑----多I/O節(jié)點(diǎn)架構(gòu)

　　引入多I/O節(jié)點(diǎn)架構(gòu)，涉及到很多存儲(chǔ)技術(shù)。筆者下面的分析中，主要考慮了FC-SAN，iSCSI-SAN，基于SAN的文件共享以及PVFS(并行虛擬文件系統(tǒng))等技術(shù)手段。

　　方案一、簡(jiǎn)單SAN架構(gòu)下的多I/O節(jié)點(diǎn)模式

　　實(shí)現(xiàn)多I/O節(jié)點(diǎn)，最容易想到的第一步就是引入SAN架構(gòu)。那么，我們就先來分析一下簡(jiǎn)單的SAN架構(gòu)能否滿足Linux并行集群的需求。

　　由于基本的SAN架構(gòu)不能提供文件級(jí)共享，兩個(gè)I/O節(jié)點(diǎn)還是完全獨(dú)立的工作。前端的所有計(jì)算節(jié)點(diǎn)如果同時(shí)讀取同一個(gè)文件的話，還必須經(jīng)由一個(gè)I/O節(jié)點(diǎn)完成。由此可見，在單一任務(wù)情況下，多I/O節(jié)點(diǎn)的結(jié)構(gòu)形同虛設(shè)，根本無法負(fù)載均衡的為前端計(jì)算節(jié)點(diǎn)提供服務(wù)響應(yīng)。為了解決這一問題?？梢钥紤]在多I/O節(jié)點(diǎn)間需要引入文件級(jí)共享的工作機(jī)制。

方案二、多I/O節(jié)點(diǎn)間文件級(jí)共享

　　在引入文件共享技術(shù)的SAN架構(gòu)下，各個(gè)I/O節(jié)點(diǎn)可以同時(shí)讀取同一文件。這為I/O節(jié)點(diǎn)間的負(fù)載均衡提供了可能。然而SAN架構(gòu)下的文件共享并沒有解決所有問題，其實(shí)這一技術(shù)僅僅是為解決問題提供了底層的支持而已。

　　從圖中可以看到，所有計(jì)算節(jié)點(diǎn)被人為劃分成兩部分，每個(gè)I/O節(jié)點(diǎn)為其中一個(gè)部分提供I/O服務(wù)響應(yīng)。也就是說，在計(jì)算節(jié)點(diǎn)的層面上，系統(tǒng)是手工負(fù)載均衡，而非自動(dòng)負(fù)載均衡。在大多數(shù)實(shí)際應(yīng)用環(huán)境中，手工負(fù)載均衡意味著繁重的管理工作任務(wù)。每當(dāng)增加新的計(jì)算任務(wù)或者調(diào)整參與計(jì)算的CPU數(shù)量時(shí)，幾乎所有的NFS共享卷綁定關(guān)系必須重新配置。而當(dāng)多個(gè)作業(yè)同時(shí)運(yùn)行，尤其是每個(gè)作業(yè)要求的CPU資源還不盡相同時(shí)，配置合理的綁定關(guān)系將是系統(tǒng)管理人員的一場(chǎng)噩夢(mèng)。

　　造成這一問題的根本原因在于，多I/O節(jié)點(diǎn)為系統(tǒng)引入了多個(gè)邏輯數(shù)據(jù)源，而目前主流并行集群系統(tǒng)都是在單一數(shù)據(jù)源的結(jié)構(gòu)下開發(fā)的。既然現(xiàn)有應(yīng)用不能在短時(shí)期內(nèi)有所改變，能否在提高前端計(jì)算節(jié)點(diǎn)I/O能力的同時(shí)，回歸到單一邏輯數(shù)據(jù)源的結(jié)構(gòu)呢?其實(shí)，以目前的技術(shù)而言，答案是肯定的。

　　方案三、單I/O節(jié)點(diǎn)蛻化為MDC，計(jì)算節(jié)點(diǎn)直接接入SAN

　　目前SAN架構(gòu)下文件共享的技術(shù)已經(jīng)較為成熟，如果將全部計(jì)算節(jié)點(diǎn)都接入SAN，而將I/O節(jié)點(diǎn)設(shè)置為MDC(Meta Data Controller)，就可以在提高系統(tǒng)I/O能力的同時(shí)，形式上保留原有的單一I/O節(jié)點(diǎn)，單一數(shù)據(jù)源的邏輯結(jié)構(gòu)。

　　在這一架構(gòu)下，各個(gè)計(jì)算節(jié)點(diǎn)形式上還是通過NFS共享訪問I/O節(jié)點(diǎn)，但實(shí)際的數(shù)據(jù)讀寫路徑則通過SAN交換直接到達(dá)磁盤陣列。這種模式的可行性已經(jīng)在現(xiàn)實(shí)中被證實(shí)。例如，IBM公司的GPFS技術(shù)就是以這種方式解決集群的I/O瓶頸問題的。

這一架構(gòu)從技術(shù)上看似乎是無懈可擊的。它真的一舉解決了所有問題的問題嗎?非也!當(dāng)考慮到成本的時(shí)候，問題就出現(xiàn)了。即使按照最保守的32個(gè)節(jié)點(diǎn)計(jì)算，在不考慮容錯(cuò)的前提下，整個(gè)SAN系統(tǒng)需要至少提供32個(gè)端口用于連接主機(jī)，另外還至少需要4個(gè)端口連接磁盤陣列。要建立如此龐大的SAN網(wǎng)絡(luò)，其成本將相當(dāng)可觀，這也就失去了Linux并行集群的最大優(yōu)勢(shì)----性能價(jià)格比。 #p#page_title#e#

　　FC-SAN的成本昂貴，能否考慮替代技術(shù)呢?那么不妨考慮以相對(duì)成本較低的iSCSI技術(shù)替代FC的解決方案。

　　方案四、以iSCSI技術(shù)取代FC

　　以iSCSI替代FC技術(shù)構(gòu)建SAN網(wǎng)絡(luò)的確可以降低一定的成本。按32節(jié)點(diǎn)的例子計(jì)算，不考慮磁盤陣列部分，F(xiàn)C-SAN的硬件成本約為每端口$2000以上，采用iSCSI技術(shù)可以將這個(gè)數(shù)字降低到$1000以內(nèi)。性能雖然受到一定影響，但仍會(huì)比目前的狀況好很多。

　　然而，iSCSI技術(shù)的引入只能降低硬件產(chǎn)品，而對(duì)軟件成本則沒有任何影響。SAN架構(gòu)文件共享軟件的一般價(jià)格是每節(jié)點(diǎn)$5000~$7000，當(dāng)硬件成本降低后，這部分軟件成本占了SAN成本的大部分，存儲(chǔ)系統(tǒng)的總體成本仍然明顯高于計(jì)算節(jié)點(diǎn)的總和。

　　如此看來，無論采用哪種連接技術(shù)，只要試圖將所有節(jié)點(diǎn)直接連接存儲(chǔ)設(shè)備，共享軟件的成本都是一個(gè)無法逾越的障礙，目前只能在其他方向上尋找解決辦法。

　　方案五、多I/O節(jié)點(diǎn)間以PVFS實(shí)現(xiàn)負(fù)載均衡

　　讓我們重新回到多I/O節(jié)點(diǎn)的架構(gòu)下，來嘗試解決多邏輯數(shù)據(jù)源帶來的問題。并行文件系統(tǒng)(PVFS)似乎是個(gè)不錯(cuò)的選擇。

　　從圖中可以看到，以PVFS替代傳統(tǒng)的NFS共享之后，多I/O節(jié)點(diǎn)被虛擬為一個(gè)單一數(shù)據(jù)源。各個(gè)前端計(jì)算節(jié)點(diǎn)可以面對(duì)這個(gè)單一的數(shù)據(jù)源進(jìn)行讀寫操作，省去了復(fù)雜的管理。而PVFS架構(gòu)中的管理服務(wù)器，將前端的所有I/O請(qǐng)求均衡負(fù)載到各個(gè)I/O節(jié)點(diǎn)，從而實(shí)現(xiàn)了系統(tǒng)I/O的自動(dòng)負(fù)載均衡。

　　需要說明的是，PVFS本身有兩個(gè)重要版本。其中PVFS1存在嚴(yán)重的單點(diǎn)故障問題，一旦管理服務(wù)器宕機(jī)，則整個(gè)系統(tǒng)都無法正常工作。PVFS2中針對(duì)這個(gè)隱患做了比較大的修正，不再單獨(dú)設(shè)立管理服務(wù)器，而是各個(gè)運(yùn)行IOD進(jìn)程的節(jié)點(diǎn)都可以接管該功能，以此來改善系統(tǒng)的單點(diǎn)故障問題。

　　以PVFS構(gòu)建的系統(tǒng)甚至不再需要SAN系統(tǒng)內(nèi)文件共享，因?yàn)槊總€(gè)原始數(shù)據(jù)文件在I/O節(jié)點(diǎn)一級(jí)就被分割為一組小數(shù)據(jù)塊，分散存儲(chǔ)。

　　筆者對(duì)這一方案的顧忌在于技術(shù)的成熟度和服務(wù)保證。PVFS目前還不是由商業(yè)公司最終產(chǎn)品化的商品，而是基于GPL開放授權(quán)的一種開放技術(shù)。雖然免費(fèi)獲取該技術(shù)使整體系統(tǒng)成本進(jìn)一步降低，但由于沒有商業(yè)公司作為發(fā)布方，該技術(shù)的后續(xù)升級(jí)維護(hù)等一系列服務(wù)，都難以得到保證。

　　綜上所述，筆者認(rèn)為上述方案各有優(yōu)勢(shì)，但問題也同樣明顯。如果用戶可以接受管理維護(hù)的復(fù)雜性，那么方案二似乎最為經(jīng)濟(jì)實(shí)惠。如果用戶愿意接受基于GPL無原廠商服務(wù)支持的自由產(chǎn)品，并在短期內(nèi)不考慮對(duì)非Linux集群系統(tǒng)的整合問題，則可以采用PVFS技術(shù)，即采用方案五。方案三雖然是所有方案中性能最好的，但其高昂的成本顯然不是每一個(gè)用戶都愿意接受的。