【编者按】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和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原生是用Discovery service来支持弹性集群,和Mesos集成之后,Mesos会定期向Swarm发送offer来实现弹性集群。另外一个重要的区别就是,在和Mesos集成之前,Swarm是通过访问具体的Node来调用Docker的标准API 来创建container的,在和Mesos集成之后,是通过调用Mesos的API 来创建建container的。
把Swarm运行在Mesos之上,或者说利用Mesos向Swarm提供资源,个人认为主要有三个原因:
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来动态的配置每个租户使用资源的限额。
首先来看资源的管理。 Mesos会定期以Offer的形式向它上层的framework提供资源,Swarm也不例外,Swarm收到Mesos发送的Offer之后:
注:作者认为对于Swarm的这个设计来说,它可以通过修改offertimeout来长时间的占有offer,进而提高它自己创建container的效率,但是对于Mesos来说,这个做法是不推荐的,因为它会影响Mesos资源分配的公平性以及降低资源的利用率。
你可以通过Docker info 命令来查看目前Swarm中可用的Offer:
下边介绍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。
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 的集成仍然处于起步阶段,改进的空间还很大,个人认为主要存在以下几个方面的问题:
以上分析充数一家之言,如有失误,敬请指导。
IBM Platform DCOS作为Mesos社区的主要贡献组织,结合自身在资源调度方面丰富的实践应验,正在对Mesos资源的调度模块(Mesos Allocator)进行不断的优化,而且通过将自己的资源调度组件EGO与Mesos集成,为Mesos上层framework提供了更多的调度策略和更加友好的策略配置界面。本文主要分析了 Swarm与Mesos集成的原理以及存在的问题,在本文的基础上,后续我们会详细介绍IBM platform DCOS对Mesos的改进,如何将这些改进应用于Swarm,以及这些改进会对企业级用户带来什么样的体验。
作者简介:
王勇桥,80后的IT攻城狮,供职于IBM多年,主要从事云计算领域相关的工作,Mesos和Swarm社区的贡献者。平时喜欢在业余时间研究DevOps相关的应用, 对自动化部署,持续集成,资源调度有较深的研究。
责编:魏伟,关注OpenStack,欢迎投稿,[email protected]
2016年3月18日-19日,由CSDN重磅打造的数据库核心技术与实战应用峰会、互联网应用架构实战峰会将在上海举行。这两场峰会将邀请业内顶尖的架构师和技术专家,共同探讨高可用/高并发系统架构设计、新技术应用、移动应用架构、微服务、智能硬件架构、云数据库实战、新一代数据库平台、产品选型、性能调优、大数据应用实战等领域的热点话题与技术。
2月29日24点前仍处于最低六折优惠票价阶段,单场峰会(含餐)门票只需799元,5人以上团购或者购买两场峰会通票更有特惠,限量供应,预购从速。(票务详情链接)。