IB網(wǎng)上CPU-GPU異構(gòu)超算平臺(tái)容器性能評(píng)估及優(yōu)化

胡 鶴，趙 毅，王憲賀

中國(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)用性能提供參考。

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

測(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

2 測(cè)試結(jié)果與性能評(píng)估

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

為面向宿主機(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性能的影響。

2.2 通信性能

該測(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

2.3 GPU計(jì)算性能

本文采用了安裝好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的性能。

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

測(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)行容器配置采用如下建議。

3.1 容器IO優(yōu)化

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的編排。

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

建議使用宿主機(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)。

3.3 充分利用容器可移植性

用英偉達(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)境配置。

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

在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è)置為只讀。

4 結(jié)束語(yǔ)

容器可以解決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)一步深入。