提升大規(guī)模集群上并行計算軟件系統(tǒng)可靠性和服務(wù)性的方法與實踐*

林彥宇,陳 虎,苗 軍,韓佳龍媚,賴路雙

(華南理工大學(xué)軟件學(xué)院,廣東 廣州 510006)

提升大規(guī)模集群上并行計算軟件系統(tǒng)可靠性和服務(wù)性的方法與實踐*

林彥宇,陳 虎,苗 軍,韓佳龍媚,賴路雙

(華南理工大學(xué)軟件學(xué)院,廣東 廣州 510006)

大規(guī)模集群上的并行計算軟件需要具備處理部分節(jié)點、網(wǎng)絡(luò)等失效的容錯能力，也需要具有易于管理、維護、移植和可擴展的服務(wù)能力。針對星形計算模型，研究和開發(fā)了一套并行計算框架。利用調(diào)度節(jié)點內(nèi)部的可變粒度分解器、相關(guān)隊列等方法，實現(xiàn)了全系統(tǒng)容錯，且具有較好的易用性、可移植性和可擴展性。系統(tǒng)目前可以實現(xiàn)300 TFlops計算能力下連續(xù)運行超過150 h，而且還具有進(jìn)一步的可擴展能力。

可靠性；可擴展性；服務(wù)性;大規(guī)模集群；并行計算軟件

1 引言

可靠性(Availability)和服務(wù)性(Serviceability)是軟件系統(tǒng)的RAS屬性中的重要組成部分[1]，前者指系統(tǒng)可以正常運行的時間比例，后者指軟件使用、維護、改進(jìn)和升級的難易程度。這兩個問題在大規(guī)模集群軟件系統(tǒng)中顯得尤為突出，主要體現(xiàn)在以下幾個方面：

(1)大規(guī)模集群軟硬件結(jié)構(gòu)復(fù)雜，包括節(jié)點計算機、互連網(wǎng)絡(luò)、操作系統(tǒng)、協(xié)議棧和基礎(chǔ)庫等內(nèi)容，而且計算過程中所涉及的節(jié)點眾多，系統(tǒng)基礎(chǔ)平臺的整體平均無故障工作時間大大低于一般單機系統(tǒng)；

(2)并行計算軟件自身算法復(fù)雜，運行時間長，一旦運行過程中失效，重新計算的開銷很大；

(3)并行計算軟件要能適應(yīng)不同的節(jié)點、互連網(wǎng)絡(luò)結(jié)構(gòu)和規(guī)模的多種大規(guī)模集群，對于系統(tǒng)可配置性、可擴展性和可管理性的要求更高。

本文針對大規(guī)模集群并行計算軟件的上述挑戰(zhàn)，介紹了某大規(guī)模并行計算軟件的計算模型和軟件總體結(jié)構(gòu)，重點討論了提高系統(tǒng)可靠性、增強系統(tǒng)可管理性，以及針對不同集群結(jié)構(gòu)的可配置性和可伸縮性的方法。

2 相關(guān)工作

大規(guī)模集群并行計算過程中，系統(tǒng)基礎(chǔ)平臺的整體平均無故障工作時間較低，需要通過改進(jìn)應(yīng)用軟件的方法提升系統(tǒng)整體可靠性。限于篇幅，這里僅僅討論MPI(Message Passing Interface)[2]和MapReduce兩種并行編程模型下的軟件可靠性設(shè)計方法。

MPI是當(dāng)前高性能計算的最主要編程模型。該模型自身并未提供提高系統(tǒng)可靠性的方法，往往采用在檢查點將當(dāng)前運行的現(xiàn)場記錄在文件中的方法，如果系統(tǒng)發(fā)生故障則從前一個檢查點恢復(fù)計算現(xiàn)場，從而避免了從頭重新計算。檢查點又可以分為系統(tǒng)級檢查點和用戶級檢查點兩種，前者的典型代表是美國Ohio大學(xué)的MVAPICH2系統(tǒng)[3]，后者則是由程序員根據(jù)算法的特點在合適的地方自行設(shè)置和實現(xiàn)。

這兩種方法各有利弊，前者對程序員透明，易于編程，但是開銷較大；后者需要程序員對已有并行軟件進(jìn)行改造。這兩種方法雖然都可以避免從頭計算的開銷，但是系統(tǒng)的容錯能力有限。這是因為MPI編程模型中計算的規(guī)模(節(jié)點數(shù))預(yù)先確定，任何一個節(jié)點的失效都會導(dǎo)致整個計算過程中途失敗?；赝说綑z查點后，往往需要人工干預(yù)、重新調(diào)整計算規(guī)?；騿⒂眯碌挠嬎愎?jié)點。對于大規(guī)模、長時間的計算任務(wù)而言，將大大增加系統(tǒng)管理難度。

MapReduce[4]是Google公司提出的面向大數(shù)據(jù)處理的并行架構(gòu)。它與Hadoop并行文件系統(tǒng)緊密相連，其map任務(wù)分解數(shù)正比于Hadoop文件系統(tǒng)中的文件分塊數(shù)。在任務(wù)執(zhí)行前，需要將任務(wù)所需要的資源(包括任務(wù)執(zhí)行代碼、配置文件、輸入文件分段)拷貝到Hadoop文件系統(tǒng)的指定目錄中，并在執(zhí)行過程中由執(zhí)行代碼讀取，這將導(dǎo)致大量的文件內(nèi)容在內(nèi)部互連網(wǎng)絡(luò)傳輸。MapReduce提供了節(jié)點失效的自動處理能力，但是在重啟計算任務(wù)過程中，也需要將輸入文件拷貝到新的計算節(jié)點上，會造成額外的開銷。因此，MapReduce更適合于基于文件的大數(shù)據(jù)并行處理系統(tǒng)，并不適合于計算密集型應(yīng)用。

3 一個面向星形計算模型的并行計算框架

高性能計算應(yīng)用軟件體系結(jié)構(gòu)往往與其計算模型密不可分，本文所研究的星形計算模型可以描述為以下三個步驟：

(1)任務(wù)分解：計算量為S的作業(yè)J分解為N個計算量分別為S1,…,SN的節(jié)點任務(wù)T1,…,TN;

(2)并行計算：P個計算節(jié)點并行完成計算任務(wù)T1,…,TN，并得到對應(yīng)的計算結(jié)果R1,…,RN;

(3)結(jié)果合并：系統(tǒng)的最終結(jié)果R取決于R1,…,RN。

節(jié)點任務(wù)T1,…,TN都是計算密集型任務(wù)，執(zhí)行過程之間沒有相關(guān)性，也不進(jìn)行相互通信。最后的結(jié)果合并過程非常簡單，計算量僅為O(N)。雖然星形計算模型非常簡單，但是應(yīng)用非常廣泛，例如大空間的并行搜索、動漫渲染中對多個文件的并行渲染等。

為了實現(xiàn)星形計算模型，系統(tǒng)包含了管理節(jié)點、調(diào)度節(jié)點和計算節(jié)點三個主要部分，如圖1所示。其中管理節(jié)點負(fù)責(zé)整個系統(tǒng)的管理和監(jiān)控，提供用戶添加、刪除、查詢作業(yè)等操作界面，同時向用戶反饋作業(yè)的執(zhí)行情況。調(diào)度節(jié)點主要負(fù)責(zé)將作業(yè)分解為適合于節(jié)點計算的任務(wù)，并將任務(wù)分配到相應(yīng)的計算節(jié)點上。計算節(jié)點負(fù)責(zé)完成調(diào)度節(jié)點發(fā)出的節(jié)點任務(wù)。

Figure 1 System structure

調(diào)度節(jié)點是整個系統(tǒng)的核心，其軟件總體結(jié)構(gòu)如圖2所示。

Figure 2 Software structure of scheduling nodes

調(diào)度節(jié)點中的核心是作業(yè)分解器(Decomposer)，其任務(wù)是將計算量為S的作業(yè)J分解為N個計算量分別為S1,…,SN的節(jié)點任務(wù)T1,…,TN。該通用計算模型中，分解器應(yīng)可以事先設(shè)定目標(biāo)計算粒度Starget，使得任務(wù)平均計算粒度S/N盡量接近于它。在實際的分解器中，往往很難做到每個節(jié)點任務(wù)的粒度都等于目標(biāo)計算粒度，但應(yīng)該滿足min(S1,…,SN)>(1/λ)Starget和max(S1,…,SN)<λStarget，其中λ一般不超過3。本系統(tǒng)中使用的分解器主要是對字符空間進(jìn)行分解。分解器通過預(yù)設(shè)的計算粒度將字符空間分解成相互獨立的子空間。用戶可以通過自定義分解器替換本系統(tǒng)已有的字符空間分解器來實現(xiàn)對新類型的分解。

調(diào)度節(jié)點中還包含了三個隊列：全局隊列g(shù)q(GlobalQueue)、完成隊列dq(DoneQueue)和任務(wù)隊列jq(JobQueue)。其中全局隊列g(shù)q用于存儲已經(jīng)被分解的但尚未投入計算節(jié)點的任務(wù)，完成隊列dq存儲所有已經(jīng)發(fā)給計算節(jié)點但尚未返回結(jié)果的任務(wù)，任務(wù)隊列jq則用于存儲尚未進(jìn)行分解的作業(yè)。同時，每個計算節(jié)點都有一個與之對應(yīng)的節(jié)點隊列NodeQueue用于存儲分配到該計算節(jié)點、但尚未發(fā)送給該計算節(jié)點的計算任務(wù)。

調(diào)度節(jié)點中有六個線程并行工作，其中最主要的線程為周期性執(zhí)行的(周期一般設(shè)定為10 s)Dispatcher線程，其核心算法為：

(1)如果分解器已分解完當(dāng)前作業(yè)，則從作業(yè)隊列中重新取一個作業(yè)，并調(diào)用分解器；

(2)將作業(yè)分解為若干計算任務(wù)(任務(wù)分解數(shù)由gq隊列的空閑長度決定)，并插入gq隊列中；

(3)根據(jù)一定的分派算法將gq中的任務(wù)分派到計算節(jié)點隊列NodeQueue上，同時將此任務(wù)也插入到dq隊列，并記錄插入dq隊列的時間Tdq。

(4)檢查所有dq隊列中的任務(wù)t，如果當(dāng)前時間T和Tdq大于閾值Tretry，則將此任務(wù)從dq中刪除，并重新加入gq隊列。

Result線程將監(jiān)聽計算節(jié)點返回的結(jié)果，根據(jù)結(jié)果中包含的全局唯一任務(wù)號在完成隊列dq中查找，如果找到則將其從dq隊列中刪除;Task線程監(jiān)聽管理節(jié)點的TCP連接，并負(fù)責(zé)接收管理節(jié)點發(fā)出的新建作業(yè)命令，并將該作業(yè)插入到作業(yè)隊列jq中；Sender線程負(fù)責(zé)將Dispatcher分派到NodeQueue的任務(wù)通過UDP連接發(fā)送到相應(yīng)的計算節(jié)點上；Status線程負(fù)責(zé)將系統(tǒng)狀態(tài)信息周期性反饋給管理節(jié)點；Command線程主要監(jiān)聽管理節(jié)點TCP連接，并處理管理節(jié)點發(fā)送過來的控制命令。

計算節(jié)點在接收到調(diào)度節(jié)點發(fā)來的任務(wù)后，將任務(wù)記錄在一個隊列中。如果計算節(jié)點有K個計算部件，則可以同時執(zhí)行K個任務(wù)。任務(wù)計算結(jié)束后，將計算結(jié)果通過UDP協(xié)議發(fā)送回調(diào)度節(jié)點，由Result線程處理計算結(jié)果。當(dāng)計算節(jié)點的隊列將滿時，將向調(diào)度節(jié)點發(fā)送減速命令；隊列將空時，發(fā)送加速命令，從而保證計算節(jié)點的隊列長度處于合適大小。

4 容錯性設(shè)計方法

在上述系統(tǒng)中，為了提高系統(tǒng)的可靠性，使得系統(tǒng)具有一定的容錯能力，我們使用了以下具體方法。

4.1 計算節(jié)點失效的處理方法——調(diào)度節(jié)點的任務(wù)重發(fā)機制

在大規(guī)模集群的長時間計算過程中，難免會出現(xiàn)一個或多個計算節(jié)點失效的情況。為了防止計算任務(wù)丟失，本系統(tǒng)利用dq隊列實現(xiàn)失效計算節(jié)點任務(wù)的重計算。在Dispatcher分派線程中，當(dāng)將一個節(jié)點任務(wù)插入到gq時，也同時會將其插入到dq中，并且記錄其加入dq的時間。當(dāng)要向各個計算節(jié)點分派節(jié)點任務(wù)時，調(diào)度節(jié)點從gq取出節(jié)點任務(wù)，但不刪除dq中對應(yīng)的元素。當(dāng)一個節(jié)點任務(wù)計算完成時，調(diào)度節(jié)點會收到來自計算節(jié)點的反饋信息，這時調(diào)度節(jié)點才會把dq中對應(yīng)的節(jié)點任務(wù)刪除。因此，通常情況下，每一個節(jié)點任務(wù)只會在dq中駐留一段時間。如果dq中某個任務(wù)的駐留時間超過閾值，調(diào)度節(jié)點認(rèn)為此節(jié)點任務(wù)因網(wǎng)絡(luò)故障或者計算節(jié)點失效而不能完成，會把該節(jié)點任務(wù)重新插入到gq中，重新分配到其他計算節(jié)點，從而實現(xiàn)計算節(jié)點或互連網(wǎng)絡(luò)失效時計算任務(wù)重發(fā)的處理過程。

4.2 調(diào)度節(jié)點失效的處理方法——定時保存和恢復(fù)

在大規(guī)模集群中，還可能出現(xiàn)調(diào)度節(jié)點失效的情況。為了應(yīng)對這種情況，在調(diào)度節(jié)點中有一個定時備份線程(周期一般為30 min)，定時保存調(diào)度節(jié)點當(dāng)前運行狀態(tài)到特定的現(xiàn)場文件，以便在調(diào)度節(jié)點失效時恢復(fù)。該線程保護的內(nèi)容主要包括：

(1)當(dāng)前計算作業(yè)信息，包括提交用戶、作業(yè)名、作業(yè)的具體內(nèi)容、運行狀態(tài)等。

(2)分解器狀態(tài)。由于較大的計算作業(yè)不可能一次性完全分解，我們所采用的策略是邊計算邊分解。因此，正在執(zhí)行的計算作業(yè)中，有些任務(wù)已經(jīng)分解完成，有些則處于尚未分解的狀態(tài)，需要保護當(dāng)前分解器的這些現(xiàn)場。

(3)調(diào)度節(jié)點中的gq隊列、dq隊列和jq隊列。

調(diào)度節(jié)點意外失效后，重啟時將檢查系統(tǒng)的現(xiàn)場文件，并通過現(xiàn)場文件恢復(fù)失效前系統(tǒng)的運行狀態(tài)。由于定時備份的周期為30 min，因此在計算節(jié)點失效時最多可能會浪費30 min的計算能力。

4.3 互連網(wǎng)絡(luò)失效的處理方法——計算節(jié)點失去連接后對調(diào)度節(jié)點的自動重連

在大規(guī)模集群中，可能會有部分互連網(wǎng)絡(luò)故障(例如某機柜的交換機暫時失效)，導(dǎo)致部分計算節(jié)點和調(diào)度節(jié)點的通信中斷。為了解決此類問題，系統(tǒng)使用了如下兩種方法：

(1)計算節(jié)點每隔一定時間間隔會向調(diào)度節(jié)點發(fā)送心跳報文，以通知調(diào)度節(jié)點該計算節(jié)點仍可用。

(2)若計算節(jié)點處于空閑狀態(tài)，則它會統(tǒng)計處于空閑的時間。若該時間超過預(yù)先設(shè)定的閾值，則認(rèn)為計算節(jié)點可能由于互連網(wǎng)絡(luò)失效而和調(diào)度節(jié)點失去連接。此時，計算節(jié)點會每隔一定周期就向調(diào)度節(jié)點發(fā)送一個重連報文，以便和調(diào)度節(jié)點重新建立聯(lián)系。

5 易用性設(shè)計方法

5.1 在線監(jiān)控

在系統(tǒng)正常運行過程中，調(diào)度節(jié)點會周期性地統(tǒng)計和輸出以下信息，供系統(tǒng)管理員實時監(jiān)控系統(tǒng)運行狀態(tài)：

(1)當(dāng)前每個計算節(jié)點的計算能力、系統(tǒng)平均計算能力等信息；

(2)當(dāng)前周期內(nèi)計算節(jié)點的加速和減速命令個數(shù)；

(3)gq隊列和dq隊列的長度及重發(fā)的任務(wù)數(shù)；

(4)分解器的任務(wù)粒度、分解的任務(wù)數(shù)、任務(wù)平均大小等；

(5)當(dāng)有新的計算節(jié)點加入到集群、發(fā)送一個節(jié)點任務(wù)、刪除一個節(jié)點任務(wù)等情況時，調(diào)度節(jié)點都會顯示相應(yīng)的信息。

計算節(jié)點每個周期都會輸出一些信息，以方便系統(tǒng)管理員實時了解計算節(jié)點的運行狀態(tài)：

(1)計算節(jié)點的配置信息，包括CPU型號、計算加速卡型號和卡數(shù)、內(nèi)存大小等信息；

(2)計算節(jié)點中的任務(wù)隊列長度及各計算加速卡的負(fù)載情況；

(3)計算節(jié)點的空閑時間。

通過上述信息，系統(tǒng)管理員可以實時了解整個系統(tǒng)的工作狀態(tài)，并及時發(fā)現(xiàn)可能存在的問題。

5.2 離線監(jiān)控

由于作業(yè)的計算時間可能長達(dá)一周，系統(tǒng)管理員難以24 h監(jiān)控系統(tǒng)運行。調(diào)度節(jié)點會對系統(tǒng)的運行狀態(tài)進(jìn)行實時記錄，產(chǎn)生基于XML格式的日志文件。系統(tǒng)管理員可以使用離線監(jiān)控軟件對日志文件解析，并實現(xiàn)可視化顯示，分析整個運行過程中系統(tǒng)的運行狀態(tài)。

調(diào)度節(jié)點實時保存的信息主要分為三類：

(1)計算節(jié)點的基本信息，包括計算節(jié)點啟動時間、日志文件最后保存時間、系統(tǒng)名等；

(2)某時刻系統(tǒng)中的計算節(jié)點數(shù)；

(3)計算節(jié)點上所有任務(wù)的運行狀態(tài)。

在離線管理節(jié)點，由C#語言編寫的Windows桌面應(yīng)用程序，使用System.XML命名空間下針對日志文件格式的函數(shù)來對日志文件進(jìn)行讀取和解析，并使用WPF開源控件庫DynamicDataDisplay將信息可視化顯示。圖3給出了一個典型日志文件的顯示狀態(tài)。

Figure 3 Status of computing nodes on a small-scale test

5.3 作業(yè)的不間斷運行

在大規(guī)模集群中，經(jīng)常需要提交多個作業(yè)。若一次同時提交并執(zhí)行多個作業(yè)，將導(dǎo)致各個作業(yè)的完成時間都很長，不利于及時評估任務(wù)的執(zhí)行情況。但是，如果每次僅僅執(zhí)行一個作業(yè)，就需要系統(tǒng)管理員計算好各個作業(yè)的運行時間，當(dāng)估計前一個作業(yè)即將完成時，再去提交下一個作業(yè)，以防止系統(tǒng)空轉(zhuǎn)，提高系統(tǒng)的利用率。由于作業(yè)切換的預(yù)期時間有可能會在深夜，這將大大增加系統(tǒng)管理員的工作負(fù)擔(dān)。

為了解決上面提到的問題，使用作業(yè)隊列jq實現(xiàn)作業(yè)的不間斷運行。當(dāng)用戶提交一個作業(yè)時，該作業(yè)一般會先被加入到j(luò)q的隊尾。若當(dāng)前系統(tǒng)沒有正在運行的作業(yè)，則調(diào)度節(jié)點會取出jq隊列頭的作業(yè)運行。使用jq使得系統(tǒng)一次僅運行一個作業(yè)，且保證了每個作業(yè)間可以實現(xiàn)自動切換，避免了系統(tǒng)管理員手工提交作業(yè)的工作。為了實現(xiàn)高優(yōu)先級作業(yè)的優(yōu)先運行，系統(tǒng)支持用戶將作業(yè)插入到j(luò)q隊列的隊頭，或者直接將正在運行的作業(yè)切換到指定作業(yè)。

6 多種平臺的支持能力

6.1 針對不同計算節(jié)點類型的配置

對于不同的平臺，系統(tǒng)中計算節(jié)點的計算卡數(shù)會各有不同(如“天河一號”系統(tǒng)中，每個計算節(jié)點包含一塊C2050卡；Mole 8.5系統(tǒng)中，每個計算節(jié)點有六塊C2050卡)。當(dāng)系統(tǒng)每次收到計算節(jié)點的加速命令或減速命令時，調(diào)度節(jié)點按照設(shè)定的步進(jìn)值speed_step調(diào)整系統(tǒng)對計算節(jié)點的計算速度的評估值。在Mole 8.5系統(tǒng)中speed_step設(shè)置為6；“天河一號”系統(tǒng)中speed_step設(shè)置為1。當(dāng)接收到計算節(jié)點發(fā)送一個加速命令時，Mole 8.5系統(tǒng)將按六倍于“天河一號”系統(tǒng)的步進(jìn)值對計算節(jié)點的計算速度進(jìn)行調(diào)整，這使得系統(tǒng)可以更加迅速地響應(yīng)計算節(jié)點的速度變化。

6.2 計算節(jié)點和規(guī)模的自動適應(yīng)能力

在一個集群中，各個計算節(jié)點間的硬件配置可能不一樣，其性能也有所差別，即使是在相同配置的計算節(jié)點上，其性能也不完全一樣。例如，當(dāng)出現(xiàn)計算節(jié)點上的某些設(shè)備突然失效時，該計算節(jié)點的計算性能可能會有所下降。系統(tǒng)通過考察64個周期(即640 s)計算節(jié)點完成的基準(zhǔn)任務(wù)數(shù)來評估該節(jié)點的當(dāng)前計算能力。在得到各個節(jié)點的計算能力后，系統(tǒng)會為每個計算節(jié)點分派適當(dāng)?shù)娜蝿?wù)。

當(dāng)計算節(jié)點的隊列將滿時，會向調(diào)度節(jié)點發(fā)送一個減速命令。當(dāng)調(diào)度節(jié)點接收到此命令后，會適當(dāng)?shù)匕褜Υ擞嬎愎?jié)點的計算能力估計值調(diào)低，以降低對該節(jié)點的任務(wù)發(fā)送速度。同理，在計算節(jié)點的任務(wù)減少到一定程度時，計算節(jié)點又會向調(diào)度節(jié)點發(fā)送加速命令，以提高計算節(jié)點的計算能力估計值，從而加快節(jié)點任務(wù)的發(fā)送速度。

當(dāng)新的計算節(jié)點剛加入時，通過發(fā)送加速命令可以快速地提高調(diào)度節(jié)點對該節(jié)點計算能力的評估值，從而快速達(dá)到預(yù)期的計算能力。當(dāng)系統(tǒng)中有計算節(jié)點失效或計算節(jié)點性能下降時，調(diào)度節(jié)點會降低對計算節(jié)點速度的評估值，從而降低或完全取消對該節(jié)點的任務(wù)分配。

6.3 系統(tǒng)可擴展能力分析

由于整個系統(tǒng)中僅有一個調(diào)度節(jié)點，其處理能力和網(wǎng)絡(luò)傳輸能力可能會成為系統(tǒng)的瓶頸。系統(tǒng)采用了粒度可配置的作業(yè)分解器和基于UDP協(xié)議網(wǎng)絡(luò)傳輸方法等兩種解決方法，以提升調(diào)度節(jié)點的處理能力。

調(diào)度節(jié)點中最占用計算資源的是Dispatcher線程，設(shè)其每完成一個包的分解、分派和相應(yīng)的隊列操作的時間為Tdispatch(注意：此時間與任務(wù)的目標(biāo)粒度Starget無關(guān))，則每秒鐘能產(chǎn)生的任務(wù)數(shù)為1/Tdispatch。

單個計算節(jié)點的吞吐率可以描述為(K*C)/Starget個任務(wù)/s，其中,K為計算節(jié)點中的并行任務(wù)處理數(shù)，C為單個任務(wù)的單位處理速度。P個計算節(jié)點的總吞吐率為(K*C)/Starget×P。調(diào)度節(jié)點的吞吐率需要大于所有計算節(jié)點吞吐率之和，即(K*C)/Starget×P<1/Tdispatch，由此可以得到系統(tǒng)最大可以支持的計算節(jié)點數(shù)P為：

(1)

其中，Ttarget=Starget/C為一個目標(biāo)大小任務(wù)完成所需要的時間。

根據(jù)我們的實際測試，對于字符空間的分解而言,Tdispatch大約為6 ms左右。目前系統(tǒng)設(shè)定適當(dāng)?shù)娜蝿?wù)粒度Starget，使得Ttarget為8 s。“天河一號”超級計算機系統(tǒng)中每個計算節(jié)點包含一塊C2050計算卡(K=1)，Mole 8.5系統(tǒng)中每個節(jié)點則包含六塊C2050計算卡(K=6)，則本系統(tǒng)在“天河一號”和Mole 8.5系統(tǒng)上所能支持的最大計算節(jié)點數(shù)分別為1 328個和221個。

由式(1)可以看出，可以通過增加目標(biāo)分解粒度的方法來增加系統(tǒng)的計算節(jié)點數(shù)。當(dāng)然，如果增加目標(biāo)分解粒度，系統(tǒng)的任務(wù)重發(fā)時間Tre_compute(一般為Ttarget的10倍)將隨之增大，使得系統(tǒng)發(fā)現(xiàn)失效節(jié)點的能力下降。對于“天河二號”而言，每個計算節(jié)點有三塊MIC加速卡(K=3)，如果峰值性能要求達(dá)到10 PFlops，需要支持3 333個節(jié)點，由式(1)可以計算得出Ttarget應(yīng)為60.2 s，Tre_compute為600 s，依然處于可以接受的范圍之內(nèi)。通過Ttarget可以計算出合理的任務(wù)粒度Starget，使其與并行計算的規(guī)模相適應(yīng)。

由于在調(diào)度節(jié)點和計算節(jié)點之間采用UDP協(xié)議傳輸任務(wù)內(nèi)容和計算結(jié)果，其傳輸包數(shù)量僅僅為任務(wù)數(shù)量的兩倍，且有效地避免了調(diào)度節(jié)點用于TCP協(xié)議的處理開銷以及額外的網(wǎng)絡(luò)傳輸開銷。每個任務(wù)描述和結(jié)果包大小一般不超過1 500 B，實際測試表明，調(diào)度節(jié)點的網(wǎng)絡(luò)負(fù)載僅為系統(tǒng)的5%以下。

從上述分析可以看出，雖然系統(tǒng)中僅僅只有一個調(diào)度節(jié)點，但是借助于調(diào)整作業(yè)分解器粒度和基于UDP協(xié)議的傳輸依然可以有效地擴展系統(tǒng)的計算能力，達(dá)到10 PFlops的計算能力。

7 結(jié)束語

圖3所示為某次較小規(guī)模測試的計算節(jié)點運行情況。開始時系統(tǒng)共有102個計算節(jié)點，但由于計算節(jié)點故障和網(wǎng)絡(luò)失效等原因，有一小部分計算節(jié)點先后與系統(tǒng)失去聯(lián)系。在4月22日9時左右，由于網(wǎng)絡(luò)恢復(fù)，大部分節(jié)點都重新與系統(tǒng)取得聯(lián)系，并較平穩(wěn)地運行直至計算任務(wù)完成。

為了測試本系統(tǒng)的可靠性、容錯能力。我們先后在廣州超級計算中心先導(dǎo)系統(tǒng)和Mole 8.5上分別進(jìn)行了大規(guī)模測試。在廣州超級計算中心先導(dǎo)系統(tǒng)上，使用300個節(jié)點(峰值計算能力達(dá)到150 TFlops)，連續(xù)運行177 h，總計算能力達(dá)到53 100卡*h。在過程所的Mole 8.5系統(tǒng)上，使用100個節(jié)點(峰值計算能力達(dá)到300 TFlops)，連續(xù)運行169 h，總計算能力達(dá)到101 400卡*h。

該并行計算框架已經(jīng)在某專業(yè)計算軟件中得到使用，并且實現(xiàn)了較好的容錯性、可移植性和可擴展性。但是，隨著“天河二號”等新一代超級計算機的出現(xiàn)，用戶對系統(tǒng)又提出了更高的可擴展性要求，并且在軟件的友好性、方便性等方面提出了進(jìn)一步的要求。

致謝 本文得到廣州市科技計劃項目(2012Y2-00032，2013Y2-00055，201200000034)的資助，并得到廣州超級計算中心先導(dǎo)系統(tǒng)、中國科學(xué)院過程工程研究所、國家超級計算天津中心的大力支持。歐彥麟、陳海歐等同學(xué)對本文亦有貢獻(xiàn)。

[1] Hwang K. Distributed and cloud computing:From parallel Processing to the Internet of Things[M]San Francisco:Morgan Kaufmann, 2011.

[2] MPI standard[EB/OL].[2013-07-15].http://www.mcs.anl.gov/research/projects/mpi/.

[3] MVAPICH and MVAPICH2 project[EB/OL].[2013-07-15].http://mvapich.cse.ohio-state.edu/overview/mvapich2/.

[4] White T. Hadoop:The definitive guide[M]. California:O’Reilly Media Inc, 2008.

LIN Yan-yu,born in 1989,MS,his research interest includes high performance computing.

陳虎(1974-),男,江蘇南京人，博士,副教授,研究方向為高性能計算。E-mail:chenhu@scut.edu.cn

CHEN Hu,born in 1974,PhD,associate professor,his research interest includes high performance computing.

苗軍(1989-),男,安徽阜陽人，碩士，研究方向為高性能計算。E-mail:527361274@qq.com

MIAO Jun,born in 1989,MS,his research interest includes high performance computing.

韓佳龍媚(1991-),女,陜西西安人，碩士，研究方向為高性能計算。E-mail:664291895@qq.com

HAN Jia-long-mei,born in 1991,MS,her research interest includes high performance computing.

賴路雙(1988-),男,廣東梅州人，碩士,研究方向為高性能計算。E-mail:563662346@qq.com

LAI Lu-shuang,born in 1988,MS,his research interest includes high performance computing.

Methods to enhance reliability and serviceability of parallel computing software on large scale clusters

LIN Yan-yu,CHEN Hu,MIAO Jun,HAN Jia-long-mei,LAI Lu-shuang

(School of Software,South China University of Technology,Guangzhou 510006,China)

Parallel computing software on large-scale clusters requires not only fault tolerance against local nodes or network failure,but also manageability,maintainability,portability and scalability. Based on the star model,we design a parallel computing framework and achieve system-wide fault tolerance, usability,portability and scalability,using methods such as the variable granularity decomposer and associated queue on the scheduling nodes.Our system can continuously run over 150 hours with 300 TFlops computational capability.Besides,the system is scalable.

availability;scalability;serviceability;large scale cluster;parallel computing software

1007-130X(2015)01-0001-06

2013-09-24;

2013-12-18

TP393

A

10.3969/j.issn.1007-130X.2015.01.001

林彥宇(1989-),男,廣東陸豐人，碩士，研究方向為高性能計算。E-mail:446260133@qq.com

通信地址：510006 廣東省廣州市華南理工大學(xué)軟件學(xué)院

Address:School of Software, South China University of Technology, Guangzhou 510006,Guangdong,P.R.China