摘要：本文重點講解了基於v1.1.0的目標作業資源預留特性的設計和最佳實踐。講解過程中，全面介紹了特性設計過程中的考量因素和算法設計。
資源預留（Reservation）是批處理系統的一類常見需求，也是公平性調度（Fair Scheduling）的補充。從不同維度來看，資源預留可以分爲搶佔式預留和非搶佔式預留、作業資源預留和隊列資源預留、即時預留和預見性預留等。自v1.1.0開始，Volcano開始迭代支持資源預留特性。根據社區Roadmap，v1.1.0（已發佈）優先支持作業資源預留，v1.2.0將支持指定隊列資源預留。
場景分析
在實際應用中，常見以下兩種場景：
（1）在集羣資源不足的情況下，假設處於待調度狀態的作業A和B，A資源申請量小於B或A優先級高於B。基於默認調度策略，A將優先於B進行調度。在最壞的情況下，若後續持續有高優先級或申請資源量較少的作業加入待調度隊列，B將長時間處於飢餓狀態並永遠等待下去。
（2）在集羣資源不足的情況下，假設存在待調度作業A和B。A優先級低於B但資源申請量小於B。在基於集羣吞吐量和資源利用率爲核心的調度策略下，A將優先被調度。在最壞的情況下，B將持續飢餓下去。
以上兩種場景出現的根因是缺少一種公平調度機制：保證長期處於飢餓狀態的作業在達到某個臨界條件後被優先調度。造成作業持久飢餓的原因很多，包括資源申請量長時間無法滿足、優先級持續過低、搶佔發生頻率過高、親和性無法滿足（v1.1.0暫不支持此場景）等，以資源申請量無法滿足最爲常見。
特性設計
爲了保證長期處於阻塞狀態的作業能夠擁有公平的調度機會，需要解決兩個主要問題：
- 如何識別目標作業？
- 如何爲目標作業預留資源？
1、目標作業識別
- 作業條件
作業條件的選定可以基於等待時間、資源申請量等單個維度或多個維度的組合。綜合考慮，v1.1.0實現版本選擇優先級最高且等待時間最長的作業作爲目標作業。這樣不僅可以保證緊急任務優先被調度，等待時間長度的考慮默認篩選出了資源需求較多的作業。
- 作業數量
客觀來說，滿足條件的作業通常不止一個，可以爲目標作業組或單個目標作業預留資源。考慮到資源預留必然引起調度器性能在吞吐量和延時等方面的影響，v1.1.0採用了單個目標作業的方式。
- 識別方式
識別方式有兩種：自定義配置和自動識別。v1.1.0暫時僅支持自動識別方式，即調度器在每個調度週期自動識別符合條件和數量的目標作業，併爲其預留資源。後續版本將考慮在全局和Queue粒度支持自定義配置。
2、資源預留算法
資源預留算法是整個特性的核心。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
```自行配置時，請注意以下事項：
- elect action必須配置在enqueue action和allocate action之間
- reserve action必須配置在allocate action之後
由於目標作業的識別、選取、資源預留都是自動化完成，整個過程在用戶側完全透明，可通過scheduler日誌查看到整個過程。
圖2 作業資源預留流程圖
總結展望
本文重點講解了基於v1.1.0的目標作業資源預留特性的設計和最佳實踐。講解過程中，全面介紹了特性設計過程中的考量因素和算法設計。資源預留的細分場景很多，無法一一枚舉。社區後續版本將持續聚焦共性預留需求，完善主要場景下資源預留特性，保證調度公平性。
本文分享自華爲雲社區《Volcano作業資源預留設計原理解讀》，原文作者：技術火炬手。