深刻淺出Mesos（四）：Mesos的資源分配

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

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

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

Apache Mesos可以成爲最優秀的數據中心資源管理器的一個重要功能是面對各類類型的應用，它具有像交警同樣的疏導能力。本文將深刻Mesos的資源分配內部，探討Mesos是如何根據客戶應用需求，平衡公平資源共享的。在開始以前，若是讀者尚未閱讀這個系列的前序文章，建議首先閱讀它們。第一篇是Mesos的概述，第二篇是兩級架構的說明，第三篇是數據存儲和容錯。

咱們將探討Mesos的資源分配模塊，看看它是如何肯定將什麼樣的資源邀約發送給具體哪一個Framework，以及在必要時如何回收資源。讓咱們先來回顧一下Mesos的任務調度過程：

從前面提到的兩級架構的說明一文中咱們知道，Mesos Master代理任務的調度首先從Slave節點收集有關可用資源的信息，而後以資源邀約的形式，將這些資源提供給註冊其上的Framework。

Framework能夠根據是否符合任務對資源的約束，選擇接受或拒絕資源邀約。一旦資源邀約被接受，Framework將與Master協做調度任務，並在數據中心的相應Slave節點上運行任務。

如何做出資源邀約的決定是由資源分配模塊實現的，該模塊存在於Master之中。資源分配模塊肯定Framework接受資源邀約的順序，與此同時，確保在本性貪婪的Framework之間公平地共享資源。在同質環境中，好比Hadoop集羣，使用最多的公平份額分配算法之一是最大最小公平算法（max-min fairness）。最大最小公平算法算法將最小的資源分配最大化，並將其提供給用戶，確保每一個用戶都能得到公平的資源份額，以知足其需求所需的資源；一個簡單的例子可以說明其工做原理，請參考最大最小公平份額算法頁面的示例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的默認資源分配策略實現編碼。

讀者能夠從此處和此處閱讀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/九、內存總數的2/9，所以Framework 1的主導資源是內存。一樣，Framework 2的每一個任務會CPU總數的1/三、內存總數的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/九、內存總數的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首先選擇的是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上溝通，請關注 @hui_kenneth。