Volcano火山:容器与批量计算的碰撞

Kubernetes是当前非常流行的容器编排框架,在其发展早期重点以微服务类应用为主

但随着Kuberentes的用户越来越多,更多的用户希望在Kubernetes上运行BigData和AI框架,如Spark、TensorFlow等以构建统一的容器平台 。 但在Kubernetes运行这些高性能应用时,Kubernetes的默认调度器无法满足高性能应用的需求,例如:公平调度、优先级、队列等高级调度功能 。 由于Kubernetes的默认调度器是基于Pod进行调度,虽然在1.17中引入了调度框架,但仍无法满足高性能应用对作业级调度的需求 。

容器批量计算平台Volcano

针对云原生场景下的高性能应用场景,华为云容器团队推出了Volcano项目 。 Volcano是基于Kubernetes构建的一个通用批量计算系统,它弥补了Kubernetes在“高性能应用”方面的不足,支持TensorFlow、Spark、MindSpore等多个领域框架,帮助用户通过Kubernetes构建统一的容器平台 。 Volcano作为容器调度系统,不仅包括了作业调度,还包含了作业生命周期管理、多集群调度、命令行、数据管理、作业视图及硬件加速等功能 。


Volcano火山:容器与批量计算的碰撞

----Volcano火山:容器与批量计算的碰撞//----

而在调度方面,Volcano又对场景进行了细分、归类,并提供了相关的方案及算法;同时也为这些功能提供了调度框架,方便用户对调度器进行扩展 。 对于分布式计算或是并行计算来说,根据场景和作业属性的不同,也可以对其进行细分;在《并行计算导论》中将并行计算大致分为三类:

简单的并行

简单的并行指多个子任务(tasks)之间没有通信也不需要同步,可以完全的并行的执行 。 比较著名的例子应该就属MapReduce了,它的两个阶段都属于这种类型:mapper任务在执行时并不会彼此通信同步运行状态;另一个常见的例子是蒙特·卡罗方法,各个子任务在计算随机数时也无需彼此通信、同步 。 由于这种并行计算有比较广泛的应用,例如数据处理、VatR等,针对不同的场景也产生了不同的调度框架,例如Hadoop、DataSynapse和Symphony 。 同时,由于子任务之间无需信息和同步,当其中某几个计算节点(workers)被驱逐后,虽然作业的执行时间可能会变长,但整个作业仍可以顺利完成;而当计算节点增加时,作业的执行时间一般都会缩短 。 因此,这种作业也常常被称作ElasticJob 。

复杂的并行

复杂的并行作业指多个子任务(tasks)之间需要同步信息来执行复杂的并行算法,单个子任务无法完成部分计算 。 最近比较有名的例子应该算是Tensorflow的"ps-work模式"和ringall-reduce了,各个子任务之间需要大量的数据交换和信息同步,单独的子任务无法独立完成 。 正是由于作业的这种属性,对作业调度平台也提出了相应的调度要求,比如gang-scheduling、作业拓扑等 。 由于子任务之间需要彼此通信,因此作业在启动后无法动态扩展子任务,在没有checkpoint的情况下,任一子任务失败或驱逐,整个作业都需要重启,这种作业也常常被称作BatchJob,传统的HPC场景多属于这种类型的并行作业,针对这种场景的调度平台为Slurm/PBS/SGE/HTCondor等 。

流水线并行

流水线并行是指作业的多个子任务之间存在依赖关系,但不需要前置任务完全结束后再开始后续的任务;比如Hadoop里有相应的研究:在Map没有完全结束的时候就部分开始Reduce阶段,从而提高任务的并行度,提高整体的运行性能 。 符合这种场景的应用相对来说比较少,一般都做为性能优化;因此没有针对这种场景的作业管理平台 。 需要区分一下工作流与流水线并行,工作流一般指作业之间的依赖关系,而流水线并行一般指作业内部多个任务之间的依赖 。 由于工作流中的作业差异比较大,很难提前开始后续步骤 。


推荐阅读