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原生是用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创建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参数，来修改这个默认时间。

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

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

3. 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相关的应用， 对自动化部署，持续集成，资源调度有较深的研究。

声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。