2.5　资源实际利用率

集群部署上线后，只要业务跑起来，监控大盘就可以显示出资源实际利用率情况：或高或低，或者表现出周期性规律。从大盘上看到的数据，已经成为事实上的结果。分析资源实际利用率不是为了展示，而是为了优化、提升资源利用率。这需要事前、事中结合起来实现。事前：大盘数据显示，此时业务跑得好好的，因此不会轻易地改变、优化，除非问题特别突出。所以在机房建设中，预先诊断分析潜在的业务Workload特征、资源利用率画像情况，对优化资源利用率有宏观的指导作用。事中：对Workload实际资源消耗进行画像、重调度，逐步优化资源实际利用率。下面围绕资源宏观利用率分布、分配不充分、负载不均衡、编排动态调整来理解资源实际利用率的优化。

2.5.1　资源宏观利用率分布

资源宏观利用率分布的指导意义在于对资源整体的认知，以及为全局性决策提供数据支持。业务对性能、稳定性的敏感程度不同，以及业务处于不同的发展阶段，资源宏观利用率的关注点也有所不同。例如，是整体NC优先还是突出CPU、内存、磁盘等。一般情况下，优先考虑整体CPU资源分布。比如某集群瞬时利用率分析，图2-1所示为基于阿里巴巴某个历史集群在线服务视角的一张瞬时统计图。

图中，数字1表示物理资源；数字2表示运维管控资源，其中有僵尸失联（节点状态和数据在数据库中的记录缺失）；数字3表示已管控并量化与环境标准并量化紧密相关；数字4表示链路统一标准化与已管控并量化相关。Offline和Online是节点数量比率。在Online部分，细分为非混部（数字5）和混部（数字6）。非混部又分为特殊池和公共池，公共池有超卖和非超卖。混部因业务等级、性能敏感度不同，在逻辑上又分为在线服务与在线计算、数据库与在线计算、在线计算与离线计算。NC集群的CPU利用率，在线均值为～4%，离线均值为～66%，混部后为8%～45%。

宏观分析一个集群时需要关注的内容还是比较多的，不同的业务布局、集群角色、集群规划等，资源调度分配的策略、流量等均不完全一致。因此，分配不充分、负载不均衡、编排动态调整（业务发展引起负载行为持续变化）需要具体场景具体分析。

2.5.2　分配不充分

集群资源调度和管理的背后存在一些固有的约束，可以预见：资源[14]在分配之前客观上就分配不充分。分配不充分的原因一般有单机性能和容量约束、实例规格约束、实例编排规则约束。其他原因有资源运营、资源池的布局、系统工具的Bug、稳定性等相关因素。通常使用分配率指标来衡量资源分配是否充分，指导如何优化、平衡相关约束。

1.单机性能和容量约束

资源的容量约束条件一般包括：计算资源，如vCPU、GPU（Graphics Processing Unit）［12］的核数；内存资源，如内存大小；存储资源，如磁盘类型、磁盘空间大小、磁盘读/写带宽；位置资源，如Zone、Region、Rack等；其他，如性能NUMA的配置、业务自身的虚拟标签资源等。

性能约束有两个层面：一是物理级别的绝对性能，如CPU主频；二是资源共享时的性能，如多个实例共享同一宿主机时，单个实例获得的稳定性能。对于资源共享场景下的性能，打个比方：当马路上没有红绿灯、没有其他车辆，只有你一个人时，相对来说你是独占马路的，你可以跑得非常快，这是极限性能。实际上，马路是各种机动车辆共享的，每一辆车都是不可能获得极限性能的。映射到实际场景中：A应用在日常态的单机极限性能和在大促态（在线N个应用同时出现峰值）的性能不是完全等同的。间接的反应是，大促态的容量评估，不是简单的单机压测性能的线性扩展。大促态的容量评估，可以以“单元的业务容量”[15]为单位，对最小化一个单元启动所需的容量做初始化，然后全链路压测，并弹性扩容到预期容量。

2.实例规格约束

实例规格约束一般以vCPU、内存、磁盘资源的单位数量构成的资源为代表，反映一种计算实例的各方面资源的构成。例如规格4C-8G-60G，表示4个vCPU、8GB内存、60GB磁盘空间大小。多种实例规格在逻辑上可以归纳为实例规格簇，关于这方面信息可以参考阿里云实例规格簇官方文档［13］。规格的多样性，导致分配组合的多样性，从而导致无法完全将资源分配出去。

3.实例编排规则约束

实例编排规则约束包括硬件故障和高可用设计，如单机层面、实例不扎堆、可用区级别对等部署等。这样的亲和性、互斥规则，导致有限的位置资源无法匹配更大规模的应用位置诉求。换句话说，相同的位置资源，不能叠加到同一个业务或者应用，间接使得部分资源不能被完全分配出去。

2.5.3　负载不均衡

负载不均衡有如下几个原因。

原因1：请求量不均衡

例如，地域间的请求不均衡导致地域间负载不均衡。

原因2：Workload特征不均衡

有的应用是计算密集型的，有的应用是存储I/O密集型的，有的应用是网络I/O密集型的，这些应用混合编排部署到相同或者不同的集群，使得集群节点负载不均衡。尽管同一个应用在同一个可用区内，默认流量是均匀分布的，应用自身的负载是均衡的，但是物理节点的负载不一定就是均衡的。

原因3：容量规划不均衡

一些特殊的应用有特殊的资源诉求，如License、安全法规等，使得一部分实例独享一定的计算资源、存储资源和网络资源，而另外一些应用可以充分混合编排。在这种场景下，容量规划一开始就不均衡，通过Workload优化实现负载均衡很难奏效。

原因4：业务持续变化

由于应用具有Workload特征，特别是持续、快速变化的互联网应用，Workload生命周期一般很短，且最初的规划容量很快就因为业务变化而超出预期，使得承载业务的负载发生变化，进而使得物理集群的负载受到影响而出现不均衡。

2.5.4　编排动态调整

一方面，部分新应用上线、部分老应用下线、核心应用升级，使得应用混合部署，彼此间的编排关系在动态地变化；另一方面，硬件故障是常态，出现故障后，应用会发生迁移，应用间的组合关系会发生变化。上面两种现象在“非面向终态”调度中尤为突出，而“面向终态”因为持续向调度规则看齐，会减弱编排关系的不一致性。

随着业务的发展变化，应用的任务等级[16]、资源等级[17]也会发生变化，导致存量关系和新增关系的不一致性。而修复存量关系，往往意味着重新编排一次应用，间接改变了其他实例的关系。

综上所述，我们需要综合评估各方面因素，在确保业务稳定的前提下，逐步提升分配率和资源实际利用率。这也表明没有一种绝对的利用率提升方法，或者说很难有一种最优的利用率策略适用于各种场景。