GPU加速高性能計(jì)算平臺(tái)上容器性能評(píng)估

胡 鶴,趙 毅,龐 飛

(中科院計(jì)算機(jī) 網(wǎng)絡(luò)信息中心，北京 100190)

在高性能計(jì)算領(lǐng)域，并行計(jì)算具有強(qiáng)環(huán)境依賴的特點(diǎn)，所需的軟件堆棧通常很復(fù)雜，涉及編譯器、通信中間件及數(shù)學(xué)庫(kù).虛擬機(jī)和容器這2種云服務(wù)商常用的虛擬化的方式，具有部署簡(jiǎn)單、快速遷移和彈性伸縮等優(yōu)點(diǎn)，帶來不同依賴環(huán)境下應(yīng)用程序的可移植性，幫助高性能計(jì)算平臺(tái)降低使用門檻.而容器鏡像相對(duì)于虛擬機(jī)的快照更小，可以快速的在具備容器環(huán)境的物理機(jī)上部署，且非應(yīng)用層資源占用更少，啟動(dòng)時(shí)間更短.

不同容器方案會(huì)在鏡像格式、隔離與加載名字空間、啟動(dòng)方式上有區(qū)別，常用的包括Docker[1]及Singularity[2].位于美國(guó)橡樹嶺國(guó)家實(shí)驗(yàn)室的著名的超級(jí)計(jì)算機(jī)SUMMIT提供了容器服務(wù)[3].SUMMIT提供的容器平臺(tái)將Docker容器作為管理對(duì)象，以開源的Kubernetes[4]作為容器編排引擎組件用于自動(dòng)化Docker的部署、擴(kuò)展和管理，提供了一套完整的容器應(yīng)用平臺(tái).美國(guó)國(guó)家能源研究科學(xué)計(jì)算中心(national energy research scientific computing center，NERSC)利用Docker容器技術(shù)提高其HPC系統(tǒng)的靈活性和可用性[5].天河二號(hào)實(shí)踐了基于容器的HPC/大數(shù)據(jù)處理，利用Docker整合HPC軟件棧，優(yōu)化了高性能計(jì)算環(huán)境的公共服務(wù)能力與模式，優(yōu)化用戶應(yīng)用體驗(yàn)[6].Singularity是勞倫斯伯克利國(guó)家實(shí)驗(yàn)室(lawrence livermore national laboratory，LLNL)專門為大規(guī)模、跨節(jié)點(diǎn)HPC工作負(fù)載而開發(fā)的容器化技術(shù)，但相比之下HPC應(yīng)用研發(fā)人員及系統(tǒng)管理員對(duì)Docker技術(shù)更為了解和熟知，應(yīng)用范圍更廣.

為評(píng)估不同高性能計(jì)算程序移植到Docker中的適用性，評(píng)估各種影響計(jì)算效率的因素，相關(guān)研究對(duì)容器性能和裸機(jī)性能做出了比對(duì).并行應(yīng)用程序性能的影響因素主要包括計(jì)算、通信以及I/O模式等.Felter等人在2014年的IBM研究報(bào)告[7]中，得出Docker的性能表現(xiàn)優(yōu)于幾乎所有測(cè)試場(chǎng)景中的虛擬化性能，IO方面順序、隨機(jī)讀寫幾乎沒有性能損失，但Docker的分層文件存儲(chǔ)方式帶來一定的IO性能損耗，其本身的NAT還為網(wǎng)絡(luò)密集型工作負(fù)載帶來了較大開銷.文獻(xiàn)[8]利用NPB基準(zhǔn)測(cè)試程序，對(duì)比同樣進(jìn)程數(shù)量，但容器個(gè)數(shù)及容器內(nèi)部進(jìn)程數(shù)不同的情況下，基準(zhǔn)測(cè)試程序的性能，證明在HPC工作負(fù)載較高的情況下，同一宿主機(jī)上容器的開銷會(huì)增加導(dǎo)致性能降低.

隨著加速GPU在高性能計(jì)算領(lǐng)域的應(yīng)用，大部分高性能平臺(tái)都采用了CPU+GPU的混合架構(gòu)[9]，GPU卡成為作為重要的計(jì)算資源，且為支持智能業(yè)務(wù)，大都有往容器遷移演進(jìn)的趨勢(shì).如何利用GPU資源成為容器高性能計(jì)算平臺(tái)亟需解決的問題.但是在應(yīng)用容器技術(shù)的HPC環(huán)境下，加速應(yīng)用的效果尚未深入研究.

本文執(zhí)行全面的基準(zhǔn)測(cè)試，測(cè)試容器虛擬化解決方案下集群各項(xiàng)性能表現(xiàn)，包括I/O、并行通信，并評(píng)估容器虛擬化對(duì)GPU加速性能的影響，有助于應(yīng)用根據(jù)自身計(jì)算、通信、IO模式等特點(diǎn)，確定是否選擇容器虛擬化方案.

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)都配備有2個(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來執(zhí)行所有測(cè)試，并行環(huán)境部署了OpenMPI1.6.5版.

圖1 測(cè)試鏡像軟件棧

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

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

2.1 文件系統(tǒng)訪問

為測(cè)試文件系統(tǒng)訪問性能，使用Pynamic作為IO壓力測(cè)試工具.Pynamic是基于Python編寫的并行應(yīng)用程序，模擬基于python的科學(xué)程序各種動(dòng)態(tài)鏈接和加載行為[12].Pynamic模擬大規(guī)模Python動(dòng)態(tài)加載程序，生成指定數(shù)量的Python動(dòng)態(tài)模塊和實(shí)用程序庫(kù)對(duì)象，利用pyMPI擴(kuò)展提供的MPI通信庫(kù)，將配置好數(shù)量的動(dòng)態(tài)庫(kù)加載到進(jìn)程中，如許多并行進(jìn)程同時(shí)加載動(dòng)態(tài)Python模塊時(shí)，會(huì)創(chuàng)建文件系統(tǒng)訪問風(fēng)暴.Pynamic通過計(jì)量運(yùn)行程序時(shí)啟動(dòng)、模塊導(dǎo)入及訪問時(shí)間，可獲取文件系統(tǒng)操作及執(zhí)行例程的速度.表1顯示了宿主機(jī)和容器的測(cè)試結(jié)果.可以得出容器的性能基本與宿主機(jī)性能保持一致，最大開銷為8%.

表1 Pynamic測(cè)試結(jié)果比較

2.2 通信性能

該測(cè)試的目的是將容器間通信與物理機(jī)器之間的通信，從網(wǎng)絡(luò)通信及MPI并行通信方面進(jìn)行比較，衡量容器通信的性能開銷.

為測(cè)試容器間直接進(jìn)行網(wǎng)絡(luò)通信的性能，InfiniBand設(shè)備廠商Mellanox提供了基準(zhǔn)測(cè)試工具用于測(cè)試InfiniBand網(wǎng)卡帶寬和網(wǎng)絡(luò)延遲[13].圖2顯示了IB網(wǎng)讀寫帶寬的測(cè)試結(jié)果.得到2臺(tái)測(cè)試宿主機(jī)的帶寬約為 50 Gbps，接近理論值.

圖2 IB網(wǎng)傳輸性能

為使相同主機(jī)的容器能夠通信，Docker將主機(jī)上的所有容器附加到1個(gè)網(wǎng)橋，因此容器間的通信需要經(jīng)過Docker橋接的處理過程，如圖3所示.為測(cè)試橋接對(duì)容器通信性能的影響，在不同宿主機(jī)上各啟動(dòng)一個(gè)容器，用netperf測(cè)試通信性能[14].Netperf主要針對(duì)基于TCP或UDP的傳輸，測(cè)試時(shí)在連接數(shù)為6的情況下, 網(wǎng)絡(luò)帶寬達(dá)到最大，容器間的傳輸帶寬的測(cè)試結(jié)果為 44 Gbps，開銷存在于宿主機(jī)TCP/IP協(xié)議棧及Docker橋接的處理過程，會(huì)占用較多的CPU時(shí)間和內(nèi)存資源.

圖3 Docker網(wǎng)絡(luò)結(jié)構(gòu)示意圖

為測(cè)試容器的并行通信性能開銷，使用廣泛使用的MPI庫(kù)的帶寬及延時(shí)基準(zhǔn)OSU[15]測(cè)試容器間點(diǎn)對(duì)點(diǎn)MPI通信性能.測(cè)試結(jié)果如圖4所示.從測(cè)試結(jié)果可以看出，宿主機(jī)和容器通信的峰值帶寬分別為 6 694 MB/s 以及 5 887 MB/s.Docker容器與宿主機(jī)相比在并行通信方面有約為10%的開銷.

使用基準(zhǔn)測(cè)試程序IMB[16]，選擇4種常見的集合通信方式 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)1個(gè)容器，容器內(nèi)啟動(dòng)20進(jìn)程.

測(cè)試結(jié)果如圖5所示.在并行通信性能測(cè)試實(shí)驗(yàn)中發(fā)現(xiàn)，容器并行通信性能與宿主機(jī)接近，但隨著消息包增大通信延遲差距增大.原因是容器中不能識(shí)別IB卡，通信只能通過IB卡生成的虛擬網(wǎng)橋進(jìn)行，產(chǎn)生了系統(tǒng)CPU和內(nèi)存開銷.故對(duì)于通信負(fù)載較高的通信密集型應(yīng)用程序，當(dāng)所有內(nèi)核都被MPI進(jìn)程占用時(shí)，使用Docker橋接網(wǎng)絡(luò)的方式可能使通信性能下降導(dǎo)致應(yīng)用程序效率降低.

圖4 MPI點(diǎn)對(duì)點(diǎn)通信性能

圖5 集合通信性能(40進(jìn)程)

2.3 GPU計(jì)算性能

本文采用了安裝好GPU驅(qū)動(dòng)的Docker鏡像nvidia-docker，可以在容器中能夠直接訪問GPU資源.這種方式可以解決不同CUDA版本在容器與宿主機(jī)的匹配問題.

本文使用Mixbench對(duì)容器GPU計(jì)算性能與宿主機(jī)進(jìn)行比對(duì)[17].Mixbench是HIP平臺(tái)的開發(fā)者推動(dòng)的一項(xiàng)開源的GPU性能基準(zhǔn)測(cè)試工具，利用Roof-line Model測(cè)試浮點(diǎn)計(jì)算能力及顯存性能，能夠得到理論計(jì)算峰值(Flops/byte)、以及實(shí)際計(jì)算過程中所能達(dá)到的最大值.測(cè)試結(jié)果如表2所示，宿主機(jī)及容器沒有明顯差異.

表2 Mixbench測(cè)試結(jié)果比較

為衡量容器對(duì)GPU顯存帶寬的影響，使用BabelStream[18]進(jìn)行測(cè)試.測(cè)試結(jié)果如表3所示.單顆GPU現(xiàn)存帶寬為 424 762.4 MB/s.,Docker單顆GPU卡實(shí)測(cè)顯存拷貝帶寬為 422 473 MB/s.容器比宿主機(jī)帶寬性能略有下降，開銷最高為0.54%.

表3 BabelStream測(cè)試結(jié)果比較

3 結(jié)語

在HPC領(lǐng)域，使用容器可以解決開發(fā)環(huán)境的一系列問題，能夠?qū)?yīng)用程序和依賴打包進(jìn)輕量級(jí)可移植的環(huán)境中，帶來了應(yīng)用程序跨平臺(tái)的可移植性，實(shí)現(xiàn)輕量級(jí)的虛擬化，輕松部署應(yīng)用.本文評(píng)估高性能計(jì)算環(huán)境下Docker容器的性能表現(xiàn)，從計(jì)算、IO、通信3方面，通過基準(zhǔn)軟件衡量容器本身開銷對(duì)系統(tǒng)性能的影響，并對(duì)結(jié)果做出分析，為應(yīng)用程序選擇容器提供依據(jù).

測(cè)試結(jié)果表明，Docker可以很好的支持GPU、Infiniband等硬件，使用容器中的MPI庫(kù)能夠帶來更好的可移植性.Docker簡(jiǎn)單可控一行配置輕松獲取 GPU 計(jì)算能力，為GPU帶來了微不足道的開銷和顯存性能.在GPU的計(jì)算能力和顯存性能方面，Docker帶來的開銷可以忽略.I/O方面，由于容器通過bind mount的形式與宿主機(jī)共享文件系統(tǒng)，因此性能損失可以接受.在并行通信性能測(cè)試實(shí)驗(yàn)中發(fā)現(xiàn)，容器并行通信性能與宿主機(jī)接近，但隨著消息包增大通信延遲差距增大.由于容器通信使用主機(jī)網(wǎng)絡(luò)橋接的方式，容器中不能識(shí)別IB卡，通信只能通過IB卡生成的虛擬網(wǎng)橋進(jìn)行，需要CPU中斷處理.故對(duì)于通信負(fù)載較高的通信密集型應(yīng)用程序，當(dāng)所有內(nèi)核都被MPI進(jìn)程占用時(shí)，使用主機(jī)網(wǎng)絡(luò)的方式可能使通信性能下降導(dǎo)致應(yīng)用程序效率降低.

在本文基準(zhǔn)測(cè)試中觀察到的容器總體性能開銷是可以容忍的，如僅考慮性能，Docker適合在弱通信，rdma特性要求不高的并行應(yīng)用程序.另外，容器方案還需要考慮隔離性、安全性、穩(wěn)定性及可管理性等.構(gòu)建容器應(yīng)用生態(tài)圈(從哪里獲取容器鏡像)仍是容器在HPC領(lǐng)域推廣的主要障礙.這增加了性能調(diào)整和設(shè)計(jì)有效的并行解決方案的挑戰(zhàn).