（四）：Mesos的資源分配

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

Apache Mesos能夠成為最優(yōu)秀的數(shù)據(jù)中心資源管理器的一個重要功能是面對各種類型的應(yīng)用，它具備像交警一樣的疏導(dǎo)能力。本文將深入Mesos的資源分配內(nèi)部，探討Mesos是如何根據(jù)客戶應(yīng)用需求，平衡公平資源共享的。在開始之前，如果讀者還沒有閱讀這個系列的前序文章，建議首先閱讀它們。第一篇是Mesos的概述，第二篇是兩級架構(gòu)的說明，第三篇是數(shù)據(jù)存儲和容錯。

我們將探討Mesos的資源分配模塊，看看它是如何確定將什么樣的資源邀約發(fā)送給具體哪個Framework，以及在必要時如何回收資源。讓我們先來回顧一下Mesos的任務(wù)調(diào)度過程：

從前面提到的兩級架構(gòu)的說明一文中我們知道，Mesos Master代理任務(wù)的調(diào)度首先從Slave節(jié)點收集有關(guān)可用資源的信息，然后以資源邀約的形式，將這些資源提供給注冊其上的Framework。

Framework可以根據(jù)是否符合任務(wù)對資源的約束，選擇接受或拒絕資源邀約。一旦資源邀約被接受，F(xiàn)ramework將與Master協(xié)作調(diào)度任務(wù)，并在數(shù)據(jù)中心的相應(yīng)Slave節(jié)點上運行任務(wù)。

如何作出資源邀約的決定是由資源分配模塊實現(xiàn)的，該模塊存在于Master之中。資源分配模塊確定Framework接受資源邀約的順序，與此同時，確保在本性貪婪的Framework之間公平地共享資源。在同質(zhì)環(huán)境中，比如Hadoop集群，使用最多的公平份額分配算法之一是最大最小公平算法（max-min fairness）。最大最小公平算法算法將最小的資源分配最大化，并將其提供給用戶，確保每個用戶都能獲得公平的資源份額，以滿足其需求所需的資源；一個簡單的例子能夠說明其工作原理，請參考最大最小公平份額算法頁面的示例1。如前所述，在同質(zhì)環(huán)境下，這通常能夠很好地運行。同質(zhì)環(huán)境下的資源需求幾乎沒有波動，所涉及的資源類型包括CPU、內(nèi)存、網(wǎng)絡(luò)帶寬和I/O。然而，在跨數(shù)據(jù)中心調(diào)度資源并且是異構(gòu)的資源需求時，資源分配將會更加困難。例如，當(dāng)用戶A的每個任務(wù)需要1核CPU、4GB內(nèi)存，而用戶B的每個任務(wù)需要3核CPU、1GB內(nèi)存時，如何提供合適的公平份額分配策略？當(dāng)用戶A的任務(wù)是內(nèi)存密集型，而用戶B的任務(wù)是CPU密集型時，如何公平地為其分配一攬子資源？

因為Mesos是專門管理異構(gòu)環(huán)境中的資源，所以它實現(xiàn)了一個可插拔的資源分配模塊架構(gòu)，將特定部署最適合的分配策略和算法交給用戶去實現(xiàn)。例如，用戶可以實現(xiàn)加權(quán)的最大最小公平性算法，讓指定的Framework相對于其它的Framework獲得更多的資源。默認情況下，Mesos包括一個嚴(yán)格優(yōu)先級的資源分配模塊和一個改良的公平份額資源分配模塊。嚴(yán)格優(yōu)先級模塊實現(xiàn)的算法給定Framework的優(yōu)先級，使其總是接收并接受足以滿足其任務(wù)要求的資源邀約。這保證了關(guān)鍵應(yīng)用在Mesos中限制動態(tài)資源份額上的開銷，但是會潛在其他Framework饑餓的情況。

由于這些原因，大多數(shù)用戶默認使用DRF（主導(dǎo)資源公平算法 Dominant Resource Fairness），這是Mesos中更適合異質(zhì)環(huán)境的改良公平份額算法。

DRF和Mesos一樣出自Berkeley AMPLab團隊，并且作為Mesos的默認資源分配策略實現(xiàn)編碼。

讀者可以從此處和此處閱讀DRF的原始論文。在本文中，我將總結(jié)其中要點并提供一些例子，相信這樣會更清晰地解讀DRF。讓我們開始揭秘之旅。

DRF的目標(biāo)是確保每一個用戶，即Mesos中的Framework，在異質(zhì)環(huán)境中能夠接收到其最需資源的公平份額。為了掌握DRF，我們需要了解主導(dǎo)資源（dominant resource）和主導(dǎo)份額（dominant share）的概念。Framework的主導(dǎo)資源是其最需的資源類型（CPU、內(nèi)存等），在資源邀約中以可用資源百分比的形式展示。例如，對于計算密集型的任務(wù)，它的Framework的主導(dǎo)資源是CPU，而依賴于在內(nèi)存中計算的任務(wù)，它的Framework的主導(dǎo)資源是內(nèi)存。因為資源是分配給Framework的，所以DRF會跟蹤每個Framework擁有的資源類型的份額百分比；Framework擁有的全部資源類型份額中占最高百分比的就是Framework的主導(dǎo)份額。DRF算法會使用所有已注冊的Framework來計算主導(dǎo)份額，以確保每個Framework能接收到其主導(dǎo)資源的公平份額。

概念過于抽象了吧？讓我們用一個例子來說明。假設(shè)我們有一個資源邀約，包含9核CPU和18GB的內(nèi)存。Framework 1運行任務(wù)需要（1核CPU、4GB內(nèi)存），F(xiàn)ramework 2運行任務(wù)需要（3核CPU、1GB內(nèi)存）
Framework 1的每個任務(wù)會消耗CPU總數(shù)的1/9、內(nèi)存總數(shù)的2/9，因此Framework 1的主導(dǎo)資源是內(nèi)存。同樣，F(xiàn)ramework 2的每個任務(wù)會CPU總數(shù)的1/3、內(nèi)存總數(shù)的1/18，因此Framework 2的主導(dǎo)資源是CPU。DRF會嘗試為每個Framework提供等量的主導(dǎo)資源，作為他們的主導(dǎo)份額。在這個例子中，DRF將協(xié)同F(xiàn)ramework做如下分配：Framework 1有三個任務(wù)，總分配為（3核CPU、12GB內(nèi)存），F(xiàn)ramework 2有兩個任務(wù)，總分配為（6核CPU、2GB內(nèi)存）。

此時，每個Framework的主導(dǎo)資源（Framework 1的內(nèi)存和Framework 2的CPU）最終得到相同的主導(dǎo)份額（2/3或67％），這樣提供給兩個Framework后，將沒有足夠的可用資源運行其他任務(wù)。需要注意的是，如果Framework 1中僅有兩個任務(wù)需要被運行，那么Framework 2以及其他已注冊的Framework將收到的所有剩余的資源。

那么，DRF是怎樣計算而產(chǎn)生上述結(jié)果的呢？如前所述，DRF分配模塊跟蹤分配給每個Framework的資源和每個框架的主導(dǎo)份額。每次，DRF以所有Framework中運行的任務(wù)中最低的主導(dǎo)份額作為資源邀約發(fā)送給Framework。如果有足夠的可用資源來運行它的任務(wù)，F(xiàn)ramework將接受這個邀約。通過前面引述的DRF論文中的示例，我們來貫穿DRF算法的每個步驟。為了簡單起見，示例將不考慮短任務(wù)完成后，資源被釋放回資源池中這一因素，我們假設(shè)每個Framework會有無限數(shù)量的任務(wù)要運行，并認為每個資源邀約都會被接受。

回顧上述示例，假設(shè)有一個資源邀約包含9核CPU和18GB內(nèi)存。Framework 1運行的任務(wù)需要（1核CPU、4GB內(nèi)存），F(xiàn)ramework 2運行的任務(wù)需要（3核CPU、2GB內(nèi)存）。Framework 1的任務(wù)會消耗CPU總數(shù)的1/9、內(nèi)存總數(shù)的2/9，F(xiàn)ramework 1的主導(dǎo)資源是內(nèi)存。同樣，F(xiàn)ramework 2的每個任務(wù)會CPU總數(shù)的1/3、內(nèi)存總數(shù)的1/18，F(xiàn)ramework 2的主導(dǎo)資源是CPU。

上面表中的每一行提供了以下信息：

• Framework chosen——收到最新資源邀約的Framework。
• Resource Shares——給定時間內(nèi)Framework接受的資源總數(shù)，包括CPU和內(nèi)存，以占資源總量的比例表示。
• Dominant Share（主導(dǎo)份額）——給定時間內(nèi)Framework主導(dǎo)資源占總份額的比例，以占資源總量的比例表示。
• Dominant Share %（主導(dǎo)份額百分比）——給定時間內(nèi)Framework主導(dǎo)資源占總份額的百分比，以占資源總量的百分比表示。
• CPU Total Allocation——給定時間內(nèi)接受的所有Framework的總CPU資源。
• RAM Total Allocation——給定時間內(nèi)接受的所有Framework的總內(nèi)存資源。

注意，每個行中的最低主導(dǎo)份額以粗體字顯示，以便查找。

最初，兩個Framework的主導(dǎo)份額是0％，我們假設(shè)DRF首先選擇的是Framework 2，當(dāng)然我們也可以假設(shè)Framework 1，但是最終的結(jié)果是一樣的。

1. Framework 2接收份額并運行任務(wù)，使其主導(dǎo)資源成為CPU，主導(dǎo)份額增加至33％。
2. 由于Framework 1的主導(dǎo)份額維持在0％，它接收共享并運行任務(wù)，主導(dǎo)份額的主導(dǎo)資源（內(nèi)存）增加至22％。
3. 由于Framework 1仍具有較低的主導(dǎo)份額，它接收下一個共享并運行任務(wù)，增加其主導(dǎo)份額至44％。
4. 然后DRF將資源邀約發(fā)送給Framework 2，因為它現(xiàn)在擁有更低的主導(dǎo)份額。
5. 該過程繼續(xù)進行，直到由于缺乏可用資源，不能運行新的任務(wù)。在這種情況下，CPU資源已經(jīng)飽和。
6. 然后該過程將使用一組新的資源邀約重復(fù)進行。

需要注意的是，可以創(chuàng)建一個資源分配模塊，使用加權(quán)的DRF使其偏向某個Framework或某組Framework。如前面所提到的，也可以創(chuàng)建一些自定義模塊來提供組織特定的分配策略。

一般情況下，現(xiàn)在大多數(shù)的任務(wù)是短暫的，Mesos能夠等待任務(wù)完成并重新分配資源。然而，集群上也可以跑長時間運行的任務(wù)，這些任務(wù)用于處理掛起作業(yè)或行為不當(dāng)?shù)腇ramework。

值得注意的是，在當(dāng)資源釋放的速度不夠快的情況下，資源分配模塊具有撤銷任務(wù)的能力。Mesos嘗試如此撤銷任務(wù)：向執(zhí)行器發(fā)送請求結(jié)束指定的任務(wù)，并給出一個寬限期讓執(zhí)行器清理該任務(wù)。如果執(zhí)行器不響應(yīng)請求，分配模塊就結(jié)束該執(zhí)行器及其上的所有任務(wù)。

分配策略可以實現(xiàn)為，通過提供與Framework相關(guān)的保證配置，來阻止對指定任務(wù)的撤銷。如果Framework低于保證配置，Mesos將不能結(jié)束該Framework的任務(wù)。

我們還需了解更多關(guān)于Mesos資源分配的知識，但是我將戛然而止。接下來，我要說點不同的東西，是關(guān)于Mesos社區(qū)的。我相信這是一個值得考慮的重要話題，因為開源不僅包括技術(shù)，還包括社區(qū)。

說完社區(qū)，我將會寫一些關(guān)于Mesos的安裝和Framework的創(chuàng)建和使用的，逐步指導(dǎo)的教程。在一番實操教學(xué)的文章之后，我會回來做一些更深入的話題，比如Framework與Master是如何互動的，Mesos如何跨多個數(shù)據(jù)中心工作等。

與往常一樣，我鼓勵讀者提供反饋，特別是關(guān)于如果我打標(biāo)的地方，如果你發(fā)現(xiàn)哪里不對，請反饋給我。我非全知，虛心求教，所以非常期待讀者的校正和啟示。我們也可以在twitter上溝通，請關(guān)注 @hui_kenneth。

查看英文原文：?PLAYING TRAFFIC COP: RESOURCE ALLOCATION IN APACHE MESOS