GPU加速高性能计算平台上容器性能评估

胡 鹤,赵 毅,庞 飞

(中科院计算机 网络信息中心，北京 100190)

在高性能计算领域，并行计算具有强环境依赖的特点，所需的软件堆栈通常很复杂，涉及编译器、通信中间件及数学库.虚拟机和容器这2种云服务商常用的虚拟化的方式，具有部署简单、快速迁移和弹性伸缩等优点，带来不同依赖环境下应用程序的可移植性，帮助高性能计算平台降低使用门槛.而容器镜像相对于虚拟机的快照更小，可以快速的在具备容器环境的物理机上部署，且非应用层资源占用更少，启动时间更短.

不同容器方案会在镜像格式、隔离与加载名字空间、启动方式上有区别，常用的包括Docker[1]及Singularity[2].位于美国橡树岭国家实验室的著名的超级计算机SUMMIT提供了容器服务[3].SUMMIT提供的容器平台将Docker容器作为管理对象，以开源的Kubernetes[4]作为容器编排引擎组件用于自动化Docker的部署、扩展和管理，提供了一套完整的容器应用平台.美国国家能源研究科学计算中心(national energy research scientific computing center，NERSC)利用Docker容器技术提高其HPC系统的灵活性和可用性[5].天河二号实践了基于容器的HPC/大数据处理，利用Docker整合HPC软件栈，优化了高性能计算环境的公共服务能力与模式，优化用户应用体验[6].Singularity是劳伦斯伯克利国家实验室(lawrence livermore national laboratory，LLNL)专门为大规模、跨节点HPC工作负载而开发的容器化技术，但相比之下HPC应用研发人员及系统管理员对Docker技术更为了解和熟知，应用范围更广.

为评估不同高性能计算程序移植到Docker中的适用性，评估各种影响计算效率的因素，相关研究对容器性能和裸机性能做出了比对.并行应用程序性能的影响因素主要包括计算、通信以及I/O模式等.Felter等人在2014年的IBM研究报告[7]中，得出Docker的性能表现优于几乎所有测试场景中的虚拟化性能，IO方面顺序、随机读写几乎没有性能损失，但Docker的分层文件存储方式带来一定的IO性能损耗，其本身的NAT还为网络密集型工作负载带来了较大开销.文献[8]利用NPB基准测试程序，对比同样进程数量，但容器个数及容器内部进程数不同的情况下，基准测试程序的性能，证明在HPC工作负载较高的情况下，同一宿主机上容器的开销会增加导致性能降低.

随着加速GPU在高性能计算领域的应用，大部分高性能平台都采用了CPU+GPU的混合架构[9]，GPU卡成为作为重要的计算资源，且为支持智能业务，大都有往容器迁移演进的趋势.如何利用GPU资源成为容器高性能计算平台亟需解决的问题.但是在应用容器技术的HPC环境下，加速应用的效果尚未深入研究.

本文执行全面的基准测试，测试容器虚拟化解决方案下集群各项性能表现，包括I/O、并行通信，并评估容器虚拟化对GPU加速性能的影响，有助于应用根据自身计算、通信、IO模式等特点，确定是否选择容器虚拟化方案.

1.测试环境配置

本文测试是基于中国科技云基础设施“人工智能计算及数据服务应用平台”进行的，数据传输使用计算存储网络为 56 Gb/s FDR Infiniband高速网络，每个节点都配备有2个Intel Xeon E5-2650处理器(每个具有12个内核，频率为 2.40 GHz)，256 GB RAM.每个节点配有8块Tesla P100 GPU卡.使用具有Linux内核3.10.0的64位CentOS 7.6来执行所有测试，并行环境部署了OpenMPI1.6.5版.

图1 测试镜像软件栈

采用NVIDIA提供的支持GPU的Docker镜像作为基础镜像，该镜像能够发现宿主机驱动文件以及GPU设备，并且将这些挂载到来自Docker守护进程的请求中，以此来支持Docker GPU的使用[10].按照文献[11]的操作对容器使用IB进行适配，将Docker默认的网络地址设置成IB卡的地址，在容器内部安装配置ssh做进程启动.为了保持一致性和统一性，容器和宿主机具有相同的软件堆栈如图1所示，配置了相同的MPI版本.启动内核后，Docker将文件系统、进程、网络等操作系统管理的资源划分到不同的namespace中，创建隔离的硬件资源.为衡量Docker运行时的性能，以及衡量硬件在容器内虚拟化后相应的系统开销，本文使用基准测试程序分别针对文件系统I/O性能、并行通信性能与GPU计算性能进行测试.

2 测试结果与性能评估

2.1 文件系统访问

为测试文件系统访问性能，使用Pynamic作为IO压力测试工具.Pynamic是基于Python编写的并行应用程序，模拟基于python的科学程序各种动态链接和加载行为[12].Pynamic模拟大规模Python动态加载程序，生成指定数量的Python动态模块和实用程序库对象，利用pyMPI扩展提供的MPI通信库，将配置好数量的动态库加载到进程中，如许多并行进程同时加载动态Python模块时，会创建文件系统访问风暴.Pynamic通过计量运行程序时启动、模块导入及访问时间，可获取文件系统操作及执行例程的速度.表1显示了宿主机和容器的测试结果.可以得出容器的性能基本与宿主机性能保持一致，最大开销为8%.

表1 Pynamic测试结果比较

2.2 通信性能

该测试的目的是将容器间通信与物理机器之间的通信，从网络通信及MPI并行通信方面进行比较，衡量容器通信的性能开销.

为测试容器间直接进行网络通信的性能，InfiniBand设备厂商Mellanox提供了基准测试工具用于测试InfiniBand网卡带宽和网络延迟[13].图2显示了IB网读写带宽的测试结果.得到2台测试宿主机的带宽约为 50 Gbps，接近理论值.

图2 IB网传输性能

为使相同主机的容器能够通信，Docker将主机上的所有容器附加到1个网桥，因此容器间的通信需要经过Docker桥接的处理过程，如图3所示.为测试桥接对容器通信性能的影响，在不同宿主机上各启动一个容器，用netperf测试通信性能[14].Netperf主要针对基于TCP或UDP的传输，测试时在连接数为6的情况下, 网络带宽达到最大，容器间的传输带宽的测试结果为 44 Gbps，开销存在于宿主机TCP/IP协议栈及Docker桥接的处理过程，会占用较多的CPU时间和内存资源.

图3 Docker网络结构示意图

为测试容器的并行通信性能开销，使用广泛使用的MPI库的带宽及延时基准OSU[15]测试容器间点对点MPI通信性能.测试结果如图4所示.从测试结果可以看出，宿主机和容器通信的峰值带宽分别为 6 694 MB/s 以及 5 887 MB/s.Docker容器与宿主机相比在并行通信方面有约为10%的开销.

使用基准测试程序IMB[16]，选择4种常见的集合通信方式 bcast、allgather、allreduce及alltoall进行宿主机和容器的集合通信性能测试.对比两种情况的测试结果：

1)每台宿主机启动20进程；

2)每台宿主机启动1个容器，容器内启动20进程.

测试结果如图5所示.在并行通信性能测试实验中发现，容器并行通信性能与宿主机接近，但随着消息包增大通信延迟差距增大.原因是容器中不能识别IB卡，通信只能通过IB卡生成的虚拟网桥进行，产生了系统CPU和内存开销.故对于通信负载较高的通信密集型应用程序，当所有内核都被MPI进程占用时，使用Docker桥接网络的方式可能使通信性能下降导致应用程序效率降低.

图4 MPI点对点通信性能

图5 集合通信性能(40进程)

2.3 GPU计算性能

本文采用了安装好GPU驱动的Docker镜像nvidia-docker，可以在容器中能够直接访问GPU资源.这种方式可以解决不同CUDA版本在容器与宿主机的匹配问题.

本文使用Mixbench对容器GPU计算性能与宿主机进行比对[17].Mixbench是HIP平台的开发者推动的一项开源的GPU性能基准测试工具，利用Roof-line Model测试浮点计算能力及显存性能，能够得到理论计算峰值(Flops/byte)、以及实际计算过程中所能达到的最大值.测试结果如表2所示，宿主机及容器没有明显差异.

表2 Mixbench测试结果比较

为衡量容器对GPU显存带宽的影响，使用BabelStream[18]进行测试.测试结果如表3所示.单颗GPU现存带宽为 424 762.4 MB/s.,Docker单颗GPU卡实测显存拷贝带宽为 422 473 MB/s.容器比宿主机带宽性能略有下降，开销最高为0.54%.

表3 BabelStream测试结果比较

3 结语

在HPC领域，使用容器可以解决开发环境的一系列问题，能够将应用程序和依赖打包进轻量级可移植的环境中，带来了应用程序跨平台的可移植性，实现轻量级的虚拟化，轻松部署应用.本文评估高性能计算环境下Docker容器的性能表现，从计算、IO、通信3方面，通过基准软件衡量容器本身开销对系统性能的影响，并对结果做出分析，为应用程序选择容器提供依据.

测试结果表明，Docker可以很好的支持GPU、Infiniband等硬件，使用容器中的MPI库能够带来更好的可移植性.Docker简单可控一行配置轻松获取 GPU 计算能力，为GPU带来了微不足道的开销和显存性能.在GPU的计算能力和显存性能方面，Docker带来的开销可以忽略.I/O方面，由于容器通过bind mount的形式与宿主机共享文件系统，因此性能损失可以接受.在并行通信性能测试实验中发现，容器并行通信性能与宿主机接近，但随着消息包增大通信延迟差距增大.由于容器通信使用主机网络桥接的方式，容器中不能识别IB卡，通信只能通过IB卡生成的虚拟网桥进行，需要CPU中断处理.故对于通信负载较高的通信密集型应用程序，当所有内核都被MPI进程占用时，使用主机网络的方式可能使通信性能下降导致应用程序效率降低.

在本文基准测试中观察到的容器总体性能开销是可以容忍的，如仅考虑性能，Docker适合在弱通信，rdma特性要求不高的并行应用程序.另外，容器方案还需要考虑隔离性、安全性、稳定性及可管理性等.构建容器应用生态圈(从哪里获取容器镜像)仍是容器在HPC领域推广的主要障碍.这增加了性能调整和设计有效的并行解决方案的挑战.