今天主要為大家介紹下mesos社群，分享mesos最近釋出的一些新功能，以及未來會做的一些項目。
1 mesos社群介紹
mesos是apache下的開源分布式資源管理架構，它被稱為是分布式系統的核心，是dcos，也就是我們通常所說的資料中心作業系統的的基礎。mesos最初是由加州大學伯克利分校的amplab開發的。
我們可以看到2014年參加mesos conf的是260多人，2015年在西雅圖一下漲到了700多人，是以mesos在2015年是發展迅猛的一年。現在在mesos社群貢獻代碼的主要是mesospher，twitter，ibm和intel，大多數committer都來自這mesospher和twitter。但是現在twitter的好幾個工程師都跳到了mesosphere，同時mesospher也有幾個工程師跳到了intel，現在ibm在社群逐漸發力，從目前代碼的送出量和參與人員來看，已經成為第二大貢獻者。
還有一點就是我經常把mesos社群和openstack社群做一些比較，mesos和openstack到現在都已經發展5年多了，openstack峰會上次的人數是将近7000人，mesos才700來人，但是我仔細想了下，其實也不奇怪。openstack項目很多，有十幾個核心項目，分攤下來的話，其實一個項目大概也就對應6,700人，這麼一想的話，其實mesos社群還是挺活躍的。
mesos的生态系統在2015年發展也很快，出現了好多新的mesos使用者和新的mesos framework。并且好多公司都在基于mesos開發自己的framework，包括vmware，cisco，huawei，蘋果等等。個人感覺是，對于mesos，大家更看中的是上層的framework，如何讓上層的framework來最大化的把mesos用好，是好多公司一直在探索的，這些探索産生的一些需求又推進了mesos，形成一個良性循環。
這個圖很形象的描述了mesos生态系統的發展曆程：
左上角是基于mesos産生一些商業化的産品，服務，來幫助使用者提供dcos的功能。
左下角就是使用者在使用的時候，會有一些特殊定制的需求，服務提供商需要根據這些需求提供解決方案。
右邊這一步就是說如果是一些很common的解決方案的話，就需要把這些方案貢獻給社群。
然後就進入下一輪疊代開發：改進産品，提供解決方案，貢獻社群，其實這個和openstack的開發流程基本上是一樣的，都分為這三步。
新應用的話，主要是mesos和越來越多的framework開始繼承了，包括kibana，kafka，k8s，cassandra, swarm等等，另外一個值得注意的是華為貢獻了他們的cloudfoundry的framework，雖然現在還處在一個原型階段，但是cloudfoundry和mesos內建又為mesos生态圈添加了一員大将，我覺得如果有人在基于cloudfoundry做paas的，可以對cloudfoundry和mesos做一些調研，他們的內建能夠讓使用者的資料中心資源使用更加充分。
2mesos社群最近釋出的一些新功能
接下來我們看下mesos社群在最近一些版本釋出的新功能，mesos 0.27馬上釋出，現在已經開始了0.28的開發，至于什麼時候到1.0，這個不好說。
1. resources/attributes discovery (mesos-3366)
在一個異構的計算環境中，客戶在運作作業的時候，有時候對硬體有一些特定的需求，例如gpu，網卡類型，cpu架構，作業系統版本等等，但是這些屬性，mesos agent在啟動的時候，都不會主動上報給mesos master節點的，使用者雖然可以通過—resources —attribute等flag在mesos agent啟動的時候指定一些屬性值，但是這樣做的缺點是如果換了一台agent，這些屬性值可能需要改變，不便于移植。是以社群就做了這個項目，能夠實作讓使用者在mesos agent啟動的時候，指定一些專門做資源搜集，資源發現的一些hook腳本，讓這些腳本幫忙搜集mesos agent上使用者需要的指定資源，使用者需要做的就是按照mesos的需要寫一些資源搜集，資源發現的插件，在mesos agent啟動的時候作為參數傳給mesos agent，就可以通過這些hook把使用者需要的資源搜集上來，同時這些插件可以在不同的mesos agent上去使用，使用者不需要改代碼，直接就可以運作。
2. quota (mesos-1791)
quota主要是用來做資源預留的，和mesos的dynamic/static reservation比較像，都是為某個role去預留一些資源，但是dynamic/static reservation的資源預留主要是host級别的，但是quota的資源預留是叢集級别的，一旦資源被某個role通過quota預留後，這些資源就不能分給别的role去使用了。通常在我們提到quota的時候，會主要關心兩個值：quota的minimal guarantee和quota的maximal limit。現在mesos的quota支援隻做了minimal guarantee，未來會加入對quota maximal limit的支援。
quota支援的場景主要是當使用者的一些framework開發完成後，可能需要運作一些很critical的作業，使用者期望這些作業在送出後，能馬上運作，不用等其它的framework釋放資源。對于這種framework的作業，使用者可以為目前的framework的role設定一個quota，然後當使用者的作業運作的時候，可以馬上得到自己通過quota預留的資源，保證使用者作業的sla。設定quota的前提是目前系統必須有足夠的資源或者足夠的沒有被使用的offer，如果系統有足夠的空閑資源，使用者可以直接預留這些空閑資源；如果空閑資源不夠的話，mesos會通過去decline一些沒有使用的offer，也就是我們通常所說的outstanding offer來增加一些系統的空閑資源，保證quota的設定可以成功。
3.implicit role (mesos-3988)
有這個項目的主要原因是靜态配置role的一些局限。在沒有implicit role之前，在mesos master啟動的時候，需要通過—roles flag指定目前mesos叢集可用的role。目前方案的主要缺點是mesos叢集的role是靜态的，不能動态的變化，這種配置很不靈活。
例如當使用者在目前的mesos叢集添加一個新的framework，并且這個framework用的是一個新的role，這種情況下，就需要系統管理者重新開機mesos master，在mesos master重新開機時，在—roles flag加入即将加入的framework的role，才能保證mesos master能夠認識新的framework的role，保證新的framework可以成功注冊。
在引入了implicit role的功能後，使用者在mesos master啟動的時候好，可以不指定任何的role，所有role的都是預設建立的，例如在使用者注冊framework或者設定quota的時候，如果目前叢集沒有framework或者quota需要的role，mesos會自動建立這些role，當這些framework被删除時，如果目前被删的framework的role沒有任何framework使用時，這個role就會被删掉。通過implicit role簡化了使用者建立，注冊新的framework的流程。
4. oversubscription (usage slack/allocation slack mesos-1607)
我們可以通過這張圖介紹下mesos中的資源超售，這張圖主要是描述了一個agent上的所有的資源類型。資源超售現在分兩類，第一類是usage slack的資源超售，第二個是allocation slack的資源超售。接下來詳細介紹這兩種超售類型。
資源超售主要是在可撤銷的資源上利用暫時沒有使用的資源來運作tasks/executors，而 mesos 可以随時撤銷任務。mesos可以利用資源超售提升系統的資源使用率。
對于usage slack類型的資源超售，它有兩個插件來控制：資源估算和服務品質（qos）控制，同時對現有的資源進行配置設定、資源螢幕和 mesos slave 進行了擴充。
reserved resources resources：預留資源，主要有兩類，一類是靜态預留，一類是動态預留。靜态預留可以在mesos agent啟動的時候通過“--resources”參數設定。動态預留有兩種方式去設定。第一個方法是通過framework在運作時，動态的為目前的framework預留一些資源。第二個是使用者可以通過http endpoint直接在某個agent上為某個role去預留一些資源。
allocated resources resources: 已經配置設定的資源，主要包含兩類，第一類是已經被framework接受用于執行作業的資源，第二類是被outstanding offer所占用的那些資源。
revocable resources resources：可撤銷回收或者可被搶占的資源。現在revocable的資源可以分兩類：usage slack和allocation slack，目前的邏輯這兩類資源都是通過agent去殺掉使用這類資源的executor來釋放資源。
reservation slack：主要是指agent上總的資源和這個agent上預約的資源內插補點，這部分資源主要是作為unreserved resource供其它role去使用。
allocation slack： 預留資源和實際配置設定預留資源的內插補點。預留資源減掉實際配置設定預留資源即為allocation slack，這部分資源可以被借給其他的role去使用，在目前的role有新作業時，會對借出去的資源進行回收。這個項目現在還在進行中，感興趣的可以看下mesos-1607.
usage slack：實際配置設定的資源和實際使用的資源內插補點，舉個例子，mesos分給某個executor/task 10個cpus，但是實際當這個task在運作的時候，隻是用了60%的cpus，那麼我們就可以把剩餘的沒用的40%作為usage slack彙報給mesos allocator對這部分資源進行重新排程。當然因為usage slack都是通過plugin的形式去做的，使用者可以根據自己的需求寫自己的resources estimator和qos controller來對usage slack進行處理。
3mesos社群計劃做的項目
1. quota enhancement mesos-4392
目前quota的實作有一些缺陷可能會導緻系統的資源使用率不高，例如一個role的quota設定為cpus：100；mem：2048，但是當在真正使用的時候，這個role可能隻有cpus：30；mem：1024被framework去使用了，剩下的cpus：70；mem：1024因為quota的限制，不能被其它的role去使用，造成了資源浪費。是以社群目前有個項目計劃對quota做一些改進，加入一種新的revocable resources，名字還沒定，但是我估計可能會叫quota slack，就是被quota預留的但是沒有被配置設定出去的資源，這部分資源可以作為revocable resources，借給其它的role去使用，提升系統的資源使用率。當借出去資源的role又有新的資源請求時，會通過殺掉一些使用quota slack的executor來釋放資源。
2. optimistic offer mesos-1607
需要這個功能的主要原因是，現在所有的offer都是pessimistic offer，所謂的pessimistic offer就是說當一個offer被發給framework後，就被目前的framework鎖定了，其它的famework都不能使用這個offer，隻有當在這個offer上launch完task後，framework把目前offer剩餘的資源傳回給allocator後，這個offer才能被下一個framework去使用。optimistic offer主要是想當mesos allocator發出去一個offer時，多個framework可以同時競争這個resources， 誰搶到這個offer，這個offer就可以為誰所用。這樣做的好處是。。。。
3. multi-role framework mesos-1763
目前mesos一個framework隻能使用一個role上的資源，如果一個framework在注冊的時候沒有指定role，那它就會用預設的role(*)，role的主要作用是：
1）首先是每個role都會有個weight,如果一個role的weight比較高的話，那麼在mesos allocator進行資源配置設定的時候，weight高的會按照drf配置設定政策拿到比較多的資源。
2）資源預留：資源預留主要是通過role去做的，每個role可以靜态或者動态的去預留一些資源。
3） 資源配額：每個role可以配置一個資源配額，這個配額是cluster級别的。
如果一個framework隻有一個role的話，對于meta-framework會有一個問題。所謂的meta-framework就是這個framework可以再管理一堆其它的framework，marathon就是一個很典型的meta-framework，我們可以通過marathon管理spark，kubernets，swarm等framework。但是因為現在一個framework隻能有一個role，是以即使marathon可以管理多個framework，目前意義也不是太大，因為所有的framework共享同一個role，資源配置設定，利用都不是很有效率。是以現在一個workaround的方法是每個marathon隻管理一個framework。
如果引入了multiple role支援後，我們就可以給marathon設定多個role，被marathon管理的framework可以每個使用一個role，這樣marathon就可以把不同role的資源配置設定給上層的framework，提升了資源配置設定，共享的效率。
4. fine grained resource offer mesos-3765
所謂的細粒度的resource offer，主要是相對于現在的mesos offer來說的，目前的mesos allocator在給framework發offer的時候，都是粗力度的。所謂的粗力度就是在給上層的framework配置設定resources offer的時候，總是把某個agent上所有的所有資源發給上層的某個framework。也就是說某個agent在某一時刻隻能作為一個framework的offer。目前這種粗力度的offer配置設定導緻的主要問題是在某些情況下，可能會導緻一些framework拿不到資源。一個例子就是一個mesos叢集有少量的很強大的agent和大量greedy的framework，framework的數量多于agent的數量，在這種情況下，會導緻一些framework拿不到資源運作作業。
如果mesos的allocator能按照細粒度的方式對資源進行配置設定，那麼就可以把一個agent上的resource作為多個offer分發給上層的多個framework，保證上層的framework能對資源共享，不會因為某些貪婪的framwork導緻其他的framwork不能運作。
關于這個項目的方案，現在還在讨論，有人建議看能不能讓framework直接把請求發給mesos，然後mesos直接把目前framework需要的資源發給它就完了。社群的回報是，如果讓framework主動申請資源，可能會導緻一些貪婪的framework或者一些使用者寫的有bug的framework把系統資源都占了，導緻其他的framework不能運作。另外一個方案是mesos master在啟動時，指定offer的大小，mesos allocator在發offer的時候，會按照制定的offer的大小發offer，這個方案可能會被采納。
5. unified container mesos-2840
docker是mesos的一等公民，是以mesos社群最近在對docker內建作比較大的改進，“unified container”是xxxxxxx
mesos的所有設計文檔
https://cwiki.apache.org/confluence/display/mesos/design+docs+--+shared+links，大家可以通過這個連結拿到基本上所有mesos的設計文檔，可以挑幾個感興趣的看看，了解下mesos的工作原理。
ibm platform computing & mesos
最後想跟大家介紹下ibm在mesos基礎上研發的mesos connector，mesos connector主要是使mesos內建了ibm platform computing的ego強大的資源共享，資源排程政策，為mesos提前加入了社群現在還沒有的資源搶占，optimistic offer的功能。
ibm mesos conenctor的主要特點如下：
1）豐富的資源共享政策
ibm platform computing ego 是一個企業級的資源排程系統，為使用者提供豐富的資源共享政策，使用者可以根據自己的需求定義自己自然配置設定計劃。mesos 與 ego 內建起來後，這些政策也适用于 mesos 的 frameworks。
管理者根據每個 role/framework 的需求，可以為其定義一定量的 owned 資源. 就是說這些資源一定可以得到保證的，不管 framework 什麼時候想要這些資源。owned 資源定義支援多種形式，可以是以實體機器為機關的多個機器，也可以是百分比的方式擁有每個實體機器上百分之多少。如果 role/framework允許，在他自己不用的時候可以把這些owned 的資源借給其他人使用。這樣最大化的提供整個叢集的資源使用率。
管理者根據每個 role/framework 的需求，可以定義一些資源共享政策。那些被别人 own 完，剩下的資源稱之為共享資源，每個使用者都可以使用的。但每個使用者使用共享資源的優先級可以不同，使用共享資源的比例也可以不同。首先，優先級高的 role/framework 永遠優先使用共享資源，在必要的情況下，可以搶占優先級的 role/framework 的共享資源。這是下面要提到的資源搶占。其次，如果 role/framework 優先級相同，他們根據資源比例配比去使用共享資源，如果某個 role/framework 使用了超過了他自己配比的資源，資源搶占也會發生。還可以進一步為 role/framework 配置共享資源使用上限。如果貢獻資源使用将要超過設定的上限，mesos-ego 就不允許 role/framework 再啟動作業了。
2）資源搶占式政策
資源搶占主要發生在一下三種情況下：
1. 某個 role/framework 借了别人 owned 資源。 但資源擁有者想要把借出去的資源要回來，資源搶占就發生了。
2. 高優先級 role/framework 搶占低優先級 framework/role 使用的共享資源。
3. 某個 role/framework 使用了超過配比給他的共享資源。這時候 mesos-ego 會嘗試根據資源配比去平衡 role/framework 使用的共享資源，所謂的資源搶占也就發生了。
當資源搶占發生時，mesos-ego 會給 framework 發 inverseoffer 把要搶占的資源要回來。一般會給 framework 一定的緩沖時間，隻要在要求時間内把作業停掉，把資源釋放了就行。但如果 framework 不配合，mesos-ego 會強制 framework 的一些作業，把資源釋放出來給高優先級 framework, 或資源本身所有者使用。
講師介紹：劉光亞
西安交通大學碩士，目前就職于ibm platform computing 系統科技部雲計算部門，擔任雲計算開發部架構師。
參與nova、cinder、heat和magnum等openstack社群項目開發，目前擔任magnum的core member。
2014年參與mesos生态系統的調研以及mesos社群的開發工作，mesos活躍貢獻者。西安openstack meetup和mesos meetup組織者。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-01-29</b>