HPC（高性能計算High Performance Computing，也稱超級計算）歷來是石油、生物、氣象、科研等計算密集型應用中的首要技術問題。早期的HPC系統(tǒng)，主要以IBM、Cray、SGI等廠商的大型機或并行機為硬件系統(tǒng)平臺。隨著Linux并行集群技術的成熟和普及，目前HPC技術主流已經(jīng)轉向以IA架構為硬件平臺，以Linux并行集群為系統(tǒng)平臺的廉價系統(tǒng)為主。近年來，這一技術又進一步發(fā)展，各廠商目前競相追捧的網(wǎng)格計算技術，從某種意義上說，就是這一架構的延伸。鑒于Linux并行集群技術在HPC應用中的主流地位及快速發(fā)展趨勢，本文主要討論的也是這一架構中的存儲系統(tǒng)問題。
當前Linux并行集群的困惑—-遭遇I/O瓶頸
Linux并行集群中的計算資源按其功能角色不同，通常被分為兩種：“計算節(jié)點”和“I/O節(jié)點”。其中計算節(jié)點負責運行計算任務，I/O節(jié)點負責數(shù)據(jù)的存儲并響應計算節(jié)點的存儲請求。目前Linux并行集群一般采用單I/O節(jié)點服務多計算節(jié)點的模式。從硬件角度看，I/O節(jié)點和計算節(jié)點都是標準的IA架構，沒有本質(zhì)區(qū)別。計算所需要的初始數(shù)據(jù)、計算得出的最終數(shù)據(jù)以及并行計算平臺本身，都存儲于I/O節(jié)點上。計算節(jié)點與I/O節(jié)點間一般采用標準NFS協(xié)議交換數(shù)據(jù)。
當一個計算任務被加載到集群系統(tǒng)時，各個計算節(jié)點首先從I/O節(jié)點獲取數(shù)據(jù)，然后進行計算，最后再將計算結果寫入I/O節(jié)點。在這個過程中，計算的開始階段和結束階段I/O節(jié)點的負載非常大，而在計算處理過程中，卻幾乎沒有任何負載。
提高各計算節(jié)點CPU頻率和增加計算節(jié)點數(shù)量，可以提高集群整體的計算處理能力，進一步縮短處理階段的時間。在當前的Linux并行集群系統(tǒng)中，集群系統(tǒng)的處理能力越來越強，每秒運算次數(shù)在迅速增長，于是集群系統(tǒng)真正用于計算處理的時間越來越短。然而，由于I/O能力改進不大，集群系統(tǒng)工作中的I/O效率沒有明顯進步，甚至會隨著計算節(jié)點數(shù)的增加而明顯降低。
實際監(jiān)測結果顯示，當原始數(shù)據(jù)量較大時，開始階段和結束階段所占用的整體時間已經(jīng)相當可觀，在有些系統(tǒng)中甚至可以占到50%左右。I/O效率的改進，已經(jīng)成為今天大多數(shù)Linux并行集群系統(tǒng)提高效率的首要任務。
解決I/O瓶頸的初步探討—-瓶頸到底在哪里？
在上面的系統(tǒng)結構圖中可以看出，如果把“以太網(wǎng)交換”以下的部分統(tǒng)統(tǒng)看作存儲系統(tǒng)的話，那么可能的瓶頸無外乎以下三種：
目前的存儲設備類型豐富，種類繁多。僅中端設備中，容量擴展能力在幾十TB，每秒處理數(shù)萬次I/O，數(shù)據(jù)吞吐帶寬在數(shù)百MB/s的設備就有很多種選擇。以勘探數(shù)據(jù)處理系統(tǒng)為例，在一個32計算節(jié)點的疊前處理系統(tǒng)中，如果需要使每個計算節(jié)點得到15～20MB/s的帶寬，那么集群對后端存儲的總體帶寬（即聚合帶寬）要求大約為500～650MB/s。目前的中端磁盤陣列產(chǎn)品基本都可以達到這一性能指標。如果考慮64個或更多計算節(jié)點，后端帶寬要求需要達到1～1.3GB/s甚至更大，這一性能是目前單一中端磁盤陣列系統(tǒng)難以達到的。然而通過引入多臺存儲設備，這一問題也不難解決。
目前的存儲設備通道技術主要以SCSI和FC為主。目前單條FC通道可保證200MB/s的傳輸帶寬，以4條通道并行工作就可以達到800MB/s的帶寬保證。這一指數(shù)已經(jīng)完全可以滿足32個計算節(jié)點并行工作的帶寬要求。此外IB（InfiniBand）技術作為新興通道技術，更進一步保證了通道帶寬。目前已經(jīng)產(chǎn)品化的IB交換技術已經(jīng)可以達到10~30Gb/s的帶寬，是目前FC技術的5～15倍。在這樣的帶寬保證下，既便是256或512節(jié)點的集群也可以與存儲設備從容交換數(shù)據(jù)。
這樣看來，“存儲設備瓶頸”和“存儲通道瓶頸”似乎都不是難以解決的問題，那么“網(wǎng)絡交換瓶頸”的情況又如何呢？
照搬前面的計算方法，如果要為前端32個計算節(jié)點提供15～20MB/s的帶寬，I/O節(jié)點需要提供至少500～650MB/s的網(wǎng)絡帶寬。這就是說，既便完全不考慮以太網(wǎng)交換的額外損耗，也需要安裝6～7片千兆以太網(wǎng)卡。而一般的PC或PC服務器最多只有兩個PCI控制器，要想保證這6～7片千兆以太網(wǎng)卡都以最高效率工作，完全是不可能的。更何況一般以太網(wǎng)的效率，只有理論帶寬的50%左右。就是說實際上要想達到500～650MB/s的實際帶寬，需要13～15片千兆以太網(wǎng)卡，十幾個64位PCI插槽！這大概是目前最高端的PC服務器所能提供的PCI插槽數(shù)目的二倍。
照此看來，單一I/O節(jié)點架構無疑是整個集群系統(tǒng)性能死結。那么考慮多I/O節(jié)點的架構會如何呢？筆者的觀點是：多I/O節(jié)點架構困難重重，但勢在必行。
解決I/O瓶頸的途徑—-多I/O節(jié)點架構
引入多I/O節(jié)點架構，涉及到很多存儲技術。筆者下面的分析中，主要考慮了FC-SAN，iSCSI-SAN，基于SAN的文件共享以及PVFS（并行虛擬文件系統(tǒng)）等技術手段。
方案一、簡單SAN架構下的多I/O節(jié)點模式
實現(xiàn)多I/O節(jié)點，最容易想到的第一步就是引入SAN架構。那么，我們就先來分析一下簡單的SAN架構能否滿足Linux并行集群的需求。以兩個I/O節(jié)點為例，下圖是多I/O節(jié)點的結構框圖：
從圖中可以看到，由于基本的SAN架構不能提供文件級共享，兩個I/O節(jié)點還是完全獨立的工作。前端的所有計算節(jié)點如果同時讀取同一個文件的話，還必須經(jīng)由一個I/O節(jié)點完成。由此可見，在單一任務情況下，多I/O節(jié)點的結構形同虛設，根本無法負載均衡的為前端計算節(jié)點提供服務響應。為了解決這一問題。可以考慮在多I/O節(jié)點間需要引入文件級共享的工作機制。
方案二、多I/O節(jié)點間文件級共享
在引入文件共享技術的SAN架構下，各個I/O節(jié)點可以同時讀取同一文件。這為I/O節(jié)點間的負載均衡提供了可能。然而SAN架構下的文件共享并沒有解決所有問題，其實這一技術僅僅是為解決問題提供了底層的支持而已。
從圖中可以看到，所有計算節(jié)點被人為劃分成兩部分，每個I/O節(jié)點為其中一個部分提供I/O服務響應。也就是說，在計算節(jié)點的層面上，系統(tǒng)是手工負載均衡，而非自動負載均衡。在大多數(shù)實際應用環(huán)境中，手工負載均衡意味著繁重的管理工作任務。每當增加新的計算任務或者調(diào)整參與計算的CPU數(shù)量時，幾乎所有的NFS共享卷綁定關系必須重新配置。而當多個作業(yè)同時運行，尤其是每個作業(yè)要求的CPU資源還不盡相同時，配置合理的綁定關系將是系統(tǒng)管理人員的一場噩夢。
造成這一問題的根本原因在于，多I/O節(jié)點為系統(tǒng)引入了多個邏輯數(shù)據(jù)源，而目前主流并行集群系統(tǒng)都是在單一數(shù)據(jù)源的結構下開發(fā)的。既然現(xiàn)有應用不能在短時期內(nèi)有所改變，能否在提高前端計算節(jié)點I/O能力的同時，回歸到單一邏輯數(shù)據(jù)源的結構呢？其實，以目前的技術而言，答案是肯定的。
方案三、單I/O節(jié)點蛻化為MDC，計算節(jié)點直接接入SAN
目前SAN架構下文件共享的技術已經(jīng)較為成熟，如果將全部計算節(jié)點都接入SAN，而將I/O節(jié)點設置為MDC（Meta Data Controller），就可以在提高系統(tǒng)I/O能力的同時，形式上保留原有的單一I/O節(jié)點，單一數(shù)據(jù)源的邏輯結構。
在這一架構下，各個計算節(jié)點形式上還是通過NFS共享訪問I/O節(jié)點，但實際的數(shù)據(jù)讀寫路徑則通過SAN交換直接到達磁盤陣列。這種模式的可行性已經(jīng)在現(xiàn)實中被證實。例如，IBM公司的GPFS技術就是以這種方式解決集群的I/O瓶頸問題的。
這一架構從技術上看似乎是無懈可擊的。它真的一舉解決了所有問題的問題嗎？非也！當考慮到成本的時候，問題就出現(xiàn)了。即使按照最保守的32個節(jié)點計算，在不考慮容錯的前提下，整個SAN系統(tǒng)需要至少提供32個端口用于連接主機，另外還至少需要4個端口連接磁盤陣列。要建立如此龐大的SAN網(wǎng)絡，其成本將相當可觀，這也就失去了Linux并行集群的最大優(yōu)勢—-性能價格比。
FC-SAN的成本昂貴，能否考慮替代技術呢？那么不妨考慮以相對成本較低的iSCSI技術替代FC的解決方案。
方案四、以iSCSI技術取代FC
以iSCSI替代FC技術構建SAN網(wǎng)絡的確可以降低一定的成本。按32節(jié)點的例子計算，不考慮磁盤陣列部分，F(xiàn)C-SAN的硬件成本約為每端口$2000以上，采用iSCSI技術可以將這個數(shù)字降低到$1000以內(nèi)。性能雖然受到一定影響，但仍會比目前的狀況好很多。
然而，iSCSI技術的引入只能降低硬件產(chǎn)品，而對軟件成本則沒有任何影響。SAN架構文件共享軟件的一般價格是每節(jié)點$5000~$7000，當硬件成本降低后，這部分軟件成本占了SAN成本的大部分，存儲系統(tǒng)的總體成本仍然明顯高于計算節(jié)點的總和。
如此看來，無論采用哪種連接技術，只要試圖將所有節(jié)點直接連接存儲設備，共享軟件的成本都是一個無法逾越的障礙，目前只能在其他方向上尋找解決辦法。
方案五、多I/O節(jié)點間以PVFS實現(xiàn)負載均衡
讓我們重新回到多I/O節(jié)點的架構下，來嘗試解決多邏輯數(shù)據(jù)源帶來的問題。并行文件系統(tǒng)（PVFS）似乎是個不錯的選擇。
從圖中可以看到，以PVFS替代傳統(tǒng)的NFS共享之后，多I/O節(jié)點被虛擬為一個單一數(shù)據(jù)源。各個前端計算節(jié)點可以面對這個單一的數(shù)據(jù)源進行讀寫操作，省去了復雜的管理。而PVFS架構中的管理服務器，將前端的所有I/O請求均衡負載到各個I/O節(jié)點，從而實現(xiàn)了系統(tǒng)I/O的自動負載均衡。
需要說明的是，PVFS本身有兩個重要版本。其中PVFS1存在嚴重的單點故障問題，一旦管理服務器宕機，則整個系統(tǒng)都無法正常工作。PVFS2中針對這個隱患做了比較大的修正，不再單獨設立管理服務器，而是各個運行IOD進程的節(jié)點都可以接管該功能，以此來改善系統(tǒng)的單點故障問題。
以PVFS構建的系統(tǒng)甚至不再需要SAN系統(tǒng)內(nèi)文件共享，因為每個原始數(shù)據(jù)文件在I/O節(jié)點一級就被分割為一組小數(shù)據(jù)塊，分散存儲。
筆者對這一方案的顧忌在于技術的成熟度和服務保證。PVFS目前還不是由商業(yè)公司最終產(chǎn)品化的商品，而是基于GPL開放授權的一種開放技術。雖然免費獲取該技術使整體系統(tǒng)成本進一步降低，但由于沒有商業(yè)公司作為發(fā)布方，該技術的后續(xù)升級維護等一系列服務，都難以得到保證。
綜上所述，筆者認為上述方案各有優(yōu)勢，但問題也同樣明顯。如果用戶可以接受管理維護的復雜性，那么方案二似乎最為經(jīng)濟實惠。如果用戶愿意接受基于GPL無原廠商服務支持的自由產(chǎn)品，并在短期內(nèi)不考慮對非Linux集群系統(tǒng)的整合問題，則可以采用PVFS技術，即采用方案五。方案三雖然是所有方案中性能最好的，但其高昂的成本顯然不是每一個用戶都愿意接受的。
訂閱《信息存儲》雜志請 點擊此處鏈接
