為了保證系統的線上交易服務順利運轉，最初幾年，阿裡都是在雙11大促來臨之前大量採購機器儲備計算資源，雙11之後資源大量閑置。是否能把計算任務與線上服務進行混合部署，在現有彈性資源基礎上提升叢集資源利用率，降低雙11資源新增成本？阿裡巴巴研發效能事業部容器排程域，測試開發專家何穎為我們揭秘。
Sigma 是阿裡巴巴全集團範圍的 Pouch 容器排程系統。2017年是 Sigma 正式上線以來第1次參與雙11，在雙11期間成功支撐了全集團所有容器（交易線中介軟體、資料庫、廣告等20多個業務）的調配，使雙11 IT成本降低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有限情況下應對快速擴容多種容器的需求問題。
-
如何衡量排程分配結果的優劣？
-
大批次應用一鍵建站時，如何剋服映象拉取慢的問題？
-
大批次應用同時一次性建站分配時，如何準確進行資源評估？
-
如何在測試環境復現線上的排程問題？
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 排程模擬器，提供了擬真的生產背景環境資料和需求請求，對靜態資源的調配，可進行一個比較清晰的評估。
1.2 如何在宿主機IO有限情況下應對快速擴容多種容器的需求
在歷史的效能測試和生產資料中分析可知，最最耗費容器建立時間的，可能是宿主機層面的 Docker 映象下載和解壓時間，根據歷史經驗，可能佔到一半以上的耗時，如果出現極端長的耗時，一般是這個階段卡住導致。
在一鍵建站場景下，要求30分鐘內完成1.6w個容器的建立；
快上快下場景下，要求5分鐘內完成5k個容器的建立。
阿裡的 Pouch 使用了基於 P2P 技術的蜻蜓來進行映象分發，因此在大規模映象下載時是很有優勢的。除此之外也有映象的預載入手段能夠縮短實際容器建立時的對應時間。
但是某些時候宿主機的磁碟容量較小，而阿裡的富容器映象又比較大，當一次一鍵建站應用種類過多時，如果全部映象種類都預熱到對應機器上，那麼磁碟是不夠用的。
另有部分宿主機，磁碟IO能力較弱，即使蜻蜓超級節點預熱充分，解決了網路IO時間長的問題，但是到宿主機磁碟層面，仍然會卡較久，甚至到 timeout 也無法完成。
因此如果能夠預先精準地知道宿主機上究竟會用到哪些容器，就可以針對性精準預熱少量容器，從而解決如上問題。透過模擬器的預分配，可解決該問題。
前面1.1介紹了資源的碎片化情況，在演演算法未經充分最佳化的情況下，碎片率可能是很高的。因此一次建站是否需要增加宿主機，需要增加多少宿主機，就不是一個直接資源疊加的簡單問題了。如果估算過多可能浪費預算，如果估算過少又影響使用，如何適量估計是個問題。
生產環境場景比較豐富，可能出現一些在測試環境下未曾預測到的場景，出現一些預期外的問題。要穩定而無生產影響地復現生產環境的問題，就可以給問題修複一個比較清晰的指引。
前面已經講過，目前的全部模擬都是靜態的。這裡還有兩個問題：
-
如果靜態需求滿足了，各種微服務就一定能夠和諧相處，執行到最佳嗎？怎樣的應用組合是最有效的？
-
透過 cpushare 等方式，是否更能削峰填谷，有效利用資源？
這些問題都不是目前的靜態模擬能夠回答的。因此，後續計劃進行理想化正交動態模擬的方式做一些嘗試和靜態互補，推動排程演演算法的發展。
未來這樣具有混部能力的混合雲彈效能力將透過阿裡雲開放，讓使用者以更低的成本獲得更強的計算能力，進而幫助整個社會提高資源效率。
原文連結：https://yq.aliyun.com/articles/448315
本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
