分布式调度架构之共享状态调度

前言

上文介绍了在两层调度架构中，第二层调度只知道集群中的部分资源，无法进行全局最优调度。而要解决全局最优调度的问题需要共享状态调度。

什么是共享调度

集群中需要管理的对象主要包括两种：

• 资源的分配和使用状态；
• 任务的调度和执行状态；

单体调度和两层调度实现集群对象管理的方式和问题

• 单体调度：这两种对象都是由单体调度器管理的，因此可以比较容易地保证全局状态的一致性，但问题是可扩展性较差（支持业务类型受限），且存在单点瓶颈问题。
• 两层调度：这两种对象分别由第一层中央调度器和第二层Framework 调度器管理，由于 Framwork 调度器只能看到部分资源，因此不能保证全局状态的一致性，也不容易实现全局最优的调度。

为了解决这些问题，一种新的调度器架构被设计了出来。这种架构基本上沿袭了单体调度器的模式，通过将单体调度器分解为多个调度器，每个调度器都有全局的资源状态信息，从而实现最优的任务调度，提供了更好的可扩展性。
这就是共享状态调度器这种调度架构的多个调度器需要共享集群状态，包括资源状态和任务状态等。
共享状态调度架构的示意图，如下所示：

• State Storage 模块（资源维护模块）负责存储和维护资源及任务状态，以便 Scheduler查询资源状态和调度任务；
• Resource Pool 即为多个节点集群，接收并执行 Scheduler 调度的任务；
• Scheduler只包含任务调度操作，而不是像单体调度器那样还需要管理集群资源等。

共享状态调度与两层调度架构的区别：

• 存在多个调度器，每个调度器都可以拥有集群全局的资源状态信息，可以根据该信息进行任务调度；
• 共享状态调度是乐观并发调度，在执行了任务匹配算法后，调度器将其调度结果提交给State Storage，由其决定是否进行本次调度，从而解决竞争同一种资源而引起的冲突问题，实现全局最优调度。而，两层调度是悲观并发调度，在执行任务之前避免冲突，无法实现全局最优匹配。

乐观并发调度和悲观并发调度的区别

• 乐观并发调度，强调事后检测，在事务提交时检查是否避免了冲突：若避免，则提交；否则回滚并自动重新执行。也就是说，它是在执行任务匹配调度算法后，待计算出结果后再进行冲突检测。
• 悲观并发调度，强调事前预防，在事务执行时检查是否会存在冲突。不存在，则继续执行；否则等待或回滚。也就是说，在执行任务匹配调度算法前，通过给不同的Framework 发送不同的资源，以避免冲突。

共享状态调度设计

共享状态调度的理念最早是 Google 针对两层调度器的不足，提出的一种调度架构。这种调度结构的典型代表有 Google 的 Omega、微软的 Apollo，以及 Hashicorp 的 Nomad 容器调度器。

Omega 调度架构

Omega 集群中有一个“Cell”的概念，每个 Cell 管理着部分物理集群，一个集群有多个 Cell。实际上，你可以直接将这里的“Cell”理解为一个集群的子集群或子节点的集合。
Omega 集群的调度架构示意图，如下所示：

State Storage 模块负责存储和维护资源及任务状态，里面有一个 Cell State 文件，记录着全局共享的集群状态。实际上，State Storage 组件中的集群资源状态信息，就是主本，而 Cell State 就是以主副本的形式存在的。每个调度器都包含一个私有的 Cell State 副本，也就是拥有了一个集群资源状态信息的副本，进而达到了共享集群资源状态信息的目的。
在 Omega 系统中，没有中央资源分配器，所有资源分配决策都在调度器（Scheduler）中进行。每个调度器都可以根据私有的 Cell State 副本，来制定调度决策。调度器可以查看 Cell 的整个状态，并申请任何可用的集群资源。一旦调度器做出资源调度决策，它就会在原子提交中更新本地的 Cell State 的资源状态副本。若同时有多个调度器申请同一份资源，State Storage 模块可以根据任务的优先级，选择优先级最高的那个任务进行调度。可以看出，在 Omega 系统中的每个调度器，都具有对整个集群资源的访问权限，从而允许多个调度器自由地竞争空闲资源，并在更新集群状态时使用乐观并发控制来调解资源冲突问题。这样一来，Omega 就有效地解决了两层调度中 Framework 只拥有局部资源，无法实现全局最优的问题。

Omega 共享调度工作原理

Omega 使用事务管理状态的设计思想，将集群中资源的使用和任务的调度类似于基于数据库中的一条条事务（Transaction）一样进行管理。
在一个应用执行的过程中：

• 调度器会将一个 Job 中的所有 Task 与 Resource 进行匹配，可以说 Task 与 Resource之间是进行多对多匹配的。
• 调度器会设置多个 Checkpoint 来检测 Resource 是否都已经被占用，只有这个 Job的所有 Task 可以匹配到可用资源时，这个 Job 才可以被调度。

这里的 Job 相当于一个事务，也就是说，当所有 Task 匹配成功后，这个事务就会被成功 Commit，如果存在 Task 匹配不到可用资源，那么这个事务需要执行回滚操作，Job 调度失败。

• 无论事务是否执行成功，调度器都会在事务执行之后，重新从主本那里同步更新本地 Cell State的资源状态副本，以保证本地集群信息状态的有效性。
• 若事务未成功执行，则调度器会在必要时重新运行其调度算法并再次尝试申请资源。也就是说，调度器对 Job 的调度是具有原子性的，一个 Job的所有 Task 都是一起调度的，即使部分 Task 调度失败了，调度器再次调度时也必须再次调度整个 Job。
• 多个调度器可以并行调度，无需等待其他调度器调度结果，若存在冲突时，进行冲突处理，比如根据 Job 的优先级，优先级高则获得资源。

由此我们可以看到，Omega 涉及了 Job 并发调度。针对这一点，Omega 采用了传统数据库中的乐观锁（MVCC，Multi-Version Concurrency Control，基于多版本的并发访问控制），即每一个应用都发放了所有的可用资源，在更新集群状态时使用乐观并发控制来解决资源冲突问题，来提高 Omega 的并发度。不同的 Omega 调度器可以实现不同的策略，但有一些调度规则是所有调度器必须达成一致的，比如哪些资源是允许分配的、如何评估作业的优先级等。因此，Omega 调度器将两层调度器中的集中式资源调度模块简化成了一些持久化的共享数据（状态）和针对这些数据的验证代码。而这里的“共享数据”，实际上就是整个集群的实时资源状态信息，而验证代码就是解决调度冲突的调度规则。

单体调度、两层调度和共享调度区别

共享状态调度总结