集群调度架构的变革 (二)

二级调度架构 通过隔离资源获取与任务来解决这个问题。这样任务调度逻辑可以针对特定的应用，这也可以保持在集群间共享的能力。Mesos的集群管理在这方面是先驱， 同时YARN支持一部分功能。在Mesos，资源是应用级别调度器提供的（被挑选和选中），而YARN允许应用级别调度器请求资源（在返回中得到配额）。 图1b展示了基本思想：负责负载的调度器（S0-S2）与资源管理器进行交互，资源管理器为集群资源的每个负载刻画出动态分区。这种方式可以支持定制化，针对负载的调度策略。

现在，分离了关注点的两级架构带来了一些缺点：应用级调度器丢掉了一些知识，例如，他们看不到所有可能的资源点，他们基本看不到这些与资源管理器组件提供的资源获取（Mesos）或分配（YARN）相关的选项。这有一些缺点：

1. 优先级抢占（高优先级任务踢掉低优先级的）的实现变得困难了：在一个基于提供的模型里，运行任务的资源对于上一级的调度器是不可见的；在一个基于请求的模型里，低级别的资源管理器必须理解抢占策略（很可能与应用相关）。
2. 调度器不能从负载运行中来考虑降级资源（例如，“吵闹的邻居”抢占了IO资源），因为他们看不到他。
3. 应用级调度关心下游资源的许多不同方面，但他们只有资源管理器的提供/请求接口。这个接口很容易变得很复杂。

共享状态架构 将这个问题转化成分布式模型，多个集群状态的副本会被应用级调度器独自更新，就像图1c展示的。在本地更改后，调度器发起一个乐观更新事物去更新共享的集群状态。这个事务可能会失败，很明显：一个其他的调度器可能同一时间也在做一个冲突的变动。

最知名的使用共享状态的设计就是Google的 Omega，和微软的Apollo,还有Hashicorp的Nomad容器调度器。以上豆浆共享集群状态是现在一个单点位置：Omega的“cell state”，Apollo的“resource monitor”，Nomad的“plan queue”。Apollo与其他两个不同的是它的共享状态是只读的，调度事务直接提交给集群机器。机器自己检查冲突并选择接受或拒绝变动。这让Apollo可以在共享状态暂时不可用时进行调度。

一个“逻辑”共享状态设计可以归档同时不需要实现整个的集群状态。这种方式（类似Apollo做的），每个机器维护它们自己的状态并且将更新发送给不同的agent，如调度器，机器健康监控，资源监控系统。每个机器自己的本地状态的视图现在组成了一个全局共享状态的分片。

当然，共享状态架构也有一些缺点：他们必须与状态信息一起工作（不像中心式调度器），也会遇到高层争抢时降级调度性能（尽管其他架构也会遇到）。

本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。微信扫一扫关注公众号。
交流Email: zhukunrong@yeah.net