关于Swarm和Mesos资源利用率优化实践分析

【编者按】Apache Mesos作为一个非常优秀的分布式资源管理和调度系统，如何高效的管理和分配资源，必然成为它研究和努力的主要方向之一。本文是基于IBM Platform DCOS Team在资源调度领域的优秀经验，以及他们在Mesos社区为提升Mesos资源利用率而正在进行的实践活动，深度剖析了Mesos资源的收集和调度原理，以及如何在Mesos中提供Revocable资源来提高Mesos数据中心的资源利用率。最后，作者结合自己在Docker Swarm社区的贡献经验，重点讲解了在Docker Swarm如何支持Mesos的Revocable资源。来自IBM Platform软件工程师王勇桥将带来“Swarm和Mesos集成指南”系列文章，带大家了解Swarm和Mesos集成的架构和原理，Swarm基于Mesos集群的实战部署和配置，以及基于IBM Platform自身在资源调度、分布式计算领域方面的实践经验，向大家介绍IBM Platform对Mesos在资源调度方面的策略优化，以及以Swarm为例向大家介绍这些优化将对Mesos上层的framework和企业级用户带来哪些增强性的体验。本文为第三篇：资源利用率优化实践。
　　Mesos集群资源收集
　　Apache Mesos是一种分布式的资源管理和调度框架，它被称为是分布式系统的内核。那么Mesos是怎么在这个分布式的异质的环境中收集资源的呢？官方给出的架构图如下所示：
　　
　　默认情况下每一个Mesos Slave会主动采集它所在机器上的实际资源量， 现在默认情况下主要收集以下四种资源：
　　CPU： 默认调用系统函数os：：cpus（）来获取系统CPU的个数，如果在某些特殊的平台或者系统上获取失败，将采用默认值1。Memory：默认调用系统函数os：：memory（）来获取系统内存的大小，如果在某些特殊的平台或者系统上获取失败，将采用默认值1GB。Disk：注意，每一个Slave它不是获取整个机器的硬盘的大小，它默认调用系统函数fs：：size（flags.work_dir）来获取Mesos Slave指定的工作目录（Mesos Slave默认的工作目录为/tmp/mesos，你可以通过在启动Mesos slave的时候指定–work_dir参数来修改这个值）的文件系统的硬盘的大小。如果在某些特殊的平台或者系统上获取失败，将采用默认值10GB；在获取成功的情况下，如果获取的值大于默认值10GB，则预留5GB留给Mesos slave本身使用，剩下的当作此计算节点的存储资源交给其他framework使用，如果小于默认值10GB，则将获取值的一半预留，剩下的一半下的当作此计算节点的存储资源交给其他framework使用。Ports：默认使用默认值”［31000-32000］”。
　　当然了你可以通过以下两种方式改变默认的行为：
　　1.通过在启动Mesos Slave时指定–resources参数来定义每个计算节点上可以消费的资源量。它的值有两种格式：
　　第一种是分号分割的键值对字符串列表：“name（role）：value;name:value…”。name表示资源的名称，例如可以是cpus，mem，disk和ports以及用户自定义资源类型名称等，role表示资源预留的角色（就是Mesos中的static reservation），如果不指定，则表示此资源预留给默认的role（通过—default-role参数指定，如果不指定，则表示Mesos默认的role（＊）），value表示此资源的值，现在支持的类型有主要有三种SCALAR数字类型，RANGES范围类型，比如端口，SET离散枚举值。
　　第二种是一个文件的路径，如（file:///path/to/file or /path/to/file），这个文件的格式是一个JSON 文件，例如：
　　［ { “name”： “cpus”， “type”： “SCALAR”， “scalar”： { “value”： 24} }， { “name”： “mem”， “type”： “SCALAR”， “scalar”： { “value”： 24576} } ］
　　注意：如果你指定–resources这个参数它不会完全覆盖默认的行为，也就是说只有你指定了某种具体的资源，它才会覆盖这种具体资源的收集方式。例如你指定：–resources=”cpus（role1）：1;cpus（*）：2”，则表示，此计算节点总共有三个CPU，一个预留给role1，另两个预留给默认的role（＊），其他的三种资源memory，disk，ports仍然按照默认的方式收集。
　　2.由于通过–resources的方式来指定某种资源，它需要你在启动对应的Mesos Salve的时候就知道具体的资源量，但是对于有些集成的系统，它的资源是由某些第三方的资源收集服务获取的，比如Collectd。对于这种需求，Mesos同时提供了一种 hook的机制，来让用户实现自己的Moudle，定制他们收集资源的策略。
　　综上所述，Mesos集群中的每一个Slave节点，通过以上的资源收集方式，将所有的资源在它注册的时候上报给Master节点，Master将会利用它的资源调度策略，把这些资源以“Offer”的形式动态的分配给上层的framework，framework可以根据自身任务对资源的要求来选择是否接收这个Offer，一旦这个Offer被接受，framework将通过Mesos Master的任务调度机制，将任务运行在数据中心的指定的Slave节点上。
　　Mesos集群资源调度策略
　　Apache Mesos能够成为数据中心资源调度的内核，一个非常重要的原因就是它能够支持大多数framework的接入，那么Mesos要考虑的一个主要的问题就是如何为众多的framework分配资源。在mesos中，这个功能是由Master中的一个单独的模块（Allocation module）来实现的，因为Mesos设计用来管理异构环境中的资源，所以它实现了一个可插拔的资源分配模块架构，用户可以根据自己的需求来实现定制化的分配策略和算法。
　　本章节将主要介绍Mesos默认的资源调度模块DRF Allocator。官方默认给出了一个资源调度的流程图，如下所示：
　　
　　DRF（Dominant Resource Fairness） Allocator，它的目标是确保每一个上层的Framework能够接收到它最需资源的公平份额。下边我们先简单介绍一下DRF算法。在DRF中一个很重要的概念就是主导资源（dominant resource），例如对于运行计算密集型任务的framework，它的主导资源是CPU，对于运行大量依赖内存的任务的framework，它的主导资源是内存。DRF Allocator在分配资源之前，首先会按照资源类型计算每个framework占有（已经使用的资源＋已经以offer的形式发给framework但是还没有使用的资源）份额百分比，占有比最高的为这个framework的主导资源，然后比较每个framework主导资源的百分比，哪个值小，则将这个机器上资源发给对应的framework。你可以参考Benjamin Hindman的这篇论文https://www.cs.berkeley.edu/~alig/papers/drf.pdf来了解DRF算法的详细说明。
　　另外，Mesos集群管理员可以通过以下几种方式提供更多的资源分配策略：
　　给某个framework设置权重（weight）来使某个framework获取更多的资源。可以使用static/dynamic reservation指定将某一个Slave节点上的资源发送给特定role下的framework。可以为某个role配置quota来保证这个role下的framework在整个Mesos集群中获取资源的最小份额。Framework收到资源之后，可以创建持久化存贮卷，保证这些存储资源不能被其他的framework使用。
　　使用Revocable资源来提高资源利用率
　　对于DRF的Allocator，在资源分配方面可能存在以下几个方面的问题：
　　1.资源碎片的问题。由于DRF总是追求公平，它会把剩余资源公平的分配给所有的framework，但是这种公平分配可能会导致所有的framework在一个分配的周期中都没有足够的资源来运行它的任务。
　　2.本性贪婪的framework为了提高它自身的性能，有时候总试图去hold offer，即便是它当时没有需要执行的任务，那么这个时候，这些resource也不能分配给另外的framework使用。
　　3.对于gang-scheduing（同时申请一组资源）类型的应用，由于Mesos在一个时刻只能提供集群的部分资源，那么这种类型的应用可能需要等待比较长的时间才可以运行。
　　为了适当的提高Mesos的资源利用率，Mesos社区现在引入了Revocable类型的资源。这种资源是一种可以被Mesos自行回收的资源，也就是说如果上层的framework使用这种资源来运行的它们的任务，那么这些任务就有随时被杀掉的可能。它被设计主要用来运行一些可靠性要求比较低，无状态的的任务。也就是说现在Mesos主要为上层的framework提供两种资源：
　　• Non-revocable resources： Mesos提供的最常见的资源类型，一旦这种资源offer发给某个framework，那么这些资源永远可以保证对这个framework可用，Framework一旦用这种资源运行它的任务，那么这个任务所占用的资源不能被Mesos收回，除非framework主动杀掉任务或者任务结束。
　　• Revocable resources：这种资源是framework没有充分利用的资源，Mesos会把这部分资源再发送给其他的framework使用，如果其他framework用这种resource运行任务，那么这个任务有可能在某个时候被Mesos杀掉来回收对应的资源。这种资源主要运来执行best-effort任务，例如后台分析，视频图像处理，芯片模拟等一些低优先级的任务。
　　首先Mesos在MESOS-354项目中初次引入了Revocable类型的资源，它是我们所说的其中一种Revocable类型的资源，它主要考虑的应用场景是：在Mesos集群中，Mesos对资源的分配率一般可以达到80%以上，但实际的资源利用率却低于20%。在这个项目中，它提供了一种资源的再分配机制，就是把临时没有使用的资源（这些资源已经在之前分配给了某些任务，而且这些任务正在运行，但是它们没有完全使用已经分配给它们的资源）再分配给其他的任务。这种类型的revocable资源被称为Usage Slack的资源，下边我们来主要分析一下这种资源的生命周期：
　　第一步首先要确定哪些资源是Usage slack的revocable resource。每个Mesos Salve节点上的Resource estimator会定期和Resource Monitor模块交互来计算Usage slack，如果前后两次计算的值不同，则它会把这些revocable的资源上报给Mesos master。Mesos allocator会收到每个Slave上报的Usage slack的revocable resource，然后把这些revocable resource 发送给上层的framework。注：默认情况下framework是不接收revocable resource的，如果framework在注册时候指定REVOCABLE_RESOURCES capability，那么它将可以收到revocable resource。Framework可以选择使用这些revocable resource运行任务，这些revocable任务会像正常的任务一样被运行在对应的节点上。每个Slave上的Monitor会监视原来task的运行状况，如果它的运行负载提高，则Qos controller模块会杀掉对应的revocable task来释放资源。
　　另外的一种Revocable资源则在MESOS-4967项目中引入，它主要由IBM Platform DCOS Team的工程师主导设计开发，目前基本的设计和编码已经完成，正在review阶段，很快会在最近的Mesos版本中支持。它主要是考虑到在Mesos中有些资源某些role reserve，但是没有被使用的情况（Allocation Slack），我们在后续的文章中会对其详细介绍。
　　对于Revocable类型的资源，需要注意以下几点：
　　Revocable资源不能动态的reserve；Revocable资源不能用来创建存储卷；运行任务的时候，对同一种资源，revocable资源和non-revocable资源不能混用，但是不同类型的资源可以混用。比如CPU用revocable resource，Memory可以使用non-revocable资源。如果一个task使用了revocable资源或者它对应的executor使用了revocable资源，则整个container都被视为revocable task，可以被Qos controller杀掉。
　　在Swarm中使用Mesos的Revocable资源
　　在Docker Swarm目前的版本（v1.1.3）中，它不支持接收Mesos的revocable resource。IBM Platform DCOS Team对Swarm做了改进，使Swarm可以接收revocable resource，并且Swarm 的终端用户可以选择使用revocable 资源来运行他们低优先级的任务，或者使用non-revocable 资源来运行他们的高优先级任务。这样的话，如果Swarm和其他的framework共享Mesos集群资源的时候，其他framework的未充分利用的资源将可以被Swarm使用，这样的话Mesos集群整体的资源利用率将得到提升。注：这个新的改进可能会在Swarm的v1.1.3之后的某个版本release，如果哪位读者需要尝试这个新的特性，可以关注这个https://github.com/docker/swarm/pull/1946pull request。
　　这个特性主要支持以下几种使用场景：
　　Swarm集群的管理员可以配置Swarm集群来接收Mesos的revocable resource。Swarm的终端用户可以只选择非revocable资源来运行他们的高优先级任务。Swarm的终端用户可以优先考虑选择非revocable资源来运行他们的中优先级任务，如果没有非revocable资源可用，那么这些任务也可以选择revocable资源来运行。Swarm的终端用户可以只选择revocable资源来运行他们的低优先级任务。Swarm的终端用户可以优先考虑选择revocable资源来运行他们的低优先级任务。如果没有revocable资源可用，那么这些任务也可以选择非revocable资源来运行。Swarm的终端用户可以查看他们的container使用什么资源来运行的。
　　Swarm支持Revocable resource主要做了以下几个方面的改进：
　　在Swarm manage命令中新增一个cluster参数选项mesos.enablerevocable，通过将这个参数设置为true来使Swarm可以接收Mesos发送的revocable资源。当然按照Swarm之前的设计原则，你可以export SWARM_MESOS_ENABLE_REVOCABLE环境变量来替代那个参数选项。Mesos会定期的发送offer给Swarm，当Swarm接收到这些offer之后，需要修改对应Docker engine的资源类型，现在支持的有三种类型：Regular（表示这个节点上只有非revocable资源），Revocable（表示这个节点上只有revocable资源），Any（表示这个节点上即有非revocable资源，也有revocable资源），Unknown（表示这个节点的资源类型不确定，也就是这个节点上暂时没有可用的资源，这类节点如果没有正在运行的任务，它默认会被Swarm很快地删除）。根据Swarm所提供的constraint来使用revocable或者非revocable资源来创建任务。最常见的constraint写法有四种：
　　constraint:res-type==regular： 表示只使用非revocable资源来运行任务，如果没有非revocable资源，那么这个任务将会被放到任务队列中等待更多的非revocable资源，直到超时。constraint:res-type==~regular： 表示优先使用非revocable资源来运行任务，如果没有非revocable资源，那么选择使用revocable资源来执行。如果这两种资源都不够，这个任务将会被放到任务队列中等待Mesos发送更多的offer，直到超时。constraint:res-type==revocable： 表示只使用revocable资源来运行任务，如果没有revocable资源，那么这个任务将会被放到任务队列中等待更多的revocable资源，直到超时。constraint:res-type==~revocable： 表示优先使用revocable资源来运行任务，如果没有revocable资源，那么选择使用非revocable资源来执行。如果这两种资源都不够，这个任务将会被放到任务队列中等待Mesos发送更多的offer，直到超时。constraint:res-type==＊： 表示可以使用任何类型的资源来运行任务，如果revocable资源和非revocable资源都不够，那么这个任务将会被放到任务队列中等待Mesos发送更多的offer，直到超时。
　　几个细节需要特别注意：
　　由于Swarm的constraint支持正则表达式，所以当指定的正则表达式同时满足使用revocable和非revocable的资源，那么我们默认优先使用非revocable的资源来运行任务，如果非revocable的资源不够用，我们才会使用revocable资源运行任务。在Swarm对使用revocable资源的设计中，同一个任务不支持即使用revocable资源又使用非revocable资源。但是Mesos的这种限制只是局限于同一类型的资源，也就是说在Mesos中，不同类型的资源是可以混用的。个人认为Mesos的这种设计不是很合理，原因是，主要某个任务使用了revocable资源，那么它就会被当作revocable任务，可以被Qos控制器杀掉，根本就不会考虑它所使用的非revocable资源。在Swarm中创建container的时候，同一个constraint是可以指定多次的，Swarm会把它当作各自不同的constraint来对待，一个一个进行过滤。但是在此设计中，我们不允许Swarm用户指定多个res-type，如果指定多个，创建container将会失败。Mesos现在的设计是将非revocable资源和revocable资源放在了同一个offer中发给上层framework的，也就是说当Swarm收到offer之后，需要遍历offer中的每个资源来查看它的类型，来更新对应Docker engine的资源类型。在创建容器的时候，需要遍历某个节点上的所有的offer来计算所需要的资源，这可能会带来性能上的问题。比较庆幸的是，Mesos正在考虑对这个行为作出改进，也就是把revocable资源和非revocable资源用不同的offer来发送，也就说到时候framework收到的offer要么全是revocable资源，要么全是非revocable资源，这样的话就可以提高Swarm计算资源的性能。顺便说一下，Mesos做这个改进的出发点是考虑到rescind offer的机制，因为rescind offer是以整个offer为单位回收资源的，如果我们把revocable资源和非revocable资源放到一个offer进行发送，那么回收revocable资源的时候，不可避免的会同时回收非revocable资源。
　　下边我将带领大家进行实战，用Swarm使用Mesos的revocable资源。在进行之前，我建议读者先看看和这篇文章相关的前两篇《Swarm和Mesos集成指南－原理剖析》和 《Swarm和Mesos集成指南－实战部署》。
　　为了简化环境部署的复杂度，使读者可以轻松地在自己的环境上体验以下这个新的特性，我提供了三个Docker Image，读者可以很轻松的使用这三个Image 搭建起体验环境。
　　1.准备三台机器，配置好网络和DNS服务，如果没有DNS服务，可以直接配置/etc/hosts，使这三台机器可以使用机器名相互访问。我使用的是三台Ubuntu 14.04的机器：
　　wangyongqiao-master.grady.com
　　wangyongqiao-slave1.grady.com
　　wangyongqiao-slave2.grady.com
　　2.在wangyongqiao-master.grady.com上执行以下Docker Run命令启动Zookeeper节点，用作Mesos集群的服务发现，在这里我们直接使用mesoscloud提供的zookeeper镜像。
　　＃ docker run –privileged –net=host -d mesoscloud/zookeeper
　　其实这一步不是必须的，但是如果你的Mesos集群不使用Zookeeper，在Swarm使用的依赖库mesos-go有一个问题会导致Mesos Master重启或者failover之后，Swarm manage不会向Mesos重新注册（re-register），需要用户重新启动swarm manage节点，这会导致它之前运行的所有任务都变成了孤儿任务。我在Swarm社区已经创建了一个issue来跟踪这个问题，具体的情况和重现步骤你可以参考：https://github.com/docker/swarm/issues/1730。
　　3.在wangyongqiao-master.grady.com上执行以下Docker Run命令启动Mesos Master服务。这里使用我提供了一个Mesos Master的Image：
　　# docker run -d \ -v /opt/mesosinstall:/opt/mesosinstall \ --privileged \ --name mesos-master --net host gradywang/mesos-master \ --zk=zk://wangyongqiao-master.grady.com:2181/mesos
　　因为对于从事Mesos开发的人来说，经常性的修改Mesos的代码是不可避免的事情，所以为了避免每次改完代码都要重新build Docker镜像，在我提供的镜像中，其实并不包含Mesos的bin包，你在使用这个镜像之前必须先在本地build你的Mesos，然后执行make install把你的Mesos按照到某个空的目录，然后把这个目录mount到你的Mesos master容器中的/opt/mesosinstall目录。 具体的步骤你可以参考网上的这篇文章《Swarm和Mesos集成指南－实战部署》。
　　本例中，我把Mesos build完成之后安装在了本地的/opt/mesosinstall目录：
　　# make install DESTDIR=/opt/mesosinstall# ll /opt/mesosinstall/usr/local/total 36drwxr-xr-x 9root root 4096Jan 1520:02./ drwxr-xr-x 3root root 4096Jan 1519:44.。/ drwxr-xr-x 2root root 4096Mar 1813:30bin/ drwxr-xr-x 3root root 4096Jan 1520:02etc/ drwxr-xr-x 5root root 4096Mar 1813:30include/ drwxr-xr-x 5root root 4096Mar 1813:31lib/ drwxr-xr-x 3root root 4096Jan 1520:02libexec/ drwxr-xr-x 2root root 4096Mar 1813:31sbin/ drwxr-xr-x 3root root 4096Jan 1520:02share/
　　4.在wangyongqiao-slave1.grady.com和wangyongqiao-slave2.grady.com上执行以下命令，启动Mesos Salve服务。这里使用我提供了一个Mesos Slave的Image：
　　# docker run -d \-v /opt/mesosinstall:/opt/mesosinstall \ --privileged \-v /var/run/docker.sock:/var/run/docker.sock \ --name mesos-slave --net host gradywang/mesos-slave \--master=zk://wangyongqiao-master.grady.com:2181/mesos \--resource_estimator=“org_apache_mesos_FixedResourceEstimator” \--modules=‘{“libraries”： { “file”： “/opt/mesosinstall/usr/local/lib/libfixed_resource_estimator-0.29.0.so”， “modules”： { “name”： “org_apache_mesos_FixedResourceEstimator”， “parameters”： { “key”： “resources”， “value”： “cpus:4”} } } }’
　　在使用gradywang/mesos-slave这个镜像之前，必须注意以下这几点：
　　a.像上一步一样，我们假设你已经手动build，并安装了你的Mesos在/opt/mesosinstall目录下，当然你可以只需要在wangyongqiao-master.grady.com这个机器上构建你的Mesos，然后在wangyongqiao-master.grady.com机器上按照NFS服务，把安装目录/opt/mesosinstall挂载到其他的两个计算节点上，具体的步骤你可以参考网上的这片文章《Swarm和Mesos集成指南－实战部署》。
　　b.因为我们要演示怎么用在Swarm上使用Mesos提供的revocable资源，所以我们使用了Mesos默认提供的Fixed estimator，它是Mesos提供用来模拟计算revocable资源的一个工具，可以配置系统中固定提供的revocable资源。上例中我们默认在每个机器上配置4个CPU作为这个机器的revocable资源。
　　5.在wangyongqiao-master.grady.com上执行以下Docker Run命令启动Docker Swarm mange服务。这里使用我提供了一个Swarm的Image：
　　# docker run -d \ --net=host gradywang/swarm-mesos \ --debug manage \ -c mesos-experimental \ --cluster-opt mesos.address=192.168.0.2\ --cluster-opt mesos.tasktimeout=10s \ --cluster-opt mesos.user=root \ --cluster-opt mesos.offertimeout=10m \ --cluster-opt mesos.port=3375\ --cluster-opt mesos.enablerevocable=true\ --host=0.0.0.0:4375zk://wangyongqiao-master.grady.com:2181/mesos
　　注意：
　　在启动Swarm Manage的时候，我们使用了mesos.enablerevocable=true cluster 选项，这个选项是在这个patch中新增的，设置为true，表示Swarm愿意使用mesos的revocable资源。为了考虑向后的兼容性，如果你不指定这个选项，像往常一样启动Docker Swarm的时候，Swarm将默认不会接收Mesos的revocable资源。当然了，你可以像其他的参数一样，通过export这个变量SWARM_MESOS_ENABLE_REVOCABLE来设置。
　　192.168.0.2是wangyongqiao-master.grady.com机器的IP地址，Swarm会检查mesos.address是不是一个合法的IP地址，所以不能使用机器名。
　　gradywang/swarm-mesos这个镜像在Docker Swarm v1.1.3版本之上主要包含了四个新的特性：
　　支持了Mesos rescind Offer机制，相关的pull request是：https://github.com/docker/swarm/pull/1866。这个添加的特性有助于，在Mesos集群中的某个计算节点宕机之后，它上边的offer在Swarm中立即会被删除，不会在Swarm info中显示不可用的offer信息。支持Swarm用一个特定的role来注册Mesos。在之前的版本中，Swarm只能使用Mesos默认的role（＊）来注册。相关的pull request是：https://github.com/docker/swarm/pull/1890。支持Swarm使用reserved资源来创建容器。在Swarm支持了用特定的role注册之后，我们就可以使用Mesos的static／dynamic reservation来给Swarm提前预定一些资源。这些资源只能给Swarm使用。现在的行为是，当Swarm的用户创建容器的时候，我们会默认的优先使用reserved资源，当reserved资源不够的时候，我们会用部分的unreserved资源弥补。相关的pull request是：https://github.com/docker/swarm/pull/1890。支持Swarm使用revocable资源。这将是本文重点演示的特性。相关的pull request是：https://github.com/docker/swarm/pull/1946。
　　6.查看Docker Info：
　　# docker -H wangyongqiao-master.grady.com:4375 infoContainers:0Running： 0Paused： 0Stopped： 0Images:6Server Version： swarm/1.1.3Role:primary Strategy:spread Filters:health， port， dependency， affinity， constraint Offers:2Offer： eba7f1e4-36ca-4a2f-9e24-e8cffce7393a-S0》》eba7f1e4-36ca-4a2f-9e24-e8cffce7393a-O0 └ cpus： 2└ mem： 2.851GiB └ disk： 29.79GiB └ ports： 31000-32000└ cpus（Revocable）： 4└ Labels： executiondriver=native-0.2， kernelversion=3.13.0-32-generic， operatingsystem=Ubuntu 14.04.1LTS， res-type=any， storagedriver=aufs Offer： eba7f1e4-36ca-4a2f-9e24-e8cffce7393a-S1》》eba7f1e4-36ca-4a2f-9e24-e8cffce7393a-O1 └ cpus： 2└ mem： 2.851GiB └ disk： 29.79GiB └ ports： 31000-32000└ cpus（Revocable）： 4└ Labels： executiondriver=native-0.2， kernelversion=3.13.0-32-generic， operatingsystem=Ubuntu 14.04.1LTS， res-type=any， storagedriver=aufs Plugins:Volume： Network： Kernel Version： 3.13.0-32-generic Operating System： linux Architecture:amd64 CPUs:12Total Memory： 5.701GiB Name:wangyongqiao-master.grady.com
　　从上边的信息我们可以观察到，每个机器上都收到了四个revocable的CPU，每个机器的res－type都是any，它代表他们上边既有regular资源，又有revocable资源。
　　7.下边我们演示上边所提到的那几个user casees。
　　Swarm的用户可以只选择regular的资源来运行他们的高优先级的任务：
　　＃ docker -H wangyongqiao-master.grady.com:4375 run -d -e constraint:res-type==regular –cpu-shares 2 ubuntu:14.04 sleep 100
　　可以用以上的命令连续创建三个contianer，每个container使用两个regular的CPU，当创建第三个的时候，由于所有的regular CPU资源都被前两个使用，所以第三个会因为缺乏可用的regular资源而失败（执行超时）。
　　Swarm的用户可以优先选择regular的资源来运行他们的中优先级的任务，如果没有足够的regular资源，也可以用revocable资源来运行这个任务：
　　＃ docker -Hwangyongqiao-master.grady.com:4375run -d-econstraint:res-type==～regular --cpu-shares2ubuntu:14.04sleep 100
　　可以用以上的命令连续创建三个contianer，每个container使用两个regular的CPU，当创建第三个的时候，由于所有的regular CPU资源都被前两个使用，所以第三个任务会使用revocable资源来创建。
　　• Swarm的用户可以只选择revocable的资源来运行他们的低优先级的任务，把regular的资源预留来执行后续的高优先级任务：
　　＃ docker -Hwangyongqiao-master.grady.com:4375run -d-econstraint:res-type==revocable --cpu-shares2ubuntu:14.04sleep 100
　　可以用以上的命令连续创建五个contianer，每个container使用两个regular的CPU，当创建第五个的时候，由于所有的revocable CPU资源都被前四个使用，所以第五个会因为缺乏可用的revocable资源而失败（执行超时）。
　　Swarm的用户可以优先选择revocable的资源来运行他们的中优先级的任务，如果没有足够的revocable资源，也可以用regular资源来运行这个任务：
　　＃ docker -Hwangyongqiao-master.grady.com:4375run -d-econstraint:res-type==～revocable --cpu-shares2ubuntu:14.04sleep 100
　　可以用以上的命令连续创建五个contianer，每个container使用两个regular的CPU，当创建第五个的时候，由于所有的revocable CPU资源都被前四个使用，所以第五个会使用regular的资源来创建。
　　Swarm的终端用户可以通过docker inspect来查看他们之前运行的contianer使用的是revocable资源还是regular资源：
　　# docker -H gradyhost1.eng.platformlab.ibm.com:4375inspect --format “{{json .Config.Labels}}”22a8a06ccf5e {“com.docker.swarm.constraints”：“［\”res-type==revocable\“］”，“com.docker.swarm.mesos.detach”：“true”，“com.docker.swarm.mesos.name”：“”，“com.docker.swarm.mesos.resourceType”：“Revocable”，“com.docker.swarm.mesos.task”：“e93593367025”}
　　此文出自我个人的见解，非常期待读者的校正和启示。
　　IBM Platform DCOS作为Mesos社区的主要贡献组织，结合自身在资源调度方面丰富的实践应验，正在对Mesos资源的调度模块（Mesos Allocator）进行不断的优化，而且通过将自己的资源调度组件EGO与Mesos集成，为Mesos上层framework提供了更多的调度策略和更加友好的策略配置界面，同时，结合EGO丰富的资源调度策略，IBM platform DCOS丰富了Mesos的Revocable类型的资源，进一步提高了Mesos的资源利用率，通过Mesos-EGO，上层的framework基本可以看到整个集群的资源全貌，通过EGO界面的配置调度策略，合理高效的解决了资源申请冲突的问题，这些改进会对企业级用户带来新的Mesos体验。