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

刘光亚 2016-01-29 10:13:12

今天主要为大家介绍下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做一些调研,他们的集成能够让用户的数据中心资源使用更加充分。


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


3
Mesos社区计划做的项目
 

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组织者。



小编精心为大家挑选了近日最受欢迎的几篇热文↓↓↓

(关注订阅号dbaplus,回复以下数字,即可获取相应文章)

 

回复001,看陈爱珍《从文艺女到技术咖,一位美女工程师的华丽转身》;

回复002,看丁俊的《【重磅干货】看了此文,Oracle SQL优化文章不必再看!》;

回复003,看胡怡文《PG,一道横跨oltp到olap的梦想之桥》;

回复004,看陈科《memcached&redis等分布式缓存的实现原理》;

回复005,看陆传胜《听阿里巴巴JVM工程师为你分析常见Java故障案例》;

回复006,看郑晓辉《存储和数据库不得不说的故事》;

回复007,看袁伟翔《揭秘Oracle数据库truncate原理》;

回复008,看OpenSkill陈荣华《时下最火搜索引擎:ElasticSearch详解与优化设计》;

回复009,看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》;

回复010,看周李洋《面对Schema free的MongoDB,如何规范你的schema》。

 

最新评论
访客 2017年06月23日

为什么小表驱动大表比较快呢?

访客 2017年06月20日

学习

访客 2017年06月16日

水平太差,完全没看懂

访客 2017年06月14日

可以可视化吗?信息是挺全的

访客 2017年06月13日

学习了

活动预告