胡 鶴,趙 毅,龐 飛

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

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

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

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

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

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

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

本文測試是基于中國科技云基礎(chǔ)設(shè)施“人工智能計算及數(shù)據(jù)服務(wù)應(yīng)用平臺”進行的，數(shù)據(jù)傳輸使用計算存儲網(wǎng)絡(luò)為 56 Gb/s FDR Infiniband高速網(wǎng)絡(luò)，每個節(jié)點都配備有2個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版.

圖1 測試鏡像軟件棧

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

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

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

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

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

2.2 通信性能

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

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

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

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

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

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

使用基準測試程序IMB[16]，選擇4種常見的集合通信方式 bcast、allgather、allreduce及alltoall進行宿主機和容器的集合通信性能測試.對比兩種情況的測試結(jié)果：

1)每臺宿主機啟動20進程；

2)每臺宿主機啟動1個容器，容器內(nèi)啟動20進程.

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

圖4 MPI點對點通信性能

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

2.3 GPU計算性能

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

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

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

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

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

3 結(jié)語

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

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

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