mesos概述

mesos解決的問題

不一樣的分佈式運算框架(spark,hadoop,ES,MPI,Cassandra,etc.)中的不一樣任務每每須要的資源（內存，CPU，網絡IO等）不一樣，它們運行在同一個集羣中，會相互干擾，爲此，應該提供一種資源隔離機制避免任務之間由資源爭用致使效率降低,考慮到資源利用率，運維成本，數據共享等因素，公司通常但願將全部這些框架部署到一個公共的集羣中，讓它們共享集羣的資源，並對資源進行統一使用，這樣，便誕生了資源統一管理與調度平臺,典型的表明就是mesos和yarn。

Mesos的目標就是在不一樣的framework之間高效的共享硬件資源，同時簡化自身的調度邏輯，使其具備儘量大的兼容性和可擴展性，以保證在大規模集羣使用環境下的健壯性和對各類可能的運算框架的廣泛適用性。

mesos基本術語解釋

• Mesos-master：協調所有的slave，並肯定每一個節點的可用資源，聚合計算跨節點的全部可用資源的報告，而後向註冊到Master的Framework發出資源邀約。

• Mesos-slave：向master彙報本身的空閒資源和任務的狀態，負責管理本節點上的各個mesos-task，在framework成功向Master申請資源後,收到消息的slave會啓動相應framework的exexutor

• Framework：Hadoop，Spark等，經過MesosSchedulerDiver接入Mesos

• Executor：執行器，用於啓動計算框架中的task

mesos與yarn區別

• Mesos只負責offer資源給framework，而Yarn本身來分配資源。

• Yarn侷限在Hadoop上，無法做爲別的機器管理。

• Mesos管理CPU，Memory，Disk；而Yarn只管理Memory和CPU。

• Mesos用lxc隔離，Yarn用進程來進行隔離（性能可能更好）。

• 部署Mesos之後，再跑Spark或Hadoop MapReduce的時候，就不須要部署Spark和Hadoop了，直接在Mesos上運行Spark或Hadoop任務(在文件系統中指定運行所須要的框架二進制包位置)。

• 兩種系統都採用了雙層調度機制，即，第一層是源管理系統（mesos/YARN）將資源分配給應用程序（或框架），第二層，應用程序將收到的資源進一步分配給內部的任務。可是資源分配器智能化程度不一樣，mesos是基於resource offer的調度機制，包含很是少的調度語義，他只是簡單的將資源推給各個應用程序，由應用程序選擇是否接受資源，而mesos自己並不知道各個應用程序資源需求；YARN則不一樣，應用程序的ApplicationMaster會把各個任務的資源要求彙報給YARN，YARN則根據須要爲應用程序分配資源。

• 從功能上講YARN和Mesos類似，只是Mesos更通用，能夠支持在線和離線任務。通常YARN用於調度離線任務。

mesos架構

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

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

細粒度分配

Mesos最大的好處是可以對分佈式集羣作細粒度資源分配。以下圖所示，左邊是粗粒度的資源分配，右邊是細粒度的資源分配。

細粒度的資源分配是指直接按照任務實際需求分配資源，這種分配機制可大大提升資源利用率。

左邊有三個集羣，每一個集羣三臺服務器，分別裝三種分佈式計算平臺，好比上面裝三臺Hadoop，中間三臺是Spark，下面三臺是Storm，三個不一樣的框架分別進行管理。右邊是Mesos集羣統一管理9臺服務器，全部來自Spark、Hadoop或Storm的任務都在9臺服務器上混合運行。Mesos提升了資源冗餘率。粗粒度資源管理確定帶來必定的浪費，細粒度的管理提升了資源管理能力。

Mesos的分配邏輯很簡單，只要不停地報告哪些是可用資源就能夠了。Mesos資源分配方法也有一個潛在的缺點，就是無中心化的分配方式，因此有可能不會帶來全局最優的方式。但這個數據資源缺點對目前來說並非很嚴重。

mesos流程

如上圖所示,Mesos由始至終只作一件事情，就是分佈式集羣資源的分配。任務的調度和執行由每一個計算框架(Framework)本身完成,這樣能夠容易的實現mesos的擴展性和穩定性。

1. Slave1向Master彙報其有<4CPU,4GB RAM>的空閒資源，而後Master調用分配模塊，告訴Framework1全部可用的空閒資源。
2. Master發送一個描述Slave1當前空閒資源的resource offer給框架1。
3. Framework1的調度器回覆Master，須要運行兩個task在Slave1上，第一個task須要資源<2CPU, 1GBRAM>，第二個task須要資源<1CPU, 2GB RAM>。
4. Master把任務需求資源發送給Slave1，Slave1分配適當的資源給Framework1的executor，而後executor開始執行這兩個任務,由於Slave1還剩<1CPU,1G RAM>的資源還未分配，分配模塊能夠將這些資源提供給Framwork2來使用。

每當有task結束，容器會被」銷燬」,釋放新的資源，都會執行資源邀約(resource offer)進程。

mesos資源分配

Mesos早在2009年就用上了Linux的容器技術，如cgroups和Solaris Zone，時至今日這些仍然是默認的。 然而，Mesos社區增長了Docker做爲運行任務的隔離機制。無論哪一種隔離機制，處理流程都是相同的。

前面提到資源邀約的概念，即由Master向註冊其上的Framework發送資源邀約。 每次資源邀約包含一份Slave節點上可用的CPU、RAM等資源的列表。 Master提供這些資源給它的Framework，是基於分配策略的。分配策略對全部的Framework廣泛適用，同時適用於特定的Framework。 若是它不知足要求,Framework能夠拒絕資源邀約，若是這樣，資源邀約隨便可以發給其餘Framework。 由Mesos管理的應用程序一般運行短週期的任務，所以這樣能夠快速釋放資源，緩解Framework的資源飢餓； Slave按期向Master報告其可用資源，以便Master可以不斷產生新的資源邀約。 另外，還可使用諸如此類的技術， 每一個Framework過濾不知足要求的資源邀約、Master主動廢除給定週期內一直沒有被接受的邀約。

DRF算法

mesos默認資源分配策略是DRF（主導資源公平算法 Dominant Resource Fairness），DRF的目標是確保每個Framework，在異質環境中可以接收到其最需資源的公平份額。

爲了掌握DRF，咱們須要瞭解主導資源（dominant resource）和主導份額（dominant share）的概念。Framework的主導資源是其最需的資源類型（CPU、內存等），在資源邀約中以可用資源百分比的形式展現。例如，對於計算密集型的任務，它的Framework的主導資源是CPU，而依賴於在內存中計算的任務，它的Framework的主導資源是內存。由於資源是分配給Framework的，因此DRF會跟蹤每一個Framework擁有的資源類型的份額百分比；Framework擁有的所有資源類型份額中佔最高百分比的就是Framework的主導份額。DRF算法會使用全部已註冊的Framework來計算主導份額，以確保每一個Framework能接收到其主導資源的公平份額。

舉例說明:

假設咱們有一個資源邀約，包含<9CPU,18GB RAM>。Framework1 運行任務需<1CPU,4GB RAM>，Framework2 運行任務須要<3CPU,1GB RAM>

Framework1 的每一個任務會消耗CPU總數的1/九、內存總數的2/9，所以Framework1 的主導資源是內存。一樣，Framework2 的每一個任務會CPU總數的1/三、內存總數的1/18，所以Framework2 的主導資源是CPU。DRF會嘗試爲每一個Framework提供等量的主導資源，做爲他們的主導份額。在這個例子中，DRF將協同Framework作以下分配：Framework1 有三個任務，總分配爲<3CPU,12GB RAM>，Framework2 有兩個任務，總分配爲<6CPU,2GB RAM>。

此時，每一個Framework的主導資源（Framework1 的內存和Framework2 的CPU）最終獲得相同的主導份額（2/3），這樣提供給兩個Framework後，將沒有足夠的可用資源運行其餘任務。須要注意的是，若是Framework1 中僅有兩個任務須要被運行，那麼Framework2 以及其餘已註冊的Framework將收到的全部剩餘的資源。

DRF分配模塊跟蹤分配給每一個Framework的資源和每一個框架的主導份額。每次，DRF以全部Framework中運行的任務中最低的主導份額做爲資源邀約發送給Framework。若是有足夠的可用資源來運行它的任務，Framework將接受這個邀約。經過前面引述的DRF論文中的示例，咱們來貫穿DRF算法的每一個步驟。爲了簡單起見，示例將不考慮短任務完成後，資源被釋放回資源池中這一因素，咱們假設每一個Framework會有無限數量的任務要運行，並認爲每一個資源邀約都會被接受。

回顧上述示例，假設有一個資源邀約包含9核CPU和18GB內存。Framework 1運行的任務須要（1核CPU、4GB內存），Framework 2運行的任務須要（3核CPU、2GB內存）。Framework 1的任務會消耗CPU總數的1/九、內存總數的2/9，Framework 1的主導資源是內存。一樣，Framework 2的每一個任務會CPU總數的1/三、內存總數的1/18，Framework 2的主導資源是CPU。

上面表中的每一行提供瞭如下信息：

• Framework chosen——收到最新資源邀約的Framework。
• Resource Shares——給定時間內Framework接受的資源總數，包括CPU和內存，以佔資源總量的比例表示。
• Dominant Share（主導份額）——給定時間內Framework主導資源佔總份額的比例，以佔資源總量的比例表示。
• Dominant Share %（主導份額百分比）——給定時間內Framework主導資源佔總份額的百分比，以佔資源總量的百分比表示。
• CPU Total Allocation——給定時間內接受的全部Framework的總CPU資源。
• RAM Total Allocation——給定時間內接受的全部Framework的總內存資源。

注意，每一個行中的最低主導份額以粗體字顯示，以便查找。

最初，兩個Framework的主導份額是0％，咱們假設DRF首先選擇的是Framework2，固然咱們也能夠假設Framework1，可是最終的結果是同樣的。

1. Framework 2接收份額並運行任務，使其主導資源成爲CPU，主導份額增長至33％。
2. 因爲Framework 1的主導份額維持在0％，它接收共享並運行任務，主導份額的主導資源（內存）增長至22％。
3. 因爲Framework 1仍具備較低的主導份額，它接收下一個共享並運行任務，增長其主導份額至44％。
4. 而後DRF將資源邀約發送給Framework 2，由於它如今擁有更低的主導份額。
5. 該過程繼續進行，直到因爲缺少可用資源，不能運行新的任務。在這種狀況下，CPU資源已經飽和。
6. 而後該過程將使用一組新的資源邀約重複進行。

值得注意的是，在當資源釋放的速度不夠快的狀況下，資源分配模塊具備撤銷任務的能力。Mesos嘗試如此撤銷任務：向執行器發送請求結束指定的任務，並給出一個寬限期讓執行器清理該任務。若是執行器不響應請求，分配模塊就結束該執行器及其上的全部任務。

分配策略能夠實現爲，經過提供與Framework相關的保證配置，來阻止對指定任務的撤銷。若是Framework低於保證配置，Mesos將不能結束該Framework的任務。

mesos優勢

1.效率

上圖來自Mesosphere網站，描繪出Mesos爲效率帶來的好處。現在，在大多數數據中心中，服務器的靜態分區是常態，即便使用最新的應用程序，如Hadoop。這時常使人擔心的是，當不一樣的應用程序使用相同的節點時，調度相互衝突，可用資源互相爭搶。靜態分區本質上是低效的，由於常常會面臨，其中一個分區已經資源耗盡，而另外一個分區的資源卻沒有獲得充分利用，並且沒有什麼簡單的方法能跨分區集羣從新分配資源。使用Mesos資源管理器仲裁不一樣的調度器，咱們將進入動態分區/彈性共享的模式，全部應用程序均可以使用節點的公共池，安全地、最大化地利用資源。 一個常常被引用的例子是Slave節點一般運行Hadoop做業，在Slave空閒階段，動態分配給他們運行批處理做業，反之亦然。 值得一提的是，這其中的某些環節能夠經過虛擬化技術，如VMware vSphere的分佈式資源調度（DRS）來完成。 然而，Mesos具備更精細的粒度，由於Mesos在應用層而不是機器層分配資源，經過容器而不是整個虛擬機（VM）分配任務。 前者可以爲每一個應用程序的特殊需求作考量，應用程序的調度器知道最有效地利用資源; 後者可以更好地「裝箱」，運行一個任務，沒有必要實例化一整個虛擬機，其所需的進程和二進制文件足矣。

2.敏捷

快速使用集羣中可用的資源。

3.可擴展性

Mesos可擴展設計的關鍵之處是採用兩級調度架構。 使用Framework代理任務的實際調度，Master能夠用很是輕量級的代碼實現，更易於擴展集羣發展的規模。 由於Master沒必要知道所支持的每種類型的應用程序背後複雜的調度邏輯。 此外，因爲Master沒必要爲每一個任務作調度，所以不會成爲容量的性能瓶頸，而這在爲每一個任務或者虛擬機作調度的總體調度器中常常發生。

4.模塊化

每接入一種新的Framework，Master無需爲此編碼，Slave模塊能夠複用，使得在Mesos所支持的寬泛領域中，業務迅速增加。相反，開發者能夠專一於他們的應用和Framework的選擇。 當前並且還在不斷地增加着的Mesos Framework。目前已經支持的框架在下圖：

Mesos容錯

• Master: Mesos使用熱備份（hot-standby）設計來實現Master節點集合。一個Master節點與多個備用（standby）節點運行在同一集羣中，並由開源軟件Zookeeper來監控。Zookeeper會監控Master集羣中全部的節點，並在Master節點發生故障時管理新Master的選舉。建議的節點總數是5個，實際上，生產環境至少須要3個Master節點。 Mesos決定將Master設計爲持有軟件狀態，這意味着當Master節點發生故障時，其狀態能夠很快地在新選舉的Master節點上重建。 Mesos的狀態信息實際上駐留在Framework調度器和Slave節點集合之中。當一個新的Master當選後，Zookeeper會通知Framework和選舉後的Slave節點集合，以便使其在新的Master上註冊。彼時，新的 Master能夠根據Framework和Slave節點集合發送過來的信息，重建內部狀態。

• Framework調度器: Framework調度器的容錯是經過Framework將調度器註冊2份或者更多份到Master來實現。當一個調度器發生故障時，Master會通知另外一個調度來接管。須要注意的是Framework自身負責實現調度器之間共享狀態的機制。

• Slave: Mesos實現了Slave的恢復功能，當Slave節點上的進程失敗時，可讓執行器/任務繼續運行，併爲那個Slave進程從新鏈接那臺Slave節點上運行的執行器/任務。當任務執行時，Slave會將任務的監測點元數據存入本地磁盤。若是Slave進程失敗，任務會繼續運行，當Master從新啓動Slave進程後，由於此時沒有能夠響應的消息，因此從新啓動的Slave進程會使用檢查點數據來恢復狀態，並從新與執行器/任務鏈接。當計算節點/Slave節點沒法響應多個連續的消息後，Master會從可用資源的列表中刪除該節點，並會嘗試關閉該節點。而後，Master會向分配任務的Framework調度器彙報執行器/任務失敗，並容許調度器根據其配置策略作任務失敗處理。一般狀況下，Framework會從新啓動任務到新的Slave節點，假設它接收並接受來自Master的相應的資源邀約。

• Executor/task: 與計算節點/Slave節點故障相似，Master會向分配任務的Framework調度器彙報執行器/任務失敗，並容許調度器根據其配置策略在任務失敗時作出相應的處理。一般狀況下，Framework在接收並接受來自Master的相應的資源邀約後，會在新的Slave節點上從新啓動任務。

一些問題

• Mesos不支持搶佔，沒法設置任務優先級

• spark在mesos上的資源佔用有兩種模式fine（細粒度）和coarse（粗粒度）。其中fine是default模式，按官方給出的文檔，fine模式會提升資源利用率，可是在實際使用中咱們發現，fine模式下，mesos集羣有資源，spark仍然報資源不足，運行失敗。而這時候改成coarse模式，問題就會消失。

• spark運行時的文件碎片。spark shuffle會在slave機器上產生大量的文件碎片，若是slave配置不夠，就會直接致使機器inode 100%。爲了提升文件系統性能，你須要修改你的spark config，將spark.shuffle.consolidateFiles設置爲true。

• Mesos最適用於Job的任務持續時間短，資源需求能夠靈活伸縮的運算框架，如MapReduce等，對於須要長時間佔用大量資源類型的Job，其非全局式的資源調度可能較難實現近似最優的調度。Google的Omega調度框架則試圖同時解決這些問題。

參考文檔

http://www.infoq.com/cn/author/韓陸

http://mesos.apache.org/documentation/latest/mesos-architecture/

http://www.csdn.net/article/2015-07-10/2825180