mesos概述

mesos解决的问题

不同的分布式运算框架(spark,hadoop,ES,MPI,Cassandra,etc.)中的不同任务往往需要的资源（内存，CPU，网络IO等）不同，它们运行在同一个集群中，会相互干扰，为此，应该提供一种资源隔离机制避免任务之间由资源争用导致效率下降,考虑到资源利用率，运维成本，数据共享等因素，公司一般希望将所有这些框架部署到一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，这样，便诞生了资源统一管理与调度平台,典型的代表就是mesos和yarn。

Mesos的目标就是在不同的framework之间高效的共享硬件资源，同时简化自身的调度逻辑，使其具有尽可能大的兼容性和可扩展性，以保证在大规模集群使用环境下的健壮性和对各种可能的运算框架的普遍适用性。

mesos基本术语解释

• Mesos-master：协调全部的slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework发出资源邀约。

• Mesos-slave：向master汇报自己的空闲资源和任务的状态，负责管理本节点上的各个mesos-task，在framework成功向Master申请资源后,收到消息的slave会启动相应framework的exexutor

• Framework：Hadoop，Spark等，通过MesosSchedulerDiver接入Mesos

• Executor：执行器，用于启动计算框架中的task

mesos与yarn区别

• Mesos只负责offer资源给framework，而Yarn自己来分配资源。

• Yarn局限在Hadoop上，没法作为别的机器管理。

• Mesos管理CPU，Memory，Disk；而Yarn只管理Memory和CPU。

• Mesos用lxc隔离，Yarn用进程来进行隔离（性能可能更好）。

• 部署Mesos以后，再跑Spark或Hadoop MapReduce的时候，就不需要部署Spark和Hadoop了，直接在Mesos上运行Spark或Hadoop任务(在文件系统中指定运行所需要的框架二进制包位置)。

• 两种系统都采用了双层调度机制，即，第一层是源管理系统（mesos/YARN）将资源分配给应用程序（或框架），第二层，应用程序将收到的资源进一步分配给内部的任务。但是资源分配器智能化程度不同，mesos是基于resource offer的调度机制，包含非常少的调度语义，他只是简单的将资源推给各个应用程序，由应用程序选择是否接受资源，而mesos本身并不知道各个应用程序资源需求；YARN则不同，应用程序的ApplicationMaster会把各个任务的资源要求汇报给YARN，YARN则根据需要为应用程序分配资源。

• 从功能上讲YARN和Mesos相似，只是Mesos更通用，可以支持在线和离线任务。一般YARN用于调度离线任务。

mesos架构

总体上看，Mesos是一个master/slave结构，其中，master是非常轻量级的，仅保存了framework和mesos slave的一些状态，而这些状态很容易通过framework和slave重新注册而重构，因而很容易使用了zookeeper解决mesos master的单点故障问题。

Mesos master实际上是一个全局资源调度器，采用某种策略将某个slave上的空闲资源分配给某一个framework，各种framework通过自己的调度器向Mesos master注册，以接入到Mesos中。而Mesos slave主要功能是汇报任务的状态和启动各个framework的executor

细粒度分配

Mesos最大的好处是能够对分布式集群做细粒度资源分配。如下图所示，左边是粗粒度的资源分配，右边是细粒度的资源分配。

细粒度的资源分配是指直接按照任务实际需求分配资源，这种分配机制可大大提高资源利用率。

左边有三个集群，每个集群三台服务器，分别装三种分布式计算平台，比如上面装三台Hadoop，中间三台是Spark，下面三台是Storm，三个不同的框架分别进行管理。右边是Mesos集群统一管理9台服务器，所有来自Spark、Hadoop或Storm的任务都在9台服务器上混合运行。Mesos提高了资源冗余率。粗粒度资源管理肯定带来一定的浪费，细粒度的管理提高了资源管理能力。

Mesos的分配逻辑很简单，只要不停地报告哪些是可用资源就可以了。Mesos资源分配方法也有一个潜在的缺点，就是无中心化的分配方式，所以有可能不会带来全局最优的方式。但这个数据资源缺点对目前来讲并不是很严重。

mesos流程

如上图所示,Mesos由始至终只做一件事情，就是分布式集群资源的分配。任务的调度和执行由每个计算框架(Framework)自己完成,这样可以容易的实现mesos的扩展性和稳定性。

1. Slave1向Master汇报其有<4CPU,4GB RAM>的空闲资源，然后Master调用分配模块，告诉Framework1所有可用的空闲资源。
2. Master发送一个描述Slave1当前空闲资源的resource offer给框架1。
3. Framework1的调度器回复Master，需要运行两个task在Slave1上，第一个task需要资源<2CPU, 1GBRAM>，第二个task需要资源<1CPU, 2GB RAM>。
4. Master把任务需求资源发送给Slave1，Slave1分配适当的资源给Framework1的executor，然后executor开始执行这两个任务,因为Slave1还剩<1CPU,1G RAM>的资源还未分配，分配模块可以将这些资源提供给Framwork2来使用。

每当有task结束，容器会被”销毁”,释放新的资源，都会执行资源邀约(resource offer)进程。

mesos资源分配

Mesos早在2009年就用上了Linux的容器技术，如cgroups和Solaris Zone，时至今日这些仍然是默认的。 然而，Mesos社区增加了Docker作为运行任务的隔离机制。不管哪种隔离机制，处理流程都是相同的。

前面提到资源邀约的概念，即由Master向注册其上的Framework发送资源邀约。 每次资源邀约包含一份Slave节点上可用的CPU、RAM等资源的列表。 Master提供这些资源给它的Framework，是基于分配策略的。分配策略对所有的Framework普遍适用，同时适用于特定的Framework。 如果它不满足要求,Framework可以拒绝资源邀约，如果这样，资源邀约随即可以发给其他Framework。 由Mesos管理的应用程序通常运行短周期的任务，因此这样可以快速释放资源，缓解Framework的资源饥饿； Slave定期向Master报告其可用资源，以便Master能够不断产生新的资源邀约。 另外，还可以使用诸如此类的技术， 每个Framework过滤不满足要求的资源邀约、Master主动废除给定周期内一直没有被接受的邀约。

DRF算法

mesos默认资源分配策略是DRF（主导资源公平算法 Dominant Resource Fairness），DRF的目标是确保每一个Framework，在异质环境中能够接收到其最需资源的公平份额。

为了掌握DRF，我们需要了解主导资源（dominant resource）和主导份额（dominant share）的概念。Framework的主导资源是其最需的资源类型（CPU、内存等），在资源邀约中以可用资源百分比的形式展示。例如，对于计算密集型的任务，它的Framework的主导资源是CPU，而依赖于在内存中计算的任务，它的Framework的主导资源是内存。因为资源是分配给Framework的，所以DRF会跟踪每个Framework拥有的资源类型的份额百分比；Framework拥有的全部资源类型份额中占最高百分比的就是Framework的主导份额。DRF算法会使用所有已注册的Framework来计算主导份额，以确保每个Framework能接收到其主导资源的公平份额。

举例说明:

假设我们有一个资源邀约，包含<9CPU,18GB RAM>。Framework1 运行任务需<1CPU,4GB RAM>，Framework2 运行任务需要<3CPU,1GB RAM>

Framework1 的每个任务会消耗CPU总数的1/9、内存总数的2/9，因此Framework1 的主导资源是内存。同样，Framework2 的每个任务会CPU总数的1/3、内存总数的1/18，因此Framework2 的主导资源是CPU。DRF会尝试为每个Framework提供等量的主导资源，作为他们的主导份额。在这个例子中，DRF将协同Framework做如下分配：Framework1 有三个任务，总分配为<3CPU,12GB RAM>，Framework2 有两个任务，总分配为<6CPU,2GB RAM>。

此时，每个Framework的主导资源（Framework1 的内存和Framework2 的CPU）最终得到相同的主导份额（2/3），这样提供给两个Framework后，将没有足够的可用资源运行其他任务。需要注意的是，如果Framework1 中仅有两个任务需要被运行，那么Framework2 以及其他已注册的Framework将收到的所有剩余的资源。

DRF分配模块跟踪分配给每个Framework的资源和每个框架的主导份额。每次，DRF以所有Framework中运行的任务中最低的主导份额作为资源邀约发送给Framework。如果有足够的可用资源来运行它的任务，Framework将接受这个邀约。通过前面引述的DRF论文中的示例，我们来贯穿DRF算法的每个步骤。为了简单起见，示例将不考虑短任务完成后，资源被释放回资源池中这一因素，我们假设每个Framework会有无限数量的任务要运行，并认为每个资源邀约都会被接受。

回顾上述示例，假设有一个资源邀约包含9核CPU和18GB内存。Framework 1运行的任务需要（1核CPU、4GB内存），Framework 2运行的任务需要（3核CPU、2GB内存）。Framework 1的任务会消耗CPU总数的1/9、内存总数的2/9，Framework 1的主导资源是内存。同样，Framework 2的每个任务会CPU总数的1/3、内存总数的1/18，Framework 2的主导资源是CPU。

上面表中的每一行提供了以下信息：

• Framework chosen——收到最新资源邀约的Framework。
• Resource Shares——给定时间内Framework接受的资源总数，包括CPU和内存，以占资源总量的比例表示。
• Dominant Share（主导份额）——给定时间内Framework主导资源占总份额的比例，以占资源总量的比例表示。
• Dominant Share %（主导份额百分比）——给定时间内Framework主导资源占总份额的百分比，以占资源总量的百分比表示。
• CPU Total Allocation——给定时间内接受的所有Framework的总CPU资源。
• RAM Total Allocation——给定时间内接受的所有Framework的总内存资源。

注意，每个行中的最低主导份额以粗体字显示，以便查找。

最初，两个Framework的主导份额是0％，我们假设DRF首先选择的是Framework2，当然我们也可以假设Framework1，但是最终的结果是一样的。

1. Framework 2接收份额并运行任务，使其主导资源成为CPU，主导份额增加至33％。
2. 由于Framework 1的主导份额维持在0％，它接收共享并运行任务，主导份额的主导资源（内存）增加至22％。
3. 由于Framework 1仍具有较低的主导份额，它接收下一个共享并运行任务，增加其主导份额至44％。
4. 然后DRF将资源邀约发送给Framework 2，因为它现在拥有更低的主导份额。
5. 该过程继续进行，直到由于缺乏可用资源，不能运行新的任务。在这种情况下，CPU资源已经饱和。
6. 然后该过程将使用一组新的资源邀约重复进行。

值得注意的是，在当资源释放的速度不够快的情况下，资源分配模块具有撤销任务的能力。Mesos尝试如此撤销任务：向执行器发送请求结束指定的任务，并给出一个宽限期让执行器清理该任务。如果执行器不响应请求，分配模块就结束该执行器及其上的所有任务。

分配策略可以实现为，通过提供与Framework相关的保证配置，来阻止对指定任务的撤销。如果Framework低于保证配置，Mesos将不能结束该Framework的任务。

mesos优点

1.效率

上图来自Mesosphere网站，描绘出Mesos为效率带来的好处。如今，在大多数数据中心中，服务器的静态分区是常态，即使使用最新的应用程序，如Hadoop。这时常令人担忧的是，当不同的应用程序使用相同的节点时，调度相互冲突，可用资源互相争抢。静态分区本质上是低效的，因为经常会面临，其中一个分区已经资源耗尽，而另一个分区的资源却没有得到充分利用，而且没有什么简单的方法能跨分区集群重新分配资源。使用Mesos资源管理器仲裁不同的调度器，我们将进入动态分区/弹性共享的模式，所有应用程序都可以使用节点的公共池，安全地、最大化地利用资源。 一个经常被引用的例子是Slave节点通常运行Hadoop作业，在Slave空闲阶段，动态分配给他们运行批处理作业，反之亦然。 值得一提的是，这其中的某些环节可以通过虚拟化技术，如VMware vSphere的分布式资源调度（DRS）来完成。 然而，Mesos具有更精细的粒度，因为Mesos在应用层而不是机器层分配资源，通过容器而不是整个虚拟机（VM）分配任务。 前者能够为每个应用程序的特殊需求做考量，应用程序的调度器知道最有效地利用资源; 后者能够更好地“装箱”，运行一个任务，没有必要实例化一整个虚拟机，其所需的进程和二进制文件足矣。

2.敏捷

快速使用集群中可用的资源。

3.可扩展性

Mesos可扩展设计的关键之处是采用两级调度架构。 使用Framework代理任务的实际调度，Master可以用非常轻量级的代码实现，更易于扩展集群发展的规模。 因为Master不必知道所支持的每种类型的应用程序背后复杂的调度逻辑。 此外，由于Master不必为每个任务做调度，因此不会成为容量的性能瓶颈，而这在为每个任务或者虚拟机做调度的整体调度器中经常发生。

4.模块化

每接入一种新的Framework，Master无需为此编码，Slave模块可以复用，使得在Mesos所支持的宽泛领域中，业务迅速增长。相反，开发者可以专注于他们的应用和Framework的选择。 当前而且还在不断地增长着的Mesos Framework。目前已经支持的框架在下图：

Mesos容错

• Master: Mesos使用热备份（hot-standby）设计来实现Master节点集合。一个Master节点与多个备用（standby）节点运行在同一集群中，并由开源软件Zookeeper来监控。Zookeeper会监控Master集群中所有的节点，并在Master节点发生故障时管理新Master的选举。建议的节点总数是5个，实际上，生产环境至少需要3个Master节点。 Mesos决定将Master设计为持有软件状态，这意味着当Master节点发生故障时，其状态可以很快地在新选举的Master节点上重建。 Mesos的状态信息实际上驻留在Framework调度器和Slave节点集合之中。当一个新的Master当选后，Zookeeper会通知Framework和选举后的Slave节点集合，以便使其在新的Master上注册。彼时，新的 Master可以根据Framework和Slave节点集合发送过来的信息，重建内部状态。

• Framework调度器: Framework调度器的容错是通过Framework将调度器注册2份或者更多份到Master来实现。当一个调度器发生故障时，Master会通知另一个调度来接管。需要注意的是Framework自身负责实现调度器之间共享状态的机制。

• Slave: Mesos实现了Slave的恢复功能，当Slave节点上的进程失败时，可以让执行器/任务继续运行，并为那个Slave进程重新连接那台Slave节点上运行的执行器/任务。当任务执行时，Slave会将任务的监测点元数据存入本地磁盘。如果Slave进程失败，任务会继续运行，当Master重新启动Slave进程后，因为此时没有可以响应的消息，所以重新启动的Slave进程会使用检查点数据来恢复状态，并重新与执行器/任务连接。当计算节点/Slave节点无法响应多个连续的消息后，Master会从可用资源的列表中删除该节点，并会尝试关闭该节点。然后，Master会向分配任务的Framework调度器汇报执行器/任务失败，并允许调度器根据其配置策略做任务失败处理。通常情况下，Framework会重新启动任务到新的Slave节点，假设它接收并接受来自Master的相应的资源邀约。

• Executor/task: 与计算节点/Slave节点故障类似，Master会向分配任务的Framework调度器汇报执行器/任务失败，并允许调度器根据其配置策略在任务失败时做出相应的处理。通常情况下，Framework在接收并接受来自Master的相应的资源邀约后，会在新的Slave节点上重新启动任务。

一些问题

• Mesos不支持抢占，无法设置任务优先级

• spark在mesos上的资源占用有两种模式fine（细粒度）和coarse（粗粒度）。其中fine是default模式，按官方给出的文档，fine模式会提高资源利用率，但是在实际使用中我们发现，fine模式下，mesos集群有资源，spark仍然报资源不足，运行失败。而这时候改为coarse模式，问题就会消失。

• spark运行时的文件碎片。spark shuffle会在slave机器上产生大量的文件碎片，如果slave配置不够，就会直接导致机器inode 100%。为了提高文件系统性能，你需要修改你的spark config，将spark.shuffle.consolidateFiles设置为true。

• Mesos最适用于Job的任务持续时间短，资源需求可以灵活伸缩的运算框架，如MapReduce等，对于需要长时间占用大量资源类型的Job，其非全局式的资源调度可能较难实现近似最优的调度。Google的Omega调度框架则试图同时解决这些问题。

参考文档

http://www.infoq.com/cn/author/韩陆

http://mesos.apache.org/documentation/latest/mesos-architecture/

http://www.csdn.net/article/2015-07-10/2825180