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

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

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

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

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

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

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

1 引言

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

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

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

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

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

2 相關(guān)工作

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

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

這兩種方法各有利弊，前者對(duì)程序員透明，易于編程，但是開銷較大；后者需要程序員對(duì)已有并行軟件進(jìn)行改造。這兩種方法雖然都可以避免從頭計(jì)算的開銷，但是系統(tǒng)的容錯(cuò)能力有限。這是因?yàn)镸PI編程模型中計(jì)算的規(guī)模(節(jié)點(diǎn)數(shù))預(yù)先確定，任何一個(gè)節(jié)點(diǎn)的失效都會(huì)導(dǎo)致整個(gè)計(jì)算過程中途失敗。回退到檢查點(diǎn)后，往往需要人工干預(yù)、重新調(diào)整計(jì)算規(guī)?；騿⒂眯碌挠?jì)算節(jié)點(diǎn)。對(duì)于大規(guī)模、長時(shí)間的計(jì)算任務(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é)點(diǎn)失效的自動(dòng)處理能力，但是在重啟計(jì)算任務(wù)過程中，也需要將輸入文件拷貝到新的計(jì)算節(jié)點(diǎn)上，會(huì)造成額外的開銷。因此，MapReduce更適合于基于文件的大數(shù)據(jù)并行處理系統(tǒng)，并不適合于計(jì)算密集型應(yīng)用。

3 一個(gè)面向星形計(jì)算模型的并行計(jì)算框架

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

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

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

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

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

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

Figure 1 System structure

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

Figure 2 Software structure of scheduling nodes

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

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

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

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

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

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

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

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

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

4 容錯(cuò)性設(shè)計(jì)方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1 在線監(jiān)控

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

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

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

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

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

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

計(jì)算節(jié)點(diǎn)每個(gè)周期都會(huì)輸出一些信息，以方便系統(tǒng)管理員實(shí)時(shí)了解計(jì)算節(jié)點(diǎn)的運(yùn)行狀態(tài)：

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

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

(3)計(jì)算節(jié)點(diǎn)的空閑時(shí)間。

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

5.2 離線監(jiān)控

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

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

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

(2)某時(shí)刻系統(tǒng)中的計(jì)算節(jié)點(diǎn)數(shù)；

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

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

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

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

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

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

6 多種平臺(tái)的支持能力

6.1 針對(duì)不同計(jì)算節(jié)點(diǎn)類型的配置

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

6.2 計(jì)算節(jié)點(diǎn)和規(guī)模的自動(dòng)適應(yīng)能力

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

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

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

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

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

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

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

(1)

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

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

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

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

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

7 結(jié)束語

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

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

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

致謝 本文得到廣州市科技計(jì)劃項(xiàng)目(2012Y2-00032，2013Y2-00055，201200000034)的資助，并得到廣州超級(jí)計(jì)算中心先導(dǎo)系統(tǒng)、中國科學(xué)院過程工程研究所、國家超級(jí)計(jì)算天津中心的大力支持。歐彥麟、陳海歐等同學(xué)對(duì)本文亦有貢獻(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-),男,江蘇南京人，博士,副教授,研究方向?yàn)楦咝阅苡?jì)算。E-mail:chenhu@scut.edu.cn

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

苗軍(1989-),男,安徽阜陽人，碩士，研究方向?yàn)楦咝阅苡?jì)算。E-mail:527361274@qq.com

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

韓佳龍媚(1991-),女,陜西西安人，碩士，研究方向?yàn)楦咝阅苡?jì)算。E-mail:664291895@qq.com

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

賴路雙(1988-),男,廣東梅州人，碩士,研究方向?yàn)楦咝阅苡?jì)算。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-),男,廣東陸豐人，碩士，研究方向?yàn)楦咝阅苡?jì)算。E-mail:446260133@qq.com

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

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