返回 登录
0

Apache Mesos社区、生态、项目进展及规划概述

阅读10177

本文谢绝任何公众号转载!

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

作者简介

刘光亚,2008年于西安交通大学软件学院获得硕士学位,目前就职于IBM Platform Computing 系统科技部云计算部门,担任云计算开发部架构师。自2013年5月开始参与OpenStack社区的开发工作,参与的项目包括Nova、Cinder、Heat和Magnum等项目,目前担任Magnum的core member。同时自2014年12月参与Mesos生态系统的调研以及Mesos社区的开发工作,Mesos活跃贡献者。西安OpenStack Meetup和Mesos Meetup组织者。

责编:周建丁(zhoujd@csdn.net)

评论