Yige

Yige

Build

分布式資源管理與調度

分佈式資源管理與調度#

內容來自

  1. 極客時間專欄:《分佈式技術原理與算法解析》
  2. Google 集群管理系統 Omega 解析

分佈式體系結構#

集中式結構#

由一台或多台伺服器組成中央伺服器,系統內的所有數據都存儲在中央伺服器中,系統內所有的業務也均先由中央伺服器處理,由中央伺服器統一進行資源和任務調度

  • Google Borg
  • Kubernetes
  • Mesos

非集中式結構#

服務的執行和數據的存儲被分散到不同的伺服器集群,伺服器集群間通過消息傳遞進行通信和協調。相比於集中式結構,非集中式結構就降低了某一個或者某一簇計算機集群的壓力,在解決了單點瓶頸和單點故障問題的同時,還提升了系統的並發度,比較適合大規模集群的管理

  • Akka 集群
  • Redis 集群
  • Cassandra 集群

調度架構之單體調度器#

單體調度器的特點是,資源的調度和作業的管理功能全部放到一個進程中完成,開源界典型的代表是Hadoop JobTracker的實現

缺點
擴展性差:首先,集群規模受限,其次,新的調度策略難以融入現有代碼中,比如之前僅支持 MapReduce 作業,現在要支持流式作業,而將流式作業的調度策略嵌入到單體調度器中是一項很難的工作

優化方案
將每種調度策略放到單獨一個路徑(模塊)中,不同的作業由不同的調度策略進行調度。這種方案在作業量和集群規模比較小時,能大大縮短作業相應時間,但由於所有調度策略仍在一個集中式的組件中,整個系統擴展性沒有變得更好

調度架構之雙層調度器#

雙層調度器仍保留一個經簡化的中央式調度器,但調度策略下放到各個應用程序調度器完成。這種調度器的典型代表是 Mesos 和 YARN

雙層層調度器的職責分別是:第一層調度器負責管理資源並向框架分配資源,第二層調度器接收分佈式集群管理系統中第一層調度器分配的資源,然後根據任務和接收到的資源進行匹配

缺點

  • 各個框架無法知道整個集群的實時資源使用情況

  • 採用悲觀鎖,並發粒度小
    拿 Mesos 來看,Mesos 的資源調度器只會將所有資源推送給任意一個框架,等到該框架返回資源使用情況後,才能夠將資源推動給其他框架,因此,Mesos 資源調度器中實際上有一個全局鎖,這大大限制了系統並發性

調度架構之共享狀態調度器#

該調度器將雙層調度器中的集中式資源調度模塊簡化成了一些持久化的共享數據(狀態)和針對這些數據的驗證代碼,而這裡的 “共享數據” 實際上就是整個集群的實時資源使用信息, 典型代表有 Google 的 Omega、微軟的 Apollo,以及 Hashicorp 的 Nomad 容器調度器

引入共享數據後,共享數據的並發訪問方式就成為該系統設計的核心,例如 Omega 則採用了傳統數據庫中基於多版本的並發訪問控制方式(MVCC),這大大提升了 Omega 的並發性

資源分配方式#

兩種資源分配方式

  • incremental placement
  • all-or-nothing

舉例說明:一個任務需要 2GB 內存,而一個節點剩余 1GB,若將這 1GB 內存分配給該任務,則需等待將節點釋放另外 1GB 內存才可運行該任務,這種方式稱為“incremental placement”, Hadoop YARN 採用了這種增量資源分配的方式。
而如果只為該任務選擇剩余節點超過 2GB 內存的節點,其他不考慮,則稱為“all-or-nothing”,Mesos 和 Omega 均採用了這種方式。

兩種方式各有優缺點,“all-or-nothing” 可能會造成作業餓死(大資源需求的任務永遠得到不需要的資源),而 “incremental placement” 會造成資源長時間閒置,同時可也能導致作業餓死,比如一個服務需要 10GB 內存,現在一個節點上剩余 8GB,調度器將這些資源分配給它並等待其他任務釋放 2GB,然而,由於其他任務運行時間非常長,可能短時間內不會釋放,這樣,該服務將長時間得不到運行。

總結#

image.png
單體調度
由一個中央調度器去管理整個集群的資源信息和任務調度,也就是說所有任務只能通過中央調度器進行調度。
這種調度架構的優點是,中央調度器擁有整個集群的節點資源信息,可以實現全局最優調度。但它的缺點是,無調度並發性,且中央伺服器存在單點瓶頸問題,導致支持的調度規模和服務類型受限,同時會限制集群的調度效率,適用於小規模集群

雙層調度
將資源管理和任務調度分為兩層來調度。其中,第一層調度器負責集群資源管理,並將可用資源發送給第二層調度;第二層調度接收到第一層調度發送的資源,進行任務調度
這種調度架構的優點是,避免了單體調度的單點瓶頸問題,可以支持更大的服務規模和更多的服務類型。但其缺點是,第二層調度器往往只對全局資源信息有部分可觀察性,因此任務匹配算法無法實現全局最優,適用於中等規模集群

共享狀態調度
多個調度器,每個調度器都可以看到集群的全局資源信息,並根據這些信息進行任務調度。相較於其他兩個調度架構來說,共享狀態調度架構適用的集群規模最大。

這種調度架構的優點是,每個調度器都可以獲取集群中的全局資源信息,因此任務匹配算法可以實現全局最優性。但,也因為每個調度器都可以在全局範圍內進行任務匹配,所以多個調度器同時調度時,很可能會匹配到同一個節點,從而造成資源競爭和衝突

雖然 Omega 的論文宣稱可以通過樂觀鎖機制,避免衝突。但在工程實踐中,如果沒有妥善處理資源競爭的問題,則很可能會產生資源衝突,從而導致任務調度失敗。這時,用戶就需要對調度失敗的任務進行處理,比如重新調度、任務調度狀態維護等,從而進一步增加了任務調度操作的複雜度

總結分析如下表格
image.png

載入中......
此文章數據所有權由區塊鏈加密技術和智能合約保障僅歸創作者所有。