Volcano：在离线作业混部管理平台，实现智能资源管理和作业调度

阅读原文时间：2022年04月01日阅读：1

摘要：本文结合华为CCE团队在混合部署方面的研究和实战，介绍了混合部署的背景、概念、混部技术的设计方案和实际落地情况，以及对未来的计划和展望。

现代互联网数据中心的规模随着应用服务需求的快速增长而不断扩大，但服务器资源利用率却一直很低，导致企业基础设施成本不断上涨。随着云原生技术的发展，混合部署成为了降低成本的一大手段。本文结合华为CCE团队在混合部署方面的研究和实战，介绍了混合部署的背景、概念、混部技术的设计方案和实际落地情况，以及对未来的计划和展望。

云原生概念在2013年由Matt Stine提出并沿用至今，经过不断的总结完善，已经涵盖了DevOps、持续交付、微服务、容器化等主题，成为一套完整的技术方法体系。通过构建易观测、低耦合、容错性高的系统来达成提高效率、加速创新、降低成本的目标。

随着云原生基础技术日渐成熟，在提升效率和加速创新的目标上已经取得了显著的成效。得益于效率提升的优势，如今千行百业都在拥抱云原生，Gartner报告指出，到2022年将有75%的全球化企业在生产中使用云原生的容器化应用。同时伴随着开源项目的不断更新和逐步成熟，其加速创新的优点也促使各企业在AI、大数据、边缘、高性能计算等新兴业务场景不断采用云原生技术来构建创新解决方案。然而在降低成本的目标上，当前仍面临着基础设施成本高昂和资源利用率低下的问题。全球云基础设施服务支出保持千亿美元的年增长，总体规模已经突破万亿美元大关，中国仅IDC业务在2019年就突破了千亿大关，并保持30%的年增长率。根据Dell'Oro市场研究公司于2021年7月发布的预测，未来五年服务器支出将以11%的年复合增长率增长，到2025年将占数据中心资本支出的近一半。《中国“新基建”发展研究报告》称，到2025年，数据中心将占全球能耗的最大份额，高达33%。另一方面，全球服务器平均利用率不到20%，我国大多数数据中心的PUE普遍大于2.2。由此可见，云基础设施在降低成本上还有很大的提升空间。

图 1 中国数据中心市场规模

2021年7月工业和信息化部印发的《新型数据中心发展三年行动计划（2021-2023年）》（简称“计划”）提出，到2021年底，全国数据中心平均利用率力争提升到55%以上，总算力超过120 EFLOPS，新建大型及以上数据中心PUE降低到1.35以下。到2023年底，平均利用率力争提升到60%以上，总算力超过200 EFLOPS，新建大型及以上数据中心PUE降低到1.3以下。

为了帮助达成“计划”的目标，这里简要分析资源利用率低下的原因，并基于HCE（Huawei Cloud EulerOS）制定一套行之有效的解决方案。

造成服务器资源利用率低的主要原因可以归为两大类：

1、不同类型业务分开部署在不同的资源池

为了避免业务之间的竞争影响到服务质量，不同类型的业务通常分开部署在不同的资源池。但业务的运行往往存在高峰期和低谷期，例如网购、社交一类的业务在白天的使用量明显高于夜间，但版本构建、测试类的业务则主要集中在晚上运行。分开部署导致服务器普遍存在空闲周期，很多业务空闲期远长于高峰期，导致总体资源利用率很低。

2、服务预留资源与实际使用资源之间存在较大冗余

企业通常采用过量供应资源的方式来保障服务质量，导致预留的资源量与实际的使用量之间存在较大的差距，下图为推特数据中心管理系统30天内的CPU和memory资源预留和实际使用情况，CPU实际使用值在20%上下，但预留值却接近80%，超出了实际使用值的三倍，内存预留则超出了实际使用值的1.5倍。

图 2 推特数据中心资源利用率

基于以上原因，如果能够将业务的波谷时段利用起来，就能减少波谷时间，从时间维度提升效能；同理，将资源预留冗余缩小，就能从空间维度提升效能。因此将不同优先级、不同波动周期的业务进行混合部署，为两个维度提升利用率提供了可能性，即利用低优先级任务占用空闲资源，同时高优先级任务能及时抢占到资源，从而保证关键业务的服务质量。在离线业务在特征上很好的满足了上述条件，本文提到的混合部署特指在离线混合部署。

在线业务通常是处理用户请求的服务，包含交易、购物、搜索、网页浏览等对于实时响应要求高、延时敏感的业务。离线业务通常是计算密集型的批处理任务，包含大数据分析、机器学习训练、算法运算、统计报告等优先级较低、相应要求不高的业务。在离线任务的主要特征如下表所示：

表 1 在离线业务特征

从表1可以看出，在离线业务在很多特征上具有互补性，将二者进行混合部署也已经成为数据中心提升整体资源利用率的主流方法。

方案介绍

在离线业务混合部署对容器管理平台提出了更高的要求，这些要求包括：

调度器需要同时支持在线任务和离线任务的调度，离线任务对调度器提出了更高的性能要求、更多的调度特性需求，比如大数据或AI任务需要支持gang-scheduling、binpack等。
工作节点支持同时运行在线和离线容器，在离线业务统一管理。
超卖特性支持，根据节点实时和预测的空闲资源进行调度，提升资源利用率的同时减少在离线运行干扰以达到单次调度最优。
多维度资源隔离与抢占，确保离线任务充分利用空闲资源的前提下，支持在线任务对资源百毫秒级抢占。
节点可观测性增强，对在离线任务资源布局动态优化，识别在线业务是否受到干扰，对干扰进行定位和控制。
集群可观测性增强，对集群任务布局动态优化，减少集群资源使用不均衡问题。

基于Volcano混合部署解决方案如下图所示：

图 3 基于Volcano混合部署架构

Volcano混部调度能力

目前Kubernetes的默认调度器是以Pod为单位进行调度的，不区分Pod中运行的业务类型。因此无法满足混部场景对资源分配的特殊要求。针对上述问题，Volcano实现了基于应用模型感知的智能调度算法，根据用户提交的作业类型，针对其应用模型对资源的诉求和整体应用负载的情况，优化调度方式，通过资源抢占，分时复用等机制减少集群资源的空闲比例。

Volcano应用模型感知分为两种：

1.作业类型感知：能够识别在线作业和离线作业。

2.Pod类型感知：能够识别作业中不同类型的Pod，例如Tensorflow作业中的PS和Worker，Spark作业中的Driver和Executor等。

针对作业类型感知，Volcano通过作业混合部署+资源超卖的方式，实现集群资源利用率的提升，示意如下：

图 4 混合调度超卖示意图

资源超卖是指将集群资源申请量与使用量的差值进行再次分配，进而提升集群的资源使用率，参考如下方式进行：

图 5 资源超卖示意图

其中request-used为资源超卖部分，Volcano调度器会将这部分资源再次分配。由于超卖资源的稳定性不能保证，因此只能用于运行SLA较低的离线作业。

用户提交多种类型作业时，Volcano进行统一调度，优先保证在线作业运行（如图4所示）。当在线作业压力较低时，意味着节点上物理资源的使用率较低，此时Volcano会进行资源超卖，将离线作业调度到相应的节点上运行。当在线作业压力变大时，Volcano会驱逐掉当前节点上的离线作业，保证在线作业能够正常运行。

针对Pod类型感知，Volcano根据应用模型对资源的诉求和整体应用模型本身运行的要求，进行优化调度。以Tensorflow作业为例，一个Tensorflow作业中包含若干PS Pod和若干Worker Pod，当PS Pod和Worker Pod能够均匀分配时，TF作业的运行效果更优。例如，对于一个包含2个PS Pod和4个Worker Pod的TF作业，默认调度器和Volcano对比如下：

图 6 作业类型感知调度

可以看出，在资源充足的情况下，默认调度器会出现PS Pod和Worker Pod分别被调度到不同节点的情况，Volcano能够保证将1个PS Pod和2个Worker Pod调度到一台节点上，从而提升作业整体运行效率。

目前K8S提供的默认调度器，仅根据节点资源请求数量调度Pod。该方式并未考虑到节点实际资源使用情况，可能会出现各个节点资源申请率相同，而实际负载差别较大的情况。对于高负载的节点，可能会导致应用响应速度变慢，无法满足SLA。对于低负载的节点，则存在资源浪费的情况。

针对该问题，Volcano提出了基于节点物理资源使用率的预测及调度功能，提供以下三方面的能力：

1.预测调度：接入集群监控系统，根据节点及Pod历史资源使用率，预测未来节点及Pod资源使用率的变化趋势，根据预测结果进行合理调度。

2.负载均衡调度：根据集群各节点当前负载情况，结合未来使用趋势的预测，将pod调度到使用率较低的节点，进而提升整个集群资源使用的均衡性。

3.资源抢占调度：节点资源不足时，调度器实时驱逐部分离线作业，保证在线作业的资源使用。

节点管理

混合部署的节点管理主要包括两个部分，一是资源配置管理，二是干扰控制管理。资源配置组件主要负责在pod创建时配置相关的优先级用于资源隔离。干扰控制组件主要负责在容器运行时动态检测异常并进行相关处理。

图 7 cgroup控制层级

虽然kubernetes支持多种QoS类型的Pod，如Guaranteed、Burstable和BestEffort，但是这些类型并不能和在离线任务直接对应。HCE通过新增cgroup接口来控制pod的优先级，如cpu cgroup下的cpu.qos_level用于控制当前Pod对CPU资源抢占的优先级。当前通过kubelet执行相关配置操作，保证Pod各资源配置的一致性。

资源超卖及在离线作业混部必然会导致不同作业之间的相互干扰，因此除了通过cgroup进行资源隔离之外，kubelet同时会实时采集节点上物理资源使用率，根据不同的情况驱逐离线作业，提前释放相应资源，防止对在线作业的SLA产生影响。

节点资源隔离

资源隔离技术涉及的资源包括CPU、内存、网络和IO等等，针对每一种资源，需要结合已有隔离技术来应对混合部署场景下的新需求。在离线混合部署对资源的需求可归纳为两点：对于资源分配情况优先供应给在线任务，对于资源回收情况优先从离线任务回收资源。

对于CPU资源，目前内核已经提供丰富的隔离和带宽控制技术，例如调度类、调度策略、进程优先级、cpu.shares等，但这些技术并非为混合部署设计，使用上存在如下一些问题。

调度类：不同的调度类优先级不同，并且支持快速抢占，这一特点和混合部署的需求吻合。但由于系统进程运行在CFS类上，离线任务就只能用优先级更低的IDLE调度类，而IDLE调度类不能用于普通进程调度，因此不能通过设置不同调度类来支持CPU抢占。
调度策略：CFS支持多种调度策略，不同策略优先级也不同，这也是混合部署所需要特性。由于通用进程运行在SCHED_NORMAL策略，因此离线任务可以选择优先级更低的SCHED_BATCH或SCHED_IDLE策略。使用调度策略的关键问题是没有提供cgroup控制接口，用户无法通过cgroup配置Pod的调度策略。
权重（优先级&cpu.share）：进程优先级和cpu.shares通过虚拟时间片来控制CPU权重，只能保障总体运行时间比例，本质上属于公平调度的范畴，不能保障在线进程实时抢占离线进程。

HCE目前的做法是在SCHED_IDLE上进行修改以满足离线进程调度：

新增cgroup接口cpu.qos_level来控制Pod中所有进程的优先级。
引入throttle机制对离线任务进行进一步压制，使得在线任务能够独占CPU。
增加kill boost机制避免当在线业务100%占用CPU时，杀死离线任务无法释放资源的问题。
对在线任务进行高负载检测，超时后对内核态离线任务放行，防止离线进程在内核态发生优先级反转导致系统假死。

在内存资源方面，HCE通过如下能力支持内存分级保障：

新增cgroup接口memory.qos_level来控制Pod优先级。
分级回收：通过内存回收水位分级和OOM回收分级来保障在线任务内存需求。
kill快速回收：该技术可以使得分配内存触发大量离线任务OOM的情况下仍能具有较高的内存分配性能。
页缓存限制：避免因page cache使用过多导致内存不足从而影响业务功能。

网络资源原生可以使用TC HTB规则控制优先级，但该方法配置繁琐，规则数量增加时会导致性能损耗变大，对于在线小报文离线大报文情况，在线任务性能会受到干扰。

HCE对此提出以下网络隔离优化机制：

基于eBPF和EDT技术实现动态限速分配策略，根据业务优先级自动调整带宽，实现per-cgroup级别的带宽隔离。
网络带宽优先级抢占机制，当在线业务占用带宽比较低时，空闲带宽能够分配给离线业务使用；而当在线业务需要更多带宽时，能够迅速（<100ms）将带宽从离线业务上抢占回来。
对离线业务提供最低带宽保障，避免饥饿导致的业务中断。

CPU隔离效果

这里使用CloudSuite验证CPU隔离效果，使用web-serving模拟在线业务，in-memory-analytics模拟离线业务。使用三种部署方式进行验证：只运行在线、在离线混合部署、在离线混合部署（开启QoS隔离特性）。测试数据如下所示，利用CPU抢占能力可以让在线任务达到接近独立部署的性能。

图 8 混合部署响应时间

网络隔离效果

网络通过netperf进行测试，分别在不同优先级Pod执行发包测试，在离线发包时序如下图所示，时间轴单位为s，在第5秒验证离线对在线的性能影响，在第15秒验证在线任务对网络的抢占能力。

图 9 网络发包时序

采样数据如下图所示，启动离线任务对在线任务网络性能影响较小，在线任务可以在100ms时间内完成网络性能从0到最大的抢占。

图 10 网络抢占性能

虽然混合部署解决方案是提升资源利用率的重要技术手段，但该方案目前没有形成业界统一标准，存在重复设计，通用性不强等问题。后续计划向kubernetes和linux内核提交贡献来推进生态标准化。

未来，混合部署的含义也将随着技术的发展而逐渐丰富，例如多种类型任务的混合部署，异构资源的混合部署等等。因此需要在两级优先级设计的基础上，探索多级优先级场景和扩展方案，以支持更丰富任务类型。异构和跨代硬件资源的混合部署对传统基于资源部署的方式提出了新的需求，让业务的部署不再需要感知底层硬件资源才能提供更智能的调度、更精准的资源匹配。

此外，仍有部分资源没有分级抢占能力，例如L1/L2缓存、缓存带宽等，因此混合部署的性能干扰不可避免。为了让混合部署后仍能提供优质的服务质量，不仅要从芯片微架构到上层调度层进行全面设计，还需要一种预测、反馈和校正机制。