Swarm和Mesos集成指南-原理剖析

Posted CSDN

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Swarm和Mesos集成指南-原理剖析相关的知识,希望对你有一定的参考价值。

【编者按】Swarm是Docker旗下的子项目,用来帮助用户管理多个Docker引擎,并且将他们抽象成为一个虚拟的整体以标准Docker API的方式暴露给终端用户。Mesos 是Apache下的一个分布式资源管理框架,它最大的优势就是可以让各种不同的workload共享一个数据中心的资源。从今天开始,来自IBM Platform软件工程师王勇桥将带来“Swarm和Mesos集成指南”系列文章,带大家了解Swarm和Mesos集成的架构和原理,Swarm基于Mesos集群的实战部署和配置,以及基于IBM Platform自身在资源调度、分布式计算领域方面的实践经验,向大家介绍IBM Platform对Mesos在资源调度方面的策略优化,以及以Swarm为例向大家介绍这些优化将对Mesos上层的framework和企业级用户带来哪些增强性的体验。本文为第一篇:原理剖析。


Swarm介绍


在介绍Swarm和Mesos集成之前,我们先来简单的了解一下Swarm以及它的架构。在Swarm出现之前,基于Docker API的上层应用如果想要把它的container部署在多个Docker host上,那么它必须自己管理一组Docker host,然后自己设计实现调度策略把它的container部署到不同的Docker host上。这对于将Docker应用于大规模的生产环境实际上是一大障碍,因为上层应用不但要考虑自身的业务需求,还要实现Docker集群资源的管理和调度。为了解决这个实际的问题,使Docker可以很容易的应用于大规模的集群环境,Swarm应运而生,它是Docker旗下的子项目,用来帮助用户管理多个Docker引擎,并且将他们抽象成为一个虚拟的整体以标准Docker API的方式将暴露给终端用户。也就是说,已经支持Docker 标准API的上层应用可以无缝的和Swarm进行集成 ,利用Swarm提供的调度策略来轻松的将自己的container部署到不同的Docker Host上。


下边我们来看一下Swarm的架构设计,如下图所示:



在Swarm的架构中,它的后台cluster的采用了面向接口(swarm/cluster/cluster.go)的设计,也就是说你可以重新实现哪些接口来提供更强大的后台cluster。比如Mesos。Swarm和Mesos集成之后的架构如下图所示:


Swarm和Mesos集成指南-原理剖析

从两个架构图的对比,我们不难发现Swarm原生是用Discovery service来支持弹性集群,和Mesos集成之后,Mesos会定期向Swarm发送offer来实现弹性集群。另外一个重要的区别就是,在和Mesos集成之前,Swarm是通过访问具体的Node来调用Docker的标准API 来创建container的,在和Mesos集成之后,是通过调用Mesos的API 来创建建container的。


为什么要把Swarm运行在Mesos之上


把Swarm运行在Mesos之上,或者说利用Mesos向Swarm提供资源,个人认为主要有三个原因:


  1. 首先从Swarm推广的角度来看,因为各大云厂商都开始拥抱Mesos,Swarm和Mesos集成可以扩大Swarm应用的空间,使Swarm可以运行在一个以Mesos管理资源的数据中心。


  2. 第二个也是最主要的目的就是利用Mesos的弹性资源分配机制,使Swarm可以和Mesos之上的其他framework共享资源,进而提高资源利用率。


  3. 第三个优势是它填补了Swarm对多租户支持的空白。在Swarm和Mesos集成之前,Swarm是很难支持多租户的。在Swarm和Mesos集成之后,Swarm可以借助Mesos容易的实现多租户。作者认为实现的方式有以下两种:


a. 在Mesos中的framework支持多个role之前,我们可以在一个Mesos的数据中心中为每个Swarm租户启动一个Swarm framework(启动多个Swarm Manager),每个Swarm framework使用不同的role向Mesos注册。

b. 如果Mesos中的framework支持使用多个role(Mesos社区正在开发这个功能,详细的进展你可参考#MESOS-1763),那么我们就只需要在Mesos数据中心启动一个Swarm framework,并且使用多个role向Mesos注册,每个role对应一个Swam 的租户。


这样我们就可以利用Mesos 来轻松的达到如下多租户的效果:


a. 通过static/dynamic reservation, create volume为每个租户分配固定的资源,这些资源对对应的租户总是优先可用。 
b. 通过为role配置不同的weight 来动态的修改每个租户使用资源的优先级。(注:Mesos社区在0.28版本中将会提供一个endpoint来支持在运行时修改weight,详细进展你可以参考#MESOS-4189)。 
c. 通过为role配置quota来动态的配置每个租户使用资源的限额。


Swarm和Mesos集成剖析


首先来看资源的管理。 Mesos会定期以Offer的形式向它上层的framework提供资源,Swarm也不例外,Swarm收到Mesos发送的Offer之后:

  1. 从Offer 中获取Mesos Slave ID作为键值来创建Swarm Agent,也就是说Mesos的一个Slave会映射为Swarm 的一个Agent, 在一个agent下会包含多个Offer。(在Swarm和Mesos集成之前, Swarm agent是由Discovery service动态添加和删除的)。

  2. 从Offer中获取Mesos Slave的机器名(offer.Hostname)和对应的Docker Engine的端口(这个端口的默认值为Docker daemon的默认端口2375,如果你的Docker daemon没有使用默认端口,你需要在启动对应的Mesos Salve时指定一个名为docker_port的attribute来修改这个端口)来创建一个Swarm Cluster Engine,一个Swarm Agent对应一个Engine。Swarm利用这个Engine来和对应的Mesos Slave上的Docker Daemon进行通信,比如查看docker info,docker version等。如果通信失败(返回ErrConnectionRefused错误),Swarm会把这个Engine设置为Unhealthy。另外的Swarm会为这个Engine启动一个协程来定期的刷新对应Docker Engine的信息,例如container,image,volume以及network等信息。

  3. Swarm将缓存这个Offer,并为这个Offer创建一个timer,如果这个offer在一定的时间内没有被用来创建container,Swarm会自动将这个offer decline把对应的资源归还给Mesos,以便于其他的framework可以使用。默认的offer失效时间为30秒,用户可以通过在Swarm Manager启动时设置–cluster-opt mesos.offertimeout参数,来修改这个默认时间。


注:作者认为对于Swarm的这个设计来说,它可以通过修改offertimeout来长时间的占有offer,进而提高它自己创建container的效率,但是对于Mesos来说,这个做法是不推荐的,因为它会影响Mesos资源分配的公平性以及降低资源的利用率。


你可以通过Docker info 命令来查看目前Swarm中可用的Offer:


Swarm和Mesos集成指南-原理剖析
下边介绍Swarm+Mesos创建container的流程:



Step 1: Swarm Manager通过Docker标准的REST API接收上层应用发送的创建container的请求:


a.创建Task对象,并将新创建的Task加入到任务队列(cluster. pendingTasks)。 
b.创建Task对应的timer,如果在设置的超时时间内没有可用的offer用来执行这个Task,则此Task会被标识为失败并返回,并且从任务队列中删除,默认的超时时间为5秒,用户可以通过在Swarm Manager启动时设置–cluster-opt mesos.tasktimeout参数,来修改这个默认时间。


Step 2: Swarm Manager通过scheduler选择合适的node来执行这个Task:


a.Step 2.1 如果此时有足够的resources可以满足,则调用Mesos API来创建这个container. 
b.否则等待Mesos 发送Offer。


Step 3: Swarm scheduler收到Mesos发送的Offer,然后遍历所有的pendingTasks,通过filter和设置的strategy选择合适的node来执行这个任务:


a.目前Swarm一旦为一个Task选择了一个合适的Node,它会利用这个Node上所有的Offer来执行这个Task,也就是说它不会根据这个Task实际使用的资源量来挑选必要的offer,在这个Node上执行一个Task之后其余的resource都会被退还给Mesos。这个实现会影响Swarm创建container的性能,后期需要改进。


b.同时Swarm会在launch task的同时为相关的offer设置一个offerFilter,告诉Mesos在一段时间内它不接受相关Node上的resources。这个默认的时间为5秒,用户可以通过在Swarm Manager启动时设置–cluster-opt mesos. offerrefusetimeout参数,来修改这个默认时间。


Step 4: Swarm scheduler调用Mesos API创建container。


a.调用Mesos API创建task之后,Swarm会将这个Node上的所有offer从缓存中删除。 
b.同时启动一个Monitor来监听任务的运行状态。


Step 5,6: 如果Task的状态有所变化,Mesos会发送StatusUpdateMessage给Swarm。


Step 7: 终端用户可以通过Docker 命令(docker ps)或者API查看所有container的运行状态。


结束语


目前Swarm和Mesos 的集成仍然处于起步阶段,改进的空间还很大,个人认为主要存在以下几个方面的问题:

  1. 对Mesos Scheduler接口的实现还不够全面,比如没有实现SlavrLost, ExecutorLost等事件。


  2. 不支持Mesos 的Rescind offer。Rescind offer是Mesos提供的一种撤销offer的机制。比如当某个Mesos Slave不可用之后,Mesos会向对应的framework发送RescindResourceOfferMessage告诉这个offer现在已经不可用了。Swarm支持了Rescind offer之后,可以避免用失效的offer创建container,提高终端用户的体验。


  3. 不支持Mesos的Inverse offer。Inverse offer是Mesos提供的一种回收资源的机制。比如在Mesos maintenance功能中,如果operator计划维护某个slave,它会向Mesos发起一个maintenance scheduler请求,Mesos收到这个请求之后,会向每个使用了这个slave的资源的framework发送Inverse offer来告诉这些资源即将不可用,framework可以选择将对应的task迁移到另外的slave上或者采用另外的方式来避免损失。Swam 支持了Inverse offer之后就可以实现task的自动failover。


  4. 不支持Mesos的Revocable resource。Revocable resource顾名思义就是可以收回的resource,目前支持的Revocable resource 是Usage slack, 它是由每个Mesos slave上的estimator来计算,比如某个task创建时预计使用1024M内存,但它在某一时刻实际只使用了512M,这时Mesos就会将另外没有使用的512M以Usage slack的类型发送给其他的framework使用,如果一段时间之后,那个task使用的内存上升,则slave会直接kill掉使用了对应revocable resource的task来回收资源。Swarm在支持了Revocable resource之后,可以进一步充分的利用Mesos的资源。


  5. 对Mesos failover的支持不够strong。根据个人的测试,发现在Mesos failover之后,Swarm 不会重新向新的Mesos Master注册,我已经在Swarm社区log了一个issue,你可以关注#1730获取后续的解决办法。


  6. Docker Info的显示不够合理。个人认为在Swarm+Mesos中,Docker info命令的实现应该和之前的行为保持一致。首先不应该显示offer的信息,offer对于Swarm的终端用户来说应该是透明的,因为Swarm的filter和strategy都是以node为单位来调度的,所以应该像原来一样显示 nodes的信息,并且显示每个node的当前状态,运行container的数量,reserved resources,total resources和标签等。


  7. Swarm创建container的性能有待改进。目前Swarm一旦为一个Task选择了一个合适的Node,它会利用这个Node上所有的Offer来执行这个Task,也就是说它不会根据这个Task实际使用的资源量来挑选必要的offer,在这个Node上执行一个Task之后其余的resource都会被退还给Mesos。这个实现会影响Swarm创建container的性能。


  8. 最后一条我认为,Swarm和Mesos集成以后可能会影响Swarm创建container的性能,从上文架构图中可以看出,Swarm和Mesos集成之前它是通过调用Docker标准API来访问每个Node创建container的,在和Mesos集成之后所有创建container的请求都必须交给Mesos Master来处理,也就是把多点变成了单点,在大并发情况下,性能可能有所降低。


以上分析纯属一家之言,如有失误,敬请指导。


IBM Platform DCOS作为Mesos社区的主要贡献组织,结合自身在资源调度方面丰富的实践应验,正在对Mesos资源的调度模块(Mesos Allocator)进行不断的优化,而且通过将自己的资源调度组件EGO与Mesos集成,为Mesos上层framework提供了更多的调度策略和更加友好的策略配置界面。本文主要分析了 Swarm与Mesos集成的原理以及存在的问题,在本文的基础上,后续我们会详细介绍IBM platform DCOS对Mesos的改进,如何将这些改进应用于Swarm,以及这些改进会对企业级用户带来什么样的体验。


作者简介:王勇桥,80后的IT攻城狮,供职于IBM多年,主要从事云计算领域相关的工作,Mesos和Swarm社区的贡献者。平时喜欢在业余时间研究DevOps相关的应用, 对自动化部署,持续集成,资源调度有较深的研究。




SDCC 2016 数据库&架构技术峰会(上海站)将于3月18日-19日举行,讲师和议题已全部确认。目前6折限时报名,团购享有更多优惠!详情请戳「阅读原文」


以上是关于Swarm和Mesos集成指南-原理剖析的主要内容,如果未能解决你的问题,请参考以下文章

技术分享|手机推送原理剖析指南

深入浅出Java并发编程指南「剖析篇」Fork/Join框架的实战开发和原理探究指南

Flutter之GetX入门指南 ObxWidget原理剖析

Flutter之GetX入门指南 ObxWidget原理剖析

总目录机器学习原理剖析开源实战项目全套学习指南(50篇合集)

深入浅出RocketMQ原理及实战「底层原理挖掘系列」透彻剖析贯穿RocketMQ的消息发送的全部流程和落盘原理分析指南