排程演算法為何被阿里如此重視？

阿里妹導讀：資源管理系統作為將資料中心資源向上抽象的關鍵一層，需要的能力是全面的，從保障應用的穩定性、效能（保證SLA，Service Level Agreement）到全面提高資料中心執行的效率，節約能源等等，今天這篇文章，我們重點講一講排程演算法在資源管理中的作用。

本文作者：臨石，阿里系統軟體事業部資源排程與管理系統技術專家

網際網路應用和現代資料中心

雲計算已經火了很多年了，早已開始惠及我們每一個人。今天火熱的大資料、機器學習、人工智慧、以及你們看到的幾乎所有的大規模的網際網路應用（淘寶、天貓、優酷等），都是執行在雲上的。而支撐雲的，是大型雲計算服務商部署在世界各地的多個數據中心，每個資料中心都有大量的物理伺服器。為了有效地管理這些伺服器，我們需要叢集資源管理系統（Cluster Resource Management System），後面簡稱資源管理系統。資源管理系統的價值，用一句話說，是Datacenter as a Computer，即讓人們管理和使用資料中心，像管理和使用一個臺電腦一樣簡單。

排程演算法的價值

排程演算法在是整個資源管理系統中的一個重要組成部分，簡單地說，排程演算法的作用是決定一個計算任務需要放在叢集中的哪臺機器上面。

在容器化的今天，叢集中排程器的排程物件很可能是一個容器例項，Docker或者是PouchContainer。為容器選擇合適的宿主機顯然是一個值得考慮的問題，這裡我們說一說排程演算法能夠幫助我們實現的價值，這些價值可以從單個容器、到應用、再到資料中心，這三個不同的層面展示出來。

1、單個容器層面：

滿足容器執行的資源需求：確保每個容器在執行的時候擁有足夠的資源，CPU、Memory、Disk、網路頻寬等等。除了用數量衡量的資源，很多容器在執行的時候還需要一些特殊的資源，例如特定的作業系統版本、特定的硬體等等。

讓容器在更“舒適”的環境下執行：容器之間可能發生資源的搶佔現象，例如兩個對Memory消耗很大的容器部署在同一臺機器上，很容易造成Memory資源的吃緊。雖然我們可以透過容器和核心提供的資源隔離技術降低這種影響，但是最好的辦法還是在一開始不讓這種“容易吵架的人做鄰居”。

2、應用層面，每個應用在提供服務的時候往往是多個容器例項同時支援的，排程器需要考慮應用的需求

應用的高可用：分散式環境下宿主機失敗或者單個容器的失敗是正常現象，因此我們要保證每個應用同時有多個例項在執行，這樣即使有一個例項掛了，整個應用不會受很大影響。

應用的容災：容災其實也經常和高可用放在一起，如果一個應用有多個應用例項，但是都部署在一個機房，如果機房斷電，那麼應用也就不能提供服務了，沒有高可用了。解決這個問題需要的容災部署，也就不同維度地打散。排程演算法需要儘量讓同一個應用的不同例項部署在不同的宿主機、不同的機架、不同的機房、不同的資料中心、不同的城市、真是不同的國家；這種容災甚至可以體現在更高一層，幾個重要應用之間的所有例項，也要儘量打散。

很多應用因為其提供服務的特性往往需要排程器做更多的事情，例如：按照一定的順序排程例項、將計算任務排程到離資料最近的地方，等等，這裡不一一列舉了。

3、資料中心層面

降低資料中心的成本：合理的排程能夠節省資料中心大量的成本，如果用裝箱問題來表示，就是用更少的伺服器裝下了更多的應用。伺服器數目的減少不僅僅是採購成本的下降，伺服器的佔地、用電、冷卻等都是一筆很大的開銷，合理的資源排程能夠為資料中心節省大量成本。

除了以上這些內容，實際中排程演算法要考慮的內容還有很多，例如公平性的問題、應用間的干擾問題、不同應用間資源共享（互相借用）的問題、單機資源的調配問題（超執行緒、記憶體帶框等）等等。例如，實際管理阿里巴巴集團線上服的資源管理系統Sigma的排程規則，就十分複雜。

為了讓更多的學生、研究者能夠接觸到我們的排程問題，並鼓勵他們與我們一起應對挑戰，我們舉辦了“

阿里巴巴全球排程演算法挑戰賽

”。這個演算法大賽是怎麼回事兒呢？讓我們介紹一下。

排程演算法大賽是什麼？

這次演算法大賽（初賽）來自我們生產環境中的一個真實的場景，簡化了一些約束條件，方便一些對這個領域剛剛開始瞭解（你讀完這篇文章，就算是入了一點門了）的同學找到一個求解的方法，但是即使對於在該領域有一定經驗的同學、工程師、研究者們，我們也相信這份題目能夠讓你花費一些精力才能得到一個最佳化的解。

在這次演算法大賽中，我們提供了大約6K個宿主機，68K個例項（其中一部分已經部署，一部分尚未部署），約束型別主要有3類：資源約束、重要應用高可用約束和應用間反親和約束。

資源約束

資源約束是最容易理解的，每個屬於不同應用的例項都有不同的計算資源要求。我們本次比賽的一個重要特點是，CPU和Mem的數量約束是以時間曲線的形式給出的。每個應用的對應資源需求的時間曲線是我們透過對該應用下多個例項（一個應用由很多例項組成）的24小時的歷史資料進行觀察並整理得到的需求曲線，描述了每個應用下面的例項在一天當中每個取樣點需要的對應資源的數量。對映的場景是我們假定各個應用的例項的資源需求的有著24小時的變化週期（即98個點的變化週期），第二天、第三天甚至再往後，應用的例項還是按照這個需求長時間存在。注意，這裡提到的應用是長應用（Long Running Service），沒有特殊原因是不會下線的（例如淘寶網站），這種長應用與一些分散式計算中的有限持續時間計算任務是不一樣。

這樣的時間曲線比普通的標量規定的資源需求具有更多的最佳化空間，但也帶來了更多的複雜度。下面這個圖是兩個應用在不同時間點的資源需求對於滿足機器容量的互斥（左）與互補（右）的例子。

重要應用高可用約束

除了CPU、Mem、Disk這樣計算資源的約束，我們還有三類名為P、M、PM的約束，這個約束名字大家可能會覺得有些奇怪，但這是我們透過排程來保障重要應用高可用的重要約束。我們把一些重要應用標記為P類、M類、或者PM類，透過限制每臺機器上可以承載的P、M、PM型別應用例項的上限來保證在機器發生故障的時候（宕機、斷網等），重要應用受到的影響最小。

應用間反親和約束

在上述兩種約束之外，我們提供第三種的約束型別是應用之間的反親和，以的形式給出，其語義是：如果一臺機器上已經部署了一個App_1的例項，那麼這臺機器上最多可以部署k個來自App_2的例項。這種約束在實際中的意義是什麼呢？這些約束使我們透過觀測和經驗，確定這兩個應用間可能存在干擾因素，如果有超過一定數量的兩類應用的例項部署在一起，會影響彼此的效能，因此，在進行排程決策的時候儘量不讓這種互相干擾的應用的例項出現“扎堆”的現象。

最佳化的目標

我們的最佳化目標是在維持每臺機器的資源使用率在一定水平的基礎上（具體數字不透露，你好好看一下題目的描述，相信你可以判斷出來的），儘量減少使用的機器的數目（即實際部署了容器的機器的數目）。為什麼這樣設計呢？較少機器的數目很容易想到是節省成本，而維持機器的資源利用率在一定水平，而不是100%，在實際生產中是很有意義的。因為每個應用都會有一定的、不可準確預計的負載增加，因此，我們需要在每臺機器上流出一定的“餘量”來應對每個例項可能突然需要的計算資源。

這些餘量的資源在平時也可以為我們所用，但這並在不在我們初賽的考察範圍內。也許複賽中我們會涉及到這些內容。另外，有經驗的朋友可能會發現我們這裡沒有對應用的遷移做出限制，沒錯，我們這樣做的目的是為了降低初賽的難度。實際生產中，應用的遷移，尤其我們這次考慮的線上應用的遷移是一件頗有代價的事情，你能否在設計算法的時候考慮一下應用遷移的代價呢？

期待您的參與

我們誠摯地邀請所有對資源排程、運籌最佳化、資源管理、演算法有興趣的同學、學者來參加我們的大賽，獎金豐厚而且有前往美國參加Hackthon的機會。點選文末“

閱讀原文

”，即可直接報名。

每天一篇技術文章，

看不過癮？

關注“

阿里巴巴機器智慧

”，

發現更多AI乾貨。

↑

翹首以盼等你關注

你可能還喜歡

為什麼阿里工程師紛紛在內網曬程式碼？

關注「阿里技術」

把握前沿技術脈搏