閱讀(27.7k) 書簽贊(0) 我要糾錯

（二）：Mesos的體系結(jié)構(gòu)和工作流

2018-02-24 16:03 更新

來源：http://www.infoq.com/cn/articles/analyse-mesos-part-02

在本系列的第一篇文章中，我簡單介紹了Apache Mesos的背景、架構(gòu)，以及它在數(shù)據(jù)中心資源管理中的價值。本篇文章將深入剖析Mesos的技術細節(jié)和組件間的流程，以便大家更好地理解為什么Mesos是數(shù)據(jù)中心操作系統(tǒng)內(nèi)核的重要候選者。文中所述的大部分技術細節(jié)都來自Ben Hindman團隊2010年在加州大學伯克利分校時發(fā)表的白皮書。順便說一句，Hindman已經(jīng)離開Twitter去了Mesosphere，著手建設并商業(yè)化以Mesos為核心的數(shù)據(jù)中心操作系統(tǒng)。在此，我將重點放在提煉白皮書的主要觀點上，然后給出一些我對相關技術所產(chǎn)生的價值的思考。

Mesos流程

接著上一篇文章說。并結(jié)合前述的加州大學伯克利分校的白皮書以及Apache Mesos網(wǎng)站，開始我們的講述：

我們來研究下上圖的事件流程。上一篇談到，Slave是運行在物理或虛擬服務器上的Mesos守護進程，是Mesos集群的一部分。Framework由調(diào)度器（Scheduler）應用程序和任務執(zhí)行器（Executor）組成，被注冊到Mesos以使用Mesos集群中的資源。

Slave 1向Master匯報其空閑資源：4個CPU、4GB內(nèi)存。然后，Master觸發(fā)分配策略模塊，得到的反饋是Framework 1要請求全部可用資源。
Master向Framework 1發(fā)送資源邀約，描述了Slave 1上的可用資源。
Framework的調(diào)度器（Scheduler）響應Master，需要在Slave上運行兩個任務，第一個任務分配資源，第二個任務分配資源。
最后，Master向Slave下發(fā)任務，分配適當?shù)馁Y源給Framework的任務執(zhí)行器（Executor）,接下來由執(zhí)行器啟動這兩個任務（如圖中虛線框所示）。此時，還有1個CPU和1GB的RAM尚未分配，因此分配模塊可以將這些資源供給Framework 2。

資源分配

為了實現(xiàn)在同一組Slave節(jié)點集合上運行多任務這一目標，Mesos使用了隔離模塊，該模塊使用了一些應用和進程隔離機制來運行這些任務。不足為奇的是，雖然可以使用虛擬機隔離實現(xiàn)隔離模塊，但是Mesos當前模塊支持的是容器隔離。 Mesos早在2009年就用上了Linux的容器技術，如cgroups和Solaris Zone，時至今日這些仍然是默認的。然而，Mesos社區(qū)增加了Docker作為運行任務的隔離機制。不管使用哪種隔離模塊，為運行特定應用程序的任務，都需要將執(zhí)行器全部打包，并在已經(jīng)為該任務分配資源的Slave服務器上啟動。當任務執(zhí)行完畢后，容器會被“銷毀”，資源會被釋放，以便可以執(zhí)行其他任務。

我們來更深入地研究一下資源邀約和分配策略，因為這對Mesos管理跨多個Framework和應用的資源，是不可或缺的。我們前面提到資源邀約的概念，即由Master向注冊其上的Framework發(fā)送資源邀約。每次資源邀約包含一份Slave節(jié)點上可用的CPU、RAM等資源的列表。 Master提供這些資源給它的Framework，是基于分配策略的。分配策略對所有的Framework普遍適用，同時適用于特定的Framework。 Framework可以拒絕資源邀約，如果它不滿足要求，若此，資源邀約隨即可以發(fā)給其他Framework。由Mesos管理的應用程序通常運行短周期的任務，因此這樣可以快速釋放資源，緩解Framework的資源饑餓； Slave定期向Master報告其可用資源，以便Master能夠不斷產(chǎn)生新的資源邀約。另外，還可以使用諸如此類的技術，每個Fraamework過濾不滿足要求的資源邀約、Master主動廢除給定周期內(nèi)一直沒有被接受的邀約。

分配策略有助于Mesos Master判斷是否應該把當前可用資源提供給特定的Framework，以及應該提供多少資源。關于Mesos中使用資源分配以及可插拔的分配模塊，實現(xiàn)非常細粒度的資源共享，會單獨寫一篇文章。言歸正傳，Mesos實現(xiàn)了公平共享和嚴格優(yōu)先級（這兩個概念我會在資源分配那篇講）分配模塊，確保大部分用例的最佳資源共享。已經(jīng)實現(xiàn)的新分配模塊可以處理大部分之外的用例。

集大成者

現(xiàn)在來回答談及Mesos時，“那又怎樣”的問題。對于我來說，令人興奮的是Mesos集四大好處于一身（概述如下），正如我在前一篇文章中所述，我目測Mesos將為下一代數(shù)據(jù)中心的操作系統(tǒng)內(nèi)核。

效率 - 這是最顯而易見的好處，也是Mesos社區(qū)和Mesosphere經(jīng)常津津樂道的。

上圖來自Mesosphere網(wǎng)站，描繪出Mesos為效率帶來的好處。如今，在大多數(shù)數(shù)據(jù)中心中，服務器的靜態(tài)分區(qū)是常態(tài)，即使使用最新的應用程序，如Hadoop。這時常令人擔憂的是，當不同的應用程序使用相同的節(jié)點時，調(diào)度相互沖突，可用資源互相爭搶。靜態(tài)分區(qū)本質(zhì)上是低效的，因為經(jīng)常會面臨，其中一個分區(qū)已經(jīng)資源耗盡，而另一個分區(qū)的資源卻沒有得到充分利用，而且沒有什么簡單的方法能跨分區(qū)集群重新分配資源。使用Mesos資源管理器仲裁不同的調(diào)度器，我們將進入動態(tài)分區(qū)/彈性共享的模式，所有應用程序都可以使用節(jié)點的公共池，安全地、最大化地利用資源。一個經(jīng)常被引用的例子是Slave節(jié)點通常運行Hadoop作業(yè)，在Slave空閑階段，動態(tài)分配給他們運行批處理作業(yè)，反之亦然。值得一提的是，這其中的某些環(huán)節(jié)可以通過虛擬化技術，如VMware vSphere的分布式資源調(diào)度（DRS）來完成。然而，Mesos具有更精細的粒度，因為Mesos在應用層而不是機器層分配資源，通過容器而不是整個虛擬機（VM）分配任務。前者能夠為每個應用程序的特殊需求做考量，應用程序的調(diào)度器知道最有效地利用資源; 后者能夠更好地“裝箱”，運行一個任務，沒有必要實例化一整個虛擬機，其所需的進程和二進制文件足矣。

敏捷 - 與效率和利用率密切相關，這實際上是我認為最重要的好處。往往，效率解決的是“如何花最少的錢最大化數(shù)據(jù)中心的資源”，而敏捷解決的是“如何快速用上手頭的資源?！?正如我和我的同事Tyler Britten經(jīng)常指出，IT的存在是幫助企業(yè)賺錢和省錢的；那么如何通過技術幫助我們迅速創(chuàng)收，是我們要達到的重要指標。這意味著要確保關鍵應用程序不能耗盡所需資源，因為我們無法為應用提供足夠的基礎設施，特別是在數(shù)據(jù)中心的其他地方都的資源是收費情況下。
可擴展性 - 為可擴展而設計，這是我真心欣賞Mesos架構(gòu)的地方。這一重要屬性使數(shù)據(jù)可以指數(shù)級增長、分布式應用可以水平擴展。我們的發(fā)展已經(jīng)遠遠超出了使用巨大的整體調(diào)度器或者限定群集節(jié)點數(shù)量為64的時代，足矣承載新形式的應用擴張。

Mesos可擴展設計的關鍵之處是采用兩級調(diào)度架構(gòu)。使用Framework代理任務的實際調(diào)度，Master可以用非常輕量級的代碼實現(xiàn)，更易于擴展集群發(fā)展的規(guī)模。因為Master不必知道所支持的每種類型的應用程序背后復雜的調(diào)度邏輯。此外，由于Master不必為每個任務做調(diào)度，因此不會成為容量的性能瓶頸，而這在為每個任務或者虛擬機做調(diào)度的整體調(diào)度器中經(jīng)常發(fā)生。
模塊化 - 對我來說，預測任何開源技術的健康發(fā)展，很大程度上取決于圍繞該項目的生態(tài)系統(tǒng)。我認為Mesos項目前景很好，因為其設計具有包容性，可以將功能插件化，比如分配策略、隔離機制和Framework。將容器技術，比如Docker和Rocket插件化的好處是顯而易見。但是我想在此強調(diào)的是圍繞Framework建設的生態(tài)系統(tǒng)。將任務調(diào)度委托給Framework應用程序，以及采用插件架構(gòu)，通過Mesos這樣的設計，社區(qū)創(chuàng)造了能夠讓Mesos問鼎數(shù)據(jù)中心資源管理的生態(tài)系統(tǒng)。因為每接入一種新的Framework，Master無需為此編碼，Slave模塊可以復用，使得在Mesos所支持的寬泛領域中，業(yè)務迅速增長。相反，開發(fā)者可以專注于他們的應用和Framework的選擇。當前而且還在不斷地增長著的Mesos Framework列表參見此處以及下圖：