//
資源管理框架（mesos/YARN/coraca/Torca/Omega)分析
http://mp.weixin.qq.com/s?__biz=MzA3ODUxMzQxMA==&mid=200171215&idx=1&sn=689072b46fc5d4b4e848f251a68809ac&scene=21#wechat_redirect
1 資源調(diào)度的目標(biāo)和價值
1.1 子系統(tǒng)高效調(diào)度
任務(wù)之間資源隔離，減少爭搶。 任務(wù)分配調(diào)度時結(jié)合資源分配，各個任務(wù)分配合理的資源，充分利用系統(tǒng)資源，減少資源利用不充分的問題。 資源調(diào)度結(jié)合優(yōu)先級，優(yōu)先級高的分配更多的資源。
1.2 提高全系統(tǒng)的資源利用率
各個子系統(tǒng)，存在不同時期，對資源需求不一樣的情況，平滑系統(tǒng)資源的利用。
1.3 支持動態(tài)調(diào)整切分資源，增強(qiáng)系統(tǒng)擴(kuò)展性。
系統(tǒng)對資源的規(guī)劃很難一次性準(zhǔn)確，通過mesos支持虛擬主機(jī)的方式，動態(tài)擴(kuò)展。
2 資源調(diào)度使用限制以及難點(diǎn)
2.1 資源調(diào)度使用限制
資源調(diào)度是為了提高資源利用率，分配本身是存在一定的開銷的，對實(shí)時性要求非常高的應(yīng)用不適合(毫秒，秒級別的應(yīng)用)。
2.2 應(yīng)用（框架）比較難規(guī)劃資源
資源框架通過算法分配資源，但是每個細(xì)粒度的具體的任務(wù)對資源的需求非常難預(yù)估。規(guī)劃如果偏差比較大，反而會降低系統(tǒng)本身的性能。
2.3 mem使用分配難題 JVM虛擬機(jī)存在內(nèi)存回收的問題，這個不是程序本身是不能干涉的。內(nèi)存很難分配準(zhǔn)確，如果內(nèi)存分配過少會導(dǎo)致任務(wù)失敗。分配過多，造成資源浪費(fèi)。
3 業(yè)界資源調(diào)度框架
3.1 Mesos
3.1.1 背景
Mesos誕生于UC Berkeley的一個研究項(xiàng)目，現(xiàn)已成為Apache Incubator中的項(xiàng)目，當(dāng)前有一些公司使用Mesos管理集群資源，比如Twitter。
3.1.2 架構(gòu)
總體上看，Mesos是一個master/slave結(jié)構(gòu)，其中，master是非常輕量級的，僅保存了framework（各種計(jì)算框架稱為framework）和mesos slave的一些狀態(tài)，而這些狀態(tài)很容易通過framework和slave重新注冊而重構(gòu)，因而很容易使用了zookeeper解決mesos master的單點(diǎn)故障問題。
Mesos master實(shí)際上是一個全局資源調(diào)度器，采用某種策略將某個slave上的空閑資源分配給某一個framework，各種framework通過自己的調(diào)度器向Mesos master注冊，以接入到Mesos中；而Mesos slave主要功能是匯報(bào)任務(wù)的狀態(tài)和啟動各個framework的executor（比如Hadoop的excutor就是TaskTracker）。
整個mesos系統(tǒng)采用了雙層調(diào)度框架：第一層，由mesos將資源分配給框架；第二層，框架自己的調(diào)度器將資源分配給自己內(nèi)部的任務(wù)。
在Mesos中，各種計(jì)算框架是完全融入Mesos中的，也就是說，如果你想在Mesos中添加一個新的計(jì)算框架，首先需要在Mesos中部署一套該框架； Mesos采用linux container對內(nèi)存和cpu進(jìn)行隔離。
3.1.3 優(yōu)點(diǎn)
可以同時支持短類型任務(wù)以及長類型服務(wù)，比如webservice以及SQL service。 資源分配粒度粗，比較適合我們產(chǎn)品多種計(jì)算框架并存的現(xiàn)狀。
3.1.4 缺點(diǎn)
Mesos中的DRF調(diào)度算法過分的追求公平，沒有考慮到實(shí)際的應(yīng)用需求。在實(shí)際生產(chǎn)線上，往往需要類似于Hadoop中Capacity Scheduler的調(diào)度機(jī)制，將所有資源分成若干個queue，每個queue分配一定量的資源，每個user有一定的資源使用上限；更使用的調(diào)度策略是應(yīng)該支持每個queue可單獨(dú)定制自己的調(diào)度器策略，如：FIFO，Priority等。
由于Mesos采用了雙層調(diào)度機(jī)制，在實(shí)際調(diào)度時，將面臨設(shè)計(jì)決策問題：第一層和第二層調(diào)度器分別實(shí)現(xiàn)哪幾個調(diào)度機(jī)制，即：將大部分調(diào)度機(jī)制放到第一層調(diào)度器，還是第一層調(diào)度器僅支持簡單的資源分配（分配比例由管理員指定）？
Mesos采用了Resource Offer機(jī)制（不同于Hadoop中的基于slot的調(diào)度機(jī)制），這種調(diào)度機(jī)制面臨著資源碎片問題，即：每個節(jié)點(diǎn)上的資源不可能全部被分配完，剩下的一點(diǎn)可能不足以讓任何任務(wù)運(yùn)行，這樣，便產(chǎn)生了類似于操作系統(tǒng)中的內(nèi)存碎片問題。
3.2 YARN(Coroca)
3.2.1 背景
從hadoop 1.0發(fā)展而來，解決了hadoop1.0的單管理節(jié)點(diǎn)兩個主要問題：
1、 單管理節(jié)點(diǎn)性能瓶頸。一個管理節(jié)點(diǎn)能管理的服務(wù)器不能無上限。
2、 Hadoop 1.0按照slot來劃分資源，map slot的資源不能共享給reduce slot。造成資源浪費(fèi) 很多公司都切換到hadoop 2.0，如淘寶天梯已經(jīng)淘汰1.0，上線2.0。
3.2.2 架構(gòu)
MRv2最基本的設(shè)計(jì)思想是將JobTracker的兩個主要功能，即資源管理和作業(yè)調(diào)度/監(jiān)控分成兩個獨(dú)立的進(jìn)程。在該解決方案中包含兩個組件：全局的ResourceManager（RM）和與每個應(yīng)用相關(guān)的ApplicationMaster（AM）。這里的“應(yīng)用”指一個單獨(dú)的MapReduce作業(yè)或者DAG作業(yè)。RM和與NodeManager（NM，每個節(jié)點(diǎn)一個）共同組成整個數(shù)據(jù)計(jì)算框架。RM是系統(tǒng)中將資源分配給各個應(yīng)用的最終決策者。AM實(shí)際上是一個具體的框架庫，它的任務(wù)是【與RM協(xié)商獲取應(yīng)用所需資源】和【與NM合作，以完成執(zhí)行和監(jiān)控task的任務(wù)】。
調(diào)度器根據(jù)容量，隊(duì)列等限制條件（如每個隊(duì)列分配一定的資源，最多執(zhí)行一定數(shù)量的作業(yè)等），將系統(tǒng)中的資源分配給各個正在運(yùn)行的應(yīng)用。這里的調(diào)度器是一個“純調(diào)度器”，因?yàn)樗辉儇?fù)責(zé)監(jiān)控或者跟蹤應(yīng)用的執(zhí)行狀態(tài)等，此外，他也不負(fù)責(zé)重新啟動因應(yīng)用執(zhí)行失敗或者硬件故障而產(chǎn)生的失敗任務(wù)。調(diào)度器僅根據(jù)各個應(yīng)用的資源需求進(jìn)行調(diào)度，這是通過抽象概念“資源容器”完成的，資源容器（Resource Container）將內(nèi)存，CPU，磁盤，網(wǎng)絡(luò)等資源封裝在一起，從而限定每個任務(wù)使用的資源量。
調(diào)度器是可插拔的組件，主要負(fù)責(zé)將集群中得資源分配給多個隊(duì)列和應(yīng)用。YARN自帶了多個資源調(diào)度器，如Capacity Scheduler和Fair Scheduler等。
ASM主要負(fù)責(zé)接收作業(yè)，協(xié)商獲取第一個容器用于執(zhí)行AM和提供重啟失敗AM container的服務(wù)。
NM是每個節(jié)點(diǎn)上的框架代理，主要負(fù)責(zé)啟動應(yīng)用所需的容器，監(jiān)控資源（內(nèi)存，CPU，磁盤，網(wǎng)絡(luò)等）的使用情況并將之匯報(bào)給調(diào)度器。
AM主要負(fù)責(zé)同調(diào)度器協(xié)商以獲取合適的容器，并跟蹤這些容器的狀態(tài)和監(jiān)控其進(jìn)度。
3.2.3 優(yōu)點(diǎn)
YARN作為hadoop 2.0，hadoop各個組件都快速的接入YARN框架，未來發(fā)展很快，默認(rèn)支持調(diào)度算法更豐富。
3.2.4 缺點(diǎn)
ResourceManager負(fù)責(zé)所有應(yīng)用的任務(wù)調(diào)度，各個應(yīng)用作為YARN的一個client library。傳統(tǒng)數(shù)據(jù)庫應(yīng)用，接入之后效率不高，比較困難。
3.2.5 Coraca
Hadoop Corona是facebook開源的下一代MapReduce框架。其基本設(shè)計(jì)動機(jī)和Apache的YARN一致
(1) Cluster Manager 類似于YARN中的Resource Manager，負(fù)責(zé)資源分配和調(diào)度。Cluster Manager掌握著各個節(jié)點(diǎn)的資源使用情況，并將資源分配給各個作業(yè)（默認(rèn)調(diào)度器為Fair Scheduler）。同YARN中的Resource Manager一樣，Resource Manager是一個高度抽象的資源統(tǒng)一分配與調(diào)度框架，它不僅可以為MapReduce，也可以為其他計(jì)算框架分配資源。
(2) Corona Job Tracker 類似于YARN中的Application Master，用于作業(yè)的監(jiān)控和容錯，它可以運(yùn)行在兩個模式下：
1） 作為JobClient，用于提交作業(yè)和方便用戶跟蹤作業(yè)運(yùn)行狀態(tài)
2） 作為一個Task運(yùn)行在某個TaskTracker上。與MRv1中的Job Tracker不同，每個Corona Job Tracker只負(fù)責(zé)監(jiān)控一個作業(yè)。
(3) Corona Task Tracker 類似于YARN中的Node Manager，它的實(shí)現(xiàn)重用了MRv1中Task Tracker的很多代碼，它通過心跳將節(jié)點(diǎn)資源使用情況匯報(bào)給Cluster Manager，同時會與Corona Job Tracker通信，以獲取新任務(wù)和匯報(bào)任務(wù)運(yùn)行狀態(tài)。
(4) Proxy Job Tracker 用于離線展示一個作業(yè)的歷史運(yùn)行信息，包括Counter、metrics、各個任務(wù)運(yùn)行信息等。 相比YARN，Coraca和hadoop耦合比較深，還是slot管理資源方式?；緟⒖糦ARN框架即可。
3.3 Torca
3.3.1 背景
Torca作為Typhoon云平臺的關(guān)鍵系統(tǒng)也就應(yīng)運(yùn)而生，已經(jīng)在網(wǎng)頁搜索、廣告等廣泛應(yīng)用。
3.3.2 架構(gòu)
分central manager和execute server。central manager是集群的任務(wù)調(diào)度中心，包含以下模塊
Master Daemon：負(fù)責(zé)啟動/重啟其他進(jìn)程。
Scheduler：管理多個優(yōu)先級的任務(wù)隊(duì)列，根據(jù)任務(wù)描述文件生成任務(wù)ClassAd（分類廣告），通過collector匹配任務(wù)與資源，下發(fā)任務(wù)至Execute Server。
Collector：集群的數(shù)據(jù)中心，負(fù)責(zé)從Execute Server收集機(jī)器及任務(wù)狀態(tài)。機(jī)器的動態(tài)信息由Execute Server上報(bào)，一些靜態(tài)信息及機(jī)器無法上報(bào)的信息如機(jī)位從CMDB拉?。煌瑫r，也是集群的匹配中心，對任務(wù)與資源的ClassAd進(jìn)行匹配（MatchMaking）。
用戶通過submitter和jdf提交job，如果作業(yè)依賴的文件在提交機(jī)本地，則submitter自動將其copy到xfs，并且用digest做標(biāo)記，同時對job的各個屬性進(jìn)行解析，以及進(jìn)行有效性檢查，如果沒有問題后，將生成最終的作業(yè)描述，發(fā)給CM上的scheduler。scheduler執(zhí)行一定的調(diào)度策略，當(dāng)決定這個job可以調(diào)度時，就將其發(fā)給collector，則collector會返回給scheduler滿足條件的機(jī)器列表，scheduler就可以向這些機(jī)器發(fā)出啟動task的流程了。Execute server根據(jù)job描述，準(zhǔn)備相應(yīng)的作業(yè)執(zhí)行環(huán)境，分配資源，創(chuàng)建container等，就會啟動task，并且在zk上記入該task相應(yīng)的name信息。
3.3.3 優(yōu)點(diǎn)
資源分配的有一個匹配的map的過程，而不是如mesos一樣直接把所有資源先分給一個框架。分配算法更合理，可以參考。
3.3.4 缺點(diǎn)
模仿hadoop搞了一套私有的xfs,mapreduce，完全沒有生態(tài)圈。
3.4 Omega
3.4.1 背景
Google的論文《Omega flexible, scalable schedulers for large compute clusters》中把調(diào)度分為3代，第一代是獨(dú)立的集群，第二代是兩層調(diào)度（mesos,YARN）第三帶是共享狀態(tài)調(diào)度。
3.4.2 架構(gòu)
為了克服雙層調(diào)度器的以上兩個缺點(diǎn)，Google開發(fā)了下一代資源管理系統(tǒng)Omega，Omega是一種基于共享狀態(tài)的調(diào)度器，該調(diào)度器將雙層調(diào)度器中的集中式資源調(diào)度模塊簡化成了一些持久化的共享數(shù)據(jù)（狀態(tài)）和針對這些數(shù)據(jù)的驗(yàn)證代碼，而這里的“共享數(shù)據(jù)”實(shí)際上就是整個集群的實(shí)時資源使用信息。一旦引入共享數(shù)據(jù)后，共享數(shù)據(jù)的并發(fā)訪問方式就成為該系統(tǒng)設(shè)計(jì)的核心，而Omega則采用了傳統(tǒng)數(shù)據(jù)庫中基于多版本的并發(fā)訪問控制方式（也稱為“樂觀鎖”, MVCC, Multi-Version Concurrency Control），這大大提升了Omega的并發(fā)性。 由于Omega不再有集中式的調(diào)度模塊，因此，不能像Mesos或者YARN那樣，在一個統(tǒng)一模塊中完成以下功能：對整個集群中的所有資源分組，限制每類應(yīng)用程序的資源使用量，限制每個用戶的資源使用量等，這些全部由各個應(yīng)用程序調(diào)度器自我管理和控制，根據(jù)論文所述，Omega只是將優(yōu)先級這一限制放到了共享數(shù)據(jù)的驗(yàn)證代碼中，即當(dāng)同時由多個應(yīng)用程序申請同一份資源時，優(yōu)先級最高的那個應(yīng)用程序?qū)@得該資源，其他資源限制全部下放到各個子調(diào)度器。 引入多版本并發(fā)控制后，限制該機(jī)制性能的一個因素是資源訪問沖突的次數(shù)，沖突次數(shù)越多，系統(tǒng)性能下降的越快，而google通過實(shí)際負(fù)載測試證明，這種方式的沖突次數(shù)是完全可以接受的。 Omega論文中談到，Omega是從Google現(xiàn)有系統(tǒng)上演化而來的。既然這篇論文只介紹了Omega的調(diào)度器架構(gòu)，我們可推測它的整體架構(gòu)類似于Mesos，這樣，如果你了解Mesos，那么可知道，我們可以通過僅修改Mesos的Master將之改造成一個Omega。
3.4.3 優(yōu)點(diǎn)
共享資源狀態(tài)，支持更大的集群和更高的并發(fā)。
3.4.4 缺點(diǎn)
只有論文，無具體實(shí)現(xiàn)，在小集群下，沒有優(yōu)勢。
4 Linux container介紹
LXC為Linux Container的簡寫。Linux Container容器是一種內(nèi)核虛擬化技術(shù)，可以提供輕量級的虛擬化，以便隔離進(jìn)程和資源，而且不需要提供指令解釋機(jī)制以及全虛擬化的其他復(fù)雜性。相當(dāng)于C++中的NameSpace。容器有效地將由單個操作系統(tǒng)管理的資源劃分到孤立的組中，以更好地在孤立的組之間平衡有沖突的資源使用需求。與傳統(tǒng)虛擬化技術(shù)相比，它的優(yōu)勢在于：
（1）與宿主機(jī)使用同一個內(nèi)核，性能損耗小；
（2）不需要指令級模擬；
（3）不需要即時(Just-in-time)編譯；
（4）容器可以在CPU核心的本地運(yùn)行指令，不需要任何專門的解釋機(jī)制；
（5）避免了準(zhǔn)虛擬化和系統(tǒng)調(diào)用替換中的復(fù)雜性；
（6）輕量級隔離，在隔離的同時還提供共享機(jī)制，以實(shí)現(xiàn)容器與宿主機(jī)的資源共享。
總結(jié)：Linux Container是一種輕量級的虛擬化的手段。 Linux Container提供了在單一可控主機(jī)節(jié)點(diǎn)上支持多個相互隔離的server container同時執(zhí)行的機(jī)制。Linux Container有點(diǎn)像chroot，提供了一個擁有自己進(jìn)程和網(wǎng)絡(luò)空間的虛擬環(huán)境，但又有別于虛擬機(jī)，因?yàn)閘xc是一種操作系統(tǒng)層次上的資源的虛擬化。
5 選型建議
1）如果整個系統(tǒng)是hadoop應(yīng)用和傳統(tǒng)數(shù)據(jù)庫并存的系統(tǒng)，可以考慮選用mesos，mesos是二層資源管理框架，更多的資源分配的權(quán)利提供了framework。
2）如果整個系統(tǒng)是純粹的hadoop應(yīng)用，考慮到Y(jié)ARN框架的發(fā)展，以及對框架開發(fā)對各個hadoop應(yīng)用的支持，建議考慮YARN。
不管mesos和YARN本身，框架設(shè)計(jì)都考慮了的擴(kuò)展性，但是原生的框架可能并非適用完全適用實(shí)際場景的應(yīng)用，所以基于原有框架擴(kuò)展分配策略是非常重要的，大家可以一起探討下框架本身的限制以及修改擴(kuò)展思路？
