IBM云计算架构师：Mesos新功能以及roadmap简介

今天主要为大家介绍下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，huawei，苹果等等。个人感觉是，对于mesos，大家更看中的是上层的framework，如何让上层的framework来最大化的把mesos用好，是好多公司一直在探索的，这些探索产生的一些需求又推进了Mesos，形成一个良性循环。

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

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

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

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

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

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

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

1. 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上去使用，用户不需要改代码，直接就可以运行。

2. 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的设置可以成功。

3.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的流程。

4. 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 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进行处理。

1. 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来释放资源。

2. 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就可以为谁所用。这样做的好处是。。。。

3. 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，Kubernets，Swarm等framework。但是因为现在一个framework只能有一个role，所以即使Marathon可以管理多个framework，目前意义也不是太大，因为所有的framework共享同一个role，资源分配，利用都不是很有效率。所以现在一个workaround的方法是每个Marathon只管理一个framework。

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

4. 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，这个方案可能会被采纳。

5. Unified Container MESOS-2840

Docker是Mesos的一等公民，所以Mesos社区最近在对docker集成作比较大的改进，“Unified Container”是xxxxxxx

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, 或资源本身所有者使用。 

讲师介绍：刘光亚

• 西安交通大学硕士，目前就职于IBM Platform Computing 系统科技部云计算部门，担任云计算开发部架构师。

• 参与Nova、Cinder、Heat和Magnum等OpenStack社区项目开发，目前担任Magnum的core member。

• 2014年参与Mesos生态系统的调研以及Mesos社区的开发工作，Mesos活跃贡献者。西安OpenStack Meetup和Mesos Meetup组织者。