现代互联网数据中心的规模随着应用服务需求的快速增长而不断扩大，但服务器资源利用率却一直很低，导致企业基础设施成本不断上涨。随着云原生技术的发展，混合部署成为了降低成本的一大手段。本文结合华为 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 可以看出，在离线业务在很多特征上具有互补性，将二者进行混合部署也已经成为数据中心提升整体资源利用率的主流方法。

方案设计

方案介绍

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

1. 调度器需要同时支持在线任务和离线任务的调度，离线任务对调度器提出了更高的性能要求、更多的调度特性需求，比如大数据或 AI 任务需要支持 gang-scheduling、binpack 等。

2. 工作节点支持同时运行在线和离线容器，在离线业务统一管理。

3. 超卖特性支持，根据节点实时和预测的空闲资源进行调度，提升资源利用率的同时减少在离线运行干扰以达到单次调度最优。

4. 多维度资源隔离与抢占，确保离线任务充分利用空闲资源的前提下，支持在线任务对资源百毫秒级抢占。

5. 节点可观测性增强，对在离线任务资源布局动态优化，识别在线业务是否受到干扰，对干扰进行定位和控制。

6. 集群可观测性增强，对集群任务布局动态优化，减少集群资源使用不均衡问题。

基于 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 上进行修改以满足离线进程调度：

1. 新增 cgroup 接口 cpu.qos_level 来控制 Pod 中所有进程的优先级。

2. 引入 throttle 机制对离线任务进行进一步压制，使得在线任务能够独占 CPU。

3. 增加 kill boost 机制避免当在线业务 100%占用 CPU 时，杀死离线任务无法释放资源的问题。

4. 对在线任务进行高负载检测，超时后对内核态离线任务放行，防止离线进程在内核态发生优先级反转导致系统假死。

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

1. 新增 cgroup 接口 memory.qos_level 来控制 Pod 优先级。

2. 分级回收：通过内存回收水位分级和 OOM 回收分级来保障在线任务内存需求。

3. kill 快速回收：该技术可以使得分配内存触发大量离线任务 OOM 的情况下仍能具有较高的内存分配性能。

4. 页缓存限制：避免因 page cache 使用过多导致内存不足从而影响业务功能。

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

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

1. 基于 eBPF 和 EDT 技术实现动态限速分配策略，根据业务优先级自动调整带宽，实现 per-cgroup 级别的带宽隔离。

2. 网络带宽优先级抢占机制，当在线业务占用带宽比较低时，空闲带宽能够分配给离线业务使用；而当在线业务需要更多带宽时，能够迅速（<100ms）将带宽从离线业务上抢占回来。

3. 对离线业务提供最低带宽保障，避免饥饿导致的业务中断。

落地效果

CPU 隔离效果

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

图 8 混合部署响应时间

网络隔离效果

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

图 9 网络发包时序

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

图 10 网络抢占性能

计划与展望

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

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

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

参考资料

1. 云原生 2.0白皮书

2. 数据中心产业发展指数 2021 年

3. 新型数据中心发展三年行动计划（2021-2023 年）

4. 中国数据中心行业研究报告 2020 年

5. 王康瑾,贾统,李影.在离线混部作业调度与资源管理技术研究综述.软件学报,2020,31(10):3100-3119

6. Interference-Aware Scheduling for Inference Serving

点击关注，第一时间了解华为云新鲜技术~​