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/9、內存總數的2/9，因此Framework1 的主導資源是內存。同樣，Framework2 的每個任務會CPU總數的1/3、內存總數的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/9、內存總數的2/9，Framework 1的主導資源是內存。同樣，Framework 2的每個任務會CPU總數的1/3、內存總數的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