深刻淺出Mesos（二）：Mesos的體系結構和工做流

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

【編者按】Mesos是Apache下的開源分佈式資源管理框架，它被稱爲是分佈式系統的內核。Mesos最初是由加州大學伯克利分校的AMPLab開發的，後在Twitter獲得普遍使用。InfoQ接下來將會策劃系列文章來爲讀者剖析Mesos。本文是整個系列的第一篇，簡單介紹了Mesos的背景、歷史以及架構。

注：本文翻譯自Cloud Architect Musings，InfoQ中文站在得到做者受權的基礎上對文章進行了翻譯。

---

在本系列的第一篇文章中，我簡單介紹了Apache Mesos的背景、架構，以及它在數據中心資源管理中的價值。本篇文章將深刻剖析Mesos的技術細節和組件間的流程，以便你們更好地理解爲何Mesos是數據中心操做系統內核的重要候選者。文中所述的大部分技術細節都來自Ben Hindman團隊2010年在加州大學伯克利分校時發表的白皮書。 順便說一句，Hindman已經離開Twitter去了Mesosphere，着手建設並商業化以Mesos爲核心的數據中心操做系統。在此，我將重點放在提煉白皮書的主要觀點上，而後給出一些我對相關技術所產生的價值的思考。

Mesos流程

接着上一篇文章說。並結合前述的加州大學伯克利分校的白皮書以及Apache Mesos網站，開始咱們的講述：

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

• Slave 1向Master彙報其空閒資源：4個CPU、4GB內存。而後，Master觸發分配策略模塊，獲得的反饋是Framework 1要請求所有可用資源。
• Master向Framework 1發送資源邀約，描述了Slave 1上的可用資源。
• Framework的調度器（Scheduler）響應Master，須要在Slave上運行兩個任務，第一個任務分配<2 CPUs, 1 GB RAM>資源，第二個任務分配<1 CPUs, 2 GB RAM>資源。
• 最後，Master向Slave下發任務，分配適當的資源給Framework的任務執行器（Executor）,接下來由執行器啓動這兩個任務（如圖中虛線框所示）。 此時，還有1個CPU和1GB的RAM還沒有分配，所以分配模塊能夠將這些資源供給Framework 2。

資源分配

爲了實如今同一組Slave節點集合上運行多任務這一目標，Mesos使用了隔離模塊， 該模塊使用了一些應用和進程隔離機制來運行這些任務。 不足爲奇的是，雖然可使用虛擬機隔離實現隔離模塊，可是Mesos當前模塊支持的是容器隔離。 Mesos早在2009年就用上了Linux的容器技術，如cgroups和Solaris Zone，時至今日這些仍然是默認的。 然而，Mesos社區增長了Docker做爲運行任務的隔離機制。 無論使用哪一種隔離模塊，爲運行特定應用程序的任務，都須要將執行器所有打包，並在已經爲該任務分配資源的Slave服務器上啓動。 當任務執行完畢後，容器會被「銷燬」，資源會被釋放，以即可以執行其餘任務。

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

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

集大成者

如今來回答談及Mesos時，「那又怎樣」的問題。 對於我來講，使人興奮的是Mesos集四大好處於一身（概述以下），正如我在前一篇文章中所述，我目測Mesos將爲下一代數據中心的操做系統內核。

• 效率 - 這是最顯而易見的好處，也是Mesos社區和Mesosphere常常津津樂道的。

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

• 敏捷 - 與效率和利用率密切相關，這其實是我認爲最重要的好處。 每每，效率解決的是「如何花最少的錢最大化數據中心的資源」，而敏捷解決的是「如何快速用上手頭的資源。」 正如我和個人同事Tyler Britten常常指出，IT的存在是幫助企業賺錢和省錢的；那麼如何經過技術幫助咱們迅速創收，是咱們要達到的重要指標。 這意味着要確保關鍵應用程序不能耗盡所需資源，由於咱們沒法爲應用提供足夠的基礎設施，特別是在數據中心的其餘地方都的資源是收費狀況下。

• 可擴展性 - 爲可擴展而設計，這是我真心欣賞Mesos架構的地方。 這一重要屬性使數據能夠指數級增加、分佈式應用能夠水平擴展。 咱們的發展已經遠遠超出了使用巨大的總體調度器或者限定羣集節點數量爲64的時代，足矣承載新形式的應用擴張。

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

• 模塊化 - 對我來講，預測任何開源技術的健康發展，很大程度上取決於圍繞該項目的生態系統。 我認爲Mesos項目前景很好，由於其設計具備包容性，能夠將功能插件化，好比分配策略、隔離機制和Framework。將容器技術，好比Docker和Rocket插件化的好處是顯而易見。可是我想在此強調的是圍繞Framework建設的生態系統。將任務調度委託給Framework應用程序，以及採用插件架構，經過Mesos這樣的設計，社區創造了可以讓Mesos問鼎數據中心資源管理的生態系統。由於每接入一種新的Framework，Master無需爲此編碼，Slave模塊能夠複用，使得在Mesos所支持的寬泛領域中，業務迅速增加。相反，開發者能夠專一於他們的應用和Framework的選擇。 當前並且還在不斷地增加着的Mesos Framework列表參見此處以及下圖：

總結

在接下來的文章中，我將更深刻到資源分配模塊，並解釋如何在Mesos棧的各級上實現容錯。 同時，我很期待讀者的反饋，特別是關於若是我打標的地方，若是你發現哪裏不對，請反饋給我。 我也會在Twitter響應你的反饋，請關注 @hui_kenneth。

下一篇是關於Mesos的持久性存儲和容錯的。