資源管理與調度系統-資源管理系統Mesos
作者：尹正傑
版權聲明：原創作品，謝絕轉載！否則將追究法律責任。
Mesos是誕生於UC Berkeley的一個研究項目，它的設計動機是解決編程模型和計算框架在多樣化環境下，不同框架間的資源隔離和共享問題。
盡管他的直接設計動機與YARN稍有不同，但它的架構和實現策略與YARN類似。當前部分公司在使用Mesos管理集群資源，比如外國的Twitrer，國內的豆瓣等。
Mesos官方鏈接 ：http://mesos.apache.org/
豆瓣的dpark項目 ：https://github.com/douban/dpark
一.Mesos基本架構
如下圖所示，Apache Mesos由以下四個組件組成，接下來我們將詳細對這些組件進行介紹。
1>.Mesos Master
Mesos Master是整個系統的核心，負載管理整個系統中的資源和接入的各個框架（Framework），並將Mesos Slave上的資源按照某種策略分配給框架。
為了防止Mesos Master出現故障后導致集群不可用，Mesos允許用戶配置多個Mesos Master，並通過Zookeeper進行管理，當主Mesos Master出現故障后，Zookeeper可馬上從備用Master中選擇一個提升為新的主Mesos Master。
2>.Mesos Slave
Mesos Slave負責接受並執行來自Mesos Master的命令，並定時將任務執行狀態匯報給Mesos Master。Mesos Slave將節點上的資源使用情況發送給Mesos Master，由Mesos Master中的Allocaltor模塊決定將資源分配給哪個Feamework，需要注意的是，當Mesos僅考慮了CPU和內存兩種資源。
為了避免任務之間互相干擾，同YARN一樣，Mesos Slave采用了輕量級資源隔離機制Cgroups。
3>.Framework Scheduler
Framework是指外部的框架，如MPI，MapReduce，Spark等，這些框架可通過注冊的方式接入Mesos，以便Mesos進行統一資管理和資源分配。Mesos要求接入的框架必須有一個調度器模塊Framework Scheduler，該調度器負責框架內部的任務調度。
一個Framework在Mesos上工作流程為：首先通過自己的調度器向Mesos注冊，並獲取Mesos分配給自己的資源，然后再由自己的調度器將這些資源分配給框架中的任務。也就是說，同YARN一樣，Mesos采用了雙層調度框架：
（1）第一層，由Mesos將資源分配給框架；
（2）第二層 ，框架自己的調度器將資源非配給內部的各個任務。
當前Mesos支持三種語言編寫的調度器，分別是C++，Java和Python，為了向各種調度器提供統一的接入方式，Mesos內部采用C++實現一個MesosSchedulerDriver（調度器驅動器），Framework的調度器可調用該Driver中的接口與Mesos Master交互，完成一系列功能（如注冊，資源分配等）。
4>.Framework Executor
Framework Executor主要用於啟動框架內部的任務。由於不同的框架，啟動任務的接口或者方式不對，當一個新的框架要接入Mesos時，通常需要指定專有的Executor，宜高速Mesoss如何啟動該框架中的任務。為了給各種框架提供統一的編寫方式，Mesos內部采用C++實現了一個MesosExecutorDiver（執行器驅動器），Framework可通過該驅動器的相關接口高速Mesos啟動任務的方法。
二.Mesos資源分配策略
Mesos中最核心的問題是如何構建一個兼具良好擴展性和性能調度模型以支持各種計算框架。由於不同框架可能有不同的調度需求（這往往跟它的編程模型，通信模型，任務依賴關系和數據放置策略等因素相關），因此，為Mesos設計一個好的調度器模型是一個極具挑戰性的工作。
一種可能性的解決方案是構建一個具有豐富表達能力的中央調度器，該調度器接受來自不同框架的詳細需求描述，比如資源需求，任務調度順序和組織關系等，然后為這些任務構建一個全局的調度序列。但是，在真是系統中，由於每種計算框架具有不同的調度需求，且有寫框架的調度需求非常復雜，因此，提供一個具有豐富表達能力的API以捕獲所有框架的需求是不太可能，也就是說，該方案過於理想化，在真是系統中很難實現。
Mesos提供了一種簡化方案：將資源調度的控制授權給各個框架。Mesos負責按照一些簡單的策略（比如FIFO，Fari等）將資源分配給各個框架，而框架內部調度器則根據一些個性化的需求將得到的資源進一步分配個各個作業。
考慮到Mesos缺少對各個框架的實際資源需求的了解，為保證框架能高效地獲取到自己的需要的資源，它提供了以下三個機制。
1>.資源拒絕
如果Mesos為了某個服務分配的資源不符合它的要求，則框架可拒絕該資源直到出現滿足自己需求的資源。該機制使得框架在復雜的資源約束條件下，還能夠保證Mesos設計簡單和具有良好的擴展性；
2>.資源過濾
每次發生資源協調時，Mesos Master均要與Framework Scheduler進行通信，如果有些框架總是拒絕某些節點上的資源，那么由於額外的通信開銷會使得調度性變得低效。為了避免不必要的通信，Mesos提供了資源過濾機制，允許框架只接受來自“剩余資源量大於L的Mesos Slave”或者“位於特定列表中的Mesos Slave”上的資源。
3>.資源回收
如果某個框架在一定的時間內沒有為分配的資源返回對應的任務，則Mesos將回收為其分配的資源，並將這些資源重新分配給其他框架。
為了支持多種資源調度，Mesos采用了主資源公平調度算法（Dominant ResourceFairness，DRF），該算法擴展了最大最小公平（max-min fairness）算法，使其能夠支持多維度資源的調度。
三.Mesos與YARN對比
盡管YARN和Mesos誕生於不同的公司和研究機構，但它們的架構卻大同小異，如下圖所示，給出了它們內部的組織對應關系。
如下表所示，從設計目標，容錯性，在線升級，調度模型，調度算法，資源隔離等方面對比了Mesos和YARN。
總結起來，YARN起源於大數據領域，目前已經形成了良好的生態系統，與其他大數據系統結合緊密，而Mesos源自於集群化服務部署，因而更加適合服務部署與管理。
四.資源管理系統架構演化
Google在論文“Omega:Flexible,scalable schedulers for large compute clusters”中介紹了Google經歷的三代資源調度器的架構，如下圖所示。
分別是中央調度器（類似於Hadoop JobTracker，但是支持多種類型作業調度），雙層調度架構（類似於Mesos和YARN）和共享狀態架構（Omega），並分別討論了這幾個架構的優缺點，重點剖析了最新資源管理系統Omega的相關實現。
1>.集中式架構
集中式調度器（Monolithic scheduler）的特點是，資源的調度和應用程序的管理功能全部放到一個進程中完成，開源典型的代表是MRv1 JobTracker的實現。這種設計方式的缺點很明顯，擴展性差：首先，集群規模受限，其次，新的調度策略難以融入現有代碼中，比如之前僅支持MapReduce作業，現在要支持流式作業，而將流式作業的調度策略嵌入到中央式調度器中是一項很難得工作。
Omega論文中提到了一種對集中式調度器的優化方案：將每種調度策略放到單獨一個路徑（模塊）中，不同的作業由不同的調度策略進行調度。這種方案在作業量和集群規模比較小時，能大大縮短作業響應時間，但由於所有調度策略仍在一個集中式的組件中，整個系統擴展性並沒有變得更好。
2>.雙層調度架構
為了解決集中式調度器的不足，雙層調度器（Two-level scheduler）是一種很容易想到的解決之道。可將它看作一種分而治之的機制或則策略下放機制：雙層調度器仍保存一個經簡化的集中式資源調度器，但具體任務相關的調度策略則下放到各個應用程序調度器中完成。這種調度器典型代表是Mesos和YARN。Omega論文重點介紹了Mesos，Mesos是Twitter開源的資源管理系統，正如上面我們提到的，Mesos調度器由兩部分組成，分別是資源調度器和框架（應用程序）調度器，其中，資源調度器負責將集群中的資源分配給各個框架（應用程序），而框架（應用程序）調度器則負責將資源進一步分配給內部的各個任務，用戶很容易將一種框架或者系統接入Mesos，當然，很多框架已經成功接入了Mesos中，包括Hadoop，MPI，Spark等。
雙層調度器的特點是，各個框架調度器並不知道整個集群資源的使用情況，只是被動的接受資源；資源調度器僅將可用的資源推送給各個框架，而框架自己選擇使用還是拒絕這些資源；一旦框架接受到新資源后，再進一步將資源分配給其內部的任務，進而實現雙層調度。
然而，雙層調度的缺點也是非常明顯的：
（1）各個框架無法知道整個集群的實時資源使用情況
很多框架不需要知道整個集群的實時資源使用情況就可以運行的很順暢，但是對於其他的一些應用，為了提供實時資源使用情況可以挖掘潛在的優化空間，比如，當集群非常繁忙時，一個服務在一個節點上運行失敗了，此時應該選擇換一個節點重新運行它呢，還是在這個節點上在此嘗試運行？通常而言，換一個節點可能會更有利（排除硬件故障和即誒案環境問題導致失敗），但是，如果此時集群非常繁忙，所以節點只剩下小於5GB的內存，而這個服務需要10GB內存，那么換一個節點可能意味着長時間等待資源釋放，而這個等待時間是無法確定的。
（2）采用被關鎖，並發粒度小
在數據庫領域，悲觀鎖和樂觀鎖的爭論一直不休，悲觀鎖通常采用鎖機制控制並發，這會大大降低性能，而樂觀鎖則采用多版本並發控制，典型代表是MySQL InnoDB，這種機制通過多版本方式控制並發，可大大提升性能。
在YARN/Mesos中，在任意一個時刻，Mesos資源調度器只會將某些資源推送給一個框架，等到該框架返回資源使用情況后，才能夠將資源再次推動給其他框架，因此，YARN/Mesos資源調度器中實際上有一個全局鎖，這大大限制了系統的並發性。
3>.共享狀態架構
為了克服雙層調度器的以上兩個缺點，Google開發了下一代資源管理系統Omega，Omega是一種基於共享狀態的調度器（Shared State Scheduler），該調度器將雙層調度器中的集中式資源調度模塊簡化成了一些持久化的共享數據（狀態）和針對這些數據的驗證代碼，而這里的“共享數據”實際上就是整個集群的實時資源使用信息。一旦引入了共享數據后，共享數據的並發訪問方式就成為該系統設計的核心，而Omega則采用了傳統數據庫中基於多版本的並發訪問控制方式（也稱為“樂觀鎖”），這大大提升了Omega的並發性。
由於Omega不再有集中式的調度模塊，因此，不能像Mesos或者YARN集群那樣，在一個統一模塊完成以下功能：對整個集群中的所有資源分組，限制沒類應用程序的資源使用量，限制每個用戶的資源使用量，限制每個用戶的資源使用量等。這些全部由各個應用程序調度器自我管理和控制，根據論文所屬，Omega只是將優先級這一限制放到了共享數據的驗證代碼中，即當同時有多個應用程序申請同一份資源時，優先級最高的哪個應用程序將獲得該資源，其他資源限制全部放到各個子調度器。
引入多版本並發控制后，限制該機制性能的一個因素是資源訪問沖突的次數，沖突次數越多，系統性能下降得越快，而Google通過實際負載測試證明，這種方式的沖突次數是完全可以接受的。
Omega論文中談到，Omega是從Google現有系統上演化而來的。也就是從類似於YARN或者Mesos的系統改造而來的，經過前面的介紹后，有心的讀者會發現，可以很容易將YARN或者Mesos改造成一個類Omega的系統，有興趣的讀者可以嘗試一下完成這項工作。