轉-Zeus資源調度系統介紹

時間 2019-11-30

標籤 zeus 資源調度系統介紹简体版

原文原文鏈接

摘要： 本文主要概述阿里巴巴Zeus資源調度系統的背景和實現思路。本文主線：問題、解決方案、依賴基礎知識、工程實踐、目標、經驗分享。立足企業真實問題、常規解決策略，引出依賴的容器技術、實踐方案，全部這些落實到工程實踐，要解決那些問題、實現哪些目標、技術大趨勢的影響。最後給出阿里巴巴的實踐經驗。本序列文章並非突出架構上重大突破，畢竟這個領域已經發展了10多年了。而是，實踐過程當中的一些細節、一些特殊場景下的特殊處理方法，做爲一種新的認知素材。依賴的容器或周邊系統，都不會進行深刻的分析，圍繞資源調度歸納性地作一些總結和補充些細節描述。html

關鍵詞：容器技術資源調度java

1.背景：資源浪費剖析

企業裏面資源調度的存在或者必要性，與企業發展規模有很強的關聯關係。任何企業從一開始就有某種程度的、某種特有階段性的「服務器資源分配使用方案」，只是對資源或者成本「優化」的度,或者效率的要求急迫性、重要性不是那麼突出。當服務器數量以萬爲單位增加，成本支出過億的大背景下，依賴面向容器技術的資源調度和管理，顯得很是急迫和重要。制定執行成本優化目標，落到實踐中，首先須要對資源浪費、已有系統的缺陷、資源利用率不高進行系統化的診斷，而後執行平穩的逐步優化、提高效率、利用率。這就是問題或者需求的源頭。linux

（1）資源管理混亂編程

資源管理系統沒有掌握資源的利用狀況，當前的資源利用率是怎麼樣的，有哪些空閒資源不是太清楚。甚至有些資源脫離了系統的管理，成爲殭屍資源。這樣形成了大量可用資源的閒置和浪費。服務器

（2）申請和使用不一致網絡

例如，營銷或者宣傳活動，申請幾百臺資源實例，因爲業務沒有預期那麼好，或者預留buffer，應對超預期壓力。最終的結果是申請和使用不一致。活動期間，白天總體利用率偏高，晚上總體利用率偏低。例如，初期資源少，每一次申請和使用的一致性，並無系通通一追蹤沉澱、統一透明化度量，業務慢慢發展了，單純申請機器擴容不必定是最佳的。軟件是否也須要進行優化升級了呢。容量評估和預測、歷史趨勢追蹤預測等系統完善度直接影響申請和使用的過程一致性、長期一致性。架構

（3）在線業務的訪問低谷期間資源浪費併發

對於網站來講，訪問量是呈現成曲線分佈的，有高峯有低谷。在訪問高峯的時候資源利用率比較高，在訪問低谷的時候，則資源比較閒置，從而形成大量資源的浪費負載均衡

（4）故障修復運維

機器的磁盤、內存條、網卡，隨時都會壞掉，統計機率大約是萬分之三，一旦壞掉了，進入維修流程。1萬臺規模，天天來個三、5臺，一個禮拜也就20多臺，再花個1個禮拜慢慢修復。修復了，迴歸可用資源池又是一段時間。這種浪費是隱形的，很零碎。一年下來累計的不可用工做小時很是大。故障自動識別、自動腳本處理、故障預警等直接影響效率、準確率。

（5）可達效率

在IT軟件中，基本上沒有解決不了的問題。系統分層、功能弱化老是可以把問題的影響或者問題的複雜度降到最低，最終達到服務可上線的目標。系統之間的這種分層或者功能弱化造成的依賴關係，上下游之間的可達效率，其實也很是影響系統的總體資源利用率。例如：A上游RT、QPS很是大，A下游B可以處理的吞吐量大，可是RT相對增加，總體鏈路可達效率逐層下降。適當的整合可以帶來必定的資源利用率提高。

2. Zeus介紹

Zeus是一個資源調度系統，它對數據中心的服務器資源進行統一的調度和分配。它的主要功能包括：

（1）對數據中心的物理資源進行了封裝，隱藏了其中的細節。對於外界來講，整個數據中心就像是一臺巨大的服務器，對外提供CPU, 內存，存儲，網絡等資源。應用開發者不須要關心本身的應用部署在哪臺服務器上。
（2）接收應用的資源申請請求，爲應用調度分配資源。
（3）優化成本。經過超賣，混合部署等方法提升資源利用率，節約成本。
（4）提高系統穩定性。Zeus在進行資源調度時，會監控系統的軟硬件故障，確保有故障的資源不被分配，對有問題的物理資源進行跟蹤處理。

3. 資源的虛擬化

Zeus使用LXC容器技術對物理資源進行切分隔離，在CPU、Memory、Disk、Network量化後的數據基礎上，按照固定或者分時共享，實現資源動態共享，總體提高物理機的資源利用率。容器技術還有其餘的優點，例如屏蔽硬件的異構性，帶來面向API的資源分配和數據沉澱，從而爲資源預測提供了規範、統一的數據。另外，容器技術是雲時代的加速器，以Docker容器爲表明的容器技術極大的方便了應用運維管理。固然容器技術從某種角度看，也有一些不足，不能應用在全部場景當中、難以解決依賴關係問題、較差的隔離性、潛在的蔓延問題、缺少工具。

容器技術把硬件等計算、存儲、傳輸資源進行了無狀態性、相對透明的共享。容器內的具體任務以及容器的生命週期等管理，交給了上層業務進行管理、運維。

從任務實現的語言來看，一類是編譯型語言（C、C++、Golang）實現的服務，一類是解釋型語言（Java、PHP、Javascript）。對於前者，進程啓動時並不須要一次性hold住固定大內存，對於後者特別是java，在進程啓動時候，配置固定內存開銷。兩種不一樣類型語言，使得物理機內存資源的動態共享模型有所不一樣，而Cgroup實現的CPU Set或者CPU子系統，能夠動態共享CPU。磁盤IO、網絡IO經過隊列、聚合等也能夠執行「限流」。另外，在單JVM進程中，合併部署多個應用，或者單JVM進程中，經過租用的方式，啓動多個服務，共享同一個JVM進程。

從資源生命週期看，長期租用、短時間租用、不定時租用。不定時租用對應的每每是分時共享，而長期租用多半是固定配額共享或者專有共享。資源在時間、粒度、上下文環境一致、業務類型上進行平衡。

不論哪一種角度看共享，只要有共享，就必須保障基礎環境的一致性，不能由於共享者的環境變動致使其餘服務受影響。實時環境巡檢也就必不可少。

在一個大的生態性質的資源調度管理系統中，上面這些每每同時存在不一樣的業務集羣中。在一個業務集羣中、抽象出一套綜合的策略是很難知足多場景需求的。不一樣業務集羣，在底層的硬件抽象、運維監控管理工具是能夠統一的。資源共享的粒度、時機，能夠多樣化。

4. 技術架構

Zeus主要採起分佈式二層架構模式，分配策略空閒優先，融合業務相親相近、負載錯峯、業務穩定性等多種約束條件，基於超賣的資源共享。調度併發上，選擇資源是全局排序，採起的編程語言是Golang。容器服務的對象集中在在線Service。在線離線混部部分，採起分時共享資源。經過周邊多個系統的協調，爲公司每一年節約大量成本，而且所使用的策略是常態化的。也有一些一次性的策略，針對11大促特殊場景的需求。

Zeus從穩定性，資源利用率，運維自動化這三個方面來考慮調度的問題。實時監控基礎設施層的故障，並進行自動化處理，對上層應用屏蔽掉故障，從而提高系統的穩定性。經過多種調度策略，以及混合部署等方案提高資源利用率。經過提高調度的成功率，提供多種數據分析工具和數據視圖提高運維自動化程度。

架構圖以下

5. 資源利用率

5.1 超賣

應用在申請的資源的時候，每每會申請比他實際使用更多的資源。也就是說他申請的資源，在實際使用中，他是用不了這麼多資源的。這樣就造成了資源的浪費。咱們經過超賣來解決這個問題。

超賣帶來的挑戰就是，超賣多少比較合適。若是超賣多了，會引發資源競爭，致使系統的不穩定。若是超賣少了，會致使資源的浪費。咱們須要找到一個平衡點，既不會影響系統的穩定性，也不會有不少的資源浪費。解決方案就是實行動態的超賣係數。先設置一個比較低的超賣係數，而後在系統運行的過程當中，採集分析資源利用率狀況，根據資源利用率的實際狀況調高或者調低超賣係數。

5.2 混合部署

離線任務（Jobs或者短週期任務）、在線任務（service或者長週期任務）經過合併部署來共享宿主機資源。一種是實時錯峯共享資源，當調度系統發現當前在線任務的資源利用率比較低的時候，把離線任務調度上來運行，從而提升資源的利用率。但要確保在線任務優先搶佔資源，若是發生離線任務和在線任務爭搶資源的狀況，要殺掉離線任務，把資源讓給在線任務。一種是固定配額來共享，service和jobs固定必定的資源，而後根據service空閒週期，jobs加大資源計算，動態調整CPU資源，假設內存、IO都不是瓶頸，也就是部分的調整資源給jobs。或者不關注service空閒，在jobs固定配額內自由提交jobs計算。這種時間窗口越短，對任務切換要求能力更高，須要資源實時預測模型。例如 Borg系統，針對進程最近時刻內存開銷進行實時調整。這對C、C++是有益處的，而對java就很難快速實施了，由於須要改JVM參數，從而JVM須要重啓，而後是業務代碼重啓。一種是分時獨佔交付，在service空閒週期內，service中止服務，完整的將資源空閒出來給jobs使用。

5.3 減小資源碎片

在資源分配的時候，有兩種方式，一種是湊整分配，一種是打散分配。湊整分配就是儘可能將一臺宿主機分配滿，這臺宿主機分配滿了之後，再去分配到別的宿主機。這種分配方式的好處是資源碎片比較少，資源利用率比較高，但容易形成資源競爭，系統不穩定。打散分配就是每次分配的時候找到空閒資源最多的宿主機進行分配，這種分配方式的好處是各個宿主機的負載比較均衡，可是會形成較多的資源碎片。Zeus的處理方法是在這兩種方式之間找到一個平衡點，同時考慮湊整和負載均衡的問題，既要減小資源的碎片，也要考慮負載的適當均衡。

6. 穩定性

6.1 故障處理

Zeus會實時監控基礎設施層的各類軟硬件故障。提早發現大量軟硬件或操做系統故障的宿主機，並標記爲unavailable，線下按期處理。按期處理並回收失聯及load太高的宿主機（數10臺），成本回收並提升應用運行穩定性。提供黑名單機制，能快速屏蔽故障機和測試機，提升用戶操做效率。能提早發現IP衝突等網絡問題，並按期解決。