【云驻共创】基础设施感知业务需求，AI业务基于Volcano的实践

和大家进行华为云在基础设施感知业务需求，AI业务基于Volcano的落地实践的分享。AI是属于批量计算的一个领域，今天会按照以下结构来和大家分享

批量计算发展历程

Volcano项目介绍与关键特性

Volcano助力客户构建AI平台

Volcano社区发展介绍

批量计算发展历程

HPC、大数据、AI批量计算的发展历程和趋势

如上图有三条主线，代表了批量计算的三个主要场景，

最早是在HPC这个领域，这个领域从90年代诞生到现在，主要的公司基本都是以B原为主的。在2018年的时候，HPC和AI开始进行了一定的融合，一些AI领域的应用可以应用到HPC领域中去。HPC的一些技术也可以给AI领域提供帮助。随着K8s的发展和成熟，HPC也开始拥抱K8s。在2020年的vhpc大会上，也在研讨如何把HPC应用更好的部署到k8s上去运行。

另外在大数据领域，2012年和2014年是两个重要的时间节点，2012年Hadoop将资源管理层和上面的领域框架进行了解耦，上层的领域框架就有机会发展自己的生态。目前Spark和Flink对K8s都提供了一些官方的支持。

AI领域的框架，像Tensorflow、Caffe2这些诞生的比较晚。所以目前来看，主要的AI框架对接的资源管理平台都是K8s。K8s凭借它的一些优势，比如环境的标准化、开放的生态、模块化与扩展等等，让越来越多的用户比较认可K8s，也有越来越多的用户希望将他们的批量计算任务对接到K8s平台上面来，集中统一的管理。

这个趋势将会带来两个主要的收益。

在技术站方面可以得到统一，不需要同时维护多个技术站，降低了公司维护和学习的成本。

可以将多种业务类型和资源池进行归一，大大提升资源的整体利用率。

Kubernetes容器平台已成为批量计算场景的主流

从各个领域的头部公司的发展动态中可以看出，他们在逐渐的拥抱K8s ，K8s也成为HPC管理层的主流选择。像欧洲原子能机构，欧洲生物学实验室，他们已经基于容器和K8s来构建他们的批量计算平台，云原生基金会也专门成立了兴趣小组，来讨论如何基于K8s让批量计算任务运行得更好。

云原生批量计算面临的关键挑战

用户把批量计算运行在K8s平台上，还是会遇到很多挑战，这里列出了主要几方面的挑战。

1. 作业管理缺失：

Pod级别调度，无法感知上层应用。

缺少作业概念、缺少完善的生命周期的管理。

缺少任务依赖、作业依赖支持。

2. 调度策略局限

不支持Gang-Scheduling、Fairshaing scheduling。

不支持多场景的Resource reservation，backfill。

不支持CPU/IO topology based scheduling。

3. 领域计算框架支持不足

1:1的operator部署运维复杂。

不同框架对作业管理、并行计算等要求不同。

计算密集，资源波动大，需要高级调度能力。

4. 资源规划复用、异构计算支持不足

缺少队列概念。

不支持集群资源的动态规划以及资源复用。

对异构资源支持不足

Volcano帮助批量计算面对云原生的各种挑战

针对上面遇到的这些挑战，希望Volcano基于K8s做最好的云原生批量计算平台。Volcano在2019年6月份的时候正式进行了开源，在去年4月份捐献给了云原生基金会，成为了CNCF的官方项目。Volcano社区大概每3个月发布一个版本，社区的活跃度上面贡献者已经超过了120人。

Volcano帮助批量计算面对云原生的各种挑战

Volcano和上游领域的框架进行了充分的合作，目前已经支持了主流的计算平台，比如大数据领域的Spark和Flink，AI领域的像TensorFlow、mxnet等都和Volcano进行了完美的结合。另外像OPEN MPI、argo也都和Volcano进行了集成。

上图可以看到，Volcano不只是一个调度器，除了scheduler还有job、Queue这种controller来进行丰富的作业生命周期管理。

Volcano项目介绍与关键特性

Volcano总体架构和优势

Volcano不仅有调度器，还有控制器。在调度器层面，提供了很多子系统，比如调度策略子系统，可以以插件的方式支持用户热插拔各种的调度策略；资源规划子系统，可以提供级联的队列能力，资源共享和隔离功能；性能子系统，包含了资源和作业的catch信息；还扩展联邦调度子系统，支持多集群的作业调度。

关于Volcano的8大优势，在用户实际生产环境中得到了充分的验证：

高性能：提供队列调度、优先级调度、抢占、装箱、资源预留、拓扑调度等丰富的调度策略，在多种场景下提升应用性能。

智能混合调度：支持在线、离线混合部署调度，提高整体资源利用效率。

应用感知：应用感知类型和特点，针对大数据、AI、HPC负载提供完善的生命周期管理。

集群联邦调度：支持多集群调度和作业分发，满足效率优先、成本优先等不同的场景诉求。

大规模：支持大规模集群调度，单集群规模支持1万节点，100万容器。

高扩展：插件化算法集成框架，提供两级插件扩展，方便二次开发，满足不同场景诉求。

易运维：Volcano作业提供统一接口，避免过多Operator带来的繁杂管理。

社区成熟：CNCF收个批量计算平台，已支持众多的主流AI、大数据、高性能计算框架，众多用户已用于生产环境。

分布式训练场景、大数据场景性能提升30%

下面结合一些使用场景和案例来介绍一下，Volcano在用户的生产环境中所带来的好处。

第一个场景就是在AI分布式和大数据中最普遍遇到的场景，也就是Volcano首先要解决的批量调度的问题。在AI的分布式训练和大数据场景下，需要调度器以作业为单位进行整体的调度，而K8s默认的调度器目前只能以 Pod的方式去进行调度的。Pod的只是作业的一部分，在资源紧张的多作业调度情况下，K8s的调度很容易出现多个AI训练作业或者Spark作业都只有一部分Pod的成功调度了。部分Pod由于缺少资源判定，在AI训练作业和Spark作业这种场景下面，就是作业之间的盲导和思索。

AI分布式训练场景

Volcano特有的Gang-Scheduling，这种调度策略可以使调度器以作业为力度，整体的去申请资源，从而达到作业可以整体的运行的效果。解决了由于资源不足而导致作业之间盲道和死锁的这种情况。

上图可以看出，红色的是kubeflow加k8s的默认调度器运行case的执行时间，蓝色的是使用Volcano调度器来执行的时间。在最坏的情况下，看到 volcano和K8s默认调度器执行作业都是24分钟，而在资源不足的像k12和k13当中，Volcano相比较K8s的默认调度器有了30%的性能提升。

上图是Volcano提供的作业拓扑和IO感知的调度策略。使用作业拓扑和IO感知，可以极大的降低作业的整体运行时间。

大数据场景

上图是大数据TPC-DS性能测试，由于minResource的策略可以解决在高并发场景下Spark driver和executor资源的竞争问题，合理的规划并行动，从而使整个作业的执行时间提升30%。可以看到红色的圆点代表Volcano运行的作业，蓝色的是K8s默认调度器运行的作业，横坐标是作业的启动时间，纵坐标是运行时间，可以看出Volcano作业启动的时间更早，整体运行时间更快。

关键特性：基于Volcano Job运行MPI

上图左边是MPI的Volcano Job的一个定义，右边展示了Volcano创建这个作业时候所做的工作。

Kind是一个job类型的，它的apiVersion是batch.volcano.sh，是k8s自定义的一种CRD，区别于k8s自带的这种Job类型。在Spark里定义了minAvailable这个字段，这个字段意味着Job至少要得到三个pod的资源才会去调度下发，体现了这种作业的Gang的这种特性。再往下是schedulerName，这个作业使用的是Volcano来进行调度的，Volcano提供了三种内置的plugins，在这个例子里使用了其中的两种ssh和svc。

ssh插件提供了作业内部Pod之间的ssh互信，如果这个工作交由用户来做的话就会比较麻烦。需要在Pod启动之后，逻辑运行之前去配置Pod的ssh互信。现在Volcano提供了sss插件，来帮助用户在平台层面做了这件事，这对于MPI的作业来说是非常必要的。

svc插件会为每个作业创建一个highly service，用来帮助pod之间使用pod名字来进行访问。同时Volcano也提供了作业级别的和task级别的policies，来进行job和task的生命周期管理。比如用户可以定义在什么事件触发的时候，启动job重启的这个策略，什么事件触发了叫做结束的这个策略。另外一个比较重要的就是tasks，这个字段的描述。Volcano job是支持多pod模板的，所以在tasks里边可以定义多种类型的task，每一种类型的task就是一种Pod，多种task共同构成了一个完整的job。

关键特性：资源共享、多种级别的公平调度

队列广泛用于共享弹性工作负载和批处理工作负载资源池中。队列的主要目的：

对于不同的租户或者资源池之间的共享资源。

为不同的租户和资源支持不同的调度策略。

这些功能其实还可以通过层级队列的方式进一步扩展。队列在Volcano中是一个集群范围的CRD，当前版本还不支持层级队列这个功能，预计会在未来的1~2个版本中就会提供。

它的特点如下：

相比于Namespace来说，队列更加灵活，它不仅支持静态配置capacity，还支持着多队列之间的动态的比例配置。

动态配置可以支持队列之间的资源租借与共享。当一个队列的workload比较低的时候，可以把应得的资源进行借出，当队列的workload涨上来的时候，可以把借出的资源进行回收。

Volcano还提供了多维度的公平调度，补齐了现在亚尔和麦克斯中都有的DRF调度策略，提供了namespace级别的工程调度。

关键特性：IOAware降低分布式训练传输时延

K8s的调度器并没有lO感知的能力，对于1个包含2ps+4workers的tensflow作业来说，可能会出现上图中的三种节点的Pod分布方式。对于ps和worker有大量数据传输的训练作业来说， 第三种ps和worker的均匀分布的调度结构是比较好的，因为这样可以最大化使用节点内部的带宽来进行数据传输。

上图是在一个Vgg16模型上测试的案例。多次的测试结果中显示前两种调度策略作业的运行波动时间比较大，就是因为想要调度出最佳的pod分布。当采用IOAware这种调度策略之后，它就会比较稳定，作业运行的时间也会整体的会更短。

关键特性：NUMA Aware调度策略

首先来讲一讲场景和诉求：

针对一些计算密集型的对性能要求比较高的AI训练任务，用户希望容器可以独占CPU来减少CPU共享导致的上下文的切换的这种损耗。

对于运行在NUMA架构上处理器的任务，也希望容器独占多个位于同一个NUMA node上的CPU盒，减少通讯之间的损耗，来提升整体的一个训练的一个性能。

K8s引入了 topology manager和CPU manager等组件提供节点上面的资源分配和拓扑调动。

但是这种特性都是工作在节点上面的，存在一些局限性。比如调度器不支持拓扑感知的能力，不支持这个节点的CPU topology和资源分配。因此容器可能会由于节点资源不满足topology manager这种调度策略，导致在节点上被拦截，最终导致调度失败。另外一个是上述描述的管理器都是运行在节点上面的，并不能为作业提供优选的服务。为了解决这些局限性，Volcano新增了NUMA Aware这种插件，以及NUMA info组建，提供了Pod的级别的拓扑策略，便于用户灵活的结合自身的使用场景进行不同的客户配置，具体关键技术如下：

NUMA info通过为节点创建CRD来上报更新节点NUMA的拓扑信息。

Volcano依据这些NUMA信息以及作业Pod需求来进行NUMA的亲和性调度，避免了默认调度器调度Pod之后被拦截的问题。

关键特性：在线、离线混合调度、资源超卖

多种业务类型的混合部署在近些年是非常热门的一个话题。在线的web服务和离线的分析业务有着各自不同的特点。在线业务需要的资源相对较少，但是对时延有严格的要求。比如推荐业务、广告业务等，同时又有波峰波谷的特性。离线分析的业务计算量比较大，占用的资源比较多，使用的资源比较稳定，但是不需要对任务进行迅速的响应。

如果可以把在线业务和离线业务进行混合部署，就可以充分的实现资源的复用，削峰填谷，提升整体的资源使用率。另外一个就是资源超卖，在真实的使用场景中，用户往往为了业务的稳定性，会为Pod申请过多的资源，而K8s调度器是依赖于用户的静态request输入来进行调度的，这样会造成集群的分配率比较高，使用率低， CPU平均资源使用率不到15%，造成了巨大的资源浪费。

Volcano在资源超卖和业务稳步这两个方面进行了相应的研究。

QoS-feature：欧拉OS对QoS场景支持能力。

Kubelet：添加对QoS模型的支持，支持实时上报、计算超卖资源，作业驱逐。

Scheduler：集群调度器，添加对QoS模型的支持，在统一资源模型下支持多类型业务场景。

Volcano助力客户构建AI平台

某内容电商：Volcano优化AI训练平台

这个案例是一个月活数超过1亿的内容社区用户，每天大概有几十万篇的笔记投稿，上百亿次笔记曝光，用户是一个比较新的公司，没有基站的机房，所有的服务器是买云厂商的云服务，而且大多数服务都是通过K8s来进行管理的。用户有两个重要的平台，一个是内部的流量计算平台，主要是用来管理实时的标签计算，以及这种在线学习的Flink任务。还有一个是机器学习平台，它主要的是管理机器学习的任务，他们承载了像TCL开发的一些模型训练。

那么如何将这些任务呢调度到k8s集群上？其实原生的k8s对这种场景存在一个比较大的问题，它是基于单pod来进行调度的，经常会遇到作业死锁的问题。用户基于这个痛点做了一些调研，发现Volcano可以解决这些痛点，用户最终加入volcano社区当中，客户在使用Volcano提供了增强了task，托福调度算法，使AI的训练性能的整体提升了一个20%，同时使用我们提供的srv的调度策略，来避免大作业饿死的这种现象。

某投资公司：基于Volcano构建大规模计算平台

这个案例是一个金融客户，随着公司规模的扩大，公司的策略人员在使用环境也在不断的变化，对于不同的研究环境促使用户开始使用容器技术来屏蔽多种环境因素所带来的这种困扰。随着k8s社区的成熟与稳定，在计算集群中使用容器技术几乎就等同于使用k8s，但是原生的k8s调度器并没有提供批处理任务的调度能力，也缺乏团队之间的这种资源共享，公平调度的这种机制。

某视屏网站：Volcano构建AI训练平台

这是一个国内排名在Top3之内的某视频网站使用我看到的一个场景，他们构建自己的 Java4的深度学习平台，支持了TensorfFlow、PyTorch、Caffe、Caffe2，MXNet等框架。其中以TensorfFlow和PyTorch为主，承载了公司的广告搜索、推荐、NLP等业务。他们的容器平台因为起步比较早，一开始使用的是MESOS加马拉松，作为他们的容器平台，当K8s社区成为云原生应用的编排管理实施标准之后，用户开始把 AI容器业务呢从MESOS加马拉松迁移至K8s加Volcano上面来。训练平台在迁移到K8s的主要过程中遇到了三方面的挑战：

原生的Pod/Deployment/Job无法满足分布式训练要求。

无队列管理、配额管理能力。

对于Gang Scheduling这种调度能力的缺失。

实际上Volcano对于用户来说，最重要的就是这么几个概念：

提供了Volcano job，可以简单的理解成是对K8s job的扩展，或者说是对Pod的封装。

在队列上可以分配一些配额，可以做一些队列的管理。

有了Pod集合这种概念，可以做一些更高级的上层的调度策略。

客户之所以选择Volcano，是因为Volcano高度符合AI训练场景，另外Volcano不侵入k8s源码，符合k8s的开发规范，简单来说就是方便客户的二次开发。还有一点就是Volcano项目，加入了CNCF，成熟度相对来说是比较高的。目前Volcano已经在客户的生产环境中稳定运行了一年以上。

Volcano社区发展变化

众多企业、机构积极参与社区贡献

Volcano可以帮助客户在云原生的环境下更好的运行批量计算任务，同时达到降本增效的目的。使用Volcano的用户分布在各个领域， Volcano的使用场景变的是越来越多，遍布的行业也越来越广，这个是Volcano目前发展的一个状况。项目现在有1900多颗星，120多位的贡献者。

上图也可以看出，虽然Volcano是华为捐献给CNCF基金会的，但是现在独立的贡献者已经接近50%了。

社区版本发布

上图是Volcano社区成立以来呢现在 release的一些主要的版本，希望有更多的开发者和用户加入到Volcano社区，使用Volcano产品。

本文整理自【内容共创系列】1024，懂你所需，予你温暖，致敬新时代可爱的程序员们

查看活动详情：https://bbs.huaweicloud.com/blogs/302011

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。