顛覆大數據分析之Mesos：集羣調度及管理系統

正如前面「Mesos:動機」一節中所述，Mesos的主要目標就是去幫助管理不一樣框架（或者應用棧）間的集羣資源。好比說，有一個業務須要在同一個物理集羣上同時運行Hadoop，Storm及Spark。這種狀況下，現有的調度器是沒法完成跨框架間的如此細粒度的資源共享的。Hadoop的YARN調度器是一箇中央調度器，它能夠容許多個框架運行在一個集羣裏。可是，要使用框架特定的算法或者調度策略的話就變得很難了，由於多個框架間只有一種調度算法。好比說，MPI使用的是組調度算法，而Spark用的是延遲調度。它們兩個同時運行在一個集羣上會致使供求關係的衝突。還有一個辦法就是將集羣物理拆分紅多個小的集羣，而後將不一樣的框架獨立地運行在這些小集羣上。再有一個方法就是爲每一個框架分配一組虛擬機。正如Regola和Ducom所說的，虛擬化被認爲是一個性能瓶頸，尤爲是在高性能計算（HPC）系統中。這正是Mesos適合的場景——它容許用戶跨框架來管理集羣資源。

Mesos是一個雙層調度器。在第一層中，Mesos將必定的資源提供（以容器的形式）給對應的框架。框架在第二層接收到資源後，會運行本身的調度算法來將任務分配到Mesos所提供的這些資源上。和Hadoop YARN的這種中央調度器相比，或許它在集羣資源使用方面並非那麼高效。可是它帶來了靈活性——好比說，多個框架實例能夠運行在一個集羣裏。這是現有的這些調度器都沒法實現的。就算是Hadoop YARN也只是儘可能爭取在同一個集羣上支持相似MPI這樣的第三方框架而已。更重要的是，隨着新框架的誕生，好比說Samza最近就被LinkedIn開源出來了——有了Mesos這些新框架能夠試驗性地部署到現有的集羣上，和其它的框架和平共處。

Mesos組件

Mesos的關鍵組件是它的主從守護，正如圖2.5所示，它們分別運行在Mesos的主節點和從節點上。框架或者框架部件都會託管在從節點上，框架部件包括兩個進程，執行進程和調度進程。從節點會給主節點發佈一個可用資源的列表。這是以<2 CPU，8GB內存>列表的形式發佈的。主節點會喚起分配模塊 ，它會根據配置策略來給框架分配資源。隨後主節點將資源分配給框架調度器。框架調度器接收到這個請求後（若是不知足需求的話，也可能會拒絕它），會將須要運行的任務列表以及它們所需的資源發送回去。主節點將任務以及資源需求一併發送給從節點，後者會將這些信息發送給框架調度器，框架調度器會負責啓動這些任務。集羣中剩餘的資源能夠自由分配給其它的框架。接下來，只要現有的任務完成了而且集羣中的資源又從新變爲可用的，分配資源的過程會隨着時間不斷地重複。須要注意的是，框架不會去說明本身須要多少資源，若是沒法知足它所請求的資源的話，它能夠拒絕這些請求。爲了提升這個過程的效率，Mesos讓框架能夠本身設置過濾器，主節點在分配資源以前總會首先檢查這個條件。在實踐中，框架可使用延遲調度，先等待一段時間，待獲取到持有它們所需數據的節點後再進行計算。

圖2.5  Mesos的架構

一旦資源分配好了，Mesos會當即提供給框架。框架響應此次請求可能會須要必定的時間。這得確保資源是加鎖的，一旦框架接受了此次分配後資源是當即可用的。若是框架長時間沒有響應的話，資源管理器（RM）有權撤銷此次分配。

資源分配

資源分配模塊是可插拔的。目前一共有兩種實現——一種是Ghodsi等人（2011）提出的主導資源公平（Dominant Resource Fairness, DRF）策略。Hadoop中的公平調度器（https://issues. apache.org/jira/browse/HADOOP-3746）會按照節點的固定大小分區（也被稱爲槽）的粒度來分配資源。這樣作的效率會差，尤爲是在現代的多核處理器的異構計算環境中。DRF是最小-最大公平算法在異構資源下的一個泛化。須要注意的是，最大最小算法是一個常見的算法，它擁有許多變種好比循環以及加權公平排隊，但它一般都用於同類的資源。DRF算法會確保在用戶的主導資源中使用最大最小策略。（CPU密集型做業的主導資源是CPU，而IO密集型做業的主導資源則是帶寬）。DRF算法中的一些有趣的特性列舉以下：

• 它是公平的，而且吸引用戶的一點是，它能保證若是全部資源都是靜態平均分佈的話，不會偏向任何一個用戶。

• 用戶謊報資源需求沒有任何好處。

• 它具備帕累託效率，從某種意義上來講，系統資源利用率最大化且服從分配約束。

框架能夠經過API調用獲取到保證分配給它們的資源大小。當Mesos必需要殺掉一些用戶任務的時候，這個功能就頗有用了。若是框架分配的資源在確保的範圍內的話，它的進程就不會被Mesos殺掉，若是超出了閾值，Mesos就會殺掉它的進程。

隔離

Mesos使用Linux或者Solaris容器提供了隔離功能。傳統的基於hypervisor的虛擬化技術，好比基於內核的虛擬機（KVM），Xen(Barham等2003)，或者VMware，都是由基於宿主操做系統實現的虛擬機監控器組成的，這個監控器提供了虛擬機全部的硬件仿真。如此說來，每一個虛擬機都有本身專屬的操做系統，這是和其它虛擬機徹底隔離開來的。Linux容器的方式是一種被稱爲操做系統級虛擬化的技術。操做系統級虛擬化會使用隔離用戶空間實例的概念來建立一個物理機器資源的分區。本質上而言，這種方法則再也不須要基於hypervisor的虛擬化技術中所需的客戶操做系統了 。也就是說，hypervisor工做於硬件抽象層，而操做系統級虛擬化工做於系統調用層。然而，給用戶提供的抽象是指每一個用戶空間實體都會運行本身八專屬的獨立的操做系統。操做系統級虛擬化的不一樣實現會略有不一樣，Linux-VServer是工做於chroot之上的，而OpenVZ則是工做於內核命名空間上。Mesos使用的是LXC，它經過cgroups（進程控制組）來進行資源管理，並使用內核命名空間來進行隔離。Xavier等人（2013）對它作了一份詳細的性能評估報告，結果以下：[1]

 

• 從測試CPU性能的LINPACK基準測試(Dongarra 1987)來看，LXC的方式要優於Xen。

• 進行STREAM基準測試的時候，Xen的內存開銷要明顯大於LXC(接近30%)，然後者能提供接近原生的性能表現。

• 進行IOzone基準測試時，LXC的讀，重複讀，寫，重寫操做的性能接近於本機的性能，而Xen會產生明顯的開銷。

• 使用LXC進行NETPIPE基準測試的網絡帶寬性能接近本機性能，而Xen的開銷幾乎增長了40%。

• 因爲使用了客戶機操做系統，在Isolation Benchmark Suite (IBS)測試中，LXC的隔離性與Xen相比要較差。一個稱爲fork炸彈（fork bomb）的特殊測試（它會不斷地重複建立子進程）代表，LXC沒法限制當前建立的子進程數。

容錯性

Mesos爲主節點提供容錯的方式是使用zookeeper（Hunt 等2010）的熱備用配置來運行多個主節點，一旦主節點崩潰的話，就會選舉出新的主節點。主節點的狀態由三部分組成——它們分別是，活動從節點，活動框架，以及運行任務列表。新的主節點能夠從從節點和框架調度器的信息中重構自身的狀態。Mesos還會將框架執行器及任務報告給對應的框架，框架能夠根據自身的策略來獨立地處理失敗。Mesos還容許框架註冊多個調度器，一旦主調度器失敗了，能夠去鏈接從調度器。然而，框架得確保不一樣調度器的狀態是同步的。

[1] 熟悉UNIX操做系統的讀者會記得，chroot是一個改變當前工做進程樹根目錄的命令，它會建立一個叫」chroot監獄」的環境來提供文件級別的隔離。

原創文章，轉載請註明： 轉載自併發編程網 – ifeve.com