今天主要为大家介绍下mesos社区，分享mesos最近发布的一些新功能，以及未来会做的一些项目。
1 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做一些调研，他们的集成能够让用户的数据中心资源使用更加充分。
2mesos社区最近发布的一些新功能
接下来我们看下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进行处理。
3mesos社区计划做的项目
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组织者。
<b></b>
<b>本文来自云栖社区合作伙伴"dbaplus"，原文发布时间：2016-01-29</b>