文敏華,胡廣超,王一超
(上海交通大學(xué) 網(wǎng)絡(luò)信息中心,上海 200240)
高性能計(jì)算(High Performance Computing,HPC)與理論研究、實(shí)驗(yàn)科學(xué)并稱(chēng)為人類(lèi)科學(xué)研究的三大范式[1],在生物科學(xué)、材料模擬、天氣預(yù)報(bào)、工程計(jì)算等眾多領(lǐng)域有廣泛應(yīng)用。軟件部署和環(huán)境維護(hù)是HPC 集群運(yùn)維的重點(diǎn)和難點(diǎn)。HPC 軟件通常涉及復(fù)雜依賴(lài)環(huán)境、多種依賴(lài)庫(kù)、多版本部署,而一般用戶往往需要使用特定版本軟件,極易與其他版本產(chǎn)生沖突;另一方面,新型HPC 芯片層出不窮,計(jì)算架構(gòu)的多樣性使軟件部署方式更加復(fù)雜。如果采用傳統(tǒng)物理機(jī)直接編譯的部署方法,很難兼顧其他軟件的版本和依賴(lài)環(huán)境,軟件版本控制極大增加了部署和使用難度。
容器是一種輕型虛擬化技術(shù),以輕量級(jí)、隔離性和啟動(dòng)速度快等優(yōu)勢(shì)著稱(chēng),近年來(lái)逐漸被HPC 領(lǐng)域關(guān)注和應(yīng)用。容器技術(shù)為軟件安裝提供了一種便利的打包機(jī)制[2],可對(duì)應(yīng)用及其依賴(lài)環(huán)境進(jìn)行打包,并封裝為單個(gè)對(duì)象,既可以避免不同版本軟件產(chǎn)生沖突,又提升了不同系統(tǒng)間的可移植性。
2013 年,世界首個(gè)開(kāi)源容器引擎Docker[3]誕生,其基于Linux 核心中的資源分離機(jī)制和cgroup 等技術(shù)實(shí)現(xiàn)了靈活、便捷、輕量級(jí)的容器方案。之后容器技術(shù)快速發(fā)展,Linux Container[4]等典型的應(yīng)用實(shí)例,以及Kubernetes[5]、Mesos[6]等多容器編排框架相繼誕生,并在HPC 領(lǐng)域有所應(yīng)用[7-10]。然而上述容器技術(shù)存在一些問(wèn)題,如多節(jié)點(diǎn)并行運(yùn)行模式下Linux Container 存在性能損耗[11];Docker 在多用戶共享場(chǎng)景下的權(quán)限和安全性存在問(wèn)題[12],且對(duì)多處理器及多節(jié)點(diǎn)并行計(jì)算模式MPI 的支持機(jī)制復(fù)雜[13],使其在HPC 中的應(yīng)用受到限制。針對(duì)這些問(wèn)題,一些面向HPC 計(jì)算的容器技術(shù)先后被開(kāi)發(fā)出來(lái)[14-16],其中Singularity 是其中典型代表,由于在性能、安全性、并行效率等方面表現(xiàn)優(yōu)異,Singularity 已在HPC 領(lǐng)域廣泛應(yīng)用[15],本文便是基于Singularity容器技術(shù)進(jìn)行軟件部署和測(cè)試。
本文選取開(kāi)源分子動(dòng)力學(xué)軟件Quantum Espresso(QE)[17-18]在不同計(jì)算平臺(tái)進(jìn)行部署和性能測(cè)試,探索容器使用對(duì)HPC 應(yīng)用部署和性能的影響。在算法上,分子動(dòng)力學(xué)模擬對(duì)訪存和計(jì)算均具有一定要求,是HPC 的典型計(jì)算模式。在軟件選擇上,QE 是最廣泛使用的開(kāi)源分子動(dòng)力學(xué)軟件之一,其計(jì)算性能和可擴(kuò)展性均有充分研究與優(yōu)化依據(jù)[19],在眾多分子動(dòng)力學(xué)軟件中具有代表性。
除了傳統(tǒng)的x86 計(jì)算平臺(tái),本文也將面向國(guó)產(chǎn)ARM 計(jì)算平臺(tái)進(jìn)行測(cè)試,以探索容器技術(shù)在不同架構(gòu)計(jì)算平臺(tái)的適用性。分別通過(guò)容器技術(shù)安裝基準(zhǔn)測(cè)試程序和QE,以不同規(guī)模的算例進(jìn)行性能測(cè)試,并與物理機(jī)運(yùn)行性能進(jìn)行比較,以探索容器技術(shù)對(duì)以QE 為代表的分子動(dòng)力學(xué)軟件可移植性和性能的影響。
Singularity 為超輕量級(jí)容器化方案,用戶可在隔離空間內(nèi)部署所需應(yīng)用,有效解決物理機(jī)上因依賴(lài)插件過(guò)多而導(dǎo)致的版本沖突,同時(shí)給應(yīng)用版本的升級(jí)也提供了極大便利。此外,容器化應(yīng)用在不同計(jì)算平臺(tái)上可快速遷移,諸多優(yōu)勢(shì)使得Singularity 在HPC 領(lǐng)域應(yīng)用空間廣闊。
Singularity 架構(gòu)如圖1 所示,容器中的應(yīng)用運(yùn)行在一個(gè)相對(duì)隔離的空間內(nèi)。從操作系統(tǒng)角度來(lái)看,容器和主機(jī)上運(yùn)行的進(jìn)程比較相似,使得容器易于運(yùn)行與管理。相較于傳統(tǒng)虛擬機(jī)技術(shù),容器共享物理機(jī)上的Linux 內(nèi)核與底層硬件資源使得容器體量變小,一定程度上會(huì)降低虛擬化開(kāi)銷(xiāo)。容器對(duì)底層資源的訪問(wèn)無(wú)需通過(guò)root 權(quán)限,普通用戶即可共享主機(jī)上的服務(wù),為容器的可遷移性奠定了良好基礎(chǔ),使得任何用戶均可在裸機(jī)上運(yùn)行容器中的應(yīng)用。
Fig.1 Architecture of Singularity圖1 Singularity 架構(gòu)
Singularity 是專(zhuān)門(mén)面向HPC 開(kāi)發(fā)的容器技術(shù),主要特征為:①計(jì)算可移植。容器內(nèi)部的軟件棧從數(shù)據(jù)到依賴(lài)庫(kù)均可在不同操作系統(tǒng)和計(jì)算平臺(tái)上遷移,鏡像將應(yīng)用打包成一個(gè)可復(fù)制與共享的文件,該文件適用于任何標(biāo)準(zhǔn)Unix文件系統(tǒng);②用戶自由度高。非特權(quán)用戶也可操作容器并根據(jù)需求實(shí)施應(yīng)用部署、安裝依賴(lài)和版本升級(jí)等操作,無(wú)需擔(dān)心與其他應(yīng)用的依賴(lài)版本沖突;③不完全隔離。不同于Docker 和Linux Container 等容器技術(shù),Singularity 沒(méi)有實(shí)現(xiàn)網(wǎng)絡(luò)地址空間的隔離,網(wǎng)絡(luò)虛擬化開(kāi)銷(xiāo)較低;④兼容HPC 計(jì)算環(huán)境。Singularity 可有效整合并行文件系統(tǒng)、GPU、MPI 和快速網(wǎng)絡(luò)等傳統(tǒng)HPC 軟硬件支持;⑤安全性高。雖然容器內(nèi)外用戶目錄保持一致,但容器不能對(duì)主機(jī)上的系統(tǒng)配置實(shí)施任何其他操作,普通用戶無(wú)法更改鏡像文件內(nèi)容,對(duì)其僅有只讀權(quán)限。
主要通過(guò)兩個(gè)基準(zhǔn)測(cè)試程序和QE 的3 個(gè)算例進(jìn)行部署與性能測(cè)試。
基準(zhǔn)測(cè)試程序主要用于對(duì)分項(xiàng)性能參數(shù)進(jìn)行測(cè)試,分別采用STREAM[20]和HPL[21]兩個(gè)基準(zhǔn)測(cè)試程序?qū)υL存和計(jì)算能力進(jìn)行測(cè)試。STREAM 是一個(gè)用于測(cè)試可持續(xù)訪存帶寬的綜合基準(zhǔn)測(cè)試程序,由4 種不同算術(shù)操作組成,分別為Copy、Scale、Add 和Triad。STREAM 最多使用3 個(gè)數(shù)組和1 個(gè)標(biāo)量進(jìn)行基本算術(shù)操作,通過(guò)控制數(shù)組數(shù)據(jù)大小可以實(shí)現(xiàn)不同數(shù)據(jù)量的內(nèi)存帶寬測(cè)試。HPL 是目前使用最廣泛的浮點(diǎn)性能測(cè)試基準(zhǔn)程序,長(zhǎng)期用于世界前500 強(qiáng)超級(jí)計(jì)算機(jī)排行榜排名。HPL 通過(guò)采用高斯消元法求解一元N 次稠密線性代數(shù)方程組對(duì)HPC 集群進(jìn)行測(cè)試,評(píng)價(jià)其浮點(diǎn)計(jì)算能力。
開(kāi)源分子動(dòng)力學(xué)軟件QE 是在密度泛函理論、贗勢(shì)和平面波的基礎(chǔ)上,使用電子結(jié)構(gòu)技術(shù)對(duì)材料進(jìn)行量子模擬的軟件包,從其誕生至今,一直在全球領(lǐng)先的材料建模團(tuán)隊(duì)中廣泛使用。QE 彈性擴(kuò)展性能良好,在不同大型并行計(jì)算機(jī)的各種硬件架構(gòu)上均能保持優(yōu)越性能,為其在HPC 平臺(tái)上的容器部署奠定了良好基礎(chǔ)。
分別在x86 平臺(tái)和國(guó)產(chǎn)ARM 平臺(tái)上進(jìn)行部署與性能測(cè)試,配置信息如表1 所示。在軟件層面,兩個(gè)平臺(tái)除操作系統(tǒng)外,其余均采用同版本軟件。
Table 1 Testing platform environment configuration表1 測(cè)試平臺(tái)環(huán)境配置
與在裸機(jī)上通過(guò)源碼編譯不同,QE 在容器中的部署需按照一定規(guī)則生成定義文件,然后通過(guò)Singularity 的build指令生成相應(yīng)鏡像。定義文件的制作示意圖見(jiàn)圖2,其本質(zhì)安裝邏輯與裸機(jī)安裝一致,可以對(duì)軟件和依賴(lài)庫(kù)的版本實(shí)現(xiàn)精細(xì)控制。定義文件包含%files、%environment 和%post 等關(guān)鍵屬性,分別用于實(shí)現(xiàn)容器內(nèi)外文件傳輸、環(huán)境變量配置與使用命令行編譯軟件等操作。
Fig.2 Schematic diagram of QE image definition file圖2 QE 鏡像制作定義文件示意圖
制作定義文件后,通過(guò)命令行“singularity build qe.sif qe.def”生成鏡像,此處qe.sif 為生成的鏡像,qe.def 為制作鏡像的定義文件。鏡像生成后,可以通過(guò)Singularity 的exec指令調(diào)用鏡像中封裝的各類(lèi)可執(zhí)行文件,從而運(yùn)行容器內(nèi)應(yīng)用。
本文測(cè)試平臺(tái)包括x86 平臺(tái)和國(guó)產(chǎn)ARM 平臺(tái),兩種平臺(tái)部署邏輯一致,僅需根據(jù)實(shí)際配置對(duì)定義文件內(nèi)環(huán)境變量、源碼安裝命令進(jìn)行設(shè)置即可,這表示x86 平臺(tái)的配置經(jīng)驗(yàn)可以比較方便地推廣到國(guó)產(chǎn)ARM 計(jì)算平臺(tái)上。
對(duì)于基準(zhǔn)測(cè)試程序,本文主要針對(duì)單節(jié)點(diǎn)進(jìn)行測(cè)試,目的是獲得容器下單項(xiàng)特征的性能數(shù)據(jù);對(duì)于QE,本文分別在x86 平臺(tái)和ARM 平臺(tái)上使用不同核心數(shù)量進(jìn)行測(cè)試。兩種架構(gòu)上使用的數(shù)據(jù)為官方提供的AUSURF112、CuO 和PSIWAT,鏈接為https://github.com/QEF/benchmarks。
圖3 和圖4 分別為STREAM 和HPL 基準(zhǔn)測(cè)試程序在x86 平臺(tái)和國(guó)產(chǎn)ARM 平臺(tái)上的性能比較,此處調(diào)用單節(jié)點(diǎn)所有核心,以測(cè)試整個(gè)節(jié)點(diǎn)的性能。對(duì)于x86 平臺(tái),容器對(duì)表征內(nèi)存帶寬的STREAM 帶來(lái)的損失小于1%,對(duì)表征浮點(diǎn)計(jì)算性能的HPL 帶來(lái)的損失亦小于1%。對(duì)于國(guó)產(chǎn)ARM平臺(tái),容器對(duì)內(nèi)存帶寬帶來(lái)的損失小于3%,對(duì)浮點(diǎn)計(jì)算性能帶來(lái)的損失小于1%。兩種計(jì)算平臺(tái)的性能損失均不超過(guò)3%。由此可以推測(cè),不論是對(duì)于計(jì)算受限還是訪存受限的應(yīng)用,容器的引入都不會(huì)帶來(lái)較大的性能損失。
Fig.3 Performance comparison of x86 and ARM platform on STREAM benchmark圖3 x86 平臺(tái)與ARM 平臺(tái)STREAM 基準(zhǔn)測(cè)試性能比較
Fig.4 Performance comparison of x86 and ARM platform on HPL benchmark圖4 x86 平臺(tái)與ARM 平臺(tái)HPL 基準(zhǔn)測(cè)試性能比較
Singularity 容器部署作為新的部署方法,需優(yōu)先考慮其正確性,為此比較物理機(jī)部署和容器部署的計(jì)算結(jié)果差異。對(duì)于QE 模擬,總能(Total Energy)是其關(guān)鍵指標(biāo),可用于結(jié)果正確性驗(yàn)證。通過(guò)比較基于這兩種部署方式的總能隨運(yùn)行時(shí)迭代步數(shù)的變化情況判斷二者結(jié)果是否一致。圖5 展示了一個(gè)典型QE 算例(CuO)在兩種計(jì)算平臺(tái)上的運(yùn)行結(jié)果,可以看出,不論是x86 還是ARM 平臺(tái),物理機(jī)部署方式和Singularity 容器部署方式的總能都能吻合得很好,說(shuō)明兩種部署方式模擬結(jié)果一致,證明了Singularity 容器部署方式的正確性。
Fig.5 Correctness verification of QE installation based on Singularity(up:x86,down:ARM)圖5 Singularity 安裝QE 正確性驗(yàn)證(上:x86 平臺(tái),下:ARM 平臺(tái))
圖6 為x86 平臺(tái)上物理機(jī)與Singularity 運(yùn)行AUSURF112、CuO 和PSIWAT 3 個(gè)算例的計(jì)算時(shí)間??梢钥闯?,從單節(jié)點(diǎn)內(nèi)的20 核心和40 核心并行,到跨節(jié)點(diǎn)的80 核心和120 核心并行,基于Singularity 容器技術(shù)安裝的QE 均能取得接近物理機(jī)裸機(jī)部署的性能,性能損失最大不超過(guò)3%,最小則小于1%,可見(jiàn)Singularity 對(duì)跨節(jié)點(diǎn)的MPI 并行方式確實(shí)有較好的支持效果。
圖7 為國(guó)產(chǎn)ARM 平臺(tái)上物理機(jī)和Singularity 運(yùn)行AUSURF112、CuO 和PSIWAT 3 種算例的計(jì)算時(shí)間。由不同并行核數(shù)下性能表現(xiàn)可以看出,QE 在兩種環(huán)境下可以保持相近的性能。在3 種算例上使容器運(yùn)行應(yīng)用,結(jié)果表明不同并行度下容器部署性能損耗值均小于2%,可見(jiàn)對(duì)于國(guó)產(chǎn)ARM 平臺(tái),容器的引入也基本上不會(huì)帶來(lái)性能損失。
Fig.6 Running time of examples of physical machine and Singularity on x86 platform圖6 x86 平臺(tái)物理機(jī)與Singularity 算例運(yùn)行時(shí)間
Fig.7 Running time of examples of physical machine and Singularity on ARM platform圖7 ARM 平臺(tái)物理機(jī)與Singularity 算例運(yùn)行時(shí)間
本文闡述了基于Singularity 容器技術(shù)的QE 部署流程,并在x86 和國(guó)產(chǎn)ARM 兩種平臺(tái)上進(jìn)行了部署實(shí)踐和性能測(cè)試。利用容器技術(shù)靈活、便捷、輕量級(jí)等特點(diǎn)可有效應(yīng)對(duì)應(yīng)用軟件及其依賴(lài)庫(kù)版本不同帶來(lái)的挑戰(zhàn),方便HPC 集群管理人員進(jìn)行應(yīng)用軟件部署與管理。在兩種計(jì)算平臺(tái)的不同并行規(guī)模上,相較于物理機(jī)裸機(jī)部署方法,基于容器技術(shù)的部署方法性能損失小于3%,幾乎可以忽略不計(jì)。不僅如此,QE 在兩種計(jì)算架構(gòu)上容器中的性能均可隨節(jié)點(diǎn)數(shù)增加而良好擴(kuò)展,即使算例的計(jì)算規(guī)模不斷擴(kuò)大也能夠取得物理機(jī)般的計(jì)算效果,說(shuō)明Singularity 容器高度兼容多核與MPI 多節(jié)點(diǎn)并行的計(jì)算方式,對(duì)高速網(wǎng)絡(luò)的支持度較為友好,在x86 和國(guó)產(chǎn)ARM 兩種主流HPC 集群架構(gòu)上均能保持穩(wěn)定的計(jì)算性能。
綜上所述,對(duì)于分子動(dòng)力學(xué)軟件QE 以及不同計(jì)算平臺(tái),Singularity 容器技術(shù)可以在保障性能的情況下優(yōu)化軟件部署與管理。后續(xù)將繼續(xù)對(duì)其他分子動(dòng)力學(xué)軟件進(jìn)行部署和性能測(cè)試,驗(yàn)證容器部署模式對(duì)分子動(dòng)力學(xué)類(lèi)計(jì)算模式的可用性。