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/九、内存总数的2/9，所以Framework1 的主导资源是内存。一样，Framework2 的每一个任务会CPU总数的1/三、内存总数的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/九、内存总数的2/9，Framework 1的主导资源是内存。一样，Framework 2的每一个任务会CPU总数的1/三、内存总数的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