資源管理框架（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管理集群資源，比如推ter。

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的單管理節點兩個主要問題：

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

2、 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是非死book開源的下一代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是一種操作系統層次上的資源的虛擬 化。