阿里容器調(diào)度系統(tǒng)Sigma仿真平臺Cerebro揭秘
為了保證系統(tǒng)的在線交易服務(wù)順利運轉(zhuǎn),最初幾年,阿里都是在雙 11 大促來臨之前大量采購機器儲備計算資源,雙 11 之后資源大量閑置。是否能把計算任務(wù)與在線服務(wù)進行混合部署,在現(xiàn)有彈性資源基礎(chǔ)上提升集群資源利用率,降低雙 11 資源新增成本?阿里巴巴研發(fā)效能事業(yè)部容器調(diào)度域,測試開發(fā)專家何穎為我們揭秘。
寫在前面
Sigma 是阿⾥巴巴全集團范圍的 Pouch 容器調(diào)度系統(tǒng)。2017 年是 Sigma 正式上線以來第⼀次參與雙 11,在雙 11 期間成功⽀撐了全集團所有容器(交易線中間件、數(shù)據(jù)庫、⼴告等⼆⼗多業(yè)務(wù))的調(diào)配,使雙 11IT 成本降低 50%,是阿⾥巴巴運維系統(tǒng)重要的底層基礎(chǔ)設(shè)施。
Sigma 已經(jīng)是阿里全網(wǎng)所有機房在線服務(wù)管控的核心角色,管控的宿主機資源達到幾十萬量級,重要程度不言而喻,其算法的優(yōu)劣程度影響了集團整體的業(yè)務(wù)穩(wěn)定性,資源利用率。
Sigma-cerebro 系統(tǒng)是 Sigma 系統(tǒng)的調(diào)度模擬系統(tǒng),可以在無真實宿主機的情況下,以最小成本,最快速度模擬線上 1:1 機器資源和請求要求的調(diào)度需求完成情況,從各個角度進行擴縮容算法的評測。在對抗系統(tǒng)資源碎片化,在有限資源條件下大批量擴縮容,預(yù)期外超賣等問題的過程中,系統(tǒng)一步步發(fā)展成現(xiàn)在的樣子。
在 2017 年雙 11 中,依靠 cerebro 進行預(yù)處理,Sigma 成功完成了雙 11 一鍵建站,30 分鐘內(nèi)完成建站任務(wù),且系統(tǒng)靜態(tài)分配率從 66% 提升到 95%,大大提升了資源利用的有效性。
什么是好的調(diào)度?最理想的情況如何?
我認為在滿足容器的資源運行時,最小化互相干擾的前提下,越能夠節(jié)省集群整體資源,提高利用率,在固定時間內(nèi)完成分配的調(diào)度系統(tǒng),較符合理想的調(diào)度系統(tǒng)。
那么一個調(diào)度算法仿真評測的系統(tǒng),要做到什么程度?
-
要能夠真實模擬生產(chǎn)的大規(guī)模環(huán)境和復(fù)雜需求;
-
要盡量節(jié)省模擬的開銷,避免模擬的風(fēng)險;
-
從靜態(tài)和動態(tài)的角度都能夠給***個問題以定性定量的回答。
在這個基礎(chǔ)上,我們來看看 Sigma 的副產(chǎn)品,Sigma-cerebro 調(diào)度模擬器。
調(diào)度模擬器設(shè)計
總的來說,目前的模擬器是一個使用 1:1 生產(chǎn)環(huán)境數(shù)據(jù)來進行調(diào)度分配仿真的工具平臺。
該仿真目前是純數(shù)據(jù)層面的,動態(tài)預(yù)測也是基于靜態(tài)數(shù)據(jù)的。原因是要 1:1 模擬線上,而線上動輒萬臺宿主,是不可能真的動用這么多資源的。另外后續(xù)也計劃搞小規(guī)模的池子進行全動態(tài)的 runtime 仿真和評測。
模擬器需要同時滿足很多需求,因此分成了多套環(huán)境,有一個環(huán)境池。每個環(huán)境池,僅需要 3 個容器即可完成全套任務(wù)。
背景數(shù)據(jù)是存放在 OSS 中的,因為一套背景數(shù)據(jù)可能非常大,另外解耦和線上的依賴將風(fēng)險降到***,因此仿真時僅需要從 OSS 取數(shù)據(jù)即可。在各種仿真下,用戶需要的服務(wù)是不同的,因此模擬器設(shè)計了幾個不同的模式來進行支持。這些模式即可對應(yīng)前面的 4 個需求。
目前已有的模式包括:擴、縮容算法評測模式,預(yù)分配模式,問題復(fù)現(xiàn)模式。
對于如何衡量調(diào)度分配結(jié)果的優(yōu)劣問題來說,模擬器支持將算法配置透出,支持用戶自定義水位配置和調(diào)度器,模擬器會負責(zé)將一套線上 1:1 宿主機數(shù)據(jù),應(yīng)用要求配置等寫入該環(huán)境,并將用戶的算法配置寫入,然后將每次相同的請求發(fā)送到該環(huán)境,待結(jié)束后用同樣的方式進行打分。
針對同樣的一份背景數(shù)據(jù),不同的算法配置和版本會產(chǎn)生不同的打分,我們就可以觀察他們之間的優(yōu)劣。如下圖:
另外,可以快速在模擬器環(huán)境下進行資源的預(yù)分配,之后精準按照本次預(yù)分配,預(yù)熱少量鏡像到宿主機,使用親和標的方式,解決如何在宿主機 IO 有限情況下應(yīng)對快速擴容多種容器的需求問題。
為什么需要調(diào)度模擬器?
容器調(diào)度中有如下幾個業(yè)務(wù)問題:
-
如何衡量調(diào)度分配結(jié)果的優(yōu)劣?
-
大批量應(yīng)用一鍵建站時,如何克服鏡像拉取慢的問題?
-
大批量應(yīng)用同時一次性建站分配時,如何準確進行資源評估?
-
如何在測試環(huán)境復(fù)現(xiàn)線上的調(diào)度問題?
Sigma 調(diào)度模擬器以***的成本和風(fēng)險引入即可給上述問題一個可行的解答。
下面將針對每個業(yè)務(wù)問題進行闡述。
如何衡量調(diào)度分配結(jié)果的優(yōu)劣
首先,容器的調(diào)度過程一定會存在一定的碎片化情況。
讓我們先從單維度的 CPU 核分配談起。想象如下最簡化的場景:
我們的某個總資源池僅僅有 2 臺宿主機,每臺宿主機各自有 4 個空閑的 CPU 可分配。示意圖如下:
我們要分配給 3 個容器:2 核容器 A,2 核容器 B,4 核容器 C。
設(shè)想 A 和 B 的請求先至,如果我們的分配算法不夠優(yōu)秀,那么可能出現(xiàn)如下分配場景??梢院苊黠@看出,應(yīng)用 C 無法獲得相應(yīng)資源,而整個系統(tǒng)的靜態(tài)分配率僅有 50%,浪費較大。
理想的分配結(jié)果當(dāng)然是如下圖:3 個容器全部被分配成功,總的靜態(tài)分配率為 100%。如果容器的資源本身需求是合理的話,那么浪費會很小。
當(dāng)然,大家知道上面舉的例子僅僅是個最簡單的背包問題。
我們現(xiàn)在把這個場景復(fù)雜化一步。
系統(tǒng)要調(diào)配的資源不止 CPU 一種,Sigma 配合的 Pouch 能夠支持多種資源隔離,包括內(nèi)存等。多種資源給背包問題增加了一個可能的錯誤解法如下圖:
上圖中可以看出,部分宿主機的 CPU 資源已經(jīng)被耗盡,雖然內(nèi)存和磁盤資源還有剩余,但也無法再被分配了。而另外有一些宿主機的 CPU 資源還頗有剩余,但是卻由于內(nèi)存或硬盤資源的不足,而無法被利用了。可以看出其中必定存在著調(diào)配的不合理之處,造成相當(dāng)?shù)馁Y源浪費。
讓我們將這個場景再復(fù)雜化一步。
為了保證被調(diào)度容器中服務(wù)的容災(zāi)以及其他運行時狀態(tài)需求,調(diào)度系統(tǒng)在進行調(diào)度時,允許業(yè)務(wù)應(yīng)用分類設(shè)置自己獨特的機型要求,獨占要求,互斥和親和要求等。這些強弱規(guī)則無疑將這個背包問題又復(fù)雜化了一些。
讓我們將這個場景再復(fù)雜化一步。
在線和離線任務(wù)混布,如果在線任務(wù)決定根據(jù)當(dāng)前業(yè)務(wù)服務(wù)需求,可以下掉一部分容器釋放資源給離線任務(wù)運行,那么縮容哪些實例是更為合理的,是***的?縮容當(dāng)然需要考慮,那么擴容分配的時候是否需要考慮到這個情況?
再復(fù)雜化一步。
在滿足前面所述條件的前提下,分配是有時間限制的,雖然不是非常 critical。一般每個請求至多 180s 內(nèi)每個需求要得到返回,同時管控的宿主機規(guī)模在萬級別。
同時要考慮請求的并發(fā)程度,可能較高。
使用 Sigma 調(diào)度模擬器,提供了擬真的生產(chǎn)背景環(huán)境數(shù)據(jù)和需求請求,對靜態(tài)資源的調(diào)配,可進行一個比較清晰的評估。
如何在宿主機 IO 有限情況下應(yīng)對快速擴容多種容器的需求
在歷史的性能測試和生產(chǎn)數(shù)據(jù)中分析可知,最最耗費容器創(chuàng)建時間的,可能是宿主機層面的 Docker 鏡像下載和解壓時間,根據(jù)歷史經(jīng)驗,可能占到一半以上的耗時,如果出現(xiàn)極端長的耗時,一般是這個階段卡住導(dǎo)致。
-
在一鍵建站場景下,要求 30 分鐘內(nèi)完成 1.6w 個容器的創(chuàng)建;
-
快上快下場景下,要求 5 分鐘內(nèi)完成 5k 個容器的創(chuàng)建。
阿里的 Pouch 使用了基于 P2P 技術(shù)的蜻蜓來進行鏡像分發(fā),因此在大規(guī)模鏡像下載時是很有優(yōu)勢的。除此之外也有鏡像的預(yù)加載手段能夠縮短實際容器創(chuàng)建時的對應(yīng)時間。
但是某些時候宿主機的磁盤容量較小,而阿里的富容器鏡像又比較大,當(dāng)一次一鍵建站應(yīng)用種類過多時,如果全部鏡像種類都預(yù)熱到對應(yīng)機器上,那么磁盤是不夠用的。
另有部分宿主機,磁盤 IO 能力較弱,即使蜻蜓超級節(jié)點預(yù)熱充分,解決了網(wǎng)絡(luò) IO 時間長的問題,但是到宿主機磁盤層面,仍然會卡較久,甚至到 timeout 也無法完成。
因此如果能夠預(yù)先精準地知道宿主機上究竟會用到哪些容器,就可以針對性精準預(yù)熱少量容器,從而解決如上問題。通過模擬器的預(yù)分配,可解決該問題。
當(dāng)然還有另外的更優(yōu)雅的解決方案,這里不贅述。
如何進行資源需求預(yù)算預(yù)估
前面介紹了資源的碎片化情況,在算法未經(jīng)充分優(yōu)化的情況下,碎片率可能是很高的。因此一次建站是否需要增加宿主機,需要增加多少宿主機,就不是一個直接資源疊加的簡單問題了。如果估算過多可能浪費預(yù)算,如果估算過少又影響使用,如何適量估計是個問題。
如何在測試環(huán)境復(fù)現(xiàn)線上的調(diào)度問題
生產(chǎn)環(huán)境場景比較豐富,可能出現(xiàn)一些在測試環(huán)境下未曾預(yù)測到的場景,出現(xiàn)一些預(yù)期外的問題。要穩(wěn)定而無生產(chǎn)影響地復(fù)現(xiàn)生產(chǎn)環(huán)境的問題,就可以給問題修復(fù)一個比較清晰的指引。
后續(xù)計劃
前面已經(jīng)講過,目前的全部模擬都是靜態(tài)的。這里還有兩個問題:
-
如果靜態(tài)需求滿足了,各種微服務(wù)就一定能夠和諧相處,運行到***嗎?怎樣的應(yīng)用組合是最有效的?
-
通過 cpushare 等方式,是否更能削峰填谷,有效利用資源?
這些問題都不是目前的靜態(tài)模擬能夠回答的。因此,后續(xù)計劃進行理想化正交動態(tài)模擬的方式做一些嘗試和靜態(tài)互補,推動調(diào)度算法的發(fā)展。
未來這樣具有混部能力的混合云彈性能力將通過阿里云開放,讓用戶以更低的成本獲得更強的計算能力,進而幫助整個社會提高資源效率。