胡 鶴，趙 毅，王憲賀

中國科學(xué)院 計算機網(wǎng)絡(luò)信息中心，北京100190

傳統(tǒng)HPC負(fù)載具有強環(huán)境依賴的特點，所需的軟件堆棧通常很復(fù)雜，涉及編譯器、通信中間件及數(shù)學(xué)庫。容器技術(shù)的產(chǎn)生帶來不同依賴環(huán)境下應(yīng)用程序的可移植性。為支持智能業(yè)務(wù)的機器學(xué)習(xí)負(fù)載，超算平臺均采用CPU+GPU的混合架構(gòu)[1]，有往容器遷移演進的趨勢，確保開發(fā)環(huán)境的可移植性及訓(xùn)練的可復(fù)制性。美國橡樹嶺國家實驗室的著名超級計算機SUMMIT提供了容器服務(wù)[2]。NERSC開發(fā)了類似Docker的Linux容器技術(shù)OpenShift來提高其HPC系統(tǒng)的靈活性和可用性[3]。天河二號實踐了基于容器的HPC/大數(shù)據(jù)處理，優(yōu)化了超算環(huán)境的公共服務(wù)能力與模式，優(yōu)化用戶應(yīng)用體驗[4]。

在并行應(yīng)用程序中，影響性能的因素主要包括計算、通信以及I/O模式等。因此，相關(guān)研究對容器性能和裸機性能進行比對，以此來評估不同超算應(yīng)用程序移植到容器中的適用性，并評估各種影響計算效率的因素。Felter等人在IBM研究報告[5]中指出，Docker的性能表現(xiàn)優(yōu)于幾乎所有測試場景中的虛擬化性能，但Docker分層文件存儲方式會產(chǎn)生一定的I/O性能損耗，在網(wǎng)絡(luò)密集型工作負(fù)載時，其本身的NAT會帶來較大開銷。GPU方面，文獻(xiàn)[6]評估了機器學(xué)習(xí)應(yīng)用在GPU上的訓(xùn)練效率，以證明容器化部署對機器學(xué)習(xí)的效率開銷不大。通信方面，文獻(xiàn)[7]對比同樣進程數(shù)量但容器個數(shù)及容器內(nèi)部進程數(shù)不同的情況下，NPB基準(zhǔn)測試程序測試結(jié)果的變化，證明HPC工作負(fù)載會影響容器間的通信性能。I/O方面，文獻(xiàn)[8]對容器的I/O性能競爭進行深入的討論和實驗分析，分析了I/O各項指標(biāo)隨容器數(shù)量的變化趨勢，提出通過動態(tài)限制過載容器I/O強度從而提高容器系統(tǒng)I/O性能。

以上研究均為針對影響高性能計算應(yīng)用各方面I/O、通信等進行性能對比，但并未利用分析結(jié)果，提出在HPC上進行容器應(yīng)用部署及優(yōu)化的合理化建議，使容器應(yīng)用性能最大化。本文執(zhí)行全面的基準(zhǔn)測試，分析容器虛擬化解決方案下集群各項性能表現(xiàn)，包括I/O、并行通信及GPU加速性能，并根據(jù)不同應(yīng)用的特點提出系統(tǒng)設(shè)置的合理化建議，為管理員及應(yīng)用研發(fā)人員提高應(yīng)用性能提供參考。

1 測試環(huán)境配置

測試是基于中國科技云基礎(chǔ)設(shè)施“人工智能計算及數(shù)據(jù)服務(wù)應(yīng)用平臺”進行的，數(shù)據(jù)傳輸使用計算存儲網(wǎng)絡(luò)為56 Gb/s FDR Infiniband高速網(wǎng)絡(luò)，每個節(jié)點都配有兩個Intel Xeon E5-2650處理器（每個具有12個內(nèi)核，頻率為2.40 GHz），256 GB RAM。每個節(jié)點配有8塊Tesla P100 GPU卡。使用具有Linux內(nèi)核3.10.0的64位CentOS 7.6來執(zhí)行所有測試，并行環(huán)境部署了OpenMPI1.6.5版。

采用NVIDIA提供的支持GPU的Docker鏡像作為基礎(chǔ)鏡像，該鏡像能夠發(fā)現(xiàn)宿主機驅(qū)動文件以及GPU設(shè)備，并且將這些掛載到來自Docker守護進程的請求中，以此來支持Docker GPU的使用[9]。按照文獻(xiàn)[10]的操作對容器使用IB進行適配，將Docker默認(rèn)的網(wǎng)絡(luò)地址設(shè)置成IB卡的地址，在容器內(nèi)部安裝配置ssh做進程啟動。為了保持一致性，容器和宿主機具有相同的軟件堆棧并為比較使用容器內(nèi)部MPI庫及宿主機MPI庫兩者不同的性能表現(xiàn)，在容器內(nèi)及容器外分別部署MPI庫，配置了相同的MPI版本，如圖1所示。為衡量Docker運行時的性能，以及衡量硬件在容器內(nèi)虛擬化后相應(yīng)的系統(tǒng)開銷，本文使用基準(zhǔn)測試程序分別針對文件系統(tǒng)I/O性能、并行通信性能與GPU計算性能進行測試。

圖1 測試鏡像軟件棧Fig.1 Software stack of host and container

2 測試結(jié)果與性能評估

2.1 文件系統(tǒng)讀寫性能

為面向宿主機和容器分析分布式集群文件系統(tǒng)的讀寫性能，選取IOR[11]作為測試工具進行性能分析。IOR（Interleaved or Random）是一種常用的文件系統(tǒng)基準(zhǔn)測試應(yīng)用程序，旨在測量POSIX和MPI-IO級別的并行I/O性能，特別適用于評估并行文件系統(tǒng)的性能。

測試使用2個節(jié)點，每節(jié)點12核心，每進程生成5 GB數(shù)據(jù)進行讀寫操作。測試兩種使用場景：

（1）主機上啟動一個容器，容器內(nèi)啟動多個進程；

（2）主機上啟動多個容器，每容器啟動一個進程。

場景1測試IO讀寫帶寬隨進程數(shù)的變化趨勢如圖2。

圖2 IOR讀寫帶寬隨進程數(shù)變化趨勢Fig.2 IOR read-write bandwidth trend with the number of processes

從圖2可以看出容器的性能基本與宿主機性能保持一致，最大開銷為8%。因此，容器采用bind mount的方式，使用宿主機的存儲，文件系統(tǒng)I/O開銷僅比宿主機多占用容器系統(tǒng)軟件棧，性能差距不大。

使每個容器產(chǎn)生同樣的I/O負(fù)載進行場景2測試，隨容器數(shù)量的增長，I/O性能的變化如圖3所示。當(dāng)容器數(shù)量為13時，IOR程序異常終止。讀寫帶寬呈類冪函數(shù)的下降趨勢。

圖3 IOR讀寫帶寬隨容器數(shù)變化趨勢Fig.3 IOR read-write bandwidth trend with the number of containers

因此當(dāng)宿主機上容器個數(shù)增多，對I/O密集型應(yīng)用而言，各容器之間會搶占系統(tǒng)資源，導(dǎo)致整體I/O性能下降。原因是Docker容器技術(shù)本身沒有提供良好的容器I/O管理機制，無法保證容器之間的I/O隔離性，降低主機上容器之間的I/O性能影響。因此在實際應(yīng)用中研發(fā)和部署中，應(yīng)設(shè)法降低容器間I/O性能的影響。

2.2 通信性能

該測試的目的是比較容器間通信與物理機間通信，衡量容器MPI并行通信的性能開銷。在進行MPI通信性能對比之前，通過InfiniBand設(shè)備廠商Mellanox提供的基準(zhǔn)測試工具測試InfiniBand網(wǎng)卡帶寬和網(wǎng)絡(luò)延遲[12]。得到兩臺測試宿主機的帶寬約為50 Gb/s，接近理論值。用qperf[13]測試IB網(wǎng)針對基于TCP或UDP的通信性能，得出容器間的帶寬約為11.12 Gb/s，約為IB網(wǎng)絡(luò)帶寬的25%。

使用廣泛使用的MPI庫的帶寬及延時基準(zhǔn)OSU[14]測試容器的并行通信性能開銷，并比較兩種方案——使用容器MPI庫及宿主機MPI庫兩者的不同。在不同宿主機上各啟動一個容器進行測試，帶寬結(jié)果的比較如圖4所示。采用宿主機MPI宿主機和容器通信的峰值帶寬分別為6 694 MB/s以及5 887 MB/s，Docker容器與宿主機相比在并行通信方面有約為10%的開銷；而使用容器內(nèi)部的MPI，帶寬僅為使用宿主機帶寬的約25%。

圖4 MPI點對點通信帶寬Fig.4 MPI Point-to-Point communication performance

延遲結(jié)果的比較如表1所示，使用宿主機MPI，容器延遲比宿主機延遲高6%，而使用容器內(nèi)部MPI相比使用主機MPI延遲多了2.8倍。

表1 MPI點對點通信延遲Table 1 MPI point-to-point communication latency

使用容器MPI比使用主機MPI開銷大的原因，是由于容器中不能識別IB卡，通信只能通過IB卡生成的虛擬網(wǎng)橋進行，產(chǎn)生了系統(tǒng)CPU和內(nèi)存開銷而造成的。

為評估其他MPI常見函數(shù)的延遲情況，使用基準(zhǔn)測試程序IMB[15]，利用宿主機的MPI庫，選擇四種常見的集合通信方式bcast、allgather、allreduce及alltoall進行宿主機和容器的集合通信性能測試。對比兩種情況的測試結(jié)果：（1）每臺宿主機啟動20進程；（2）每臺宿主機啟動一個容器，容器內(nèi)啟動20進程。

測試結(jié)果如圖5所示，顯示常見的四種MPI庫函數(shù)容器與主機的延遲差值隨數(shù)據(jù)包大小的變化趨勢。在實驗中發(fā)現(xiàn)，容器并行通信性能與宿主機接近，但隨著消息包增大通信延遲差距增大。

圖5 IMB集合通信性能（40進程）Fig.5 Collective communication performance with 40 processes

2.3 GPU計算性能

本文采用了安裝好GPU驅(qū)動的開源版本Docker鏡像nvidia-docker，可以在容器中能夠直接訪問GPU資源。之后如需支持不同版本的開發(fā)框架，只需在容器中安裝cuda toolkit即可。這種方式可以使同一個GPU硬件驅(qū)動支持不同CUDA版本，解決用戶CUDA版本多樣化需求。使用ResNet-50[16]模型通過深度學(xué)習(xí)框架TensorFlow[17]進行了性能評估。在所有測試中均使用ILSVRC2012[18]數(shù)據(jù)集。測試結(jié)果如圖6所示。

圖6 ImageNet圖像處理吞吐量Fig.6 ImageNet image processing throughput

使用AI訓(xùn)練和推理模型對宿主機和容器進行測試的結(jié)果表明，在采用多個容器的情況下，容器能夠以近線性方式向上擴展。容器與宿主機性能接近，最大開銷約為7%。通過查看GPU利用率，所有容器的GPU達(dá)到了飽和狀態(tài)，使用容器進行訓(xùn)練可充分利用GPU的性能。

3 容器應(yīng)用優(yōu)化建議

測試結(jié)果表明，Docker可以很好地支持GPU、Infiniband等硬件，能夠在超算領(lǐng)域帶來更好的可移植性。在I/O、通信、GPU計算能力方面，Docker帶來的開銷可以忽略。通過以上實驗結(jié)果分析，提出應(yīng)用程序在進行容器配置采用如下建議。

3.1 容器IO優(yōu)化

I/O方面通過bind mount的形式與宿主機共享文件系統(tǒng)，將存儲盤掛載到容器，減少文件分層存儲方式帶來的I/O性能損耗。

對于I/O密集型應(yīng)用，減少宿主機上啟動容器的個數(shù)，避免同一時間多容器同時進行I/O操作。減少宿主機上容器的I/O爭用。而容器內(nèi)部，通過MPI或OpenMP等實現(xiàn)對并發(fā)、同步、數(shù)據(jù)讀寫的支持，完成I/O的編排。

3.2 容器通信優(yōu)化

建議使用宿主機的MPI庫，發(fā)揮平臺IB網(wǎng)RDMA傳輸特性帶來的優(yōu)勢。因容器內(nèi)部對Infiniband的支持問題，使用宿主機MPI約為使用容器MPI性能的四倍。實現(xiàn)時將宿主機文件系統(tǒng)中的MPI庫文件映射到容器中，在并行通信時選擇宿主機的MPI庫。

使用宿主機MPI，容器并行通信性能與宿主機接近，但隨著消息包增大通信延遲差距增大。故對于通信負(fù)載較高的通信密集型應(yīng)用程序，使用容器會給通信性能帶來一定開銷。

3.3 充分利用容器可移植性

用英偉達(dá)的鏡像作為基礎(chǔ)進行配置，也可以選擇在自身鏡像中安裝nvidia-docker-plugin的方式支持GPU。容器中可以識別GPU卡，因此可以在容器內(nèi)部安裝與宿主機不同的CUDA版本，實現(xiàn)對不同應(yīng)用軟件的兼容。系統(tǒng)管理員可以準(zhǔn)備裝有不同應(yīng)用版本的容器鏡像，放入容器倉庫中方便用戶下載，使用戶集中精力于模型和算法，而不是應(yīng)用環(huán)境配置。

3.4 進行容器安全設(shè)置

在Docker設(shè)計之初安全性是無關(guān)緊要的，用戶可以使用root用戶掛載主機文件目錄，還可以用root權(quán)限訪問主機上的其他容器，而造成系統(tǒng)破壞或數(shù)據(jù)泄露。在容器使用時，系統(tǒng)管理員需設(shè)置好訪問控制策略，盡量使用戶獨占節(jié)點，避免用戶的容器被其他用戶以root權(quán)限訪問。另外，保護好宿主機的MPI目錄，掛載單獨的分區(qū)，并設(shè)置為只讀。

4 結(jié)束語

容器可以解決HPC領(lǐng)域開發(fā)環(huán)境的一系列問題，帶來應(yīng)用程序跨平臺的可移植性。本文評估超算環(huán)境下Docker容器的性能表現(xiàn)，從計算、I/O、通信三方面，通過基準(zhǔn)軟件衡量容器本身開銷。在測試中觀察到的容器總體性能開銷是可以容忍的。具體使用時，應(yīng)盡量使用宿主機的文件系統(tǒng)及MPI庫，盡量減少并發(fā)容器的個數(shù)，發(fā)揮計算網(wǎng)絡(luò)性能并減少文件系統(tǒng)開銷。另外提出了增加容器隔離性、安全性，及可管理性的相關(guān)設(shè)置。本文尚未針對大規(guī)模應(yīng)用使用容器進行相關(guān)實驗和結(jié)果分析，需要在今后的工作中進一步深入。