解析Google集群資源管理系統Omega

　　1. 背景

　　Google的第一代/第二代集群(資源)管理系統被稱為Borg，Borg設計細節因零零星星出現在各種文章中而知名，但一直未公開(比如發一篇paper)。然而，我們可從騰訊公布的Torca(Torca是google華人老員工朱會燦加入搜搜后，仿照google borg開發的資源管理系統, 鏈接是：“Torca：Typhoon上的分布式集群調度系統”)設計文檔中可猜測一二。

　　而在近期，Google公布了它的下一代集群管理系統Omega(下載地址)的設計細節。論文中談到Google經歷的三代資源調度器的架構，分別是中央式調度器架構(類似于Hadoop JobTracker，但是支持多種類型作業調度)、雙層調度器架構(類似于Apache Mesos和Hadoop YARN)和共享狀態架構(就是Omega)，并分別討論了這幾個架構的優缺點。同Google公布的其他系統類論文不同，這次它并沒有公布Omega的設計架構，只是介紹了它的資源管理組件的設計思想和關鍵技術，個人認為這主要是因為Omega整體架構與現有的資源管理系統，比如Apache Mesos，非常類似(比如各個slave上會部署一個代理用戶接收任務，向master匯報任務狀態和資源使用情況等)，主要不同集中在資源管理器上，所以重點介紹這個組件。

　　另外，從論文作者看，Omega主要是由劍橋大學和加州大學伯克利分校的兩個實習生在google實習時完成的。

　　2. 集群管理(或者叫資源管理)系統的設計動機

　　集群資源管理系統是對底層硬件的進一步抽象，它屏蔽了硬件的異構性，對上層各種應用提供資源統一管理和調度。從當前公認的云計算劃分看，它屬于IAAS(Infrastructure-as-a- Service)。

　　我在“淺談Borg/YARN/Mesos/Torca/Corona一類系統”一文中已經詳細介紹了這類系統的設計動機，主要有兩個，分別是提高系統利用率和服務自動化部署，google在Omega論文中也談到了這些。

　　這類系統不同于現在的Hadoop，Hadoop運行的任務是快短類型的，可以運行在任何很爛的機器上，一旦任務失敗后，可以很快地將之調度運行到另外一個機器上;而類似于Omega或者Mesos的資源管理系統則不同，它不僅要運行這種短類型的任務，更多的是運行一些長類型的服務，比如web service、MySQL Server等，對于這類服務，Omega應盡量將其調度到一個性能穩定可靠的節點上，這通常是通過跟蹤每個節點的歷史表現情況判斷節點的穩定性和可靠性實現的，比如，如果你向通過Omega運行一個大約工作1個月的web service(一個月后可能會棄用)，那么，Omega會通過分析歷史數據，得到一個月內出現故障的可能性最低的節點，并將該節點的資源分配給該web service，而對于一個MapReduce作業，可將任何節點分配給他，但從資源合理使用上看，應盡可能將一些表現差的節點分配給MapReduce作業或者一些性能好的節點上的瑣碎資源分配給它。

　　3. 三類集群管理系統

　　Omega論文描述了Google經歷的三代資源管理系統，并探討了各自的優缺點，這三代系統分別如下：

　　(1) 中央式調度器(Monolithic scheduler)

　　中央式調度器的特點是，資源的調度和作業的管理功能全部放到一個進程中完成，開源界典型的代表是Hadoop JobTracker的實現。這種設計方式的缺點很明顯，擴展性差：首先，集群規模受限，其次，新的調度策略難以融入現有代碼中，比如之前僅支持MapReduce作業，現在要支持流式作業，而將流式作業的調度策略嵌入到中央式調度器中是一項很難的工作。

　　Omega論文中提到了一種對中央式調度器的優化方案：將每種調度策略放到單獨一個路徑(模塊)中，不同的作業由不同的調度策略進行調度。這種方案在作業量和集群規模比較小時，能大大縮短作業相應時間，但由于所有調度策略仍在一個集中式的組件中，整個系統擴展性沒有變得更好。

　　(2) 雙層調度器(Two-level scheduler)

　　為了解決中央式調度器的不足，雙層調度器是一種很容易想到的解決之道(實際上是分而治之策略或者是策略下放機制)。雙層調度器仍保留一個經簡化的中央式調度器，但調度策略下放到各個應用程序調度器完成。這種調度器的典型代表是Apache Mesos和Hadoop YARN。Omega論文重點介紹了Mesos，Mesos是twitter開源的資源管理系統，它的詳細設計架構我已在多篇博文中進行了介紹，在此簡要介紹一下：

　　Mesos資源管理部分由兩部分組成：分別是Mesos Master和Mesos Slave，其中，Mesos Slave是每個節點上的代理，負責向Master匯報信息和接收并執行來自Master的命令，而Master則是一個輕量級中央化的資源管理器，負責管理和分配整個集群中的資源。如果一個應用程序想通過Mesos資源管理系統申請和使用資源，需編寫兩個組件：框架調度器和框架執行器，其中，框架調度器負責從Mesos Master上獲取資源、將資源分配給自己內部的各個應用程序，并控制應用程序的執行過程;而框架執行器運行在Mesos Slave中，負責運行該框架中的任務。當前很多框架可以接入Mesos中，包括Hadoop、MPI、Spark等。

　　雙層調度器的特點是，各個框架調度器并不知道整個集群資源使用情況，只是被動的接收資源;Mesos Master僅將可用的資源推送給各個框架，而框架自己選擇使用還是拒絕這些資源;一旦框架(比如Hadoop JobTracker)接收到新資源后，再進一步將資源分配給其內部的各個應用程序(各個MapReduce作業)，進而實現雙層調度。

　　雙層調度器的缺點是：

　　1) 各個框架無法知道整個集群的實時資源使用情況。

　　很多框架不需要知道整個集群的實時資源使用情況就可以運行的很順暢，但是對于其他一些應用，為之提供實時資源使用情況可以為之提供潛在的優化空間，比如，當集群非常繁忙時，一個服務失敗了，是選擇換一個節點重新運行它呢，還是繼續在這個節點上運行?通常而言，換一個節點可能會更有利，但是，如果此時集群非常繁忙，所有節點只剩下小于5GB的內存，而這個服務需要10GB內存，那么換一個節點可能意味著長時間等待資源釋放，而這個等待時間是無法確定的。

　　2) 采用悲觀鎖，并發粒度小。

　　在數據庫領域，悲觀鎖與樂觀鎖爭論一直不休，悲觀鎖通常采用鎖機制控制并發，這會大大降低性能，而樂觀鎖則采用多版本并發控制(MVCC ,Multi-Version Concurrency Control)，典型代表是MySQL innoDB，這種機制通過多版本方式控制并發，可大大提升性能。在Mesos中，在任意一個時刻，Mesos資源調度器只會將所有資源推送給任意一個框架，等到該框架返回資源使用情況后，才能夠將資源推動給其他框架，因此，Mesos資源調度器中實際上有一個全局鎖，這大大限制了系統并發性。

原文轉自：http://blogread.cn/it/article/6387?f=wb