0. 集群資源管理與任務調度系統出現的背景

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

（2）目前的挑戰

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

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

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

（4）系統演進

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

（5）一些分配策略演進

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

1. 研究點與研究團隊

目前關于集群資源管理和任務調度的研究點很多，例如：資源分配策略的優化、支持調度器的熱插拔、支持資源超售、支持任務的混合部署、支持對多維度資源的高效隔離、避免任務之間的干擾、長尾問題的處理、任務資源需求和運行時畫像、多任務優先級搶占、針對特定場景的調度系統設計、大數據系統基準測試等。
主要研究團隊：

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

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

2. 集群資源管理與任務調度系統架構

集群資源管理和任務調度設計兩個方面：（1）集群管理，主要負載集群中資源的管理和調度，給定一個任務需求，其能夠在目前情況下給出較優的調度方案；（2）任務調度，來了很多的任務我們應該選擇哪個任務來進行分配；這兩個方面是相輔相成的關系，任何一個方面的優化都會帶來集群整體性能的提升。因為任務調度主要涉及調度策略部分，在上面一節中有一些論述，并且任務調度本身帶有一些隨機性，所以對其的研究相對較少，下面主要針對資源管理系統進行簡要總結。

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

2.1 單層調度系統

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

2.2 雙層調度器

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

2.3 共享狀態調度器

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

2.4 分布式調度器

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

2.5 混合式調度器

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

2.6 總結

目前主流的開源調度系統比較（結構，資源維度，多調度器，支持可插拔，優先級搶占，重調度，資源超售，資源評估，避免干擾）：

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

3. 工業界相關系統

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。