《美團(tuán)點(diǎn)評容器平臺HULK的調(diào)度系統(tǒng)》要點(diǎn)：
本文介紹了美團(tuán)點(diǎn)評容器平臺HULK的調(diào)度系統(tǒng)，希望對您有用。如果有疑問，可以聯(lián)系我們。

本文授權(quán)轉(zhuǎn)載自微信公眾號：美團(tuán)點(diǎn)評技術(shù)團(tuán)隊(duì)

美團(tuán)點(diǎn)評作為國內(nèi)最大的O2O平臺,業(yè)務(wù)熱度的高峰低谷非常顯著且規(guī)律,如果遇到節(jié)假日或促銷活動,流量還會在短時間內(nèi)出現(xiàn)成倍的增長.過去傳統(tǒng)虛擬機(jī)的服務(wù)運(yùn)行及部署機(jī)制在應(yīng)對服務(wù)快速擴(kuò)容、縮容需求中存在諸多不足：

• 資源實(shí)例創(chuàng)建慢,需要預(yù)先安裝好運(yùn)行所需的環(huán)境,比如JDK等.
• 擴(kuò)容后的實(shí)例,需要經(jīng)過代碼部署流程,一些情況下還需要修改配置后才能承接流量.
• 資源申請容易回收難,促銷活動后做相關(guān)資源的回收下線會比較漫長.
• 由于業(yè)務(wù)存在典型的高峰低谷,為保障業(yè)務(wù)穩(wěn)定,資源實(shí)例數(shù)要保障能抗高峰期容量峰值的1-2倍,從而導(dǎo)致非高峰期資源大量閑置,整體利用效率低.

注意到上面這些問題后,我們經(jīng)過調(diào)研與測試,結(jié)合業(yè)界的實(shí)踐經(jīng)驗(yàn),決定基于Docker容器技術(shù)來實(shí)現(xiàn)服務(wù)的彈性伸縮,有效應(yīng)對快速擴(kuò)縮容需求、提升資源利用效率.

Docker容器技術(shù)也是一類虛擬化技術(shù),不同于虛擬機(jī)的硬件虛擬化,容器是基于操作系統(tǒng)內(nèi)核的隔離機(jī)制實(shí)現(xiàn).容器省去了模擬底層硬件、指令等操作,直接基于宿主機(jī)內(nèi)核,并隔離出獨(dú)立的系統(tǒng)環(huán)境、加以資源限制,能有效提升啟動速度和性能.

HULK容器平臺簡介

美團(tuán)點(diǎn)評基礎(chǔ)架構(gòu)團(tuán)隊(duì)在2015年中旬啟動了公司級的容器集群管理及彈性伸縮平臺——HULK項(xiàng)目,目標(biāo)是提供Docker容器平臺,推動公司的服務(wù)容器化,實(shí)現(xiàn)自動的彈性擴(kuò)容、縮容,提升資源利用率、業(yè)務(wù)運(yùn)維效率并降低IT運(yùn)維成本.

HULK是美國漫威漫畫旗下超級英雄“綠巨人”,擁有強(qiáng)大的變身能.變身后的綠巨人對各類疾病、射線、毒藥及物理攻擊有很高的免疫力,加上超強(qiáng)的再生能力使得其非常強(qiáng)大.

我們選擇HULK作為項(xiàng)目名,就是希望美團(tuán)點(diǎn)評服務(wù)在接入HULK之后可以擁有綠巨人般強(qiáng)大的變身能力(彈性擴(kuò)縮),進(jìn)而在此基礎(chǔ)上提升服務(wù)的健壯性、穩(wěn)定性及資源利用率.

HULK容器平臺系統(tǒng)層次圖

在HULK所有模塊中,調(diào)度系統(tǒng)負(fù)責(zé)對資源池進(jìn)行統(tǒng)一的調(diào)度分配與管理.主要職責(zé)包括：

1. 接受上層彈性伸縮及集群管理模塊的資源申請、回收請求,執(zhí)行資源分配.
2. 綜合多種資源利用、服務(wù)優(yōu)化的調(diào)度算法,決策最優(yōu)資源部署位置,提高資源利用率、節(jié)約成本并保障服務(wù)穩(wěn)定性.
3. 對接云平臺IaaS層.

本文將主要對HULK容器平臺的調(diào)度系統(tǒng)進(jìn)行介紹,包括當(dāng)前調(diào)度系統(tǒng)的設(shè)計(jì)、考量指標(biāo)、相關(guān)算法等.

HULK調(diào)度系統(tǒng)介紹

核心指標(biāo)

從HULK彈性調(diào)度系統(tǒng)的設(shè)計(jì)以及后續(xù)的演進(jìn)過程來看,一個完善的調(diào)度系統(tǒng)主要需要關(guān)注以下三個指標(biāo)：

調(diào)度系統(tǒng)核心指標(biāo)

• 資源利用率：即提高整體物理集群的資源利用率.一個優(yōu)秀的調(diào)度系統(tǒng)可以把資源利用率提高到30%~70%,而簡陋的調(diào)度系統(tǒng)甚至?xí)官Y源利用率降低到10%以下.
• 業(yè)務(wù)最優(yōu)化：即保障運(yùn)行業(yè)務(wù)的穩(wěn)定高可用,以及服務(wù)相互調(diào)用的優(yōu)化.比如,如果調(diào)度系統(tǒng)一味的追求資源利用率,將宿主機(jī)上堆砌超過其負(fù)載能力的實(shí)例,又或一臺宿主機(jī)/機(jī)架的故障會影響到一個服務(wù)下所有實(shí)例的運(yùn)行,都在業(yè)務(wù)穩(wěn)定性上打了折扣.
• 并發(fā)調(diào)度能力：調(diào)度系統(tǒng)請求處理能力的體現(xiàn).一個大規(guī)模的物理集群上,往往運(yùn)行了數(shù)以千百計(jì)的業(yè)務(wù),當(dāng)出現(xiàn)調(diào)度請求高峰的場景下,調(diào)度系統(tǒng)要有能力在短時間內(nèi)給出答案,即使這個答案可能只是全局近似最優(yōu)解.

調(diào)度系統(tǒng)設(shè)計(jì)難題

調(diào)度系統(tǒng)設(shè)計(jì)的難題,在于幾個調(diào)度核心指標(biāo)在實(shí)現(xiàn)上存在的矛盾關(guān)系,類似于CAP理論中的三要素,無法同時滿足.

在CAP理論中,Consistency(一致性)、Availability(可用性)與Partition Tolerance(分區(qū)容錯性)無法同時滿足.如果追求可用性與分區(qū)容錯性,則需要犧牲強(qiáng)一致性,只能保證最終一致性；而如果要保障強(qiáng)一致性與可用性,如果出現(xiàn)網(wǎng)絡(luò)故障將無法正常工作.

類似的,在調(diào)度系統(tǒng)中,如果要追求極限的資源利用率,則每一次調(diào)度的結(jié)果必須是基于當(dāng)前資源池狀態(tài)的最優(yōu)解,因此不管調(diào)度隊(duì)列還是調(diào)度處理計(jì)算只能是“單行道”,效率低下是毋庸置疑的,大批量伸縮調(diào)度場景下任務(wù)堆積嚴(yán)重.

如果追求高效的調(diào)度能力,則所有調(diào)度請求需要并發(fā)處理.但底層資源池只有一個,很容易出現(xiàn)多個調(diào)度請求爭搶同一份資源的情況.這種情況下,就要采取措施來保障資源層數(shù)據(jù)一致性,且調(diào)度所得的結(jié)果不能保證是全局最優(yōu)解(無法最大化資源利用率).

業(yè)界解決思路

Mesos

Mesos采用雙層調(diào)度的理念,把應(yīng)用相關(guān)的管理交由上層Framework來做,這也是Mesos與Kubernetes等系統(tǒng)最大的不同點(diǎn).Mesos只是分布式系統(tǒng)內(nèi)核,即管理分布式資源、對外暴露標(biāo)準(zhǔn)接口來操作集群資源(屏蔽資源層細(xì)節(jié)).在雙層調(diào)度的模式下,Mesos只負(fù)責(zé)在不同的Framework之間分派資源,將資源作為Offer的形式提供給Framework.

這種做法把上述調(diào)度設(shè)計(jì)矛盾丟給了Framework,但如果只從提供資源Offer的角度來看,這是一種并發(fā)調(diào)度的形式(同一個Mesos資源池,資源要提供給上層多個Framework).Mesos解決并發(fā)調(diào)度、資源池?cái)?shù)據(jù)一致性的方案是,資源Offer同時只會分派給一個Framework.這種資源分派方式是悲觀的,資源被Framework獨(dú)占,直到返回或超時.

顯然,這種悲觀鎖導(dǎo)致了Mesos雙層調(diào)度的并發(fā)粒度較小,但是在多數(shù)情況下,同個Mesos集群上層的Framework數(shù)量不會太多,有時只有一個Framework在獨(dú)享資源,因此這種悲觀鎖的方案一般不會存在分配調(diào)度的瓶頸問題.

Omega

Omega同樣采用了將資源分派給上層應(yīng)用的調(diào)度方式,與Mesos的悲觀鎖不同,Omega采用了樂觀鎖(MVCC,基于多版本的并發(fā)訪問控制)解決并發(fā)調(diào)度的問題,因此Omega也被稱為共享狀態(tài)調(diào)度器.

由于將資源層信息作為共享數(shù)據(jù)提供給上層所有應(yīng)用,Omega為了解決數(shù)據(jù)一致性,會對所有應(yīng)用調(diào)度的提交沖突做解決,本質(zhì)上是為每個節(jié)點(diǎn)維護(hù)了一個狀態(tài)關(guān)系數(shù)據(jù)庫.從這個角度看,Omega也存在一些缺點(diǎn)：

1. 共享調(diào)度時沖突發(fā)生的頻率,直接影響了整體調(diào)度器的性能.
2. 由于沒有集中的調(diào)度模塊,難以對所有資源分組(Namespace)或用戶的資源使用量做精確限制.
3. 上層調(diào)度器數(shù)量仍然不能很多,并行分發(fā)完整的集群狀態(tài)的開銷較大.

Borg與Kubernetes

Borg據(jù)說現(xiàn)在已經(jīng)逐漸演進(jìn)吸收了Omega的很多設(shè)計(jì)思想,包括共享狀態(tài)調(diào)度模式,然而Kubernetes默認(rèn)調(diào)度plugin的做法仍然是串行處理隊(duì)列中的調(diào)度任務(wù),這也符合Kubernetes追求的簡潔優(yōu)雅.

HULK調(diào)度解決方案

對于調(diào)度器設(shè)計(jì)難題,我們認(rèn)為針對不同的場景,指標(biāo)的側(cè)重點(diǎn)不同.

比如對于分布式系統(tǒng)的CAP,大多數(shù)互聯(lián)網(wǎng)場景下都會保證AP而舍棄C(只保證最終一致性),因?yàn)樵诨ヂ?lián)網(wǎng)分布式集群規(guī)模大、網(wǎng)絡(luò)故障頻發(fā)的場景下,要保證服務(wù)高可用只能犧牲強(qiáng)一致；而對于金融等涉及錢財(cái)?shù)念I(lǐng)域,則一般保證CA、舍棄P,即使遇到網(wǎng)絡(luò)故障時只讀不寫,也必須保證強(qiáng)一致性.

同理對于調(diào)度器資源層設(shè)計(jì),在互聯(lián)網(wǎng)高并發(fā)、彈性伸縮頻發(fā)的場景下,可以犧牲部分資源利用率從而提高并發(fā)調(diào)度能力.

HULK調(diào)度系統(tǒng)模型如下：

HULK調(diào)度模型

如圖,HULK調(diào)度系統(tǒng)分為調(diào)度請求隊(duì)列、調(diào)度計(jì)算模塊、調(diào)度資源池這三個模塊.工作流程如下：

1. 上層HULK彈性伸縮系統(tǒng),將調(diào)度任務(wù)ID寫入調(diào)度請求隊(duì)列中.
2. HULK調(diào)度系統(tǒng)消費(fèi)調(diào)度請求隊(duì)列,取出的調(diào)度任務(wù)ID將由調(diào)度計(jì)算池執(zhí)行調(diào)度計(jì)算,決策出備選的部署位置,并向調(diào)度資源池申請資源.
3. 調(diào)度資源池維護(hù)管理宿主機(jī)集群資源,全部資源會提供給所有調(diào)度任務(wù)共享(與Omega類似),資源池中每個宿主機(jī)都有一個對應(yīng)的Actor來負(fù)責(zé)管理.

調(diào)度計(jì)算模塊(資源調(diào)度算法)

HULK調(diào)度系統(tǒng)的調(diào)度計(jì)算方式與諸多業(yè)界調(diào)度系統(tǒng)類似,通過過濾+打分的方式篩選出“最優(yōu)部署位置”：

HULK調(diào)度任務(wù)

• 宿主機(jī)(Host)：調(diào)度資源池中共享的宿主機(jī)集群,支持pool級別硬隔離,如在線服務(wù)與數(shù)據(jù)庫/緩存的實(shí)例部署在不同的物理機(jī)集群中；支持資源軟隔離,如在線服務(wù)離線任務(wù)混布部署,通過cgroups等機(jī)制隔離和設(shè)置權(quán)重.
• 過濾(Filter)：預(yù)選(Predicates)的概念,通過超售、打散限制策略,排除掉一部分不合需求的宿主機(jī).
• 打分(Rank)：優(yōu)選(Priorities)的概念,通過在線離線混布、不同資源類型混布、宿主機(jī)負(fù)載均衡等策略和對應(yīng)權(quán)重,最終計(jì)算出一個rank值,根據(jù)rank值排序最終得出最優(yōu)部署位置.

超售

不管是在傳統(tǒng)虛擬機(jī)時代還是容器時代,超售始終是一個讓人又愛又恨的機(jī)制.

超售在一定程度上提高了集群的資源利用率,因?yàn)闄C(jī)器在申請之時往往提高對真實(shí)資源消耗的預(yù)估,也就是在服務(wù)運(yùn)行中,絕大多數(shù)情況用不到申請的所有資源.然而正因?yàn)槌?常常會帶來各種因資源爭用引發(fā)的服務(wù)異常,嚴(yán)重的情況下會導(dǎo)致宿主機(jī)上所有實(shí)例的不可用.

HULK容器調(diào)度同樣采用了超售機(jī)制,我們和IaaS層對資源進(jìn)行了分類,可壓縮資源(如CPU、I/O等)使用超售機(jī)制,而不可壓縮資源(如Memory、Disk)只允許在一些測試環(huán)境超售.

相比于是否開啟超售,超售系數(shù)才是更為棘手的難題,它直接關(guān)系到資源利用率和服務(wù)穩(wěn)定性.我們采用了超售上限+動態(tài)系數(shù)的機(jī)制,從IaaS層設(shè)置的超售上限固定了資源超售的上限比例,超過上限的實(shí)例創(chuàng)建將會失敗,而HULK調(diào)度系統(tǒng)會根據(jù)具體場景決定超售系數(shù)：

1. 參考宿主機(jī)實(shí)時監(jiān)控,如Load負(fù)載、內(nèi)存使用、帶寬占用等指標(biāo).
2. 不同的實(shí)例類型(在線、離線)調(diào)度時超售系數(shù)不同.

業(yè)務(wù)實(shí)例打散

隨著物理集群規(guī)模的擴(kuò)大,宿主機(jī)故障頻次也會響應(yīng)提高.如果一個在線服務(wù)的所有實(shí)例都部署在同一個宿主機(jī)上,很可能出現(xiàn)宿主機(jī)宕機(jī)后服務(wù)整體不可用,這是我們不能接受的.

業(yè)務(wù)用戶在HULK上配置不同的伸縮組,每個組對應(yīng)了一個機(jī)房(數(shù)據(jù)中心),同個機(jī)房調(diào)度過程中會把同個服務(wù)的實(shí)例打散到不同的宿主機(jī)上,并優(yōu)先在不同的交換機(jī)(機(jī)架)下.此外,針對數(shù)據(jù)庫/緩存類的實(shí)例還有更嚴(yán)格的容災(zāi)策略,比如Redis實(shí)例調(diào)度部署時,不允許同一個交換機(jī)下部署超過該Redis集群25%的實(shí)例數(shù)量.

在線離線混布

一般來說,在線服務(wù)(如外賣、酒旅等服務(wù))和離線任務(wù)(如定時任務(wù)、爬蟲、大數(shù)據(jù)計(jì)算)的需求資源類型和高峰/執(zhí)行時間不盡相同,將這兩種實(shí)例進(jìn)行混布可以有效提高物理集群的資源利用率.

Borg系統(tǒng)中對prod與non-prod實(shí)例的一類處理方式是,根據(jù)宿主機(jī)上實(shí)例運(yùn)行狀況,實(shí)時調(diào)整實(shí)例的資源配置.比如當(dāng)在線服務(wù)迎來流量高峰、宿主機(jī)內(nèi)存告急時,Borg會調(diào)整宿主機(jī)上non-prod任務(wù)的內(nèi)存配額,以保證在線服務(wù)的穩(wěn)定性.

但這種方案對Google中的部分C/C++服務(wù)適用,在美團(tuán)點(diǎn)評Java服務(wù)的場景下,實(shí)例內(nèi)存配額調(diào)整可能會導(dǎo)致OOM,而重啟服務(wù)非我們所愿.

下圖是HULK某臺宿主機(jī)一天內(nèi)的實(shí)例部署情況：

宿主機(jī)實(shí)例部署

目前HULK平臺上的離線任務(wù)主要還是定時任務(wù)與爬蟲,HULK針對在線離線混布場景從資源分配、時間錯峰上優(yōu)化.根據(jù)美團(tuán)點(diǎn)評的服務(wù)特性,HULK會盡量保證在早晚高峰的時期動態(tài)擴(kuò)容在線服務(wù)承接流量,而在低峰期會對應(yīng)縮容在線服務(wù),并調(diào)度部署離線任務(wù)執(zhí)行.

宿主機(jī)負(fù)載均衡

在調(diào)度計(jì)算的打分過程中,還會參考當(dāng)前宿主機(jī)的負(fù)載情況.

HULK會從監(jiān)控系統(tǒng)中獲取宿主機(jī)的系統(tǒng)監(jiān)控?cái)?shù)據(jù),包括了CPU、Load、Memory、IO等指標(biāo).針對負(fù)載較低的宿主機(jī)我們給予較高的權(quán)重,而負(fù)載較高的宿主機(jī),即使物理資源較為空閑,也不會優(yōu)先選擇部署.

調(diào)度資源池(資源申請算法)

當(dāng)調(diào)度計(jì)算過程決策出一個根據(jù)調(diào)度rank權(quán)重排序好的資源可部署位置列表后,調(diào)度任務(wù)會取列表前n個元素,依次向?qū)?yīng)的宿主機(jī)Actor申請資源,直到宿主機(jī)Actor返回批準(zhǔn)(調(diào)度成功)；如果取出的前n個均被拒絕,調(diào)度任務(wù)需要根據(jù)新的全局資源池共享狀態(tài)再次調(diào)度計(jì)算.

如果兩個調(diào)度任務(wù)基于共享資源狀態(tài)同時申請某個宿主機(jī)上同一塊資源,則宿主機(jī)Actor會根據(jù)mailbox中消息的順序來處理,資源先到先得,后者調(diào)度任務(wù)會繼續(xù)向下一個備選資源的宿主機(jī)Actor嘗試申請.

調(diào)度資源申請

這種資源調(diào)度的架構(gòu)下,調(diào)度的并發(fā)度相比串行調(diào)度有了顯著的提高,即使出現(xiàn)提交沖突,重試機(jī)制也是非常輕量的,一般都可以在前n次之內(nèi)完成.

這里另一個核心問題在于n取值的權(quán)衡.如果n取值1,則每次失敗后就需要根據(jù)當(dāng)前的集群資源狀態(tài)重新調(diào)度計(jì)算,這種情況下調(diào)度資源利用率較高,但效率較低；而若n取值大于1,則重試后的調(diào)度位置往往并非當(dāng)前最佳調(diào)度位置,且n越大這里的最優(yōu)調(diào)度偏差就越大.我們考慮的是根據(jù)當(dāng)前整個系統(tǒng)中的調(diào)度請求數(shù)量來確定這個動態(tài)的n變量取值,當(dāng)調(diào)度任務(wù)較少時n取較小值,當(dāng)調(diào)度任務(wù)較多、彈性伸縮頻繁時,n的取值會相應(yīng)調(diào)大.

調(diào)度模式總結(jié)

總的來看,HULK調(diào)度系統(tǒng)的共享狀態(tài)資源調(diào)度模式與Omega比較相似,不同的是Omega采用MVCC為每個節(jié)點(diǎn)維護(hù)一個狀態(tài)關(guān)系數(shù)據(jù)庫,而HULK使用Actor模型來解決提交沖突.另外,HULK調(diào)度任務(wù)的n次最優(yōu)重試機(jī)制,在互聯(lián)網(wǎng)的彈性伸縮場景下可以帶來更高效的調(diào)度能力.

結(jié)束語

彈性調(diào)度系統(tǒng)作為HULK平臺的核心模塊之一,有著下接美團(tuán)云IaaS平臺、抽象化資源層,上承彈性伸縮系統(tǒng)、處理調(diào)度請求的職責(zé).我們從美團(tuán)點(diǎn)評的服務(wù)特殊性出發(fā),打造適用于大規(guī)模容器化場景的調(diào)度體系,后續(xù)還會在大數(shù)據(jù)離線任務(wù)場景下做更優(yōu)化的深層智能調(diào)度.

此外,我們對Kubernetes等開源解決方案同樣抱有極大的興趣,從Kubernetes近年來的發(fā)展上能看到未來容器平臺的標(biāo)準(zhǔn)雛形,我們也在積極參與和回饋開源社區(qū).

文章來自微信公眾號：Docker

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4111.html