0. 集群資源管理與任務(wù)調(diào)度系統(tǒng)出現(xiàn)的背景

（1）出現(xiàn)背景
信息技術(shù)快速發(fā)展，各行各業(yè)都慢慢于互聯(lián)網(wǎng)進(jìn)行深度融合，即所謂的“互聯(lián)網(wǎng)+”。為了提供更好的服務(wù)以吸引更多的消費(fèi)者進(jìn)行更多維度的消費(fèi)，各個(gè)互聯(lián)網(wǎng)公司針對不同的場景進(jìn)行深度拓展，而這些業(yè)務(wù)的進(jìn)行全部需要對海量數(shù)據(jù)進(jìn)行大規(guī)模處理。傳統(tǒng)的單機(jī)模式已經(jīng)很難滿足公司和企業(yè)的發(fā)展需求，因此各個(gè)公司開始搭建自己的數(shù)據(jù)中心，但是獨(dú)立搭建的數(shù)據(jù)中心往往存在一定的缺陷，例如：集群的資源利用率低導(dǎo)致資源閑置（業(yè)務(wù)往往是不均衡的，但是公司為了保證用戶體驗(yàn)，不得不配置能夠應(yīng)對洪峰的物理資源），集群的維護(hù)和管理成本也越來越高。因此出現(xiàn)了云服務(wù)商，公司可以將自己的服務(wù)部署在云上，以實(shí)現(xiàn)按需付費(fèi)和彈性調(diào)度，這樣能夠顯著降低公司的運(yùn)營成本，這就是云計(jì)算出現(xiàn)的本質(zhì)原因。對于云計(jì)算來說涉及到多個(gè)方面的內(nèi)容，例如：云存儲系統(tǒng)、云資源管理和任務(wù)調(diào)度系統(tǒng)、網(wǎng)絡(luò)等，下面僅關(guān)注集群資源管理和任務(wù)調(diào)度系統(tǒng)。

（2）目前的挑戰(zhàn)

• 數(shù)據(jù)中心的負(fù)載種類越來越多，有批處理任務(wù)、實(shí)時(shí)查詢?nèi)蝿?wù)、流式服務(wù)等；
• 異構(gòu)負(fù)載的資源需求越來越多樣化，資源約束和偏好越來越復(fù)雜，例如：一個(gè)任務(wù)運(yùn)行需要考慮CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤甚至內(nèi)存帶寬、網(wǎng)絡(luò)帶寬等，還需要考慮數(shù)據(jù)本地行，對物理機(jī)的偏好等；
• 不同類型任務(wù)在實(shí)際調(diào)度過程中不可避免會調(diào)度至相同的數(shù)據(jù)節(jié)點(diǎn)上，這就需要對不同種類的任務(wù)進(jìn)行隔離以減少兩者之間的干擾；
• 調(diào)度過程中的動(dòng)態(tài)資源調(diào)整；
• 任務(wù)搶占模式下的重調(diào)度機(jī)制；
• 故障恢復(fù)；
• 集群中不可知原因的長尾問題；
• 集群資源利用率低，全球云服務(wù)器的平均物理資源利用率低于20%，并且通常在邏輯資源幾乎全部分配的前提下實(shí)際的物理資源利用量不及資源申請總量的一半；

（3）抽象模型
其實(shí)集群資源管理和任務(wù)調(diào)度系統(tǒng)就是一個(gè)復(fù)雜的多維混合背包問題，背包問題應(yīng)該是動(dòng)態(tài)規(guī)劃問題中最經(jīng)典的問題。我們可以將集群中的每個(gè)數(shù)據(jù)節(jié)點(diǎn)比作一個(gè)背包，不同背包不同維度的容量是不同的，將任務(wù)比作是需要放置的物品，任務(wù)所需要的資源就是其花費(fèi)，而任務(wù)運(yùn)行產(chǎn)生的租賃費(fèi)用即為效益。我們需要做的就是在滿足任務(wù)需求的前提下將其放置在適合的背包中，保證集群利用率最高。但是實(shí)際的調(diào)度過程和該算法還有很多不同的地方，例如：

• 背包問題只是一個(gè)推演的過程，我們可以使用一些數(shù)據(jù)結(jié)構(gòu)來保存一些中間結(jié)果來推導(dǎo)出最優(yōu)的分配方式。但是實(shí)際的調(diào)度中來了一個(gè)任務(wù)我們要馬上根據(jù)現(xiàn)有的資源情況進(jìn)行分配，而不能暫時(shí)存留一個(gè)分配方案，等多有任務(wù)都提交完成之后再根據(jù)最優(yōu)的方案進(jìn)行任務(wù)放置；
• 不同的任務(wù)在實(shí)際運(yùn)行過程中有一定的優(yōu)先級，需要保證高優(yōu)先級的任務(wù)最先被保證，這就增加了調(diào)度的難度；
• 任務(wù)在運(yùn)行過程中的資源需求不是一成不變的，有時(shí)候會隨著時(shí)間的變化增加資源需求，這就是彈性調(diào)度需要解決的問題。
• 任務(wù)之間還會產(chǎn)生干擾，并且不同資源敏感度的任務(wù)在不同資源維度上的干擾是不同的；
• 資源管理和調(diào)度系統(tǒng)相當(dāng)于系統(tǒng)的大腦，其要處理所有數(shù)據(jù)節(jié)點(diǎn)和任務(wù)的各種請求，所以其核心的調(diào)度邏輯一定不能太過復(fù)雜，如果考慮所有的情況后再進(jìn)行調(diào)度，勢必會延長調(diào)度時(shí)間，這是任務(wù)執(zhí)行所不能容忍的；
  因此對于一個(gè)資源管理和任務(wù)調(diào)度系統(tǒng)來說，其的職能就表明其不可能是一個(gè)完美的系統(tǒng)，也不可能是一個(gè)通用的系統(tǒng)，需要針對不同的業(yè)務(wù)場景進(jìn)行改造，因此就在工業(yè)界和學(xué)術(shù)界激起了廣泛的研究和探索。

（4）系統(tǒng)演進(jìn)

• 整體上來說分為：單層調(diào)度系統(tǒng)，兩層調(diào)度系統(tǒng)，共享狀態(tài)調(diào)度系統(tǒng)，分布式調(diào)度系統(tǒng)，混合式調(diào)度系統(tǒng)。
• Google提出MR模型
• 批處理框架Hadoop的出現(xiàn)
• 內(nèi)存計(jì)算框架Spark的出現(xiàn)
• 資源管理框架Mesos、YARN、borg的出現(xiàn)
• 基于狀態(tài)共享的Omega
• 完全的分布式調(diào)度器Sparrow
• 中心式和分布式相結(jié)合的混合架構(gòu)Mercury
• 支持快速故障恢復(fù)的Fuxi
• 支持在離線混合調(diào)度的阿里混布系統(tǒng)
• 基于容器的集群管理框架kubernetes的出現(xiàn)

（5）一些分配策略演進(jìn)

• FIFO方式，先來先分配后來后分配；該方式雖然不能保證調(diào)度最優(yōu)但是因?yàn)楹唵卧谀壳暗馁Y源調(diào)度系統(tǒng)中也廣泛使用；
• 公平調(diào)度，將資源分配為多個(gè)不同的資源池，每個(gè)資源池中分配一定比例的資源，任務(wù)在資源池中按照最大最小策略（例如有三個(gè)任務(wù)分別需要的資源是2 ，4， 4 個(gè)單位，而現(xiàn)在總共有9個(gè)單位資源，首先每個(gè)任務(wù)平均得到3個(gè)單位資源，因?yàn)榈谝粋€(gè)任務(wù)多了一個(gè)單位資源，其將多出的一個(gè)單位資源再平均分配給任務(wù)二和三，所以最終任務(wù)一得到2個(gè)單位資源，任務(wù)二得到3.5個(gè)單位資源，任務(wù)三得到3.5個(gè)單位資源）或者加權(quán)的最大最小策略（不同任務(wù)具有不同的優(yōu)先級，所以在平均分配的時(shí)候還需要考慮權(quán)重）進(jìn)行資源分配。
• DRF主資源優(yōu)先調(diào)度。對于一個(gè)任務(wù)來說其主資源是其各維度資源申請中占比最大的資源，例如一個(gè)任務(wù)需要<2CPU,4G>，現(xiàn)在有<4CPU, 10G>,比例為1/2,4/10，那么CPU就是該任務(wù)的主資源。在分配時(shí)候選擇主資源占比最小的任務(wù)進(jìn)行優(yōu)先分配，目前該方式被廣泛的應(yīng)用在各種調(diào)度系統(tǒng)中。有興趣的可以搜索相關(guān)論文查看其詳細(xì)的論證過程。
• 最短作業(yè)優(yōu)先調(diào)度。有研究表明采用最短作業(yè)優(yōu)先調(diào)度的方式可以提高系統(tǒng)資源利用率，其實(shí)也比較容易理解，短作業(yè)需要的資源少所以在分配的時(shí)候可以盡快被滿足，另外短作業(yè)的執(zhí)行時(shí)間少，所以可以盡快的釋放資源，這對于提高集群吞吐量和利用率都有好處。但是這種方式也存在缺點(diǎn)就是長作業(yè)會出現(xiàn)長時(shí)間得不到資源而餓死的情況；另外任務(wù)的執(zhí)行時(shí)間預(yù)先是不可預(yù)知的；
• 能力調(diào)度器，被默認(rèn)應(yīng)用在YARN中。其原理是為不同的用戶組構(gòu)建不同層級的任務(wù)隊(duì)列。在進(jìn)行分配時(shí)，優(yōu)先選擇min{use/分配}的隊(duì)列進(jìn)行分配，在隊(duì)列內(nèi)部按照FIFO的策略進(jìn)行選擇。所以選擇的過程可以總結(jié)為下面步驟：（1）根據(jù)最小滿足比選擇一個(gè)任務(wù)隊(duì)列；（2）在任務(wù)隊(duì)列中選擇一個(gè)具體的任務(wù)；（3）從該任務(wù)中選擇一個(gè)資源申請請求，因?yàn)橐粋€(gè)任務(wù)可能會對應(yīng)多個(gè)資源申請請求；得到這個(gè)請求之后與目前的剩余資源情況進(jìn)行匹配，然后進(jìn)行調(diào)度；
• Tetris算法。考慮到任務(wù)的資源申請需求越來越多樣，需要考慮不同維度資源的權(quán)重問題，其核心思想是將資源申請表示為多維向量，進(jìn)行歸一化處理并與集群剩余資源進(jìn)行點(diǎn)積運(yùn)算，優(yōu)先響應(yīng)權(quán)重最大的資源請求。該方法從算法論證的角度來看能夠在一定程度提高調(diào)度的準(zhǔn)確度和效率，但是其在資源分配過程中需要進(jìn)行較為復(fù)雜的運(yùn)算，采用的并不多。并且目前主流的資源調(diào)度系統(tǒng)中在資源申請方面僅考慮了CPU和內(nèi)存兩個(gè)維度的資源。
• 延遲調(diào)度策略。如果當(dāng)前分配的資源不能夠滿足諸如數(shù)據(jù)本地行等需求，可以暫時(shí)放棄該輪分配，等待下一輪分配，通過設(shè)定一個(gè)放棄次數(shù)閾值來進(jìn)行。

1. 研究點(diǎn)與研究團(tuán)隊(duì)

目前關(guān)于集群資源管理和任務(wù)調(diào)度的研究點(diǎn)很多，例如：資源分配策略的優(yōu)化、支持調(diào)度器的熱插拔、支持資源超售、支持任務(wù)的混合部署、支持對多維度資源的高效隔離、避免任務(wù)之間的干擾、長尾問題的處理、任務(wù)資源需求和運(yùn)行時(shí)畫像、多任務(wù)優(yōu)先級搶占、針對特定場景的調(diào)度系統(tǒng)設(shè)計(jì)、大數(shù)據(jù)系統(tǒng)基準(zhǔn)測試等。
主要研究團(tuán)隊(duì)：

• UC Berkeley的AMP實(shí)驗(yàn)室。開創(chuàng)性的提出多框架資源共享調(diào)度框架Mesos，對后續(xù)工業(yè)界和學(xué)術(shù)界有很大的啟發(fā)和推動(dòng)作用；完全分布式的高吞吐分布式調(diào)度系統(tǒng)Sparrow；內(nèi)存計(jì)算框架Spark；DRF調(diào)度策略；其多項(xiàng)成果被Apache收錄；
• Stanford大學(xué)。通過對任務(wù)的建模分類來進(jìn)行高效的調(diào)度和提高資源利用率，保證服務(wù)質(zhì)量，減少任務(wù)間的性能干擾，研究基于私有云和公有云的高效集群。代表系統(tǒng)有Quasar，Tarcil，Hcloud，Paragon。
• Google。其實(shí)大規(guī)模分布式調(diào)度系統(tǒng)的先導(dǎo)者，分布式系統(tǒng)的三駕馬車：MR,BigTable,GFS。其研究涉及高效的任務(wù)調(diào)度、資源管理和任務(wù)隔離。代表系統(tǒng)有：MR，Borg,Omega。
• 微軟。其研究主要與其內(nèi)部的業(yè)務(wù)緊密相關(guān)，涉及數(shù)據(jù)和查詢密集型的分布式系統(tǒng)和針對Bing搜索任務(wù)單額資源管理和任務(wù)調(diào)度系統(tǒng)，代表：Apollo，JetScope，Mercury，Reserved。
• 澳大利亞墨爾本大學(xué)。其主要進(jìn)行調(diào)度系統(tǒng)優(yōu)化相關(guān)工作，包括云負(fù)載的彈性調(diào)度、基于經(jīng)濟(jì)學(xué)的資源調(diào)度模型、綠色節(jié)能計(jì)算機(jī)制等。代表：GridSim，CloudSim。
• 華中科技大學(xué)的金海教授團(tuán)隊(duì)。主要進(jìn)行資源的虛擬化研究，利用虛擬化技術(shù)來提高負(fù)載均衡、平臺的可用性等。
• 中科院計(jì)算所詹劍鋒團(tuán)隊(duì)。主要進(jìn)行大數(shù)據(jù)系統(tǒng)基準(zhǔn)測試相關(guān)研究，包括數(shù)據(jù)集的生成、負(fù)載的特征分析和分類、負(fù)載集的構(gòu)建、測試指標(biāo)的選擇等方面，代表：BigDataBench，BDGS。

雖然目前針對資源管理和任務(wù)調(diào)度的研究已經(jīng)有很多，但是任然面臨著一些挑戰(zhàn)，這些挑戰(zhàn)主要包括：負(fù)載異質(zhì)性程度越來越高；資源請求的高并發(fā)越來越高；物理資源的利用率得不到顯著的提升。

2. 集群資源管理與任務(wù)調(diào)度系統(tǒng)架構(gòu)

集群資源管理和任務(wù)調(diào)度設(shè)計(jì)兩個(gè)方面：（1）集群管理，主要負(fù)載集群中資源的管理和調(diào)度，給定一個(gè)任務(wù)需求，其能夠在目前情況下給出較優(yōu)的調(diào)度方案；（2）任務(wù)調(diào)度，來了很多的任務(wù)我們應(yīng)該選擇哪個(gè)任務(wù)來進(jìn)行分配；這兩個(gè)方面是相輔相成的關(guān)系，任何一個(gè)方面的優(yōu)化都會帶來集群整體性能的提升。因?yàn)槿蝿?wù)調(diào)度主要涉及調(diào)度策略部分，在上面一節(jié)中有一些論述，并且任務(wù)調(diào)度本身帶有一些隨機(jī)性，所以對其的研究相對較少，下面主要針對資源管理系統(tǒng)進(jìn)行簡要總結(jié)。

總的來說目前的調(diào)度系統(tǒng)可以分為：單層調(diào)度系統(tǒng)、兩層調(diào)度系統(tǒng)、共享狀態(tài)調(diào)度系統(tǒng)、分布式調(diào)度系統(tǒng)和混合式調(diào)度系統(tǒng)。每種調(diào)度系統(tǒng)的存在都有其背景，下面主要從產(chǎn)生的背景、實(shí)現(xiàn)的原理、存在的缺點(diǎn)、典型的系統(tǒng)等方面進(jìn)行闡述。需要注意的是，雖然有這么多種調(diào)度系統(tǒng)，但是目前工業(yè)界使用的大部分還是單層或者兩層的調(diào)度系統(tǒng)，原因是這些架構(gòu)設(shè)計(jì)方案成熟，已經(jīng)經(jīng)歷了多年的線上實(shí)踐，可以平穩(wěn)運(yùn)行；另外就是這些調(diào)度系統(tǒng)擁有比較好的生態(tài)和社區(qū)，能夠兼容現(xiàn)有的生態(tài)，節(jié)省研究的成本。所以一些小型公司大多還是采用Hadoop相關(guān)的系統(tǒng)，只有專門針對云計(jì)算市場的公司，例如阿里云、騰訊云、華為云等會專門研發(fā)自己的調(diào)度系統(tǒng)。

2.1 單層調(diào)度系統(tǒng)

• 產(chǎn)生背景：該調(diào)度系統(tǒng)是大規(guī)模數(shù)據(jù)分析和云計(jì)算出現(xiàn)的雛形，其產(chǎn)生主要就是進(jìn)行大規(guī)模的集群管理以提高數(shù)據(jù)處理能力。
• 基本原理：單層調(diào)度系統(tǒng)融合了資源管理和任務(wù)調(diào)度，有一個(gè)中心式的JobTracker負(fù)責(zé)進(jìn)行集群資源的合理分配、任務(wù)的統(tǒng)一調(diào)度、集群計(jì)算節(jié)點(diǎn)信息的統(tǒng)計(jì)維護(hù)、任務(wù)執(zhí)行過程中的狀態(tài)管理等。
• 優(yōu)點(diǎn)：（1）JobTracker能夠感知集群中所有資源和任務(wù)的執(zhí)行狀態(tài)，能夠進(jìn)行全局最優(yōu)的資源分配和調(diào)度，避免任務(wù)間的干擾，適當(dāng)進(jìn)行任務(wù)搶占，保證任務(wù)計(jì)算效率和服務(wù)質(zhì)量；（2）架構(gòu)模型簡單，只有一個(gè)全局的管理者負(fù)責(zé)進(jìn)行所有管理。
• 缺點(diǎn)：（1）JobTracker作為集群的中心，存在單點(diǎn)瓶頸問題，不能支持大規(guī)模集群；（2）內(nèi)部實(shí)現(xiàn)異常復(fù)雜，因?yàn)橐粋€(gè)調(diào)度器中需要實(shí)現(xiàn)所有的功能模塊；（3）負(fù)載種類的增加會導(dǎo)致系統(tǒng)需要進(jìn)行不斷的迭代，這將增加系統(tǒng)的復(fù)雜性，不利于后期的維護(hù)和擴(kuò)展；（4）只支持單類型的任務(wù)，MR類型的批處理任務(wù)；
• 典型的調(diào)度系統(tǒng)：Hadoop1.*版本；K8S中的kube-scheduler，Paragon,Quasar。

2.2 雙層調(diào)度器

• 產(chǎn)生背景：為了解決單層調(diào)度系統(tǒng)的擴(kuò)展性問題，系統(tǒng)實(shí)現(xiàn)負(fù)責(zé)，需要不斷迭代，不能支持不同類型任務(wù)等缺點(diǎn)
• 實(shí)現(xiàn)原理：將資源管理和任務(wù)調(diào)度解耦。集群資源管理器負(fù)責(zé)維護(hù)集群中的資源信息并將資源分配給具體的任務(wù)，任務(wù)管理器負(fù)責(zé)申請資源并將申請到的資源根據(jù)用戶邏輯進(jìn)行細(xì)分和具體的任務(wù)調(diào)度，節(jié)點(diǎn)管理器負(fù)責(zé)維護(hù)節(jié)點(diǎn)上的所有信息，包括：任務(wù)的運(yùn)行狀況，節(jié)點(diǎn)資源剩余情況等。通過三者之間的協(xié)調(diào)來進(jìn)行資源資源管理和任務(wù)調(diào)度。
• 優(yōu)點(diǎn)：（1）資源管理器只負(fù)責(zé)資源分配，任務(wù)調(diào)度由應(yīng)用完成，提高了系統(tǒng)的擴(kuò)展性和模塊化設(shè)計(jì)；（2）任務(wù)調(diào)度邏輯由具體的任務(wù)完成，能夠提供對不同類型任務(wù)的支持；（3）內(nèi)部實(shí)現(xiàn)模塊化，利于維護(hù)和擴(kuò)展；
• 缺點(diǎn)：（1）任務(wù)無法感知全局的資源情況，只能基于request/offer來進(jìn)行資源獲取，無法有效避免異構(gòu)負(fù)載之間的性能干擾問題；（2）任務(wù)調(diào)度和資源管理解耦不利于實(shí)現(xiàn)多任務(wù)間的優(yōu)先級搶占；（3）所有任務(wù)的資源請求都需要資源管理器進(jìn)行處理，此外其還需要與節(jié)點(diǎn)管理器之間維持通信，導(dǎo)致資源管理器存在單點(diǎn)問題；
• 典型系統(tǒng)：
  • Mesos：最先將資源管理和任務(wù)調(diào)度解耦的offer-based（基于資源供應(yīng)）方案，其有一個(gè)中心的資源管理器，通過采用一些分配策略將資源分配給不同的計(jì)算框架，每個(gè)計(jì)算框架依據(jù)自身的邏輯、資源偏好等采取增量或者All-or-Nothing的方式?jīng)Q定接受還是拒絕分配的資源，計(jì)算框架根據(jù)分配到的資源進(jìn)行下一步的資源分配和任務(wù)執(zhí)行。優(yōu)點(diǎn)：實(shí)現(xiàn)邏輯簡單，兩層調(diào)度；缺點(diǎn)：（1）調(diào)度結(jié)果不是全局最優(yōu)的；（2）存在單點(diǎn)瓶頸，因?yàn)橹醒胭Y源管理器需要逐個(gè)詢問計(jì)算框架是否需要資源；（3）無法支持搶占，資源一旦分配不能夠搶占回收；（4）DRF策略過于理想化；（5）并發(fā)度不高，因?yàn)閷τ谀硞€(gè)slave的資源剩余信息，需要逐個(gè)詢問計(jì)算框架是否需要資源,，基于串行輪詢方式；
  • YARN：基本思想與Mesos相同，但其采用requese-based方式進(jìn)行資源申請，但是在YARN中有三個(gè)模塊，RM負(fù)責(zé)資源管理，AM負(fù)責(zé)任務(wù)資源申請和運(yùn)行；優(yōu)點(diǎn)：（1）支持不同的調(diào)度策略可以保證任務(wù)優(yōu)先級、多租戶容量管理、資源公平共享、彈性伸縮（當(dāng)某個(gè)租戶需要資源時(shí)會搶占共享出去的資源）等；（2）應(yīng)用擴(kuò)展方便，只要根據(jù)提供的AM 相關(guān)API就可以實(shí)現(xiàn)用戶的任務(wù)執(zhí)行邏輯；缺點(diǎn)：存在單點(diǎn)瓶頸問題；故障處理和容錯(cuò)方面不夠完善；對于隔離的支持不夠友好；
  • borg：最早融合資源隔離、資源超售、機(jī)器打分、多任務(wù)優(yōu)先級于一體的資源管理系統(tǒng)。采用二層調(diào)度框架，節(jié)點(diǎn)管理器Borglet定期將自己節(jié)點(diǎn)的資源和任務(wù)執(zhí)行情況匯報(bào)給BorgMaster，每個(gè)應(yīng)用內(nèi)的調(diào)度器根據(jù)自身保存的集群信息做調(diào)度決策，然后由Master決定是否允許其資源申請。在此基礎(chǔ)上其做了一些優(yōu)化，例如：用戶控制訪問、節(jié)點(diǎn)打分、多任務(wù)派遣、多維度資源隔離和進(jìn)程隔離、可插拔的調(diào)度策略等，支持?jǐn)?shù)千種不同的應(yīng)用和服務(wù)，支持?jǐn)?shù)萬臺規(guī)模的集群。但是目前其為閉源系統(tǒng)，這些思想僅能通過論文中獲取，具體的實(shí)現(xiàn)細(xì)節(jié)并不清楚。
  • Fuxi。其是阿里云針對離線作業(yè)的調(diào)度系統(tǒng)，與其相對的是針對在線服務(wù)端額調(diào)度系統(tǒng)Sigma。伏羲的設(shè)計(jì)思想與YARN非常相似，具體的資源分配也相似。但是伏羲針對故障恢復(fù)和可用性方面記性了優(yōu)化擴(kuò)展，能夠基于已有的信息進(jìn)行快速的故障恢復(fù)，并提供多級黑名單機(jī)制。

2.3 共享狀態(tài)調(diào)度器

• 產(chǎn)生背景：前面的調(diào)度器存在一個(gè)問題就是應(yīng)用在進(jìn)行資源申請的時(shí)候無法獲知到集群的全局資源信息，這就導(dǎo)致無法進(jìn)行全局最優(yōu)的調(diào)度，共享狀態(tài)調(diào)度器就是為了解決這個(gè)問題。
• 基本原理：是一個(gè)半分布式的架構(gòu)，通過共享集群狀態(tài)為應(yīng)用提供全局的資源視圖，并采用樂觀并發(fā)機(jī)制進(jìn)行資源申請和釋放，來提高系統(tǒng)的并發(fā)度。
• 優(yōu)點(diǎn)：（1）支持全局最優(yōu)調(diào)度；（2）能夠一定程度的提高并發(fā)度；
• 缺點(diǎn)：（1）高并發(fā)資源請求下會造成頻繁的資源競爭；（2）不利于實(shí)現(xiàn)任務(wù)的優(yōu)先級搶占；（3）資源全局副本維護(hù)模塊存在單點(diǎn)瓶頸；
• 典型系統(tǒng)：
  • Omega:Omega系統(tǒng)中存在多個(gè)調(diào)度器，每個(gè)調(diào)度器中都保存集群資源的副本信息，每個(gè)調(diào)度器可以按照副本信息進(jìn)行任務(wù)調(diào)度，在進(jìn)行資源申請和調(diào)度時(shí)采用樂觀鎖的并發(fā)方式進(jìn)行。目前其只是在模擬環(huán)境下進(jìn)行實(shí)驗(yàn)，并沒有真正在線上進(jìn)行測試。
  • Apollo：綜合考慮了微軟生產(chǎn)平臺Scope的擴(kuò)展性、用戶群間的公平調(diào)度、提高資源利用率、縮短工作時(shí)間（數(shù)據(jù)本地行、任務(wù)特性、任務(wù)預(yù)測）的解決方案。核心包括兩個(gè)方面：（1）利用實(shí)時(shí)系統(tǒng)維護(hù)和更新每個(gè)任務(wù)的等待時(shí)間矩陣作為調(diào)度的基礎(chǔ)和參考，需要考慮子任務(wù)調(diào)度到哪個(gè)計(jì)算節(jié)點(diǎn)上更合適；（2）在計(jì)算節(jié)點(diǎn)設(shè)置獨(dú)立的任務(wù)等待隊(duì)列，采集其上的任務(wù)執(zhí)行情況，依次根據(jù)相關(guān)成本模型進(jìn)行較優(yōu)的調(diào)度決策。其主要針對海量短作業(yè)進(jìn)行設(shè)計(jì)。
  • JetScope：在Apollo的基礎(chǔ)上對交互式數(shù)據(jù)分析任務(wù)進(jìn)行了特殊的優(yōu)化處理，通過Gang調(diào)度策略對低延遲交互式作業(yè)進(jìn)行調(diào)度優(yōu)化。
  • Nomad

2.4 分布式調(diào)度器

• 產(chǎn)生背景：提供系統(tǒng)吞吐率和并發(fā)度
• 基本原理：完全分布式的調(diào)度系統(tǒng)之間沒有通訊協(xié)作，每個(gè)分布式調(diào)度器根據(jù)自己最少的先驗(yàn)知識進(jìn)行最快的決策，每個(gè)調(diào)度器單獨(dú)響應(yīng)任務(wù)，總體的執(zhí)行計(jì)劃于資源分配服從統(tǒng)計(jì)意義。目前還處于學(xué)術(shù)研究階段，尚未真正運(yùn)用至生產(chǎn)環(huán)境中。
• 優(yōu)點(diǎn)：提高吞吐量和并發(fā)度
• 缺點(diǎn)：（1）調(diào)度質(zhì)量得不到保障；（2）資源非公平分配；（3）不能支持多租戶管理；（4）不能避免不同任務(wù)之間的性能干擾；
• 典型系統(tǒng)：Sparrow：是一個(gè)完全的去中心化的分布式調(diào)度系統(tǒng)，通常用于滿足低延遲高吞吐的短任務(wù)場景。系統(tǒng)包含多個(gè)調(diào)度器，這些調(diào)度器分布在集群的節(jié)點(diǎn)上，作業(yè)可以提交給任何一個(gè)分布式調(diào)度器。其核心是采用隨機(jī)調(diào)度模型，利用二次冪采樣原理針對每個(gè)任務(wù)隨機(jī)采樣出兩個(gè)服務(wù)節(jié)點(diǎn)，選擇任務(wù)等待隊(duì)列最短的一個(gè)作為調(diào)度結(jié)果，也可以采用異步預(yù)定的方式進(jìn)行資源調(diào)度。實(shí)驗(yàn)證明近似最優(yōu)解能夠有效的滿足大規(guī)模毫秒調(diào)度性能的需求。

2.5 混合式調(diào)度器

• 出現(xiàn)背景：針對一些特定的混合任務(wù)調(diào)度場景，某些任務(wù)需要比較快的調(diào)度響應(yīng)，而其他任務(wù)不需要很快的調(diào)度響應(yīng)，但是需要保證調(diào)度質(zhì)量。
• 基本原理:設(shè)計(jì)兩條資源請求和任務(wù)調(diào)度路徑，保留兩層調(diào)度的優(yōu)點(diǎn)，同時(shí)兼顧分布式調(diào)度器的優(yōu)勢。對于沒有資源偏好且響應(yīng)要求高的任務(wù)采用分布式調(diào)度器，對于資源調(diào)度質(zhì)量要求較高的采用中央資源管理器進(jìn)行資源分配。
• 優(yōu)點(diǎn)：（1）能夠針對不同類型的任務(wù)進(jìn)行不同方式的調(diào)度；（2）為應(yīng)用層提供靈活的接口和性能保障；
• 缺點(diǎn)：復(fù)雜化了計(jì)算框架層的業(yè)務(wù)邏輯；調(diào)度系統(tǒng)內(nèi)部也需要針對兩種不同的調(diào)度器進(jìn)行協(xié)同處理；
• 典型調(diào)度系統(tǒng)：
  • Mercury:微軟的混合調(diào)度機(jī)制，中心式調(diào)度器對調(diào)度質(zhì)量要求較高的作業(yè)進(jìn)行公平的資源分配，分布式調(diào)度器對時(shí)間敏感和吞吐率要求高的作業(yè)進(jìn)行調(diào)度。
  • Tracil在Sparrow基礎(chǔ)上增加了訪問控制模型，結(jié)合QoS感知對負(fù)載進(jìn)行建模和性能評估指定訪問控制策略，確保任務(wù)可以快速獲取到資源并執(zhí)行，提升系統(tǒng)并發(fā)度和響應(yīng)時(shí)間提高集群資源利用率。

2.6 總結(jié)

目前主流的開源調(diào)度系統(tǒng)比較（結(jié)構(gòu)，資源維度，多調(diào)度器，支持可插拔，優(yōu)先級搶占，重調(diào)度，資源超售，資源評估，避免干擾）：

• Kubernetes：單層，支持多維資源，可插拔，資源超售
• Swarm：單層，支持多維資源
• YARN：單層/兩層，CPU和內(nèi)存，多調(diào)度器，可插拔
• Mesos:兩層，多維，多調(diào)度器，可插拔，資源超售
• Nomad：共享狀態(tài)，多維，可插拔
• Sparrow：完全分布式，固定槽位
• Borg:優(yōu)先級搶占，重調(diào)度，資源超售，資源評估
• Omega：支持除了避免干擾的所有特征
• Apollo：多調(diào)度器，可插拔，優(yōu)先級搶占，重調(diào)度
• 選用何種調(diào)度架構(gòu)需要根據(jù)具體的應(yīng)用場景結(jié)合不同調(diào)度框架的特點(diǎn)進(jìn)行判斷。目前調(diào)度系統(tǒng)存在的問題主要包括：功能缺失、資源利用率不佳、任務(wù)特征不可預(yù)測、性能干擾降低執(zhí)行效率、調(diào)度器性能較弱。

3. 工業(yè)界相關(guān)系統(tǒng)

• 公司+市場份額+其調(diào)度系統(tǒng)
• 阿里云45.5%，Fuxi，Sigma，混布系統(tǒng)，Zeus（宙斯）系統(tǒng)
• 騰訊云10.3%， VStation
• 中國電信7.6%，天翼云
• 金山云6.5%
• AWS5.4%
• UCloud 5.3%
• 微軟 5.0%
• 中國聯(lián)通 5.0%
• IBM 3.0%
• 華為云 0.9%
• 國云
• 百度云
• 京東云，京東阿基米德

總結(jié)

以上是生活随笔為你收集整理的集群资源管理与任务调度系统综述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。