【編者按】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體驗。
?

普通下載普通下載

相關電子資料下載