ｍｅｓｏｓ论文阅读

2019独角兽企业重金招聘Python工程师标准>>>

                                作者：zy 转载请注明出处

由于近期在做一些图片离线计算的工作，需要对几亿的图片数据进行处理（特征值处理和计算），需要考虑图片数据的全量和增量计算，受ｙａｒｎ的框架的思想的启发，想要寻找一个ｃ＋＋的集群管理和调度框架，然后就找到了ｍｅｓｏｓ，决定深入地学习一下，并考虑在ｍｅｓｏｓ上做一些离线图片数据处理的尝试。

花了点时间阅读了一下ｍｅｓｏｓ的论文，把论文中最核心的第三章和第四章翻译了一下，翻译地比较简陋。

／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／

ｍｅｓｏｓ架构

设计哲学

Mesos的目标是提供一个弹性的可以扩展的架构，供各种类型的计算框架(framework)能够共享集群。集群的计算框架都是高度多样化和快速演进的。Mesos的设计哲学就是定义一个最小的接口，在集群之间能够实现有效的资源共享，将任务调度和执行的控制权下放到计算框架中。

将资源调度和集群下放有两点好处： 首先允许框架在集群上针对不同的问题实现多种解决方案（如达到数据局部性，容错等等），可以独立的演进这些解决方法。其次使得mesos相对简单和最小化系统需要修改速度。可以容易地实现mesos的扩展性(scalable)和稳定性(robust)。

  

从上面两个图可见，mesos包括两个重要组成部分，首先是一个master进程，它管理运行在各个集群节点上的slave后台进程。计算框架可以在slave上运行计算任务(task)。mesos使用resource offers的方式实现计算框架之间的细粒度的共享。Resource offer是多个slave节点上的一组空闲资源。Master根据调度策略来决定提供多少资源给每一个framework，比如fair sharing和priority。为了支持多种内部框架的分配策略，mesos通过一个可插拔的分配模块来允许用户定义自己的策略。

运行在mesos上的每一个框架都必须包含两个部分：

1、 调度器，向master注册用来offered resourece。

2、 执行器，用来加载运作在slave nodes上的框架的任务。

当master决定将那些资源提供给每个框架，框架的schedulers可以对这些资源进行选择。当框架接收这些资源，它会向mesos返回一个运行在这些资源上的task的描述。

为了维持一个thin interface，使得框架独立地进行演进，mesos不要求框架指定对资源的要求和约束。相反，mesos给予框架拒绝offer的能力，一个框架能拒绝不能满足其约束的资源，等待满足其需求的资源。因而，这个拒绝机制使得框架能支持任意复杂的资源约束，并保持mesos简单和可扩展。 图3显示了一个框架调度任务运行的例子，step1，slave1向master上报 4 CPU和4GB内存的空闲资源，然后master调用分配模块，告诉框架1所有可用的空闲资源。Step2，master发送一个描述当前空闲资源的resource offer给框架1。Step3，框架1的调度器回复master，运行两个task在slave上，第一个任务试用了资源{2CPU, 1GBRAM}，第二个任务使用了{1CPU, 2GBRAM}。Step4，master把任务描述发送给slave，slave分配适当的资源给框架的执行器，然后有框架的执行器加载这两个任务。一个潜在的挑战是单独使用拒绝机制满足所有的框架约束是否高效：一个框架可能必须等待很长一段时间，才能收到满足其约束的资源。Mesos可能需要将一个resource offer发送给多个framework，才能找到接收这个resource offer的框架。 为了避免这种状况，mesos也允许框架设置过滤器，过滤器可以指定一个框架通常会拒绝的特定资源。举个例子，一个框架可以指定其能够运行其上的节点的白名单。

有两点值得提示：首先过滤器只是代表resource offer模型的性能优化，框架仍然拥有拒绝任何资源以及选择任务执行的节点的最终决定权。其次，当workload包括细粒度的任务（比如mapreduce的workload）时，resource offer模型在缺少过滤器的情况下，性能出奇的好。特别的，我们发现一种叫delay scheduling的简单机制，使用这种机制的框架等待一定的时间，可以获得存储他们所需数据的节点，基本在等待1-5S内可以达到最佳的数据局部性。

资源分配

Mesos将资源分配的决定权交给了插件化的分配模块，那么用户可以根据其需求定制分配策略，mesos实现了两个分配模块，一个是基于max-min fairness，对不同的资源执行fair sharing，另一个是实现了严格的优先级。

在普通的操作中，mesos在大部分任务都是短时间，只有在任务结束后重新分配资源的场景下有优势。通常这种情况会频繁的发生，这样一个新框架才能快速地获取它所需要的资源。 举个列子：如果一个框架的共享资源是集群的10%，那么这个框架需要等待平均任务长度的10%的时间来接收它需要的资源。然而，假如一个集群中充满了长任务，比如一个古怪的作业和贪婪的框架，分配模块可以取消任务，但取消任务之前，mesos会给予框架一个宽限期去释放资源。

我们选择取消任务的策略的权利留给了分配模块，但描述了两种相关的机制。

首先对于大部分框架，取消一个任务没有多大影响，但对于那些任务相互依赖的框架，取消掉一个任务会带来很大的影响，我们允许这些框架通过分配模块来公开每一个框架的（guaranteed allocations）最低保障分配来避免取消任务，（guaranteed allocations）最低保障分配是只一个框架在不失去task的情况下所需要持有的资源量；框架通过一个api调用来读入其（guaranteed allocations）保障分配，分配模块负责满足框架的（guaranteed allocations）保障分配；当前，mesos是指简单地提供了（guaranteed allocations）保障分配的语义：加入一个框架拥有的资源低于其（guaranteed allocations）保障分配，那么任何一个task都不应该被取消，如果高于（guaranteed allocations）保障分配，那么任何的任务都可以被取消。 其次，决定何时触发取消操作，mesos必须知道在已经连接的框架中，那些框架使用的资源超出分配给它的资源限定。框架可以通过一个api调用表示它对资源的兴趣。

资源隔离

Mesos通过利用现有的操作系统隔离机制来提供多个框架执行器(framework executors)在同一个slave上运行的性能隔离(performancd isolation)。既然这些机制是平台依赖的，那么mesos通过一个可插拔的隔离模块来提供做种隔离机制。

目前资源隔离使用了操作系统沙箱的技术，如linux container和solaris projects。这些技术可以限制cpu、内存、network bandwidth和IO，这些技术虽然不完美，但使用沙箱技术相遇于其他框架如hadoop之类只是将不同job的任务简单地运行在不同的进程上是一个优势。

resource offers的扩展和稳定性

因为任务调度在mesos中是一个分布式进程，它需要高效和对于失败的容错。Mesos包括三个机制来到达这个目的。

首先，因为有些框架总是拒绝某一类资源，mesos让他们可以最短路径处理拒绝，通过filter机制避免与master之间的通信。当前支持两种类型的过滤器：”only offer nodes from list L”和”only offer nodes with at least R resource free”。

其次，因为一个框架需要时间来响应一个resource offer，mesos会对分配给框架的resource offer进行计时。框架有强烈的冲动快速地响应resource offer以及过滤其不适用的资源。

最后，假如一个框架没有在一个有效的时间内对一个resource offer进行响应，mesos会取消这个offer，然后重新这部分资源分配给其他框架。

容错

既然所有的框架都依赖mesos master，所有master的容错至关重要，为了达到这一点，我们通过将master设计成软状态，因此一个新的master可以通过slave和framework schedulers持有的信息完整地重建其内部状态。特别的，master的唯一状态就是active slave和active frame的列表和运行的tasks。这些信息足够计算每一个框架正在使用和运行多少资源。我们通过zookeeper的leader election来实现对master的热备。当active master失败时，slaves和schedulers会连接下一个被选举出了的master，重新填充其状态。

出了处理master的失败，mesos也会向框架的scheduler上报节点失败和executor crash。Framework可以根据他们选择的策略相应这些错误。

最后，处理scheduler的失败，mesos允许一个框架注册多个schedulers，当一个失败时，mesos master会提示另一个接管，但framework必须使用他们自己的机制在scheduler之间共享状态。

API

左边的callback 列显示的函数是框架需要要实现的函数，右边的action列是框架可以调用的操作。

Mesos 行为

总之，我们发现在如下情形时，mesos表现地比较好：框架能够弹性地扩展、任务的持续时间是均匀（homogeneous），框架同等地对待所有的节点。当不同的框架喜欢不同的节点，mesos会模拟一个中心调度器，在所有的框架上执行资源共享的公平调度策略。此外mesos能够在不影响框架的短任务的性能下处理异构任务持续时间（heterogeneous task durations）。 我们也讨论了框架如何在mesos能够改进他们的性能和集群资源利用率，以及mesos的分布式调度模型的限制。

定义、度量和假设

在我们的讨论中，我们考虑了三个度量（metrics）：

1、 framework ramp-up time: 一个新框架得到它所需要的资源所花费的时间（对于公平调度策略，一般来说就是等待上一个任务完成的时间）。

2、 job completion time: 作业完成时间，假设每个框架只有一个作业。

3、 system utilization：总的集群利用率

我们用两个维度来描述工作负载（workloads）：弹性和任务持续时间分布。

一个弹性框架（elastic framework）如hadoop和dryad能对集群资源进行伸缩，比如它一旦获取到集群节点就立即使用以及任务执行完后立刻释放节点。相反对于刚性框架（rigid framework），如MPI，只有在获取到一个固定数量的资源后，才能运行其作业，而且不能进行动态地伸缩（在有新资源时进行扩展提升性能，在性能受到很大影响时进行缩减）。对于任务的持续时间，考虑同构和异构这两种分布。

我们同样回去两种类型的资源进行区分：

1、 强制的资源

2、 偏好的资源

强制地资源是指一个框架必须得到这种资源才能运行，比如一个框架再没有获取到GPU就不能运行，那么GPU资源就是强制资源。相反，偏好的资源是指一个框架在得到这种资源后能运行地更好，框架也可以运行在其他资源上，比如一个框架系统偏好运行在存储数据的节点之上，但也可以运行在远离资源的节点上。

我们假设框架要求的强制资源的数量不会超过强制资源的共享上限，这点确保了框架不会在等待空闲的强制资源时发生死锁。

为了简单起见，我们假设所有任务对资源的要求都是相同的，运行在叫做slot的机器同等切片上，每个框架都运行一个作业。

Homogeneous Tasks

我们考虑一个拥有n slot的集群，以及一个框架f，拥有对k个slot的使用权。我们考虑两种任务持续时间的分布：常数时间和指数时间。假设平均的任务持续时间是T，假设框架f运行一个作业需要βkT总的计算时间，即一个框架拥有k个slot，那么它需要βT时间去运行完成一个作业。

下面这个表总结了两种不同类型的框架和两种不同任务持续时间分布的作业完成时间和系统资源利用率。果然任务持续时间为常数的弹性计算框架拥有最好性能，而任务持续时间为指数的刚性框架性能最差。由于论文中缺乏空间，在这里我们只列举出结果和推过过程。

Framework ramp-up time:假如任务持续时间是常数T，那么框架f最多需要花费T时间来获取到其所需的k slots（最长要等待T时间，才能等待上一个任务完成， slot才能变为可用）。假如任务持续时间是指数，那么ramp-up time的时间最多是Tln k。

Job completion time: 一个弹性作业的期望完成时间最多是 （1 + β）T，T是任务执行的平均时间，一个作业所花费的时间为执行任务的时间加上作业获取所有slot的时间。对于持续时间为常数的任务，一个刚性作业可以达到类似的完成时间。但对于持续时间为指数的任务，刚性作业需要花更高的时间才能完成，比如( lnk +β) T，这是因为框架平均需要花费Tlnk的时间去获取到作业所依赖的slot。（个人理解，对于刚性框架因为需要等待所有资源都就绪后才能执行任务，所以对于持续时间为指数的任务，会花费更多时间去等待资源，而弹性框架没有这方面的限制）。

System utilization：弹性作业可以充分地利用分配给它们的slot，因为它们一旦得到slot，能能立即使用。结果，假设有无限的需求，一个系统只运行弹性作业可以得到充分地使用。刚性的框架能取得稍差一点的利用率，因为他们的作业在获取到所有资源前不能启动，因而会浪费已经持有的资源的利用率。

位置偏好

到目前位置，我们都假设框架没有对slot的偏好，。实际上，不同的框架会偏好不同的节点，他们的偏好可能会随着时间的变化而改变。我们这里考虑在那些情况下框架对slot有着不同的偏好。 这个问题可以归结为将mesos比作一个中央调度器，在知道了关于框架的偏好信息后，如何能更好地工作。

我们考虑两种情况：

(a) 存在一个系统配置，通过这个配置，每一个框架会获得满足其它需求和偏好的slot。

(b) 没有类似的配置对偏好slot的需求超过其供应。

对于第一种情况，不考虑初始配置，系统会收敛到这样一个状态中：每一个框架最多花费T的时间间隔来获取偏好的slot。这是因为在T的时间间隔里，所有slot都会变得可用，结果就是每一个框架都会分配到其所偏好的slot。 在第二种状况里，没有可以让所有框架都满足其偏好的系统配置。在这种情况下，关键的问题是如何在所有要求资源的框架中分配框架偏好的slot。特别是，假设有p 个slot被m个框架所偏好，其中框架i要求个这样的slot， 。许多分配策略适合处理这种情况，这里我们考虑一种加权的公平分配策略，其中权重与框架i的总的预期分配相关。换句话说，假设每一个框架有足够的请求，我们的目标是分配个框架偏好的slot给框架i。

Mesos的挑战是调度器不知道各个框架的偏好，幸运的是，有一种简单的方法达到这种偏好slot的加权分配策略：“simple perform lottery scheduling”，提供slot给框架的概率与框架资源要求成正比。Mesos能提供slot给框架i的概率是，n是系统的框架总数目。 此外，因为每个框架i在每个T时间单位内平均接收到 个slot，ramp-up time和job completion time的值继续维持不变。

Heterogeneous Tasks

到目前位置，我们都假设框架运行同构的持续时间的任务，比如所有框架都运行相同持续时间分布的任务。在这一章，我们讨论框架运行异构的持续时间的任务。特别是那些既运行着长任务又运行着短任务的工作负载（workload），而且长任务的平均持续时间要比明显长于短任务的平均持续时间。这种异构的工作负载会明显损害框架的短任务的性能。在最坏情况下，一个短作业所要求的节点都可能运行着长任务，那么这个作业可能需要等待很长一段时间来获取资源。

假设一个集群中，每个节点有S个slot，每个slot运行长任务的概率为，那么节点的所有slot被长任务占据的概率为。所以当没有接近1且一个节点上运行多个slot的话，那么随机的任务分配会运行地比较好，比如S=8, =0.5，那么一个节点被长任务占据满的概率为0.4%。因而运行短任务的框架仍然能在短时间获取其偏好的节点。

为了进一步减少长任务的影响，mesos能够做一些轻量级的扩展，允许分配策略在每个节点上位运行短任务而预留一些资源。特别是，我们能在每个节点上将任务的最大持续时间与某些资源进行关联，运行在这些资源上的任务的持续时间一旦超过这个最大值，那么将会被杀掉。这些时间限制会在resource offers中会提供给框架，允许框架选择是否使用这些资源。 这个场景与在HPC集群中为短作业提供一个独立队列的通用分配策略非常类似。

框架激励

Mesos实现了一个去中心化的调度模型，每个框架可以觉得是否接受resource offer。对于一个去中心化的系统，理解系统中每个实体的激励机制是非常重要的。在这一章，我们讨论提升作业响应时间的框架激励机制。

短任务：一个框架被鼓励使用短任务的原因有两个：首先，任何资源能够为短任务预留。其次，使用短任务在框架发生丢任务执行失败、取消任务时减少了框架所做的无用功。

可扩展的弹性机制：框架在获得资源时能立即使用资源而不是等待达到一个最小的资源分配值的能力允许框架能较早启动作业。特别是框架的弹性扩展能力允许一个框架有机会使用闲置的资源，并在使用后释放这些资源只有带来极少的负面影响。

拒绝未知的资源：框架被鼓励不接受他们不能使用的资源，因为大部分分配策略在进行资源分配时，都会对框架拥有的资源进行计数。

我们注意到这些激励措施与我们提升系统利用率的目标是保持一致的。假如框架使用短任务，mesos能够快速地重新分配这些资源，减少为新作业分配资源的延时和取消作业时的无用功。 假如框架是弹性的，那么它们有机会使用所有它们获取到的资源。最后，假如框架不接受它们使用不了的资源，那么就可以把这些资源留给能使用它们的框架。 我们也注意到这些特性与现行的很多集群计算框架相吻合，比如mapreduce和dryad，仅仅是使用了独立的短任务而简化了负载均衡和容错处理。

分布式调度的限制

虽然我们展示了分布式调度在当前集群的环境中的很多场景下都工作良好，但像许多去中心化的调度策略，它们表现地要比中心化调度器要差很多。我们确定了分布式调度模型的三个局限性。

碎片：任务对异构资源进行请求时，一个分布式框架的集合不能像中心调度器一样对装箱问题进行优化（个人理解就是各个任务请求的内存、cpu都是不相等的，所以资源调度就等同于一个装箱问题）。然而，装箱问题的次优方案的浪费空间被最大任务规模与节点规模的比率所约束（个人理解是装箱问题的浪费空间与物体的最大大小和箱子的大小的比率相关），因此那些运行更大的节点（节点更大是指一个节点拥有的slot数目越多）和更小的任务（任务更小是指持续时间和申请的资源）的集群即使采用分布式调度也会取得更高的利用率。（个人理解箱子越大，物体越小，那么利用率越高） 还有另外一种坏结果的可能，假如分配模块以本地模式进行资源的重新分配，当一个集群被请求小量资源的任务占满时，那么一个请求大量资源的框架f可能会饥饿，因为当一个小任务完成时，框架f不能接收被释放的资源（需要的是大量资源），但其他框架可以。为了适应请求大资源任务的框架，分配模块能支持设定每个slave节点最小资源供给大小，并且避免在slave上进行offer resource，直到slave上的空闲资源达到最小资源供给大小。

相互依赖的框架约束：因为框架之间复杂的相互依赖，只有集群全局调度器才能更好地执行。我们认为这些场景在现实中非常少见。在本章讨论的模型中，框架只是对他们所使用的节点有所偏好，我们展示了这些优化的调度器的近似分配。

框架复杂性：mesos使用resource offers可能使得框架调度变得更加复杂。然而，我们认为这个难度并不繁重。首先是否使用mesos或中心调度器，框架都需要知道他们的喜好；在一个中心调度器中，框架需要调度器来做这些工作。而在mesos中，需要框架的调度器来决定是否接受resource offer。其次，对于现存的框架的许多调度策略是在线算法，因为框架不能预测任务执行时间，以及必须处理错误。这些策略可以非常容易地在resource offers机制上实现。

转载于:https://my.oschina.net/zhengyang841117/blog/167297