眾所周知，集群調(diào)度系統(tǒng)是現(xiàn)代數(shù)據(jù)中心舉足輕重的組件，一個好的調(diào)度器，能提高集群資源利用率，實現(xiàn)自動化部署和高可用，節(jié)約用戶投資，“讓開發(fā)者最大可能地把精力集中到上層業(yè)務(wù)邏輯上”?？紤]到時下各路調(diào)度系統(tǒng)眼花繚亂，小編打算從Google的三代集群調(diào)度架構(gòu)演進(jìn)切入，對十個主流集群調(diào)度系統(tǒng)進(jìn)行分門別類大盤點。
開始盤點前，讓我們先快速回顧一下Google的三代集群調(diào)度架構(gòu)——中央式（Monolithic）、雙層式（Two-level）、共享狀態(tài)式（Shared-state）都有哪些特征？
快速回顧：Google三代集群資源調(diào)度架構(gòu)
早在十多年前，Google就開始使用第一代集群管理Borg技術(shù)管理數(shù)據(jù)中心。2013年，Google發(fā)表的Omega論文（Omega，a scalable scheduler for large compute clusters）詳細(xì)介紹了Google的三代集群資源調(diào)度架構(gòu)：中央式（Monolithic）、雙層式（Two-level）、共享狀態(tài)式（Shared-state）。（見下圖）
http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41684.pdf
（1） 中央式調(diào)度器（Monolithic scheduler）
中央式調(diào)度器實質(zhì)上就是一個單一的調(diào)度agent來負(fù)責(zé)所有請求，通常用在HPC（高性能計算）中。由于將資源的調(diào)度和作業(yè)的管理功能全部放到一個進(jìn)程中完成，擴(kuò)展性較差：首先，集群規(guī)模受限。其次，很難引入新的調(diào)度策略，比如之前僅支持MapReduce作業(yè)，現(xiàn)在要支持流式作業(yè)，而將流式作業(yè)的調(diào)度策略嵌入到中央式調(diào)度器中是一項很難的工作。
（2） 雙層調(diào)度器（Two-level scheduler）
雙層調(diào)度器采用“分層”思想，上層是一個非常輕量級的的中央式調(diào)度器，下層是具體某個應(yīng)用程序的調(diào)度器，如Hadoop、Storm、Spark、MPI等。這樣就可以減小“中心節(jié)點”的壓力，由原來的一個“中心”，變成二層“中心”；而且同一個集群中多種應(yīng)用接入，多種框架混部，有效提高分布式集群的利用率。但是，這種“二級調(diào)度”也有缺陷：各應(yīng)用無法感知集群整體的使用狀況，只能等待上層調(diào)度推送信息；再加上資源分配采用輪詢，在分配過程使用“悲觀鎖”（即PCC，Pessimistic Concurrency Control，悲觀并發(fā)訪問控制方式），并發(fā)粒度小，響應(yīng)稍慢，缺乏一種有效的競爭機(jī)制。
（3）共享狀態(tài)調(diào)度器（Shared-state scheduler）
為克服雙層調(diào)度器的不足，Google提出了共享狀態(tài)調(diào)度。這種調(diào)度器將雙層調(diào)度器中的集中式資源調(diào)度模塊簡化為持久化的“共享數(shù)據(jù)”（狀態(tài)）和針對這些數(shù)據(jù)的驗證代碼——這里的“共享數(shù)據(jù)”實際上就是整個集群的實時資源使用信息。共享狀態(tài)調(diào)度器最典型的代表就是Google的Omega系統(tǒng)，它也可理解為改進(jìn)版的“雙層調(diào)度器”。通過將雙層調(diào)度器中的“共享數(shù)據(jù)”進(jìn)行全局持久化，任何應(yīng)用都可以看到集群資源信息。而且資源申請采用“樂觀鎖”（即MVCC，Multi-Version Concurrency Control，多版本并發(fā)訪問控制方式），優(yōu)先級控制，大大提升并發(fā)性。
現(xiàn)在讓我們基于這三類調(diào)度策略，對時下十個主流集群調(diào)度系統(tǒng)進(jìn)行分門別類大盤點吧！
Monolithic篇
1. Google Borg
Borg作為Google的內(nèi)部集群管理系統(tǒng)已有十多年歷史了，但其細(xì)節(jié)信息一直鮮少公開，直到去年Google發(fā)表的論文（Large-scale cluster management at Google with Borg）才第一次揭開它的神秘面紗。一個Borg集群（即Cell）由一個邏輯中央控制器BorgMaster和若干代理節(jié)點Borglet組成，屬于Monolithic架構(gòu)。（見下圖）
http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/43438.pdf
關(guān)于Borg架構(gòu)的解讀，網(wǎng)上有一個有趣的段子，它將Borg架構(gòu)比作黑社會，BorgMaster是黑老大，Borglet是底下的一幫小弟，而Borg的一套調(diào)度流程就像黑社會運作一趟毒品交易。（見下圖，轉(zhuǎn)自網(wǎng)絡(luò)）
2. Kubernetes
Kubernetes是一個容器集群的編排管理系統(tǒng)，主要面向跨Docker主機(jī)場景之下容器集群的統(tǒng)一管理，據(jù)Wikipedia介紹，最初是由Google在2014年提出的開源項目，其開發(fā)設(shè)計思想深受Google的Borg系統(tǒng)影響。
Kubernetes屬于Monolithic架構(gòu)，Kubernetes Master提供了集群統(tǒng)一視圖的中心控制點，Node節(jié)點又稱作Minion，負(fù)責(zé)運行Master交付的任務(wù)。
3. Docker Swarm
Docker Swarm是Docker公司在2014年12月初發(fā)布的一套管理Docker集群的工具。一套Docker Swarm架構(gòu)由一個Swarm manager和一組Swarm節(jié)點組成，Swarm manager上運行Swarm daemon，用戶只需跟Swarm manager通信，然后Swarm manager根據(jù)discovery service的信息選擇一個Swarm節(jié)點來運行容器。典型的Monolithic架構(gòu)。
4. 騰訊 Torca
Torca作為騰訊Typhoon云平臺的資源調(diào)度子系統(tǒng)，已經(jīng)在網(wǎng)頁搜索、廣告方面廣泛應(yīng)用。Torca屬于Monolithic架構(gòu)，一個Torca集群由一個Central Manager和若干Execute Server組成。Central Manager是集群任務(wù)調(diào)度中心，Execute Server接收任務(wù)并負(fù)責(zé)相應(yīng)執(zhí)行。
5. 阿里飛天伏羲
“飛天”是阿里巴巴的云計算平臺，其中分布式調(diào)度系統(tǒng)被命名為“伏羲”（代號Fuxi）。伏羲主要負(fù)責(zé)集群資源管理和任務(wù)調(diào)度，屬于Monolithic架構(gòu)。系統(tǒng)有一個“Fuxi Master”的集群控制中心，其余每個Slave節(jié)點上會運行一個“Fuxi Agent”的守護(hù)進(jìn)程，F(xiàn)uxi Agent除了管理節(jié)點上運行的任務(wù)外，還負(fù)責(zé)收集該節(jié)點上的資源使用情況，并匯報給Fuxi Master。Fuxi Master與Fuxi Agent之間使用Heartbeat機(jī)制，以監(jiān)測節(jié)點健康狀態(tài)。
Two-level篇
1. Apache Mesos
Apache Mesos是2009年加州大學(xué)伯克利分校AMPLab首先開發(fā)出的一款開源集群管理軟件，主要用于搭建高效擴(kuò)展的分布式系統(tǒng)來支持各式各樣不斷增長的Framework。Mesos以Framework的形式，提供兩級調(diào)度機(jī)制，即Two-level scheduler的典型代表。
Mesos Master協(xié)調(diào)全部的Mesos Slave，并確定每個節(jié)點的可用資源，聚合計算跨節(jié)點的所有可用資源的報告，然后向注冊到Master的Framework（作為Master的客戶端）發(fā)出資源邀約。Framework根據(jù)應(yīng)用程序的需求，選擇接受或拒絕來自Master的資源邀約。一旦接受邀約，Master即協(xié)調(diào)Framework和Slave，調(diào)度參與節(jié)點上的任務(wù)，并在容器中執(zhí)行，使得多種類型的任務(wù)可在同一個節(jié)點上同時運行。
下圖為Mesos“兩級調(diào)度機(jī)制”示意圖，圖中只展示了Hadoop和MPI兩種框架類型。
2. Apache Hadoop YARN
Apache Hadoop 是一個開源軟件框架，最初包含HDFS（Hadoop分布式文件系統(tǒng)）和Hadoop MapReduce分布式計算引擎。自2012年8月開始，Apache Hadoop YARN成為Apache Hadoop的一個新子項目，其目的是讓Hadoop數(shù)據(jù)處理能力超越MapReduce。Hadoop YARN提供了一個更加通用的資源管理和分布式應(yīng)用框架，不僅支持Hadoop MapReduce，而且MPI，圖處理，在線服務(wù)（比如Spark、Storm、HBase）等應(yīng)用都可放到Y(jié)ARN上。
注：在 YARN 中，MapReduce 降級為一個分布式應(yīng)用程序的角色（但仍是一個非常流行且有用的角色），現(xiàn)在稱為 MRv2。MRv2 是經(jīng)典 MapReduce 引擎（現(xiàn)在稱為 MRv1）的重現(xiàn)，運行在 YARN 之上。
MRv1屬于Monolithic架構(gòu)，由一個JobTracker和若干TaskTracker組成。JobTracker負(fù)責(zé)資源管理以及Job的生命周期管理，TaskTracker負(fù)責(zé)執(zhí)行JobTracker分配的Task，并周期性向JobTracker匯報Task進(jìn)度及狀態(tài)。（見下圖）
YARN將MRv1中JobTracker的兩大職責(zé)——資源管理和Job管理，分別交給兩個角色負(fù)責(zé)。一個是全局的ResourceManager，一個是每個應(yīng)用一個的ApplicationMaster。ResourceManager是整個系統(tǒng)仲裁應(yīng)用之間資源分配的最高權(quán)威，而每個應(yīng)用一個的ApplicationMaster負(fù)責(zé)向ResourceManager協(xié)商資源，并與NodeManager協(xié)同工作來執(zhí)行和管理task。（見下圖）
最近CamSaS項目組（Cambridge System at Scale）在Cambridge官網(wǎng)發(fā)表了一篇博客——The evolution of cluster scheduler architectures，文中認(rèn)為YARN屬于“有限的兩級調(diào)度”。因為YARN的ApplicationMaster只能將應(yīng)用層的Tasks放置在已有容器里，無法挑選資源（除非它向ResourceManager請求的資源遠(yuǎn)超過它的需要）。（見下圖）
http://www.cl.cam.ac.uk/research/srg/netos/camsas/blog/2016-03-09-scheduler-architectures.html
但Google在2013年的Omega論文中（Omega，a scalable scheduler for large compute clusters），直接將 YARN歸到了Monolithic架構(gòu)。
Shared-state篇
1. Google Omega
如前所述，Omega使用基于共享狀態(tài)的策略，每個調(diào)度器擁有全局資源視圖，具有整個集群全部負(fù)載信息的完全訪問權(quán)限。Omega中的“元調(diào)度器”（Cell State）維護(hù)著一個全局共享的集群狀態(tài)，而每個調(diào)度器具有一個私有集群狀態(tài)副本。
ACM Queue（美國計算機(jī)學(xué)會ACM發(fā)行的商業(yè)雜志）最近也發(fā)表了一篇文章（Borg, Omega, and Kubernetes：Lessons learned from three container-management systems over a decade），詳細(xì)介紹了Omega的“共享狀態(tài)”調(diào)度以及“樂觀并發(fā)”策略。
http://queue.acm.org/detail.cfm?id=2898444
2. 微軟Apollo
Apollo是已經(jīng)部署在微軟實際生產(chǎn)環(huán)境中的集群調(diào)度系統(tǒng)，每天負(fù)責(zé)上萬臺機(jī)器上數(shù)以百萬計的高并發(fā)計算任務(wù)的調(diào)度和管理。Apollo使用基于共享狀態(tài)的策略。每個調(diào)度器（即Job Manager，負(fù)責(zé)Job的生命周期管理）擁有全局資源視圖，具有整個集群的完全訪問權(quán)限。Process Node負(fù)責(zé)管理所在server上的本地資源和調(diào)度。Resource Monitor負(fù)責(zé)維護(hù)一個全局共享的集群狀態(tài)，即持續(xù)收集集群所有Process Node的負(fù)載信息，向每個Job Manager提供集群狀態(tài)的全局視圖。見下圖，轉(zhuǎn)自Microsoft Research（微軟研究院）關(guān)于Apollo的論文（Apollo: Scalable and Coordinated Scheduling for Cloud-Scale Computing）。
http://research.microsoft.com/pubs/232978/osdi14-paper-boutin.pdf
3. Hashicorp Nomad
Nomad是著名開源公司Hashicorp在2015年9月推出的一款分布式、高可用的開源集群管理工具，專為微服務(wù)和批量處理工作流設(shè)計，支持所有主流操作系統(tǒng)以及虛擬化、容器化或獨立應(yīng)用?，F(xiàn)已在生產(chǎn)環(huán)境使用。Nomad支持跨數(shù)據(jù)中心跨區(qū)域數(shù)千節(jié)點的高擴(kuò)展和任務(wù)調(diào)度，下圖為Nomad跨區(qū)域調(diào)度示意圖，轉(zhuǎn)自Hashicorp官網(wǎng)。
https://www.nomadproject.io/docs/internals/architecture.html
Nomad也是基于共享狀態(tài)的調(diào)度器，它是通過“Plan Queue”來維持一個全局共享的集群狀態(tài)。下圖為Nomad的一個完整Evaluation工作流，轉(zhuǎn)自Hashicorp官網(wǎng)。
聯(lián)系客服
