周墨頌 董小社 陳 衡 張興軍

(西安交通大學(xué)電子與信息工程學(xué)院 西安 710049)

(zhoumosong@stu.xjtu.edu.cn)

基于計(jì)算資源運(yùn)行時(shí)剩余能力評(píng)估優(yōu)化云平臺(tái)

周墨頌 董小社 陳 衡 張興軍

(西安交通大學(xué)電子與信息工程學(xué)院 西安 710049)

(zhoumosong@stu.xjtu.edu.cn)

云平臺(tái)資源管理中存在資源供給與需求不匹配的問題，導(dǎo)致平臺(tái)性能受到嚴(yán)重影響.針對(duì)此問題，基于相似任務(wù)建立運(yùn)行時(shí)計(jì)算資源剩余能力評(píng)估模型，該模型利用云計(jì)算負(fù)載中相似任務(wù)執(zhí)行邏輯相同的特點(diǎn)，使用相似任務(wù)代替測(cè)試程序量化資源剩余能力，避免了執(zhí)行測(cè)試程序的計(jì)算資源代價(jià)；依據(jù)該模型提出了一種運(yùn)行時(shí)云計(jì)算資源剩余能力分類評(píng)估方法RCE(resource capacity evaluation)，該方法綜合各方面因素評(píng)估運(yùn)行時(shí)資源剩余能力，具有運(yùn)行時(shí)代價(jià)低、評(píng)估結(jié)果準(zhǔn)確且有時(shí)效性的特點(diǎn).將RCE評(píng)估結(jié)果應(yīng)用在若干算法中，以提高云平臺(tái)資源供給與需求的匹配程度并優(yōu)化云平臺(tái)各方面性能；在獨(dú)享環(huán)境和真實(shí)云環(huán)境中驗(yàn)證了RCE方法和基于RCE的算法，實(shí)驗(yàn)結(jié)果表明:RCE評(píng)估結(jié)果及時(shí)反映了計(jì)算資源能力變化，為算法和平臺(tái)的優(yōu)化提供了有力支持，基于RCE優(yōu)化的算法解決了云計(jì)算資源管理中資源供給與需求不匹配問題并大幅提高云計(jì)算平臺(tái)性能.

云計(jì)算；資源能力評(píng)估；相似任務(wù)；資源管理；平臺(tái)優(yōu)化

目前，云平臺(tái)普遍采用的資源管理算法只考慮資源量而忽略資源的品質(zhì).例如，Hadoop[1]使用槽作為資源劃分單位，代表定量的CPU和內(nèi)存資源.Yarn[2]使用容器封裝一定虛擬核和內(nèi)存資源.Hadoop和Yarn均不保證所分配計(jì)算資源品質(zhì).資源品質(zhì)因素在資源管理中十分重要：資源的品質(zhì)可能直接影響任務(wù)的資源需求量，比如相同任務(wù)在不同品質(zhì)的CPU上可呈現(xiàn)出不同的資源需求量；資源品質(zhì)也可能影響資源總量，比如品質(zhì)好的網(wǎng)絡(luò)資源具有更高的傳輸帶寬；負(fù)載的資源使用行為可能造成資源品質(zhì)持續(xù)波動(dòng)，比如負(fù)載的多少可以影響CPU的切換頻率，從而影響CPU資源品質(zhì).在資源管理時(shí)忽略計(jì)算資源的品質(zhì)導(dǎo)致資源分配與任務(wù)資源需求不匹配：1)如果資源供給過剩，則任務(wù)執(zhí)行過程中易出現(xiàn)資源碎片，造成資源浪費(fèi)[3]；2)如果資源供給不足，則任務(wù)執(zhí)行過程中易出現(xiàn)資源瓶頸，造成性能下降[4].另外，云計(jì)算服務(wù)器間普遍存在的異構(gòu)性加劇了計(jì)算資源品質(zhì)的差異，從而增加了資源供給與需求不匹配的頻率和程度，嚴(yán)重影響云平臺(tái)性能[3,5-7].

資源供給與需求不匹配的原因在于資源管理中沒有精確量化資源的剩余能力，即資源品質(zhì)和資源量.為了解決上述問題，云平臺(tái)資源管理中需要一種評(píng)估計(jì)算資源剩余能力的方法.現(xiàn)存的性能評(píng)估方法[8-10]均因時(shí)效性、準(zhǔn)確性以及代價(jià)等問題而不宜應(yīng)用在云平臺(tái)的資源管理決策中.本文提出計(jì)算資源剩余能力評(píng)估方法RCE(resource capacity evaluation)，該方法使用云負(fù)載中普遍存在的相似任務(wù)[11-12]代替?zhèn)鹘y(tǒng)的測(cè)試程序，通過相似任務(wù)保證評(píng)估結(jié)果準(zhǔn)確性的同時(shí)避免了執(zhí)行測(cè)試程序的資源代價(jià)；通過比較相似任務(wù)在不同計(jì)算資源上的執(zhí)行情況，在運(yùn)行時(shí)獲得具有時(shí)效性的計(jì)算資源剩余能力評(píng)估結(jié)果；克服了傳統(tǒng)評(píng)估方法的缺點(diǎn)，可為云平臺(tái)和算法的優(yōu)化提供支持.本文的主要貢獻(xiàn)有3個(gè)方面：

1) 基于相似任務(wù)建立運(yùn)行時(shí)云計(jì)算資源剩余能力評(píng)估模型，依據(jù)相似任務(wù)在不同計(jì)算資源上的執(zhí)行情況量化計(jì)算資源運(yùn)行時(shí)剩余能力.

2) 基于評(píng)估模型針對(duì)CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)4種資源提出了分類評(píng)估方法RCE，并實(shí)現(xiàn)了與平臺(tái)無關(guān)的評(píng)估服務(wù).

3) 設(shè)計(jì)了基于RCE的任務(wù)資源需求推測(cè)、資源分配、負(fù)載均衡、異常識(shí)別等算法，并在Yarn平臺(tái)中實(shí)現(xiàn)算法以解決云資源管理平臺(tái)中的問題，優(yōu)化云平臺(tái)性能.

測(cè)試結(jié)果顯示，RCE的評(píng)估結(jié)果有效且及時(shí)反映出計(jì)算資源能力變化，基于RCE評(píng)估結(jié)果的算法有效解決了資源供給與需求的匹配問題，提高了云平臺(tái)資源利用率，降低了負(fù)載完成時(shí)間.RCE為平臺(tái)及算法的優(yōu)化提供了良好的支持.

1 相關(guān)工作

近年來很多研究[3,5-7]分析了國內(nèi)外公司的日志文件，指出現(xiàn)代云計(jì)算中心及負(fù)載普遍存在規(guī)模及異構(gòu)性的挑戰(zhàn).異構(gòu)性加劇了資源品質(zhì)的差異性，從而使云計(jì)算中心資源供給與需求間的不匹配問題更加突出.資源供給與需求的不匹配可能造成計(jì)算資源被浪費(fèi)，也可能造成負(fù)載爭搶資源出現(xiàn)局部資源瓶頸，導(dǎo)致云計(jì)算中心性能大幅下降.

Hadoop[1]分布式平臺(tái)實(shí)現(xiàn)了MapReduce計(jì)算框架，可以在商用集群上提供分布式并行計(jì)算.Yarn[2]資源管理平臺(tái)從Hadoop延續(xù)而來，它采用雙層調(diào)度模型解耦了資源管理與任務(wù)調(diào)度，以支持多樣性負(fù)載.Mesos[13]采用與Yarn類似的雙層調(diào)度模型并支持多種計(jì)算模型.國內(nèi)外眾多公司均使用Hadoop，Yarn，Mesos等構(gòu)建云計(jì)算平臺(tái)[14-15]，但是上述開源云資源管理平臺(tái)均存在資源供給與需求的匹配問題.

Corona[16]平臺(tái)使用消息推送機(jī)制提高了平臺(tái)可擴(kuò)展性同時(shí)降低了MapReduce作業(yè)延遲.Fuxi[17]具有很強(qiáng)的可擴(kuò)展性和容錯(cuò)性，被用于管理Alibaba公司并發(fā)任務(wù)數(shù)以萬計(jì)的大型云平臺(tái).Borg[18]是一個(gè)在Google公司使用超過10年的資源管理系統(tǒng)，可以管理上萬節(jié)點(diǎn)組成的大型云平臺(tái).Omega[19]是Google公司的新一代資源管理系統(tǒng)，通過共享狀態(tài)和樂觀鎖極大地提高了資源分配并發(fā)度，實(shí)現(xiàn)了對(duì)大規(guī)模云平臺(tái)的管理.上述工業(yè)界云計(jì)算資源管理平臺(tái)中同樣存在著資源供給與需求的匹配問題，該問題存在的根本原因是目前的資源管理平臺(tái)不了解運(yùn)行時(shí)計(jì)算資源剩余能力和負(fù)載的資源需求.

資源供給與需求的不匹配直接導(dǎo)致個(gè)別任務(wù)執(zhí)行緩慢，最終拖慢整個(gè)作業(yè)的完成時(shí)間[20].LATE[21]通過計(jì)算任務(wù)剩余執(zhí)行時(shí)間判斷識(shí)別落后任務(wù)并啟動(dòng)冗余執(zhí)行，防止個(gè)別任務(wù)拖慢作業(yè)完成.Mantri[4]分析實(shí)時(shí)進(jìn)度報(bào)告找出落后任務(wù)，并采用重新啟動(dòng)任務(wù)、網(wǎng)絡(luò)感知放置等措施減輕落后任務(wù)的影響.LATE和Mantri等算法可以緩解由資源供給與需求不匹配造成的影響，但是不能預(yù)防執(zhí)行緩慢任務(wù)的出現(xiàn)，更不能解決資源供給與需求的匹配問題.

在云平臺(tái)執(zhí)行負(fù)載期間實(shí)時(shí)評(píng)估負(fù)載的資源需求和計(jì)算資源剩余能力是解決上述問題的一種有效方法.針對(duì)云計(jì)算資源能力評(píng)估研究的主要思路分為2種：

1) 文獻(xiàn)[8]，它基于CloudSuite，HiBench，BenchClouds，TPC-W等基準(zhǔn)測(cè)試結(jié)果建立性能評(píng)估模型，對(duì)云計(jì)算平臺(tái)效率、彈性、QoS等進(jìn)行評(píng)估.這種方式并不能應(yīng)用在運(yùn)行時(shí)資源能力評(píng)估中，原因在于在運(yùn)行時(shí)引入額外測(cè)試程序的性能代價(jià)太大，且通過分析測(cè)試程序運(yùn)行結(jié)果得出的評(píng)估結(jié)果不具有時(shí)效性.

2) 文獻(xiàn)[9-10]，它們針對(duì)云計(jì)算平臺(tái)的性能指標(biāo)建立基于隨機(jī)回報(bào)Petri網(wǎng)、連續(xù)時(shí)間馬爾可夫鏈等的評(píng)估模型.由于這種方式無法全面考慮所有影響因素、不使用測(cè)試程序，因此其評(píng)估結(jié)果并不準(zhǔn)確.

已有評(píng)估研究的問題在于不使用測(cè)試程序得不到準(zhǔn)確結(jié)果，而使用測(cè)試程序會(huì)消耗資源，影響負(fù)載執(zhí)行.本文評(píng)估解決了這個(gè)問題，它利用云計(jì)算負(fù)載中相似任務(wù)的特性，采用相似任務(wù)代替?zhèn)鹘y(tǒng)評(píng)估方法中使用的測(cè)試程序，并綜合相似任務(wù)運(yùn)行時(shí)信息、計(jì)算資源理論性能及基準(zhǔn)測(cè)試信息等建立了運(yùn)行時(shí)計(jì)算資源剩余能力評(píng)估模型.因此本文的評(píng)估具有的優(yōu)勢(shì)包括：運(yùn)行時(shí)不引入負(fù)載無關(guān)的測(cè)試程序，性能代價(jià)小；使用負(fù)載中相似任務(wù)代替測(cè)試程序，保證結(jié)果準(zhǔn)確性；運(yùn)行時(shí)實(shí)時(shí)評(píng)估，結(jié)果時(shí)效性高.

Apollo[11]是一個(gè)分布式協(xié)作的調(diào)度框架，它通過整合、共享集群的資源可用性信息實(shí)現(xiàn)多調(diào)度器分布式調(diào)度，解決了調(diào)度的擴(kuò)展性問題.Apollo中的資源可用性信息通過預(yù)測(cè)、整合各任務(wù)的完成時(shí)間得出，而其對(duì)任務(wù)完成時(shí)間的預(yù)測(cè)是通過分析相似任務(wù)實(shí)現(xiàn)的，因此本文在資源剩余能力評(píng)估模型以及基于RCE的任務(wù)資源需求推測(cè)算法中均利用了與Apollo相似的原理.但是本文在評(píng)估中進(jìn)一步定義了相似任務(wù)，同時(shí)在評(píng)估中引入了其他因素，而本文的需求推測(cè)算法在推測(cè)過程中考慮了任務(wù)使用資源的差異性，這是Apollo中沒有考慮到的.Google公司提出的CPI2[12]將相似原理應(yīng)用到異常任務(wù)識(shí)別中，但并未涉及到計(jì)算資源評(píng)估方面.

RCE評(píng)估方法可以應(yīng)用到Hadoop，Yarn，Mesos等開源云計(jì)算平臺(tái)中，為平臺(tái)及算法優(yōu)化提供有力支持.例如，文獻(xiàn)[22]提出一種適用于異構(gòu)集群的調(diào)度算法和基于負(fù)載的混合調(diào)度策略，基于RCE評(píng)估、分析異構(gòu)集群可以更好地獲取負(fù)載狀態(tài)，取得更好的平均完成時(shí)間；文獻(xiàn)[23]根據(jù)節(jié)點(diǎn)性能、任務(wù)特征等信息進(jìn)行負(fù)載均衡，但是在判斷節(jié)點(diǎn)性能時(shí)只依據(jù)硬件配置信息且在任務(wù)特征方面只考慮CPU和IO這2種類型，使用RCE評(píng)估節(jié)點(diǎn)性能、判斷任務(wù)特征有利于提升方法效率.

2 基于相似任務(wù)的計(jì)算資源剩余能力評(píng)估模型

云計(jì)算負(fù)載中普遍存在的執(zhí)行邏輯相同的任務(wù)具有相同的資源使用行為.本文在執(zhí)行邏輯相同任務(wù)上進(jìn)一步定義了相似任務(wù)，并采用相似任務(wù)代替測(cè)試程序量化計(jì)算資源剩余量以及品質(zhì).在此基礎(chǔ)上，綜合其他信息建立計(jì)算資源剩余能力的評(píng)估模型.

定義1. 計(jì)算資源剩余能力Cr R.假設(shè)計(jì)算資源R在運(yùn)行時(shí)的空閑資源量為μ、資源品質(zhì)(單位計(jì)算資源擁有的計(jì)算性能)為θ，則R剩余能力可由二元組(μ,θ)表示，且其數(shù)值可以按Cr R=μ×θ計(jì)算.

定義2. 相似任務(wù).假設(shè)任務(wù)執(zhí)行邏輯為L，任務(wù)所處階段為S，處理數(shù)據(jù)量為D，如果對(duì)于任務(wù)i和j存在關(guān)系Li=Lj∧Si=Sj∧Di=Dj，則任務(wù)i和j互為相似任務(wù).

定義2約束了相似任務(wù)的3個(gè)方面：執(zhí)行邏輯、所處階段以及處理數(shù)據(jù)量.只有在3個(gè)方面均相同的任務(wù)才互為相似任務(wù).這樣約束的原因在于，任務(wù)的執(zhí)行邏輯以及所處的階段均能影響資源的使用行為，而處理數(shù)據(jù)量可能影響某些資源的使用量以及任務(wù)階段的劃分.

（1）

定理1推導(dǎo)如下：

任務(wù)的性能指標(biāo)P與任務(wù)邏輯L和計(jì)算資源品質(zhì)θ間存在映射關(guān)系：

f:L,θ→P,ρP,θgt;0,ρP,Llt;0.

（2）

對(duì)于相似任務(wù)i和j而言，執(zhí)行邏輯相同，即Li=Lj，因此有：

θ ∝P??Pilt;Pj，?θilt;θj.

（3）

因此任務(wù)與其相似任務(wù)性能指標(biāo)的比較關(guān)系可以反映出任務(wù)占用資源的品質(zhì)，云負(fù)載相似任務(wù)可以代替測(cè)試程序用于評(píng)估計(jì)算資源剩余能力.

評(píng)估模型依據(jù)定理1評(píng)估資源剩余能力Cr R，并綜合計(jì)算資源的理論能力Cs R以及實(shí)測(cè)峰值Sj，使評(píng)估結(jié)果CR更加準(zhǔn)確.評(píng)估模型如式(4)，其計(jì)算結(jié)果數(shù)值越大表示被評(píng)估的計(jì)算資源剩余能力越大.

其中，Cr R為計(jì)算資源剩余能力；Mr R為同類計(jì)算資源運(yùn)行時(shí)剩余能力的中位數(shù)；TEST為計(jì)算資源測(cè)試項(xiàng)集合；Sj為測(cè)試項(xiàng)j的實(shí)測(cè)峰值；Ej為測(cè)試項(xiàng)j的期望結(jié)果；Wj為測(cè)試項(xiàng)j的權(quán)重；Ms R為同類計(jì)算資源理論能力的中位數(shù)；α，β，η為權(quán)重參數(shù)，滿足α+β+η=1.

基于相似任務(wù)的評(píng)估模型的創(chuàng)新在于使用云計(jì)算負(fù)載代替了傳統(tǒng)測(cè)試程序，它在3個(gè)方面具有優(yōu)點(diǎn)：

1) 準(zhǔn)確度.該模型考慮計(jì)算資源上任務(wù)執(zhí)行情況、理論能力、測(cè)試結(jié)果等方面，評(píng)估結(jié)果準(zhǔn)確度高.

2) 代價(jià)低.該模型在運(yùn)行時(shí)只需要執(zhí)行負(fù)載，評(píng)估運(yùn)行時(shí)代價(jià)很低.

3) 時(shí)效性.評(píng)估過程與負(fù)載執(zhí)行同時(shí)進(jìn)行，評(píng)估結(jié)果時(shí)效性高.

3 運(yùn)行時(shí)計(jì)算資源剩余能力評(píng)估方法RCE

3.1RCE概述

同一任務(wù)對(duì)不同計(jì)算資源的使用行為不同，各種計(jì)算資源信息間不具有比較性.因此，RCE方法按資源類型分類評(píng)估，目前分CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)4類進(jìn)行.圖1所示為RCE方法示意圖.

圖1中Master為云平臺(tái)管理節(jié)點(diǎn)；Worker為云平臺(tái)工作節(jié)點(diǎn)，其內(nèi)小矩形表示計(jì)算資源；陰影代表被占用.工作節(jié)點(diǎn)上運(yùn)行著資源特性各異的各種任務(wù)，任務(wù)A與A′互為相似任務(wù).RCE執(zhí)行流程如下：

1) 當(dāng)服務(wù)器作為工作節(jié)點(diǎn)首次加入云平臺(tái)時(shí)，RCE收集服務(wù)器計(jì)算資源理論能力并執(zhí)行各種基準(zhǔn)測(cè)試采集測(cè)試結(jié)果.

2) 云平臺(tái)工作節(jié)點(diǎn)執(zhí)行云負(fù)載時(shí)，RCE采集任務(wù)及資源的運(yùn)行時(shí)信息.

3) RCE分類存儲(chǔ)各種運(yùn)行時(shí)信息，識(shí)別負(fù)載中相似任務(wù)，并按資源類型分類評(píng)估計(jì)算資源.

4) 云平臺(tái)管理服務(wù)Master通過RCE接口獲取評(píng)估結(jié)果并應(yīng)用在各種算法中，優(yōu)化云平臺(tái)性能.

Fig. 1 Schematic diagram of RCE圖1 RCE示意圖

3.2相似任務(wù)識(shí)別

識(shí)別云計(jì)算負(fù)載中的相似任務(wù)是資源剩余能力評(píng)估的基礎(chǔ)，RCE依照任務(wù)執(zhí)行邏輯、處理數(shù)據(jù)大小、所處執(zhí)行階段識(shí)別相似任務(wù)，具體步驟如下：

1) 將執(zhí)行邏輯相同且處理數(shù)據(jù)大小相等的任務(wù)作為相似任務(wù)的備選集合；

2) 根據(jù)運(yùn)行時(shí)信息分別迭代計(jì)算任務(wù)各種資源每個(gè)進(jìn)度的資源使用情況；

3) 根據(jù)任務(wù)資源使用信息劃分任務(wù)執(zhí)行階段；

4) 按照任務(wù)執(zhí)行階段將備選集合劃分成多個(gè)子集，執(zhí)行階段相同的任務(wù)在相同子集中，子集內(nèi)的任務(wù)互為相似任務(wù).

λ=e×λ′+(1-e)×γ.

（5）

式(5)為任務(wù)資源使用情況的迭代計(jì)算公式.其中，λ為任務(wù)在某進(jìn)度時(shí)的資源使用量，λ′為更新前任務(wù)資源使用量，γ為更新的任務(wù)資源使用信息.當(dāng)λ′=0時(shí)，采用前3次信息的平均值作為λ的初始值.

利用任務(wù)資源使用信息劃分執(zhí)行階段時(shí)，依據(jù)不同資源劃分出的任務(wù)階段可能不同.RCE依據(jù)CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)資源得出4種執(zhí)行階段劃分，依據(jù)某種資源劃分任務(wù)執(zhí)行階段的流程圖如圖2所示.

Fig. 2 Flow chart of task stage recognition圖2 任務(wù)階段劃分流程圖

圖2中Pk，Ps，Pe分別表示任務(wù)進(jìn)度、階段起始進(jìn)度、階段終止進(jìn)度；λmax，λmin分別表示任務(wù)在階段內(nèi)最大、最小資源使用量.初始時(shí)，各種變量均為0；然后Pe隨Pk增加，并更新[Ps,Pe]區(qū)間內(nèi)的最大、最小資源使用量；當(dāng)[Ps,Pe]區(qū)間大于5%并且區(qū)間內(nèi)最大最小資源使用量之差大于總資源量Ra%時(shí)，將[Ps,Pe]劃分為1個(gè)任務(wù)階段，直至任務(wù)劃分完成.

3.3計(jì)算資源分類評(píng)估

3.3.1 CPU資源評(píng)估

由于CPU架構(gòu)設(shè)計(jì)的差異，相同任務(wù)使用不同架構(gòu)CPU得到的性能指標(biāo)可能大不相同.因此，RCE按照CPU型號(hào)系列分類評(píng)估CPU剩余能力.CPU資源運(yùn)行時(shí)剩余能力Crc計(jì)算具體如式(6)所示，其中Cidle為CPU空閑時(shí)間百分比，Cload為平均隊(duì)列長度，TASK為CPU上執(zhí)行中任務(wù)集合，It為任務(wù)t平均每個(gè)時(shí)鐘周期完成的指令數(shù)，Mt為任務(wù)t的cache失效率，St為任務(wù)t的上下文切換頻率，MIPC t，Mmt，Mst分別為任務(wù)t的相似任務(wù)在同型號(hào)系列CPU上平均每個(gè)時(shí)鐘周期完成的指令數(shù)、cache失效率、上下文切換頻率的中位數(shù)，Ct為任務(wù)t的CPU時(shí)間占用率,card(TASK)為TASK集合內(nèi)任務(wù)數(shù)量.

（6）

在分析CPU理論性能時(shí)，RCE主要考慮計(jì)算核心數(shù)、主頻、緩存等指標(biāo).由于層次越小的緩存對(duì)CPU性能影響越大，因此分析時(shí)賦予層次低的緩存更大的權(quán)重.

（7）

其中,Ch為計(jì)算核心數(shù)，Sp為主頻，Li為i層的緩存大小，W為小于1的權(quán)值，設(shè)置t=3.

RCE采用Whetstone[24]作為CPU的基準(zhǔn)測(cè)試，F(xiàn)ortran版的Whetstone是第1個(gè)工業(yè)標(biāo)準(zhǔn)上的通用CPU綜合測(cè)試.相比常用于超級(jí)計(jì)算機(jī)科學(xué)計(jì)算的LINPACK[25]測(cè)試，Whetstone含有浮點(diǎn)計(jì)算、過程調(diào)用、條件跳轉(zhuǎn)、數(shù)學(xué)函數(shù)等多個(gè)測(cè)試項(xiàng)，更加適合測(cè)試云計(jì)算服務(wù)器CPU的綜合能力.

3.3.2 內(nèi)存資源評(píng)估

在內(nèi)存資源評(píng)估中，RCE以缺頁頻率的倒數(shù)作為衡量內(nèi)存資源品質(zhì)的指標(biāo)，并按照式(8)計(jì)算內(nèi)存資源運(yùn)行時(shí)剩余能力值Crm.

（8）

RCE使用內(nèi)存資源的理論帶寬值作為內(nèi)存理論性能分析結(jié)果，并采用STREAM[26]作為內(nèi)存資源基準(zhǔn)測(cè)試，測(cè)試中啟動(dòng)與CPU計(jì)算核心相等的線程并行操作內(nèi)存以衡量其可持續(xù)的帶寬.

3.3.3 磁盤資源評(píng)估

在磁盤資源評(píng)估中，RCE以磁盤上IO請(qǐng)求排隊(duì)及執(zhí)行時(shí)間等指標(biāo)衡量磁盤資源品質(zhì)，而以未利用的磁盤帶寬和傳輸次數(shù)等指標(biāo)考察可用資源量，磁盤資源剩余能力Crs計(jì)算為

（9）

RCE使用磁盤轉(zhuǎn)速、磁頭數(shù)、緩存大小的乘積作為磁盤理論性能的分析結(jié)果.磁盤基準(zhǔn)測(cè)試中分別讀寫不同大小的文件及磁盤緩存，并記錄磁盤峰值帶寬及傳輸次數(shù)作為結(jié)果，測(cè)試數(shù)據(jù)范圍為16 KB～8 GB，單個(gè)測(cè)試項(xiàng)的讀寫次數(shù)從5～500次不等.

3.3.4 網(wǎng)絡(luò)資源評(píng)估

網(wǎng)絡(luò)資源評(píng)估針對(duì)帶寬資源進(jìn)行，帶寬品質(zhì)均相等，評(píng)估時(shí)只需考慮空閑資源量.RCE使用未利用的網(wǎng)絡(luò)帶寬作為網(wǎng)絡(luò)空閑資源量，網(wǎng)絡(luò)資源運(yùn)行時(shí)剩余能力Crn在數(shù)值上等于實(shí)測(cè)帶寬峰值Pnio與當(dāng)前被占用帶寬Cnio的差,即:

Crn=Pnio-Cnio.

（10）

RCE使用網(wǎng)絡(luò)設(shè)備標(biāo)識(shí)的理論帶寬作為理論性能.在網(wǎng)絡(luò)資源基準(zhǔn)測(cè)試中，RCE使用多臺(tái)服務(wù)器協(xié)同測(cè)試，模擬實(shí)際網(wǎng)絡(luò)使用并記錄峰值帶寬.測(cè)試中傳輸數(shù)據(jù)按大小分為3類，范圍涵蓋16 KB～2 GB.

3.3.5 評(píng)估值計(jì)算

RCE將各計(jì)算資源評(píng)估因素代入評(píng)估模型分別計(jì)算最終評(píng)估結(jié)果.由于不同計(jì)算資源的特性具有差異，RCE針對(duì)CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)資源的特性分別調(diào)整評(píng)估模型參數(shù)使最終評(píng)估結(jié)果準(zhǔn)確.評(píng)估模型中的α，β，η參數(shù)分別代表計(jì)算資源運(yùn)行時(shí)剩余能力、基準(zhǔn)測(cè)試性能峰值、理論性能在計(jì)算資源剩余能力評(píng)估結(jié)果中所占的權(quán)重.對(duì)于CPU資源，RCE使用默認(rèn)參數(shù)0.8，0.1，0.1分別作為α，β，η的值；對(duì)于內(nèi)存資源，RCE在默認(rèn)參數(shù)的基礎(chǔ)上提高了α而降低了β，η的值；對(duì)于磁盤和網(wǎng)絡(luò)資源，RCE在默認(rèn)參數(shù)的基礎(chǔ)上提高了β而降低了η，這是由于資源的理論性能達(dá)不到，參考意義不大.

3.4RCE實(shí)現(xiàn)

RCE在實(shí)現(xiàn)時(shí)設(shè)計(jì)為1個(gè)評(píng)估服務(wù)和若干信息采集服務(wù)組成的主從式架構(gòu)，其中采集服務(wù)負(fù)責(zé)采集評(píng)估所需的各種信息并匯報(bào)給評(píng)估服務(wù)，評(píng)估服務(wù)負(fù)責(zé)分類存儲(chǔ)各種信息、識(shí)別相似任務(wù)并使用評(píng)估模型量化運(yùn)行時(shí)計(jì)算資源剩余能力評(píng)估值.評(píng)估服務(wù)可以與云平臺(tái)管理服務(wù)分離部署，這使得服務(wù)不互相干擾，不影響云平臺(tái)可擴(kuò)展性.RCE的實(shí)現(xiàn)與具體云平臺(tái)無關(guān)，其評(píng)估服務(wù)中設(shè)計(jì)有獲取各種評(píng)估因素以及結(jié)果的接口，可供其他服務(wù)獲取使用.因此，RCE可以靈活接入各種云平臺(tái)提供評(píng)估服務(wù).

RCE在評(píng)估過程中多次用到了數(shù)據(jù)的中位數(shù).在具體實(shí)現(xiàn)中，我們以平衡二叉樹存儲(chǔ)信息，并使用二叉樹根節(jié)點(diǎn)數(shù)據(jù)作為近似中位數(shù)在計(jì)算中使用，以提高中位數(shù)的獲取效率.

4 基于RCE的算法優(yōu)化

在負(fù)載運(yùn)行時(shí)得到具有時(shí)效性的計(jì)算資源剩余能力結(jié)果為匹配資源供給與需求打下基礎(chǔ)，同時(shí)為優(yōu)化云平臺(tái)各種算法提供了新思路和支持.本節(jié)基于RCE設(shè)計(jì)、優(yōu)化了任務(wù)需求推測(cè)、資源分配、負(fù)載均衡等算法并在Yarn平臺(tái)中實(shí)現(xiàn)了這些算法：1)解決云平臺(tái)中資源供給與需求的問題、提高云平臺(tái)性能；2)演示計(jì)算資源剩余能力評(píng)估結(jié)果的應(yīng)用，證明評(píng)估結(jié)果對(duì)算法優(yōu)化的支持效果.

4.1任務(wù)資源需求推測(cè)算法

本文依據(jù)相似任務(wù)的資源使用情況，考慮計(jì)算資源的品質(zhì)因素，推測(cè)任務(wù)對(duì)CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等資源的需求，具體如算法1所示：

算法1. 任務(wù)資源需求推測(cè)算法.

輸入：任務(wù)T、相似任務(wù)集合ST；

輸出：任務(wù)T的資源需求.

①forT中每個(gè)階段do

② Rc,Rm,Rs,Rn,N,Ttime,Ntime←0;

③ M←Median(θ,ST)；

④forSinSTdo

⑤ Rc←Rc+Sc×max(θM ,1);

⑥ Rm←Rm+Sm;

⑦ N←N+1;

⑧ Rs←Rs+Ss;

⑨ Tt←Tt+St;

⑩ Snr?Ssr?continue:(Rn←Rn+Sn,

Nt←Nt+St);

資源需求推測(cè)算法推測(cè)任務(wù)每個(gè)階段的資源需求，首先初始化變量并取得與任務(wù)T使用相同型號(hào)系列CPU的相似任務(wù)集合ST中任務(wù)使用的CPU資源品質(zhì)的中位數(shù)M.在資源總量疊加過程中，算法使用任務(wù)CPU資源品質(zhì)θ與M的商衡量當(dāng)前CPU資源的品質(zhì)，任務(wù)S占用的CPU時(shí)間Sc與max(θM,1)的乘積被疊加進(jìn)CPU的總量Rc中.當(dāng)θMlt;1時(shí)，即任務(wù)CPU資源品質(zhì)較差時(shí)，max(θM,1)按1計(jì)算，以防止CPU資源品質(zhì)突然變差造成需求推測(cè)變小.之后算法疊加相似任務(wù)內(nèi)存使用量Rm并記錄任務(wù)數(shù).由于磁盤和網(wǎng)絡(luò)資源只疊加傳輸量，因此并不考慮資源能力因素.磁盤傳輸量Rs分讀和寫分別統(tǒng)計(jì)，并記錄任務(wù)執(zhí)行的總時(shí)間Tt.在計(jì)算相似任務(wù)網(wǎng)絡(luò)傳輸量及傳輸時(shí)間時(shí)，算法會(huì)根據(jù)網(wǎng)絡(luò)接收數(shù)據(jù)量Snr和磁盤讀取數(shù)據(jù)量Ssr過濾掉具有數(shù)據(jù)本地性的任務(wù)，以保證推測(cè)準(zhǔn)確性.最后算法計(jì)算相似任務(wù)各種資源的平均使用量或平均傳輸速度作為任務(wù)資源需求的推測(cè)值.

4.2資源分配算法

基于RCE的資源分配算法依據(jù)計(jì)算資源剩余能力評(píng)估結(jié)果和需求推測(cè)值提高資源供給與需求的匹配程度，一方面充分滿足任務(wù)的資源需求，另一方面減少資源碎片、提高計(jì)算資源利用率.資源分配算法如算法2所示：

算法2. 資源分配算法.

輸入：服務(wù)器集合Se、任務(wù)資源需求Tx.

①fors∈Sedo

②ifCidle×min(θM,1)gt;Tcthen

③ifCm-M×min(max(1-Crm,0)+Th0, Th1)gt;Tmthen*檢查內(nèi)存資源*

④ifCsgt;TsandCb- Ths× BsCstgt;TbandTeTwgt;Thwthen*檢查磁盤IO資源*

⑤ifCn-Thn×BnCntgt;Tnthen

⑥ AllocResoucre(s, Tx);

⑦ Ras←Ras{Tx};*更新資源量*

⑧endif

⑨endif

⑩endif

算法2遍歷云平臺(tái)服務(wù)器集合Se查找合適任務(wù)執(zhí)行的資源.算法首先檢查服務(wù)器CPU資源是否滿足任務(wù)需求，Cidle為CPU空閑百分比，θ為服務(wù)器CPU資源品質(zhì)，M為相同型號(hào)系列CPU資源品質(zhì)的中位數(shù)，Tc為任務(wù)對(duì)CPU資源的需求量.由于任務(wù)對(duì)內(nèi)存帶寬的使用不受控制，因此在內(nèi)存方面只考慮內(nèi)存可用空間Cm在保留一定比例后是否滿足任務(wù)的使用需求Tm，M為總內(nèi)存大小，Crm為內(nèi)存資源當(dāng)前剩余能力.min(max(1-Crm,0)+Th0,Th1)為保留比例，該數(shù)值根據(jù)內(nèi)存資源剩余能力在Th0和Th1之間調(diào)節(jié)，剩余能力升高則預(yù)留減少，反之則預(yù)留增加.之后算法2檢查磁盤容量、帶寬等資源，當(dāng)磁盤可用空間Cs滿足任務(wù)磁盤空間需求Ts、磁盤可用帶寬Cb在預(yù)留一定比例之后滿足任務(wù)磁盤帶寬需求Tb并且磁盤當(dāng)前狀態(tài)良好時(shí)，則通過磁盤資源檢查.Bs為磁盤實(shí)測(cè)帶寬峰值，Cst為磁盤資源剩余能力評(píng)估結(jié)果，Te為磁盤IO請(qǐng)求的平均執(zhí)行時(shí)間，Tw為磁盤IO請(qǐng)求平均等待時(shí)間.最后，算法檢查可用網(wǎng)絡(luò)帶寬Cn在保留網(wǎng)絡(luò)實(shí)測(cè)帶寬Bn的一定比例之后是否滿足任務(wù)的網(wǎng)絡(luò)帶寬需求Tn，其中Thn為預(yù)留閾值，Cnt為網(wǎng)絡(luò)資源評(píng)估值.ThnCnt為保留帶寬比例，該比例與網(wǎng)絡(luò)資源評(píng)估值成反比，即性能越好的網(wǎng)絡(luò)資源的保留帶寬越小，反之保留帶寬增加以避免網(wǎng)絡(luò)擁塞.通過所有資源檢查之后，分配算法向任務(wù)分配計(jì)算資源，并更新服務(wù)器可用計(jì)算資源量Ras.

4.3負(fù)載均衡算法

云計(jì)算平臺(tái)負(fù)載是否均勻分布是衡量平臺(tái)可用性的重要指標(biāo)之一,基于RCE的負(fù)載均衡算法依據(jù)RCE評(píng)估結(jié)果和任務(wù)資源特性篩選被分配服務(wù)器，使負(fù)載在各服務(wù)器上均勻分布，實(shí)現(xiàn)有效的負(fù)載均衡.

（11）

定義3. 任務(wù)資源需求度. 假設(shè)任務(wù)i對(duì)資源R的需求量為tiR，則任務(wù)j對(duì)資源R的需求度RjR如式(11)計(jì)算，Ta為所有任務(wù)集合，card(Ta)為Ta中元素個(gè)數(shù).

定義4. 任務(wù)主資源.任務(wù)資源需求度最大的資源稱為任務(wù)的主資源，任務(wù)主資源在一定程度上可以刻畫任務(wù)的資源特性.

負(fù)載均衡算法如算法3所示：

算法3. 負(fù)載均衡算法.

輸入：任務(wù)資源需求Tx、任務(wù)平均資源需求Ax、資源類型X.

① M←0;

②forx∈Xdo

③ Rx←TxAx;

④ Rm←Mlt;Rx?(M←Rx,x): Rm;

⑤endfor

⑥ T0←systemtime;

⑦fors∈Sedo

⑧ Tc←systemtime;

⑨ifTc-T0lt;ThTthen*檢查時(shí)延*

⑩ Check(Crm)?Alloc(Tx,s)：;

4.4異常識(shí)別算法

云平臺(tái)中服務(wù)器資源異常輕則影響任務(wù)執(zhí)行，重則影響整個(gè)平臺(tái)運(yùn)轉(zhuǎn).基于RCE的異常識(shí)別算法是通過分析RCE的評(píng)估指標(biāo)來識(shí)別異常，并采取報(bào)告異常原因、停止分配等相關(guān)措施避免異常造成嚴(yán)重影響.異常識(shí)別算法如算法4所示：

算法4. 異常識(shí)別算法.

輸入：服務(wù)器集合Se、疑似集合G、異常集合H；

輸出：異常集合H.

①forC∈Sedo

②ifCpgt;Thpthen

⑥continue;

⑦endif

⑧ T0←(CIPClt;ThIPCandCidlelt;Thidle)?systemtime:0;

⑨ T1←(Cpfgt;ThpfandCfreelt;Thfree)?systemtime:0;

⑩ T2←(Cwgt;ThworClgt;Thl)?system

time:0;

算法4使用任務(wù)進(jìn)度指標(biāo)Cp進(jìn)行初篩,Cp由服務(wù)器上任務(wù)與其相似任務(wù)的每秒進(jìn)度值計(jì)算，當(dāng)Cp大于集合S中各服務(wù)器該指標(biāo)的10分位值Thp時(shí)，則認(rèn)為服務(wù)器C不存在異常;如果服務(wù)器上可能存在異常，則開始分析服務(wù)器計(jì)算資源.CIPC由服務(wù)器上各任務(wù)與其相似任務(wù)平均每個(gè)時(shí)鐘周期完成的指令數(shù)的比值，再與其資源占用百分比相乘求和后再除以總資源占用率計(jì)算.當(dāng)服務(wù)器任務(wù)指標(biāo)CIPC小于集合S中相同型號(hào)系列CPU相應(yīng)指標(biāo)的10分位值ThIPC并且CPU空閑百分比Cidle小于Thidle時(shí)，即CPU大部分時(shí)間被占用但是性能很差，則加蓋時(shí)間戳T0.Cpf與CIPC計(jì)算過程相似，其指示服務(wù)內(nèi)存平均缺頁頻率情況.當(dāng)服務(wù)器Cpf指標(biāo)大于各服務(wù)器相應(yīng)指標(biāo)的10分位值Thpf并且內(nèi)存空閑百分比Cfreelt;Thfree時(shí)，則加蓋時(shí)間戳T1.當(dāng)磁盤IO請(qǐng)求平均等待時(shí)間Cw大于各服務(wù)器IO請(qǐng)求平均等待時(shí)間的95分位值Thw或者磁盤IO隊(duì)列長度Cl大于各服務(wù)器IO隊(duì)列長度的95分位值Thl時(shí)，則加蓋時(shí)間戳T2.如果3個(gè)時(shí)間戳均為0，則將服務(wù)器C從疑似異常集合G以及異常集合H中除去并進(jìn)入下一次循環(huán)，否則將C加入疑似異常集合G中.當(dāng)服務(wù)器由于某種原因在疑似異常集合中持續(xù)存在超過Tht時(shí)，則將服務(wù)器加入異常集合并記錄異常信息.當(dāng)服務(wù)器處于異?；蛞伤飘惓＜现袝r(shí)，云平臺(tái)將暫停分配該服務(wù)器資源，避免異常造成影響.

當(dāng)沒有足夠數(shù)據(jù)可供分析時(shí),閾值不準(zhǔn)確會(huì)造成算法判斷失誤率大幅升高,此時(shí)算法會(huì)暫停識(shí)別工作等待足夠數(shù)據(jù)出現(xiàn).相比傳統(tǒng)的異常識(shí)別方法，基于RCE的異常識(shí)別算法在識(shí)別速度和精度上均有提升，它不僅可以精確報(bào)告出現(xiàn)異常的計(jì)算資源，而且可以在異常出現(xiàn)時(shí)停止分配服務(wù)器資源，防止異常造成的影響擴(kuò)大，更加適合應(yīng)用在實(shí)際環(huán)境中.

4.5緩慢任務(wù)發(fā)現(xiàn)算法

在云計(jì)算中，作業(yè)中全部任務(wù)完成才標(biāo)志作業(yè)完成，因此避免個(gè)別任務(wù)拖慢整個(gè)作業(yè)十分重要.基于RCE的緩慢任務(wù)發(fā)現(xiàn)算法依據(jù)RCE評(píng)估結(jié)果及運(yùn)行時(shí)信息精確識(shí)別緩慢任務(wù)并在必要時(shí)啟動(dòng)冗余任務(wù)，從預(yù)防到補(bǔ)救全方位避免作業(yè)完成時(shí)間被拖長.緩慢任務(wù)發(fā)現(xiàn)算法如算法5所示：

算法5. 緩慢任務(wù)發(fā)現(xiàn)算法.

輸入：任務(wù)集合Sta、疑似集合G、緩慢集合H；

輸出：

①forT∈Stado

② T0←(Tslt;ThsandTIPClt;ThIPC)?

系統(tǒng)時(shí)間：0;

③ G←(T0==0)?(H←H{T},G{T}):G∪{T};

④ T1←系統(tǒng)時(shí)間;

⑤if(T1-T0)×T0gt;Tt×T0then

⑥ H←H∪{T};

⑦if(100%-Tp)Tsgt;(100%+Tht)×ATthen

⑧ ApplyAndRestart(T);

⑨endif

⑩endif

算法5監(jiān)測(cè)任務(wù)平均每秒鐘取得的進(jìn)度Ts以及平均每個(gè)時(shí)鐘周期完成的指令數(shù)TIPC，如果Ts和TIPC均小于相似任務(wù)相應(yīng)指標(biāo)的閾值，則記錄時(shí)間戳T0并將任務(wù)加入觀察集合G中.當(dāng)1個(gè)任務(wù)在觀察集合G中持續(xù)存在超過閾值Tt時(shí)，將任務(wù)加入執(zhí)行緩慢任務(wù)集合H并判斷是否需要啟動(dòng)冗余任務(wù).假設(shè)啟動(dòng)的冗余任務(wù)取得相似任務(wù)平均完成時(shí)間AT，如果該完成時(shí)間相對(duì)當(dāng)前已取得進(jìn)度Tp且繼續(xù)以當(dāng)前速度Ts執(zhí)行的任務(wù)有Tht的提升，則算法為任務(wù)申請(qǐng)資源并重新啟動(dòng)任務(wù).算法在申請(qǐng)冗余任務(wù)所需資源時(shí)會(huì)標(biāo)識(shí)只接受任務(wù)主資源評(píng)估值大于一定值的服務(wù)器，以保證冗余執(zhí)行快速完成.

調(diào)節(jié)算法中的閾值Tt可以在發(fā)現(xiàn)緩慢任務(wù)的耗時(shí)和準(zhǔn)確性之間做出取舍.當(dāng)閾值Tt較小時(shí)，算法5對(duì)執(zhí)行緩慢的任務(wù)十分敏感，這一方面大幅縮短了發(fā)現(xiàn)緩慢任務(wù)的耗時(shí)，另一方面將執(zhí)行稍微緩慢的任務(wù)識(shí)別為緩慢任務(wù)，在發(fā)現(xiàn)準(zhǔn)確度方面做出了一定的妥協(xié).在任務(wù)被確認(rèn)執(zhí)行緩慢之后，算法5權(quán)衡利弊決定是否啟動(dòng)冗余任務(wù)，因此并不是所有執(zhí)行緩慢任務(wù)都被冗余執(zhí)行，這很大程度上彌補(bǔ)了準(zhǔn)確度下降帶來的影響.調(diào)節(jié)閾值Tht可以決定冗余任務(wù)的啟動(dòng)條件，冗余任務(wù)占用的總資源以及任務(wù)數(shù)也可以配置，以避免過度啟動(dòng)冗余任務(wù)浪費(fèi)計(jì)算資源.

算法5發(fā)現(xiàn)緩慢任務(wù)的精確度依賴于各種閾值的準(zhǔn)確性，當(dāng)閾值不準(zhǔn)確時(shí)算法會(huì)暫停發(fā)現(xiàn)以避免發(fā)現(xiàn)效率大幅下降.當(dāng)閾值隨平臺(tái)運(yùn)行時(shí)間及負(fù)載信息的增加而趨于準(zhǔn)確之后，算法會(huì)繼續(xù)工作.

5 實(shí)驗(yàn)與結(jié)果

本節(jié)首先介紹各種測(cè)試的環(huán)境以及負(fù)載；之后測(cè)試驗(yàn)證RCE和基于RCE的各種算法，證明RCE評(píng)估的有效性、時(shí)效性、擴(kuò)展性以及RCE評(píng)估結(jié)果對(duì)算法和平臺(tái)的優(yōu)化支持.

5.1測(cè)試環(huán)境及負(fù)載介紹

本文使用國家高性能計(jì)算中心(西安)中的一個(gè)集群測(cè)試驗(yàn)證，該集群由30臺(tái)服務(wù)器組成，具體配置如表1所示.RCE方法有效性和時(shí)效性測(cè)試使用集群中3臺(tái)A類型和2臺(tái)B類型服務(wù)器，在1臺(tái)A類型服務(wù)器上部署RCE評(píng)估服務(wù)，其余4臺(tái)服務(wù)器作為計(jì)算節(jié)點(diǎn).在方法擴(kuò)展性測(cè)試中，使用集群所有服務(wù)器模擬各種規(guī)模的集群.該部分測(cè)試使用CPU、內(nèi)存、磁盤等資源特性突出的測(cè)試程序作為負(fù)載.

Table 1 Hardware Information of Cluster表1 集群硬件配置

在基于RCE的算法測(cè)試及平臺(tái)優(yōu)化測(cè)試中均使用集群所有服務(wù)器，Yarn平臺(tái)管理服務(wù)和RCE評(píng)估服務(wù)被部署在A類型服務(wù)器上，其余節(jié)點(diǎn)作為云平臺(tái)計(jì)算節(jié)點(diǎn).集群上部署Yarn 平臺(tái)并在平臺(tái)上配置MapReduce，Spark，Storm等多種計(jì)算框架.該部分測(cè)試負(fù)載由多個(gè)處理不同大小數(shù)據(jù)的作業(yè)混合組成.測(cè)試中以負(fù)載規(guī)模表示測(cè)試數(shù)據(jù)大小，負(fù)載規(guī)模1定義為使集群內(nèi)所有服務(wù)器計(jì)算核心同時(shí)執(zhí)行任務(wù)所處理的數(shù)據(jù)大小.測(cè)試負(fù)載單次處理數(shù)據(jù)最高達(dá)到300 GB，數(shù)據(jù)來源于Wikipedia、集群日志以及隨機(jī)生成等.各作業(yè)數(shù)據(jù)大小服從Facebook作業(yè)大小分布[27]，提交時(shí)間服從泊松分布.

本文分別在獨(dú)享和云2種環(huán)境下測(cè)試驗(yàn)證：在獨(dú)享環(huán)境中，整個(gè)集群只執(zhí)行測(cè)試負(fù)載；在云環(huán)境中，集群資源由Yarn平臺(tái)和科學(xué)計(jì)算等應(yīng)用共享，集群處于日常真實(shí)使用狀態(tài).

5.2RCE方法測(cè)試

5.2.1 有效性測(cè)試

由于空閑資源量從系統(tǒng)直接采集，而資源理論性能和基準(zhǔn)測(cè)試等信息不變，因此評(píng)估值的有效性主要由資源品質(zhì)值決定.測(cè)試從2方面證明RCE結(jié)果的有效性：1)檢驗(yàn)RCE評(píng)估出資源品質(zhì)值能否體現(xiàn)出真實(shí)資源品質(zhì)的變化；2)以任務(wù)平均完成時(shí)間驗(yàn)證評(píng)估出資源品質(zhì)值的有效性.如果評(píng)估出各服務(wù)器上計(jì)算資源品質(zhì)隨負(fù)載變化，且與任務(wù)完成時(shí)間比較關(guān)系一致，則說明RCE評(píng)估結(jié)果有效地反映出了資源能力.資源品質(zhì)變化測(cè)試和有效性測(cè)試均使用資源特性單一負(fù)載按計(jì)算資源類型分別進(jìn)行.由于網(wǎng)絡(luò)評(píng)估中只考慮了空閑資源量，而該值由系統(tǒng)中采集的資源使用量決定，因此無需證明有效性.

Fig. 3 The influence of workload on resource quality圖3 負(fù)載變化對(duì)資源品質(zhì)的影響

資源品質(zhì)變化測(cè)試初始時(shí)在每個(gè)服務(wù)器上提交相同數(shù)量的負(fù)載，隨后逐漸增加配置較好的A類型服務(wù)器上的負(fù)載數(shù)量，觀察資源品質(zhì)評(píng)估值的變化.資源品質(zhì)變化情況如圖3所示，圖3中曲線A1，A2和B1，B2分別為A類型和B類型服務(wù)器資源品質(zhì)值變化.從圖3中可以看出，開始時(shí)曲線A1，A2的值大于曲線B1，B2的值，即A類型服務(wù)器資源品質(zhì)值在初始時(shí)優(yōu)于B類型；隨著A類服務(wù)器負(fù)載加重，A1，A2開始下降而B1，B2逐漸上升，這是由于A類型服務(wù)器負(fù)載過重導(dǎo)致資源品質(zhì)指標(biāo)下降，品質(zhì)指標(biāo)中位數(shù)發(fā)生變化，從而影響B(tài)類型服務(wù)器資源品質(zhì)值反方向變化；負(fù)載持續(xù)加重時(shí)，2種類型服務(wù)器上計(jì)算資源品質(zhì)的比較關(guān)系發(fā)生逆轉(zhuǎn)，B類型服務(wù)器資源品質(zhì)值優(yōu)于A類型；當(dāng)負(fù)載數(shù)量不再變化，資源品質(zhì)值也隨之穩(wěn)定.綜上所述，RCE對(duì)資源品質(zhì)的評(píng)估值隨資源運(yùn)行情況而變化，可以反映出真實(shí)資源品質(zhì).

Fig. 4 Resource quality and average completion time of tasks圖4 計(jì)算資源品質(zhì)與任務(wù)平均完成時(shí)間

5.2.2 時(shí)效性測(cè)試

RCE時(shí)效性測(cè)試在之前測(cè)試程序的基礎(chǔ)上增加了網(wǎng)絡(luò)測(cè)試程序.測(cè)試在50 ms，100 ms，200 ms，400 ms，800 ms的采集周期下分別進(jìn)行，圖5為不同采集周期下RCE評(píng)估各種資源剩余能力的評(píng)估耗時(shí)變化.從圖5中可以看出，采集周期變小時(shí)，各種資源的評(píng)估耗時(shí)略有增加.因?yàn)橹芷谠叫?，RCE接收信息越頻繁，對(duì)數(shù)據(jù)的處理、維護(hù)代價(jià)越大.在同一采集周期下，磁盤與網(wǎng)絡(luò)的評(píng)估耗時(shí)基本相同，而內(nèi)存、CPU的評(píng)估耗時(shí)及波動(dòng)幅度均明顯大于磁盤與網(wǎng)絡(luò)，因?yàn)镃PU和內(nèi)存在評(píng)估過程中需要更新、處理多種數(shù)據(jù).

當(dāng)采集周期為50 ms時(shí)，CPU評(píng)估平均耗時(shí)14.06 ms，內(nèi)存評(píng)估平均耗時(shí)10.58 ms，磁盤與網(wǎng)絡(luò)的評(píng)估平均耗時(shí)分別不足6 ms和5 ms.因此RCE方法在運(yùn)行時(shí)評(píng)估的資源年剩余能力評(píng)估結(jié)果具有時(shí)效性.

Fig. 5 Evaluation time of RCE in different acquisition cycles圖5 不同采集周期下RCE評(píng)估耗時(shí)

5.2.3 擴(kuò)展性測(cè)試

擴(kuò)展性測(cè)試中，各計(jì)算節(jié)點(diǎn)將每次的采集信息在6 000 ms的周期內(nèi)向RCE評(píng)估服務(wù)發(fā)送多次，分別模擬600，1 200，1 800，2 400，3 000節(jié)點(diǎn)的集群規(guī)模.

RCE在不同集群規(guī)模下的評(píng)估耗時(shí)如圖6所示.從圖6中可以看出，擴(kuò)展性測(cè)試評(píng)估耗時(shí)及其波動(dòng)幅度大于之前的測(cè)試，且隨著模擬規(guī)模增大而增大.原因是集群規(guī)模的增大導(dǎo)致網(wǎng)絡(luò)傳輸、數(shù)據(jù)處理、數(shù)據(jù)結(jié)構(gòu)維護(hù)、相似任務(wù)識(shí)別等代價(jià)增加.CPU和內(nèi)存的資源評(píng)估耗時(shí)增加大于磁盤和網(wǎng)絡(luò)資源的資源評(píng)估耗時(shí)，因?yàn)镃PU和內(nèi)存資源在評(píng)估中需要處理的數(shù)據(jù)更多，使用平衡樹數(shù)據(jù)結(jié)構(gòu)更頻繁，相似任務(wù)集合維護(hù)代價(jià)會(huì)更大.

Fig. 6 Evaluation time of RCE in different cluster scale圖6 RCE在不同集群規(guī)模下的評(píng)估耗時(shí)

當(dāng)模擬集群規(guī)模達(dá)到3 000節(jié)點(diǎn)時(shí)，CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)評(píng)估的平均耗時(shí)分別為27.16 ms，18.49 ms，8.41 ms，6.45 ms.RCE方法在節(jié)點(diǎn)規(guī)模達(dá)到3 000時(shí)仍能得出具有時(shí)效性的結(jié)果，說明該方法擴(kuò)展性良好，可以應(yīng)用在大規(guī)模云平臺(tái)上.

5.3基于RCE的算法測(cè)試

5.3.1 資源分配算法測(cè)試

資源分配算法測(cè)試的負(fù)載規(guī)模從2開始，每次遞增0.5，當(dāng)規(guī)模達(dá)到16時(shí)，單次負(fù)載處理數(shù)據(jù)總計(jì)達(dá)到240 GB.資源分配測(cè)試分別在獨(dú)享和云環(huán)境下進(jìn)行，相同負(fù)載規(guī)模下完成時(shí)間越小表示性能越好.資源分配測(cè)試2種環(huán)境下測(cè)試結(jié)果如圖7和圖8所示.

Fig. 7 Resource allocation test in dedicated environment圖7 獨(dú)享環(huán)境下資源分配測(cè)試

Fig. 8 Resource allocation test in cloud environment圖8 云環(huán)境下資源分配測(cè)試

從圖7中可以看出，基于RCE的資源分配算法在相同規(guī)模負(fù)載下總是取得比Fair[27]算法更小的完成時(shí)間，并且隨著負(fù)載規(guī)模的增大，兩者負(fù)載完成時(shí)間差距越來越顯著.負(fù)載規(guī)模超過14時(shí)，基于RCE的資源分配算法的性能提升穩(wěn)定在35.5%左右.獨(dú)享環(huán)境下帶來的性能提升源于對(duì)任務(wù)資源需求和計(jì)算資源剩余能力的準(zhǔn)確量化.

相比在獨(dú)享環(huán)境中的測(cè)試結(jié)果，云環(huán)境測(cè)試在相同規(guī)模負(fù)載下的完成時(shí)間普遍大幅增加，這是環(huán)境中其他應(yīng)用占用及爭搶計(jì)算資源所造成的.與獨(dú)享環(huán)境資源分配測(cè)試結(jié)果一致的是，云環(huán)境中資源分配算法的優(yōu)化效果隨著負(fù)載規(guī)模的增大而增大.不同的是資源分配算法在云環(huán)境中取得了更好的效果，在規(guī)模超過14后負(fù)載完成時(shí)間降低穩(wěn)定在41%左右.原因是Fair算法不感知其他應(yīng)用造成的計(jì)算資源剩余能力變化，也不在分配資源時(shí)對(duì)計(jì)算資源剩余能力的變化做出調(diào)整，造成了計(jì)算資源被過多的任務(wù)爭搶使用，最終導(dǎo)致負(fù)載完成時(shí)間大幅增加.基于RCE的資源分配算法依據(jù)時(shí)刻變化的計(jì)算資源剩余能力評(píng)估值調(diào)整資源分配，避免了計(jì)算資源承載過多的任務(wù).

對(duì)比圖7和圖8，當(dāng)測(cè)試的負(fù)載規(guī)模較小時(shí)，2圖中柱狀圖均十分接近.原因有：1)基于RCE的資源分配算法的閾值由于負(fù)載執(zhí)行信息過少未達(dá)到精準(zhǔn)，效果不佳；2)負(fù)載規(guī)模較小時(shí)，負(fù)載中處理數(shù)據(jù)量大的作業(yè)往往決定著整個(gè)負(fù)載的完成時(shí)間，優(yōu)化效果不明顯.

5.3.2 負(fù)載均衡算法測(cè)試

負(fù)載均衡測(cè)試分別在獨(dú)享和云2種環(huán)境下進(jìn)行，每次均提交規(guī)模為20的負(fù)載.負(fù)載執(zhí)行中對(duì)各服務(wù)器上CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等資源的使用情況隨機(jī)采樣并計(jì)算資源利用率均值和標(biāo)準(zhǔn)差.測(cè)試結(jié)果以CPU被利用的時(shí)間百分比作為CPU資源利用率；以內(nèi)存空間被任務(wù)占用的百分比作為內(nèi)存資源利用率；以磁盤和網(wǎng)絡(luò)當(dāng)前傳輸速度占實(shí)測(cè)峰值傳輸速度的百分比作為磁盤和網(wǎng)絡(luò)資源利用率.

獨(dú)享環(huán)境下測(cè)試結(jié)果如圖9所示，基于RCE的負(fù)載均衡算法明顯提高了各種資源的平均利用率，并且降低了各服務(wù)器上資源利用率的差異，具體變化如表2所示，表2顯示云平臺(tái)中各個(gè)服務(wù)器上資源使用情況趨于均勻，負(fù)載均衡取得了良好的效果.云環(huán)境下測(cè)試結(jié)果如圖10所示，基于RCE的負(fù)載均衡算法在云環(huán)境中同樣取得了良好的效果，各種資源平均利用率提高，且各服務(wù)器間資源利用率差異降低，負(fù)載均勻分散在各個(gè)服務(wù)器上，具體變化如表3所示.

Fig. 9 Resource utilization in dedicated environment圖9 獨(dú)享環(huán)境下負(fù)載資源利用情況

Table 2 Changes of Resource Utilization in Dedicated Environment

Fig. 10 Resource utilization in cloud environment圖10 云環(huán)境下負(fù)載資源利用情況

Table 3 Changes of Resource Rtilization in Cloud Environment

對(duì)比圖9和圖10中Yarn平臺(tái)資源使用情況，不難發(fā)現(xiàn)相同負(fù)載下云環(huán)境中的資源利用率比在獨(dú)享環(huán)境中的更高，且各服務(wù)器資源利用率的差異更大.這是由于云環(huán)境中存在的其他應(yīng)用與Yarn應(yīng)用同時(shí)使用計(jì)算資源，造成個(gè)別服務(wù)器出現(xiàn)資源爭搶導(dǎo)致利用率升高，而在個(gè)別服務(wù)器上資源利用不變導(dǎo)致資源利用率的標(biāo)準(zhǔn)差變大.但是這種資源利用率的升高并不意味著性能的提升，嚴(yán)重的資源爭搶會(huì)導(dǎo)致局部的資源瓶頸，最終引起性能大幅下降.對(duì)比圖9和圖10中基于RCE的負(fù)載均衡算法取得的結(jié)果，可以看出該算法在云環(huán)境中相比在獨(dú)享環(huán)境中的平均資源利用率基本不變，而資源利用率標(biāo)準(zhǔn)差略有升高，這說明該算法適應(yīng)了環(huán)境中其他應(yīng)用的資源使用行為，并有效地調(diào)節(jié)了負(fù)載對(duì)計(jì)算資源的選擇.

對(duì)比表2和表3可知:1)基于RCE的負(fù)載均衡算法在云環(huán)境中對(duì)于資源平均利用率的提升相較獨(dú)享環(huán)境有所下降，其原因在于云環(huán)境中存在的科學(xué)計(jì)算應(yīng)用的資源使用行為提高了資源利用率，壓縮了提升空間;2)基于RCE的負(fù)載均衡算法在2種環(huán)境中取得的各服務(wù)器資源利用率標(biāo)準(zhǔn)差變化基本持平，這再次說明了該算法根據(jù)可用計(jì)算資源調(diào)節(jié)負(fù)載的資源選擇，并且取得了良好的效果.

5.3.3 異常識(shí)別算法測(cè)試

異常識(shí)別算法測(cè)試在獨(dú)享環(huán)境中進(jìn)行，測(cè)試中提交規(guī)模為20的負(fù)載，隨機(jī)制造多次計(jì)算資源異常并在異常被發(fā)現(xiàn)時(shí)解除.測(cè)試結(jié)果如圖11所示，有意制造的資源異常識(shí)別率達(dá)94.58%，且準(zhǔn)確記錄下異常原因，算法取得了很好的效果.從圖11中曲線可以看出，識(shí)別異常所需時(shí)間隨著系統(tǒng)運(yùn)行時(shí)間增長而逐漸減少，最終穩(wěn)定在52 s左右.原因是算法的識(shí)別耗時(shí)與閾值準(zhǔn)確性直接相關(guān)，隨著系統(tǒng)的運(yùn)行各種評(píng)估結(jié)果趨于準(zhǔn)確，依據(jù)該結(jié)果確定的各種識(shí)別閾值也一同趨于準(zhǔn)確，最終表現(xiàn)為識(shí)別耗時(shí)逐漸減少.

Fig. 11 Time of abnormal recognition圖11 異常識(shí)別耗時(shí)

由此測(cè)試可以得出結(jié)論，基于RCE的異常識(shí)別算法可以準(zhǔn)確且迅速地識(shí)別出服務(wù)器資源異常，并及時(shí)停止分配相應(yīng)服務(wù)器上的計(jì)算資源，避免服務(wù)器資源異常造成平臺(tái)整體性能下降，提高了云平臺(tái)穩(wěn)定性.

5.3.4 緩慢任務(wù)發(fā)現(xiàn)算法測(cè)試

緩慢任務(wù)發(fā)現(xiàn)測(cè)試在獨(dú)享環(huán)境下進(jìn)行，測(cè)試中提交規(guī)模為20的負(fù)載，并在負(fù)載中隨機(jī)挑選5%的任務(wù)進(jìn)行干擾使其執(zhí)行緩慢,當(dāng)任務(wù)被發(fā)現(xiàn)時(shí)停止干擾.

Fig. 12 Time of sluggish task recognition圖12 緩慢任務(wù)發(fā)現(xiàn)耗時(shí)

緩慢任務(wù)發(fā)現(xiàn)耗時(shí)如圖12所示，被干擾產(chǎn)生的緩慢任務(wù)全部被發(fā)現(xiàn)，且發(fā)現(xiàn)所需時(shí)間逐漸減少，最終穩(wěn)定在36 s左右.算法耗時(shí)與其使用的閾值有關(guān)，隨著負(fù)載的執(zhí)行信息越來越多，算法閾值變得準(zhǔn)確，發(fā)現(xiàn)耗時(shí)逐漸減少.

圖13所示為制造緩慢任務(wù)并分別采用基于RCE的緩慢發(fā)現(xiàn)算法及LATE算法[21]時(shí)相對(duì)不制造緩慢任務(wù)Yarn平臺(tái)的負(fù)載完成時(shí)間.從圖13中可以發(fā)現(xiàn)，采用基于RCE的緩慢任務(wù)發(fā)現(xiàn)算法時(shí)，負(fù)載完成時(shí)間相比無緩慢任務(wù)時(shí)僅增加了16.26%；而使用LATE算法時(shí)完成時(shí)間增加了35.04%，基于RCE的緩慢任務(wù)發(fā)現(xiàn)算法相比LATE算法有18.78%的性能提升.

Fig. 13 The influence of sluggish task on completion time圖13 緩慢任務(wù)對(duì)負(fù)載完成時(shí)間的影響

5.4云平臺(tái)優(yōu)化測(cè)試

本節(jié)測(cè)試中，在Yarn平臺(tái)中整合上述算法，驗(yàn)證基于RCE的算法對(duì)Yarn平臺(tái)的整體優(yōu)化效果.原Yarn平臺(tái)使用LATE算法作為緩慢任務(wù)發(fā)現(xiàn)算法.測(cè)試中分別在獨(dú)享和云2種環(huán)境中提交不同規(guī)模的負(fù)載并記錄負(fù)載完成時(shí)間.

圖14所示為獨(dú)享環(huán)境測(cè)試的負(fù)載完成時(shí)間.從圖14中曲線可以看出，基于RCE優(yōu)化后的Yarn平臺(tái)在各規(guī)模負(fù)載測(cè)試中均取得了優(yōu)于原始Yarn平臺(tái)的完成時(shí)間，并且優(yōu)化效果隨著負(fù)載規(guī)模的增大而增大.這是由于隨負(fù)載規(guī)模增大，RCE方法評(píng)估結(jié)果越準(zhǔn)確，算法的效果越明顯.當(dāng)負(fù)載規(guī)模超過14.5時(shí)，基于RCE的算法降低負(fù)載完成時(shí)間穩(wěn)定在57%左右.

圖15為云環(huán)境測(cè)試的負(fù)載完成時(shí)間.優(yōu)化效果隨著負(fù)載規(guī)模的增大而顯著，當(dāng)測(cè)試負(fù)載規(guī)模超過14時(shí)，優(yōu)化后平臺(tái)相比原平臺(tái)的負(fù)載完成時(shí)間降低效果穩(wěn)定在59%左右.另外，在云環(huán)境中優(yōu)化后的平臺(tái)降低了規(guī)模為2的負(fù)載12.09%的完成時(shí)間，這遠(yuǎn)遠(yuǎn)優(yōu)于獨(dú)享環(huán)境測(cè)試中0.4%的優(yōu)化效果.這可能由2方面原因共同導(dǎo)致：1)規(guī)模較小的負(fù)載所需完成時(shí)間較少；2)云環(huán)境中的其他應(yīng)用影響了Yarn應(yīng)用的資源使用.本身較小的負(fù)載完成時(shí)間受到影響之后大幅增加，也增加了其可被優(yōu)化的空間.

Fig. 15 Workload completion time in cloud environment圖15 云環(huán)境中負(fù)載完成時(shí)間

從圖14和圖15中的測(cè)試結(jié)果可以得出結(jié)論，基于RCE的算法在獨(dú)享和云環(huán)境中均能給云計(jì)算平臺(tái)帶來性能的大幅提升.

6 結(jié) 論

針對(duì)云平臺(tái)中存在的資源供給與需求的匹配問題，本文提出了一種新的解決思路：首先，利用相似任務(wù)特性，采用相似任務(wù)代替?zhèn)鹘y(tǒng)的測(cè)試程序，并綜合其他因素建立了運(yùn)行時(shí)計(jì)算資源剩余能力評(píng)估模型；其次，提出依據(jù)該模型的計(jì)算資源分類評(píng)估方法RCE，得出運(yùn)行時(shí)評(píng)估結(jié)果；最后，將計(jì)算資源剩余能力應(yīng)用在算法設(shè)計(jì)和優(yōu)化中，解決資源供給與需求的匹配問題，并對(duì)Yarn平臺(tái)進(jìn)行多方面優(yōu)化.在獨(dú)享和云環(huán)境中對(duì)本文工作進(jìn)行驗(yàn)證，測(cè)試結(jié)果顯示RCE的評(píng)估結(jié)果有效、具有時(shí)效性且擴(kuò)展性良好，并為平臺(tái)及算法優(yōu)化提供了有力支持，基于RCE的算法可以提高資源分配與任務(wù)資源需求的匹配程度，大幅提高云計(jì)算平臺(tái)性能.

在未來研究中，我們計(jì)劃將RCE應(yīng)用到更多種類資源的剩余能力評(píng)估中，并進(jìn)一步提高其效率.

[1]Apache. Hadoop[OL]. [2016-07-05]. http:hadoop.apache.org

[2]Vavilapalli V K, Murthy A C, Douglas C, et al. Apache Hadoop Yarn: Yet another resource negotiator[C]Proc of the 4th Annual Symp on Cloud Computing. New York: ACM, 2013: 5-20

[3]Reiss C, Tumanov A, Ganger G R, et al. Heterogeneity and dynamicity of clouds at scale: Google trace analysis[C]Proc of the 3rd ACM Symp on Cloud Computing. New York: ACM, 2012: 7-20

[4]Ananthanarayanan G, Kandula S, Greenberg A G, et al. Reining in the outliers in Map-Reduce clusters using Mantri[C]Proc of the 9th USENIX Symp on Operating Systems Design and Implementation. Berkeley, CA: USENIX Association, 2010: 24-37

[5]Mishra A K, Hellerstein J L, Cirne W, et al. Towards characterizing cloud backend workloads: Insights from Google compute clusters[J]. ACM SIGMETRICS Performance Evaluation Review, 2010, 37(4): 34-41

[6]Sharma B, Chudnovsky V, Hellerstein J L, et al. Modeling and synthesizing task placement constraints in Google compute clusters[C]Proc of the 2nd ACM Symp on Cloud Computing. New York: ACM, 2011: 3-16

[7]Chen Yanpei, Alspaugh S, Katz R H. Design insights for MapReduce from diverse production workloads, UCBEECS-2012-17[R]. Berkeley, CA: California University Department of Electrical Engineering and Computer Science, 2012

[8]Hwang Kai, Bai Xiaoying, Shi Yue, et al. Cloud performance modeling with benchmark evaluation of elastic scaling strategies[J]. IEEE Trans on Parallel and Distributed Systems, 2016, 27(1): 130-143

[9]Bruneo D. A stochastic model to investigate data center performance and QoS in IaaS cloud computing systems[J]. IEEE Trans on Parallel and Distributed Systems, 2014, 25(3): 560-569

[10]Wang Bin, Chang Xiaolin, Liu Jiqiang. Modeling heterogeneous virtual machines on IaaS data centers[J]. IEEE Communications Letters, 2015, 19(4): 537-540

[11]Boutin E, Ekanayake J, Lin Wei, et al. Apollo: Scalable and coordinated scheduling for cloud-scale computing[C]Proc of the 11th USENIX Symp on Operating Systems Design and Implementation. Berkeley, CA: USENIX Association, 2014: 285-300

[12]Zhang Xiao, Tune E, Hagmann R, et al. CPI2: CPU performance isolation for shared compute clusters[C]Proc of the 8th ACM European Conf on Computer Systems. New York: ACM, 2013: 379-391

[13]Hindman B, Konwinski A, Zaharia M, et al. Mesos: A platform for fine-grained resource sharing in the data center[C]Proc of the 11th USENIX Symp on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2011: 22-35

[14]Wikipedia. Powered by Apache Hadoop[OL]. [2016-07-05]. https:wiki.apache.orghadoopPoweredBy

[15]Apache. Organizations using Mesos[OL]. [2016-07-05]. http:mesos.apache.orgdocumentationlatestpowered-by-mesos

[16]Facebook. Under the Hood: Scheduling MapReduce jobs more efficiently with Corona[OL]. [2016-07-05]. https:www.facebook.comnotesface book-engineeringunder-the-hood-scheduling-mapreduce-jobs-more-efficiently-with-corona10151142560538920

[17]Zhang Zhuo, Li Chao, Tao Yangyu, et al. Fuxi: A fault-tolerant resource management and job scheduling system at Internet scale[J]. Proceedings of the VLDB Endowment, 2014, 7(13): 1393-1404

[18]Verma A, Pedrosa L, Korupolu M, et al. Large-scale cluster management at Google with Borg[C]Proc of the 10th European Conf on Computer Systems. New York: ACM, 2015: 18-34

[19]Schwarzkopf M, Konwinski A, Abd-El-Malek M, et al. Omega: Flexible, scalable schedulers for large compute clusters[C]Proc of the 8th ACM European Conf on Computer Systems. New York: ACM, 2013: 351-364

[20]Dean J, Barroso L A. The tail at scale[J]. Communications of the ACM, 2013, 56(2): 74-80

[21]Zaharia M, Konwinski A, Joseph A D, et al. Improving MapReduce performance in heterogeneous environments[C]Proc of the 8th USENIX Symp on Operating Systems Design and Implementation. Berkeley, CA: USENIX Association, 2008: 7-20

[22]Li Qianmu, Zhang Shengxiao, Lu Lu, et al. A job scheduling algorithm and hybrid scheduling method on Hadoop platform[J]. Journal of Computer Research and Development, 2013, 50(Suppl.): 361-368 (in Chinese)(李千目, 張晟驍, 陸路, 等. 一種 Hadoop 平臺(tái)下的調(diào)度算法及混合調(diào)度策略[J]. 計(jì)算機(jī)研究與發(fā)展, 2013, 50(增刊): 361-368)

[23]Zheng Xiaowei, Xiang Ming, Zhang Dawei, et al. An adaptive tasks scheduling method based on the ability of node in Hadoop cluster[J]. Journal of Computer Research and Development, 2014, 51(3): 618-626 (in Chinese)(鄭曉薇, 項(xiàng)明, 張大為, 等. 基于節(jié)點(diǎn)能力的 Hadoop 集群任務(wù)自適應(yīng)調(diào)度方法[J]. 計(jì)算機(jī)研究與發(fā)展, 2014, 51(3): 618-626)

[24]Curnow H J, Wichmann B A. A synthetic benchmark[J]. The Computer Journal, 1976, 19(1): 43-49

[25]Dongarra J J. Performance of various computers using standard linear equations software in a Fortran environment[J]. Simulation, 1987, 49(2): 51-62

[26]McCalpin J D. A survey of memory bandwidth and machine balance in current high performance computers[JOL]. IEEE TCCA Newsletter, 1995 [2017-02-06]. http:www.cs.virginia.edu～mccalpinpapersbalance

[27]Zaharia M, Borthakur D, Sarma J S, et al. Job scheduling for multi-user mapreduce clusters, UCBEECS-2009-55[R]. Berkeley, CA: Department of Electrical Engineering and Computer Science, California University, 2009ZhouMosong, born in 1988. PhD candidate. His main research interests include cloud computing and distributed computing.

DongXiaoshe, born in 1963. PhD, professor, PhD supervisor. Member of CCF. His main research interests include high performance computer architecture, grid computing, cloud computing and storage.

ChenHeng, born in 1979. PhD, lecturer. His main research interests include cloud computing.

ZhangXingjun, born in 1969. PhD, professor, PhD supervisor. Member of CCF. His main research interests include high performance computer architecture, the new technologies of computer networks and high performance computing.

ImprovingCloudPlatformBasedontheRuntimeResourceCapacityEvaluation

Zhou Mosong, Dong Xiaoshe, Chen Heng, and Zhang Xingjun

(School of Electronic and Information Engineering, Xi’an Jiaotong University, Xi’an 710049)

There is a mismatch between computing resource supply and demand in cloud computing platform resource management, which leads to the performance degradation. This paper establishes a runtime computing resource available capacity evaluation model base on similar tasks. The model uses the characteristic of cloud computing workload in which similar tasks have the same execution logic, evaluates computing resource available capacity according to similar tasks avoiding computing resource consumption in executing benchmark. This paper applies the model to propose a computing resource capacity evaluation method called RCE, which considers many factors and evaluates runtime computing resource available capacity classified by resource type. This method gets accurate evaluation results timely with little cost. We apply RCE results in some algorithms to match computing resource supply and demand, and improve cloud computing platform performance. We test RCE method and algorithms base on RCE in dedicated and real cloud computing environments. The test results show that the RCE method gets runtime evaluation results timely and the evaluation results reflect computing resource available capacity accurately. Moreover, the RCE method supports the optimization of algorithm and platform effectively. And algorithms base on RCE resolve the mismatch problem between resource supply and demand, and significantly improve the performance of cloud computing platform.

cloud computing; resource capacity evaluation (RCE); similar task; resource management; platform optimization

2016-09-14；

2017-02-21

國家重點(diǎn)研發(fā)計(jì)劃項(xiàng)目(2016YFB0200902)；國家自然科學(xué)基金項(xiàng)目(61572394)

This work was supported by the National Key Research and Development Program of China (2016YFB0200902) and the National Natural Science Foundation of China (61572394).

陳衡(hengchen@mail.xjtu.edu.cn)

TP391