Mesos社区与生态

首先介绍下Mesos社区。Mesos是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核，是DCOS，也就是我们通常所说的数据中心操作系统的的基础。Mesos最初是由加州大学伯克利分校的AMPLab开发的。

2014年参加Mesos conf的是260多人，2015年在西雅图一下涨到了700多人，所以Mesos在2015年是发展迅猛的一年。现在在Mesos社区贡献代码的主要是Mesospher，Twitter，IBM和Intel，大多数committer都来自Mesospher和Twitter。但是现在Twitter的好几个工程师都跳到了Mesosphere，同时Mesospher也有几个工程师跳到了Intel，现在IBM在社区逐渐发力，从目前代码的提交量和参与人员来看，已经成为第二大贡献者。

比较Mesos社区和OpenStack社区，Mesos和OpenStack到现在都已经发展5年多了，OpenStack峰会上次的人数是将近7000人，Mesos才700来人。其实也不奇怪。OpenStack项目很多，有十几个核心项目，分摊下来的话，其实一个项目大概也就对应6,700人，这么想Mesos社区还是挺活跃的。

Mesos的生态系统在2015年发展也很快，出现了好多新的Mesos用户和新的Mesos Framework。并且好多公司都在基于Mesos开发自己的Framework，包括VMware，Cisco，华为，苹果等等。个人感觉是，对于Mesos，大家更看中的是上层的Framework，如何让上层的Framework来最大化地把Mesos用好，是好多公司一直在探索的，这些探索产生的一些需求又推进了Mesos，形成一个良性循环。

这个图很形象的描述了Mesos生态系统的发展历程：

左上角是基于Mesos产生一些商业化的产品、服务，来帮助用户提供DCOS的功能。

左下角就是用户在使用的时候，会有一些特殊定制的一些需求，服务提供商需要根据这些需求提供解决方案。

右边这一步就是说如果是一些很common的解决方案的话，就需要把这些方案贡献给社区。

然后就进入下一轮迭代开发：改进产品，提供解决方案，贡献社区，其实这个和OpenStack的开发流程基本上是一样的，都分为这三步。

新应用的话，主要是Mesos和越来越多的Framework开始继承了，包括Kibana，Kafka，Kubernetes，Cassandra, Swarm等等，另外一个值得注意的是华为贡献了他们的CloudFoundry的Framework，虽然现在还处在一个原型阶段，但是CloudFoundry和Mesos集成又为Mesos生态圈添加了一员大将，如果有人在基于CloudFoundry做PaaS的，可以对CloudFoundry和Mesos做一些调研，他们的集成能够让用户的数据中心资源使用更加充分。

Mesos演进

接下来我们看下Mesos社区在最近一些版本发布的和即将发布的新功能，Mesos 0.27马上发布，现在已经开始了0.28的开发，至于什么时候到1.0，这个不好说。

Resources/Attributes discovery (Mesos-3366)

在一个异构的计算环境中，客户在运行作业的时候，有时候对硬件有一些特定的需求，例如GPU，网卡类型，CPU架构，操作系统版本等等，但是这些属性，Mesos Agent在启动的时候，都不会主动上报给Mesos Master节点的，用户虽然可以通—resources –attribute等flag在Mesos Agent启动的时候指定一些属性值，但是这样做的缺点是如果换了一台agent，这些属性值可能需要改变，不便于移植。所以社区就做了这个项目，能够实现让用户在Mesos Agent启动的时候，指定一些专门做资源搜集，资源发现的一些hook脚本，让这些脚本帮忙搜集Mesos Agent上用户需要的指定资源，用户需要做的就是按照Mesos的需要写一些资源搜集，资源发现的插件，在Mesos Agent启动的时候作为参数传给Mesos Agent，就可以通过这些Hook把用户需要的资源搜集上来，同时这些插件可以在不同的Mesos Agent上去使用，用户不需要改代码，直接就可以运行。

Quota (Mesos-1791)

Quota主要是用来做资源预留的，和Mesos的Dynamic/Static Reservation比较像，都是为某个role去预留一些资源，但是Dynamic/Static Reservation的资源预留主要是host级别的，但是Quota的资源预留是集群级别的，一旦资源被某个role通过Quota预留后，这些资源就不能分给别的role去使用了。通常在我们提到Quota的时候，会主要关心两个值：Quota的Minimal Guarantee和Quota的maximal limit。现在Mesos的Quota支持只做了Minimal Guarantee，未来会加入对Quota maximal limit的支持。

Quota支持的场景主要是当用户的一些Framework开发完成后，可能需要运行一些很critical的作业，用户期望这些作业在提交后，能马上运行，不用等其它的Framework释放资源。对于这种Framework的作业，用户可以为当前的Framework的role设定一个quota，然后当用户的作业运行的时候，可以马上得到自己通过quota预留的资源，保证用户作业的SLA。设置Quota的前提是当前系统必须有足够的资源或者足够的没有被使用的offer，如果系统有足够的空闲资源，用户可以直接预留这些空闲资源；如果空闲资源不够的话，Mesos会通过去decline一些没有使用的offer，也就是我们通常所说的outstanding offer来增加一些系统的空闲资源，保证Quota的设置可以成功。

Implicit Role (Mesos-3988)

有这个项目的主要原因是静态配置role的一些局限。在没有Implicit Role之前，在Mesos master启动的时候，需要通过—roles flag指定当前Mesos集群可用的role。当前方案的主要缺点是Mesos集群的role是静态的，不能动态的变化，这种配置很不灵活。

例如当用户在当前的Mesos集群添加一个新的Framework，并且这个Framework用的是一个新的role，这种情况下，就需要系统管理员重启Mesos Master，在Mesos Master重启时，–roles flag加入即将加入的Framework的role，才能保证Mesos Master能够认识新的Framework的role，保证新的Framework可以成功注册。

在引入了Implicit Role的功能后，用户在Mesos Master启动的时候好，可以不指定任何的role，所有role的都是默认创建的，例如在用户注册Framework或者设置Quota的时候，如果当前集群没有Framework或者Quota需要的role，Mesos会自动创建这些role，当这些Framework被删除时，如果当前被删 的Framework的role没有任何Framework使用时，这个role就会被删掉。通过Implicit Role简化了用户创建，注册新的Framework的流程。

Oversubscription (Usage Slack/Allocation Slack Mesos-1607)

我们可以通过这张图介绍下Mesos中的资源超售，这张图主要是描述了一个agent上的所有的资源类型。资源超售现在分两类，第一类是Usage Slack的资源超售，第二个是Allocation Slack的资源超售。这两种超售类型会接先来详细介绍。

资源超售主要是在可撤销的资源上利用暂时没有使用的资源来运行tasks/executors，而 Mesos 可以随时撤销任务。Mesos可以利用资源超售提升系统的资源利用率。

对于Usage Slack类型的资源超售，它有两个插件来控制：资源估算和服务质量（QoS）控制，同时对现有的资源进行分配、资源监视器和 Mesos Slave 进行了扩展。

• Reserved Resources Resources - 预留资源，主要有两类，一类是静态预留，一类是动态预留，静态预留可以在Mesos agent启动的时候通过“–resources”参数设置，动态预留有两种方式去设置，第一个方法是通过Framework在运行时，动态的为当前的Framework预留一些资源，第二个是用户可以通过http endpoint直接在某个agent上为某个role去预留一些资源。

• Allocated Resources Resources: 已经分配的资源，主要包含两类，第一类是已经被Framework接受用于执行作业的资源，第二类是被outstanding offer所占用的那些资源。

• Revocable Resources：可撤销回收或者可被抢占的资源。现在Revocable的资源可以分两类：Usage Slack和Allocation Slack，当前的逻辑这两类资源都是通过agent去杀掉使用这类资源的executor来释放资源。

• Reservation Slack：主要是指agent上总的资源和这个agent上预约的资源差值，这部分资源主要是作为unreserved resource供其它role去使用。

• Allocation Slack： 预留资源和实际分配预留资源的差值。预留资源减掉实际分配预留资源极为allocation slack，这部分资源可以被借给其他的role去使用，当当前的role有新作业时，会对借出去的资源进行回收。这个项目现在还在进行中，感兴趣的可以看下Mesos-1607.

• Usage Slack：实际分配的资源和实际使用的资源差值，举个例子，Mesos分给某个executor/task 10个cpus，但是实际当这个task在运行的时候，只是用了60%的cpus，那么我们就可以把剩余的40%作为usage slack汇报给Mesos allocator对这部分资源进行重新调度。当然因为Usage Slack都是通过plugin的形式去做的，用户可以根据自己的需求写自己的resources estimator和qos controller来对usage slack进行处理。

Mesos社区计划

接下来我们看一下Mesos社区计划做的项目。

Quota Enhancement Mesos-4392

当前Quota的实现有一些缺陷可能会导致系统的资源使用率不高，例如一个role的quota设置为cpus：100；mem：2048，但是当在真正使用的时候，这个role可能只有cpus：30；mem：1024被Framework去使用了，剩下的cpus：70；mem：1024因为Quota的限制，不能被其它的role去使用，造成了资源浪费。所以社区目前有个项目计划对Quota做一些改进，加入一种新的revocable resources，名字还没定，但是我估计可能会叫Quota Slack，就是被Quota预留的但是没有被分配出去的资源，这部分资源可以作为revocable resources，借给其它的role去使用，提升系统的资源利用率。当借出去资源的role又有新的资源请求时，会通过杀掉一些使用Quota Slack的executor来释放资源。

Optimistic Offer Mesos-1607

需要这个功能的主要原因是，现在所有的offer都是pessimistic Offer，所谓的pessimistic Offer就是说当一个offer被发给Framework后，就被当前的Framework锁定了，其它的famework都不能使用这个offer，只有当在这个offer上launch完task后，Framework把当前offer剩余的资源返回给allocator后，这个offer才能被下一个Framework去使用。Optimistic Offer主要是想当Mesos allocator发出去一个offer时，多个Framework可以同时竞争这个resources， 谁抢到这个offer，这个offer就可以为谁所用。

Multi-Role Framework Mesos-1763

当前Mesos一个Framework只能使用一个role上的资源，如果一个Framework在注册的时候没有指定role，那它就会用默认的role(*)，role的主要作用是：

1. 首先是每个role都会有个weight，如果一个role的weight比较高的话，那么在Mesos allocator进行资源分配的时候，weight高的会按照DRF分配策略拿到比较多的资源。

2. 资源预留：资源预留主要是通过role去做的，每个role可以静态或者动态的去预留一些资源。

3. 资源配额：每个role可以配置一个资源配额，这个配额是cluster级别的。

如果一个Framework只有一个role的话，对于Meta-Framework会有一个问题。所谓的Meta-Framework就是这个Framework可以再管理一堆其它的Framework，Marathon就是一个很典型的Meta-Framework，我们可以通过Marathon管理Spark，Kubernetes，Swarm等Framework。但是因为现在一个Framework只能有一个role，所以即使Marathon可以管理多个Framework，目前意义也不是太大，因为所有的Framework共享同一个role，资源分配，利用都不是很有效率。所以现在一个workaround的方法是每个Marathon只管理一个Framework。

如果引入了Multiple role支持后，我们就可以给Marathon设置多个role，被Marathon管理的Framework可以每个使用一个role，这样Marathon就可以把不同role的资源分配给上层的Framework，提升了资源分配，共享的效率。

Fine Grained Resource Offer Mesos-3765

所谓的细粒度的Resource Offer，主要是相对于现在的Mesos Offer来说的，当前的Mesos Allocator在给在给Framework发Offer的时候，都是粗力度的，所谓的粗力度就是在给上层的Framework分配resources offer的时候，总是把某个agent上所有的所有资源发给上层的某个Framework，也就是说某个agent在某一时刻只能作为一个Framework的offer。当前这种粗力度的offer分配导致的主要问题是在某些情况下，可能会导致一些Framework拿不到资源。一个例子就是一个Mesos集群有少量的很强大的agent和大量greedy的Framework，Framework的数量多于agent的数量，在这种情况下，会导致一些Framework拿不到资源运行作业。

如果Mesos的Allocator能按照细粒度的方式对资源进行分配，那么就可以把一个agent上的resource作为多个offer分发给上层的多个Framework，保证上层的Framework能对资源共享，不会因为某些贪婪的framwork导致其他的framwork不能运行。

关于这个项目的方案，现在还在讨论，有人建议看能不能让Framework直接把请求发给Mesos，然后Mesos直接把当前Framework需要的资源发给它就完了。社区的反馈是，如果让Framework主动申请资源，可能会导致一些贪婪的Framework或者一些用户写的有bug的Framework把系统资源都占了，导致其他的Framework不能运行。另外一个方案时Mesos Master在启动时，指定Offer的大小，Mesos Allocator在发offer的时候，会按照制定的Offer的大小发offer，这个方案可能会被采纳。

Unified Container Mesos-2840

Docker是Mesos的一等公民，所以Mesos社区最近在对docker集成作比较大的改进，“Unified Container”是期望Mesos能统一的管理不同的container specifications, 例如 Docker, Appc (rkt), OCP (oci)等等。这一块的主要改动会在MesosContainerizer。现有的Docker Containerizer会保持不变，不知道等MesosContainerizer完全支持Docker后，这个Docker的Containerizer还会不会继续维护就说不定了，这个还得看社区的发展。

Mesos的所有设计文档

https://cwiki.apache.org/confluence/display/mesos/Design+docs+–+Shared+Links，大家可以通过这个链接拿到基本上所有Mesos的设计文档，可以挑几个感兴趣的看看，了解下Mesos的工作原理。

IBM Platform Computing & Mesos

最后介绍一下IBM在Mesos基础上研发的Mesos Connector。Mesos Connector主要是使Mesos集成了IBM Platform Computing的EGO强大的资源共享，资源调度策略，为Mesos提前加入了社区现在还没有的资源抢占，Optimistic Offer的功能。

IBM Mesos Conenctor的主要特点如下：

1）丰富的资源共享策略

IBM Platform Computing EGO 是一个企业级的资源调度系统，为用户提供丰富的资源共享策略，用户可以根据自己的需求定义自己自然分配计划。Mesos 与 EGO 集成起来后，这些策略也适用于 Mesos 的 Frameworks。

管理员根据每个 Role/Framework 的需求，可以为其定义一定量的 Owned 资源. 就是说这些资源一定可以得到保证的，不管 Framework 什么时候想要这些资源。Owned 资源定义支持多种形式，可以是以物理机器为单位的多个机器，也可以是百分比的方式拥有每个物理机器上百分之多少。如果 Role/Framework允许，在他自己不用的时候可以把这些owned 的资源借给其他人使用。这样最大化的提供整个集群的资源利用率。

管理员根据每个 Role/Framework 的需求，可以定义一些资源共享策略。那些被别人 Own 完，剩下的资源称之为共享资源，每个用户都可以使用的。但每个用户使用共享资源的优先级可以不同，使用共享资源的比例也可以不同。首先，优先级高的 Role/Framework 永远优先使用共享资源，在必要的情况下，可以抢占优先级的 Role/Framework 的共享资源。这是下面要提到的资源抢占。其次，如果 Role/Framework 优先级相同，他们根据资源比例配比去使用共享资源，如果某个 Role/Framework 使用了超过了他自己配比的资源，资源抢占也会发生。还可以进一步为 Role/Framework 配置共享资源使用上限。如果贡献资源使用将要超过设置的上限，Mesos-EGO 就不允许 Role/Framework 再启动作业了。

2）资源抢占式策略

资源抢占主要发生在一下三种情况下：

1. 某个 Role/Framework 借了别人 Owned 资源。 但资源拥有者想要把借出去的资源要回来，资源抢占就发生了。

2. 高优先级 Role/Framework 抢占低优先级 Framework/role 使用的共享资源。

3. 某个 Role/Framework 使用了超过配比给他的共享资源。这时候 Mesos-EGO 会尝试根据资源配比去平衡 Role/Framework 使用的共享资源，所谓的资源抢占也就发生了。

当资源抢占发生时，Mesos-EGO 会给 Framework 发 InverseOffer 把要抢占的资源要回来。一般会给 Framework 一定的缓冲时间，只要在要求时间内把作业停掉，把资源释放了就行。但如果 Framework 不配合，Mesos-EGO 会强制 Framework 的一些作业，把资源释放出来给高优先级 Framework，或资源本身所有者使用。

原文链接： http://geek.csdn.net/news/detail/54860