提升资源利用率与保障服务质量，鱼与熊掌不可兼得？

素颜马尾好姑娘i 2023-09-29 16:57 17阅读 0赞

> 美团Hulk调度系统团队在集群服务质量与资源利用率运营的长期落地实践中，基于业务实际场景，自主设计研发了集群负载自动调控系统（LAR）以及配套的运营体系，在提升集群整体资源利用率的同时保障了业务服务质量。本文介绍了LAR的设计理念、基本框架以及核心设计，并结合在线和混部场景应用展开思考，并展示了部分落地成果。希望能为从事相关工作的同学带来一些启发或者帮助。

随着云计算时代的到来，大规模资源运营面临着如何在保障服务质量的同时提升资源利用率（降本增效）。但这两个目标的达成在当前的软硬件技术水平上，是相互矛盾的。本文介绍的LAR（Load Auto-Regulator）系统，即是探索这两个矛盾方向间的平衡点，在保证质量的前提下，提升资源的利用率。

LAR通过资源分级池化，完备的QoS保障机制，做到精细化的单机资源调度与隔离，在提升整体资源利用率的同时，能够根据服务的优先级和特征保证服务的质量。LAR的整体设计可以适用于多个场景，包括在线场景和混部场景。目前LAR已经在美团在线场景中投入生产使用，并取得了较好的效果。

### 1 背景 ###

#### 1.1 云计算时代数据中心资源规模爆炸 ####

云计算时代的到来，资源规模化运营成为必然的选择，大规模数据中心成为当今企业级互联网应用和云计算系统的关键支撑。据权威报告指出，2020年全球数据中心的服务器总量将达到1800万台，并且正以每年100万台的速度增长。然而，伴随着数据中心的急速扩容，资源利用率却始终处于较低状态。统计数据表明，目前全球数据中心资源利用率仅为10%~20%，如此低的资源利用率意味着数据中心大量的资源浪费，进而导致目前数据中心的成本效率极低。

#### 1.2 资源利用率提升影响巨大 ####

在国家战略层面，数据中心资源利用率低，造成大量的资源浪费，包括物力资源和电能浪费，这与可持续发展的理念是冲突的。2021年7月，工业和信息化部印发《新型数据中心发展三年行动计划（2021-2023年）》，提出用3年时间，基本形成布局合理、技术先进、绿色低碳、算力规模与数字经济增长相适应的新型数据中心发展格局。计划中重点提出建设绿色高效的数据中心目标，将资源利用率提升作为核心目标。

在公司经营上，提升资源利用率可以提升运营效率降低运营成本。谷歌在2019年发表的论文“Borg-the Next Generation”披露其2011年数据中心核心集群（统计1.2万台服务器）的月平均CPU利用率在30%左右，而到2019年，其数据中心核心集群（统计9.6万台服务器）的月平均CPU利用率达到了50%左右，8年时间内提升了约20%，资源使用效能的大幅提升，帮助谷歌节省成本累计数十亿美元。国内各大云服务提供商和互联网公司，目前投入大量人力物力去做提升数据中心资源利用率的工作，包括阿里巴巴、腾讯、百度、华为等公司均陆续提出了比较完善的资源利用率提升方案，在内部落地实践并取得了一定的成绩。

提升资源利用率，降本增效，能给数据中心节省大量的成本。以数百万核CPU的规模的数据中心为例，整体资源利用率每提升1个百分点，节省成本（包括采购成本和运营成本，运营成本主要是机房租金、电费以及运维费用等）每年将达到数千万元。如果考虑到集群运营人工成本等，随着资源规模持续扩大，这个收益将持续增长。

**持续提升机器的资源利用率，降低单核成本，提升集群服务质量，是美团Hulk团队的核心目标之一**。针对用户对降本增效的需求，Hulk调度团队在集群资源利用率提升和服务质量保障方向率先做出相关探索，提出了一系列的建设方案，并推进落地。本文重点介绍在Hulk整体资源利用率运营体系中的核心系统集群负载自动均衡管理系统。

### 2 什么是LAR？ ###

LAR全称是集群负载自动均衡管理系统（LAR，Load Auto-Regulator），是美团Hulk团队基于Kubernetes研发的容器编排系统。LAR在Kubernetes之上，通过提供分级的QoS管理机制和负载管控能力，实现从时空维度对资源的精确调度分配管理。

#### 2.1 目标与挑战 ####

提升资源利用率从大的层面讲，符合国家降本增效、节能减排的绿色低碳发展战略；从小的层面讲，通过提升资源利用率，可以为企业每年节省数亿的成本，并且降低整体系统复杂度及运维风险。

提升资源利用率，竟有这么大的收益？可能超乎绝大多数人的预料。按照很多同学的理解，通过非常简单的操作即可达成这个目标——提高单机的服务部署密度。但如此简单的操作，为何全球数据中心资源利用率仅为10%~20%呢？利用率如此之低，这里最为关键的因素有三个：

*  部署到同一台物理机的服务在资源使用上存在相互干扰。
 *  服务在流量上存在高低峰，反映在资源使用上也有高低峰。
 *  关键核心在线服务的服务质量下降无法接受。

整体来说，从当前硬件架构和操作系统设计上看，虽然在资源分配上，理论上是进程作为独立的分配单位，资源相互隔离，但在实际使用上却是共享的，典型的包括CPU、网卡、I/O总线、Cache以及内核软件资源等。当然，软硬件如此设计本身就是为了提升整体资源利用的效率，提升整体任务的处理能力。而提升资源利用率，从本质上讲，是提升资源的复用共享，避免资源闲置浪费。但是提升资源共享复用水平，多少都会影响进程运行的效率，且随着复用水平越高，影响越大。

操作系统提供了一系列的资源隔离保障措施，意图降低服务在资源使用时彼此间的干扰，一定程度上在保障资源共享复用的同时提升了资源隔离的能力，但由于底层硬件架构上的限制，这种提升是有限的。而对于大多数业务的在线服务，服务质量的波动，比如延时增加、TPS下降等是难以接受的，特别是类似支付、订单类的核心服务。这是造成了当前数据中心整体资源利用率低的根本矛盾：一方面是在线业务对资源竞争导致的服务质量下降是难以容忍的，在线服务质量必须保障，另一方面当前大规模的数据中心在整体上资源利用率水平低，运营成本居高不下，亟需提升资源利用率，而提升资源利用率、降低运营成本会直接影响到在线业务服务质量。

一方面，“服务质量”关系着业务的服务体验，直接关系到营收，而另一方面，“提升资源利用率”，又有着巨大的成本空间可以降低，能够增加整体的收益。二者对于企业来说，就像“鱼与熊掌不可兼得”的矛盾。

![54e94729df2c58b4ba333debb1acf83d.png][]

图1 美团在线服务双峰特征

当前业界，很多企业和研究单位都在投入大量的资源来研究如何解决这一矛盾，努力实现整体利益的最大化。

**LAR（Load Auto-Regulator），聚焦于“资源利用率提升”和“服务质量保障”这一矛盾的解决，整个系统设计的根本出发点，即是在集群资源运营上要实现资源利用率和服务质量的双重保障，解决数据中心运营中的“鱼与熊掌不可兼得”难题和挑战。**

#### 2.2 系统架构 ####

提升资源利用率的本质是提升资源共享复用水平，而保障服务质量则需要通过资源隔离能力，保障服务的性能稳定。针对上述两个根本点，LAR在Kubernetes上提出两个核心创新点：

*  **资源池化分级**
    
     *  通过将单机资源划分到不同的资源池，提升资源在池内的共享复用水平。
     *  不同的资源池之间有不同的优先级，并提供不同的资源隔离水平（资源隔离水平越高，资源共享复用水平越低）。
     *  资源在不同优先级的资源池之间根据优先级和资源池的资源负载水平流动，优先保障高优资源池服务的资源使用，从而保障其服务质量。
 *  **动态负载和静态资源映射**
    
     *  资源的分配，本质上是负载空间的分配。假设单机整体CPU利用率小于50%的情况下，运营在其上的服务的服务质量不会有影响，那么这个机器的静态资源其实对应的就是节点50% CPU利用率的负载空间。换个角度看，就是无论如何调度分配资源，只要这个节点的负载不超过50%即可。
     *  业务静态的资源申请，根据服务的特征经过调度计算后，服务被放入对应的资源池，而资源池的资源配置则根据池内所有服务的实际负载进行资源配置，并可以实时地根据负载调整资源配置，实现静态资源分配和动态负载的映射管理。

上述两个核心创新点在帮助提升资源共享复用的同时，通过负载管理和操作系统提供的单机资源隔离能力，实现分级的服务质量保障的机制，具有很强的通用性，应用场景也比较广泛。

结合上述的核心创新点，LAR的整体设计目标包括：

*  相较于Kubernetes，提供分级可编辑更细致灵活的QoS服务质量保障机制，充分保障核心服务的资源供给及服务质量。
 *  建立负载与资源之间的映射关系，解决Kubernetes基于Request的静态资源调度难以解决的节点负载问题，降低负载动态调度的整体复杂度。
 *  提供灵活且具有一定通用性的单机资源调度能力，实现不同服务间资源的错峰复用。
 *  提供更强力的资源隔离能力，保障核心在线业务的服务质量前提下，提升整体的资源利用率。

![eb6fb80ec743078d69998fec6317bc7d.png][]

图2 Hulk资源利用率运营体系

在Hulk整体资源利用率运营体系中，LAR基于Kubernetes扩展，负责单个集群的资源管理和调度。相较于Native的Kubernetes，LAR提供分级可编辑更细致灵活的QoS服务质量保障机制，充分保障不同服务的资源供给及服务质量。

而LAR依托于底层的MTOS提供的资源隔离能力和调度资源Buffer池的物理机弹性伸缩能力，并根据集群运营数据中心和服务画像提供的集群及服务等特征，向上提供精细化的动态资源调整、负载管理以及QoS服务质量保障能力。统一调度系统在LAR之上，根据LAR提供的动态资源及服务质量数据，完成不同应用场景下，包括在线服务和离线服务的跨集群统一调度。

LAR处于整个资源利用率运营体系中核心关键位置，从功能上来看，整个产品分为五大主要功能模块：

*  资源分级管理模块
 *  资源池配置管理模块
 *  服务质量保障模块
 *  资源隔离管理模块
 *  策略配置模块

上述五大功能模块由LAR系统中3个核心组件来落地实现。LAR是基于原生的Kubernetes进行研发扩展，如下图3的整体架构所示，LAR在Kubernetes的基础功能上，扩展了Scheduler和Kubelet的功能，并新增Recommender和QoSAdaptor两个组件。对Kubernetes原生组件的扩展均采用插件开发的模式，减少对原生组件的入侵式修改，从而降低未来运维和升级的成本；对于新增组件，遵循云原生的开发模式，包括代码风格以及运行机制，和Kubernetes保持统一。

![b7de93271c57aaaad419fc8bde79b58f.png][]

图3 LAR系统架构

**QoSAdaptor**

QoSAdaptor主要负责服务质量保障，其核心功能是负责单机资源的分池分级管理，提供分级的单机QoS服务质量保障机制。QoSAdaptor分为五个功能模块：

*  **指标采集模块**：通过Cadvisor、Node-Exporter等工具采集节点与容器的指标，为资源池管理提供决策依据。
 *  **资源池管理模块**
    
     *  资源动态配置管理：根据数据指标对资源池实时进行负载计算，并基于负载策略及优先级动态调整资源在各级资源池的配置。
     *  QoS服务质量保障：实时监控负载指标，依据资源池的优先级管理策略，在资源竞争的情况下，通过资源抢占、服务降级及驱逐等多种手段分优先级保障服务质量。
 *  **资源配置管理模块**：基于各资源池的配置，通过Cgroup等系统工具，对不同资源池的资源进行隔离与限制。
 *  **资源上报模块**：周期Patch节点的资源使用情况、资源池负载等信息。

![9e289bba7b4ee49b406df87b13eec78a.png][]

图4 QoSAdaptor与Kubelet

QoSAdaptor以DaemonSet的形式部署在Kubelet节点上，核心功能是实现资源池和容器的资源配置管理。如上图4所示，我们通过自研的CRI Plugin，以Runtime Hook的形式在容器生命周期管理中引入自定义的QoS保障机制。

由于QoSAdaptor的资源调整与QoS服务质量保障动作，均基于本地指标采集并进行实时的负载和策略计算，不依赖外部监控系统，减少了数据传输时延，在保证服务的稳定性同时确保可以秒级响应资源配置调整和服务质量保障动作，保障业务容器的稳定性。

**Recommender**

Recommender主要负责LAR运行中策略及参数的配置更新，依托外部服务数据，周期性计算并更新LAR相关策略参数，提供统一的集群策略配置入口。

![2e8c6d7df316fb41eeb422adb2734cee.jpeg][]

图5 Recommender与其它服务组件调用关系

Recommender以集群为维度，每个集群部署一套服务。如上图5所示，Recommender通过集群运营数据中心和服务画像服务的离线数据，周期迭代计算LAR的策略参数。主要功能模块包括：

*  **资源预测**：根据离线监控数据及服务画像数据，对节点物理资源未来的使用情况进行提前预估，指导节点的不同资源池的资源配置，并可能触发QoS服务质量保障动作以及集群级别的资源调整，比如节点扩容及服务重调度等。
 *  **策略计算**：根据节点的各级资源池负载数据及集群运营数据中心的集群服务质量数据，周期性迭代更新各级资源池的负载控制及资源配置策略，保障服务质量的同时不断提升资源利用效率。此外，策略计算会定期更新QoS服务质量保障机制中的相关策略，比如服务降级、驱逐等判断条件。
 *  **参数配置**：提供统一的QoSAdaptor参数配置，实现配置变更分发的功能。

**Scheduler**

在LAR中，通过静态资源和动态负载之间的映射，进而在调度层屏蔽了动态负载变化，在调度层面降低了根据负载进行动态调度的复杂度。

Kubernetes默认根据业务申请的资源规格进行资源的调度分配，并以此设计调度计算框架和算法。但由于业务申请的资源规格是个静态值，且业务方对服务资源的使用通常倾向于放大评估，进而导致整体的资源申请和实际资源使用时存在较大的Gap。我们进一步考虑到资源的使用通常是动态的，也具有规律性的波峰波谷。这两点因素导致在集群的运营上，整体资源分配率接近满分配的情况下，资源使用率平均水平其实很低。

传统的方案通过节点资源超售来解决资源申请和实际资源使用之间存在的Gap，并引入根据负载的动态调度策略。调整节点资源超售，虽然能在一定程度上缓解资源申请和使用的Gap问题，但由于Gap在不同的服务间并不相同，加上服务资源使用的波峰波谷分布集中的情况（美团在线业务的典型特征），此方法在整体上过于粗放，会导致节点间的负载分布不均衡，部分节点负载很高，影响服务质量；另一部分节点负载极低，实际上形成资源浪费。而根据负载直接进行资源调度，由于负载是动态变化的，在调度算法设计及计算框架实现上会非常复杂，且效果一般。

在LAR中，我们通过引入资源配置因子（RCF，Resource Configuration Factor，资源池内的资源配比，动态控制池内容器的实际可用资源，数值区间为(0, 1\]），根据负载调整实际的资源分配，从而将负载的变化映射为可调度剩余资源的变化。如下图6所示，资源负载即为实际的使用资源，是动态变化的，静态资源是指资源总量和业务申请的资源规格，RCF由服务所在的节点的资源池决定，根据服务的历史资源使用数据和服务画像进行计算，并周期进行迭代更新。

![e7b5b81e78962a42f1f858f9677cd544.jpeg][]

图6 RCF实现节点负载和可调度资源转换

#### 2.3 关键能力实现 ####

围绕资源利用率提升和服务质量保障，LAR系统实现了以下关键技术：

*  **分级池化资源模型**：实现资源分池动态管理以及资源池优先级管理。
 *  **资源动态视图**：实现负载和资源配置之间的动态映射，简化负载管理，保证负载的均衡度，保障服务质量。
 *  **QoS保障机制**：根据负载管理的资源配置，在资源竞争的场景下，提供资源抢占以及服务降级驱逐等功能，提供分级服务质量的保障能力。
 *  **资源智能运营**：通过池间资源配置、池内负载配置、历史负载预测等运营策略，自动化调控节点资源分配情况，从而达到提升资源利用率的目的。

2.3.1 分级池化资源模型

分级池化资源模型是LAR整个设计的核心，整个模型包括资源分池动态管理和资源池优先级管理两个核心设计。

**资源分池动态管理机制**

资源分池动态管理引入资源池的概念，通过将节点资源进行分池管理，实现资源池内部资源高度共享，在提高资源复用率的同时，通过池间资源隔离达到池间服务的干扰隔离。资源池内资源的配置依据服务的负载进行动态调整，并通过资源配置的调整，控制资源池内部的资源负载维系在相对稳定的范围内，从而保证服务质量。

**资源池优先级管理机制**

在资源分池动态管理机制基础上，LAR引入资源池优先级管理机制，通过分级的服务质量保障机制，保障业务的服务质量。在资源池优先级管理机制中，不同的资源池具有不同的优先级，对应不同级别的服务质量保障级别。不同优先级的资源池，在资源配置管理上有3点区别：

*  **资源配置管理策略不同**：资源配置管理策略用于决策资源池的资源配置，并通过资源配置控制资源池的资源供给和负载水平。对于优先级高的资源池，资源配置充裕，资源池内的负载维系在安全稳定的水平，并通过资源池的资源隔离能力，实现对资源池内部服务资源使用的优先保障，从而保证更高的服务质量。
 *  **资源隔离保障能力不同**：高级别的资源池依托系统内核等提供的资源隔离能力，提供更高级别的资源池资源隔离级别，通过实现资源的独占或优先抢占使用，达到高优资源池内部服务在系统进程级别资源调度时的优先保障。比如，对于高优资源池，可以进行独立的CPU互斥绑定、I/O隔离等，保障其内部服务不受池外服务的影响。
 *  **优先级资源抢占机制**：资源池的资源配置可以动态调整，在高级别资源池配置资源不足，池内负载过高时，QoS服务质量保障机制会根据资源池优先级，高优资源池可以抢占低优资源池已配置的资源，通过牺牲低优资源池服务质量水平，优先保障高级别资源池的资源供给，保障高优服务的服务质量。

在LAR的分级池化的资源模型中，节点空闲资源，放置到优先级最低的资源池内，其它资源池的资源配置由服务的资源申请规格、资源池资源配置管理策略以及资源池资源负载决定。在资源池资源配置管理策略中，包含资源池目标负载和资源池RCF两部分内容。资源池具体的配置资源由服务申请的资源和资源池实时负载决定。当实时负载升高时，LAR会调整对应资源池的RCF，增加资源池的资源配置，降低资源池负载；当资源池负载降低时，LAR会通过调整RCF降低资源池的资源配置，释放冗余资源。

![36e7148570fa3bcd22157cbd32368ed2.jpeg][]

图7 LAR单机资源分配及资源池资源调整

上图7以3级资源池为例，节点资源被划分为0、1、2三类资源池，优先级依次降低。初始整个机器无服务调度其上，资源全部集中在Pool2。随着服务的调度，Pool1先调度了服务1，这时会根据上述的资源计算方式，LAR将Pool2的对应的资源调整至Poo1，Pool2资源减少。随着Pool1中服务增多，配置的资源随之增多，Pool2相应资源减少。优先级最高的Pool0调入服务后，同样的资源从Pool2调整至Pool0；Pool2调度入服务时，Pool2资源不变。

3个资源池配置不同的资源配置管理策略，0号池优先级最高，池内目标CPU负载控制在30%～50%之间；1号池优先级次之，池内目标CPU负载控制在45%～60%之间；2号池优先级最低，池内目标CPU负载控制在50%～80%。已分配的资源由资源池内服务共享，在池间相互隔离。在负载低时，不同资源池根据资源池管理策略，自动调整各资源池的资源配置，保证资源池内负载稳定；出现资源紧张时，高优资源池可以从低优资源池抢占资源，优先保障高优服务的资源需求。

2.3.2 动态资源视图

LAR通过引入动态资源视图，将静态资源与动态负载进行映射，并基于资源池的实际负载进行更精确的资源分配决策。

当在线资源池出现负载波动时，池内分配资源会随着负载进行变化，引起池间的资源流动。池间资源流动遵循以下规则：

*  所有资源池的池内分配资源之和为节点可分配的资源总量。
 *  当池内负载降低，释放资源到最低等级的资源池，复用闲时资源。
 *  当池内负载升高，向等级低于自身的资源池，根据从低到高的顺序进行资源请求，根据优先级满足服务资源需求。
 *  池内的资源最多不会超过用户申请的量。

![b6f69a4959525be36998c1a0ea694623.jpeg][]

图8 动态资源视图（以三级池为例）

如图8所示，以3级资源池为例：

*  当Pool1负载升高时，从等级更低的Pool2抢占资源，优先保障自身的服务资源需求，Pool1负载降低时，将冗余的资源释放回Pool2。
 *  当Pool0负载升高时，优先从Pool2抢占资源，当Pool2资源不足时，从Pool1抢占资源，保证更高等级的服务资源需求，当Pool0负载降低时，冗余的资源被释放回Pool2，此时若Pool1存在负载压力，则会重新从Pool2抢占资源。

下图为资源池内负载与池内分配资源的变化情况，可以看到其变化趋势与美团在线服务负载特性基本保持一致。

![e125e242d4b3a25b9e4ea4f98509c341.jpeg][]

图9 节点池内负载与池内分配资源变化情况

2.3.3 QoS服务质量保障机制

提升资源利用率会导致资源竞争，LAR通过池间、池内两层QoS服务质量保障机制，分级保证服务的隔离性和稳定性。

**池间多维度资源隔离**

LAR对资源池进行了多维度的资源隔离与限制。除了基础资源（CPU、Memory），还对磁盘I/O、CPU调度、Memory Cache、内存带宽、L3 Cache、OOM Score、网络带宽等更细粒度的资源进行了隔离，进一步提升不同等级服务间的隔离性，保证服务不会受到其他资源池的影响。

![3009e489b085045bf9df3acafec7a16e.jpeg][]

图10 多维度资源隔离

美团操作系统团队针对LAR场景进行了隔离增强，关于MTOS相关特性的详细介绍，大家可持续关注美团技术团队公众号的相关内容。

**池内多层级保障策略**

当资源池内负载出现不符合预期的情况时（如容器负载异常），由于资源池内资源共享，整个资源池的服务都可能受到影响。LAR基于资源池内不同的负载等级，制定了多级保障策略。

LAR提供了资源释放、资源抢占、CPU降级、Cache释放、容器驱逐等负载处理策略。QoSAdaptor周期性（秒级）地获取节点负载的数据，并计算资源池的负载等级。当负载达到一定的资源等级时，执行对应的负载策略。通过CPU降级、驱逐等行为，根据优先级对部分容器进行资源降级，保障池内绝大多数容器的稳定性。

*  **容器驱逐**：Kubernetes原生的驱逐策略基于整个节点的负载，LAR中将策略缩小到了资源池维度，当池内Memory使用接近Cgroup限制，避免整个资源池出现OOM，影响所有容器的正常运行，会结合优先级筛选Memory使用较多的容器进行驱逐操作。
 *  **CPU降级**：池内CPU负载超过一定负载等级，避免高负载导致的容器间互相影响，LAR会结合优先级筛选CPU使用较多的容器，对其CPU使用进行单独的限制。降级操作存在定时检查机制，当负载恢复正常，或有资源可以抢占的情况下，会将CPU限制进行恢复。
 *  **强制抢占**：从更低等级的资源池抢占资源，与普通资源抢占的区别为，即使资源已经被其他池使用，强制抢占会优先满足高等级资源池的需求。

2.3.4 资源智能运营

LAR基于资源池的历史负载与历史分配情况，对池内高峰资源使用情况进行预测，为节点资源调整提供指导。

由于资源池负载变化比较频繁，同时受到池内服务变更、资源总量、高低峰时间区间等因素的影响，节点基于实时负载进行池内资源的变更较不稳定。Recommender周期性地根据各节点资源池的历史负载与分配情况进行高峰资源预测，并下发到节点，提供高峰负载控制指导，提升资源池资源保障的稳定性。同时通过RCF完成动态负载和静态资源的转换，在调度层屏蔽了动态负载变化，减少负载频繁变化对调度准确性的影响。

![d7e9bec0bc836c062221f5726931f9aa.jpeg][]

图11 基于历史负载的资源预测

### 3 应用场景 ###

LAR的设计目标是在保障服务质量的同时提升整体资源的利用率，在资源分池分级的设计上，针对通用的在线服务进行服务分级，对接不同资源池，提供不同的服务质量保障，从而提升资源的利用率。而对于离线服务，本身相对于在线服务的服务质量要求低，故而LAR天然地适用于混部场景。

#### 3.1 在线场景 ####

对于在线服务，通过对服务进行分级，并通过服务画像对服务进行细致刻画，将资源敏感型服务和关键核心服务部署到LAR优先级最高的资源池中；而对于一般的在线服务，部署在次优先级资源池。高优资源池提供更细粒度与严格的资源隔离手段（包括绑核、进程级优先调度、I/O隔离、网络隔离、Cache隔离等），以及在资源竞争时高优的资源供给保障，保证池内服务的质量稳定。

![f4caea87d9c2ced80c21d8fe4119f784.jpeg][]

图12 LAR在线场景资源池

如上图12所示，一方面我们对高优资源池配置更强的资源隔离策略（比如CPU绑核、进程优先调度等），另一方面在池内资源配置上，高优资源池的资源配置更高。转换成资源池的资源利用率，高优池资源利用率控制在一个安全较低的水位；而低优池，则相对在一个更高的水平。而由于高优池主要针对关键核心且对资源敏感的在线服务，其在整个在线服务中相对比例不超过20%。从而能整体提升整机的资源利用率水平。

LAR在线服务场景中的应用，目前在Hulk的线上线下均已落地，如图13所示线上LAR集群（蓝色曲线表示）的整体平均CPU利用率相对于Native的Kubernetes集群（橙色和绿色曲线表示）平均高5到10个百分点，但整体平均服务质量（图14）和Native的Kubernetes集群反而更稳定。其中LAR集群目前作为在线集群使用，暂无离线服务接入。

![071df0e639c707cae8e6d0d3a0feb654.jpeg][]

图13 在线集群资源利用率

![0dc76edb650d38c92144c6484255c90f.jpeg][]

图14 集群服务质量

#### 3.2 混部场景 ####

混部主要就是通过将延时和稳定性容错性更高的离线服务和在线服务混合部署，实现在线服务和离线服务在资源使用时空上的削峰填谷，如下图15所示：

![184bf7ae41f14283e702b4e9bf17209d.jpeg][]

图15 混部场景资源复用

从上述章节介绍的LAR资源模型可知，LAR资源模型的核心特征包括：

*  资源分池分级管理，池内资源共享，池间资源隔离。
 *  资源池资源配置由资源池优先级和资源池内负载决定。
 *  QoS服务质量保障机制根据负载调整资源池的资源配置，优先保障高优资源池资源供给。

有了上述能力的保障，LAR天然地适应于混部场景。在混部场景中，假设将资源池分为0、1、2三个级别，优先级依次由高到低。0和1号池分别对应核心关键在线服务和一般的在线服务，而2号池对应离线服务使用的资源池。LAR的资源动态调整保障负载能力，会自动将0号池与1号池在业务低峰期（负载低）的闲置资源回收，提供给2号池的离线服务使用。并且QoS服务质量保障机制，可以确保在业务高峰来临时，秒级抢占2号池资源（对于内存等非复用型资源，通过驱逐方式强制回收），从而保障在线服务的资源使用。

目前，LAR集群已陆续接入离线服务进行混部的验证。

### 4 演进规划 ###

![0bea7ec5ce12072fc1fd6e2076254c96.jpeg][]

图16 LAR演进规划

LAR系统从2021年开始规划并启动建设，1.0版本我们完成了资源分级系统、负载驱动的动态资源视图建设。2.0版本，我们主要完成了服务质量保障体系建设。目前，我们正在与美团内部多个业务方深度进行合作，探索服务分级接入及混部场景的应用。未来，LAR会继续在自动化智能化运营和混部场景应用进行探索迭代。

### 5 作者简介 ###

启超、汪喆、谭霖等，均来自美团基础技术部/基础软件中心Hulk调度系统。

\---------- END ----------

**招聘信息**

基础技术部-基础软件中心-调度系统组，主要负责支撑业务在容器调度的需求，保障集群稳定性，提升资源使用率，提供基于Kubernetes的云原生编排引擎，提供ETCD服务，支撑PaaS服务云原生落地，服务于公司云化战略目标等。

目前，团队诚招高级工程师、技术专家，团队技术氛围浓厚，工作内容具有较高的技术挑战，诚邀对集群调度技术感兴趣自驱力强的伙伴加入，共建公司级的业界领先大规模复杂场景的调度系统，在效率、性能和成本优化上共同探索前进。欢迎有兴趣的同学投送简历至： edp.itu.zhaopin@meituan.com（邮件主题请注明：Hulk调度系统）

**也许你还想看**

**|** 美团集群调度系统的云原生实践

**|** 美团集群调度系统HULK技术演进

**|** 美团弹性伸缩系统的技术演进与落地实践

**阅读更多**

\---

前端 **|**[ ][Link 1]算法 **|** 后端 **|** 数据

安全 **|** Android **|** iOS  **|** 运维 **|** 测试

[54e94729df2c58b4ba333debb1acf83d.png]: https://img-blog.csdnimg.cn/img_convert/54e94729df2c58b4ba333debb1acf83d.png
[eb6fb80ec743078d69998fec6317bc7d.png]: https://img-blog.csdnimg.cn/img_convert/eb6fb80ec743078d69998fec6317bc7d.png
[b7de93271c57aaaad419fc8bde79b58f.png]: https://img-blog.csdnimg.cn/img_convert/b7de93271c57aaaad419fc8bde79b58f.png
[9e289bba7b4ee49b406df87b13eec78a.png]: https://img-blog.csdnimg.cn/img_convert/9e289bba7b4ee49b406df87b13eec78a.png
[2e8c6d7df316fb41eeb422adb2734cee.jpeg]: https://img-blog.csdnimg.cn/img_convert/2e8c6d7df316fb41eeb422adb2734cee.jpeg
[e7b5b81e78962a42f1f858f9677cd544.jpeg]: https://img-blog.csdnimg.cn/img_convert/e7b5b81e78962a42f1f858f9677cd544.jpeg
[36e7148570fa3bcd22157cbd32368ed2.jpeg]: https://img-blog.csdnimg.cn/img_convert/36e7148570fa3bcd22157cbd32368ed2.jpeg
[b6f69a4959525be36998c1a0ea694623.jpeg]: https://img-blog.csdnimg.cn/img_convert/b6f69a4959525be36998c1a0ea694623.jpeg
[e125e242d4b3a25b9e4ea4f98509c341.jpeg]: https://img-blog.csdnimg.cn/img_convert/e125e242d4b3a25b9e4ea4f98509c341.jpeg
[3009e489b085045bf9df3acafec7a16e.jpeg]: https://img-blog.csdnimg.cn/img_convert/3009e489b085045bf9df3acafec7a16e.jpeg
[d7e9bec0bc836c062221f5726931f9aa.jpeg]: https://img-blog.csdnimg.cn/img_convert/d7e9bec0bc836c062221f5726931f9aa.jpeg
[f4caea87d9c2ced80c21d8fe4119f784.jpeg]: https://img-blog.csdnimg.cn/img_convert/f4caea87d9c2ced80c21d8fe4119f784.jpeg
[071df0e639c707cae8e6d0d3a0feb654.jpeg]: https://img-blog.csdnimg.cn/img_convert/071df0e639c707cae8e6d0d3a0feb654.jpeg
[0dc76edb650d38c92144c6484255c90f.jpeg]: https://img-blog.csdnimg.cn/img_convert/0dc76edb650d38c92144c6484255c90f.jpeg
[184bf7ae41f14283e702b4e9bf17209d.jpeg]: https://img-blog.csdnimg.cn/img_convert/184bf7ae41f14283e702b4e9bf17209d.jpeg
[0bea7ec5ce12072fc1fd6e2076254c96.jpeg]: https://img-blog.csdnimg.cn/img_convert/0bea7ec5ce12072fc1fd6e2076254c96.jpeg
[Link 1]: https://t.1yb.co/jo7v