Kubernetes集群上深度学习负载优化① &nbsh1; Kubernetes集群上深度学习负载优化① 陈 培, 王 超, 段国栋, 王德奎, 王 斌, 王文潇, 孙辽东, 荆荣讯,邢良占, 刘慧兴, 姬贵阳 (浪潮电子信息产业股份有限公司, 济南 250101) 近年来人工智能技术快速发展, 尤其是深度学习方面取得了诸多令人瞩目的成就, 而Kubernetes作为下一代分布式系统的主流, 作为云原生的新生力...
陈 培, 王 超, 段国栋, 王德奎, 王 斌, 王文潇, 孙辽东, 荆荣讯,邢良占, 刘慧兴, 姬贵阳
(浪潮电子信息产业股份有限公司, 济南 250101)
近年来人工智能技术快速发展, 尤其是深度学习方面取得了诸多令人瞩目的成就, 而Kubernetes作为下一代分布式系统的主流, 作为云原生的新生力量, 其发展也是十分迅速, Kubernetes有着完善的组件和工具生态系统, 能够减轻应用程序在公有云或私有云中运行的负担, 并且可以和任何场景结合, 另外Kubernetes的插件化、组件化开发方式能够支持更多定制化的 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 开发工作, 这些优点让越来越多的开发者和互联网企业将人工智能应用部署在Kubernetes集群上. 但由于Kubernetes并不是主要针对深度学习设计, 对深度学习这个特定领域需要做定制优化.
目前针对Kubernetes集群部署深度学习应用已有很多优化尝试, 如国内腾讯的Gaia调度系统[1,2]能够细粒度使用GPU资源, 但是并没有针对数据集使用和分布式训练进行优化. 对于GPU虚拟化使用, NVIDIA推出了Multi-Process Service[3]和virtual GPU (vGPU)[4]两种 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 , 但MPS具有故障传递限制[5]而且vGPU需要授权使用, 其他的很多开源方案在具体实践应用上都有一定的局限性.
本文针对具有一定规模的Kubernetes集群上部署深度学习负载的场景, 设计和实现了一系列的优化方案, 并且已经在实际生产环境中实践, 取得了良好的效果.本文从深度学习所要求的数据处理、graphics processing unit (GPU)计算、分布式训练等几个方面进行优化, 主要优化方面有以下几点: 针对目前人工智能应用只能占用整数GPU卡资源, 难以实现GPU卡资源多任务复用的场景, 提出GPU多任务共享调度技术,能够实现多种应用共享同一张GPU卡资源, 极大限度的挖掘GPU计算力, 提升GPU的使用效率; 随着训练数据集规模的快速增长, 提出训练数据集预加载技术能快速提高数据集读取速度进而提高单机和分布式的训练速度; Kubernetes的原生调度系统和策略并不能很好的满足目前人工智能场景, 因此提出了针对non uniform memory access (NUMA)特性[6]、数据集亲和性的优化调度技术. 本文提出的优化方案覆盖了数据处理、计算等方面, 以上技术极大简化人工智能负载在规模化云原生平台上的部署难度和提高运行效率,同时从实践上来看也验证以上技术对人工智能应用有着显著的提升作用.
云原生上部署深度学习应用时, 会遇到对接不同底层存储的情况, 诸多实验 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 明, 不同存储系统对深度学习训练性能是有着不同程度的影响. 训练开始时, 存储系统的性能会极大的影响训练数据的加载和后续训练数据的持续读取, 如network file system (NFS)[7]等传统存储系统对于海量数据和海量小文件数据的读写性能不是很高, 而在深度学习训练场景(图片、视频、语音等)中的训练数据大多是以文件形式而存在, NFS系统在很多实际场景都会使用, 这样会很大程度上影响训练数据的读取速度进而影响整体训练性能. 高性能存储系统如BeeGFS[8]等, 如果在高并发、大数据量和网络带宽有限制情况下也会出现性能下降问题. 因此, 加速训练过程的数据前期读取和简化在云原生上对不同存储的对接亦是业界热门问题, 本文提出在Kubernetes集群上利用本地高性能存储设备进行数据缓存进而提高训练过程前、中的数据读取速率, 大大减少对存储系统和网络的依赖, 另外根据深度学习任务特性进行针对性优化, 与直接使用传统存储系统的表现相比这些改进提高了训练性能.
Kubernetes集群上完成对数据集缓存需要对训练数据进行很多的针对性处理和设计, 本文对Kubernetes集群上数据集本地和节点缓存两种情形设计了一套缓存系统, 该缓存系统要求需要对数据集生命周期具有细粒度的管理特性. 数据集缓存系统共分为两种方式, 即本地模式和节点缓存模式. 本地模式即直接使用从存储系统中读取和使用数据集, 不做任何缓存, 数据读取速率则完全依赖于存储系统性能或者网络带宽. 节点缓存模式即本文提到的数据缓存加速机制实现, 在运行训练任务的节点上进行数据集缓存和管理, 这样在训练时存储系统性能和网络带宽就不会是瓶颈, 如果底层存储介质为高性能设备如SSD、NVMe则会有更大的增益.
本文针对训练使用数据集的过程做了主要以下优化工作:
(1) 设计dataset-agent 实现在Kubernetes内数据集的本地和节点缓存两种使用模式.
(2) 针对大数据集和海量小文件数据缓存过程进行了优化并提高效率.
(3) 简化使用过程和能够对接不同存储, 使用者无需关注底层存储系统.
两种数据集使用方式的架构如图1和图2所示.
图1 本地模式架构图
本地模式数据读取为直接使用存储系统, 不在本文中详述, 整体架构如图1所示, 实现逻辑为管理节点的Kubernetes API Server接收到用户任务请求后下发训练任务数据集名称、存储位置等信息给Kubernetes,然后Kubernetes的调度器调度训练Pod到相应节点上进行训练, 其中数据集的加载和管理则完全依靠集群内的存储系统进行管理, 如上所述, 性能和使用逻辑则完全依靠存储系统, 由于分布式和共享存储的训练数据读取很大程度上会与网络环境强相关, 因此对训练性能会有一定程度的影响, 取决于网络设备性能和并发量, 节点缓存模式则避免上述问题.
节点缓存模式的架构如图2所示, 各个计算节点上都会部署dataset-agent服务即数据集代理服务, 主要管控数据集缓存的生命周期, 包括数据集缓存创建、删除、更新等信息. 其实现机制为在实际训练开始前提前将训练用数据集缓存到被调度使用的节点, 这样在实际训练时, 训练数据则为本地数据, 不再受存储系统或者网络性能的影响. 具体实现逻辑为Kubernetes管理节点接收到训练任务请求后, 在承载训练任务的Pod中通过init-container形式将训练所需的信息如数据集名称等进行封装, Kubernetes调度Pod成功后, initcontainer首先会将数据集信息下发到部署到该节点上的dataset-agent, 随后dataset-agent进行校验(数据一致性)决定是否访问存储系统进行数据集拉取进行缓存.
图2 节点缓存架构图
如果该节点进行了节点数据缓存, 即在训练节点上的存储设备上就会有相应的训练数据.数据缓存结束后, 随即启动训练程序Pod同时将缓存的数据集进行挂载, 这样就能直接利用本地存储介质进行数据读取和训练, 消除了存储系统和网络的影响, 提高训练速度, 经测试该系统能够支持多种存储系统包括NFS、LusterFS[9]、BeeGFS、HDFS[10]等.
节点缓存技术在部署到Kubernetes集群生产环境中时遇到很多实际问题, 为此针对如下一些主要情况做了优化处理.
(1) 实际过程中一个训练任务会出现挂载多个数据集的情况, 所以将这样一对多的组合作为一个请求任务进行管理, 同一训练任务在多次中只会有一条任务数据, 避免了由于init-container重启导致多次发起数据集缓存请求造成重复数据的情况.
(2) 数据集一致性比对, 主要是针对缓存数据集前的校验工作, 针对数据集名称相同, 通过比对原始数据集文件Summary和节点中数据集缓存的文件Summary来确认数据集和需要的数据集缓存是否相同, 这种比对规则的前提, 即假定节点中的数据集缓存不会变更, 也就是在缓存前生成的文件Summary是准确不变的, 详细 流程 快递问题件怎么处理流程河南自建厂房流程下载关于规范招聘需求审批流程制作流程表下载邮件下载流程设计 见图3.
图3 数据集一致性比对流程示意图
(3) 数据集缓存和镜像拉取并行处理, 在节点没有即将加载运行的镜像情况下, 被调度到该节点的Pod相当一段时间是在进行镜像拉取工作, 由于该段时间资源(CPU、内存等)已经分配, 但是并没有在实际使用这些资源, 因此可以有效利用Pod调度成功并且运行前这一时间段内Pod的空闲资源来提升拉取数据集的效率, 这样相对较小的数据集在镜像拉取完成的同时也缓存完成.
(4) 自动清理数据集缓存, 当计算节点空间不足时,清理缓存数据释放空间就变得十分必要, 系统根据既定的规则自动清除, 清除策略发生在新训练任务缓存数据集, 但缓存空间不足时, 系统亦会清除缓存空间中未在使用的数据集, 且长时间未使用的数据集也会作为清除对象被自动清除, 当清除的空间能够满足新数据集缓存时候, 即停止清除, 这里需要清除空间的大小是所需数据集大小的1.2倍.
(5) 支持多种存储系统下的数据集操作, 即将相关配置信息放到Pod的yaml的环境变量中来解决.
(6) 多个数据集缓存进程并发, 一个节点上的datasetagent可以处理多个数据集缓存操作来提高效率, 同时每个dataset-agent也做了多线程处理, 提高处理速度.
(7) 海量小文件数据集缓存优化处理, 采用对待缓存数据进行压缩后再进行传输完成节点缓存, 这样极大提高带宽的利用率, 实际测试中能够有效减少因为网络传输带来的数据缓存延迟, 聚合传输测试出文件个数为5万打一个包, 每个包的大小约为800 MB左右, 该设置下效率较高, 性能比命令传输提高6-8倍.聚合传输可根据实际业务场景调整聚合传输相关参数,解决机器资源占用、传输效率问题.
(8) 特别针对NFS系统, 通过使用NFS-RDMA技术[11](如图4所示)在小文件传输方面性能提升2倍左右.通过NFS-RDMA V3 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 在小文件传输上提高约1.5倍.
图4 NFS-RDMA技术应用示意图
GPU有着强大的处理并行计算任务能力, 其单一芯片上集成大量的计算核心的架构设计使得GPU对于计算敏感性任务尤其适用. 当前GPU已经广泛应用于视觉、自然语言处理等领域来加速处理过程.
CUDA (compute unified device architecture)是NVIDIA针对GPU架构提供的一套针对GPU的通用API平台, 用户可以通过CUDA简单和快速的使用GPU以达到加速效果. 无论在公有云或者私有云, GPU设备已经广泛部署并使用, 起到了显著的效果. 实际使用中GPU使用实例的类型也是多种多样, 对底层计算资源的要求也不同. 作为底层提供计算资源支持的平台对于用户来说应该是透明的, 需要做到按需索取和使用. 随着深度学习业务广泛铺开和GPU的架构快速迭代, 对于GPU计算资源的需求也变的多样, 从单卡训练到分布式训练, 从独占使用到多任务共享. 但Kubernetes、GPU (除Ampere架构[12])和CUDA原生并不支持GPU细粒度调度和使用. 基于容器的GPU虚拟化的技术在Kubernetes上容器化使用GPU也同时面临如下一些具体问题: 需要指定GPU设备[13]; 只能独享该整个GPU设备[14], 不能多任务共享; 单一GPU使用容器间只能共享主机内存[15].
本文提出一种能够在互相隔离的容器间进行共享同一GPU设备内存的方法来提高GPU的利用率.该方法不需要更改用户的镜像或者训练代码即可达到GPU虚拟化的目的. 通过自定义修改的Kubernetes device plugin可以实现按显存大小来分配GPU资源,即GPU可按显存大小粒度进行调度使用, 不再局限于整卡级别的粒度, 同时进程间可以做到隔离, 保证用户应用不会互相影响. 除此之外利用unified memory技术[16]实现显存的超分使用, 即在实际训练过程中可以保证超出GPU总显存量进行训练, 在适量超出GPU显存容量后保障较大模型正常训练.
由于docker出于安全对权限做了限制导致NVML接口[17]在容器内无法查询正在GPU上运行的进程, 为此本文针对GPU上正在运行进程的查询机制做了优化, 实现在容器内可以查询正在GPU上运行的进程信息, 可以正确的显示该容器内运行进程而不是主机上的进程以保证进程安全和访问安全.
本文针对GPU虚拟化主要做了以下工作:
(1) 通过GPU sharing device plugin 实现在Kubernetes内细粒度调度GPU任务.
(2) 封装CUDA driver API 实现GPU虚拟化使用.
(3) 添加显存超分使用, 即超出GPU总显存量可以继续进行训练.
(4) 优化NVML查询GPU进程机制使得在容器内正确显示GPU上运行的进程信息.
Kubernetes的device plugin插件的主要用途为将计算资源信息(如GPU, RDMA, FPGA[18]等)发布给集群并无需修改Kubernetes核心代码, 图5展示了基本的device plugin与kubelet通讯过程, 主要通过两个步骤实现.
图5 Kubernetes device plugin和各组件关系
(1) 资源发现: 首先每种扩展的资源类型都作为一个device plugin形式展现. Device plugin通过gRPC服务注册到kubelet上. 注册成功后, device plugin将其所管理的设备列表发送给kubelet. 最后kubelet负责将这些扩展资源发布给Kubernetes master;
(2) 资源分配: 当用户申请资源时, 调度器会将相应的Pod调度到具有所申请扩展资源的节点上. 所在节点的kubelet会将设备使用请求发送给device plugin.然后device plugin将相应的扩展资源分配给Pod. 但针对GPU等设备, 直接使用开源device plugin并不能针对GPU内存进行细粒度的使用和分配.
本文中将现有的一些扩展设备资源(如GPU等)的device plugin进行优化, 实现了以下功能: 基于Kubernetes标准的device plugin机制, 支持接入多种AI计算资源; 多种可调度的资源在业务上统一建模, 以资源名称、数量、类型等; 信息描述接入集群的异构实现, 实现统一的调度、运维管理; 实现多device plugin管理插件, 由一个device plugin实现多个异构资源的注册、分配等, 且plugin的资源使用仅需要0.1 CPU/0.3 GB内存, 降低运维成本; 实现GB粒度的资源管理以及GPU复用场景下的资源管理.
整体vCUDA架构设计和流程如图6所示, 主要由3部分组成: GPU sharing device plugin (以下简称GS device plugin), 调度器scheduler和vCUDA library.
图6 vCUDA架构和流程示意图
(1) GS device plugin
其中经过修改和优化的GS device plugin 在各个节点上运行负责建立虚拟GPU设备和与kubelet进行通讯. GS device plugin发现设备上报时将GPU显存视为一种资源进行上报, 这样GPU显存也可以作为可调度的Kubernetes集群资源进行使用.
(2)调度器 scheduler
调度器为GS device plugin提供其所申请的调度服务, 调度成功后调度器会返回包含所分配GPU信息的响应.
(3) vCUDA library
在运行的Pod中vCUDA负责实际的内存控制.vCUDA库通过挂载的方式与运行的Pod进行绑定. 当容器中应用开始运行时, vCUDA通过对训练过程中内存相关的API进行劫持从而实现内存大小的控制和隔离, 主要由以下几个部分组成:
(1) vCUDAManager: vCUDA library的总控制, 对于CUDA的操作均需要通过该类对象, 单例运行只初始化一次. 其中主要包括cudaManager、nvmlManager、gpuMemoryManager和dlsym的map管理.
(2) cudaManager: 管理所有CUDA API的劫持, 主要是cuMalloc类似的函数, 当分配显存时调用此类的接口来控制OOM问题.
(3) nvmlManager: NVML API的劫持管理类, 主要是获取NVIDIA GPU卡上各个进程运行的详细信息,如显存和进程PID.
(4) gpuMemoryManger: 记录各个GPU卡的显存利用信息, 当分配显存时会调用此类API判断是否OOM.
GPU虚拟过程主要通过GPU的显存申请和分配来实现. 本文中以1 GB显存作为基本粒度, 一个最终的内存分配单元作为一个虚拟GPU设备.当用户申请一个规定大小(GB粒度)的虚拟GPU调度请求后, 调度器会将请求发布到给个节点上的kubelet, 由于GS device plugin已经将其所管理的设备列表和资源信息发送给kubelet, 因此GS device plugin 在收到所分配的Pod为虚拟GPU的请求后将Pod所要创建的allocateResponse返回给kubelet进行资源创建即可, 其中包括基本的Pod环境变量, Pod挂载卷配置 (例如NVIDIA驱动, CUDA库, vCUDA库)和相应设备.
另外通过dlsym劫持函数的map对象中, 针对NVML库设置单独劫持进行处理主要是为了防止其他应用通过dlsym来调用CUDA和NVML的API, 例如nvidia-smi命令, 在使用CUDA劫持库时始终保持结果一致性. 具体使用到的CUDA和NVML API如表1和表2所示.
浙公网安备 33021202002483