1.3　集群资源调度

本书中的集群调度具有明确的指向性，即聚焦于资源侧的调度，如虚拟机调度（IaaS资源）、容器调度（PaaS资源）。服务调度（SaaS资源）不属于本书讨论的范畴，如流量调度［4］、FaaS［5］函数计算等。本书也不讨论机房建设、机架部署、供电、服务器硬件研发等。用一句话概述本书中的集群调度，就是：将一些物理机组成一个资源池，在逻辑上分为多个集群，从集群视角将这些资源以虚拟机或容器为单位进行切分，交付上游系统。上游系统基于资源，实现面向最终应用服务的需求，做进一步处理，例如PaaS服务运维、安装业务软件等。

1.3.1　资源调度解决什么问题

在给定的资源池中，按照一定的资源约束条件，筛选合适的宿主机，生成相应规格的虚拟机或者容器实例，并最大限度地确保资源池的资源分配率最高，即碎片最小。同时，在资源实例运行时过程中，在不影响业务服务质量、稳定性的前提下，集群利用率最优。通俗地讲，应用扩容时，只需提交一个应用分组（对应关联资源实例规格、实例约束条件）、资源位置和资源数量，调度系统就会自动选择最佳资源坑位，申请应用所需的网络资源，如网络IP地址、网络安全组（VPC）、计算资源（CPU、vCPU）、存储资源（Buffer、磁盘）、安全分组（Security Group）、位置（Pod、Rack、Switch）等各种资源。

所面临的挑战是在集群资源调度过程中，始终需要考虑平衡成本、稳定性和效率问题。在不同的场景下，某些维度权重更高；在不同的发展阶段，侧重点会有所不同。例如电商平台大型促销活动，稳定性优先。在资源编排持续交付的过程中，需要确保编排关系可预知、可控、逐步收敛，而对资源利用率不会贸然要求很高的目标值，如cpu avg util 55%。这个约束不是不关注成本问题和大促资源利用率，而是说稳定性优先，资源利用率靠后。解决大促资源成本问题，一种方法是提高大促集群利用率（负载均衡、减少局部热点、提高整体利用率），减少服务器的采购；另一种方法是租用云服务器，快上快下，发挥云端突发资源供给优势，同时也可以提高链路效率等。

1.3.2　资源描述

本书中集群调度的切入点是资源调度，因此，首先需要理解资源——集群的计算资源、存储资源、网络资源等，如CPU、内存、磁盘等资源（假设网络资源不是瓶颈，网络平面共享）。对资源的定义和描述，本书从分层的视角来进行，主要是因为在实际生产过程中，对于日常答疑碰到的问题，其定位和处理往往是由对应模块的负责人员进行专业技术支持的。从资源使用者的视角是不区分资源是否分层的，使用者看到的是计算实例资源[4]。

1.资源——分层

在数据中心有很多“资源”，按照分层的视角，每一层都有相应的资源抽象，每一种抽象都可以被理解为广义上资源调度的一个调度因子。这里给出一种拓扑属性的分层结构，如图1-6所示。左图是分层抽象，顺序是：服务、应用、交换机、机架、物理机，其中cpuset［7］是宿主机范围的核心资源抽象；右图是资源抽象，顺序是：RT/QPS/ClusterSLA、应用状态/应用单元/应用站点/数量/亲和性、网络、功耗、Cgroup资源。

cpuset这一层资源的隔离主要依赖内核Cgroup等Linux Container［8］相关技术实现。这一层的抽象不直接关联具体的业务属性，对外展现的是一个个进程，以及进程的CPU、内存、磁盘、I/O、网络的运行时特征。这一层映射到成本、稳定性、效率，依赖宿主机内核资源的调度、隔离、共享机制和实现策略。

下面对cpuset资源做进一步的分类分析，如图1-7所示。

随着计算资源和存储资源的分离、网络带宽的升级，在新一代云服务器基础设施下，CPU、内存和CPU Cache的调配是资源调度系统需要持续深入关注的，而磁盘和网络的瓶颈会越来越小[5]。

除了基本的Cgroup概念，其实Cgroup V1、V2及Node的特性，对于进程创建前资源参数的选择、运行时的稳定性、单机本地资源的微调及性能数据的收集计算方式，都有很大的影响。建议读者深入了解Cgroup V2［9］相关原理、参数含义等，这里不做进一步说明。

2.资源——属性

在不同的语境、不同的开源调度系统中，对资源有如下一些特有的描述，本书将其称为“资源属性”。

● 压缩与不可压缩资源：可压缩资源有CPU、网络；不可压缩资源有内存、磁盘。这里的“压缩”体现在超卖场景下，指原本一份资源对多个资源组进程（如容器或者虚拟机）可见并分时共享。多个用户能同时看到资源视图，同时拥有资源的使用权（微观上，依然是分时共享；宏观上，所见即所得）。就拿CPU来说，超卖共享可以是共享cpushare或者共享cpuset。“不可压缩”体现为资源视图唯一对一个容器或者虚拟机可见。就拿磁盘来说，磁盘大小是多少就是多少，没法压缩。

● 虚拟资源：各种tag，如appStatus、appAffinity等。

● 实体资源：CPU、内存、磁盘、网络等。

● 位置资源：Pod、Rack、Region、Zone、NC[6]等。

资源属性的实践分享

可压缩资源在时空上往往体现出多个Workload同时对同一份资源可见，彼此之间可以进行资源的竞争和共享。竞争和共享是客观存在的，不用纠结资源可否不竞争、不共享。实践建议：直面资源竞争和共享，关注竞争和共享的程度，结合应用承载的波动能力等，最终一起实现基于SLA的服务质量。例如，一个无状态的Web应用有1000个实例节点，其中5%（影响的规模）的实例节点随机发生了竞争，竞争的程度（影响的维度、持续的时间）如CPU负载从10%提升到30%、持续时间为1～2秒（不是持续十几分钟），那么对于应用整体来说，影响是可以忽略的。而明显的影响是指，用户的浏览、购买或下单完全卡住或者明显中断。例如，在混部场景下，长周期任务和短周期任务，或者延迟敏感任务和非延迟敏感任务，在运行过程中会共享NC的CPU、网络资源。CPU、网络资源表现出“可压缩”的属性。

不可压缩资源在时空上往往反映出同一份资源只对一个Workload可见。例如，不同的Workload分时共享，保障磁盘空间满足需求。

虚拟资源一般服务于运维、管控类需求，在逻辑上对Workload进行管理和运维。一般情况下，调度器不予以感知，交给上游平台或者业务研发部门自己处理。其中，打散度[7]、应用任务等级在部分场景下是需要透传到调度器的。追求确定性稳定性、利用率的提升时，打散度、应用任务等级就是重要的编排因子。通过对资源实例的打散编排，可以避免单个物理节点故障对整体业务产生大范围影响[8]。资源利用率的提升、成本的降低带来资源的竞争和任务的动态降级，由此可见，应用任务等级就是重要的指标。应用任务等级与应用自身的响应时间、应用在业务中的角色、应用的成本预算等都有关系，需要综合评估。

位置资源在高可用、稳定性架构设计和实践中承担着重要作用，一般通过业务单元级别充分打散（地域或可用区级别的容灾）、业务单元内充分内聚（计算、存储、网络本地化，响应时间更短）、多单元部署，来平衡局部网络级别故障的影响面。如果业务天然存在某种中心化属性，无法单元化，就需要另行设计。例如，单点故障的快速失败转移（Fast Fail Over）、快速启动热备系统（Fast Backup）、业务一致性转为存储一致性等。

1.3.3　如何调度资源

基于Workload资源分配视角，如图1-8所示，长方形代表宿主机（NC），不同颜色的圆形、椭圆性代表不同资源特征的实例。如图1-9所示，新的Workload需要被分配到集群中，资源调度器进行资源调度决策，选择合适的NC来承载新的Workload需求。这里假设：集群已有充分的剩余资源可供资源调度器选择最合适的NC。我们可以通俗地理解成装箱的过程：将物理机看作箱子，将Workload看作一个细小的有形状的“商品”，然后选择合适的物理机（箱子）将Workload这个小“商品”装进去，箱子装得越满越好。

---

[1]这里的分层不是业界通用的，仅仅是服务于本书内容而人为设定的一个划分。

[2]对于有状态的任务，迁移性成本会比较高，需要避免大量有状态业务的扎堆部署。

[3]在交易场景下，一些资源天然承载的经济影响是有差异的。

[4]截至2019年9月，主流业务需要的计算处理服务，依然要求使用者对资源实例、资源位置有所感知，未来函数计算等Serveless［6］研发运维模式，可能应用Owner对计算实例透明，关注点集中在服务能力、SLA上。

[5]深入理解磁盘和网络的资源隔离控制，推荐几个入门级别的资源链接：见链接106～链接108。

[6]本书中出现的NC（Node Controller），统称为“物理机”。

[7]定义一个应用的容器或者宿主机实例，允许部署在同一台宿主机、同一个机架、同一个Pod中的数量或者占比。

[8]通俗地讲，就是不将鸡蛋放在一个篮子里。故障是不可避免的，是常态的，所以减小故障对整体的影响面是持续的目标。