华为云Volcano：让企业AI算力像火山一样爆发

欢迎添加华为云小助手微信（微信号：HWCloud002 或 HWCloud003），输入关键字“加群”，加入华为云线上技术讨论群；输入关键字“最新活动”，获取华为云最新特惠促销。华为云诸多技术大咖、特惠活动等你来撩！

作者：TommyLike

序：

在今年6月上海的KubeCon2019上，作为开源领域的积极贡献者和推进者，华为云开源了面向高性能计算的云原生批量计算平台——Volcano，寄寓助力企业算力像火山一样爆发。该项目是基于华为云容器平台大规模高性能计算应用管理的最佳实践，在原生K8s的基础上，补齐了作业(Job)调度和设备管理等多方面的短板。

目前，Volcano在华为云上对接了包括一站式AI开发平台ModelArts、云容器实例CCI、云容器引擎CCE在内的多款服务，是整个高性能计算领域不可或缺的基座。在今年5月斯坦福大学发布最新的DAWNBench榜单中，华为云ModelArts就以2分43秒的成绩获得图像识别训练世界第一，其背后就离不开Volcano的助力。

同时，得益于Volcano的高性能任务处理机制，华为云基因容器服务将基因测序的效率提升了30%，成为基因测序行业的一匹黑马，受到国内多家头部基因测序企业的青睐。自开源以来，华为云Volcano项目已经吸引了来自腾讯、百度、快手以及AWS等多个公司的贡献者。

背景：

随着容器化以及容器编排技术的普及，越来越多的上层业务正开始拥抱K8s生态，但无法否认的是，针对人工智能和大数据作业场景，原生K8s的支持度并不高，终端用户如果想要将现有的业务迁移到K8s平台，很有可能会面临以下问题:

成组调度(Gang Scheduling): 一个BigData/AI的作业通常会包含多个任务，而业务逻辑一般要求Pod要么同时启动要么都不启动。比如一个Tensorflow的作业如果仅单独拉起一种角色的任务(Ps or Worker)是没法正常执行的。

资源公平调度(Fair-share): 部署的K8s集群会存在多个Namespace，而每个Namespace也可能提交多个作业，怎样调度资源才能避免某个Namespace的资源被无限制压缩，又怎样才能确保作业之间的资源调度公平？

GPU Topology感知(GPU Topology Awareness): 一个常见的AI训练/推理作业，为了达到更高的性能，往往需要使用多个GPU共同完成，此时 GPU的Topology结构以及设备之间的传输性能会对计算的性能造成很大影响。目前, K8s提供的扩展资源调度机制还无法满足调度时Topology感知的问题。

集群自动配置(Cluster Configuration): 许多上层工具，在业务启动之前，需要用户配置工具的集群状态，方便系统内部节点互通和识别，以MPI(Message Passing Interface)作业为例，需要用户以命令行参数“—host”配置集群的所有节点信息，并且还依赖节点之间SSH互通，所以，用户还要考虑怎样自动配置和管理业务集群。

此外，怎么监控整个作业集群的状态？单个Pod失败怎么处理？怎么解决任务依赖的问题？这些都是需要处理的问题。

正基于此，华为云Volcano在解决此类问题的基础上，致力于提供一个针对BigData/AI场景的通用、稳定、可扩展、高性能的原生批量计算平台，方便以Kubeflow[1], KubeGene[2]， Spark[3] 为代表的上层业务组件集成和使用。

概述:

图2: Volcano业务全景

如图2所示，华为云Volcano在K8s之上抽象了一个批量计算的通用基础层，向下弥补K8s调度能力的不足，向上提供灵活通用的Job抽象。目前，项目最重要的2个组件分别是Volcano-Scheduler和Volcano-Controller。

图3: Kube-Batch介绍

Volcano-Scheduler: 这个组件最开始来自社区的Scheduling SIG子项目项目Kube-Batch[4]，它是一个可扩展的增强调度器，主要支持的能力主要有：

Actions:

① Allocate: 正常的资源分配动作。

② Preempt: 抢占，当系统中存在高优先级作业，且系统资源无法满足请求时，会触发资源抢占操作。

③ Reclaim: 资源回收, Kube-Batch会使用队列(queue)将资源按照比例分配，当系统中新增或移除队列时，Reclaim会负责回收和重新分配资源到剩余队列中去。

Plugins:

① DRF: 即Dominant Resource Fairness, 目的是为了确保在多种类型资源共存的环境下，尽可能满足分配的公平原则，其理论最早来自于UC伯克利大学的论文《Dominant Resource Fairness: Fair Allocation of Multiple Resource Types》[5]。

② Conformance: 资源一致性，确保系统关键资源不被强制回收使用。

③ Gang: 资源成组，确保作业内的成组Pod资源不被强制驱逐。

而Volcano-Scheduler在Kube-Batch的基础上，又更进一步，引入了更多领域性的动作和插件，包括BinPack，GPUShare，GPUTopoAware等。

Volcano-Controller: Volcano通过CRD的方式提供了通用灵活的Job抽象Volcano Job (batch.volcano.sh/jobs), Controller则负责跟Scheduler配合，管理Job的整个生命周期。主要功能包括:

①: 自定义的Job资源: 跟K8s内置的Job(作业)资源相比，Volcano Job有了更多增强配置，比如：任务配置，提交重试，最小调度资源数，作业优先级, 资源队列等。

②: Job生命周期管理: Volcano Controller会监控Job的创建，创建和管理对应的子资源(Pod, ConfigMap, Service)，刷新作业的进度概要，提供CLI方便用户查看和管理作业资源等。

③: 任务执行策略: 单个Job下面往往会关联多个任务(Task)，而且任务之间可能存在相互依赖关系，Volcano Controller支持配置任务策略，方便异常情况下的任务间关联性重试或终止。

④: 扩展插件: 在提交作业、创建Pod等多个阶段，Controller支持配置插件用来执行自定义的环境准备和清理的工作，比如常见的MPI作业，在提交前就需要配置SSH插件，用来完成Pod资源的SSH信息配置。

下面以一个MPI Job作业的YAML片段为例，带大家从整体上了解Job Controller的功能(扩展功能相关字段已添加注释，方便理解)。

图4: Volcano Job样例(/example/integrations/mpi/mpi-example.yaml)

有了上面的介绍，回过头来参照图5梳理华为云Volcano一次普通作业的执行流程,也就很容易理解了。

图5: Volcano组件与调度流程

用户通过kubectl创建Volcano Job资源。
Volcano Controller监测到Job资源创建，校验资源有效性，依据JobSpec创建依赖的Pod， Service， ConfigMap等资源，执行配置的插件。
Volcano Scheduler监听Pod资源的创建，依据策略，完成Pod资源的调度和绑定。
Kubelet负责Pod资源的创建，业务开始执行。
Volcano Controller负责Job后续的生命周期管理(状态监控，事件响应，资源清理等)。

调度效率:

除去易用性和扩展性，在BigData/AI场景下，资源调度的效率(成功率)通常能有效减少业务的运行时间，提高底层硬件设备的使用率，从而降低使用成本。我们以Volcano Scheduler和原生Scheduler在Gang Scheduling的场景下做了一个简单的TF Job 执行时间对比:

图6: Volcano与Default Scheduler调度作业执行时间对比(Gang Scheduling)

参考图6发现，单个作业的执行环境，两种执行方式在运行时间上并无明显区别，但是当集群中存在多个作业时，因为原生Scheduler无法保证调度的成组性，直接导致极端的情况出现: 作业之间出现资源竞争，互相等待，上层业务无法正常运行，直至超时，此时调度的效率大打折扣。

社区和贡献:

目前，华为云Volcano项目还在不断地发展壮大中，更多特性也在设计和开发阶段，如果您有兴趣，欢迎随时加入我们的Slack讨论[6], 提问题，给意见，贡献代码[7]。另外，9月18至20日，华为全联接大会即将于上海举行，会上将设多场云原生相关的技术论坛，华为云云原生技术大咖和布道师也会亲临现场同开发者进行面对面的交流和互动，期待与你相遇。

[1]: https://www.kubeflow.org/

[2]: https://github.com/kubegene/kubegene

[3]: http://spark.apache.org/

[4]: https://github.com/kubernetes-sigs/kube-batch

[5]: https://people.eecs.berkeley.edu/~alig/papers/drf.pdf

[6]: http://volcano-sh.slack.com

[7]: http://github.com/volcano-sh/volcano