154
魔獸
顛覆大數據分析之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監獄”的環境來提供文件級別的隔離。
最後更新：2017-05-22 20:03:09