作者 韓陸 【編者按】Mesos是Apache下的開源分布式資源管理框架，它被稱為是分布式系統的內核。Mesos最初是由加州大學伯克利分校的AMPLab開發的，后在Twitter得到廣泛使用。InfoQ接下來將會策劃系列文章來為讀者剖析Mesos。本文是整個系列的第一篇，簡單介紹了Mesos的背景、歷史以及架構。 注：本文翻譯自[Cloud Architect Musings](http://cloudarchitectmusings.com/2015/03/23/apache-mesos-the-true-os-for-the-software-defined-data-center/)，InfoQ中文站在獲得作者授權的基礎上對文章進行了翻譯。  Apache Mesos能夠成為最優秀的數據中心資源管理器的一個重要功能是面對各種類型的應用，它具備像交警一樣的疏導能力。本文將深入Mesos的資源分配內部，探討Mesos是如何根據客戶應用需求，平衡公平資源共享的。在開始之前，如果讀者還沒有閱讀這個系列的前序文章，建議首先閱讀它們。第一篇是[Mesos的概述](http://www.infoq.com/cn/articles/analyse-mesos-part-01)，第二篇是[兩級架構的說明](http://www.infoq.com/cn/articles/analyse-mesos-part-02)，第三篇是[數據存儲和容錯](http://www.infoq.com/cn/articles/analyse-mesos-part-03)。 我們將探討Mesos的資源分配模塊，看看它是如何確定將什么樣的資源邀約發送給具體哪個Framework，以及在必要時如何回收資源。讓我們先來回顧一下Mesos的任務調度過程：  從前面提到的[兩級架構的說明](http://www.infoq.com/cn/articles/analyse-mesos-part-02)一文中我們知道，Mesos Master代理任務的調度首先從Slave節點收集有關可用資源的信息，然后以資源邀約的形式，將這些資源提供給注冊其上的Framework。 Framework可以根據是否符合任務對資源的約束，選擇接受或拒絕資源邀約。一旦資源邀約被接受，Framework將與Master協作調度任務，并在數據中心的相應Slave節點上運行任務。 如何作出資源邀約的決定是由資源分配模塊實現的，該模塊存在于Master之中。資源分配模塊確定Framework接受資源邀約的順序，與此同時，確保在本性貪婪的Framework之間公平地共享資源。在同質環境中，比如Hadoop集群，使用最多的公平份額分配算法之一是最大最小公平算法（max-min fairness）。[最大最小公平算法](http://en.wikipedia.org/wiki/Max-min_fairness)算法將最小的資源分配最大化，并將其提供給用戶，確保每個用戶都能獲得公平的資源份額，以滿足其需求所需的資源；一個簡單的例子能夠說明其工作原理，請參考[最大最小公平份額算法頁面](http://www.ece.rutgers.edu/~marsic/Teaching/CCN/minmax-fairsh.html)的示例1。如前所述，在同質環境下，這通常能夠很好地運行。同質環境下的資源需求幾乎沒有波動，所涉及的資源類型包括CPU、內存、網絡帶寬和I/O。然而，在跨數據中心調度資源并且是異構的資源需求時，資源分配將會更加困難。例如，當用戶A的每個任務需要1核CPU、4GB內存，而用戶B的每個任務需要3核CPU、1GB內存時，如何提供合適的公平份額分配策略？當用戶A的任務是內存密集型，而用戶B的任務是CPU密集型時，如何公平地為其分配一攬子資源？ 因為Mesos是專門管理異構環境中的資源，所以它實現了一個可插拔的資源分配模塊架構，將特定部署最適合的分配策略和算法交給用戶去實現。例如，用戶可以實現加權的最大最小公平性算法，讓指定的Framework相對于其它的Framework獲得更多的資源。默認情況下，Mesos包括一個嚴格優先級的資源分配模塊和一個改良的公平份額資源分配模塊。嚴格優先級模塊實現的算法給定Framework的優先級，使其總是接收并接受足以滿足其任務要求的資源邀約。這保證了關鍵應用在Mesos中限制動態資源份額上的開銷，但是會潛在其他Framework饑餓的情況。 由于這些原因，大多數用戶默認使用DRF（主導資源公平算法 Dominant Resource Fairness），這是Mesos中更適合異質環境的改良公平份額算法。 DRF和Mesos一樣出自Berkeley AMPLab團隊，并且作為Mesos的默認資源分配策略實現編碼。 讀者可以從[此處](https://www.cs.berkeley.edu/~alig/papers/drf.pdf)和[此處](http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-55.pdfhttp://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-55.pdf)閱讀DRF的原始論文。在本文中，我將總結其中要點并提供一些例子，相信這樣會更清晰地解讀DRF。讓我們開始揭秘之旅。 DRF的目標是確保每一個用戶，即Mesos中的Framework，在異質環境中能夠接收到其最需資源的公平份額。為了掌握DRF，我們需要了解主導資源（dominant resource）和主導份額（dominant share）的概念。Framework的主導資源是其最需的資源類型（CPU、內存等），在資源邀約中以可用資源百分比的形式展示。例如，對于計算密集型的任務，它的Framework的主導資源是CPU，而依賴于在內存中計算的任務，它的Framework的主導資源是內存。因為資源是分配給Framework的，所以DRF會跟蹤每個Framework擁有的資源類型的份額百分比；Framework擁有的全部資源類型份額中占最高百分比的就是Framework的主導份額。DRF算法會使用所有已注冊的Framework來計算主導份額，以確保每個Framework能接收到其主導資源的公平份額。 概念過于抽象了吧？讓我們用一個例子來說明。假設我們有一個資源邀約，包含9核CPU和18GB的內存。Framework 1運行任務需要（1核CPU、4GB內存），Framework 2運行任務需要（3核CPU、1GB內存） Framework 1的每個任務會消耗CPU總數的1/9、內存總數的2/9，因此Framework 1的主導資源是內存。同樣，Framework 2的每個任務會CPU總數的1/3、內存總數的1/18，因此Framework 2的主導資源是CPU。DRF會嘗試為每個Framework提供等量的主導資源，作為他們的主導份額。在這個例子中，DRF將協同Framework做如下分配：Framework 1有三個任務，總分配為（3核CPU、12GB內存），Framework 2有兩個任務，總分配為（6核CPU、2GB內存）。 此時，每個Framework的主導資源（Framework 1的內存和Framework 2的CPU）最終得到相同的主導份額（2/3或67％），這樣提供給兩個Framework后，將沒有足夠的可用資源運行其他任務。需要注意的是，如果Framework 1中僅有兩個任務需要被運行，那么Framework 2以及其他已注冊的Framework將收到的所有剩余的資源。  那么，DRF是怎樣計算而產生上述結果的呢？如前所述，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首先選擇的是Framework 2，當然我們也可以假設Framework 1，但是最終的結果是一樣的。 1. Framework 2接收份額并運行任務，使其主導資源成為CPU，主導份額增加至33％。 2. 由于Framework 1的主導份額維持在0％，它接收共享并運行任務，主導份額的主導資源（內存）增加至22％。 3. 由于Framework 1仍具有較低的主導份額，它接收下一個共享并運行任務，增加其主導份額至44％。 4. 然后DRF將資源邀約發送給Framework 2，因為它現在擁有更低的主導份額。 5. 該過程繼續進行，直到由于缺乏可用資源，不能運行新的任務。在這種情況下，CPU資源已經飽和。 6. 然后該過程將使用一組新的資源邀約重復進行。 需要注意的是，可以創建一個資源分配模塊，使用加權的DRF使其偏向某個Framework或某組Framework。如前面所提到的，也可以創建一些自定義模塊來提供組織特定的分配策略。 一般情況下，現在大多數的任務是短暫的，Mesos能夠等待任務完成并重新分配資源。然而，集群上也可以跑長時間運行的任務，這些任務用于處理掛起作業或行為不當的Framework。 值得注意的是，在當資源釋放的速度不夠快的情況下，資源分配模塊具有撤銷任務的能力。Mesos嘗試如此撤銷任務：向執行器發送請求結束指定的任務，并給出一個寬限期讓執行器清理該任務。如果執行器不響應請求，分配模塊就結束該執行器及其上的所有任務。 分配策略可以實現為，通過提供與Framework相關的保證配置，來阻止對指定任務的撤銷。如果Framework低于保證配置，Mesos將不能結束該Framework的任務。 我們還需了解更多關于Mesos資源分配的知識，但是我將戛然而止。接下來，我要說點不同的東西，是關于Mesos社區的。我相信這是一個值得考慮的重要話題，因為開源不僅包括技術，還包括社區。 說完社區，我將會寫一些關于Mesos的安裝和Framework的創建和使用的，逐步指導的教程。在一番實操教學的文章之后，我會回來做一些更深入的話題，比如Framework與Master是如何互動的，Mesos如何跨多個數據中心工作等。 與往常一樣，我鼓勵讀者提供反饋，特別是關于如果我打標的地方，如果你發現哪里不對，請反饋給我。我非全知，虛心求教，所以非常期待讀者的校正和啟示。我們也可以在[twitter](https://twitter.com/hui_kenneth)上溝通，請關注 @hui_kenneth。