胡 鶴,趙 毅,王憲賀
中國(guó)科學(xué)院 計(jì)算機(jī)網(wǎng)絡(luò)信息中心,北京100190
傳統(tǒng)HPC負(fù)載具有強(qiáng)環(huán)境依賴(lài)的特點(diǎn),所需的軟件堆棧通常很復(fù)雜,涉及編譯器、通信中間件及數(shù)學(xué)庫(kù)。容器技術(shù)的產(chǎn)生帶來(lái)不同依賴(lài)環(huán)境下應(yīng)用程序的可移植性。為支持智能業(yè)務(wù)的機(jī)器學(xué)習(xí)負(fù)載,超算平臺(tái)均采用CPU+GPU的混合架構(gòu)[1],有往容器遷移演進(jìn)的趨勢(shì),確保開(kāi)發(fā)環(huán)境的可移植性及訓(xùn)練的可復(fù)制性。美國(guó)橡樹(shù)嶺國(guó)家實(shí)驗(yàn)室的著名超級(jí)計(jì)算機(jī)SUMMIT提供了容器服務(wù)[2]。NERSC開(kāi)發(fā)了類(lèi)似Docker的Linux容器技術(shù)OpenShift來(lái)提高其HPC系統(tǒng)的靈活性和可用性[3]。天河二號(hào)實(shí)踐了基于容器的HPC/大數(shù)據(jù)處理,優(yōu)化了超算環(huán)境的公共服務(wù)能力與模式,優(yōu)化用戶(hù)應(yīng)用體驗(yàn)[4]。
在并行應(yīng)用程序中,影響性能的因素主要包括計(jì)算、通信以及I/O模式等。因此,相關(guān)研究對(duì)容器性能和裸機(jī)性能進(jìn)行比對(duì),以此來(lái)評(píng)估不同超算應(yīng)用程序移植到容器中的適用性,并評(píng)估各種影響計(jì)算效率的因素。Felter等人在IBM研究報(bào)告[5]中指出,Docker的性能表現(xiàn)優(yōu)于幾乎所有測(cè)試場(chǎng)景中的虛擬化性能,但Docker分層文件存儲(chǔ)方式會(huì)產(chǎn)生一定的I/O性能損耗,在網(wǎng)絡(luò)密集型工作負(fù)載時(shí),其本身的NAT會(huì)帶來(lái)較大開(kāi)銷(xiāo)。GPU方面,文獻(xiàn)[6]評(píng)估了機(jī)器學(xué)習(xí)應(yīng)用在GPU上的訓(xùn)練效率,以證明容器化部署對(duì)機(jī)器學(xué)習(xí)的效率開(kāi)銷(xiāo)不大。通信方面,文獻(xiàn)[7]對(duì)比同樣進(jìn)程數(shù)量但容器個(gè)數(shù)及容器內(nèi)部進(jìn)程數(shù)不同的情況下,NPB基準(zhǔn)測(cè)試程序測(cè)試結(jié)果的變化,證明HPC工作負(fù)載會(huì)影響容器間的通信性能。I/O方面,文獻(xiàn)[8]對(duì)容器的I/O性能競(jìng)爭(zhēng)進(jìn)行深入的討論和實(shí)驗(yàn)分析,分析了I/O各項(xiàng)指標(biāo)隨容器數(shù)量的變化趨勢(shì),提出通過(guò)動(dòng)態(tài)限制過(guò)載容器I/O強(qiáng)度從而提高容器系統(tǒng)I/O性能。
以上研究均為針對(duì)影響高性能計(jì)算應(yīng)用各方面I/O、通信等進(jìn)行性能對(duì)比,但并未利用分析結(jié)果,提出在HPC上進(jìn)行容器應(yīng)用部署及優(yōu)化的合理化建議,使容器應(yīng)用性能最大化。本文執(zhí)行全面的基準(zhǔn)測(cè)試,分析容器虛擬化解決方案下集群各項(xiàng)性能表現(xiàn),包括I/O、并行通信及GPU加速性能,并根據(jù)不同應(yīng)用的特點(diǎn)提出系統(tǒng)設(shè)置的合理化建議,為管理員及應(yīng)用研發(fā)人員提高應(yīng)用性能提供參考。
測(cè)試是基于中國(guó)科技云基礎(chǔ)設(shè)施“人工智能計(jì)算及數(shù)據(jù)服務(wù)應(yīng)用平臺(tái)”進(jìn)行的,數(shù)據(jù)傳輸使用計(jì)算存儲(chǔ)網(wǎng)絡(luò)為56 Gb/s FDR Infiniband高速網(wǎng)絡(luò),每個(gè)節(jié)點(diǎn)都配有兩個(gè)Intel Xeon E5-2650處理器(每個(gè)具有12個(gè)內(nèi)核,頻率為2.40 GHz),256 GB RAM。每個(gè)節(jié)點(diǎn)配有8塊Tesla P100 GPU卡。使用具有Linux內(nèi)核3.10.0的64位CentOS 7.6來(lái)執(zhí)行所有測(cè)試,并行環(huán)境部署了OpenMPI1.6.5版。
采用NVIDIA提供的支持GPU的Docker鏡像作為基礎(chǔ)鏡像,該鏡像能夠發(fā)現(xiàn)宿主機(jī)驅(qū)動(dòng)文件以及GPU設(shè)備,并且將這些掛載到來(lái)自Docker守護(hù)進(jìn)程的請(qǐng)求中,以此來(lái)支持Docker GPU的使用[9]。按照文獻(xiàn)[10]的操作對(duì)容器使用IB進(jìn)行適配,將Docker默認(rèn)的網(wǎng)絡(luò)地址設(shè)置成IB卡的地址,在容器內(nèi)部安裝配置ssh做進(jìn)程啟動(dòng)。為了保持一致性,容器和宿主機(jī)具有相同的軟件堆棧并為比較使用容器內(nèi)部MPI庫(kù)及宿主機(jī)MPI庫(kù)兩者不同的性能表現(xiàn),在容器內(nèi)及容器外分別部署MPI庫(kù),配置了相同的MPI版本,如圖1所示。為衡量Docker運(yùn)行時(shí)的性能,以及衡量硬件在容器內(nèi)虛擬化后相應(yīng)的系統(tǒng)開(kāi)銷(xiāo),本文使用基準(zhǔn)測(cè)試程序分別針對(duì)文件系統(tǒng)I/O性能、并行通信性能與GPU計(jì)算性能進(jìn)行測(cè)試。
圖1 測(cè)試鏡像軟件棧Fig.1 Software stack of host and container
為面向宿主機(jī)和容器分析分布式集群文件系統(tǒng)的讀寫(xiě)性能,選取IOR[11]作為測(cè)試工具進(jìn)行性能分析。IOR(Interleaved or Random)是一種常用的文件系統(tǒng)基準(zhǔn)測(cè)試應(yīng)用程序,旨在測(cè)量POSIX和MPI-IO級(jí)別的并行I/O性能,特別適用于評(píng)估并行文件系統(tǒng)的性能。
測(cè)試使用2個(gè)節(jié)點(diǎn),每節(jié)點(diǎn)12核心,每進(jìn)程生成5 GB數(shù)據(jù)進(jìn)行讀寫(xiě)操作。測(cè)試兩種使用場(chǎng)景:
(1)主機(jī)上啟動(dòng)一個(gè)容器,容器內(nèi)啟動(dòng)多個(gè)進(jìn)程;
(2)主機(jī)上啟動(dòng)多個(gè)容器,每容器啟動(dòng)一個(gè)進(jìn)程。
場(chǎng)景1測(cè)試IO讀寫(xiě)帶寬隨進(jìn)程數(shù)的變化趨勢(shì)如圖2。
圖2 IOR讀寫(xiě)帶寬隨進(jìn)程數(shù)變化趨勢(shì)Fig.2 IOR read-write bandwidth trend with the number of processes
從圖2可以看出容器的性能基本與宿主機(jī)性能保持一致,最大開(kāi)銷(xiāo)為8%。因此,容器采用bind mount的方式,使用宿主機(jī)的存儲(chǔ),文件系統(tǒng)I/O開(kāi)銷(xiāo)僅比宿主機(jī)多占用容器系統(tǒng)軟件棧,性能差距不大。
使每個(gè)容器產(chǎn)生同樣的I/O負(fù)載進(jìn)行場(chǎng)景2測(cè)試,隨容器數(shù)量的增長(zhǎng),I/O性能的變化如圖3所示。當(dāng)容器數(shù)量為13時(shí),IOR程序異常終止。讀寫(xiě)帶寬呈類(lèi)冪函數(shù)的下降趨勢(shì)。
圖3 IOR讀寫(xiě)帶寬隨容器數(shù)變化趨勢(shì)Fig.3 IOR read-write bandwidth trend with the number of containers
因此當(dāng)宿主機(jī)上容器個(gè)數(shù)增多,對(duì)I/O密集型應(yīng)用而言,各容器之間會(huì)搶占系統(tǒng)資源,導(dǎo)致整體I/O性能下降。原因是Docker容器技術(shù)本身沒(méi)有提供良好的容器I/O管理機(jī)制,無(wú)法保證容器之間的I/O隔離性,降低主機(jī)上容器之間的I/O性能影響。因此在實(shí)際應(yīng)用中研發(fā)和部署中,應(yīng)設(shè)法降低容器間I/O性能的影響。
該測(cè)試的目的是比較容器間通信與物理機(jī)間通信,衡量容器MPI并行通信的性能開(kāi)銷(xiāo)。在進(jìn)行MPI通信性能對(duì)比之前,通過(guò)InfiniBand設(shè)備廠商Mellanox提供的基準(zhǔn)測(cè)試工具測(cè)試InfiniBand網(wǎng)卡帶寬和網(wǎng)絡(luò)延遲[12]。得到兩臺(tái)測(cè)試宿主機(jī)的帶寬約為50 Gb/s,接近理論值。用qperf[13]測(cè)試IB網(wǎng)針對(duì)基于TCP或UDP的通信性能,得出容器間的帶寬約為11.12 Gb/s,約為IB網(wǎng)絡(luò)帶寬的25%。
使用廣泛使用的MPI庫(kù)的帶寬及延時(shí)基準(zhǔn)OSU[14]測(cè)試容器的并行通信性能開(kāi)銷(xiāo),并比較兩種方案——使用容器MPI庫(kù)及宿主機(jī)MPI庫(kù)兩者的不同。在不同宿主機(jī)上各啟動(dòng)一個(gè)容器進(jìn)行測(cè)試,帶寬結(jié)果的比較如圖4所示。采用宿主機(jī)MPI宿主機(jī)和容器通信的峰值帶寬分別為6 694 MB/s以及5 887 MB/s,Docker容器與宿主機(jī)相比在并行通信方面有約為10%的開(kāi)銷(xiāo);而使用容器內(nèi)部的MPI,帶寬僅為使用宿主機(jī)帶寬的約25%。
圖4 MPI點(diǎn)對(duì)點(diǎn)通信帶寬Fig.4 MPI Point-to-Point communication performance
延遲結(jié)果的比較如表1所示,使用宿主機(jī)MPI,容器延遲比宿主機(jī)延遲高6%,而使用容器內(nèi)部MPI相比使用主機(jī)MPI延遲多了2.8倍。
表1 MPI點(diǎn)對(duì)點(diǎn)通信延遲Table 1 MPI point-to-point communication latency
使用容器MPI比使用主機(jī)MPI開(kāi)銷(xiāo)大的原因,是由于容器中不能識(shí)別IB卡,通信只能通過(guò)IB卡生成的虛擬網(wǎng)橋進(jìn)行,產(chǎn)生了系統(tǒng)CPU和內(nèi)存開(kāi)銷(xiāo)而造成的。
為評(píng)估其他MPI常見(jiàn)函數(shù)的延遲情況,使用基準(zhǔn)測(cè)試程序IMB[15],利用宿主機(jī)的MPI庫(kù),選擇四種常見(jiàn)的集合通信方式bcast、allgather、allreduce及alltoall進(jìn)行宿主機(jī)和容器的集合通信性能測(cè)試。對(duì)比兩種情況的測(cè)試結(jié)果:(1)每臺(tái)宿主機(jī)啟動(dòng)20進(jìn)程;(2)每臺(tái)宿主機(jī)啟動(dòng)一個(gè)容器,容器內(nèi)啟動(dòng)20進(jìn)程。
測(cè)試結(jié)果如圖5所示,顯示常見(jiàn)的四種MPI庫(kù)函數(shù)容器與主機(jī)的延遲差值隨數(shù)據(jù)包大小的變化趨勢(shì)。在實(shí)驗(yàn)中發(fā)現(xiàn),容器并行通信性能與宿主機(jī)接近,但隨著消息包增大通信延遲差距增大。
圖5 IMB集合通信性能(40進(jìn)程)Fig.5 Collective communication performance with 40 processes
本文采用了安裝好GPU驅(qū)動(dòng)的開(kāi)源版本Docker鏡像nvidia-docker,可以在容器中能夠直接訪(fǎng)問(wèn)GPU資源。之后如需支持不同版本的開(kāi)發(fā)框架,只需在容器中安裝cuda toolkit即可。這種方式可以使同一個(gè)GPU硬件驅(qū)動(dòng)支持不同CUDA版本,解決用戶(hù)CUDA版本多樣化需求。使用ResNet-50[16]模型通過(guò)深度學(xué)習(xí)框架TensorFlow[17]進(jìn)行了性能評(píng)估。在所有測(cè)試中均使用ILSVRC2012[18]數(shù)據(jù)集。測(cè)試結(jié)果如圖6所示。
圖6 ImageNet圖像處理吞吐量Fig.6 ImageNet image processing throughput
使用AI訓(xùn)練和推理模型對(duì)宿主機(jī)和容器進(jìn)行測(cè)試的結(jié)果表明,在采用多個(gè)容器的情況下,容器能夠以近線(xiàn)性方式向上擴(kuò)展。容器與宿主機(jī)性能接近,最大開(kāi)銷(xiāo)約為7%。通過(guò)查看GPU利用率,所有容器的GPU達(dá)到了飽和狀態(tài),使用容器進(jìn)行訓(xùn)練可充分利用GPU的性能。
測(cè)試結(jié)果表明,Docker可以很好地支持GPU、Infiniband等硬件,能夠在超算領(lǐng)域帶來(lái)更好的可移植性。在I/O、通信、GPU計(jì)算能力方面,Docker帶來(lái)的開(kāi)銷(xiāo)可以忽略。通過(guò)以上實(shí)驗(yàn)結(jié)果分析,提出應(yīng)用程序在進(jìn)行容器配置采用如下建議。
I/O方面通過(guò)bind mount的形式與宿主機(jī)共享文件系統(tǒng),將存儲(chǔ)盤(pán)掛載到容器,減少文件分層存儲(chǔ)方式帶來(lái)的I/O性能損耗。
對(duì)于I/O密集型應(yīng)用,減少宿主機(jī)上啟動(dòng)容器的個(gè)數(shù),避免同一時(shí)間多容器同時(shí)進(jìn)行I/O操作。減少宿主機(jī)上容器的I/O爭(zhēng)用。而容器內(nèi)部,通過(guò)MPI或OpenMP等實(shí)現(xiàn)對(duì)并發(fā)、同步、數(shù)據(jù)讀寫(xiě)的支持,完成I/O的編排。
建議使用宿主機(jī)的MPI庫(kù),發(fā)揮平臺(tái)IB網(wǎng)RDMA傳輸特性帶來(lái)的優(yōu)勢(shì)。因容器內(nèi)部對(duì)Infiniband的支持問(wèn)題,使用宿主機(jī)MPI約為使用容器MPI性能的四倍。實(shí)現(xiàn)時(shí)將宿主機(jī)文件系統(tǒng)中的MPI庫(kù)文件映射到容器中,在并行通信時(shí)選擇宿主機(jī)的MPI庫(kù)。
使用宿主機(jī)MPI,容器并行通信性能與宿主機(jī)接近,但隨著消息包增大通信延遲差距增大。故對(duì)于通信負(fù)載較高的通信密集型應(yīng)用程序,使用容器會(huì)給通信性能帶來(lái)一定開(kāi)銷(xiāo)。
用英偉達(dá)的鏡像作為基礎(chǔ)進(jìn)行配置,也可以選擇在自身鏡像中安裝nvidia-docker-plugin的方式支持GPU。容器中可以識(shí)別GPU卡,因此可以在容器內(nèi)部安裝與宿主機(jī)不同的CUDA版本,實(shí)現(xiàn)對(duì)不同應(yīng)用軟件的兼容。系統(tǒng)管理員可以準(zhǔn)備裝有不同應(yīng)用版本的容器鏡像,放入容器倉(cāng)庫(kù)中方便用戶(hù)下載,使用戶(hù)集中精力于模型和算法,而不是應(yīng)用環(huán)境配置。
在Docker設(shè)計(jì)之初安全性是無(wú)關(guān)緊要的,用戶(hù)可以使用root用戶(hù)掛載主機(jī)文件目錄,還可以用root權(quán)限訪(fǎng)問(wèn)主機(jī)上的其他容器,而造成系統(tǒng)破壞或數(shù)據(jù)泄露。在容器使用時(shí),系統(tǒng)管理員需設(shè)置好訪(fǎng)問(wèn)控制策略,盡量使用戶(hù)獨(dú)占節(jié)點(diǎn),避免用戶(hù)的容器被其他用戶(hù)以root權(quán)限訪(fǎng)問(wèn)。另外,保護(hù)好宿主機(jī)的MPI目錄,掛載單獨(dú)的分區(qū),并設(shè)置為只讀。
容器可以解決HPC領(lǐng)域開(kāi)發(fā)環(huán)境的一系列問(wèn)題,帶來(lái)應(yīng)用程序跨平臺(tái)的可移植性。本文評(píng)估超算環(huán)境下Docker容器的性能表現(xiàn),從計(jì)算、I/O、通信三方面,通過(guò)基準(zhǔn)軟件衡量容器本身開(kāi)銷(xiāo)。在測(cè)試中觀察到的容器總體性能開(kāi)銷(xiāo)是可以容忍的。具體使用時(shí),應(yīng)盡量使用宿主機(jī)的文件系統(tǒng)及MPI庫(kù),盡量減少并發(fā)容器的個(gè)數(shù),發(fā)揮計(jì)算網(wǎng)絡(luò)性能并減少文件系統(tǒng)開(kāi)銷(xiāo)。另外提出了增加容器隔離性、安全性,及可管理性的相關(guān)設(shè)置。本文尚未針對(duì)大規(guī)模應(yīng)用使用容器進(jìn)行相關(guān)實(shí)驗(yàn)和結(jié)果分析,需要在今后的工作中進(jìn)一步深入。