[[222402]]

　　為了保證系統的在線交易服務順利運轉，最初幾年，阿里都是在雙 11 大促來臨之前大量采購機器儲備計算資源，雙 11 之后資源大量閑置。是否能把計算任務與在線服務進行混合部署，在現有彈性資源基礎上提升集群資源利用率，降低雙 11 資源新增成本？阿里巴巴研發效能事業部容器調度域，測試開發專家何穎為我們揭秘。

　　寫在前面

　　Sigma 是阿⾥巴巴全集團范圍的 Pouch 容器調度系統。2017 年是 Sigma 正式上線以來第⼀次參與雙 11，在雙 11 期間成功⽀撐了全集團所有容器（交易線中間件、數據庫、⼴告等⼆⼗多業務）的調配，使雙 11IT 成本降低 50%，是阿⾥巴巴運維系統重要的底層基礎設施。

　　Sigma 已經是阿里全網所有機房在線服務管控的核心角色，管控的宿主機資源達到幾十萬量級，重要程度不言而喻，其算法的優劣程度影響了集團整體的業務穩定性，資源利用率。

　　Sigma-cerebro 系統是 Sigma 系統的調度模擬系統，可以在無真實宿主機的情況下，以最小成本，最快速度模擬線上 1：1 機器資源和請求要求的調度需求完成情況，從各個角度進行擴縮容算法的評測。在對抗系統資源碎片化，在有限資源條件下大批量擴縮容，預期外超賣等問題的過程中，系統一步步發展成現在的樣子。

　　在 2017 年雙 11 中，依靠 cerebro 進行預處理，Sigma 成功完成了雙 11 一鍵建站，30 分鐘內完成建站任務，且系統靜態分配率從 66% 提升到 95%，大大提升了資源利用的有效性。

　　什么是好的調度？最理想的情況如何？

　　我認為在滿足容器的資源運行時，最小化互相干擾的前提下，越能夠節省集群整體資源，提高利用率，在固定時間內完成分配的調度系統，較符合理想的調度系統。

　　那么一個調度算法仿真評測的系統，要做到什么程度？

• 要能夠真實模擬生產的大規模環境和復雜需求；

• 要盡量節省模擬的開銷，避免模擬的風險；

• 從靜態和動態的角度都能夠給***個問題以定性定量的回答。

　　在這個基礎上，我們來看看 Sigma 的副產品，Sigma-cerebro 調度模擬器。

　　調度模擬器設計

　　總的來說，目前的模擬器是一個使用 1：1 生產環境數據來進行調度分配仿真的工具平臺。

　　該仿真目前是純數據層面的，動態預測也是基于靜態數據的。原因是要 1：1 模擬線上，而線上動輒萬臺宿主，是不可能真的動用這么多資源的。另外后續也計劃搞小規模的池子進行全動態的 runtime 仿真和評測。

　　模擬器需要同時滿足很多需求，因此分成了多套環境，有一個環境池。每個環境池，僅需要 3 個容器即可完成全套任務。

　　背景數據是存放在 OSS 中的，因為一套背景數據可能非常大，另外解耦和線上的依賴將風險降到***，因此仿真時僅需要從 OSS 取數據即可。在各種仿真下，用戶需要的服務是不同的，因此模擬器設計了幾個不同的模式來進行支持。這些模式即可對應前面的 4 個需求。

　　目前已有的模式包括：擴、縮容算法評測模式，預分配模式，問題復現模式。

　　對于如何衡量調度分配結果的優劣問題來說，模擬器支持將算法配置透出，支持用戶自定義水位配置和調度器，模擬器會負責將一套線上 1：1 宿主機數據，應用要求配置等寫入該環境，并將用戶的算法配置寫入，然后將每次相同的請求發送到該環境，待結束后用同樣的方式進行打分。

　　針對同樣的一份背景數據，不同的算法配置和版本會產生不同的打分，我們就可以觀察他們之間的優劣。如下圖：

　　另外，可以快速在模擬器環境下進行資源的預分配，之后精準按照本次預分配，預熱少量鏡像到宿主機，使用親和標的方式，解決如何在宿主機 IO 有限情況下應對快速擴容多種容器的需求問題。

　　為什么需要調度模擬器？

　　容器調度中有如下幾個業務問題：

1. 如何衡量調度分配結果的優劣？

2. 大批量應用一鍵建站時，如何克服鏡像拉取慢的問題？

3. 大批量應用同時一次性建站分配時，如何準確進行資源評估？

4. 如何在測試環境復現線上的調度問題？

　　Sigma 調度模擬器以***的成本和風險引入即可給上述問題一個可行的解答。

　　下面將針對每個業務問題進行闡述。

　　如何衡量調度分配結果的優劣

　　首先，容器的調度過程一定會存在一定的碎片化情況。

　　讓我們先從單維度的 CPU 核分配談起。想象如下最簡化的場景：

　　我們的某個總資源池僅僅有 2 臺宿主機，每臺宿主機各自有 4 個空閑的 CPU 可分配。示意圖如下：

　　我們要分配給 3 個容器：2 核容器 A，2 核容器 B，4 核容器 C。

　　設想 A 和 B 的請求先至，如果我們的分配算法不夠優秀，那么可能出現如下分配場景。可以很明顯看出，應用 C 無法獲得相應資源，而整個系統的靜態分配率僅有 50%，浪費較大。

　　理想的分配結果當然是如下圖：3 個容器全部被分配成功，總的靜態分配率為 100%。如果容器的資源本身需求是合理的話，那么浪費會很小。

　　當然，大家知道上面舉的例子僅僅是個最簡單的背包問題。

　　我們現在把這個場景復雜化一步。

　　系統要調配的資源不止 CPU 一種，Sigma 配合的 Pouch 能夠支持多種資源隔離，包括內存等。多種資源給背包問題增加了一個可能的錯誤解法如下圖：

　　上圖中可以看出，部分宿主機的 CPU 資源已經被耗盡，雖然內存和磁盤資源還有剩余，但也無法再被分配了。而另外有一些宿主機的 CPU 資源還頗有剩余，但是卻由于內存或硬盤資源的不足，而無法被利用了?？梢钥闯銎渲斜囟ù嬖谥{配的不合理之處，造成相當的資源浪費。

　　讓我們將這個場景再復雜化一步。

　　為了保證被調度容器中服務的容災以及其他運行時狀態需求，調度系統在進行調度時，允許業務應用分類設置自己獨特的機型要求，獨占要求，互斥和親和要求等。這些強弱規則無疑將這個背包問題又復雜化了一些。

　　讓我們將這個場景再復雜化一步。

　　在線和離線任務混布，如果在線任務決定根據當前業務服務需求，可以下掉一部分容器釋放資源給離線任務運行，那么縮容哪些實例是更為合理的，是***的？縮容當然需要考慮，那么擴容分配的時候是否需要考慮到這個情況？

　　再復雜化一步。

　　在滿足前面所述條件的前提下，分配是有時間限制的，雖然不是非常 critical。一般每個請求至多 180s 內每個需求要得到返回，同時管控的宿主機規模在萬級別。

　　同時要考慮請求的并發程度，可能較高。

　　使用 Sigma 調度模擬器，提供了擬真的生產背景環境數據和需求請求，對靜態資源的調配，可進行一個比較清晰的評估。

　　如何在宿主機 IO 有限情況下應對快速擴容多種容器的需求

　　在歷史的性能測試和生產數據中分析可知，最最耗費容器創建時間的，可能是宿主機層面的 Docker 鏡像下載和解壓時間，根據歷史經驗，可能占到一半以上的耗時，如果出現極端長的耗時，一般是這個階段卡住導致。

• 在一鍵建站場景下，要求 30 分鐘內完成 1.6w 個容器的創建；

• 快上快下場景下，要求 5 分鐘內完成 5k 個容器的創建。

　　阿里的 Pouch 使用了基于 P2P 技術的蜻蜓來進行鏡像分發，因此在大規模鏡像下載時是很有優勢的。除此之外也有鏡像的預加載手段能夠縮短實際容器創建時的對應時間。

　　但是某些時候宿主機的磁盤容量較小，而阿里的富容器鏡像又比較大，當一次一鍵建站應用種類過多時，如果全部鏡像種類都預熱到對應機器上，那么磁盤是不夠用的。

　　另有部分宿主機，磁盤 IO 能力較弱，即使蜻蜓超級節點預熱充分，解決了網絡 IO 時間長的問題，但是到宿主機磁盤層面，仍然會卡較久，甚至到 timeout 也無法完成。

　　因此如果能夠預先精準地知道宿主機上究竟會用到哪些容器，就可以針對性精準預熱少量容器，從而解決如上問題。通過模擬器的預分配，可解決該問題。

　　當然還有另外的更優雅的解決方案，這里不贅述。

　　如何進行資源需求預算預估

　　前面介紹了資源的碎片化情況，在算法未經充分優化的情況下，碎片率可能是很高的。因此一次建站是否需要增加宿主機，需要增加多少宿主機，就不是一個直接資源疊加的簡單問題了。如果估算過多可能浪費預算，如果估算過少又影響使用，如何適量估計是個問題。

　　如何在測試環境復現線上的調度問題

　　生產環境場景比較豐富，可能出現一些在測試環境下未曾預測到的場景，出現一些預期外的問題。要穩定而無生產影響地復現生產環境的問題，就可以給問題修復一個比較清晰的指引。

　　后續計劃

　　前面已經講過，目前的全部模擬都是靜態的。這里還有兩個問題：

1. 如果靜態需求滿足了，各種微服務就一定能夠和諧相處，運行到***嗎？怎樣的應用組合是最有效的？

2. 通過 cpushare 等方式，是否更能削峰填谷，有效利用資源？

　　這些問題都不是目前的靜態模擬能夠回答的。因此，后續計劃進行理想化正交動態模擬的方式做一些嘗試和靜態互補，推動調度算法的發展。

　　未來這樣具有混部能力的混合云彈性能力將通過阿里云開放，讓用戶以更低的成本獲得更強的計算能力，進而幫助整個社會提高資源效率。