摘要:本文重點講解了基於v1.1.0的目標做業資源預留特性的設計和最佳實踐。講解過程當中,全面介紹了特性設計過程當中的考量因素和算法設計。
資源預留(Reservation)是批處理系統的一類常見需求,也是公平性調度(Fair Scheduling)的補充。從不一樣維度來看,資源預留能夠分爲搶佔式預留和非搶佔式預留、做業資源預留和隊列資源預留、即時預留和預見性預留等。自v1.1.0開始,Volcano開始迭代支持資源預留特性。根據社區Roadmap,v1.1.0(已發佈)優先支持做業資源預留,v1.2.0將支持指定隊列資源預留。node
在實際應用中,常見如下兩種場景:算法
(1)在集羣資源不足的狀況下,假設處於待調度狀態的做業A和B,A資源申請量小於B或A優先級高於B。基於默認調度策略,A將優先於B進行調度。在最壞的狀況下,若後續持續有高優先級或申請資源量較少的做業加入待調度隊列,B將長時間處於飢餓狀態並永遠等待下去。性能
(2)在集羣資源不足的狀況下,假設存在待調度做業A和B。A優先級低於B但資源申請量小於B。在基於集羣吞吐量和資源利用率爲核心的調度策略下,A將優先被調度。在最壞的狀況下,B將持續飢餓下去。spa
以上兩種場景出現的根因是缺乏一種公平調度機制:保證長期處於飢餓狀態的做業在達到某個臨界條件後被優先調度。形成做業持久飢餓的緣由不少,包括資源申請量長時間沒法知足、優先級持續太低、搶佔發生頻率太高、親和性沒法知足(v1.1.0暫不支持此場景)等,以資源申請量沒法知足最爲常見。設計
爲了保證長期處於阻塞狀態的做業可以擁有公平的調度機會,須要解決兩個主要問題:日誌
做業條件的選定能夠基於等待時間、資源申請量等單個維度或多個維度的組合。綜合考慮,v1.1.0實現版本選擇優先級最高且等待時間最長的做業做爲目標做業。這樣不只能夠保證緊急任務優先被調度,等待時間長度的考慮默認篩選出了資源需求較多的做業。code
客觀來講,知足條件的做業一般不止一個,能夠爲目標做業組或單個目標做業預留資源。考慮到資源預留必然引發調度器性能在吞吐量和延時等方面的影響,v1.1.0採用了單個目標做業的方式。orm
識別方式有兩種:自定義配置和自動識別。v1.1.0暫時僅支持自動識別方式,即調度器在每一個調度週期自動識別符合條件和數量的目標做業,併爲其預留資源。後續版本將考慮在全局和Queue粒度支持自定義配置。blog
資源預留算法是整個特性的核心。v1.1.0採用節點組鎖定的方式爲目標做業預留資源,即選定一組符合某些約束條件的節點歸入節點組,節點組內的節點從歸入時刻起再也不接受新做業投遞,節點規格總和知足目標做業要求。須要強調的是,目標做業將能夠在整個集羣中進行調度,非目標做業僅可以使用節點組外的節點進行調度。排序
在特性設計階段,社區考慮過如下節點選取算法:規格優先、空閒優先。
規格優先是指集羣中全部節點按照主要規格(目標做業申請資源規格)進行降序排序,選取前N個節點歸入節點組,這N個節點的資源總量知足申請量。這種方式的優勢是實現簡單、鎖定節點數量最小化、對目標做業的調度友好(這種方式鎖定的資源總量每每比申請總量大一些,且做業中各Pod容易彙集調度在鎖定節點,有利於Pod間通訊等);缺點是鎖定資源總量大機率不是最優解、綜合調度性能損失(吞吐量、調度時長)、易產生大資源碎片。v1.1.0的實現採用的是該算法。
空閒優先是指集羣中全部節點按照主要資源類型(目標做業申請資源類型)的空閒資源量進行降序排序,選取前N個節點歸入節點組,這N個節點的資源總量知足申請量。這種方式的優勢是較大機率最快騰出知足要求的資源總量;缺點是集羣空閒資源分佈的強動態性致使節點組不是最優解,所求解穩定性差。
爲了儘量減小鎖定操做對調度器綜合性能的影響,在知足預留資源申請量的前提下,不管採用哪一種節點選取算法,都應保證所選節點數最少。
鎖定方式包括兩個核心考量點:並行鎖定數量、鎖定節點已有負載處理手段。
並行鎖定數量有三個選擇:單節點鎖定、多節點鎖定、集羣鎖定。單節點鎖定是指每一個調度週期內基於當前集羣資源分佈選定一個符合要求的節點歸入節點組。這種方式能夠儘可能減小資源分佈波動對所求解的穩定性的影響,缺點是要通過較多的調度週期才能完成鎖定過程。v1.1.0的實現選擇的是這種方式。以此類推,多節點鎖定是指每一個調度週期內選定X(X>1)個知足條件的節點進行鎖定。這種方式能必定程度上彌補單節點鎖定引入的鎖定時長過長問題,缺點是X不易找到最優值,實現複雜度高。集羣鎖定是指一次性鎖定集羣全部節點,直至目標做業完成調度。這種粗暴的方式實現最爲簡單,目標做業等待時間最短,很是適合超大目標做業的資源預留。
鎖定節點已有負載的處理手段有兩種:搶佔式預留、非搶佔式預留。顧名思義,搶佔式預留將會強制驅逐鎖定節點上的已有負載。這種方式能夠保證最快騰出所需的資源申請量,但會對已有業務形成重大影響,所以僅適用於緊急任務的資源預留。非搶佔式預留則在節點鎖定後不作任何處理,等待運行在其上的負載自行結束。v1.1.0採用的是非搶佔式預留。
圖1 做業資源預留設計
基於v1.1.0的實現,社區當前僅支持目標做業的自動化識別與資源預留。爲此,新引入了2個action和1個plugin。elect action用於選取目標做業;reserve action用於執行資源預留動做;reservation plugin中實現了具體的目標選取和資源預留邏輯。
若要開啓資源預留特性,將以上action和plugin配置到volcano的配置文件中便可。下面是推薦配置樣例:
``` yaml actions: "enqueue, elect, allocate, backfill, reserve" tiers: - plugins: - name: priority - name: gang - name: conformance - name: reservation - plugins: - name: drf - name: predicates - name: proportion - name: nodeorder - name: binpack ```
自行配置時,請注意如下事項:
因爲目標做業的識別、選取、資源預留都是自動化完成,整個過程在用戶側徹底透明,可經過scheduler日誌查看到整個過程。
圖2 做業資源預留流程圖
本文重點講解了基於v1.1.0的目標做業資源預留特性的設計和最佳實踐。講解過程當中,全面介紹了特性設計過程當中的考量因素和算法設計。資源預留的細分場景不少,沒法一一枚舉。社區後續版本將持續聚焦共性預留需求,完善主要場景下資源預留特性,保證調度公平性。
本文分享自華爲雲社區《Volcano做業資源預留設計原理解讀》,原文做者:技術火炬手。