高性能计算集群如何工程化

背景

随着人工智能的发展,高性能服务出现在工程师的日程上,模型训练可谓热火朝天,但是问题也就此而来:资源分配和任务调度缺乏统一管理,无法及时获悉任务执行情况,造成资源浪费;资源占用不能直观监控,不能及时获知服务性能情况;每次跑模型任务都需要安装依赖软件,算法工程师还需要维护服务环境,精力浪费在核心工作之外;甚至部分数据从线下环境操作,数据安全也是一大隐患等。

鉴于上述问题,我们考虑将零散在各部门的高性能服务器组成高性能计算机群HPC(High Performance Computing)用工程化的方式统一管理,算法工程师不再自己维护服务环境,也不再考虑如何调度集群,而是专注于自己的模型训练,把这些繁琐零碎的工作交给系统处理,一个理想而简洁的架构如图所示:

集群作业调度系统

集群系统具有低成本、高性能的特性,提供了强大的批处理和并行计算能力,代表了高性能计算机发展的新方向。在集群或者超级计算机平台上,必须通过其上提供的作业管理系统来提交计算任务,避免直接使用 mpiexec 或 mpirun 来运行任务。作为集群系统软件的重要组成部分,集群作业管理系统可以根据用户的需求,统一管理和调度集群的软硬件资源,保证用户作业公平合理地共享集群资源,提高系统利用率和吞吐率。我们了解几个常用的集群作业管理系统:PBS、LSF、 SLURM、GPU Sharding。

PBS

PBS(Protable Batch System)最初由NASA的Ames研发中心开发,主要为了提供一个满足异构计算网络需要的软件包,用于灵活的批处理,特别是满足高性能计算的需要,如集群系统、超级计算机和大规模并行系统。

PBS的主要特点有:

  • 代码开放,免费获取;
  • 支持批处理、交互式作业和串行、多种并行作业,如MPI、PVM、HPF、MPL;
  • PBS是功能最为齐全,历史最悠久,支持最广泛的本地集群调度器之一。

PBS目前包括 openPBS、PBS Pro 和 Torque 三个主要分支。其中OpenPBS是最早的PBS系统, 目前已经没有太多后续开发,PBS pro是PBS的商业版本, 功能最为丰富。Torque是Clustering公司接过了OpenPBS, 并给与后续支持的一个开源版本。

总的来说,PBS 作业管理系统会根据一个集群上的可用计算节点的计算资源管理和调度所有计算作业(无论是批处理作业还是交互式作业)。

参考文章:《PBS(Portable BatchSystem)简介》、《PBS 作业管理系统

LSF

LSF 简介

LSF (Load Sharing Facility)是由 platform 公司开发的公布资源管理工具。它用来调度、监视、分析联网计算的负载,可以对集群机群的资源统一调度和监控。

LSF通过集中监控和调度,充分共享计算的CPU、内存、磁盘、License等资源。

常用的LSF有 Platform LSF,IBM SPECTRUM LSF。目前 IBM 的 LSF 支持 kubernetes。

LSF 架构

使用案例

  • http://scc.ustc.edu.cn/ 中科大超算中心
  • http://www.sccas.cn/ 中科院超算中心
  • http://www.ssc.net.cn/ 上海超算中心

参考资料:《LSF系统介绍》、《LSF简单使用手册》、《IBM LSF作业调度系统(v9.1)

SLURM

Slurm 简介

SLURM (Simple Linux Utility for Resource Management)是一种可用于大型计算节点集群的高度可伸缩和容错的集群管理器和作业调度系统,被世界范围内的超级计算机和计算集群广泛采用。SLURM 维护着一个待处理工作的队列并管理此工作的整体资源利用。它以一种共享或非共享的方式管理可用的计算节点(取决于资源的需求),以供用户执行工作。SLURM 会为任务队列合理地分配资源,并监视作业至其完成。如今,SLURM 已经成为了很多最强大的超级计算机上使用的领先资源管理器。

slurm不需要对操作系统内核进行修改,而是相对独立的。作为集群工作负载管理器。slurm有三个关键功能:

  1. 首先,它在一段时间内为用户分配独占或者非独占的计算资源,以便他们能够执行工作任务
  2. 其次,它能提供一个框架,用于在分配的节点集上启动,执行,监视工作,通常是并行作业任务
  3. 最后,它通过管理挂起的工作队列,来仲裁资源争夺问题

Slurm 架构

如下图2.1所示,slurm构成有:

  1. 运行在每个计算节点上的slurmd守护进程
  2. 运行在管理节点上的中央slurmctld守护进程(可选的故障切换节点模式)

用户命令,包括:sacctsallocsattachsbatchsbcastscancelscontrolsinfosmapsqueuesrunstriggersviwsreport等,均可以在集群的任何地方运行。

如下图所示,由这些 Slurm 守护程序管理的实体,包括:

  • 计算资源node
  • 计算资源组成的逻辑集partition
  • 分配给用户指定的时间量的资源分配job
  • 作业中的一组任务(有可能是并行任务)

这些分区可以被视为作业队列, 其中每一个都有各种约束, 如作业大小限制、工作时间限制、允许使用它的用户等。按照优先级排序的作业,从队列中分配节点,直至该队列分资源,如节点,处理器,内存等耗尽。一旦一个job分配了一组节点后, 用户就能够按照任何分配配置,以作业步骤形式启动并行工作。例如, 可以启动一个作业步骤, 利用分配给作业的所有节点, 或者多个作业步骤可以独立地使用分配的一部分。

使用案列

  • http://www.nscc-gz.cn/ 天河二号

参考文章:《SLURM 资源管理系统》、《HPC上的SLURM使用技巧》《Slurm Workload Manager》《slurm用户快速入门手册

GPU Sharing Scheduler

GPU Sharing简介

全球主要的容器集群服务厂商的Kubernetes服务都提供了Nvidia GPU容器调度能力,但是通常都是将一个GPU卡分配给一个容器。这可以实现比较好的隔离性,确保使用GPU的应用不会被其他应用影响;对于深度学习模型训练的场景非常适合,但是如果对于模型开发和模型预测的场景就会比较浪费。 大家的诉求是能够让更多的预测服务共享同一个GPU卡上,进而提高集群中Nvidia GPU的利用率。而这就需要提供GPU资源的划分,而这里GPU资源划分的维度指的就是GPU显存和Cuda Kernel线程的划分。通常在集群级别谈支持共享GPU,通常是两件事情:

1.调度
2.隔离,我们这里主要讨论的是调度,隔离的方案未来会基于 Nvidia 的 MPS 来实现。

而对于细粒度的 GPU 卡调度,目前 Kubernetes 社区并没有很好的方案,这是由于 Kubernetes 对于 GPU 这类扩展资源的定义仅仅支持整数粒度的加加减减,无法支持复杂资源的分配。比如用户希望使用 Pod A 占用半张 GPU 卡,这在目前 Kubernetes 的架构设计中无法实现资源分配的记录和调用。这里挑战是多卡 GPU 共享是实际矢量资源问题,而 Extened Resource 是标量资源的描述。

针对此问题,阿里云团队设计了一个 outoftree 的共享 GPU 调度方案,该方案依赖于 Kubernetes 的现有工作机制:

  • Extended Resource定义
  • Scheduler Extender机制
  • Device Plugin机制

GPU Sharing 设计和架构

参考文章:《开源工具GPU Sharing:支持Kubernetes集群细粒度》、《gpushare-scheduler-extender

GPUs型号对比

Kubernetes GPU

  1. 如何使用 Kubernetes GPU 集群自动化深度学习训练
  2. 开源工具GPU Sharing:支持Kubernetes集群细粒度
  3. Nvidia GPU如何在Kubernetes 里工作
  4. 集群、超算:通过PBS、LSF或SLURM脚本提交任务

点击量:147

发表评论