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

前言
什么是共享状态调度？
共享状态调度设计
Omega 调度架构
Omega 共享调度工作原理
知识扩展：单体调度、两层调度和共享调度的区别是什么？
总结

前言

在两层调度架构中，第二层调度只知道集群中的部分资源，无法进行全局最优调度。是否有办法解决全局最优调度的问题呢？

解决办法是共享状态调度。

什么是共享状态调度？

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

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

在单体调度中，这两种对象都是由单体调度器管理的，因此可以比较容易地保证全局状态的一致性，但问题是可扩展性较差（支持业务类型受限），且存在单点瓶颈问题。

在两层调度中，这两种对象分别由第一层中央调度器和第二层 Framework 调度器管理，由于 Framwork 调度器只能看到部分资源，因此不能保证全局状态的一致性，也不容易实现全局最优的调度。

为了解决这些问题，一种新的调度器架构被设计了出来。这种架构基本上沿袭了单体调度器的模式，通过将单体调度器分解为多个调度器，每个调度器都有全局的资源状态信息，从而实现最优的任务调度，提供了更好的可扩展性。

这种调度架构在支持多种任务类型的同时，还能拥有全局的资源状态信息。要做到这一点，这种调度架构的多个调度器需要共享集群状态，包括资源状态和任务状态等。这种调度架构称之为共享状态调度器。

共享状态调度架构的示意图，如下所示：

共享状态调度架构为了提供高可用性和可扩展性，将集群状态之外的功能抽出来作为独立的服务。具体来说就是：

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

共享状态调度也支持多种任务类型，但与两层调度架构相比，主要有两个不同之处：

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

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

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

共享状态调度设计

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

作为 Google 公司的第二代集群管理系统，Omega 在设计时参考了 Borg 的设计，吸收了 Borg 的优点，并改进了其不足之处。

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）一样进行管理。显然，数据库是一个共享的状态，对应 Omega 中的 Cell State，而每个调度器都要根据数据库的信息（即集群的资源信息）去独立完成自己的任务调度策略。

如下图所示，在一个应用执行的过程中，调度器会将一个 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 调度器将两层调度器中的集中式资源调度模块简化成了一些持久化的共享数据（状态）和针对这些数据的验证代码。而这里的“共享数据”，实际上就是整个集群的实时资源状态信息，而验证代码就是解决调度冲突的调度规则。

知识扩展：单体调度、两层调度和共享调度的区别是什么？

单体调度，是由一个中央调度器去管理整个集群的资源信息和任务调度，所有任务只能通过中央调度器进行调度。

优点：中央调度器拥有整个集群的节点资源信息，可以实现全局最优调度。
缺点：无调度并发性，且中央服务器存在单点瓶颈问题，导致支持的调度规模和服务类型受限，同时会限制集群的调度效率。因此，单体调度适用于小规模集群。

两层调度，是将资源管理和任务调度分为两层来调度。其中，第一层调度器负责集群资源管理，并将可用资源发送给第二层调度；第二层调度接收到第一层调度发送的资源，进行任务调度。

优点：避免了单体调度的单点瓶颈问题，可以支持更大的服务规模和更多的服务类型。
缺点：第二层调度器往往只对全局资源信息有部分可观察性，因此任务匹配算法无法实现全局最优。双层调度适用于中等规模集群。

共享状态调度，多个调度器，每个调度器都可以看到集群的全局资源信息，并根据这些信息进行任务调度。相较于其他两个调度架构来说，共享状态调度架构适用的集群规模最大。

优点：每个调度器都可以获取集群中的全局资源信息，因此任务匹配算法可以实现全局最优性。
缺点：因为每个调度器都可以在全局范围内进行任务匹配，所以多个调度器同时调度时，很可能会匹配到同一个节点，从而造成资源竞争和冲突。

虽然 Omega 的论文宣称可以通过乐观锁机制，避免冲突。但在工程实践中，如果没有妥善处理资源竞争的问题，则很可能会产生资源冲突，从而导致任务调度失败。这时，用户就需要对调度失败的任务进行处理，比如重新调度、任务调度状态维护等，从而进一步增加了任务调度操作的复杂度。

总结

共享状态调度是将单体调度器分解为多个服务，由多个服务共享集群状态，包括资源状态和任务状态等。

共享状态调度的架构和工作原理，共享状态调度包含多个调度器，每个调度器都可以看到集群的全局资源信息，并根据这些信息进行任务调度。

共享状态调度是乐观并发调度，调度器将其调度的结果以原子的方式提交给资源维护模块，由其决定是否进行本次调度。

在分布式领域中，共享状态调度，是 Google 号称的下一代集群管理系统 Omega 的调度机制，可以解决双层调度无法实现全局最优的问题，同时也避免了单体调度的单点瓶颈问题。

但，说到这儿你可能会回想起曾经看到的两句话：

为了达到设计目标，Omega 的实现逻辑变得越来越复杂。在原有的 Borg 共享状态模型已经能满足绝大部分需要的情况下，Omega 的前景似乎没有那么乐观。
Omega 系统缺点是，在小集群下没有优势。

为什么说 Omega 是 Google 准备打造的下一代集群管理系统。

从调度架构方面来看，Borg 无法支持同时存在多种业务类型的场景，并且存在单点瓶颈问题。而 Omega 解决了 Borg 的这两个问题，但是当多个调度器并行调度时，可能存在资源冲突，当资源申请产生冲突时，会导致大量任务或任务多次调度失败，增加了任务调度失败的故障处理的复杂度，比如需要进行作业回滚、任务状态维护等。

因此，设计一个好的冲突避免策略是共享状态调度的关键。对于小规模集群来说，其集群规模、任务数量等都不大，使用单体调度就可以满足其任务调度的需求，避免了考虑复杂的冲突避免策略。共享状态调度比较适合大规模、同时存在多种业务类型的场景，不太适合小规模集群。

分布式调度架构：共享状态调度相关推荐

共享单车调度_共享单车调度模型及算法研究
［1］周进.互联网共享单车对出行方式选择及交通运行的影响［C］∥2017城市发展与规划论文集.海口:中国城市科学研究会,2017:412-418. ZHOU Jin. The impact of A ...
集群调度架构的变革 (二)
二级调度架构通过隔离资源获取与任务来解决这个问题.这样任务调度逻辑可以针对特定的应用,这也可以保持在集群间共享的能力.Mesos的集群管理在这方面是先驱, 同时YARN支持一部分功能.在Mesos, ...
获国际架构顶会ATC2021最佳论文！Fuxi2.0去中心化的调度架构详解
简介: 近日,在国际体系架构顶会USENIX ATC2021上,阿里云飞天伏羲团队与香港中文大学合作的一篇论文<Scaling Large Production Clusters with Pa ...
秒启万台主机，腾讯云云硬盘数据调度架构演进
导语 | CBS云硬盘为腾讯云客户提供了⾼可靠.⾼可⽤和低成本的统⼀块存储服务.CBS针对数据安全.云服务器⽣产.资源均衡.云盘介质升级等场景下的数据调度能⼒需求,抽象出统⼀数据调度平台.本文是对腾讯 ...
[译]集群调度架构的变革 (四)
原文地址:http://www.firmament.io/blog/... 混合架构是最近出现的致力于通过组合单体或共享态的设计来解决全分布架构的缺点.一般这样做是ok的 - 比如,在Tarcil( ...
Linux系统进程调度——调度架构详细分析
日期内核版本架构作者内容 2019-4-14 Linux-2.6.32 X86 Bystander Linux进程调度架构 1 调度器 1.1 概述现代的操作系统是多任务的操作系统,硬件的处 ...
XXL-Job分布式任务调度框架-- 介绍和调度中心的搭建启动1
一 xxl-job介绍 1.1 xxl-job介绍 xxl-job是轻量级的分布式任务调度框架,目标是开发迅速.简单.清理.易扩展; 老版本是依赖quartz的定时任务触发,在v2.1.0版本开始移 ...
共享单车计算机网络,基于BP神经网络的共享单车调度优化
摘要:本文通过研究共享单车的授放以及调度优化问题,使得调度以及投放单车的次数最少.经过对单车调度以及投放情况进行分析,探讨了单车分布的影响.以邹城市为倒,首先根据实际情况,对数据进行了整理,通过BP神 ...
菜鸟，下一代分布式体系架构的设计理念
二十年来,整个分布式系统架构的演进,从 C/S 到 B/S,再到分布式系统,当前广泛使用的是网格计算和云计算,包括目标.定位.场景. 菜鸟乃至阿里在全球化进程中,也面临着全球分布式架构问题,以及仓储系 ...

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

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

前言

什么是共享状态调度？

共享状态调度设计

Omega 调度架构

Omega 共享调度工作原理

知识扩展：单体调度、两层调度和共享调度的区别是什么？

总结

分布式调度架构：共享状态调度相关推荐

最新文章

热门文章