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

　　(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 Twitter Rebuilt Google’s Secret Weapon

　　(5)Google Omega PPT： http://vdisk.weibo.com/s/yLOtZ

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