孫震宇,石京燕,孫功星,杜 然,姜曉巍,鄒佳恒,譚宏楠

(1.中國科學(xué)院高能物理研究所,北京 100049; 2.中國科學(xué)院大學(xué) 物理科學(xué)學(xué)院,北京 100049)

0 概述

高能物理是研究微觀物質(zhì)世界的基本粒子組成及其相互作用的學(xué)科?，F(xiàn)代高能物理實(shí)驗(yàn)產(chǎn)生海量實(shí)驗(yàn)數(shù)據(jù),巨大的實(shí)驗(yàn)數(shù)據(jù)量可以提高物理結(jié)果的統(tǒng)計精度,有助于尋找稀有反應(yīng)過程。高能物理數(shù)據(jù)處理主要通過在計算集群上運(yùn)行大量作業(yè),每個作業(yè)分析處理一個或一批數(shù)據(jù)文件。目前高能物理計算軟件框架仍以串行計算為主,通過同時運(yùn)行大量作業(yè),分別處理不同數(shù)據(jù)文件達(dá)到并行處理的效果。高能物理計算集群管理及作業(yè)調(diào)度軟件以集中式作業(yè)調(diào)度系統(tǒng)為主,其中常用的開源作業(yè)調(diào)度軟件包括PBS[1]、SLURM[2]和HTCondor[3]等。

中國科學(xué)院高能物理研究所計算中心運(yùn)行并管理著一套本地高通量計算(High Throughput Computing,HTC)集群,以及一套高性能計算(High Performance Computing,HPC)集群。HTC集群具有13 000個CPU核心,通過HTCondor實(shí)現(xiàn)資源管理以及作業(yè)調(diào)度,主要用于處理北京譜儀[4]、大亞灣中微子實(shí)驗(yàn)[5]、羊八井宇宙線實(shí)驗(yàn)[6]、江門中微子實(shí)驗(yàn)[7]、高海拔宇宙線觀測站[8]等大型高能物理實(shí)驗(yàn)的串行計算作業(yè)。HPC集群具有4 000個CPU核心、80塊Tesla V100 GPU卡,采用SLURM實(shí)現(xiàn)資源管理以及作業(yè)調(diào)度,主要用于處理BES分波分析、JUNO、格點(diǎn)量子色動力學(xué)、環(huán)形正負(fù)電子對撞機(jī)、高能同步輻射光源等實(shí)驗(yàn)的并行計算作業(yè)。

由于各個并行作業(yè)的并行度大小不一,目前計算中心的HPC集群的整體資源利用率僅為50%左右,而HTC集群利用率長期處于飽和狀態(tài)且有大量作業(yè)排隊(duì)等待,因此在不影響并行作業(yè)正常調(diào)度的前提下,遷移HTC作業(yè)到HPC集群上運(yùn)行是計算中心需要解決的一個重要問題。

本文設(shè)計并開發(fā)雙層作業(yè)調(diào)度系統(tǒng)以及配套的用戶作業(yè)管理工具包。雙層調(diào)度系統(tǒng)可以快速接收海量的串行或并行作業(yè),以插件形式支持多種調(diào)度策略,實(shí)現(xiàn)對資源和作業(yè)的細(xì)粒度管理,并且通過多個作業(yè)隊(duì)列和特定作業(yè)調(diào)度算法保證各實(shí)驗(yàn)組對計算資源的公平使用。

1 相關(guān)研究

高能所計算中心自2001年開始一直使用開源軟件TORQUE[9]管理集群資源,并借助Maui[10]實(shí)現(xiàn)作業(yè)調(diào)度。高能所TORQUE計算集群中的計算節(jié)點(diǎn)分屬于不同高能物理實(shí)驗(yàn),隸屬于各實(shí)驗(yàn)的計算節(jié)點(diǎn)僅運(yùn)行本實(shí)驗(yàn)的計算作業(yè),各實(shí)驗(yàn)有自己的專用作業(yè)隊(duì)列。為保證實(shí)驗(yàn)內(nèi)各用戶之間的公平性,調(diào)度器還對單用戶可以同時運(yùn)行的最大作業(yè)數(shù)進(jìn)行限制。然而在實(shí)際運(yùn)行過程中,由于各實(shí)驗(yàn)對計算需求的峰谷時段不同,計算集群的整體資源利用率僅為50%～60%。此外,TORQUE/Maui還存在對GPU計算的支持不足、作業(yè)數(shù)量過大時調(diào)度性能下降等問題。

高能所計算中心自2015年開始逐步將計算資源從TORQUE/Maui集群向HTCondor集群遷移。HTCondor[3]基于分類廣告(ClassAd)及匹配操作的調(diào)度模式[11]使其可以高效地調(diào)度大量高通量計算作業(yè)。文獻(xiàn)[12]展示了其調(diào)度管理16 000個作業(yè)同時運(yùn)行的能力。因此,HTCondor被廣泛應(yīng)用于高能物理計算[13]、地理信息系統(tǒng)[14]、遙感數(shù)據(jù)處理[15-17]等領(lǐng)域。高能所計算中心將所有實(shí)驗(yàn)計算資源組成共享資源池,供各個實(shí)驗(yàn)錯峰共享使用,這使得計算集群的整體資源利用率提高到90%以上。然而,HTCondor調(diào)度算法單一,且沒有作業(yè)隊(duì)列的概念,難以提供類似PBS的資源細(xì)粒度分配和高級作業(yè)管理功能。此外,HTCondor架構(gòu)不具備中心管理功能,難以做到對計算節(jié)點(diǎn)的統(tǒng)一管理。另外,HTCondor對MPI并行作業(yè)的調(diào)度效率較低,在串并行作業(yè)混合排隊(duì)時,該問題表現(xiàn)得更加突出。

隨著科學(xué)技術(shù)的發(fā)展,高能物理數(shù)據(jù)處理正在由單進(jìn)程處理向并行計算模式轉(zhuǎn)換。為此,計算中心建立了HPC計算集群,采用SLURM實(shí)現(xiàn)資源管理以及作業(yè)調(diào)度。SLURM具有大量的調(diào)度算法,對于并行作業(yè)的資源分配有較高的效率,因此被應(yīng)用于天河2[18]超級計算機(jī)以及深度學(xué)習(xí)[19]、計算機(jī)輔助工程[20]等典型的高性能計算場景中。但經(jīng)測試SLURM在處理大量HTC短作業(yè)時調(diào)度效率下降嚴(yán)重,無法應(yīng)對萬級CPU核計算集群上的萬級串行作業(yè)資源分配。因此,計算中心無法借助單一的開源作業(yè)調(diào)度軟件來管理整個計算集群,形成了HTC及HPC作業(yè)各有一個計算集群的現(xiàn)狀。

文獻(xiàn)[21]著手解決將HTC作業(yè)遷移到HPC集群上運(yùn)行的問題,但其提出的解決方案需要用戶設(shè)置作業(yè)屬性以允許作業(yè)遷移,對用戶不完全透明。文獻(xiàn)[22]中的CMS實(shí)驗(yàn)選用GlideinWMS[22]作為其計算資源供應(yīng)層,將分布在世界各地的多級站點(diǎn)組成一個計算資源池。CMS預(yù)計其Run 2期間需要約20萬CPU核的計算規(guī)模[23],并通過調(diào)度器并行化、單核作業(yè)轉(zhuǎn)換為多核作業(yè)等手段實(shí)現(xiàn)了對20萬CPU核的有效管理[24]。然而上述工作并未涉及到基于計算資源擁有份額的公平性問題以及對計算節(jié)點(diǎn)的統(tǒng)一管理問題。文獻(xiàn)[25]實(shí)現(xiàn)了類似GlideinWMS的作業(yè)排隊(duì)、Agent分發(fā)以及作業(yè)拉取機(jī)制。文獻(xiàn)[26]使站點(diǎn)通過Mesos[27]提供計算資源給HTCondor集群,但兩者同樣側(cè)重于對異地計算資源的利用。

2 雙層作業(yè)調(diào)度系統(tǒng)架構(gòu)設(shè)計

高能所計算平臺對計算作業(yè)調(diào)度的需求為:

1)提供用戶單一作業(yè)管理功能,即用戶通過單一作業(yè)工具提交、查詢、管理自己的串并行作業(yè)。

2)保證大并行度作業(yè)的資源有效分配,同時實(shí)現(xiàn)對大規(guī)模HTC作業(yè)的高效調(diào)度。

3)提供多種作業(yè)隊(duì)列,以滿足不同實(shí)驗(yàn)用戶的多種計算需求。

4)保證實(shí)驗(yàn)組間資源使用公平性,即各個實(shí)驗(yàn)組使用的資源數(shù)量與其擁有的資源數(shù)量比例相當(dāng)。

5)充分利用空閑計算資源,提高整體資源利用率,降低作業(yè)排隊(duì)時間。

本文設(shè)計的雙層作業(yè)調(diào)度系統(tǒng)采用分治的思想,將本地的大規(guī)模異構(gòu)計算集群拆分為一個或多個同構(gòu)或異構(gòu)子集群,每個子集群分別由HTCondor或SLURM等作業(yè)調(diào)度軟件管理。同時,本文在子集群的基礎(chǔ)上增加了一個作業(yè)管理層,用來實(shí)現(xiàn)作業(yè)隊(duì)列設(shè)置以及調(diào)度算法的擴(kuò)展,同時可兼顧用戶和隊(duì)列的優(yōu)先級,以及HPC作業(yè)對計算資源的特殊需求。雙層作業(yè)調(diào)度系統(tǒng)充分利用HTCondor自有的高效調(diào)度性能以及SLURM對于并行作業(yè)管理的優(yōu)勢,彌補(bǔ)了HTCondor調(diào)度算法簡單、功能不全以及SLURM面對大量排隊(duì)作業(yè)性能下降的問題。

雙層作業(yè)調(diào)度系統(tǒng)整體架構(gòu)如圖1所示,由作業(yè)管理層和作業(yè)執(zhí)行層組成。上層為作業(yè)管理層,包括作業(yè)管理器、資源狀態(tài)收集模塊、作業(yè)調(diào)度器、作業(yè)提交模塊、作業(yè)監(jiān)視模塊等,負(fù)責(zé)向用戶提供統(tǒng)一作業(yè)管理接口,建立作業(yè)調(diào)度隊(duì)列以及實(shí)現(xiàn)作業(yè)一級調(diào)度。作業(yè)管理器接收用戶提交的計算作業(yè),并維護(hù)作業(yè)隊(duì)列。作業(yè)調(diào)度器根據(jù)系統(tǒng)管理員指定的調(diào)度算法,將用戶作業(yè)在合適的時間提交到作業(yè)執(zhí)行層。作業(yè)調(diào)度算法保證作業(yè)一旦被提交到作業(yè)執(zhí)行層,將被立即執(zhí)行。作業(yè)執(zhí)行層上長期保持沒有或只有少量作業(yè)排隊(duì)的狀態(tài)。

圖1 雙層作業(yè)調(diào)度系統(tǒng)整體架構(gòu)Fig.1 Overall architecture of the dual layer job scheduling system

下層為作業(yè)執(zhí)行層,由一個或多個HTCondor、SLURM等作業(yè)調(diào)度軟件構(gòu)成,分別管理計算集群內(nèi)的一部分計算資源,相當(dāng)于在邏輯上將整個計算集群分割為一個或多個子集群。作業(yè)執(zhí)行層主要負(fù)責(zé)作業(yè)在計算節(jié)點(diǎn)上的啟動、狀態(tài)監(jiān)視、文件輸入/輸出等工作。

用戶提交作業(yè)到作業(yè)管理器,作業(yè)信息被存儲到作業(yè)管理器的數(shù)據(jù)庫中。資源狀態(tài)收集模塊定期采集作業(yè)執(zhí)行層的各個子集群的資源信息,并存儲于資源狀態(tài)數(shù)據(jù)庫。作業(yè)調(diào)度器根據(jù)設(shè)定的作業(yè)調(diào)度算法,為排隊(duì)作業(yè)計算優(yōu)先級,再按優(yōu)先級為作業(yè)指定當(dāng)前可用計算資源。作業(yè)管理器根據(jù)作業(yè)調(diào)度器的指令調(diào)用作業(yè)提交模塊,向作業(yè)執(zhí)行層提交作業(yè)。作業(yè)監(jiān)視模塊監(jiān)視每個作業(yè)的運(yùn)行狀態(tài),并反饋給作業(yè)管理器。

作業(yè)管理器按統(tǒng)一標(biāo)準(zhǔn)格式接收各種不同類型的計算作業(yè),再根據(jù)作業(yè)需求分別提交到作業(yè)執(zhí)行層的不同子集群。這樣的設(shè)計使得雙層作業(yè)調(diào)度系統(tǒng)可以在作業(yè)執(zhí)行層靈活增加不同的作業(yè)子集群,并對用戶透明,用戶作業(yè)腳本及提交作業(yè)命令保持不變。資源狀態(tài)收集、作業(yè)提交、作業(yè)監(jiān)視等模塊通過調(diào)用各個子計算集群自有的API或命令行接口實(shí)現(xiàn),但它們與作業(yè)調(diào)度器的API接口格式定義固定不變。這樣的設(shè)計方案保證了作業(yè)管理層與作業(yè)執(zhí)行層之間的松耦合性。

3 作業(yè)管理層設(shè)計及實(shí)現(xiàn)

3.1 各模塊對外提供的接口

高能物理計算領(lǐng)域的通常作法是用戶通過命令行接口實(shí)現(xiàn)作業(yè)提交查詢等操作,因此本文開發(fā)了基于命令行的作業(yè)管理工具包。例如,用戶somebody向作業(yè)管理器提交作業(yè)的命令如下:

job_submit_client/path/test.sh

該命令的第一個參數(shù)指定了作業(yè)腳本的位置,即/path/test.sh。在作業(yè)成功提交后,命令行接口向用戶返回的信息如下:

Successfully submitted 1 job(s):44071

其中,44071是服務(wù)端為該作業(yè)分配的ID編號。

作業(yè)管理層的各模塊對外提供形似RESTful API的TCP接口,上述命令行接口是對TCP接口的封裝?？蛻舳送ㄟ^TCP接口向服務(wù)器發(fā)出的查詢請求和收到的回復(fù)都是JSON格式的字典類型變量,請求包含method、path等鍵值對,而回復(fù)包含status、content等鍵值對。上述somebody用戶通過命令行向作業(yè)管理器提交作業(yè)時,客戶端實(shí)際發(fā)出的內(nèi)容如下:

{"method":"POST",

"path":"/jobs",

"user":"somebody",

"user_group":"somebody",

"body":[{"input_path":"/path/test.sh",

"exp_group":"somebody",

"req_cpu":1,

"req_preempt":0}]}

其中,body中的input_path指定了作業(yè)腳本的位置,即/path/test.sh,而服務(wù)端回復(fù)給客戶端的內(nèi)容如下:

{′status′:202,

′comment′:′Accepted′,

′content′:[44071]}

其中,44071是服務(wù)端為該作業(yè)分配的ID編號。

3.2 基于Eventlet的基本框架

為達(dá)到快速高效的作業(yè)調(diào)度目標(biāo),本文將圖1中的隊(duì)列數(shù)據(jù)庫和資源狀態(tài)數(shù)據(jù)庫均存放在內(nèi)存中。計算作業(yè)和計算資源的信息均為高度結(jié)構(gòu)化信息,如果使用Redis等NoSQL內(nèi)存數(shù)據(jù)庫在信息匹配時性能較差,則選用SQLite內(nèi)存數(shù)據(jù)庫存儲作業(yè)信息和資源狀態(tài)。SQLite是一種嵌入式SQL數(shù)據(jù)庫,可以像傳統(tǒng)數(shù)據(jù)庫一樣將數(shù)據(jù)完全存儲在磁盤上,還可以將整個數(shù)據(jù)庫建立在內(nèi)存中?；趦?nèi)存的SQLite數(shù)據(jù)庫能夠提供優(yōu)于傳統(tǒng)磁盤數(shù)據(jù)庫的訪問性能,同時兼顧SQL數(shù)據(jù)庫結(jié)構(gòu)化數(shù)據(jù)表的特點(diǎn),更易于開發(fā)及管理。

選用SQLite內(nèi)存數(shù)據(jù)庫要求作業(yè)管理層中的每個組件都需在同一進(jìn)程中具備以下功能:

1)維護(hù)一個SQLite嵌入式內(nèi)存數(shù)據(jù)庫。

2)對外提供服務(wù)接口,響應(yīng)系統(tǒng)管理員、用戶、作業(yè)調(diào)度器及作業(yè)監(jiān)視模塊的請求,并對數(shù)據(jù)庫進(jìn)行相應(yīng)的插入、刪除、修改、查詢等操作。例如,查詢數(shù)據(jù)庫中某個用戶的排隊(duì)信息,或者更新某個作業(yè)的運(yùn)行狀態(tài)等。

3)作為作業(yè)執(zhí)行層或作業(yè)管理層內(nèi)其他組件的客戶端,定期采集作業(yè)執(zhí)行層中資源及作業(yè)狀態(tài)信息并實(shí)時更新相應(yīng)數(shù)據(jù)庫,以保證數(shù)據(jù)庫內(nèi)數(shù)據(jù)的實(shí)時性。例如查詢SLURM集群的空閑資源信息,或者查詢HTCondor集群的歷史作業(yè)信息等。

本文采用協(xié)程(coroutine)模型實(shí)現(xiàn)上述功能,將請求響應(yīng)部分和客戶端操作部分分別編寫為同一進(jìn)程中的不同協(xié)程,使兩者運(yùn)行時互不阻塞,同時SQLite數(shù)據(jù)庫以全局對象的形式供上述協(xié)程訪問。

本文為作業(yè)管理層的各模塊設(shè)計如圖2所示的基本框架。Python具有海量的第三方擴(kuò)展包(Package),且易于編碼,系統(tǒng)選擇Python作為編程語言。Eventlet是Python下實(shí)現(xiàn)協(xié)程模型的框架,被應(yīng)用于Openstack等大型開源項(xiàng)目的開發(fā),其性能與Gevent、Twisted等類似框架基本相同,因此選用Eventlet軟件包實(shí)現(xiàn)各協(xié)程之間的并發(fā)。SQLAlchemy是Python下訪問SQL數(shù)據(jù)庫的框架,用來訪問包含MySQL、SQLite在內(nèi)的多種SQL數(shù)據(jù)庫,同時實(shí)現(xiàn)了對象關(guān)系映射(Object Relational Mapping,ORM),將對SQL數(shù)據(jù)行的操作轉(zhuǎn)化為對Python對象的操作,避免手工書寫SQL語句帶來的兼容性問題及安全隱患,因此選用SQLAlchemy包作為SQLite數(shù)據(jù)庫的訪問接口。

圖2 作業(yè)管理層的模塊設(shè)計

3.3 作業(yè)管理器

作業(yè)管理器為用戶及作業(yè)調(diào)度器模塊提供作業(yè)信息保存及作業(yè)隊(duì)列管理功能。用戶向作業(yè)管理器提交大量作業(yè)后,作業(yè)信息首先被存放于作業(yè)管理器中,只有作業(yè)調(diào)度器才能決定作業(yè)被提交到作業(yè)執(zhí)行層中的指定子集群。一旦作業(yè)執(zhí)行層中沒有可用于某一作業(yè)運(yùn)行的計算資源,則該作業(yè)會在作業(yè)管理器中排隊(duì)等待。該設(shè)計可以繞過作業(yè)執(zhí)行層各子集群自有的作業(yè)調(diào)度算法對作業(yè)的管理,將作業(yè)管理上移至作業(yè)管理層完成。作業(yè)管理層松耦合的架構(gòu)還可以綜合不同作業(yè)子集群的情況,提供諸如多隊(duì)列、隊(duì)列間公平性等更豐富的作業(yè)管理功能及作業(yè)調(diào)度策略。作業(yè)管理器的主要組成部分包括:

1)SQLite內(nèi)存數(shù)據(jù)庫:通過SQLAlchemy提供訪問,用來存儲作業(yè)信息。作業(yè)數(shù)據(jù)庫中存儲的作業(yè)信息及相應(yīng)數(shù)據(jù)表格式(部分)如表1所示,其中作業(yè)ID為該數(shù)據(jù)表的主鍵且為自增類型。

表1 作業(yè)信息及相應(yīng)的數(shù)據(jù)表格式

2)SocketServer服務(wù)端:對用戶提供形似RESTful API的TCP接口,響應(yīng)用戶的作業(yè)提交、查詢、刪除請求,作業(yè)調(diào)度器的作業(yè)批量查詢、調(diào)度請求,以及作業(yè)監(jiān)視模塊的作業(yè)運(yùn)行狀況更新請求。

3)作業(yè)ID生成器:作業(yè)管理器包含一個全局單例對象,用來為新作業(yè)分配遞增的ID信息,并將當(dāng)前作業(yè)ID最大值同步至指定文件中。若作業(yè)管理器進(jìn)程被意外中止并恢復(fù),可從該文件中讀出最近作業(yè)ID最大值,確保作業(yè)管理器內(nèi)不存在重復(fù)作業(yè)ID,以保證作業(yè)運(yùn)行狀態(tài)和記賬進(jìn)程的正常運(yùn)行。

3.4 資源狀態(tài)收集模塊

資源狀態(tài)收集模塊負(fù)責(zé)收集作業(yè)執(zhí)行層的可用計算資源信息,并暫存在內(nèi)存數(shù)據(jù)庫中。這提高了作業(yè)調(diào)度效率,尤其當(dāng)作業(yè)執(zhí)行層中存在異地計算子集群時,該模塊會預(yù)先將異地計算資源的信息同步到本地,避免了異地站點(diǎn)間的高通信延遲。資源狀態(tài)收集模塊的主要組成部分包括:

1)SQLite內(nèi)存數(shù)據(jù)庫:通過SQLAlchemy提供訪問,用來存儲計算資源的各項(xiàng)信息。資源狀態(tài)數(shù)據(jù)庫存儲的計算資源信息及相應(yīng)的數(shù)據(jù)表格式(部分)如表2所示,其中計算節(jié)點(diǎn)名稱為該數(shù)據(jù)表的主鍵。

表2 計算資源信息及相應(yīng)的數(shù)據(jù)表格式

2)SocketServer服務(wù)端:對用戶提供形如RESTful API的TCP接口,可響應(yīng)批量查詢請求。

3)數(shù)據(jù)采集部分:根據(jù)配置文件,通過API定期查詢各子集群的可用計算資源。

3.5 作業(yè)調(diào)度器

作業(yè)調(diào)度器是作業(yè)管理層的核心組件,負(fù)責(zé)根據(jù)作業(yè)調(diào)度策略,為用戶作業(yè)設(shè)定執(zhí)行的先后順序及其應(yīng)被提交到的子集群。作業(yè)調(diào)度器是一個獨(dú)立模塊,可以靈活添加多種調(diào)度算法。作業(yè)調(diào)度器在一個調(diào)度周期內(nèi)完成的工作包括:

1)向作業(yè)管理器查詢當(dāng)前排隊(duì)作業(yè),向資源狀態(tài)收集模塊查詢當(dāng)前可用計算資源。

2)計算每個作業(yè)的優(yōu)先級,并將作業(yè)按優(yōu)先級排序。目前的作業(yè)調(diào)度器將作業(yè)的排隊(duì)時間作為作業(yè)優(yōu)先級,即job_prio=cur_time-time_submit,時間越長,優(yōu)先級越高,等價于先來先服務(wù)(First Come First Service,FCFS)算法。

3)按優(yōu)先級順序遍歷作業(yè)。為每個作業(yè)尋找適合該作業(yè)的計算資源,并將該資源分配給該作業(yè)。如果某個計算集群或計算節(jié)點(diǎn)的全部資源已經(jīng)被分配完,則將該集群或該節(jié)點(diǎn)從資源列表中刪除,以加快其他資源的分配速度。作業(yè)調(diào)度器用一個列表記錄成功分配到計算資源的作業(yè)以及每個作業(yè)相應(yīng)的計算資源。

4)將上述計算資源分配列表發(fā)送至作業(yè)管理器,作業(yè)管理器調(diào)用作業(yè)提交模塊,向指定計算集群提交指定作業(yè)。

作業(yè)調(diào)度器支持對機(jī)會計算作業(yè)的調(diào)度。機(jī)會計算作業(yè)由用戶在提交作業(yè)時指定,可運(yùn)行在任何一個子集群的任何可用資源上,以盡量減少排隊(duì)時間;但如果這類作業(yè)運(yùn)行期間,有更高優(yōu)先級的作業(yè)需要計算資源,子集群的調(diào)度器有權(quán)中斷機(jī)會計算作業(yè)的運(yùn)行,將作業(yè)送回作業(yè)管理層中繼續(xù)排隊(duì)。為此,作業(yè)調(diào)度器在為作業(yè)分配計算資源時會執(zhí)行如圖3所示的算法,該算法具體步驟如下:

1)判斷作業(yè)類型。若用戶設(shè)置了機(jī)會計算作業(yè)標(biāo)志,則認(rèn)為作業(yè)為機(jī)會計算作業(yè);若作業(yè)需要使用通用計算資源(GRES)或至少兩個CPU核心,則認(rèn)為作業(yè)為并行計算作業(yè);否則認(rèn)為作業(yè)為串行計算作業(yè)。

2)對于串行計算作業(yè),嘗試在HTC子集群的計算資源中為該作業(yè)分配資源。目前的作業(yè)調(diào)度器可將HTCondor及TORQUE計算集群作為HTC子集群。

3)若分配失敗,則無論作業(yè)類型如何,嘗試在HPC子集群中為該作業(yè)分配計算資源。目前的作業(yè)調(diào)度器可以將SLURM計算集群作為HPC子集群。

4)若分配失敗且作業(yè)類型為并行計算作業(yè),則先假設(shè)HPC子集群中的機(jī)會計算作業(yè)全部被清空,其占用的計算資源全部被釋放,然后再次嘗試為該作業(yè)分配計算資源。

5)若有作業(yè)通過步驟4分配到計算資源,則在步驟4假設(shè)的計算集群中,為在步驟3、步驟4中已分配到資源的所有并行計算作業(yè)重新分配資源,并撤銷步驟3、步驟4對其他類型作業(yè)的資源分配。

圖3 支持機(jī)會計算作業(yè)的資源分配算法

Fig.3 Resource allocation algorithm supporting opportunity computing jobs

綜上所述,當(dāng)前的作業(yè)調(diào)度器具備以下3類調(diào)度策略:

1)作業(yè)優(yōu)先級策略:作業(yè)調(diào)度器根據(jù)作業(yè)屬性計算各個作業(yè)的優(yōu)先級并進(jìn)行排序。

2)每個作業(yè)的資源選擇策略:為高優(yōu)先級的作業(yè)選取合適的計算資源,并將作業(yè)提交到該資源所在的計算集群。

3)全局作業(yè)調(diào)度策略:當(dāng)計算集群暫時沒有與某一作業(yè)完全匹配的計算資源,且作業(yè)無法被立即執(zhí)行時,作業(yè)調(diào)度器在當(dāng)前作業(yè)、當(dāng)前計算資源以及其他正在排隊(duì)的作業(yè)之間實(shí)現(xiàn)協(xié)調(diào)。

3.6 作業(yè)提交模塊

作業(yè)提交模塊負(fù)責(zé)將作業(yè)提交到各子集群。作業(yè)調(diào)度器為作業(yè)選定計算集群后,由作業(yè)管理器以子進(jìn)程的形式啟動作業(yè)提交模塊。作業(yè)提交模塊進(jìn)程以作業(yè)屬主的身份向相應(yīng)的子集群發(fā)送作業(yè)提交請求。系統(tǒng)中的作業(yè)提交模塊可以將作業(yè)提交到下列類型的計算集群:

1)HTCondor集群:通過HTCondor的Python API提交作業(yè)。作業(yè)提交模塊將作業(yè)的腳本、輸入/輸出路徑、資源需求等內(nèi)容打包成一個Python字典,調(diào)用HTCondor的classad包生成相應(yīng)的作業(yè)ClassAd,調(diào)用htcondor包將ClassAd發(fā)送給HTCondor SchedD進(jìn)程。

2)SLURM集群:通過SLURM的sbatch命令行接口提交作業(yè)。作業(yè)提交模塊將作業(yè)的腳本、輸入/輸出路徑、資源需求等內(nèi)容作為該命令的參數(shù)發(fā)送給SLURM集群。

3)TORQUE集群:通過TORQUE的qsub命令行接口提交作業(yè)。作業(yè)提交模塊將作業(yè)的腳本、輸入/輸出路徑、資源需求等內(nèi)容作為該命令的參數(shù)發(fā)送給TORQUE集群。

作業(yè)提交模塊不僅是作業(yè)管理器與作業(yè)執(zhí)行層解耦的必要條件,而且可避免作業(yè)管理器在作業(yè)提交期間的屬主切換問題及不必要的等待,增強(qiáng)作業(yè)管理器的穩(wěn)定性及作業(yè)調(diào)度器的運(yùn)行效率。

3.7 作業(yè)監(jiān)視模塊

作業(yè)監(jiān)視模塊負(fù)責(zé)監(jiān)視作業(yè)在作業(yè)執(zhí)行層上的運(yùn)行及完成情況。對于每個子計算集群,作業(yè)監(jiān)視模塊會為其創(chuàng)建協(xié)程,完成下列數(shù)據(jù)采集工作:

1)作業(yè)運(yùn)行狀態(tài)監(jiān)視:通過API或命令行定期查詢子集群上的作業(yè)運(yùn)行情況,從中篩選出由作業(yè)管理層提交的作業(yè),并通知作業(yè)管理器更新相應(yīng)作業(yè)的狀態(tài)。

2)作業(yè)完成情況監(jiān)視:以定期增量查詢的方式查詢子集群的作業(yè)日志文件或作業(yè)數(shù)據(jù)庫,包括但不限于HTCondor的history文件以及SLURM的job_completions.txt文件。從讀取的數(shù)據(jù)中篩選出由作業(yè)管理層提交的作業(yè),并通知作業(yè)管理器更新相應(yīng)作業(yè)的狀態(tài),存檔或刪除相應(yīng)的作業(yè)記錄。

4 系統(tǒng)運(yùn)行性能測試

4.1 作業(yè)管理器的作業(yè)接收性能測試

高能物理數(shù)據(jù)處理需要讀寫大量數(shù)據(jù)文件,通用方法是通過提交大量作業(yè)分別處理不同的數(shù)據(jù)文件達(dá)到快速處理數(shù)據(jù)的目的。因此,作業(yè)調(diào)度系統(tǒng)接收用戶大批量作業(yè)的速率直接關(guān)系到用戶的交互體驗(yàn),這要求作業(yè)管理層具備快速接收用戶大批量作業(yè)的能力。本文對系統(tǒng)大批量接收作業(yè)的性能進(jìn)行測試,并與用戶直接向HTCondor集群接收同樣數(shù)量作業(yè)的性能進(jìn)行比較。

測試環(huán)境包括運(yùn)行作業(yè)接收服務(wù)端程序和作業(yè)提交客戶端程序的兩臺服務(wù)器。這樣既可模擬用戶從專用登錄節(jié)點(diǎn)提交作業(yè)的過程,又便于觀察兩類程序各自的CPU及內(nèi)存使用情況。兩臺服務(wù)器均為雙路E5-2620 v3,16 GB內(nèi)存,Scientific Linux 6.5操作系統(tǒng)。在該測試環(huán)境上部署Python 2.6.6,并以此運(yùn)行本文所述的作業(yè)管理器組件,作為該測試的實(shí)驗(yàn)組。同時在該測試環(huán)境上部署HTCondor 8.4.11,使用HTCondor的SchedD組件和原生作業(yè)提交命令作為該測試的對照組。

在作業(yè)管理器組件和HTCondor上,分別測試了兩種提交作業(yè)的方式:1)一次提交一個作業(yè),逐個提交500個、1 000個、1 500個、2 000個不同的作業(yè),用時結(jié)果如圖4所示。2)批量提交500個、1 000個、1 500個、2 000個作業(yè),用時結(jié)果如圖5所示。

圖4 逐個提交大量作業(yè)用時對比結(jié)果

Fig.4 Comparison of time consumed by the individual submission of massive jobs

圖5 批量提交作業(yè)用時對比結(jié)果

Fig.5 Comparison of time consumed by the batch submission of jobs

由圖4可以看出,在逐個提交作業(yè)的性能測試中,作業(yè)管理器組件與HTCondor之間存在1.64倍～1.68倍的性能差距。本文的作業(yè)管理器組件是Python程序,作業(yè)提交客戶端也同樣是Python腳本,而HTCondor的SchedD端與客戶端都是C程序,兩者的執(zhí)行效率之間有一定的差距。本文在測試時直接通過bash執(zhí)行for循環(huán)調(diào)用了實(shí)驗(yàn)組和對照組的客戶端各1 000次,每次只提交一個作業(yè),這就放大了上文所述的執(zhí)行效率差距。每個作業(yè)提交成功后,在交互終端上對用戶有一個成功提示信息,對于用戶來說,提交1 000個作業(yè)是等待44 s還是73 s的差別并不明顯。

由圖4還可以發(fā)現(xiàn),無論是本文中的作業(yè)管理器組件還是HTCondor,逐個提交作業(yè)時的效率都不高,即使是性能較好的HTCondor,其接收用戶作業(yè)的速率也只有22.4個/s。因此,在第2個批量提交的性能測試中,通過兩者的客戶端分別批量提交500個、1 000個、1 500個、2 000個作業(yè)。由圖5可見,對于作業(yè)管理器,批量提交作業(yè)同通過循環(huán)提交等量的作業(yè)相比,約有19.8倍～22.6倍的速度提升。在批量提交作業(yè)的情況下,作業(yè)管理器與HTCondor之間仍然存在2.38倍～2.69倍的性能差距。然而,就絕對時間而言,兩者批量提交1 000個作業(yè)的時間只相差2.34 s,對于用戶交互體驗(yàn)的影響并不明顯。

4.2 作業(yè)管理器的作業(yè)轉(zhuǎn)發(fā)性能測試

作業(yè)啟動速率即作業(yè)從排隊(duì)狀態(tài)轉(zhuǎn)入運(yùn)行狀態(tài)的速率,決定了一個HTC作業(yè)調(diào)度系統(tǒng)可以支持的計算集群的最大規(guī)模。在有足量作業(yè)排隊(duì)的情況下,如果作業(yè)啟動速率過慢而作業(yè)結(jié)束速率過快,則會導(dǎo)致計算資源被閑置。對于本文所述的雙層作業(yè)調(diào)度系統(tǒng),作業(yè)管理層的作業(yè)調(diào)度器承擔(dān)了大部分作業(yè)調(diào)度算法的執(zhí)行工作,最可能成為整個系統(tǒng)的性能瓶頸。同時,將大量作業(yè)逐個提交到作業(yè)執(zhí)行層的各個子集群上也需要一定的時間。為探究作業(yè)管理層的作業(yè)轉(zhuǎn)發(fā)性能及其對計算集群整體資源利用率的影響,本文對作業(yè)管理層接收并運(yùn)行大量作業(yè)的完整流程進(jìn)行測試,并與單獨(dú)的HTCondor和SLURM調(diào)度系統(tǒng)進(jìn)行比較。

測試環(huán)境為同一臺服務(wù)器上的3臺相同規(guī)格的虛擬機(jī),其中一臺為作業(yè)提交及調(diào)度節(jié)點(diǎn),另外兩臺為計算節(jié)點(diǎn)。測試環(huán)境的宿主機(jī)使用E5-2665 CPU,每臺虛擬機(jī)擁有1個CPU核心和4 GB內(nèi)存,宿主機(jī)和虛擬機(jī)均使用Scientific Linux 6.9操作系統(tǒng)。本文在該測試環(huán)境上分別部署Python 2.6.6、HTCondor 8.5.6、SLURM 15.08.1以及本文所述的作業(yè)管理器組件,并配置HTCondor使每個計算節(jié)點(diǎn)提供24個作業(yè)槽,配置SLURM使每個節(jié)點(diǎn)提供24個虛擬CPU核,因此每個實(shí)驗(yàn)組和對照組都可以同時運(yùn)行48個單核作業(yè)。如表3所示,兩個實(shí)驗(yàn)組將作業(yè)管理器組件分別與HTCondor及SLURM搭配使用,而兩個對照組不使用作業(yè)管理器組件,僅分別使用HTCondor及SLURM進(jìn)行作業(yè)調(diào)度。HTCondor及SLURM上使用的調(diào)度算法為兩者的默認(rèn)算法。對于兩個實(shí)驗(yàn)組,在作業(yè)管理層的作業(yè)調(diào)度器中,以作業(yè)排隊(duì)時間作為優(yōu)先級,實(shí)現(xiàn)了簡單的先進(jìn)先出(First In First Out,FIFO)調(diào)度算法。

表3 測試環(huán)境內(nèi)實(shí)驗(yàn)組與對照組的軟件配置

Table 3 Software configuration of the experimental group and the control group in the test environment

比較項(xiàng)目實(shí)驗(yàn)組對照組1212作業(yè)管理層有有無無作業(yè)執(zhí)行層HTCondorSLURMHTCondorSLURM計算資源總量48個作業(yè)槽48個虛擬核48個作業(yè)槽48個虛擬核

本文分別向上述4組軟件環(huán)境提交500個、1 000個、1 500個、2 000個計算作業(yè),統(tǒng)計從第一個作業(yè)開始運(yùn)行到最后一個作業(yè)完成所消耗的時間。提交的每個計算作業(yè)均為sleep 1 000 s,占用HTCondor的1個作業(yè)槽或SLURM的1個虛擬CPU核,因此測試資源的實(shí)際數(shù)量不會對測試結(jié)果造成影響。該測試環(huán)境內(nèi)的每個實(shí)驗(yàn)組和對照組都可以同時運(yùn)行48個sleep作業(yè),在不考慮作業(yè)調(diào)度、轉(zhuǎn)發(fā)、I/O等開銷的情況下,理論上運(yùn)行完x個作業(yè)需要的最短時間為「x÷48?×1 000 s。當(dāng)x=1 000時,作業(yè)運(yùn)行用時約21 000 s,實(shí)際測試結(jié)果如圖6所示。

圖6 大批量提交作業(yè)用時對比結(jié)果

Fig.6 Comparison of time consumed by the massive batch submission of jobs

由圖6可以看出,雙層作業(yè)調(diào)度模式與單一的HTCondor或SLURM等作業(yè)調(diào)度系統(tǒng)相比,作業(yè)執(zhí)行用時分別增加了4.8%～5.9%和1.5%～2.0%,這是多隊(duì)列、自定義調(diào)度算法等功能的必要開銷。因此,筆者認(rèn)為作業(yè)管理層的作業(yè)調(diào)度、作業(yè)轉(zhuǎn)發(fā)過程都較高效,基本能夠滿足HTC計算集群滿負(fù)荷運(yùn)行的需求。

5 結(jié)束語

目前高能物理計算任務(wù)以單核串行作業(yè)為主,通過在計算集群上同時運(yùn)行大量互不相關(guān)的計算作業(yè)來提高數(shù)據(jù)處理速度。隨著計算集群規(guī)模的擴(kuò)大,傳統(tǒng)的PBS、HTCondor等集中式作業(yè)調(diào)度系統(tǒng)逐漸出現(xiàn)性能或功能方面的不足。本文提出雙層作業(yè)調(diào)度系統(tǒng)的概念及基本框架,使系統(tǒng)管理員可以在作業(yè)管理層靈活配置多種調(diào)度算法,同時整個系統(tǒng)具有更好的伸縮性。在此基礎(chǔ)上,本文實(shí)現(xiàn)了作業(yè)管理層的原型系統(tǒng),并將其與HTCondor及SLURM進(jìn)行整合。針對高能所計算平臺的實(shí)際需求,本文對作業(yè)管理器的批量作業(yè)接收性能以及作業(yè)轉(zhuǎn)發(fā)性能進(jìn)行測試,結(jié)果表明作業(yè)管理器的性能對雙層作業(yè)調(diào)度系統(tǒng)的效率基本沒有影響,可滿足高能物理計算集群高負(fù)荷運(yùn)行的需求。

雙層作業(yè)調(diào)度系統(tǒng)的核心是通過作業(yè)調(diào)度器實(shí)現(xiàn)的調(diào)度算法,但本文只實(shí)現(xiàn)了最基本的先進(jìn)先出算法,后續(xù)工作將針對高能物理數(shù)據(jù)處理的特性提供一些更為復(fù)雜的調(diào)度算法,以保證多個用戶組及作業(yè)隊(duì)列之間的調(diào)度公平性。另外,為兼顧HTC和HPC作業(yè)在同一計算集群內(nèi)的運(yùn)行效果,計算資源在作業(yè)執(zhí)行層的多個子集群之間的動態(tài)調(diào)配也是需要進(jìn)一步研究的內(nèi)容。