美团点评容器平台HULK的调度系统(3)

当调度计算过程决策出一个根据调度rank权重排序好的资源可部署位置列表后,调度任务会取列表前n个元素,依次向对应的宿主机Actor申请资源,直到宿主机Actor返回批准(调度成功)；如果取出的前n个均被拒绝,调度任务需要根据新的全局资源池共享状态再次调度计算.

如果两个调度任务基于共享资源状态同时申请某个宿主机上同一块资源,则宿主机Actor会根据mailbox中消息的顺序来处理,资源先到先得,后者调度任务会继续向下一个备选资源的宿主机Actor尝试申请.

调度资源申请

这种资源调度的架构下,调度的并发度相比串行调度有了显著的提高,即使出现提交冲突,重试机制也是非常轻量的,一般都可以在前n次之内完成.

这里另一个核心问题在于n取值的权衡.如果n取值1,则每次失败后就需要根据当前的集群资源状态重新调度计算,这种情况下调度资源利用率较高,但效率较低；而若n取值大于1,则重试后的调度位置往往并非当前最佳调度位置,且n越大这里的最优调度偏差就越大.我们考虑的是根据当前整个系统中的调度请求数量来确定这个动态的n变量取值,当调度任务较少时n取较小值,当调度任务较多、弹性伸缩频繁时,n的取值会相应调大.

调度模式总结

总的来看,HULK调度系统的共享状态资源调度模式与Omega比较相似,不同的是Omega采用MVCC为每个节点维护一个状态关系数据库,而HULK使用Actor模型来解决提交冲突.另外,HULK调度任务的n次最优重试机制,在互联网的弹性伸缩场景下可以带来更高效的调度能力.

结束语

弹性调度系统作为HULK平台的核心模块之一,有着下接美团云IaaS平台、抽象化资源层,上承弹性伸缩系统、处理调度请求的职责.我们从美团点评的服务特殊性出发,打造适用于大规模容器化场景的调度体系,后续还会在大数据离线任务场景下做更优化的深层智能调度.

此外,我们对Kubernetes等开源解决方案同样抱有极大的兴趣,从Kubernetes近年来的发展上能看到未来容器平台的标准雏形,我们也在积极参与和回馈开源社区.

文章来自微信公众号：Docker

（编辑：ASP站长网）