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

由于将资源层信息作为共享数据提供给上层所有应用,Omega为了解决数据一致性,会对所有应用调度的提交冲突做解决,本质上是为每个节点维护了一个状态关系数据库.从这个角度看,Omega也存在一些缺点：

1. 共享调度时冲突发生的频率,直接影响了整体调度器的性能.
2. 由于没有集中的调度模块,难以对所有资源分组(Namespace)或用户的资源使用量做精确限制.
3. 上层调度器数量仍然不能很多,并行分发完整的集群状态的开销较大.

Borg与Kubernetes

Borg据说现在已经逐渐演进吸收了Omega的很多设计思想,包括共享状态调度模式,然而Kubernetes默认调度plugin的做法仍然是串行处理队列中的调度任务,这也符合Kubernetes追求的简洁优雅.

HULK调度解决方案

对于调度器设计难题,我们认为针对不同的场景,指标的侧重点不同.

比如对于分布式系统的CAP,大多数互联网场景下都会保证AP而舍弃C(只保证最终一致性),因为在互联网分布式集群规模大、网络故障频发的场景下,要保证服务高可用只能牺牲强一致；而对于金融等涉及钱财的领域,则一般保证CA、舍弃P,即使遇到网络故障时只读不写,也必须保证强一致性.

同理对于调度器资源层设计,在互联网高并发、弹性伸缩频发的场景下,可以牺牲部分资源利用率从而提高并发调度能力.

HULK调度系统模型如下：

HULK调度模型

如图,HULK调度系统分为调度请求队列、调度计算模块、调度资源池这三个模块.工作流程如下：

1. 上层HULK弹性伸缩系统,将调度任务ID写入调度请求队列中.
2. HULK调度系统消费调度请求队列,取出的调度任务ID将由调度计算池执行调度计算,决策出备选的部署位置,并向调度资源池申请资源.
3. 调度资源池维护管理宿主机集群资源,全部资源会提供给所有调度任务共享(与Omega类似),资源池中每个宿主机都有一个对应的Actor来负责管理.

调度计算模块(资源调度算法)

HULK调度系统的调度计算方式与诸多业界调度系统类似,通过过滤+打分的方式筛选出“最优部署位置”：

HULK调度任务

• 宿主机(Host)：调度资源池中共享的宿主机集群,支持pool级别硬隔离,如在线服务与数据库/缓存的实例部署在不同的物理机集群中；支持资源软隔离,如在线服务离线任务混布部署,通过cgroups等机制隔离和设置权重.
• 过滤(Filter)：预选(Predicates)的概念,通过超售、打散限制策略,排除掉一部分不合需求的宿主机.
• 打分(Rank)：优选(Priorities)的概念,通过在线离线混布、不同资源类型混布、宿主机负载均衡等策略和对应权重,最终计算出一个rank值,根据rank值排序最终得出最优部署位置.

超售

不管是在传统虚拟机时代还是容器时代,超售始终是一个让人又爱又恨的机制.

超售在一定程度上提高了集群的资源利用率,因为机器在申请之时往往提高对真实资源消耗的预估,也就是在服务运行中,绝大多数情况用不到申请的所有资源.然而正因为超售,常常会带来各种因资源争用引发的服务异常,严重的情况下会导致宿主机上所有实例的不可用.

HULK容器调度同样采用了超售机制,我们和IaaS层对资源进行了分类,可压缩资源(如CPU、I/O等)使用超售机制,而不可压缩资源(如Memory、Disk)只允许在一些测试环境超售.

相比于是否开启超售,超售系数才是更为棘手的难题,它直接关系到资源利用率和服务稳定性.我们采用了超售上限+动态系数的机制,从IaaS层设置的超售上限固定了资源超售的上限比例,超过上限的实例创建将会失败,而HULK调度系统会根据具体场景决定超售系数：

1. 参考宿主机实时监控,如Load负载、内存使用、带宽占用等指标.
2. 不同的实例类型(在线、离线)调度时超售系数不同.

业务实例打散

随着物理集群规模的扩大,宿主机故障频次也会响应提高.如果一个在线服务的所有实例都部署在同一个宿主机上,很可能出现宿主机宕机后服务整体不可用,这是我们不能接受的.

业务用户在HULK上配置不同的伸缩组,每个组对应了一个机房(数据中心),同个机房调度过程中会把同个服务的实例打散到不同的宿主机上,并优先在不同的交换机(机架)下.此外,针对数据库/缓存类的实例还有更严格的容灾策略,比如Redis实例调度部署时,不允许同一个交换机下部署超过该Redis集群25%的实例数量.

在线离线混布

一般来说,在线服务(如外卖、酒旅等服务)和离线任务(如定时任务、爬虫、大数据计算)的需求资源类型和高峰/执行时间不尽相同,将这两种实例进行混布可以有效提高物理集群的资源利用率.

Borg系统中对prod与non-prod实例的一类处理方式是,根据宿主机上实例运行状况,实时调整实例的资源配置.比如当在线服务迎来流量高峰、宿主机内存告急时,Borg会调整宿主机上non-prod任务的内存配额,以保证在线服务的稳定性.

但这种方案对Google中的部分C/C++服务适用,在美团点评Java服务的场景下,实例内存配额调整可能会导致OOM,而重启服务非我们所愿.

下图是HULK某台宿主机一天内的实例部署情况：

宿主机实例部署

目前HULK平台上的离线任务主要还是定时任务与爬虫,HULK针对在线离线混布场景从资源分配、时间错峰上优化.根据美团点评的服务特性,HULK会尽量保证在早晚高峰的时期动态扩容在线服务承接流量,而在低峰期会对应缩容在线服务,并调度部署离线任务执行.

宿主机负载均衡

在调度计算的打分过程中,还会参考当前宿主机的负载情况.

HULK会从监控系统中获取宿主机的系统监控数据,包括了CPU、Load、Memory、IO等指标.针对负载较低的宿主机我们给予较高的权重,而负载较高的宿主机,即使物理资源较为空闲,也不会优先选择部署.

调度资源池(资源申请算法)

（编辑：ASP站长网）