天天看點

幹貨:排程算法的價值與阿裡的應用實踐

More Applications in Less Machines,你辦得到嗎?

作者:丁海洋

花名臨石。阿裡巴巴系統軟體事業部資源排程與管理系統技術專家。曾在華為從事雲計算和區塊鍊方面工作,參與了Kubernetes社群早期排程器特性的設計和開發工作,區塊鍊技術的研究、場景分析和專利工作。加入華為之前,在法國格勒諾布爾大學獲得分布式控制博士學位,大學、研究所學生畢業于東南大學。

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

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

資源管理系統作為将資料中心資源向上抽象的關鍵一層,需要全面的能力。從保障應用的穩定性、性能(保證SLA,Service Level Agreement)到全面提高資料中心運作的效率,節約能源等等,今天這篇文章,我們重點講一講排程算法在資源管理中的作用。

排程算法的價值

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

幹貨:排程算法的價值與阿裡的應用實踐

在容器化的今天,叢集中排程器的排程對象很可能是一個容器執行個體,Docker或者是PouchContainer。為容器選擇合适的主控端顯然是一個值得考慮的問題,這裡我們說一說排程算法能夠幫助我們實作的價值,這些價值可以從單個容器、到應用、再到資料中心,這三個不同的層面展示出來。

  • 單個容器層面:
    • 滿足容器運作的資源需求:確定每個容器在運作的時候擁有足夠的資源,CPU、Memory、Disk、網絡帶寬等等。除了用數量衡量的資源,很多容器在運作的時候還需要一些特殊的資源,例如特定的作業系統版本、特定的硬體等等
    • 讓容器在更“舒适”的環境下運作:容器之間可能發生資源的搶占現象,例如兩個對Memory消耗很大的容器部署在同一台機器上,很容易造成Memory資源的吃緊。雖然我們可以通過容器和核心提供的資源隔離技術降低這種影響,但是最好的辦法還是在一開始不讓這種“容易吵架的人做鄰居”
幹貨:排程算法的價值與阿裡的應用實踐
  • 應用層面,每個應用在提供服務的時候往往是多個容器執行個體同時支援的,排程器需要考慮應用的需求
    • 應用的高可用:分布式環境下主控端失敗或者單個容器的失敗是正常現象,是以我們要保證每個應用同時有多個執行個體在運作,這樣即使有一個執行個體挂了,整個應用不會受很大影響
    • 應用的容災:容災其實也經常和高可用放在一起,如果一個應用有多個應用執行個體,但是都部署在一個機房,如果機房斷電,那麼應用也就不能提供服務了,沒有高可用了。解決這個問題需要的容災部署,也就不同次元的打散。排程算法需要盡量讓同一個應用的不同執行個體部署在不同的主控端、不同的機架、不同的機房、不同的資料中心、不同的城市、甚至是不同的國家;這種容災甚至可以展現在更高一層,幾個重要應用之間的所有執行個體,也要盡量打散
    • 很多應用因為其提供服務特性往往需要排程器做更多的事情,例如:按照一定的順序排程執行個體、将計算任務排程到離資料最近的地方,等等,這裡不一一列舉了
  • 資料中心層面
    • 降低資料中心的成本:合理的排程能夠節省資料中心大量的成本,如果用裝箱問題來表示,就是用更少的伺服器裝下了更多的應用。伺服器數目的減少不僅僅是采購成本的下降,伺服器的占地、用電、冷卻等都是一筆很大的開銷,合理的資源排程能夠為資料中心節省大量成本

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

幹貨:排程算法的價值與阿裡的應用實踐

為了讓更多的學生、研究者能夠接觸到我們的排程問題,并鼓勵他們與我們一起應對挑戰,我們舉辦了“阿裡巴巴全球排程算法挑戰賽”。這個算法大賽是怎麼回事兒呢?讓我們介紹一下。

首屆阿裡全球排程算法大賽

大家可以想象下,阿裡巴巴擁有如此大規模的資料中心,1%的資源使用率的提升都将為阿裡巴巴自身和整個社會帶來可觀的能源節約讓使用者享受更加綠色的計算資源。是以最近我們發起了首屆阿裡全球排程算法大賽,初賽賽題來自我們生産環境中的一個真實的場景,簡化了一些限制條件,友善一些對這個領域剛剛開始了解的同學找到一個求解的方法,但是即使對于在該領域有一定經驗的同學、工程師、研究者們,我們也相信這份題目能夠讓你花費一些精力才能得到一個優化的解。

在這次算法大賽中,我們提供了大約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, App_2, k>

的形式給出,其語義是:如果一台機器上已經部署了一個

App_1

的執行個體,那麼這台機器上最多可以部署

k

個來自

App_2

的執行個體。這種限制在實際中的意義是什麼呢?這些限制使我們通過觀測和經驗,确定這兩個應用間可能存在幹擾因素,如果有超過一定數量的兩類應用的執行個體部署在一起,會影響彼此的性能,是以,在進行排程決策的時候盡量不讓這種互相幹擾的應用的執行個體出現“紮堆”的現象。

優化的目标

我們的優化目标是在維持每台機器的資源使用率在一定水準的基礎上(具體數字不透露,你好好看一下題目的描述,相信你可以判斷出來的),盡量減少使用的機器的數目(即實際部署了容器的機器的數目)。為什麼這樣設計呢?較少機器的數目很容易想到是節省成本,而維持機器的資源使用率在一定水準,而不是100%,在實際生産中是很有意義的。因為每個應用都會有一定的、不可準确預計的負載增加,是以,我們需要在每台機器上流出一定的“餘量”來應對每個執行個體可能突然需要的計算資源。

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

我們誠摯的邀請所有對資源排程、運籌優化、資源管理、算法有興趣的同學、學者來參加我們的大賽,獎金豐厚而且有前往美國參加Hackathon的機會!

幹貨:排程算法的價值與阿裡的應用實踐

賽題解讀直播

6月27日(下周三)晚8點

阿裡系統軟體事業部排程系統技術專家 丁海洋(花名:臨石)将為大家線上直播,深度解讀賽題!

__分享内容__:

1.Datacenter和Warehouse-Scale Computers

2.阿裡巴巴需要什麼樣的資源管理系統

3.阿裡巴巴的叢集管理和排程系統:Sigma

4.排程算法與資源管理

5.首屆阿裡全球排程算法賽題解讀

添加大賽小助手微信:alibabass88 即可進入選手群并擷取直播位址

繼續閱讀