陸志剛, 吳悅文, 顧澤宇, 吳啟德

?

應(yīng)用感知的容器資源調(diào)度優(yōu)化方法①

陸志剛1,2,3, 吳悅文1,2, 顧澤宇1,2, 吳啟德4

1(中國(guó)科學(xué)院軟件研究所, 北京 100190)2(中國(guó)科學(xué)院大學(xué), 北京 100049)3(蘇州工業(yè)園區(qū)國(guó)有資產(chǎn)控股發(fā)展有限公司, 蘇州 215028)4(中國(guó)科學(xué)技術(shù)大學(xué)計(jì)算機(jī)科學(xué)學(xué)院, 合肥 230026)

資源調(diào)度作為容器管理的關(guān)鍵技術(shù)之一, 已有研究工作或滿足公平性目標(biāo), 將工作負(fù)載平均調(diào)度到所有物理節(jié)點(diǎn)上, 關(guān)注吞吐率指標(biāo); 或滿足性能目標(biāo), 將工作負(fù)載關(guān)聯(lián)的多個(gè)容器載體調(diào)度到相同或相近的物理節(jié)點(diǎn)上, 關(guān)注響應(yīng)時(shí)間. 提出應(yīng)用感知的容器資源調(diào)度方法, 采用多隊(duì)列模型兼顧公平性和性能目標(biāo). 實(shí)驗(yàn)結(jié)果顯示, 對(duì)于典型的大數(shù)據(jù)處理場(chǎng)景, 本方法和已有公平性調(diào)度方法具有相當(dāng)?shù)耐掏侣? 對(duì)于典型的事務(wù)型應(yīng)用場(chǎng)景, 本方法相對(duì)于已有的公平性調(diào)度方法, 事務(wù)型應(yīng)用的延遲最多可減少100%.

應(yīng)用感知; 容器; 資源調(diào)度; 大數(shù)據(jù); 事務(wù)型

容器是一種新型虛擬化技術(shù), 其核心思想是操作系統(tǒng)復(fù)用, 模擬沙箱進(jìn)程環(huán)境, 因而具有接近物理主機(jī)性能、資源利用率高的特性[1]. 近年來, 容器已在國(guó)內(nèi)外產(chǎn)業(yè)界得到廣泛應(yīng)用, 比如Docker Cloud[2], 羊年春晚微信搶紅包[3], 京東618商品秒殺[4]等. 另具Gartner研究報(bào)告[5], 全球約70%的應(yīng)用將于2019年遷移到容器基礎(chǔ)設(shè)施上. 因此, 容器正逐漸成為應(yīng)用運(yùn)行支撐的主流基礎(chǔ)設(shè)施.

資源調(diào)度是大規(guī)模容器管理的核心組件之一, 也是學(xué)術(shù)界和工業(yè)界的關(guān)注重點(diǎn), 如Google Kubernetes[7]、Microsoft Apollo[8]、Apache Mesos[9]. 資源調(diào)度是指通過合適的調(diào)度策略或算法, 將容器合理的分配到不同的物理機(jī)器上, 以在滿足特定約束條件的情況下提高資源利用率, 節(jié)省運(yùn)營(yíng)成本.

已有研究考慮公平性因素, 適用大數(shù)據(jù)處理應(yīng)用, 其核心思想是將封裝大數(shù)據(jù)處理應(yīng)用的容器均分到物理服務(wù)器上, 優(yōu)化目標(biāo)是吞吐率[10,11]. 另有研究關(guān)注性能因素, 適合事務(wù)類應(yīng)用, 其核心思想是將封裝了事務(wù)類應(yīng)用的容器盡量部署在相同的物理服務(wù)器上, 優(yōu)化目標(biāo)是延遲[12,13]. 由此可見, 已有研究通常在運(yùn)行時(shí)只能滿足單一優(yōu)化目標(biāo), 難以根據(jù)應(yīng)用類型選擇最優(yōu)的調(diào)度算法.

本文提出應(yīng)用感知的容器資源調(diào)度方法, 該方法采用多隊(duì)列模型, 每個(gè)隊(duì)列采用單一調(diào)度策略, 并可根據(jù)應(yīng)用類型, 選擇合適的調(diào)度策略, 從而達(dá)到兼顧公平性和性能目標(biāo). 實(shí)驗(yàn)結(jié)果顯示, 對(duì)于典型的大數(shù)據(jù)處理場(chǎng)景, 本方法和已有公平性調(diào)度方法具有相當(dāng)?shù)耐掏侣? 對(duì)于典型的事務(wù)型應(yīng)用場(chǎng)景, 本方法相對(duì)于已有的公平性調(diào)度方法, 事務(wù)型應(yīng)用的延遲最多可減少100%. 例如文獻(xiàn)[12]選取事務(wù)型應(yīng)用TPC-W作為測(cè)試基準(zhǔn), 采用延遲優(yōu)化的調(diào)度算法, 在并發(fā)500的場(chǎng)景下, 應(yīng)用平均響應(yīng)時(shí)間從507ms下降到237ms.

1 系統(tǒng)概述

1.1 體系結(jié)構(gòu)

如圖1所示, 整個(gè)體系結(jié)構(gòu)涉及應(yīng)用層、資源調(diào)度層和物理資源層, 其中資源調(diào)度層由應(yīng)用類型聲明器、數(shù)據(jù)監(jiān)測(cè)器、調(diào)度決策器、應(yīng)用放置器四個(gè)部分.

圖1 體系結(jié)構(gòu)

應(yīng)用聲明器: 用戶在部署應(yīng)用的時(shí)候, 需要顯示聲明應(yīng)用的類型是事務(wù)型, 還是大數(shù)據(jù)處理型, 見1.2節(jié);

資源監(jiān)測(cè)器: 用于監(jiān)測(cè)物理資源的使用率, 基于開源監(jiān)測(cè)軟件Zabbix實(shí)現(xiàn);

調(diào)度決策器: 考慮資源空閑和應(yīng)用類型兩個(gè)維度因素, 采用多隊(duì)列模型進(jìn)行刻畫, 并實(shí)現(xiàn)相關(guān)的資源調(diào)度算法, 見第2節(jié);

應(yīng)用放置器: 依據(jù)調(diào)度決策器輸出結(jié)果, 調(diào)用容器暴露API進(jìn)行應(yīng)用放置, 構(gòu)建應(yīng)用與物理資源的映射關(guān)系.

1.2 應(yīng)用聲明器

1.2.1手動(dòng)設(shè)定

本文應(yīng)用App由向三元組刻畫應(yīng)用, 其中ID用于標(biāo)識(shí)是應(yīng)用的唯一標(biāo)識(shí); TYPE表示應(yīng)用的類型, 在本文中用于描述事務(wù)型或者大數(shù)據(jù)處理型; ComponentSet用于描述應(yīng)用的組件組成, 比如事務(wù)型應(yīng)用通常由Web服務(wù)器、應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器三部分組成; 大數(shù)據(jù)處理型應(yīng)用通常包括任務(wù)調(diào)度和分發(fā)器(如Hadoop的Master節(jié)點(diǎn))、任務(wù)執(zhí)行器(如Hadoop的Map和Reduce節(jié)點(diǎn))和中間數(shù)據(jù)存儲(chǔ)(如Hadoop的HDFS)三個(gè)部分.

ComponentSet采用有向無環(huán)圖進(jìn)行刻畫, 用于描述應(yīng)用組件的規(guī)模, 以及各個(gè)組件的資源需求. 其中, 點(diǎn)代表應(yīng)用組件實(shí)例, 點(diǎn)的屬性包括資源需求, 由二元組組成, 邊代表應(yīng)用組件實(shí)例之間的調(diào)用關(guān)系, 比如對(duì)于典型事務(wù)型應(yīng)用TPC-W, 點(diǎn)分別代表Web服務(wù)器、應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器, 邊代表Web服務(wù)器與應(yīng)用服務(wù)器調(diào)用關(guān)系, 或者應(yīng)用服務(wù)器與數(shù)據(jù)庫(kù)服務(wù)器的調(diào)用關(guān)系, 如圖2所示.

圖2 體系結(jié)構(gòu)

1.2.2自動(dòng)識(shí)別

相關(guān)研究工作嘗試自動(dòng)識(shí)別并挖掘應(yīng)用構(gòu)成, 這些方法通常采用代理機(jī)制, 適用于離線測(cè)試階段, 其核心思想是將Agent部署在容器中, 監(jiān)測(cè)和記錄網(wǎng)絡(luò)交互信息, 采用PCA等算法過濾噪音數(shù)據(jù), 基于圖模型分析獲取容器(及其應(yīng)用組件)的關(guān)聯(lián)關(guān)系.

2　各模塊的算法設(shè)計(jì)與實(shí)現(xiàn)

2.1 基于多隊(duì)列資源調(diào)度機(jī)制

如圖3所示, 資源調(diào)度器由多隊(duì)列模型組成, 分別實(shí)現(xiàn)公平性資源調(diào)度算法和延遲敏感調(diào)度算法, 以滿足公平性或性能目標(biāo), 其具體流程:

① 根據(jù)應(yīng)用聲明實(shí)例化隊(duì)列, 其中隊(duì)列的長(zhǎng)度為應(yīng)用組件的規(guī)模, 隊(duì)列中每個(gè)元素刻畫該應(yīng)用組件的資源需求;

② 如果應(yīng)用為事務(wù)型, 調(diào)用公平性調(diào)度算法, 最終通過容器API, 構(gòu)建應(yīng)用組件與容器服務(wù)器的映射關(guān)系, 見2.2節(jié);

③ 如果應(yīng)用為大數(shù)據(jù)處理型, 調(diào)用延遲敏感調(diào)度算法, 最終通過容器API, 構(gòu)建應(yīng)用組件與容器服務(wù)器的映射關(guān)系, 見2.3節(jié).

圖3 基于多隊(duì)列資源調(diào)度機(jī)制

2.2公平調(diào)度算法SAF

公平性資源調(diào)度算法的核心思想是均衡, 將容器服務(wù)器根據(jù)資源的空閑狀態(tài)進(jìn)行排序, 將應(yīng)用中每個(gè)組件依次進(jìn)行調(diào)度, 每次調(diào)度將應(yīng)用組件部署在資源空閑的容器服務(wù)器上.

算法1. 公平調(diào)度算法SAF 輸入:A set of physical machine PMSet; A specified application App.輸出:The relationship between componenets and PMSet f(componenet,PMSet),, where componeneti∈App.1. For componeneti in App 2. PMSet=DescendingSort(PMSet)3. PMj = PMSet.remove(0)4. PM = PM ? Attr(componeneti)5. PMSet.add(PMj)6. Add f(componeneti,PMj)7. End For

算法1為公平調(diào)度算法SAF(Scheduling algorithm based on fairness)實(shí)現(xiàn), 遍歷應(yīng)用包含的所有組件componenet, 然后根據(jù)容器物理主機(jī)的資源空閑進(jìn)行降序排列, 則第一個(gè)元素即為最為空閑的容器主機(jī)(第1行-2行). 將應(yīng)用組件調(diào)度到資源最后空閑的容器主機(jī)上, 同時(shí)更新該容器主機(jī)的空閑資源狀態(tài), 并記錄下此時(shí)應(yīng)用組件和容器服務(wù)器的關(guān)聯(lián)關(guān)系(第3行-6行).

2.3公平調(diào)度算法SAL

公平調(diào)度算法SAL(Scheduling algorithm based on latency-aware)是一種延遲敏感的資源調(diào)度算法, 其核心思想是優(yōu)先將應(yīng)用組件調(diào)度到相同的容器物理機(jī)上, 即最大資源利用率每臺(tái)容器物理服務(wù)器.

算法2為公平調(diào)度算法SAL實(shí)現(xiàn). 首先根據(jù)容器物理主機(jī)的資源空閑進(jìn)行降序排列, 則第一個(gè)元素即為最為空閑的容器主機(jī)(第1行-2行). 遍歷應(yīng)用包含的所有組件, 優(yōu)先調(diào)度到相同的容器物理服務(wù)器上, 直到該容器服務(wù)器資源飽和, 此過程中記錄下應(yīng)用組件和容器服務(wù)器的關(guān)聯(lián)關(guān)系(第3行-5行, 第9行). 如果容器服務(wù)器資源飽和, 且此時(shí)還有應(yīng)用組件未被調(diào)度(6行-8行), 則重新根據(jù)容器物理主機(jī)的資源空閑進(jìn)行降序排列, 選擇空閑的容器服務(wù)器接著調(diào)度, 直到應(yīng)用組件全部調(diào)度完成為止.

算法2. 公平調(diào)度算法SAL 輸入:A set of physical machine PMSet; A specified application App.輸出:The relationship between componenets and PMSet f(componenet,PMSet),where componeneti∈App.1. PMSet =DescendingSort(PMSet)2. PMj = PMSet.remove(0)3. While PMj > 04. For componeneti in App 5. PM = PM ? Attr(componeneti)6. If(PMj<0)7. PM = PM + Attr(componeneti)8. Break;9. Add f(componeneti,PMj)10. End For11. PMSet.add(PMj)12. PMSet =DescendingSort(PMSet)13. PMj = PMSet.remove(0)14. End While

3　實(shí)驗(yàn)與驗(yàn)證

實(shí)驗(yàn)包括三個(gè)部分, 首先是實(shí)驗(yàn)環(huán)境的介紹, 接著對(duì)比SAF和SAL算法在事務(wù)型應(yīng)用場(chǎng)景下, 性能的差異性; 最后對(duì)比兩種算法在大數(shù)據(jù)處理應(yīng)用場(chǎng)景下, 吞吐率的差異性. 從而驗(yàn)證本方法的有效性. 其中SAF算法本質(zhì)是公平調(diào)度, 可反映Kubernetes、Omage等系統(tǒng)的資源調(diào)度效果; SAL算法本質(zhì)為延遲敏感, 可反映Apollo、Nomad和DelaySchedule的資源調(diào)度效果.

4.1 實(shí)驗(yàn)環(huán)境與負(fù)載

如圖4所示, 實(shí)驗(yàn)環(huán)境由21臺(tái)刀片機(jī)組成, 每臺(tái)刀片的配置都是16 cores, 2.4GHz Intel Xeon CPU和24G內(nèi)存: 其中10臺(tái)刀片作為HDFS服務(wù)器; 10臺(tái)刀片安裝容器軟件, 用于部署容器, 1臺(tái)刀片作為負(fù)載發(fā)生器, 模擬用戶進(jìn)行壓力測(cè)試, 1臺(tái)刀片安裝本文所述應(yīng)用敏感的資源調(diào)度器. 所有刀片設(shè)備之間通過千兆交換機(jī)互聯(lián).

圖4 實(shí)驗(yàn)環(huán)境

事務(wù)型應(yīng)用采用TPC-W基準(zhǔn)測(cè)試, 前端Web服務(wù)器組件選用HttpServer 2.0, 中間應(yīng)用服務(wù)器組件tomcat 8.0, 后端數(shù)據(jù)庫(kù)服務(wù)器組件選用Mysql 5.6, 數(shù)據(jù)庫(kù)采用默認(rèn)設(shè)置, 即10 000件商品和1 440 000個(gè)用戶. 上述應(yīng)用組件均部署在2CPU和2GB內(nèi)存的容器中. 其中, 工作負(fù)載來源于1998年法國(guó)世界杯網(wǎng)站, 分別模擬50、175、250和325并發(fā)用戶, 圖5所示.

圖5 事物型負(fù)載

大數(shù)據(jù)處理應(yīng)用采用WordCount和Sort兩類基準(zhǔn)測(cè)試, 數(shù)據(jù)存在HDFS中, 前者數(shù)據(jù)總大小為10GB, 后者數(shù)據(jù)總大小為1GB, 且應(yīng)用組件均部署在2CPU和2GB內(nèi)存的容器中. 表1給出了相關(guān)的配置.

表1 Hadoop基礎(chǔ)測(cè)試配置表

4.2 事務(wù)型應(yīng)用場(chǎng)景下本方法有效性

本方法調(diào)度事務(wù)型應(yīng)用時(shí)會(huì)采用SAL算法, 而Kubernetes、Omage等系統(tǒng)會(huì)默認(rèn)采用SAF算法. 因此, 本方法與Kubernetes、Omage等系統(tǒng)資源調(diào)度算法對(duì)比本質(zhì)可轉(zhuǎn)換為事務(wù)型應(yīng)用在兩種調(diào)度算法下的性能(響應(yīng)時(shí)間刻畫)差異如圖6所示.

圖6 SAL和SAF算法下事務(wù)型用性能對(duì)比

隨著并發(fā)用戶的增加, 事務(wù)型應(yīng)用在SAF算法和SAL算法下的響應(yīng)時(shí)間的比例差異越大, 最大可達(dá)到近3倍. 這是因?yàn)轫憫?yīng)時(shí)間度量指標(biāo)是指用戶請(qǐng)求經(jīng)過TPC-W測(cè)試基準(zhǔn)Web服務(wù)器、應(yīng)用服務(wù)器、數(shù)據(jù) 庫(kù)服務(wù)器處理, 最終返回用戶的總延遲時(shí)間總和. 采用SAL算法, 由于應(yīng)用組件調(diào)度在相同容器物理服務(wù)上, 其延遲時(shí)間僅僅為SAF算法跨主機(jī)的網(wǎng)絡(luò)延遲是少1/4.

4.3 大數(shù)據(jù)處理應(yīng)用場(chǎng)景下本方法有效性

本方法調(diào)度事務(wù)型應(yīng)用時(shí)會(huì)采用SAF算法, 而DelaySchedule等系統(tǒng)會(huì)默認(rèn)采用SAL算法. 因此, 本方法與DelaySchedule等系統(tǒng)資源調(diào)度算法對(duì)比本質(zhì)可轉(zhuǎn)換為事務(wù)型應(yīng)用在兩種調(diào)度算法下的性能(吞吐率刻畫)差異如圖7所示.

圖7 SAL和SAF算法下事務(wù)型應(yīng)用性能對(duì)比

無論是WordCount測(cè)試基準(zhǔn), 還時(shí)Sort測(cè)試基準(zhǔn), 隨著Map實(shí)例數(shù)增加, Map階段在SAF算法和SAL算法下的吞吐率的比例差異越大, 其中WordCount非常明顯, 最差可相差2.5倍. 這是因?yàn)閷?shí)驗(yàn)環(huán)境全部是千兆網(wǎng)絡(luò), SAL算法會(huì)將應(yīng)用組件優(yōu)先調(diào)度到相同容器物理服務(wù)器上, 而單臺(tái)容器服務(wù)器理論網(wǎng)絡(luò)吞吐率上限為125MB/s, 會(huì)Hadoop應(yīng)用實(shí)例會(huì)因?yàn)榫W(wǎng)絡(luò)資源競(jìng)爭(zhēng)而成為瓶頸. 仔細(xì)分析實(shí)驗(yàn)數(shù)據(jù), 單個(gè)WordCount的Map階段吞吐率約為50MB/s, Sort約為20MB/s. 在SAL算法下, 由于Hadoop應(yīng)用每個(gè)實(shí)例的資源配置為2CPU和2GB內(nèi)存, 即每臺(tái)容器服務(wù)器可部署7個(gè)WordCount實(shí)例和Sort實(shí)例, 故導(dǎo)致資源瓶頸.

4　結(jié)語

資源調(diào)度作為容器管理的關(guān)鍵技術(shù)之一, 已有研究工作難以同時(shí)適用大數(shù)據(jù)處理應(yīng)用和事務(wù)型應(yīng)用場(chǎng)景. 本文提出應(yīng)用感知的容器資源調(diào)度方法, 其核心思想是采用多隊(duì)列模型, 兼顧兩種場(chǎng)景. 實(shí)驗(yàn)結(jié)果顯示本方法具有有效性. 本文下一步工作擬開展基于學(xué)習(xí)的應(yīng)用類型自動(dòng)識(shí)別技術(shù), 進(jìn)一步提高本方法的實(shí)用性.

1 Abraham L, Allen J, Barykin O, et al. Scuba: Diving into data at facebook. Proc. of the Vldb Endowment, 2013, 6(11): 1057–1067.

2 Ananthanarayanan G, Agarwal S, Kandula S, et al. Scarlett: Coping with skewed content popularity in MapReduce clusters. In EuroSys, 2011: 287–300.

3 Akidau T, Balikov A, Bekiro, et al. MillWheel: Fault-tolerant stream processing at internet scale. Proc. of the Vldb Endowment, 2013, 6(11): 1033–1044.

4 Andersen DG, Franklin J, Kaminsky M, et al. FAWN: A fast array of wimpy nodes. Communications of the ACM, 2011, 54(7): 101–109.

5 Petrucci V, Laurenzano M, Doherty J, et al. Octopus-man: QoS-driven task management for heterogeneous multicores in warehouse-scale computers. 2015 IEEE 21st International Symposium on High Performance Computer Architecture (HPCA). IEEE Computer Society. 2015. 246–258.

6 Aksanli B, Venkatesh J, Zhang L, et al. Utilizing green energy prediction to schedule mixed batch and service jobs in data centers. Association for Computing Machinery, 2011: 53–57.

7 Marchukov M, Song YJ, Bronson N, et al. TAO: Facebook’s distributed data store for the social graph. Proc. of the 2013 USENIX Conference on Annual Technical Conference. USENIX Association. 2013. 49–60.

8 Baker J, Bond C, Corbett J, et al. Megastore: Providing scalable, highly available storage for interactive services. 5th Biennial Conference on Innovative Data Systems Research (CIDR ’11). Asilomar, California, USA. 2011. 223–234.

9 Baumann A, Barham P, Dagand PE, et al. The multikernel: A new OS architecture for scalable multicore systems. ACM Sigops, Symposium on Operating Systems Principles. ACM. 2009. 29–44.

10 Belay A, Bittau A, Mashtizadeh A, et al. Dune: Safe user-level access to privileged CPU features. Symposium on Operating Systems Design & Implementation (OSDI). 2012. 335–348.

11 Schwarzkopf M, Konwinski A, Abd-El-Malek M, et al. Omega: Flexible, scalable schedulers for large compute clusters. ACM European Conference on Computer Systems. ACM. 2013. 351–364.

12 Tune E. Large-scale cluster management at Google with Borg. Proc. of the 10th European Conference on Computer Systems. ACM. 2015. 18.

Application-Aware Container-Oriented Resource Scheduling Optimized Approach

LU Zhi-Gang1,2,3, WU Yue-Wen1,2, GU Ze-Yu1,2, WU Qi-De4

1(Institute of Software, Chinese Academy of Sciences, Beijing 100190, China)2(University of Chinese Academy of Sciences, Beijing 100049, China)3(SIP State Property Holding Co. Ltd., Suzhou 215028, China)4(University of Science and Technology of China, Hefei 230026, China)

Resource scheduling is a key technique for container management. Prior work or meets the goal of fairness, the work load average is scheduled to all physical nodes, pays attention to the throughput indicator; or to meets performance targets, multiple carrier scheduling the workload related to physical nodes in the same or similar, pay attention to the response time. In this paper, it presents an application-aware resource scheduling approach, and employs a multi-queue model to meet both fairness and performance targets. Experimental results show that the approach has equal throughput for typical big data processing scenarios, and can reduce latency by up to 100% for typical transactional application scenarios.

application-aware; container; resource scheduling; big data; transaction-based web

2016-06-16;

2016-07-19

[10.15888/j.cnki.csa.005621]