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是推ter開源的資源管理系統，它的詳細設計架構我已在多篇博文中進行了介紹，在此簡要介紹一下：

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資源調度器中實際上有一個全局鎖，這大大限制了系統并發性。

（3） 共享狀態調度器（Shared State Scheduler）

為了克服雙層調度器的以上兩個缺點，Google開發了下一代資源管理系統Omega，Omega是一種基于共享狀態的調度器，該調度器將雙層調度 器中的集中式資源調度模塊簡化成了一些持久化的共享數據（狀態）和針對這些數據的驗證代碼，而這里的“共享數據”實際上就是整個集群的實時資源使用信息。 一旦引入共享數據后，共享數據的并發訪問方式就成為該系統設計的核心，而Omega則采用了傳統數據庫中基于多版本的并發訪問控制方式（也稱為“樂觀 鎖”, MVCC, Multi-Version Concurrency Control），這大大提升了Omega的并發性。

由于Omega不再有集中式的調度模塊，因此，不能像Mesos或者YARN那樣，在一個統一模塊中完成以下功能：對整個集群中的所有資源分組，限 制每類應用程序的資源使用量，限制每個用戶的資源使用量等，這些全部由各個應用程序調度器自我管理和控制，根據論文所述，Omega只是將優先級這一限制 放到了共享數據的驗證代碼中，即當同時由多個應用程序申請同一份資源時，優先級最高的那個應用程序將獲得該資源，其他資源限制全部下放到各個子調度器。

引入多版本并發控制后，限制該機制性能的一個因素是資源訪問沖突的次數，沖突次數越多，系統性能下降的越快，而google通過實際負載測試證明，這種方式的沖突次數是完全可以接受的。

Omega論文中談到，Omega是從Google現有系統上演化而來的。既然這篇論文只介紹了Omega的調度器架構，我們可推測它的整體架構類 似于Mesos，這樣，如果你了解Mesos，那么可知道，我們可以通過僅修改Mesos的Master將之改造成一個Omega。

4. 總結

除了以上討論的幾點外，Omega論文還談到了集群管理系統的其他方面，比如不同的資源分配方式的優缺點，當前有兩種資源分配方式，分別 是：“all-or-nothing”和“incremental placement”，在此舉例說明：一個任務需要2GB內存，而一個節點剩余1GB，若將這1GB內存分配給該任務，則需等待將節點釋放另外1GB內存 才可運行該任務，這種方式稱為“incremental placement”，Hadoop YARN采 用了這種增量資源分配的方式，而如果只為該任務選擇剩余節點超過2GB內存的節點，其他不考慮，則稱為“all-or-nothing”，Mesos和 Omega均采用了這種方式。兩種方式各有優缺點，“all-or-nothing”可能會造成作業餓死（大資源需求的任務永遠得到不需要的資源），而 “incremental placement”會造成資源長時間閑置，同時可也能導致作業餓死，比如一個服務需要10GB內存，當前一個節點上剩余8GB，調度器將這些資源分配給 它并等待其他任務釋放2GB，然而，由于其他任務運行時間非常長，可能短時間內不會釋放，這樣，該服務將長時間得不到運行。

從Omega論文發表時間和使用的數據時間可看出，Omega在google內部是一個比較新的系統，而開源界（Mesos，YARN）的類似系統 已經在開發中，雖然當前不穩定，但穩定版不久將推出，由于Omega與Mesos/YARN架構的不同主要體現在資源分配模塊，因此，我們很容易通過改造 Mesos或者YARN的“Resource Master”模塊將其改造成一個類似于Omega的系統。我說這句話的意思是，開源軟件已走得很快，普通公司，如果人力不足的話，就跟著開源走吧。

5. 推薦閱讀

（1）http://www.wired.com/wiredenterprise/2013/04/google-john-wilkes-new-hackers/

（2）Multi-agent Cluster Scheduling for Scalability and Flexibility

（3）Omega: flexible, scalable schedulers for large compute clusters

（4）Return of the Borg: How 推ter Rebuilt Google’s Secret Weapon

（5）Google Omega PPT： http://vdisk.weibo.com/s/yLOtZ

來自： 轉載自董的博客