【分布式系统遨游】分布式资源调度

服务器

浏览数:14

2020-6-29

AD:资源代下载服务

今天我们来讨论分布式资源调度。

为什么需要资源调度

从计算机演化说起

我们知道,计算机的出现很大程度上是为了分担人类的工作的。所以,整个计算机体系架构的演化的过程,都离不开对任务与资源这两个因素的考虑。如何利用最少的资源,运行最多的任务,且耗时最短,这是一直以来伴随我们以及科学家的难题。对于单机系统来说,从最早的单道程序设计技术、到多道程序设计技术、到现在的多核并行架构,解决方案正在逐步进化,也就是我们最直观的感受:计算机处理任务变快了。

从操作系统进程调度到分布式资源调度

我们可以类比一下操作系统的概念。相比于分布式资源调度,操作系统其实就是一种微观上的资源调度。我们把任务与任务相关的一系列上下文(包括程序代码与数据),统统抽象为进程。进程就是任务。在单核CPU架构下,由于只有一个CPU核,所以我们只能同时对一个任务进行处理。
但是,我们的任务数量不只会有1个,而是会远远超出CPU的数量,即“僧多粥少”的局面,所以,操作系统的进程调度算法出现了,比如时间片轮转调度算法,即一段时间内,CPU快速在多个任务之间快速切换、交替执行,故对每个任务内部来说,好像自己在独占CPU一样,这就是所谓的并发。除此之外,还有高优先级、高响应比、多级反馈队列调度等等任务调度算法,都在力图在单核CPU基础上解决这个问题。但是,我们一定不会满足,为了追求更高程度的并发,即在同一时刻允许多个任务同时运行。所以,多核CPU就这样诞生了,即实现了所谓的并行。那么同理,分布式系统也同样需要这种资源与任务的调度机制,来协调资源与任务之间的关系。
分布式系统存在的意义之一,就是解决单体架构执行任务时的性能瓶颈,所以,我们找来了一堆机器,来分担原来一台机器上的计算任务。但是,资源是多了,但是我们要如何利用呢?这里面就涉及到资源如何公平公正的分给每一个计算任务,让整个集群合理的利用硬件资源,短时、高效、公平的完成一系列的计算任务,而不至于某个任务被饿死或者撑死。所以,需要一个宏观上的“操作系统”,来合理的将无穷多个计算任务,分配到m个集群节点的计算资源上去执行。这,就是为什么需要分布式资源调度机制。

单体调度

对于操作系统进程调度来说,资源只有一份,那就是当前操作系统所在的计算机硬件资源;而任务有很多,资源:任务 = 1:N的关系,操作系统在进行任务调度之前,只需要收集它所在的计算机的硬件资源即可。而对于一个分布式系统中的集群,计算资源分布在多个节点上,任务还是有很多,他们之间是M:N的关系。所以,分布式系统的工作稍微复杂些,它需要收集所有节点上的资源信息而非仅仅一个节点,然后对所有收集来的资源信息做一个统筹规划。

什么是单体调度

如果让我们自己设计一个调度系统,我们自然会想到之前讲过的“分布式经典架构”中的集中式架构,由一个节点全权负责资源分配与任务调度。这,其实就是单体调度。单体调度模块称为“Scheduler”或“单体调度器”。所有的资源请求和任务调度都通过这个中心节点来进行。集中式调度器的常见模型,如下图所示。:

我们看到,master节点会收集每个节点的节点状态并交给master中的cluster state模块。这个节点状态就是指集群的计算资源的分布情况,而这个cluster state模块一般是一种内存数据库。然后,橙色方框Scheduling logic会到cluster state中查询集群资源的分布情况,然后根据分布情况执行自己的调度逻辑,进而将任务分配到各个节点上去执行。
我们可以看到,单体调度器拥有全局资源视图和全局任务,可以很容易地实现对任务的约束并实施全局性的调度策略。目前很多集群管理系统采用了单体调度设计,比如Google Borg、Kubernetes等。Kubernetes的架构经过我们之前的学习,相信你已经很熟悉了,下面我们来介绍Borg的调度架构,由于Kubernetes吸收了许多Borg的先进理念,说不定你会在Kubernetes的架构中看到许多Borg的影子。下面我们来以Borg为例,介绍一下它的单体调度实现。

单体调度的典型实现 — Borg

Borg是谷歌内部的大规模集群管理系统。有了之前的理论基础,我们直接上Borg的架构图:

我们看到,Borg主要由BorgMaster与Borglet构成。BorgMaster是整个集群的大脑,Borglet代表集群中的节点在这里,我们主要关注BorgMaster中的调度器Scheduler组件,它负责任务的调度,当用户提交一个作业给 BorgMaster 后,BorgMaster 会把该作业保存起来,并将这个作业的所有任务加入等待队列中。调度器异步地扫描等待队列,将任务分配到满足作业约束、且有足够资源的计算节点上。那么,Borg调度器是如何快速找到满足任务资源需求的那个机器呢?这个算法主要分为两个阶段:

  • 可行性检查,把不满足资源需求的机器过滤(Borglet)
  • 评分,从可行的机器中选择一个合适的机器(Borglet)

可行性检查

首先看可行性检查阶段,这个很好理解。假如当前任务需要8G内存的资源,而某个机器的内存总数低于8G,那么这台机器则会被无情的过滤掉。

评分

接下来就会进入到评分阶段,既然现在的所有机器已经符合要求了,是不是我们随便找一台机器把任务分了就完事了呢?其实不是。我们可以想想,大概有如下两种方案:

  • 将任务尽可能平均的分配到各台机器上。
  • 优先把任务都塞到某一台机器上,直到这一台塞不下了,再塞第二台机器,以此类推;

第一种方案被称为“最差匹配算法“,第二种方案被称为”最佳匹配算法“。我们分析一下这两种方案的优缺点:

最差匹配算法
  • 优点:由于各台机器上负载较均衡,所以不会造成机器长时间高负载运行,比较适合小型任务较多的场景
  • 缺点:它会导致每个机器都有少量的无法使用的剩余资源,会存在较多碎片
最佳匹配算法
  • 优点:由于任务会优先塞满第一台机器,那么其余大部分机器都是没有任务的,所以对需要资源多的大型任务的执行非常友好,适合大型任务较多的场景
  • 缺点:不利于有突发负载的应用,而且对申请少量 CPU 的批处理作业也不友好,因为这些作业申请少量 CPU 本来就是为了更快速地被调度执行,并可以使用碎片资源。还有一个问题,这种策略有点类似“把所有鸡蛋放到一个篮子里面”,当这台服务器故障后,运行在这台服务器上的作业都会故障,对业务造成较大的影响

单体调度的优缺点

优点

  • 单体调度器有所有节点的资源信息,而且任务也由单体调度器来分发,所以它拥有全局的视野,对整体资源的把控较为准确
  • 单体调度系统的状态同步比较容易且稳定,这是因为资源使用和任务执行的状态被统一管理,降低了状态同步和并发控制的难度。

缺点

  • 单体调度器承担任务过重,很容易达到单点瓶颈
  • 调度算法只能全部内置在核心调度器当中,因此调度框架的灵活性和策略的可扩展性不高。
  • 单体调度存在单点故障的可能性。

两层调度

在单体调度架构中,中央服务器的性能会限制调度的效率,这个很好理解,但为什么会限制支持的任务类型呢?
简单地说,这是因为不同的服务具有不同的特征,对调度框架和计算的要求都不一样。比如说,你的业务最开始时只有批处理任务,后来发展到同时还包括流式计算任务。这两种计算任务的资源与调度需求各不相同,所以我们的调度器需要适配每一种任务,为每一个类型的任务设计不同的资源分配与调度策略,所以单体调度框架会随着任务类型增加而变得越来越复杂,最终出现扩展瓶颈。
为了解决以上单体调度的问题,一种方法就是另起一层,分担中央服务器的任务,将任务调度与适配放到我们刚才说的具体的二层调度器中,一层调度器不再去适配每一种任务的资源与调度需求。也就是说,一层调度器只负责资源管理和分配,二层调度器负责任务与资源的匹配。这就是我们所的两层调度架构。
总结一下,在两层调度中,中央调度器从整体上收集节点资源信息,并进行资源的管理与分配,将资源分配到第二层调度器;再由第二层调度器负责将资源与具体的任务配对。所以,第二层调度可以有多个调度器,以支持不同的任务类型:

看到这里大家可能还是不明白一层调度器这个资源分配,到底是分配了什么。我们用一个例子来详细讲解一下:

两层调度的典型实现 — Mesos

Mesos也是一个大型分布式集群资源管理框架。既然是资源管理,所以Mesos只负责集群底层资源的管理和分配,并不涉及任务调度与管理等功能。所以,Mesos如果要实现类似Borg那样的资源与任务管理,还需要上层框架的配合。
Mesos本身实现的调度器为第一层调度,负责资源管理,然后将第二层任务调度,交给框架完成。所以,Mesos是一个典型的两层调度架构:

这里我们所说的二层调度的框架,是运行在Mesos上,是负责任务管理与调度的组件,比如 Hadoop、Spark等,每个框架有他们自己的任务调度器,用于调度并完成不同的任务,比如批处理任务、实时分析任务等。框架主要由调度器(Scheduler)和执行器(Executor)组成,调度器可以从 Master 节点获取集群节点的信息 ,执行器在Slave节点上执行任务。
在Mesos中,分配资源的过程叫做Resource Offer机制。Mesos Master主动将节点空闲资源,以类似发放Offer的方式发给每个框架,如果框架需要则使用,不需要则还回。也就是说,通过 Resource Offer 机制,第一层调度器将资源主动分配给第二层调度器,然后第二层调度进行具体的任务匹配,从而实现了任务调度与资源管理的分离。
总结一下,Mesos Master通过资源分配算法决定给各个Framework提供多少资源,而Framework则决定接受哪些资源,以及哪些任务使用这些资源运行。这样一来,一个两层调度架构就实现了。
但是两层调度的一个问题是,由于第二层调度只能获得部分资源视图,并没有单体调度掌控全局的能力。因此无法实现全局最优调度。为了解决这个问题,共享状态调度机制出现了。

共享状态调度

为了解决单体调度的扩展瓶颈问题,以及两层调度只能获得部分资源视图的问题,我们想,那么让两层调度器也能够看到所有节点的状态不就可以了,即我们要一个地方来存储所有节点的状态就OK了。这,就是共享状态调度。
共享状态调度结合了单体调度掌控全局的特点,以及两层调度职责分离的优势。通过将单体调度器分解为多个调度器,且每个调度器都有全局的资源状态信息,从而实现最优的任务调度,提供了更好的可扩展性。其架构如下:

共享状态调度的典型实现 — Omega

Omega是Google的第二代集群管理系统,Omega 在设计时参考了 Borg 的设计,吸收了Borg 的优点,并改进了其不足之处。
Omega中以Cell为单位来管理集群,它是一个集群中的节点集合。比如集群中有10个节点,那么我们可以把其中的2个节点称为一个Cell。在Omega中,由于需要共享每一个Cell的资源状态,那么需要一个共享存储空间,来共享每个Cell的状态。其架构图如下:

我们看到,为了提高性能、并且能更方便的查到共享的集群状态数据,每个Cell都会从中心的State Storage同步一份数据到每个Cell内部。这样一来,Omega 就有效地解决了两层调度中 Framework 只拥有局部资源,无法实现全局最优的问题。

总结

那么这几种资源调度方案字哪种场景下使用更好呢?

  • 在小规模的集群应用场景,我们应该尽量采取单体调度模型。这是因为这种模型设计和使用都比较简单,调度器容易对整个系统的状态有全面的把握。
  • 在规模较大的集群中,可以考虑使用双层调度器设计。 双层调度器调度策略的编写较为复杂,而且框架调度器并没有全局的资源视野,调度准确率较低。随着新一代共享状态调度器的发展,未来可能会慢慢退出舞台。
  • 共享状态调度器因为集合了单体调度与两层调度的优点,以及适应多种任务调度需求、灵活性高、可扩展性强的特点,正渐渐变成主流。

最后我们把讲过的三种调度方式做一个比较:

下期预告

【分布式系统遨游】分布式计算

关注我们

欢迎对本系列文章感兴趣的读者订阅我们的公众号,关注博主下次不迷路~

作者:NoSay