資源管理框架（mesos/YARN/coraca/Torca/Omega)分析

1 資源調度的目標和價值

1.1 子系統高效調度

任務之間資源隔離，減小爭搶。 任務分配調度時結合資源分配，各個任務分配合理的資源，充分利用系統資源，減小資源利用不充分的問題。 資源調度結合優先級，優先級高的分配更多的資源。

1.2 提升全系統的資源利用率

各個子系統，存在不一樣時期，對資源需求不同的狀況，平滑系統資源的利用。

1.3 支持動態調整切分資源，加強系統擴展性。

系統對資源的規劃很難一次性準確，經過mesos支持虛擬主機的方式，動態擴展。

2 資源調度使用限制以及難點

2.1 資源調度使用限制

資源調度是爲了提升資源利用率，分配自己是存在必定的開銷的，對實時性要求很是高的應用不適合(毫秒，秒級別的應用)。

2.2 應用（框架）比較難規劃資源

資源框架經過算法分配資源，可是每一個細粒度的具體的任務對資源的需求很是難預估。規劃若是誤差比較大，反而會下降系統自己的性能。

2.3 mem使用分配難題 JVM虛擬機存在內存回收的問題，這個不是程序自己是不能干涉的。內存很難分配準確，若是內存分配過少會致使任務失敗。分配過多，形成資源浪費。

3 業界資源調度框架

3.1 Mesos

3.1.1 背景

Mesos誕生於UC Berkeley的一個研究項目，現已成爲Apache Incubator中的項目，當前有一些公司使用Mesos管理集羣資源，好比Twitter。

3.1.2 架構

整體上看，Mesos是一個master/slave結構，其中，master是很是輕量級的，僅保存了framework（各類計算框架稱爲framework）和mesos slave的一些狀態，而這些狀態很容易經過framework和slave從新註冊而重構，於是很容易使用了zookeeper解決mesos master的單點故障問題。

Mesos master其實是一個全局資源調度器，採用某種策略將某個slave上的空閒資源分配給某一個framework，各類framework經過本身的調度器向Mesos master註冊，以接入到Mesos中；而Mesos slave主要功能是彙報任務的狀態和啓動各個framework的executor（好比Hadoop的excutor就是TaskTracker）。

整個mesos系統採用了雙層調度框架：第一層，由mesos將資源分配給框架；第二層，框架本身的調度器將資源分配給本身內部的任務。

在Mesos中，各類計算框架是徹底融入Mesos中的，也就是說，若是你想在Mesos中添加一個新的計算框架，首先須要在Mesos中部署一套該框架； Mesos採用linux container對內存和cpu進行隔離。

3.1.3 優勢

能夠同時支持短類型任務以及長類型服務，好比webservice以及SQL service。 資源分配粒度粗，比較適合咱們產品多種計算框架並存的現狀。

3.1.4 缺點

Mesos中的DRF調度算法過度的追求公平，沒有考慮到實際的應用需求。在實際生產線上，每每須要相似於Hadoop中Capacity Scheduler的調度機制，將全部資源分紅若干個queue，每一個queue分配必定量的資源，每一個user有必定的資源使用上限；更使用的調度策略是應該支持每一個queue可單獨定製本身的調度器策略，如：FIFO，Priority等。

因爲Mesos採用了雙層調度機制，在實際調度時，將面臨設計決策問題：第一層和第二層調度器分別實現哪幾個調度機制，即：將大部分調度機制放到第一層調度器，仍是第一層調度器僅支持簡單的資源分配（分配比例由管理員指定）？

Mesos採用了Resource Offer機制（不一樣於Hadoop中的基於slot的調度機制），這種調度機制面臨着資源碎片問題，即：每一個節點上的資源不可能所有被分配完，剩下的一點可能不足以讓任何任務運行，這樣，便產生了相似於操做系統中的內存碎片問題。

3.2 YARN(Coroca)

3.2.1 背景

從hadoop 1.0發展而來，解決了hadoop1.0的單管理節點兩個主要問題：

一、 單管理節點性能瓶頸。一個管理節點能管理的服務器不能無上限。

二、 Hadoop 1.0按照slot來劃分資源，map slot的資源不能共享給reduce slot。形成資源浪費 不少公司都切換到hadoop 2.0，如淘寶天梯已經淘汰1.0，上線2.0。

3.2.2 架構

MRv2最基本的設計思想是將JobTracker的兩個主要功能，即資源管理和做業調度/監控分紅兩個獨立的進程。在該解決方案中包含兩個組件：全局的ResourceManager（RM）和與每一個應用相關的ApplicationMaster（AM）。這裏的「應用」指一個單獨的MapReduce做業或者DAG做業。RM和與NodeManager（NM，每一個節點一個）共同組成整個數據計算框架。RM是系統中將資源分配給各個應用的最終決策者。AM其實是一個具體的框架庫，它的任務是【與RM協商獲取應用所需資源】和【與NM合做，以完成執行和監控task的任務】。

調度器根據容量，隊列等限制條件（如每一個隊列分配必定的資源，最多執行必定數量的做業等），將系統中的資源分配給各個正在運行的應用。這裏的調度器是一個「純調度器」，由於它再也不負責監控或者跟蹤應用的執行狀態等，此外，他也不負責從新啓動因應用執行失敗或者硬件故障而產生的失敗任務。調度器僅根據各個應用的資源需求進行調度，這是經過抽象概念「資源容器」完成的，資源容器（Resource Container）將內存，CPU，磁盤，網絡等資源封裝在一塊兒，從而限定每一個任務使用的資源量。

調度器是可插拔的組件，主要負責將集羣中得資源分配給多個隊列和應用。YARN自帶了多個資源調度器，如Capacity Scheduler和Fair Scheduler等。

ASM主要負責接收做業，協商獲取第一個容器用於執行AM和提供重啓失敗AM container的服務。

NM是每一個節點上的框架代理，主要負責啓動應用所需的容器，監控資源（內存，CPU，磁盤，網絡等）的使用狀況並將之彙報給調度器。

AM主要負責同調度器協商以獲取合適的容器，並跟蹤這些容器的狀態和監控其進度。

3.2.3 優勢

YARN做爲hadoop 2.0，hadoop各個組件都快速的接入YARN框架，將來發展很快，默認支持調度算法更豐富。

3.2.4 缺點

ResourceManager負責全部應用的任務調度，各個應用做爲YARN的一個client library。傳統數據庫應用，接入以後效率不高，比較困難。

3.2.5 Coraca

Hadoop Corona是facebook開源的下一代MapReduce框架。其基本設計動機和Apache的YARN一致

(1) Cluster Manager 相似於YARN中的Resource Manager，負責資源分配和調度。Cluster Manager掌握着各個節點的資源使用狀況，並將資源分配給各個做業（默認調度器爲Fair Scheduler）。同YARN中的Resource Manager同樣，Resource Manager是一個高度抽象的資源統一分配與調度框架，它不只能夠爲MapReduce，也能夠爲其餘計算框架分配資源。

(2) Corona Job Tracker 相似於YARN中的Application Master，用於做業的監控和容錯，它能夠運行在兩個模式下：

1） 做爲JobClient，用於提交做業和方便用戶跟蹤做業運行狀態

2） 做爲一個Task運行在某個TaskTracker上。與MRv1中的Job Tracker不一樣，每一個Corona Job Tracker只負責監控一個做業。

(3) Corona Task Tracker 相似於YARN中的Node Manager，它的實現重用了MRv1中Task Tracker的不少代碼，它經過心跳將節點資源使用狀況彙報給Cluster Manager，同時會與Corona Job Tracker通訊，以獲取新任務和彙報任務運行狀態。

(4) Proxy Job Tracker 用於離線展現一個做業的歷史運行信息，包括Counter、metrics、各個任務運行信息等。 相比YARN，Coraca和hadoop耦合比較深，仍是slot管理資源方式。基本參考YARN框架便可。

3.3 Torca

3.3.1 背景

Torca做爲Typhoon雲平臺的關鍵系統也就應運而生，已經在網頁搜索、廣告等普遍應用。

3.3.2 架構

分central manager和execute server。central manager是集羣的任務調度中心，包含如下模塊

Master Daemon：負責啓動/重啓其餘進程。

Scheduler：管理多個優先級的任務隊列，根據任務描述文件生成任務ClassAd（分類廣告），經過collector匹配任務與資源，下發任務至Execute Server。

Collector：集羣的數據中心，負責從Execute Server收集機器及任務狀態。機器的動態信息由Execute Server上報，一些靜態信息及機器沒法上報的信息如機位從CMDB拉取；同時，也是集羣的匹配中心，對任務與資源的ClassAd進行匹配（MatchMaking）。

用戶經過submitter和jdf提交job，若是做業依賴的文件在提交機本地，則submitter自動將其copy到xfs，而且用digest作標記，同時對job的各個屬性進行解析，以及進行有效性檢查，若是沒有問題後，將生成最終的做業描述，發給CM上的scheduler。scheduler執行必定的調度策略，當決定這個job能夠調度時，就將其發給collector，則collector會返回給scheduler知足條件的機器列表，scheduler就能夠向這些機器發出啓動task的流程了。Execute server根據job描述，準備相應的做業執行環境，分配資源，建立container等，就會啓動task，而且在zk上記入該task相應的name信息。

3.3.3 優勢

資源分配的有一個匹配的map的過程，而不是如mesos同樣直接把全部資源先分給一個框架。分配算法更合理，能夠參考。

3.3.4 缺點

模仿hadoop搞了一套私有的xfs,mapreduce，徹底沒有生態圈。

3.4 Omega

3.4.1 背景

Google的論文《Omega flexible, scalable schedulers for large compute clusters》中把調度分爲3代，第一代是獨立的集羣，第二代是兩層調度（mesos,YARN）第三帶是共享狀態調度。

3.4.2 架構

爲了克服雙層調度器的以上兩個缺點，Google開發了下一代資源管理系統Omega，Omega是一種基於共享狀態的調度器，該調度器將雙層調度器中的集中式資源調度模塊簡化成了一些持久化的共享數據（狀態）和針對這些數據的驗證代碼，而這裏的「共享數據」實際上就是整個集羣的實時資源使用信息。一旦引入共享數據後，共享數據的併發訪問方式就成爲該系統設計的核心，而Omega則採用了傳統數據庫中基於多版本的併發訪問控制方式（也稱爲「樂觀鎖」, MVCC, Multi-Version Concurrency Control），這大大提高了Omega的併發性。 因爲Omega再也不有集中式的調度模塊，所以，不能像Mesos或者YARN那樣，在一個統一模塊中完成如下功能：對整個集羣中的全部資源分組，限制每類應用程序的資源使用量，限制每一個用戶的資源使用量等，這些所有由各個應用程序調度器自我管理和控制，根據論文所述，Omega只是將優先級這一限制放到了共享數據的驗證代碼中，即當同時由多個應用程序申請同一份資源時，優先級最高的那個應用程序將得到該資源，其餘資源限制所有下放到各個子調度器。 引入多版本併發控制後，限制該機制性能的一個因素是資源訪問衝突的次數，衝突次數越多，系統性能降低的越快，而google經過實際負載測試證實，這種方式的衝突次數是徹底能夠接受的。 Omega論文中談到，Omega是從Google現有系統上演化而來的。既然這篇論文只介紹了Omega的調度器架構，咱們可推測它的總體架構相似於Mesos，這樣，若是你瞭解Mesos，那麼可知道，咱們能夠經過僅修改Mesos的Master將之改形成一個Omega。

3.4.3 優勢

共享資源狀態，支持更大的集羣和更高的併發。

3.4.4 缺點

只有論文，無具體實現，在小集羣下，沒有優點。

4 Linux container介紹

LXC爲Linux Container的簡寫。Linux Container容器是一種內核虛擬化技術，能夠提供輕量級的虛擬化，以便隔離進程和資源，並且不須要提供指令解釋機制以及全虛擬化的其餘複雜性。至關於C++中的NameSpace。容器有效地將由單個操做系統管理的資源劃分到孤立的組中，以更好地在孤立的組之間平衡有衝突的資源使用需求。與傳統虛擬化技術相比，它的優點在於：

（1）與宿主機使用同一個內核，性能損耗小；

（2）不須要指令級模擬；

（3）不須要即時(Just-in-time)編譯；

（4）容器能夠在CPU核心的本地運行指令，不須要任何專門的解釋機制；

（5）避免了準虛擬化和系統調用替換中的複雜性；

（6）輕量級隔離，在隔離的同時還提供共享機制，以實現容器與宿主機的資源共享。

總結：Linux Container是一種輕量級的虛擬化的手段。 Linux Container提供了在單一可控主機節點上支持多個相互隔離的server container同時執行的機制。Linux Container有點像chroot，提供了一個擁有本身進程和網絡空間的虛擬環境，但又有別於虛擬機，由於lxc是一種操做系統層次上的資源的虛擬化。

5 選型建議

1）若是整個系統是hadoop應用和傳統數據庫並存的系統，能夠考慮選用mesos，mesos是二層資源管理框架，更多的資源分配的權利提供了framework。

2）若是整個系統是純粹的hadoop應用，考慮到YARN框架的發展，以及對框架開發對各個hadoop應用的支持，建議考慮YARN。

無論mesos和YARN自己，框架設計都考慮了的擴展性，可是原生的框架可能並不是適用徹底適用實際場景的應用，因此基於原有框架擴展分配策略是很是重要的，你們能夠一塊兒探討下框架自己的限制以及修改擴展思路？