我們使用Mesos也有一段時間了，目前有兩個項目使用Mesos作為底層資源管理係統，各自部了一套集群。這中間對比Mesos的論文和源碼實現，到底哪些功能實現了，哪些功能未實現，版本是否穩定，使用是否順暢，有哪些坑會遇到等等這些問題，同組的同事們都遇到了不少。大致總結一下使用過程中的感受吧。

Mesos Master在給framework分配資源的時候采用的是多資源下的最大最小公平算法，即DRF算法，對於Mesos的第一層調度來說，使用方實現的Scheduler應該實現自己的調度策略和資源分配策略，Mesos Master對所有的framework一視同仁，盡量為各個framework的資源分配做到”公平”。對於這一點，我們在使用Mesos實現Scheduler的時候，有兩種使用方式。

 

第一種，項目Q會起一個long-running的framework，作為QMaster，負責接收業務係統發來的任務請求。這個情況下，QMaster接收整個Mesos集群的機器的所有資源，任何一種請求任務都會被調度到某台Mesos Slave上的Executor執行，完了之後把資源返還給Mesos集群，從而在QMaster處再次resourceOffer的時候再接收到。這種場景下，QMaster內部需要維護很多內容，比如不同用戶請求來的任務需要隊列管理，隊列和隊列之間的優先級、session管理、調度策略等都需要QMaster內部維護。

 

第二種，項目D也會起一個long-running的DMaster Framework，負責接收業務係統發來的任務請求。針對不同請求，DMaster會起新的DEngine來管理這一次任務，而DEngine本身也是一個Framework，實現了Mesos Scheduler，DEngine根據自己獲得的資源，會選擇Slave起Executor做任務的執行，並且這次任務的監控和執行情況由DEngine管理，所有的DEngine的生命周期、資源等是由DMaster掌控的。DMaster也需要維護DEngine的管理。

 

其實兩種使用方式本質上是一樣的，我們在使用Mesos的時候，在Mesos的第二層也實現了雙層調度。隻是第一種使用方式中，把我們的第二層都維護在了同一個Framework下麵，把一些元數據寫到了zk上，幫助容錯。而第二種使用方式會產生很多Framework，但是從結構上來說比較清晰一些，比較適用於任務本身比較重的情況，相比較之下，第一種使用方式還是比較輕量級的。

使用下來，感覺Mesos的輕量級使用蠻好用的。Executor和Scheduler之間的簡單通信，通過frameworkMessage這樣的接口傳輸一些消息還是比較方便的。如果Executor Lost了，Schedule能夠接收到事件並嚐試重啟；如果Executor出異常後上報給了Scheduler，Scheduler就可以killTask掉該Executor；如果Executor正常結束，使用driver.sendStatusUpdate()更新狀態，並最後顯示driver.stop()關閉，可以看到Executor正常Finish完成任務。以上這些管理和調度可以依賴Mesos輕量級地實現，並且Mesos對機器資源的使用情況有監控作用，分配任務的時候增加一些自己的調度策略，負載均衡也是很好實現的。

Mesos對每種Framework的分配策略限定在DRF算法，沒有YARN豐富，這點其實倒也不算是不足。Mesos目前比較大的問題是一套Mesos集群隻適合一種計算框架，多套計算框架在一套Mesos集群上使用，無法做到框架之間的資源隔離。對於Mesos來說，為不同業務模塊Framework分配資源這件事情是不區分的，Scheduler在接收到CPU和MEM的時候，可以根據機器信息使用Scheduler的offerRescinded接口拒絕分配來的資源，理論上能做到一定的過濾，但是被拒絕掉的資源不會實時在這次資源分配中再次分配出去，而是會在下次資源分配觸發的時候再分發出去，而且分配的資源的機器屬性也是不能控製的。綜上，Mesos沒有提供多框架之間的隔離、分組能力，我們使用的時候隻能給多個應用部署多套Mesos集群。

Mesos和YARN是雙層調度係統的代表。Mesos早於YARN誕生，是C實現的。兩者在底層CPU的隔離上都使用了cgroup。但是對於內存資源，為了能夠更靈活的控製內存使用量，YARN采用了進程監控的方案控製內存。

在資源分配模型方麵，在YARN中，用戶以隊列的形式組織，每個用戶可屬於一個或多個隊列，且隻能向這些隊列中提交application。每個隊列被劃分了一定比例的資源。而Mesos的資源分配模型應該是很簡單的，對於CPU和內存也沒有YARN那些的虛擬使用方式，往往資源也會白白浪費掉，而且不太好預估。

在資源保證機製方麵，YARN采用的是增量資源分配機製，優先為應用程序預留一個節點上的資源，優點是不會發生餓死現象，但有一定的浪費。Mesos使用的是All or nothing的模式，可能會造成作業餓死（大資源的作業長時間無法得到滿足）。

資源調度係統發展

Google新的Omega應該是在開發中，論文參見。。。，Mesos的作者Andy也在參與Omega的開發。從Hadoop v1的JobTracker，到Mesos和YARN，再到Omega，資源管理係統經曆了三代的演變。Omega的簡單介紹可以參考董的解析Google集群資源管理係統Omega，以下我從他的文章裏摘抄幾點：

中央式調度器：

資源的調度和作業的管理功能全部放到一個進程中完成，典型的代表是Hadoop JobTracker。這種設計方式的缺點是擴展性差：首先，集群規模受限，其次，新的調度策略難以融入現有代碼中，比如之前僅支持MapReduce作業，現在要支持流式作業，而將流式作業的調度策略嵌入到中央式調度器中是一項很難的工作。

 

雙層調度器：

各個框架調度器並不知道整個集群資源使用情況，隻是被動的接收資源； Master僅將可用的資源推送給各個框架，而框架自己選擇使用還是拒絕這些資源；一旦框架（比如Hadoop JobTracker）接收到新資源後，再進一步將資源分配給其內部的各個應用程序（各個MapReduce作業），進而實現雙層調度。

雙層調度器有兩個缺點，其一，各個框架無法知道整個集群的實時資源使用情況；其二，采用悲觀鎖，並發粒度小。

 

共享狀態調度器：

為了克服雙層調度器的以上兩個缺點，Google開發了下一代資源管理係統Omega，Omega是一種基於共享狀態的調度器，該調度器將雙層調度器中的集中式資源調度模塊簡化成了一些持久化的共享數據（狀態）和針對這些數據的驗證代碼，而這裏的“共享數據”實際上就是整個集群的實時資源使用信息。一旦引入共享數據後，共享數據的並發訪問方式就成為該係統設計的核心，而Omega則采用了傳統數據庫中基於多版本的並發訪問控製方式（也稱為“樂觀鎖”, MVCC, Multi-Version Concurrency Control），這大大提升了Omega的並發性。

參考

DRF算法

解析Google集群資源管理係統Omega

全文完 :)