并行程序運(yùn)行故障原因識(shí)別*

劉 軼，高玉林，張國(guó)振

(北京航空航天大學(xué) 計(jì)算機(jī)學(xué)院， 北京 100191)

高性能計(jì)算(high performance computing，HPC)系統(tǒng)廣泛應(yīng)用于國(guó)防建設(shè)、科學(xué)研究以及國(guó)民經(jīng)濟(jì)等重要領(lǐng)域，這些重要領(lǐng)域內(nèi)應(yīng)用需求的日益增長(zhǎng)促進(jìn)了高性能計(jì)算系統(tǒng)的迅速發(fā)展和規(guī)模增長(zhǎng)。日本于2020年6月發(fā)布的超級(jí)計(jì)算機(jī)Fugaku[1]擁有158 976個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)處理器包含48個(gè)計(jì)算核及4個(gè)輔助核，系統(tǒng)峰值浮點(diǎn)性能高達(dá)513 PFLOPS。神威·太湖之光[2]是性能優(yōu)越的國(guó)產(chǎn)超級(jí)計(jì)算機(jī)，擁有40 960個(gè)處理器，共10 649 600個(gè)處理器核，系統(tǒng)峰值性能達(dá)125.436 PFLOPS。

隨著高性能計(jì)算系統(tǒng)規(guī)模的日益龐大以及系統(tǒng)內(nèi)組件數(shù)量的迅速增加，硬軟件復(fù)雜性不斷提高、系統(tǒng)日益復(fù)雜，這使得高性能計(jì)算系統(tǒng)的平均無(wú)故障時(shí)間(mean time between failures，MTBF)越來(lái)越短。HPC系統(tǒng)上通常運(yùn)行并行程序，由于參與并行程序運(yùn)行的節(jié)點(diǎn)數(shù)巨大、程序運(yùn)行時(shí)間長(zhǎng)，系統(tǒng)MTBF的降低使得程序在運(yùn)行過(guò)程中發(fā)生硬軟件故障的可能性也隨之增加。突發(fā)的系統(tǒng)硬軟件故障，如節(jié)點(diǎn)死機(jī)、操作系統(tǒng)崩潰、互連網(wǎng)絡(luò)故障等，會(huì)影響程序執(zhí)行，甚至導(dǎo)致程序運(yùn)行失效。

消息傳遞接口(message passing interface, MPI)是HPC系統(tǒng)中用于進(jìn)程間通信的并行編程接口。盡管MPI應(yīng)用廣泛，但它自身并不具備容錯(cuò)機(jī)制。如果其中一個(gè)計(jì)算節(jié)點(diǎn)崩潰，整個(gè) MPI 并行程序?qū)?huì)崩潰。在HPC系統(tǒng)中，失效的程序通常比成功的程序消耗更多的資源。

大多數(shù)HPC系統(tǒng)使用作業(yè)管理系統(tǒng)(如Slurm[3]、PBS[4])來(lái)管理資源，并執(zhí)行不同用戶(hù)的多個(gè)作業(yè)。程序執(zhí)行過(guò)程中，用戶(hù)不能直接與程序進(jìn)行交互。同時(shí)，作業(yè)管理系統(tǒng)只能反映作業(yè)的排隊(duì)、運(yùn)行狀態(tài)，并不能發(fā)現(xiàn)程序在運(yùn)行時(shí)出現(xiàn)的所有異常情況。當(dāng)程序自身存在編程bug，如死鎖、死循環(huán)等情況時(shí)，程序不會(huì)被作業(yè)管理系統(tǒng)中止，這將占用計(jì)算資源，并且影響程序的正常執(zhí)行。在硬軟件故障方面，除了元器件和部件故障導(dǎo)致死機(jī)、程序崩潰等常見(jiàn)的故障之外，還有一些間歇性的故障。例如，內(nèi)存工作不穩(wěn)定或接觸不良可能導(dǎo)致系統(tǒng)故障。這些故障會(huì)偶發(fā)出現(xiàn)，具有不確定性。

雖然用戶(hù)可以在小規(guī)模下調(diào)試程序，但是許多問(wèn)題只有在進(jìn)程足夠多時(shí)才會(huì)出現(xiàn)，而且某些調(diào)試工具雖可以收集程序狀態(tài)，但不能提供參與程序執(zhí)行的計(jì)算節(jié)點(diǎn)的硬軟件狀態(tài)。因此，如果程序在HPC上運(yùn)行失敗，用戶(hù)應(yīng)該首先區(qū)分運(yùn)行失敗是由于程序自身bug還是系統(tǒng)硬軟件故障。

Slurm是一個(gè)大規(guī)模Linux機(jī)群的輕量級(jí)開(kāi)源資源與作業(yè)管理器，可以為用戶(hù)提供對(duì)機(jī)群資源的共享訪問(wèn)。由于輕量且高效的性能，Slurm受到超算中心的關(guān)注，超過(guò)60%的500強(qiáng)超級(jí)計(jì)算機(jī)使用Slurm[3]。本文基于Slurm提出一種并行程序運(yùn)行故障原因識(shí)別系統(tǒng)，將程序運(yùn)行失效的原因識(shí)別為系統(tǒng)硬軟件故障或程序自身bug，減輕了調(diào)試過(guò)程的平均故障間隔時(shí)間縮短對(duì)未來(lái)百億億級(jí)超級(jí)計(jì)算機(jī)的影響，并提高了調(diào)試大型并行程序的效率。

1 作業(yè)管理系統(tǒng)Slurm簡(jiǎn)介

Slurm是一種開(kāi)源的Linux機(jī)群管理和作業(yè)調(diào)度系統(tǒng)。它具有三個(gè)主要功能：首先，它提供了一個(gè)框架，用于在高性能計(jì)算機(jī)群上提交、啟動(dòng)和監(jiān)視分配所有計(jì)算節(jié)點(diǎn)上的作業(yè)；然后，它使用排隊(duì)策略管理等待資源分配的作業(yè)隊(duì)列，以提高計(jì)算節(jié)點(diǎn)資源的利用率；最后，它統(tǒng)籌分配計(jì)算節(jié)點(diǎn)的資源給用戶(hù)的作業(yè)，使得用戶(hù)的作業(yè)可以運(yùn)行。

Slurm的組織架構(gòu)如圖1所示。Slurm主控制節(jié)點(diǎn)運(yùn)行slurmctld守護(hù)程序，用于管理資源、調(diào)度和監(jiān)視作業(yè)。當(dāng)主控制節(jié)點(diǎn)出現(xiàn)故障時(shí)，備用控制節(jié)點(diǎn)對(duì)系統(tǒng)進(jìn)行管理，提高了Slurm的容錯(cuò)性。每個(gè)計(jì)算節(jié)點(diǎn)都運(yùn)行slurmd守護(hù)程序，該守護(hù)程序負(fù)責(zé)等待和執(zhí)行slurmctld分配的作業(yè)，并監(jiān)視作業(yè)的狀態(tài)、響應(yīng)slurmctld對(duì)機(jī)器狀態(tài)和作業(yè)信息的請(qǐng)求、發(fā)送機(jī)器狀態(tài)和作業(yè)狀態(tài)的變化到slurmctld。slurmstepd由slurmd守護(hù)進(jìn)程在作業(yè)啟動(dòng)時(shí)生成，并在作業(yè)完成后終止。slurmstepd是Slurm的作業(yè)步管理進(jìn)程，負(fù)責(zé)管理作業(yè)步的輸入、輸出(stdin、stdout和stderr)及信號(hào)處理。

圖1 Slurm組成結(jié)構(gòu)Fig.1 Slurm architecture

Slurm用戶(hù)命令包括sbatch，srun，sinfo，squeue和scontrol等。sbatch和srun用于提交作業(yè)；sinfo和squeue可以報(bào)告系統(tǒng)所有計(jì)算節(jié)點(diǎn)狀態(tài)和作業(yè)隊(duì)列中的作業(yè)狀態(tài)；scontrol用于監(jiān)視和修改機(jī)群中的配置和狀態(tài)信息。當(dāng)普通用戶(hù)在Slurm上調(diào)試大型并行程序時(shí)，只能通過(guò)Slurm提交待調(diào)試的作業(yè)，等待Slurm分配計(jì)算資源，最后等待執(zhí)行結(jié)果。在程序執(zhí)行期間，普通用戶(hù)只能使用squeue和scontrol show job命令查看作業(yè)的狀態(tài)，不能得到節(jié)點(diǎn)硬軟件狀態(tài)的數(shù)據(jù)。在節(jié)點(diǎn)失效、運(yùn)行超時(shí)等情況下，scontrol show job命令可以輸出作業(yè)的信息(如NODE FAILURE、TIMEOUT等)，但不能定位具體的故障位置和原因。

HPC上的大多數(shù)并行應(yīng)用程序需要很長(zhǎng)時(shí)間來(lái)運(yùn)行，它們的測(cè)試運(yùn)行通常持續(xù)幾個(gè)小時(shí)甚至幾天，普通用戶(hù)不可能時(shí)刻查看程序狀態(tài)和節(jié)點(diǎn)狀態(tài)。如果程序運(yùn)行失效后，普通用戶(hù)沒(méi)有第一時(shí)間發(fā)現(xiàn)程序運(yùn)行結(jié)束，并且在發(fā)現(xiàn)運(yùn)行結(jié)束后很難區(qū)分程序運(yùn)行失效是由于程序自身bug還是節(jié)點(diǎn)的硬軟件故障，這將大大增加程序調(diào)試的時(shí)間和降低調(diào)試的效率。因此，需要一種基于Slurm的并行程序運(yùn)行故障原因識(shí)別機(jī)制，通過(guò)監(jiān)控程序和節(jié)點(diǎn)狀態(tài)，當(dāng)程序出錯(cuò)時(shí)識(shí)別程序的故障原因。

2 并行程序運(yùn)行故障原因識(shí)別系統(tǒng)

2.1 運(yùn)行故障原因分類(lèi)

HPC系統(tǒng)上并行程序運(yùn)行失敗按照故障原因分類(lèi)有多種維度。

1)按照故障現(xiàn)象分類(lèi)(外在表現(xiàn))：有節(jié)點(diǎn)死機(jī)、程序異常退出、程序運(yùn)行停滯、程序執(zhí)行時(shí)間異常和程序運(yùn)行結(jié)果錯(cuò)誤等類(lèi)別。

2)按照故障原因分類(lèi)：有程序編程錯(cuò)誤和系統(tǒng)硬件/軟件故障兩種。

3)按故障的確定性分類(lèi)：有確定性故障和非確定性故障兩種類(lèi)別。確定性故障為每次運(yùn)行都會(huì)出現(xiàn)的故障，具有確定性和可重復(fù)性；非確定性故障即在運(yùn)行期間可能會(huì)出現(xiàn)的故障，具有不確定性。

把上述三種故障分類(lèi)里2和3的故障類(lèi)型進(jìn)行組合，就可以得到以下四種故障類(lèi)型：

a)編程錯(cuò)誤導(dǎo)致的確定性故障；

b)系統(tǒng)硬/軟件失效導(dǎo)致的確定性故障；

c)編程錯(cuò)誤導(dǎo)致的非確定性故障；

d)系統(tǒng)硬/軟件失效導(dǎo)致的非確定性故障。

本文的目標(biāo)在于檢測(cè)出并行程序的運(yùn)行故障，并將故障原因識(shí)別為上述4種故障類(lèi)型，從而幫助程序員提高在HPC上運(yùn)行和調(diào)試程序的效率。

確定性故障具有確定性和可重復(fù)性，當(dāng)用戶(hù)程序在Slurm上運(yùn)行出錯(cuò)時(shí)，首先檢測(cè)錯(cuò)誤原因是否為確定性故障。當(dāng)程序運(yùn)行出錯(cuò)時(shí)，重新提交程序并且組合使用換節(jié)點(diǎn)不換程序、換程序不換節(jié)點(diǎn)等方法，檢測(cè)出錯(cuò)原因是否為確定性故障。具體思路為：指定首輪節(jié)點(diǎn)，在首輪節(jié)點(diǎn)上運(yùn)行另一種經(jīng)過(guò)驗(yàn)證的程序，如果驗(yàn)證程序出錯(cuò)，可推斷為b；排除首輪節(jié)點(diǎn)，在其他節(jié)點(diǎn)上執(zhí)行該程序，在使用驗(yàn)證程序確認(rèn)新節(jié)點(diǎn)中無(wú)故障的情況下，如果該程序仍然出錯(cuò)，則可推斷為a。

非確定性故障存在隨機(jī)性，且很難通過(guò)1～2次程序運(yùn)行來(lái)復(fù)現(xiàn)和識(shí)別故障原因。通過(guò)采用在不同節(jié)點(diǎn)上多次重復(fù)執(zhí)行程序的方法，在運(yùn)行次數(shù)比較多、得到足夠的運(yùn)行結(jié)果后進(jìn)行判斷。如果在多個(gè)節(jié)點(diǎn)上程序運(yùn)行仍會(huì)出現(xiàn)故障，可推斷為c；如果在不同的節(jié)點(diǎn)上沒(méi)有出現(xiàn)故障，只在特定節(jié)點(diǎn)上出現(xiàn)故障，可推測(cè)為d。

2.2 系統(tǒng)架構(gòu)與實(shí)現(xiàn)

為了實(shí)現(xiàn)并行程序運(yùn)行故障原因識(shí)別系統(tǒng)，本文在Slurm 19.05.2發(fā)行版的基礎(chǔ)上進(jìn)行了擴(kuò)展。擴(kuò)展后的系統(tǒng)架構(gòu)如圖2所示，其中陰影填充的部分為擴(kuò)展的模塊。

圖2 擴(kuò)展后的Slurm架構(gòu)Fig.2 Extended Slurm architecture

為了進(jìn)行故障現(xiàn)象的檢測(cè)和故障原因的識(shí)別，首先在Slurm的主控制進(jìn)程slurmctld中擴(kuò)展了故障檢測(cè)模塊和故障原因識(shí)別模塊，用于程序運(yùn)行故障的檢測(cè)和故障原因的識(shí)別。

同時(shí)在Slurm中擴(kuò)展了三個(gè)用戶(hù)命令，分別是mybatch、mytrigger和myrequeue命令。三個(gè)命令對(duì)應(yīng)功能如表1所示。

表1 實(shí)現(xiàn)的命令列表

基于在Slurm中實(shí)現(xiàn)的命令和模塊，并行程序故障原因識(shí)別的流程為：

步驟1：mybatch命令提交用戶(hù)程序，提交成功后返回作業(yè)編號(hào)。

步驟2：根據(jù)作業(yè)編號(hào)，故障檢測(cè)模塊對(duì)程序和程序所在運(yùn)行節(jié)點(diǎn)進(jìn)行狀態(tài)監(jiān)控。

步驟3：作業(yè)運(yùn)行結(jié)束后，故障檢測(cè)模塊停止監(jiān)控，根據(jù)程序運(yùn)行的結(jié)果進(jìn)行下一步：如果程序運(yùn)行結(jié)果為成功完成、取消、超出內(nèi)存限制、超過(guò)截止時(shí)間四種情況，根據(jù)運(yùn)行結(jié)果可以知道運(yùn)行結(jié)果的原因，結(jié)束故障檢測(cè)，轉(zhuǎn)到步驟5；如果程序是其他運(yùn)行結(jié)果，轉(zhuǎn)到步驟4。

步驟4：如果程序重運(yùn)行次數(shù)少于2次，將上輪節(jié)點(diǎn)加入程序的排除節(jié)點(diǎn)中，重新運(yùn)行程序，同時(shí)指定上輪節(jié)點(diǎn)運(yùn)行驗(yàn)證程序，轉(zhuǎn)到步驟2；如果程序重運(yùn)行次數(shù)大于或等于2次，轉(zhuǎn)到步驟5。

步驟5：故障原因識(shí)別模塊從作業(yè)數(shù)據(jù)庫(kù)中獲取用戶(hù)程序和驗(yàn)證程序的多次運(yùn)行結(jié)果，綜合兩種程序的運(yùn)行結(jié)果，識(shí)別故障的類(lèi)型。

2.3 故障檢測(cè)模塊

在用戶(hù)程序運(yùn)行期間，為了及時(shí)檢測(cè)程序bug或系統(tǒng)硬軟件故障，需要對(duì)程序狀態(tài)和節(jié)點(diǎn)狀態(tài)進(jìn)行監(jiān)控，因此在slurmctld中擴(kuò)展了故障檢測(cè)模塊。故障檢測(cè)模塊的工作流程如圖3所示。

圖3 故障檢測(cè)流程Fig.3 Fault detection flow chart

在程序運(yùn)行期間，每隔一段時(shí)間(預(yù)設(shè)15 s)根據(jù)用戶(hù)的程序編號(hào)檢查程序的狀態(tài)和程序所在節(jié)點(diǎn)的狀態(tài)。如果在程序運(yùn)行期間某個(gè)節(jié)點(diǎn)通過(guò)心跳機(jī)制沒(méi)有響應(yīng)，那么該節(jié)點(diǎn)很可能出現(xiàn)了嚴(yán)重的硬件故障，導(dǎo)致了節(jié)點(diǎn)死機(jī)/崩潰，記錄該節(jié)點(diǎn)存在問(wèn)題，并取消程序的運(yùn)行。

當(dāng)程序結(jié)束運(yùn)行后，需要根據(jù)用戶(hù)程序的運(yùn)行結(jié)果對(duì)程序進(jìn)行處理。當(dāng)程序運(yùn)行結(jié)束后，記錄程序運(yùn)行數(shù)據(jù)，并將運(yùn)行數(shù)據(jù)發(fā)送到故障原因識(shí)別模塊。如果本次程序執(zhí)行是非正常結(jié)束(如失敗、超時(shí)、節(jié)點(diǎn)崩潰)，則把程序本次運(yùn)行的節(jié)點(diǎn)集合加入該程序的排除節(jié)點(diǎn)列表，以使該程序在其他計(jì)算節(jié)點(diǎn)上重新運(yùn)行。然后把該程序放到Slurm作業(yè)隊(duì)列中重新排隊(duì)，并且重新對(duì)該程序的狀態(tài)進(jìn)行監(jiān)控。同時(shí)指定程序當(dāng)次運(yùn)行的節(jié)點(diǎn)集合運(yùn)行驗(yàn)證程序。驗(yàn)證程序?yàn)轭A(yù)先選擇的且沒(méi)有編程故障的程序，驗(yàn)證程序可以在系統(tǒng)中提前運(yùn)行，那么運(yùn)行驗(yàn)證程序只需指定節(jié)點(diǎn)，然后將驗(yàn)證程序重新排隊(duì)運(yùn)行即可。

2.4 故障原因識(shí)別模塊

程序運(yùn)行結(jié)束后，作業(yè)數(shù)據(jù)庫(kù)中的數(shù)據(jù)發(fā)送到故障原因識(shí)別模塊。使用An表示程序第n次運(yùn)行的結(jié)果，Sn表示程序第n次運(yùn)行時(shí)所在節(jié)點(diǎn)集合，Cn表示在Sn上運(yùn)行驗(yàn)證程序的結(jié)果，該模塊的故障原因識(shí)別流程為：

1)如果A1成功，則認(rèn)為程序正常執(zhí)行；

2)如果A1失敗、C1失敗，則認(rèn)為節(jié)點(diǎn)集合S1中發(fā)生了系統(tǒng)硬軟件故障導(dǎo)致的確定性故障；

3)如果A1失敗、C1成功，但A2失敗，說(shuō)明S1正常工作。A2失敗后，還需對(duì)S2增加驗(yàn)證程序的檢驗(yàn)。如果C2成功，說(shuō)明S2沒(méi)有故障，則認(rèn)為用戶(hù)程序有bug，發(fā)生了由編程錯(cuò)誤導(dǎo)致的確定性故障；如果C2失敗，說(shuō)明節(jié)點(diǎn)集合S2中發(fā)生了系統(tǒng)硬軟件的確定性故障。

4)如果A1失敗、C1成功、A2成功，則認(rèn)為存在非確定性的故障。但是非確定性故障的具體類(lèi)型不確定，需要進(jìn)一步識(shí)別。

進(jìn)一步識(shí)別需要手動(dòng)執(zhí)行myrequeue和mytrigger命令，重提交并監(jiān)控用戶(hù)程序，通過(guò)比較作業(yè)的運(yùn)行結(jié)果和輸出結(jié)果，判斷作業(yè)是否出錯(cuò)。如果出錯(cuò)，則在節(jié)點(diǎn)上運(yùn)行驗(yàn)證程序，綜合在不同節(jié)點(diǎn)上程序和驗(yàn)證程序的運(yùn)行結(jié)果。如果在多個(gè)節(jié)點(diǎn)組合上程序運(yùn)行出錯(cuò)或者輸出結(jié)果不同，可推斷為用戶(hù)程序有bug；如果用戶(hù)程序在不同的節(jié)點(diǎn)組合上運(yùn)行均成功，驗(yàn)證程序也正常運(yùn)行，可推測(cè)為S1中存在非確定性的硬件故障。

3 實(shí)驗(yàn)測(cè)試

3.1 實(shí)驗(yàn)環(huán)境與測(cè)試方法

實(shí)驗(yàn)部署在4臺(tái)服務(wù)器(b1～b4)搭建的小規(guī)模機(jī)群中，其中b1是小規(guī)模機(jī)群的Slurm控制節(jié)點(diǎn)。機(jī)群中文件共享的軟件是網(wǎng)絡(luò)文件系統(tǒng)(network file system, NFS)，b3是NFS服務(wù)器。應(yīng)用程序采用高性能計(jì)算基準(zhǔn)測(cè)試程序NPB[5]。由于實(shí)驗(yàn)環(huán)境的限制，選擇NPB中的5個(gè)程序——IS、EP、LU、BT和SP，測(cè)試規(guī)模使用C級(jí)。表2列出了小規(guī)模測(cè)試集群的環(huán)境配置參數(shù)。

表2 測(cè)試環(huán)境配置

實(shí)驗(yàn)主要分為兩個(gè)部分：準(zhǔn)確性測(cè)試和運(yùn)行開(kāi)銷(xiāo)測(cè)試。其中準(zhǔn)確性測(cè)試包括檢測(cè)準(zhǔn)確率、識(shí)別準(zhǔn)確率和識(shí)別延遲的測(cè)試；運(yùn)行開(kāi)銷(xiāo)測(cè)試主要針對(duì)系統(tǒng)對(duì)程序執(zhí)行的影響。

3.2 準(zhǔn)確性測(cè)試

在實(shí)驗(yàn)中，設(shè)置的評(píng)估指標(biāo)為：

1)故障檢出次數(shù)(fault detection times, FDT)：故障注入后，故障檢測(cè)模塊成功檢測(cè)出來(lái)的次數(shù)；

2)故障識(shí)別次數(shù)(fault identification times, FIT)：注入的故障檢測(cè)出來(lái)后，故障原因識(shí)別模塊正確識(shí)別出故障原因的次數(shù)；

3)故障識(shí)別延遲：故障注入后，到故障原因識(shí)別模塊識(shí)別出故障原因所需要的時(shí)間。

針對(duì)程序自身bug導(dǎo)致的故障，在MPI并行程序源代碼中加入MPI_Recv阻塞死鎖、while無(wú)限循環(huán)、堆棧溢出等問(wèn)題代碼。實(shí)驗(yàn)中程序的最大運(yùn)行時(shí)間為10 min。實(shí)驗(yàn)結(jié)果如表3所示。通過(guò)實(shí)驗(yàn)發(fā)現(xiàn)，死鎖和while無(wú)限循環(huán)等bug會(huì)導(dǎo)致程序運(yùn)行超時(shí)，無(wú)限遞歸導(dǎo)致的堆棧溢出等錯(cuò)誤會(huì)導(dǎo)致程序運(yùn)行崩潰。程序自身的bug會(huì)導(dǎo)致程序在不同節(jié)點(diǎn)上的多次運(yùn)行都失敗。從表3的實(shí)驗(yàn)結(jié)果可以看出該系統(tǒng)可以有效地檢測(cè)和識(shí)別程序自身的bug。

表3 程序自身bug實(shí)驗(yàn)結(jié)果

文獻(xiàn)[6]實(shí)現(xiàn)了HPC-SFI[6]，可以有效地在一個(gè)HPC系統(tǒng)中注入三種類(lèi)型的系統(tǒng)故障，分別是節(jié)點(diǎn)內(nèi)故障、互連網(wǎng)絡(luò)故障和存儲(chǔ)/并行文件系統(tǒng)故障。本文使用HPC-SFI來(lái)隨機(jī)注入節(jié)點(diǎn)內(nèi)處理器故障、互連網(wǎng)絡(luò)故障和整個(gè)節(jié)點(diǎn)的故障。故障注入的實(shí)驗(yàn)結(jié)果如表4所示。使用的測(cè)試程序是NPB的SP.C.2，驗(yàn)證程序?yàn)锽T.C.2，設(shè)置最大程序運(yùn)行時(shí)間均為10 min。

表4 HPC-SFI硬件故障注入實(shí)驗(yàn)結(jié)果

注入的互連網(wǎng)絡(luò)故障和整個(gè)節(jié)點(diǎn)的故障，會(huì)導(dǎo)致計(jì)算節(jié)點(diǎn)與控制節(jié)點(diǎn)之間的通信中斷，可以很快被故障檢測(cè)模塊發(fā)現(xiàn)；處理器故障導(dǎo)致作業(yè)運(yùn)行時(shí)異常崩潰，作業(yè)運(yùn)行提前結(jié)束。通過(guò)表4的實(shí)驗(yàn)結(jié)果可以得出，本系統(tǒng)能夠100%檢測(cè)和識(shí)別HPC-SFI注入的硬件故障。

從表3和表4的平均識(shí)別延遲可以看出，故障原因識(shí)別延遲與故障類(lèi)型存在一定的聯(lián)系。即在相同的測(cè)試程序下，平均故障延遲因故障的不同而不同。其中的原因是，故障檢測(cè)模塊需要至少運(yùn)行2次用戶(hù)程序和一次驗(yàn)證程序，同時(shí)在Slurm中重排隊(duì)的作業(yè)需要等待2 min才能再次被分配資源開(kāi)始運(yùn)行。所以當(dāng)故障導(dǎo)致程序運(yùn)行超時(shí)時(shí)，程序運(yùn)行了最大運(yùn)行時(shí)間后因Slurm超時(shí)機(jī)制而中止，平均識(shí)別延遲會(huì)較高；當(dāng)故障導(dǎo)致作業(yè)運(yùn)行崩潰或節(jié)點(diǎn)崩潰時(shí)，作業(yè)運(yùn)行因故障提前中止，平均識(shí)別延遲較低。

潛在的故障是指一個(gè)故障在發(fā)生之前的潛在行為，潛在的故障是普遍存在的。許多節(jié)點(diǎn)故障不是突然變化的結(jié)果，而是長(zhǎng)期性能下降(軟件老化)的結(jié)果。在潛在故障存在期間，節(jié)點(diǎn)的性能已經(jīng)出現(xiàn)了偏離，比如計(jì)算速度慢、計(jì)算出錯(cuò)率高等問(wèn)題，但節(jié)點(diǎn)尚未失敗。超過(guò)20%的機(jī)器故障都是由這些潛在的故障引起的[7]。

在實(shí)驗(yàn)中分別模擬互連網(wǎng)絡(luò)丟包、CPU運(yùn)行變慢等潛在硬件故障。在模擬潛在故障的實(shí)驗(yàn)中，使用的實(shí)驗(yàn)程序是NPB的SP.C.4，最大運(yùn)行時(shí)間為10 min；驗(yàn)證程序?yàn)锽T.C.4，最大運(yùn)行時(shí)間5 min。

通過(guò)Linux內(nèi)核的流量控制器Traffic Control對(duì)網(wǎng)卡發(fā)送的數(shù)據(jù)包進(jìn)行限制，通過(guò)設(shè)置不同的丟包率模擬HPC系統(tǒng)中互連網(wǎng)絡(luò)的丟包、網(wǎng)絡(luò)中斷等故障。本文分別在丟包率為1%、5%和10%下運(yùn)行了10次實(shí)驗(yàn)。實(shí)驗(yàn)結(jié)果如表5所示。

表5 網(wǎng)絡(luò)丟包故障實(shí)驗(yàn)結(jié)果

本文使用開(kāi)源工具cpulimit[8]限制用戶(hù)程序的某個(gè)進(jìn)程的CPU使用率，從而模擬CPU速度異常變慢的故障。在程序運(yùn)行后隨機(jī)選擇一個(gè)節(jié)點(diǎn)將SP程序的進(jìn)程CPU使用率設(shè)置在90%、70%、50%，各運(yùn)行了10次。實(shí)驗(yàn)結(jié)果如表6所示。

表6 CPU故障實(shí)驗(yàn)結(jié)果

在表5和表6的實(shí)驗(yàn)中，總體的故障識(shí)別準(zhǔn)確率是66.7%。通過(guò)模擬不同程度的潛在硬件故障，發(fā)現(xiàn)不同程度的潛在硬件故障對(duì)程序的影響結(jié)果不同。只有當(dāng)故障嚴(yán)重程度超過(guò)一定程序時(shí)，導(dǎo)致作業(yè)運(yùn)行超時(shí)，本系統(tǒng)才能探測(cè)出硬件故障。如果故障只是輕微或者瞬間發(fā)生的故障，系統(tǒng)很有可能探測(cè)不出來(lái)。

此外，在網(wǎng)絡(luò)丟包實(shí)驗(yàn)中發(fā)現(xiàn)，設(shè)置的程序最大運(yùn)行時(shí)間會(huì)影響故障識(shí)別的準(zhǔn)確率。如果將實(shí)驗(yàn)程序SP.C.4的最大運(yùn)行時(shí)間設(shè)置為20 min，當(dāng)丟包率為5%時(shí)，此時(shí)10次實(shí)驗(yàn)程序的平均運(yùn)行時(shí)間為15 min 43 s，程序均運(yùn)行成功，將檢測(cè)不到故障。用戶(hù)對(duì)其程序的運(yùn)行時(shí)間估計(jì)得越準(zhǔn)確，并行程序故障原因識(shí)別系統(tǒng)的準(zhǔn)確率越高。

3.3 運(yùn)行開(kāi)銷(xiāo)測(cè)試

在運(yùn)行正常的情況下，對(duì)實(shí)驗(yàn)使用的5個(gè)NPB基準(zhǔn)程序分別運(yùn)行20次，其中10次為在Slurm的sbatch命令進(jìn)行提交，另外10次為在擴(kuò)展后的Slurm中使用mybatch命令進(jìn)行提交。當(dāng)MPI并行進(jìn)程數(shù)為2和4時(shí)，各基準(zhǔn)程序的平均運(yùn)行時(shí)間如圖4和圖5所示。

圖4 進(jìn)程數(shù)為2時(shí)基準(zhǔn)程序平均運(yùn)行時(shí)間Fig.4 Average running time of benchmark program when the number of processes is 2

圖5 進(jìn)程數(shù)為4時(shí)基準(zhǔn)程序平均運(yùn)行時(shí)間Fig.5 Average running time of benchmark program when the number of processes is 4

從圖4和圖5的實(shí)驗(yàn)結(jié)果中可以看出，在程序不出現(xiàn)故障的情況下，系統(tǒng)運(yùn)行開(kāi)銷(xiāo)保持穩(wěn)定在-9.1%到3.8%之間變化，并且不會(huì)隨著基準(zhǔn)程序的類(lèi)型和進(jìn)程數(shù)發(fā)生變化。這是因?yàn)樵诔绦蛘＿\(yùn)行期間，故障檢測(cè)模塊主要開(kāi)銷(xiāo)在于定時(shí)對(duì)作業(yè)狀態(tài)和節(jié)點(diǎn)狀態(tài)進(jìn)行輪詢(xún)。輪詢(xún)主要依靠slurmctld和slurmd之間的通信，不會(huì)影響作業(yè)在計(jì)算節(jié)點(diǎn)上的運(yùn)行。這意味著并行程序故障原因識(shí)別系統(tǒng)的開(kāi)銷(xiāo)很小，不被程序類(lèi)型和程序運(yùn)行規(guī)模所影響，擴(kuò)展性好。

4 相關(guān)工作

雖然已經(jīng)開(kāi)發(fā)了許多方法和工具，但調(diào)試大型并行程序仍然是一個(gè)艱巨的問(wèn)題。交互性調(diào)試(例如TotalView[9]、Arm DDT[10])是一種傳統(tǒng)方法，通過(guò)允許在一個(gè)窗口中的許多進(jìn)程和線程同時(shí)進(jìn)行調(diào)試，可以在一個(gè)單獨(dú)的線程內(nèi)或任意進(jìn)程或線程的組合內(nèi)對(duì)代碼逐行執(zhí)行運(yùn)行、步進(jìn)和終止，來(lái)完成對(duì)程序執(zhí)行的完全控制。但是這種方法不能自動(dòng)檢測(cè)程序故障。此外，在運(yùn)行大規(guī)模程序時(shí)，人工分析數(shù)以萬(wàn)計(jì)的進(jìn)程數(shù)據(jù)耗時(shí)耗力。一些調(diào)試工具在執(zhí)行期間收集各種程序狀態(tài)，并將其提供給程序員以進(jìn)行后期分析。例如，堆棧跟蹤分析工具(STAT[11])從并行程序的所有進(jìn)程中收集堆棧跟蹤。通過(guò)這些跟蹤，程序員可以生成調(diào)用圖前綴樹(shù)，以前綴樹(shù)的形式匯編應(yīng)用程序的行為。但是，STAT不適合普通用戶(hù)進(jìn)行調(diào)試，因?yàn)镾TAT依賴(lài)于許多軟件，這些軟件需要系統(tǒng)管理員預(yù)先安裝并且超出普通用戶(hù)的權(quán)限；STAT無(wú)法自動(dòng)識(shí)別程序故障，需要人工干預(yù)，調(diào)試運(yùn)行時(shí)間較長(zhǎng)；STAT沒(méi)有考慮程序調(diào)試期間硬件故障的影響，因此無(wú)法在發(fā)生故障時(shí)區(qū)分硬件/軟件故障和程序錯(cuò)誤。

為了簡(jiǎn)化大規(guī)模執(zhí)行下并行程序確定性重放的復(fù)雜性，Guo等[12]設(shè)計(jì)實(shí)現(xiàn)了一種使用兩個(gè)節(jié)點(diǎn)重新運(yùn)行大規(guī)模MPI并行程序的系統(tǒng)，大大減少了重放所需的節(jié)點(diǎn)數(shù)。并行程序的一個(gè)進(jìn)程在計(jì)算節(jié)點(diǎn)上運(yùn)行時(shí)，需要與其他進(jìn)程通信，但是它與之通信的進(jìn)程可能沒(méi)有在運(yùn)行。為了建立一個(gè)使重新運(yùn)行的進(jìn)程正常執(zhí)行的環(huán)境，需要在計(jì)算節(jié)點(diǎn)上模擬MPI通信環(huán)境，這需要比較長(zhǎng)的時(shí)間來(lái)完成。Zhai等[13]根據(jù)并行程序中許多進(jìn)程具有相似的計(jì)算模式這一特點(diǎn)，首先使用層次聚類(lèi)方法對(duì)運(yùn)行程序的進(jìn)程進(jìn)行聚類(lèi)，然后從每個(gè)進(jìn)程聚簇中選擇一個(gè)具有代表性的進(jìn)程進(jìn)行重放。這種“代表性”重放的方法減少了重放的進(jìn)程數(shù)量，從而顯著減少重放所需的時(shí)間。但是這種方法只能用來(lái)預(yù)測(cè)HPC的性能，不能用于故障檢測(cè)。同時(shí)他們的方法都忽略了大規(guī)模并行程序調(diào)試中硬件故障的影響。本文方法可以自動(dòng)識(shí)別程序故障，并進(jìn)一步區(qū)分硬件故障和程序錯(cuò)誤故障，以進(jìn)行更好的調(diào)試。

目前針對(duì)高性能計(jì)算系統(tǒng)故障的研究熱點(diǎn)是基于系統(tǒng)日志和傳感器數(shù)據(jù)的軟件/硬件故障檢測(cè)。基于特殊領(lǐng)域的高性能計(jì)算機(jī)群運(yùn)行的作業(yè)具有相對(duì)穩(wěn)定的運(yùn)行行為，Wu等[14]提出了一種基于異常活動(dòng)分析的高性能系統(tǒng)運(yùn)行時(shí)失效檢測(cè)方法，但這種方法只能針對(duì)具體領(lǐng)域內(nèi)的重復(fù)性作業(yè)，具有很強(qiáng)的局限性；Gabel等[7]相同的時(shí)間下在多臺(tái)配置相同的機(jī)器上執(zhí)行相同的任務(wù)，通過(guò)傳感器獲取機(jī)器的運(yùn)行性能，如果一臺(tái)機(jī)器的性能與其他機(jī)器顯著不同，就會(huì)被標(biāo)記為可疑，即懷疑該節(jié)點(diǎn)存在潛在故障；Ghiasvand等[15]定時(shí)采集系統(tǒng)日志，得到系統(tǒng)日志生成頻率，如果某個(gè)節(jié)點(diǎn)日志生成頻率與大多數(shù)節(jié)點(diǎn)的偏差超過(guò)一定閾值，則認(rèn)為該節(jié)點(diǎn)出現(xiàn)了故障。由于傳感器數(shù)據(jù)與系統(tǒng)日志有固定的格式和規(guī)律，是可以根據(jù)關(guān)聯(lián)規(guī)則進(jìn)行挖掘的文本，因此機(jī)器學(xué)習(xí)也是用于高性能計(jì)算機(jī)群故障探測(cè)主要方法之一[16-17]。但是很多時(shí)候作業(yè)在HPC上運(yùn)行時(shí)，運(yùn)行速度與用戶(hù)預(yù)期相差較大；同時(shí)因?yàn)楹芏嘧鳂I(yè)是首次提交，沒(méi)有作業(yè)運(yùn)行的數(shù)據(jù)記錄，不能依靠系統(tǒng)日志和傳感器數(shù)據(jù)來(lái)檢測(cè)故障。本文的系統(tǒng)不依賴(lài)于系統(tǒng)日志和傳感器數(shù)據(jù)，根據(jù)用戶(hù)程序與驗(yàn)證程序的運(yùn)行結(jié)果可以區(qū)分程序運(yùn)行錯(cuò)誤與節(jié)點(diǎn)的硬軟件故障。

5 結(jié)論

并行程序自身存在的編程bug會(huì)導(dǎo)致程序運(yùn)行出錯(cuò)，另外，高性能計(jì)算系統(tǒng)硬軟件故障概率的增加導(dǎo)致并行程序在運(yùn)行時(shí)出錯(cuò)的概率隨之增加。本文從普通權(quán)限的編程人員/用戶(hù)角度，提出一種在HPC上程序調(diào)試失效時(shí)識(shí)別故障原因的思路。通過(guò)對(duì)作業(yè)管理系統(tǒng)Slurm進(jìn)行擴(kuò)展，監(jiān)控作業(yè)和節(jié)點(diǎn)狀態(tài)，指定節(jié)點(diǎn)和排除節(jié)點(diǎn)重提交程序。根據(jù)程序多次運(yùn)行結(jié)果，識(shí)別故障原因的類(lèi)別，從而提高程序員在HPC上識(shí)別編程錯(cuò)誤或系統(tǒng)硬軟件故障的效率。實(shí)驗(yàn)表明，該系統(tǒng)具有較低的開(kāi)銷(xiāo)和較高的準(zhǔn)確率。