顛覆大資料分析之Mesos：叢集調度及管理系統

標籤：

正如前面“Mesos:動機”一節中所述，Mesos的主要目標就是去協助管理不同架構（或者應用棧）間的叢集資源。比如說，有一個業務需要在同一個物理叢集上同時運行Hadoop，Storm及Spark。這種情況下，現有的調度器是無法完成跨架構間的如此細粒度的資源共用的。Hadoop的YARN調度器是一個中央調度器，它可以允許多個架構運行在一個叢集裡。但是，要使用架構特定的演算法或者調度策略的話就變得很難了，因為多個架構間只有一種調度演算法。比如說，MPI使用的是組調度演算法，而Spark用的是延遲調度。它們兩個同時運行在一個叢集上會導致供求關係的衝突。還有一個辦法就是將叢集物理拆分成多個小的叢集，然後將不同的架構獨立地運行在這些小叢集上。再有一個方法就是為每個架構分配一組虛擬機器。正如Regola和Ducom所說的，虛擬化被認為是一個效能瓶頸，尤其是在Alibaba Cloud 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

顛覆大資料分析之Mesos：叢集調度及管理系統