【編者按】Apache Mesos作為一個非常優(yōu)秀的分布式資源管理和調(diào)度系統(tǒng)，如何高效的管理和分配資源，必然成為它研究和努力的主要方向之一。本文是基于IBM Platform DCOS Team在資源調(diào)度領(lǐng)域的優(yōu)秀經(jīng)驗，以及他們在Mesos社區(qū)為提升Mesos資源利用率而正在進行的實踐活動，深度剖析了Mesos資源的收集和調(diào)度原理，以及如何在Mesos中提供Revocable資源來提高Mesos數(shù)據(jù)中心的資源利用率。最后，作者結(jié)合自己在Docker Swarm社區(qū)的貢獻經(jīng)驗，重點講解了在Docker Swarm如何支持Mesos的Revocable資源。來自IBM Platform軟件工程師王勇橋?qū)怼癝warm和Mesos集成指南”系列文章，帶大家了解Swarm和Mesos集成的架構(gòu)和原理，Swarm基于Mesos集群的實戰(zhàn)部署和配置，以及基于IBM Platform自身在資源調(diào)度、分布式計算領(lǐng)域方面的實踐經(jīng)驗，向大家介紹IBM Platform對Mesos在資源調(diào)度方面的策略優(yōu)化，以及以Swarm為例向大家介紹這些優(yōu)化將對Mesos上層的framework和企業(yè)級用戶帶來哪些增強性的體驗。本文為第三篇：資源利用率優(yōu)化實踐。
　　Mesos集群資源收集
　　Apache Mesos是一種分布式的資源管理和調(diào)度框架，它被稱為是分布式系統(tǒng)的內(nèi)核。那么Mesos是怎么在這個分布式的異質(zhì)的環(huán)境中收集資源的呢？官方給出的架構(gòu)圖如下所示：
　　
　　默認情況下每一個Mesos Slave會主動采集它所在機器上的實際資源量， 現(xiàn)在默認情況下主要收集以下四種資源：
　　CPU： 默認調(diào)用系統(tǒng)函數(shù)os：：cpus（）來獲取系統(tǒng)CPU的個數(shù)，如果在某些特殊的平臺或者系統(tǒng)上獲取失敗，將采用默認值1。Memory：默認調(diào)用系統(tǒng)函數(shù)os：：memory（）來獲取系統(tǒng)內(nèi)存的大小，如果在某些特殊的平臺或者系統(tǒng)上獲取失敗，將采用默認值1GB。Disk：注意，每一個Slave它不是獲取整個機器的硬盤的大小，它默認調(diào)用系統(tǒng)函數(shù)fs：：size（flags.work_dir）來獲取Mesos Slave指定的工作目錄（Mesos Slave默認的工作目錄為/tmp/mesos，你可以通過在啟動Mesos slave的時候指定–work_dir參數(shù)來修改這個值）的文件系統(tǒng)的硬盤的大小。如果在某些特殊的平臺或者系統(tǒng)上獲取失敗，將采用默認值10GB；在獲取成功的情況下，如果獲取的值大于默認值10GB，則預(yù)留5GB留給Mesos slave本身使用，剩下的當(dāng)作此計算節(jié)點的存儲資源交給其他framework使用，如果小于默認值10GB，則將獲取值的一半預(yù)留，剩下的一半下的當(dāng)作此計算節(jié)點的存儲資源交給其他framework使用。Ports：默認使用默認值”［31000-32000］”。
　　當(dāng)然了你可以通過以下兩種方式改變默認的行為：
　　1.通過在啟動Mesos Slave時指定–resources參數(shù)來定義每個計算節(jié)點上可以消費的資源量。它的值有兩種格式：
　　第一種是分號分割的鍵值對字符串列表：“name（role）：value;name:value…”。name表示資源的名稱，例如可以是cpus，mem，disk和ports以及用戶自定義資源類型名稱等，role表示資源預(yù)留的角色（就是Mesos中的static reservation），如果不指定，則表示此資源預(yù)留給默認的role（通過—default-role參數(shù)指定，如果不指定，則表示Mesos默認的role（＊）），value表示此資源的值，現(xiàn)在支持的類型有主要有三種SCALAR數(shù)字類型，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這個參數(shù)它不會完全覆蓋默認的行為，也就是說只有你指定了某種具體的資源，它才會覆蓋這種具體資源的收集方式。例如你指定：–resources=”cpus（role1）：1;cpus（*）：2”，則表示，此計算節(jié)點總共有三個CPU，一個預(yù)留給role1，另兩個預(yù)留給默認的role（＊），其他的三種資源memory，disk，ports仍然按照默認的方式收集。
　　2.由于通過–resources的方式來指定某種資源，它需要你在啟動對應(yīng)的Mesos Salve的時候就知道具體的資源量，但是對于有些集成的系統(tǒng)，它的資源是由某些第三方的資源收集服務(wù)獲取的，比如Collectd。對于這種需求，Mesos同時提供了一種 hook的機制，來讓用戶實現(xiàn)自己的Moudle，定制他們收集資源的策略。
　　綜上所述，Mesos集群中的每一個Slave節(jié)點，通過以上的資源收集方式，將所有的資源在它注冊的時候上報給Master節(jié)點，Master將會利用它的資源調(diào)度策略，把這些資源以“Offer”的形式動態(tài)的分配給上層的framework，framework可以根據(jù)自身任務(wù)對資源的要求來選擇是否接收這個Offer，一旦這個Offer被接受，framework將通過Mesos Master的任務(wù)調(diào)度機制，將任務(wù)運行在數(shù)據(jù)中心的指定的Slave節(jié)點上。
　　Mesos集群資源調(diào)度策略
　　Apache Mesos能夠成為數(shù)據(jù)中心資源調(diào)度的內(nèi)核，一個非常重要的原因就是它能夠支持大多數(shù)framework的接入，那么Mesos要考慮的一個主要的問題就是如何為眾多的framework分配資源。在mesos中，這個功能是由Master中的一個單獨的模塊（Allocation module）來實現(xiàn)的，因為Mesos設(shè)計用來管理異構(gòu)環(huán)境中的資源，所以它實現(xiàn)了一個可插拔的資源分配模塊架構(gòu)，用戶可以根據(jù)自己的需求來實現(xiàn)定制化的分配策略和算法。
　　本章節(jié)將主要介紹Mesos默認的資源調(diào)度模塊DRF Allocator。官方默認給出了一個資源調(diào)度的流程圖，如下所示：
　　
　　DRF（Dominant Resource Fairness） Allocator，它的目標是確保每一個上層的Framework能夠接收到它最需資源的公平份額。下邊我們先簡單介紹一下DRF算法。在DRF中一個很重要的概念就是主導(dǎo)資源（dominant resource），例如對于運行計算密集型任務(wù)的framework，它的主導(dǎo)資源是CPU，對于運行大量依賴內(nèi)存的任務(wù)的framework，它的主導(dǎo)資源是內(nèi)存。DRF Allocator在分配資源之前，首先會按照資源類型計算每個framework占有（已經(jīng)使用的資源＋已經(jīng)以offer的形式發(fā)給framework但是還沒有使用的資源）份額百分比，占有比最高的為這個framework的主導(dǎo)資源，然后比較每個framework主導(dǎo)資源的百分比，哪個值小，則將這個機器上資源發(fā)給對應(yīng)的framework。你可以參考Benjamin Hindman的這篇論文https://www.cs.berkeley.edu/~alig/papers/drf.pdf來了解DRF算法的詳細說明。
　　另外，Mesos集群管理員可以通過以下幾種方式提供更多的資源分配策略：
　　給某個framework設(shè)置權(quán)重（weight）來使某個framework獲取更多的資源。可以使用static/dynamic reservation指定將某一個Slave節(jié)點上的資源發(fā)送給特定role下的framework。可以為某個role配置quota來保證這個role下的framework在整個Mesos集群中獲取資源的最小份額。Framework收到資源之后，可以創(chuàng)建持久化存貯卷，保證這些存儲資源不能被其他的framework使用。
　　使用Revocable資源來提高資源利用率
　　對于DRF的Allocator，在資源分配方面可能存在以下幾個方面的問題：
　　1.資源碎片的問題。由于DRF總是追求公平，它會把剩余資源公平的分配給所有的framework，但是這種公平分配可能會導(dǎo)致所有的framework在一個分配的周期中都沒有足夠的資源來運行它的任務(wù)。
　　2.本性貪婪的framework為了提高它自身的性能，有時候總試圖去hold offer，即便是它當(dāng)時沒有需要執(zhí)行的任務(wù)，那么這個時候，這些resource也不能分配給另外的framework使用。
　　3.對于gang-scheduing（同時申請一組資源）類型的應(yīng)用，由于Mesos在一個時刻只能提供集群的部分資源，那么這種類型的應(yīng)用可能需要等待比較長的時間才可以運行。
　　為了適當(dāng)?shù)奶岣進esos的資源利用率，Mesos社區(qū)現(xiàn)在引入了Revocable類型的資源。這種資源是一種可以被Mesos自行回收的資源，也就是說如果上層的framework使用這種資源來運行的它們的任務(wù)，那么這些任務(wù)就有隨時被殺掉的可能。它被設(shè)計主要用來運行一些可靠性要求比較低，無狀態(tài)的的任務(wù)。也就是說現(xiàn)在Mesos主要為上層的framework提供兩種資源：
　　? Non-revocable resources： Mesos提供的最常見的資源類型，一旦這種資源offer發(fā)給某個framework，那么這些資源永遠可以保證對這個framework可用，F(xiàn)ramework一旦用這種資源運行它的任務(wù)，那么這個任務(wù)所占用的資源不能被Mesos收回，除非framework主動殺掉任務(wù)或者任務(wù)結(jié)束。
　　? Revocable resources：這種資源是framework沒有充分利用的資源，Mesos會把這部分資源再發(fā)送給其他的framework使用，如果其他framework用這種resource運行任務(wù)，那么這個任務(wù)有可能在某個時候被Mesos殺掉來回收對應(yīng)的資源。這種資源主要運來執(zhí)行best-effort任務(wù)，例如后臺分析，視頻圖像處理，芯片模擬等一些低優(yōu)先級的任務(wù)。
　　首先Mesos在MESOS-354項目中初次引入了Revocable類型的資源，它是我們所說的其中一種Revocable類型的資源，它主要考慮的應(yīng)用場景是：在Mesos集群中，Mesos對資源的分配率一般可以達到80%以上，但實際的資源利用率卻低于20%。在這個項目中，它提供了一種資源的再分配機制，就是把臨時沒有使用的資源（這些資源已經(jīng)在之前分配給了某些任務(wù)，而且這些任務(wù)正在運行，但是它們沒有完全使用已經(jīng)分配給它們的資源）再分配給其他的任務(wù)。這種類型的revocable資源被稱為Usage Slack的資源，下邊我們來主要分析一下這種資源的生命周期：
　　第一步首先要確定哪些資源是Usage slack的revocable resource。每個Mesos Salve節(jié)點上的Resource estimator會定期和Resource Monitor模塊交互來計算Usage slack，如果前后兩次計算的值不同，則它會把這些revocable的資源上報給Mesos master。Mesos allocator會收到每個Slave上報的Usage slack的revocable resource，然后把這些revocable resource 發(fā)送給上層的framework。注：默認情況下framework是不接收revocable resource的，如果framework在注冊時候指定REVOCABLE_RESOURCES capability，那么它將可以收到revocable resource。Framework可以選擇使用這些revocable resource運行任務(wù)，這些revocable任務(wù)會像正常的任務(wù)一樣被運行在對應(yīng)的節(jié)點上。每個Slave上的Monitor會監(jiān)視原來task的運行狀況，如果它的運行負載提高，則Qos controller模塊會殺掉對應(yīng)的revocable task來釋放資源。
　　另外的一種Revocable資源則在MESOS-4967項目中引入，它主要由IBM Platform DCOS Team的工程師主導(dǎo)設(shè)計開發(fā)，目前基本的設(shè)計和編碼已經(jīng)完成，正在review階段，很快會在最近的Mesos版本中支持。它主要是考慮到在Mesos中有些資源某些role reserve，但是沒有被使用的情況（Allocation Slack），我們在后續(xù)的文章中會對其詳細介紹。
　　對于Revocable類型的資源，需要注意以下幾點：
　　Revocable資源不能動態(tài)的reserve；Revocable資源不能用來創(chuàng)建存儲卷；運行任務(wù)的時候，對同一種資源，revocable資源和non-revocable資源不能混用，但是不同類型的資源可以混用。比如CPU用revocable resource，Memory可以使用non-revocable資源。如果一個task使用了revocable資源或者它對應(yīng)的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 資源來運行他們低優(yōu)先級的任務(wù)，或者使用non-revocable 資源來運行他們的高優(yōu)先級任務(wù)。這樣的話，如果Swarm和其他的framework共享Mesos集群資源的時候，其他framework的未充分利用的資源將可以被Swarm使用，這樣的話Mesos集群整體的資源利用率將得到提升。注：這個新的改進可能會在Swarm的v1.1.3之后的某個版本release，如果哪位讀者需要嘗試這個新的特性，可以關(guān)注這個https://github.com/docker/swarm/pull/1946pull request。
　　這個特性主要支持以下幾種使用場景：
　　Swarm集群的管理員可以配置Swarm集群來接收Mesos的revocable resource。Swarm的終端用戶可以只選擇非revocable資源來運行他們的高優(yōu)先級任務(wù)。Swarm的終端用戶可以優(yōu)先考慮選擇非revocable資源來運行他們的中優(yōu)先級任務(wù)，如果沒有非revocable資源可用，那么這些任務(wù)也可以選擇revocable資源來運行。Swarm的終端用戶可以只選擇revocable資源來運行他們的低優(yōu)先級任務(wù)。Swarm的終端用戶可以優(yōu)先考慮選擇revocable資源來運行他們的低優(yōu)先級任務(wù)。如果沒有revocable資源可用，那么這些任務(wù)也可以選擇非revocable資源來運行。Swarm的終端用戶可以查看他們的container使用什么資源來運行的。
　　Swarm支持Revocable resource主要做了以下幾個方面的改進：
　　在Swarm manage命令中新增一個cluster參數(shù)選項mesos.enablerevocable，通過將這個參數(shù)設(shè)置為true來使Swarm可以接收Mesos發(fā)送的revocable資源。當(dāng)然按照Swarm之前的設(shè)計原則，你可以export SWARM_MESOS_ENABLE_REVOCABLE環(huán)境變量來替代那個參數(shù)選項。Mesos會定期的發(fā)送offer給Swarm，當(dāng)Swarm接收到這些offer之后，需要修改對應(yīng)Docker engine的資源類型，現(xiàn)在支持的有三種類型：Regular（表示這個節(jié)點上只有非revocable資源），Revocable（表示這個節(jié)點上只有revocable資源），Any（表示這個節(jié)點上即有非revocable資源，也有revocable資源），Unknown（表示這個節(jié)點的資源類型不確定，也就是這個節(jié)點上暫時沒有可用的資源，這類節(jié)點如果沒有正在運行的任務(wù)，它默認會被Swarm很快地刪除）。根據(jù)Swarm所提供的constraint來使用revocable或者非revocable資源來創(chuàng)建任務(wù)。最常見的constraint寫法有四種：
　　constraint:res-type==regular： 表示只使用非revocable資源來運行任務(wù)，如果沒有非revocable資源，那么這個任務(wù)將會被放到任務(wù)隊列中等待更多的非revocable資源，直到超時。constraint:res-type==~regular： 表示優(yōu)先使用非revocable資源來運行任務(wù)，如果沒有非revocable資源，那么選擇使用revocable資源來執(zhí)行。如果這兩種資源都不夠，這個任務(wù)將會被放到任務(wù)隊列中等待Mesos發(fā)送更多的offer，直到超時。constraint:res-type==revocable： 表示只使用revocable資源來運行任務(wù)，如果沒有revocable資源，那么這個任務(wù)將會被放到任務(wù)隊列中等待更多的revocable資源，直到超時。constraint:res-type==~revocable： 表示優(yōu)先使用revocable資源來運行任務(wù)，如果沒有revocable資源，那么選擇使用非revocable資源來執(zhí)行。如果這兩種資源都不夠，這個任務(wù)將會被放到任務(wù)隊列中等待Mesos發(fā)送更多的offer，直到超時。constraint:res-type==＊： 表示可以使用任何類型的資源來運行任務(wù)，如果revocable資源和非revocable資源都不夠，那么這個任務(wù)將會被放到任務(wù)隊列中等待Mesos發(fā)送更多的offer，直到超時。
　　幾個細節(jié)需要特別注意：
　　由于Swarm的constraint支持正則表達式，所以當(dāng)指定的正則表達式同時滿足使用revocable和非revocable的資源，那么我們默認優(yōu)先使用非revocable的資源來運行任務(wù)，如果非revocable的資源不夠用，我們才會使用revocable資源運行任務(wù)。在Swarm對使用revocable資源的設(shè)計中，同一個任務(wù)不支持即使用revocable資源又使用非revocable資源。但是Mesos的這種限制只是局限于同一類型的資源，也就是說在Mesos中，不同類型的資源是可以混用的。個人認為Mesos的這種設(shè)計不是很合理，原因是，主要某個任務(wù)使用了revocable資源，那么它就會被當(dāng)作revocable任務(wù)，可以被Qos控制器殺掉，根本就不會考慮它所使用的非revocable資源。在Swarm中創(chuàng)建container的時候，同一個constraint是可以指定多次的，Swarm會把它當(dāng)作各自不同的constraint來對待，一個一個進行過濾。但是在此設(shè)計中，我們不允許Swarm用戶指定多個res-type，如果指定多個，創(chuàng)建container將會失敗。Mesos現(xiàn)在的設(shè)計是將非revocable資源和revocable資源放在了同一個offer中發(fā)給上層framework的，也就是說當(dāng)Swarm收到offer之后，需要遍歷offer中的每個資源來查看它的類型，來更新對應(yīng)Docker engine的資源類型。在創(chuàng)建容器的時候，需要遍歷某個節(jié)點上的所有的offer來計算所需要的資源，這可能會帶來性能上的問題。比較慶幸的是，Mesos正在考慮對這個行為作出改進，也就是把revocable資源和非revocable資源用不同的offer來發(fā)送，也就說到時候framework收到的offer要么全是revocable資源，要么全是非revocable資源，這樣的話就可以提高Swarm計算資源的性能。順便說一下，Mesos做這個改進的出發(fā)點是考慮到rescind offer的機制，因為rescind offer是以整個offer為單位回收資源的，如果我們把revocable資源和非revocable資源放到一個offer進行發(fā)送，那么回收revocable資源的時候，不可避免的會同時回收非revocable資源。
　　下邊我將帶領(lǐng)大家進行實戰(zhàn)，用Swarm使用Mesos的revocable資源。在進行之前，我建議讀者先看看和這篇文章相關(guān)的前兩篇《Swarm和Mesos集成指南－原理剖析》和 《Swarm和Mesos集成指南－實戰(zhàn)部署》。
　　為了簡化環(huán)境部署的復(fù)雜度，使讀者可以輕松地在自己的環(huán)境上體驗以下這個新的特性，我提供了三個Docker Image，讀者可以很輕松的使用這三個Image 搭建起體驗環(huán)境。
　　1.準備三臺機器，配置好網(wǎng)絡(luò)和DNS服務(wù)，如果沒有DNS服務(wù)，可以直接配置/etc/hosts，使這三臺機器可以使用機器名相互訪問。我使用的是三臺Ubuntu 14.04的機器：
　　wangyongqiao-master.grady.com
　　wangyongqiao-slave1.grady.com
　　wangyongqiao-slave2.grady.com
　　2.在wangyongqiao-master.grady.com上執(zhí)行以下Docker Run命令啟動Zookeeper節(jié)點，用作Mesos集群的服務(wù)發(fā)現(xiàn)，在這里我們直接使用mesoscloud提供的zookeeper鏡像。
　　＃ docker run –privileged –net=host -d mesoscloud/zookeeper
　　其實這一步不是必須的，但是如果你的Mesos集群不使用Zookeeper，在Swarm使用的依賴庫mesos-go有一個問題會導(dǎo)致Mesos Master重啟或者failover之后，Swarm manage不會向Mesos重新注冊（re-register），需要用戶重新啟動swarm manage節(jié)點，這會導(dǎo)致它之前運行的所有任務(wù)都變成了孤兒任務(wù)。我在Swarm社區(qū)已經(jīng)創(chuàng)建了一個issue來跟蹤這個問題，具體的情況和重現(xiàn)步驟你可以參考：https://github.com/docker/swarm/issues/1730。
　　3.在wangyongqiao-master.grady.com上執(zhí)行以下Docker Run命令啟動Mesos Master服務(wù)。這里使用我提供了一個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開發(fā)的人來說，經(jīng)常性的修改Mesos的代碼是不可避免的事情，所以為了避免每次改完代碼都要重新build Docker鏡像，在我提供的鏡像中，其實并不包含Mesos的bin包，你在使用這個鏡像之前必須先在本地build你的Mesos，然后執(zhí)行make install把你的Mesos按照到某個空的目錄，然后把這個目錄mount到你的Mesos master容器中的/opt/mesosinstall目錄。 具體的步驟你可以參考網(wǎng)上的這篇文章《Swarm和Mesos集成指南－實戰(zhàn)部署》。
　　本例中，我把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上執(zhí)行以下命令，啟動Mesos Salve服務(wù)。這里使用我提供了一個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=‘{“l(fā)ibraries”： { “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.像上一步一樣，我們假設(shè)你已經(jīng)手動build，并安裝了你的Mesos在/opt/mesosinstall目錄下，當(dāng)然你可以只需要在wangyongqiao-master.grady.com這個機器上構(gòu)建你的Mesos，然后在wangyongqiao-master.grady.com機器上按照NFS服務(wù)，把安裝目錄/opt/mesosinstall掛載到其他的兩個計算節(jié)點上，具體的步驟你可以參考網(wǎng)上的這片文章《Swarm和Mesos集成指南－實戰(zhàn)部署》。
　　b.因為我們要演示怎么用在Swarm上使用Mesos提供的revocable資源，所以我們使用了Mesos默認提供的Fixed estimator，它是Mesos提供用來模擬計算revocable資源的一個工具，可以配置系統(tǒng)中固定提供的revocable資源。上例中我們默認在每個機器上配置4個CPU作為這個機器的revocable資源。
　　5.在wangyongqiao-master.grady.com上執(zhí)行以下Docker Run命令啟動Docker Swarm mange服務(wù)。這里使用我提供了一個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中新增的，設(shè)置為true，表示Swarm愿意使用mesos的revocable資源。為了考慮向后的兼容性，如果你不指定這個選項，像往常一樣啟動Docker Swarm的時候，Swarm將默認不會接收Mesos的revocable資源。當(dāng)然了，你可以像其他的參數(shù)一樣，通過export這個變量SWARM_MESOS_ENABLE_REVOCABLE來設(shè)置。
　　192.168.0.2是wangyongqiao-master.grady.com機器的IP地址，Swarm會檢查mesos.address是不是一個合法的IP地址，所以不能使用機器名。
　　gradywang/swarm-mesos這個鏡像在Docker Swarm v1.1.3版本之上主要包含了四個新的特性：
　　支持了Mesos rescind Offer機制，相關(guān)的pull request是：https://github.com/docker/swarm/pull/1866。這個添加的特性有助于，在Mesos集群中的某個計算節(jié)點宕機之后，它上邊的offer在Swarm中立即會被刪除，不會在Swarm info中顯示不可用的offer信息。支持Swarm用一個特定的role來注冊Mesos。在之前的版本中，Swarm只能使用Mesos默認的role（＊）來注冊。相關(guān)的pull request是：https://github.com/docker/swarm/pull/1890。支持Swarm使用reserved資源來創(chuàng)建容器。在Swarm支持了用特定的role注冊之后，我們就可以使用Mesos的static／dynamic reservation來給Swarm提前預(yù)定一些資源。這些資源只能給Swarm使用。現(xiàn)在的行為是，當(dāng)Swarm的用戶創(chuàng)建容器的時候，我們會默認的優(yōu)先使用reserved資源，當(dāng)reserved資源不夠的時候，我們會用部分的unreserved資源彌補。相關(guān)的pull request是：https://github.com/docker/swarm/pull/1890。支持Swarm使用revocable資源。這將是本文重點演示的特性。相關(guān)的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的資源來運行他們的高優(yōu)先級的任務(wù)：
　　＃ docker -H wangyongqiao-master.grady.com:4375 run -d -e constraint:res-type==regular –cpu-shares 2 ubuntu:14.04 sleep 100
　　可以用以上的命令連續(xù)創(chuàng)建三個contianer，每個container使用兩個regular的CPU，當(dāng)創(chuàng)建第三個的時候，由于所有的regular CPU資源都被前兩個使用，所以第三個會因為缺乏可用的regular資源而失敗（執(zhí)行超時）。
　　Swarm的用戶可以優(yōu)先選擇regular的資源來運行他們的中優(yōu)先級的任務(wù)，如果沒有足夠的regular資源，也可以用revocable資源來運行這個任務(wù)：
　　＃ docker -Hwangyongqiao-master.grady.com:4375run -d-econstraint:res-type==～regular --cpu-shares2ubuntu:14.04sleep 100
　　可以用以上的命令連續(xù)創(chuàng)建三個contianer，每個container使用兩個regular的CPU，當(dāng)創(chuàng)建第三個的時候，由于所有的regular CPU資源都被前兩個使用，所以第三個任務(wù)會使用revocable資源來創(chuàng)建。
　　? Swarm的用戶可以只選擇revocable的資源來運行他們的低優(yōu)先級的任務(wù)，把regular的資源預(yù)留來執(zhí)行后續(xù)的高優(yōu)先級任務(wù)：
　　＃ docker -Hwangyongqiao-master.grady.com:4375run -d-econstraint:res-type==revocable --cpu-shares2ubuntu:14.04sleep 100
　　可以用以上的命令連續(xù)創(chuàng)建五個contianer，每個container使用兩個regular的CPU，當(dāng)創(chuàng)建第五個的時候，由于所有的revocable CPU資源都被前四個使用，所以第五個會因為缺乏可用的revocable資源而失敗（執(zhí)行超時）。
　　Swarm的用戶可以優(yōu)先選擇revocable的資源來運行他們的中優(yōu)先級的任務(wù)，如果沒有足夠的revocable資源，也可以用regular資源來運行這個任務(wù)：
　　＃ docker -Hwangyongqiao-master.grady.com:4375run -d-econstraint:res-type==～revocable --cpu-shares2ubuntu:14.04sleep 100
　　可以用以上的命令連續(xù)創(chuàng)建五個contianer，每個container使用兩個regular的CPU，當(dāng)創(chuàng)建第五個的時候，由于所有的revocable CPU資源都被前四個使用，所以第五個會使用regular的資源來創(chuàng)建。
　　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社區(qū)的主要貢獻組織，結(jié)合自身在資源調(diào)度方面豐富的實踐應(yīng)驗，正在對Mesos資源的調(diào)度模塊（Mesos Allocator）進行不斷的優(yōu)化，而且通過將自己的資源調(diào)度組件EGO與Mesos集成，為Mesos上層framework提供了更多的調(diào)度策略和更加友好的策略配置界面，同時，結(jié)合EGO豐富的資源調(diào)度策略，IBM platform DCOS豐富了Mesos的Revocable類型的資源，進一步提高了Mesos的資源利用率，通過Mesos-EGO，上層的framework基本可以看到整個集群的資源全貌，通過EGO界面的配置調(diào)度策略，合理高效的解決了資源申請沖突的問題，這些改進會對企業(yè)級用戶帶來新的Mesos體驗。
?