高效能運算和資料密集型計算的儲存需要差異分析
根據應用領域的不同,目前主流的分散式並行檔案系統可分為2類:面向高效能運算(HPC:High Performance Computing)應用的並行檔案系統,典型代表如Luster、Panasas和PVFS;面向資料密集型計算(DISC: Data Intensive Scalable Computing)的並行檔案系統,典型代表為Google FS,以及重現Google FS的開原始檔系統Hadoop HDFS等。這兩種應用領域有何不同?它們對並行檔案系統的需求有何本質差異?有無可能在並行檔案系統中兼顧兩種應用的需求?本文探討並試圖回答這些問題。
長期以來,HPC應用的主要領域是科學與工程計算,諸如高能物理、核爆炸模擬、氣象預報、石油勘探、地震預報、地球模擬、藥品研製、CAD設計中的模擬與建模、流體力學的計算等。
圖1 HPC系統結構 在過去幾十年裡,HPC系統的計算能力快速提高,系統的規模也大規模擴充套件。表1顯示了過去20年中HPC系統規模、以及計算節點和I/O節點數比例的變化趨勢【1】。可以看出HPC系統中計算節點數高達幾萬,CPU數達到數十萬,與此同時,計算節點和I/O節點的比例一直呈增加之勢。 表1 HPC系統規模及計算節點與I/O節點的比例變化趨勢
HPC執行的計算任務可能需要幾個小時,也可能長達幾天甚至數週。由於高效能運算系統規模高達上萬個節點,故障難以避免,因此HPC系統中普遍使用“checkpoint”技術週期性地保持計算的狀態和中間結果,當發生故障時,則從上次儲存的“checkpoint”狀態恢復計算。雖然由OS實現“checkpoint”在理論上是可行的,但開銷巨大;由應用程式將任務分解為多個階段,在每個階段完成後儲存計算結果的方法則更簡單而高效。 目前HPC中使用較多的I/O (儲存)系統的架構分別如圖2(a)、(b)所示。 圖2 HPC中的計算節點與I/O子系統 在圖2(a)中,多個I/O節點為對稱結構,以共享儲存區域網(SAN)的方式組成叢集檔案系統,每個檔案以條帶化方式分佈到多個儲存裝置上。計算節點則使用最廣泛的網路檔案訪問協議NFS來訪問叢集檔案系統。這種架構的典型代表是IBM研製的GPFS並行檔案系統【8】。在圖2(a)所示系統中,多個I/O節點以緊耦合方式協同工作,其擴充套件性受到很大限制,I/O節點數一般不超過32。 面向物件的並行檔案系統具有更好的可擴充套件能力,其結構如圖2(b)所示。典型的用於HPC的並行檔案系統有Luster、Panasas、PVFS等。資料表明Luster系統的I/O節點數可擴充套件到103數量級。 在資料訪問模式上,HPC呈現出高併發的特徵。需要處理的資料往往以稀疏矩陣方式儲存在一個或多個巨大的檔案中(GB級甚至TB級),多個計算節點往往需要併發讀寫同一檔案;而在有些應用中則會生成或訪問大量的小檔案,每個計算節點分佈訪問不同的檔案。 HPC對儲存系統的效能,包括吞吐量和延遲都有很高要求,因此大量使用併發技術來提高效能,如在儲存節點內部基於RAID來實現多磁碟併發訪問,採用條帶花技術實現多個儲存節點的併發訪問;另外在資料訪問時採用小塊資料流水線傳輸的方式以隱藏延遲。
DISC是在近年來興起的一種新型的計算方式,在網際網路應用、超級計算、環境科學、生物醫藥、商業資料探勘等領域具有廣泛而重要的應用,已成為網際網路和電腦科學研究的重要內容之一。 DISC所處理的物件是資料,是圍繞資料而展開的計算,其計算方式完全不同於傳統的高效能運算,HPC系統並不適用於DISC。首先,HPC系統動輒高達百萬甚至千萬元的價格使其很難應用到民用領域;從技術角度看,HPC的計算方式需要將資料從儲存節點傳輸到計算節點,而對於高達PB級的海量資料而言,資料讀取的時間將遠高於資料處理所需時間,很顯然,HPC的計算方式不適用於DISC。 出於成本考慮,DISC系統通常都採用大量廉價的商業化PC機;DISC面向的是理海量資料的處理,這些處理任務應儘量在儲存節點本地進行,避免資料的遷移,因此DISC系統中的計算和儲存是一體化的,節點是對等的。 由於DISC採用廉價的商業PC機,而且規模龐大,因此容錯成為需要優先考慮的問題,目前採用的方法主要是資料複製,通常一份資料有3份副本,分別儲存到不同的節點上,從而實現節點級的容錯。資料訪問模式上,呈現WORM(Write Once,Read Many)特性,系統實現上主要針對讀操作進行優化;DISC系統對資料的處理為批處理方式、順序訪問,因此大塊資料傳輸方式效率更高。 Google公司的基礎資訊支撐系統(GFS/Bigtable/MapReduce)是典型的DISC系統,而Hadoop則是該系統的開源實現,目前已被廣泛研究和部署。
DISC和HPC對儲存系統有許多共性要求,如可擴充套件性和高I/O吞吐量。儲存系統架構也是類似的,都採用面向物件的方法,儲存系統都由MDS和OSD兩類節點組成。雖然在巨集觀上有諸多相似,但深入分析就會發現兩者在微觀上有很多差異,這些差異見表2。 表2 DISC與HPC的儲存需求差異 * Panasas和Luster都實現了細粒度的分散式鎖;PVFS不支援鎖操作,需要應用程式避免資料訪問中可能存在的衝突。 從前面的分析可以看出,DISC和HPC對儲存系統的需求有比較大的差異。從目前已有並行檔案系統或儲存產品來看,都未同時支援上述兩種應用。 CMU大學的PDL實驗室對傳統面向HPC的儲存系統能否適用於DISC計算進行了探索和研究【6】。他們將PVFS檔案系統進行了區域性改進,加入了資料複製、資料預取等優化。初步測試表明在經過上述改進後PVFS可達到與Hadoop HDFS同樣的效能,但PVFS仍然缺乏DISC所必需的自動負載均衡等關鍵特徵。
面向HPC的儲存系統所管理的是“一次性”使用的資料,系統關注於高吞吐量和併發性;而DISC面向長期儲存的資料,系統更側重於漸進的可擴充套件性和資料的保護。雖然兩者在巨集觀上有諸多相似,但在決定性的細節上有更多不同。兼顧兩種應用增加了系統的技術複雜度,效能優化變得更加困難。大量分散式系統設計的經驗表明,根據應用需求進行定製和簡化是解決複雜問題行之有效的方法。在IT應用系統的“個性化”要求越來越高而技術發展相對成熟的今天,“One size fit all”模式已不再適用。 面向DISC和HPC的儲存系統,是否應各行其道?
【3】 Hadoop. Apache Hadoop Project. HTTP://HADOOP.APACHE.ORG/ 【4】 Borthakur, D., “The hadoop distributed file system: Architecture and design, 2009.” HTTP://HADOOP.APACHE.ORG/COMMON/DOCS/CURRENT/HDFS_DESIGN.HTML 【5】 Ghemawat, S., H. Gobioff, S.-T. Lueng, “Google File System.” In 19th ACM Symposium on Operating Systems Principles (SOSP’03) 【8】 Frank Schmuck,Roger Haskin. GPFS: A Shared-Disk File System for Large Computing Clusters. Proceedings of the Conference on File and Storage Technologies (FAST’02),28–30 January 2002, Monterey, CA, pp. 231–244. 【9】 PVFS2. Parallel Virtual File System, Version 2. HTTP://WWW.PVFS2.ORG/ |