2.2　资源调度性能

在很多PR（Public Relations）宣传中，资源调度性能往往涉及整个IDC管理的规模[11]。对于技术人员来说，需要抓住有效信息——单个调度域或者部署域管理的集群服务器规模（物理机、容器或者虚拟机规模）、全局多调度域或者部署域协同和管理的集群总规模（物理机、容器或者虚拟机规模）。资源调度的性能与规模，与资源并发冲突量等有关。

例如，在100个空的NC上并发申请200个VM（Virtual Machine，虚拟机）和在50个空的NC上并发申请200个VM，其实是有差别的。第一，VM依赖的镜像下载性能，在不加速或者加速对镜像源、单机下载时，I/O性能有不同的表现；第二，在NC上并发创建VM的排队性能开销不一样；第三，调度规则的约束、打散要求会影响滚动交付的时长—交付1个VM的时间和100个VM全部交付的时间完全不一样。

NC心跳管理和VM数据同步更新，直接影响调度元数据的交互、更新模式，间接影响调度的性能。按分治策略，多个集群通过Proxy在服务接口API层实现负载均衡，可以缓解单个大集群调度管理的压力。50万个NC、10个调度域和5个调度域，在调度架构设计、性能关注点上也会不一样。

下面讨论在单个调度域前提下，一定规模的宿主机，并发批量生产容器或者虚拟机时的吞吐量、响应时间、故障感知时长、故障迁移周期。

1.批量生产吞吐量

对于批量生产吞吐量，通俗的理解是，在N个物理节点的集群中，按照系统支持的最大并发数进行资源并发申请后，在单位时间内总的生产实例（容器或者虚拟机）数量。这一方面与调度系统有关，例如资源视图的更新、资源扣减冲突的解决方案等；另一方面与底层容器或者虚拟技术有关，例如容器镜像是否加速、是否预热及虚拟机镜像技术等会对性能有一定的影响。

2.响应时间

响应时间是指从发起请求到请求完成并成功返回的时间。这里的成功返回是针对原子交付而言的，比如申请100个实例，100个全部成功；否则称为尽力交互，比如申请100个实例，实际成功多少就是多少。在尽力交付场景下，通常响应时间以满足申请数量的一个成功比例或者成功达到多少台机器所需的时间来衡量。例如申请100台机器，成功比例为99%，也就是成功返回99台机器，如所需的时间是1s，那么尽力交付的时间就是1s。

3.故障感知时长

故障感知时长是指NC故障或者实例故障被感知并发出告警需要的时间。在规模性的集群中，采集、回流、聚合、预警协同决定了故障感知时长。

4.故障迁移周期

故障迁移周期是指从发现故障到故障节点VM被迁移到新节点的时间。特别是有状态的节点，会大大提升迁移成本，增加迁移时长，甚至变得不可控。

调度性能优化实践建议

结合具体场景和在线服务类型，在没有突发资源需求时，吞吐量一般不被纳入核心指标中，响应时间的重要性更突出，因为它影响业务扩容发布的效率和体验。在突发资源诉求场景下，尤其是依托云服务供应商的资源，吞吐率、响应时间都是重要的指标，直接影响快上快下的时间。