基于計算資源運行時剩余能力評估優化云平臺

周墨頌 董小社 陳 衡 張興軍

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

(zhoumosong@stu.xjtu.edu.cn)

基于計算資源運行時剩余能力評估優化云平臺

周墨頌 董小社 陳 衡 張興軍

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

(zhoumosong@stu.xjtu.edu.cn)

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

云計算；資源能力評估；相似任務；資源管理；平臺優化

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

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

1) 基于相似任務建立運行時云計算資源剩余能力評估模型，依據相似任務在不同計算資源上的執行情況量化計算資源運行時剩余能力.

2) 基于評估模型針對CPU、內存、磁盤、網絡4種資源提出了分類評估方法RCE，并實現了與平臺無關的評估服務.

3) 設計了基于RCE的任務資源需求推測、資源分配、負載均衡、異常識別等算法，并在Yarn平臺中實現算法以解決云資源管理平臺中的問題，優化云平臺性能.

測試結果顯示，RCE的評估結果有效且及時反映出計算資源能力變化，基于RCE評估結果的算法有效解決了資源供給與需求的匹配問題，提高了云平臺資源利用率，降低了負載完成時間.RCE為平臺及算法的優化提供了良好的支持.

1 相關工作

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

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

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

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

在云平臺執行負載期間實時評估負載的資源需求和計算資源剩余能力是解決上述問題的一種有效方法.針對云計算資源能力評估研究的主要思路分為2種：

1) 文獻[8]，它基于CloudSuite，HiBench，BenchClouds，TPC-W等基準測試結果建立性能評估模型，對云計算平臺效率、彈性、QoS等進行評估.這種方式并不能應用在運行時資源能力評估中，原因在于在運行時引入額外測試程序的性能代價太大，且通過分析測試程序運行結果得出的評估結果不具有時效性.

2) 文獻[9-10]，它們針對云計算平臺的性能指標建立基于隨機回報Petri網、連續時間馬爾可夫鏈等的評估模型.由于這種方式無法全面考慮所有影響因素、不使用測試程序，因此其評估結果并不準確.

已有評估研究的問題在于不使用測試程序得不到準確結果，而使用測試程序會消耗資源，影響負載執行.本文評估解決了這個問題，它利用云計算負載中相似任務的特性，采用相似任務代替傳統評估方法中使用的測試程序，并綜合相似任務運行時信息、計算資源理論性能及基準測試信息等建立了運行時計算資源剩余能力評估模型.因此本文的評估具有的優勢包括：運行時不引入負載無關的測試程序，性能代價小；使用負載中相似任務代替測試程序，保證結果準確性；運行時實時評估，結果時效性高.

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

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

2 基于相似任務的計算資源剩余能力評估模型

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

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

定義2. 相似任務.假設任務執行邏輯為L，任務所處階段為S，處理數據量為D，如果對于任務i和j存在關系Li=Lj∧Si=Sj∧Di=Dj，則任務i和j互為相似任務.

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

（1）

定理1推導如下：

任務的性能指標P與任務邏輯L和計算資源品質θ間存在映射關系：

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

（2）

對于相似任務i和j而言，執行邏輯相同，即Li=Lj，因此有：

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

（3）

因此任務與其相似任務性能指標的比較關系可以反映出任務占用資源的品質，云負載相似任務可以代替測試程序用于評估計算資源剩余能力.

評估模型依據定理1評估資源剩余能力Cr R，并綜合計算資源的理論能力Cs R以及實測峰值Sj，使評估結果CR更加準確.評估模型如式(4)，其計算結果數值越大表示被評估的計算資源剩余能力越大.

其中，Cr R為計算資源剩余能力；Mr R為同類計算資源運行時剩余能力的中位數；TEST為計算資源測試項集合；Sj為測試項j的實測峰值；Ej為測試項j的期望結果；Wj為測試項j的權重；Ms R為同類計算資源理論能力的中位數；α，β，η為權重參數，滿足α+β+η=1.

基于相似任務的評估模型的創新在于使用云計算負載代替了傳統測試程序，它在3個方面具有優點：

1) 準確度.該模型考慮計算資源上任務執行情況、理論能力、測試結果等方面，評估結果準確度高.

2) 代價低.該模型在運行時只需要執行負載，評估運行時代價很低.

3) 時效性.評估過程與負載執行同時進行，評估結果時效性高.

3 運行時計算資源剩余能力評估方法RCE

3.1RCE概述

同一任務對不同計算資源的使用行為不同，各種計算資源信息間不具有比較性.因此，RCE方法按資源類型分類評估，目前分CPU、內存、磁盤、網絡4類進行.圖1所示為RCE方法示意圖.

圖1中Master為云平臺管理節點；Worker為云平臺工作節點，其內小矩形表示計算資源；陰影代表被占用.工作節點上運行著資源特性各異的各種任務，任務A與A′互為相似任務.RCE執行流程如下：

1) 當服務器作為工作節點首次加入云平臺時，RCE收集服務器計算資源理論能力并執行各種基準測試采集測試結果.

2) 云平臺工作節點執行云負載時，RCE采集任務及資源的運行時信息.

3) RCE分類存儲各種運行時信息，識別負載中相似任務，并按資源類型分類評估計算資源.

4) 云平臺管理服務Master通過RCE接口獲取評估結果并應用在各種算法中，優化云平臺性能.

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

3.2相似任務識別

識別云計算負載中的相似任務是資源剩余能力評估的基礎，RCE依照任務執行邏輯、處理數據大小、所處執行階段識別相似任務，具體步驟如下：

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

2) 根據運行時信息分別迭代計算任務各種資源每個進度的資源使用情況；

3) 根據任務資源使用信息劃分任務執行階段；

4) 按照任務執行階段將備選集合劃分成多個子集，執行階段相同的任務在相同子集中，子集內的任務互為相似任務.

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

（5）

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

利用任務資源使用信息劃分執行階段時，依據不同資源劃分出的任務階段可能不同.RCE依據CPU、內存、磁盤、網絡資源得出4種執行階段劃分，依據某種資源劃分任務執行階段的流程圖如圖2所示.

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

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

3.3計算資源分類評估

3.3.1 CPU資源評估

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

（6）

在分析CPU理論性能時，RCE主要考慮計算核心數、主頻、緩存等指標.由于層次越小的緩存對CPU性能影響越大，因此分析時賦予層次低的緩存更大的權重.

（7）

其中,Ch為計算核心數，Sp為主頻，Li為i層的緩存大小，W為小于1的權值，設置t=3.

RCE采用Whetstone[24]作為CPU的基準測試，Fortran版的Whetstone是第1個工業標準上的通用CPU綜合測試.相比常用于超級計算機科學計算的LINPACK[25]測試，Whetstone含有浮點計算、過程調用、條件跳轉、數學函數等多個測試項，更加適合測試云計算服務器CPU的綜合能力.

3.3.2 內存資源評估

在內存資源評估中，RCE以缺頁頻率的倒數作為衡量內存資源品質的指標，并按照式(8)計算內存資源運行時剩余能力值Crm.

（8）

RCE使用內存資源的理論帶寬值作為內存理論性能分析結果，并采用STREAM[26]作為內存資源基準測試，測試中啟動與CPU計算核心相等的線程并行操作內存以衡量其可持續的帶寬.

3.3.3 磁盤資源評估

在磁盤資源評估中，RCE以磁盤上IO請求排隊及執行時間等指標衡量磁盤資源品質，而以未利用的磁盤帶寬和傳輸次數等指標考察可用資源量，磁盤資源剩余能力Crs計算為

（9）

RCE使用磁盤轉速、磁頭數、緩存大小的乘積作為磁盤理論性能的分析結果.磁盤基準測試中分別讀寫不同大小的文件及磁盤緩存，并記錄磁盤峰值帶寬及傳輸次數作為結果，測試數據范圍為16 KB～8 GB，單個測試項的讀寫次數從5～500次不等.

3.3.4 網絡資源評估

網絡資源評估針對帶寬資源進行，帶寬品質均相等，評估時只需考慮空閑資源量.RCE使用未利用的網絡帶寬作為網絡空閑資源量，網絡資源運行時剩余能力Crn在數值上等于實測帶寬峰值Pnio與當前被占用帶寬Cnio的差,即:

Crn=Pnio-Cnio.

（10）

RCE使用網絡設備標識的理論帶寬作為理論性能.在網絡資源基準測試中，RCE使用多臺服務器協同測試，模擬實際網絡使用并記錄峰值帶寬.測試中傳輸數據按大小分為3類，范圍涵蓋16 KB～2 GB.

3.3.5 評估值計算

RCE將各計算資源評估因素代入評估模型分別計算最終評估結果.由于不同計算資源的特性具有差異，RCE針對CPU、內存、磁盤、網絡資源的特性分別調整評估模型參數使最終評估結果準確.評估模型中的α，β，η參數分別代表計算資源運行時剩余能力、基準測試性能峰值、理論性能在計算資源剩余能力評估結果中所占的權重.對于CPU資源，RCE使用默認參數0.8，0.1，0.1分別作為α，β，η的值；對于內存資源，RCE在默認參數的基礎上提高了α而降低了β，η的值；對于磁盤和網絡資源，RCE在默認參數的基礎上提高了β而降低了η，這是由于資源的理論性能達不到，參考意義不大.

3.4RCE實現

RCE在實現時設計為1個評估服務和若干信息采集服務組成的主從式架構，其中采集服務負責采集評估所需的各種信息并匯報給評估服務，評估服務負責分類存儲各種信息、識別相似任務并使用評估模型量化運行時計算資源剩余能力評估值.評估服務可以與云平臺管理服務分離部署，這使得服務不互相干擾，不影響云平臺可擴展性.RCE的實現與具體云平臺無關，其評估服務中設計有獲取各種評估因素以及結果的接口，可供其他服務獲取使用.因此，RCE可以靈活接入各種云平臺提供評估服務.

RCE在評估過程中多次用到了數據的中位數.在具體實現中，我們以平衡二叉樹存儲信息，并使用二叉樹根節點數據作為近似中位數在計算中使用，以提高中位數的獲取效率.

4 基于RCE的算法優化

在負載運行時得到具有時效性的計算資源剩余能力結果為匹配資源供給與需求打下基礎，同時為優化云平臺各種算法提供了新思路和支持.本節基于RCE設計、優化了任務需求推測、資源分配、負載均衡等算法并在Yarn平臺中實現了這些算法：1)解決云平臺中資源供給與需求的問題、提高云平臺性能；2)演示計算資源剩余能力評估結果的應用，證明評估結果對算法優化的支持效果.

4.1任務資源需求推測算法

本文依據相似任務的資源使用情況，考慮計算資源的品質因素，推測任務對CPU、內存、磁盤、網絡等資源的需求，具體如算法1所示：

算法1. 任務資源需求推測算法.

輸入：任務T、相似任務集合ST；

輸出：任務T的資源需求.

①forT中每個階段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);

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

4.2資源分配算法

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

算法2. 資源分配算法.

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

①fors∈Sedo

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

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

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

⑤ifCn-Thn×BnCntgt;Tnthen

⑥ AllocResoucre(s, Tx);

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

⑧endif

⑨endif

⑩endif

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

4.3負載均衡算法

云計算平臺負載是否均勻分布是衡量平臺可用性的重要指標之一,基于RCE的負載均衡算法依據RCE評估結果和任務資源特性篩選被分配服務器，使負載在各服務器上均勻分布，實現有效的負載均衡.

（11）

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

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

負載均衡算法如算法3所示：

算法3. 負載均衡算法.

輸入：任務資源需求Tx、任務平均資源需求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*檢查時延*

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

4.4異常識別算法

云平臺中服務器資源異常輕則影響任務執行，重則影響整個平臺運轉.基于RCE的異常識別算法是通過分析RCE的評估指標來識別異常，并采取報告異常原因、停止分配等相關措施避免異常造成嚴重影響.異常識別算法如算法4所示：

算法4. 異常識別算法.

輸入：服務器集合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使用任務進度指標Cp進行初篩,Cp由服務器上任務與其相似任務的每秒進度值計算，當Cp大于集合S中各服務器該指標的10分位值Thp時，則認為服務器C不存在異常;如果服務器上可能存在異常，則開始分析服務器計算資源.CIPC由服務器上各任務與其相似任務平均每個時鐘周期完成的指令數的比值，再與其資源占用百分比相乘求和后再除以總資源占用率計算.當服務器任務指標CIPC小于集合S中相同型號系列CPU相應指標的10分位值ThIPC并且CPU空閑百分比Cidle小于Thidle時，即CPU大部分時間被占用但是性能很差，則加蓋時間戳T0.Cpf與CIPC計算過程相似，其指示服務內存平均缺頁頻率情況.當服務器Cpf指標大于各服務器相應指標的10分位值Thpf并且內存空閑百分比Cfreelt;Thfree時，則加蓋時間戳T1.當磁盤IO請求平均等待時間Cw大于各服務器IO請求平均等待時間的95分位值Thw或者磁盤IO隊列長度Cl大于各服務器IO隊列長度的95分位值Thl時，則加蓋時間戳T2.如果3個時間戳均為0，則將服務器C從疑似異常集合G以及異常集合H中除去并進入下一次循環，否則將C加入疑似異常集合G中.當服務器由于某種原因在疑似異常集合中持續存在超過Tht時，則將服務器加入異常集合并記錄異常信息.當服務器處于異常或疑似異常集合中時，云平臺將暫停分配該服務器資源，避免異常造成影響.

當沒有足夠數據可供分析時,閾值不準確會造成算法判斷失誤率大幅升高,此時算法會暫停識別工作等待足夠數據出現.相比傳統的異常識別方法，基于RCE的異常識別算法在識別速度和精度上均有提升，它不僅可以精確報告出現異常的計算資源，而且可以在異常出現時停止分配服務器資源，防止異常造成的影響擴大，更加適合應用在實際環境中.

4.5緩慢任務發現算法

在云計算中，作業中全部任務完成才標志作業完成，因此避免個別任務拖慢整個作業十分重要.基于RCE的緩慢任務發現算法依據RCE評估結果及運行時信息精確識別緩慢任務并在必要時啟動冗余任務，從預防到補救全方位避免作業完成時間被拖長.緩慢任務發現算法如算法5所示：

算法5. 緩慢任務發現算法.

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

輸出：

①forT∈Stado

② T0←(Tslt;ThsandTIPClt;ThIPC)?

系統時間：0;

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

④ T1←系統時間;

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

⑥ H←H∪{T};

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

⑧ ApplyAndRestart(T);

⑨endif

⑩endif

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

調節算法中的閾值Tt可以在發現緩慢任務的耗時和準確性之間做出取舍.當閾值Tt較小時，算法5對執行緩慢的任務十分敏感，這一方面大幅縮短了發現緩慢任務的耗時，另一方面將執行稍微緩慢的任務識別為緩慢任務，在發現準確度方面做出了一定的妥協.在任務被確認執行緩慢之后，算法5權衡利弊決定是否啟動冗余任務，因此并不是所有執行緩慢任務都被冗余執行，這很大程度上彌補了準確度下降帶來的影響.調節閾值Tht可以決定冗余任務的啟動條件，冗余任務占用的總資源以及任務數也可以配置，以避免過度啟動冗余任務浪費計算資源.

算法5發現緩慢任務的精確度依賴于各種閾值的準確性，當閾值不準確時算法會暫停發現以避免發現效率大幅下降.當閾值隨平臺運行時間及負載信息的增加而趨于準確之后，算法會繼續工作.

5 實驗與結果

本節首先介紹各種測試的環境以及負載；之后測試驗證RCE和基于RCE的各種算法，證明RCE評估的有效性、時效性、擴展性以及RCE評估結果對算法和平臺的優化支持.

5.1測試環境及負載介紹

本文使用國家高性能計算中心(西安)中的一個集群測試驗證，該集群由30臺服務器組成，具體配置如表1所示.RCE方法有效性和時效性測試使用集群中3臺A類型和2臺B類型服務器，在1臺A類型服務器上部署RCE評估服務，其余4臺服務器作為計算節點.在方法擴展性測試中，使用集群所有服務器模擬各種規模的集群.該部分測試使用CPU、內存、磁盤等資源特性突出的測試程序作為負載.

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

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

本文分別在獨享和云2種環境下測試驗證：在獨享環境中，整個集群只執行測試負載；在云環境中，集群資源由Yarn平臺和科學計算等應用共享，集群處于日常真實使用狀態.

5.2RCE方法測試

5.2.1 有效性測試

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

Fig. 3 The influence of workload on resource quality圖3 負載變化對資源品質的影響

資源品質變化測試初始時在每個服務器上提交相同數量的負載，隨后逐漸增加配置較好的A類型服務器上的負載數量，觀察資源品質評估值的變化.資源品質變化情況如圖3所示，圖3中曲線A1，A2和B1，B2分別為A類型和B類型服務器資源品質值變化.從圖3中可以看出，開始時曲線A1，A2的值大于曲線B1，B2的值，即A類型服務器資源品質值在初始時優于B類型；隨著A類服務器負載加重，A1，A2開始下降而B1，B2逐漸上升，這是由于A類型服務器負載過重導致資源品質指標下降，品質指標中位數發生變化，從而影響B類型服務器資源品質值反方向變化；負載持續加重時，2種類型服務器上計算資源品質的比較關系發生逆轉，B類型服務器資源品質值優于A類型；當負載數量不再變化，資源品質值也隨之穩定.綜上所述，RCE對資源品質的評估值隨資源運行情況而變化，可以反映出真實資源品質.

Fig. 4 Resource quality and average completion time of tasks圖4 計算資源品質與任務平均完成時間

5.2.2 時效性測試

RCE時效性測試在之前測試程序的基礎上增加了網絡測試程序.測試在50 ms，100 ms，200 ms，400 ms，800 ms的采集周期下分別進行，圖5為不同采集周期下RCE評估各種資源剩余能力的評估耗時變化.從圖5中可以看出，采集周期變小時，各種資源的評估耗時略有增加.因為周期越小，RCE接收信息越頻繁，對數據的處理、維護代價越大.在同一采集周期下，磁盤與網絡的評估耗時基本相同，而內存、CPU的評估耗時及波動幅度均明顯大于磁盤與網絡，因為CPU和內存在評估過程中需要更新、處理多種數據.

當采集周期為50 ms時，CPU評估平均耗時14.06 ms，內存評估平均耗時10.58 ms，磁盤與網絡的評估平均耗時分別不足6 ms和5 ms.因此RCE方法在運行時評估的資源年剩余能力評估結果具有時效性.

Fig. 5 Evaluation time of RCE in different acquisition cycles圖5 不同采集周期下RCE評估耗時

5.2.3 擴展性測試

擴展性測試中，各計算節點將每次的采集信息在6 000 ms的周期內向RCE評估服務發送多次，分別模擬600，1 200，1 800，2 400，3 000節點的集群規模.

RCE在不同集群規模下的評估耗時如圖6所示.從圖6中可以看出，擴展性測試評估耗時及其波動幅度大于之前的測試，且隨著模擬規模增大而增大.原因是集群規模的增大導致網絡傳輸、數據處理、數據結構維護、相似任務識別等代價增加.CPU和內存的資源評估耗時增加大于磁盤和網絡資源的資源評估耗時，因為CPU和內存資源在評估中需要處理的數據更多，使用平衡樹數據結構更頻繁，相似任務集合維護代價會更大.

Fig. 6 Evaluation time of RCE in different cluster scale圖6 RCE在不同集群規模下的評估耗時

當模擬集群規模達到3 000節點時，CPU、內存、磁盤、網絡評估的平均耗時分別為27.16 ms，18.49 ms，8.41 ms，6.45 ms.RCE方法在節點規模達到3 000時仍能得出具有時效性的結果，說明該方法擴展性良好，可以應用在大規模云平臺上.

5.3基于RCE的算法測試

5.3.1 資源分配算法測試

資源分配算法測試的負載規模從2開始，每次遞增0.5，當規模達到16時，單次負載處理數據總計達到240 GB.資源分配測試分別在獨享和云環境下進行，相同負載規模下完成時間越小表示性能越好.資源分配測試2種環境下測試結果如圖7和圖8所示.

Fig. 7 Resource allocation test in dedicated environment圖7 獨享環境下資源分配測試

Fig. 8 Resource allocation test in cloud environment圖8 云環境下資源分配測試

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

相比在獨享環境中的測試結果，云環境測試在相同規模負載下的完成時間普遍大幅增加，這是環境中其他應用占用及爭搶計算資源所造成的.與獨享環境資源分配測試結果一致的是，云環境中資源分配算法的優化效果隨著負載規模的增大而增大.不同的是資源分配算法在云環境中取得了更好的效果，在規模超過14后負載完成時間降低穩定在41%左右.原因是Fair算法不感知其他應用造成的計算資源剩余能力變化，也不在分配資源時對計算資源剩余能力的變化做出調整，造成了計算資源被過多的任務爭搶使用，最終導致負載完成時間大幅增加.基于RCE的資源分配算法依據時刻變化的計算資源剩余能力評估值調整資源分配，避免了計算資源承載過多的任務.

對比圖7和圖8，當測試的負載規模較小時，2圖中柱狀圖均十分接近.原因有：1)基于RCE的資源分配算法的閾值由于負載執行信息過少未達到精準，效果不佳；2)負載規模較小時，負載中處理數據量大的作業往往決定著整個負載的完成時間，優化效果不明顯.

5.3.2 負載均衡算法測試

負載均衡測試分別在獨享和云2種環境下進行，每次均提交規模為20的負載.負載執行中對各服務器上CPU、內存、磁盤、網絡等資源的使用情況隨機采樣并計算資源利用率均值和標準差.測試結果以CPU被利用的時間百分比作為CPU資源利用率；以內存空間被任務占用的百分比作為內存資源利用率；以磁盤和網絡當前傳輸速度占實測峰值傳輸速度的百分比作為磁盤和網絡資源利用率.

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

Fig. 9 Resource utilization in dedicated environment圖9 獨享環境下負載資源利用情況

Table 2 Changes of Resource Utilization in Dedicated Environment

Fig. 10 Resource utilization in cloud environment圖10 云環境下負載資源利用情況

Table 3 Changes of Resource Rtilization in Cloud Environment

對比圖9和圖10中Yarn平臺資源使用情況，不難發現相同負載下云環境中的資源利用率比在獨享環境中的更高，且各服務器資源利用率的差異更大.這是由于云環境中存在的其他應用與Yarn應用同時使用計算資源，造成個別服務器出現資源爭搶導致利用率升高，而在個別服務器上資源利用不變導致資源利用率的標準差變大.但是這種資源利用率的升高并不意味著性能的提升，嚴重的資源爭搶會導致局部的資源瓶頸，最終引起性能大幅下降.對比圖9和圖10中基于RCE的負載均衡算法取得的結果，可以看出該算法在云環境中相比在獨享環境中的平均資源利用率基本不變，而資源利用率標準差略有升高，這說明該算法適應了環境中其他應用的資源使用行為，并有效地調節了負載對計算資源的選擇.

對比表2和表3可知:1)基于RCE的負載均衡算法在云環境中對于資源平均利用率的提升相較獨享環境有所下降，其原因在于云環境中存在的科學計算應用的資源使用行為提高了資源利用率，壓縮了提升空間;2)基于RCE的負載均衡算法在2種環境中取得的各服務器資源利用率標準差變化基本持平，這再次說明了該算法根據可用計算資源調節負載的資源選擇，并且取得了良好的效果.

5.3.3 異常識別算法測試

異常識別算法測試在獨享環境中進行，測試中提交規模為20的負載，隨機制造多次計算資源異常并在異常被發現時解除.測試結果如圖11所示，有意制造的資源異常識別率達94.58%，且準確記錄下異常原因，算法取得了很好的效果.從圖11中曲線可以看出，識別異常所需時間隨著系統運行時間增長而逐漸減少，最終穩定在52 s左右.原因是算法的識別耗時與閾值準確性直接相關，隨著系統的運行各種評估結果趨于準確，依據該結果確定的各種識別閾值也一同趨于準確，最終表現為識別耗時逐漸減少.

Fig. 11 Time of abnormal recognition圖11 異常識別耗時

由此測試可以得出結論，基于RCE的異常識別算法可以準確且迅速地識別出服務器資源異常，并及時停止分配相應服務器上的計算資源，避免服務器資源異常造成平臺整體性能下降，提高了云平臺穩定性.

5.3.4 緩慢任務發現算法測試

緩慢任務發現測試在獨享環境下進行，測試中提交規模為20的負載，并在負載中隨機挑選5%的任務進行干擾使其執行緩慢,當任務被發現時停止干擾.

Fig. 12 Time of sluggish task recognition圖12 緩慢任務發現耗時

緩慢任務發現耗時如圖12所示，被干擾產生的緩慢任務全部被發現，且發現所需時間逐漸減少，最終穩定在36 s左右.算法耗時與其使用的閾值有關，隨著負載的執行信息越來越多，算法閾值變得準確，發現耗時逐漸減少.

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

Fig. 13 The influence of sluggish task on completion time圖13 緩慢任務對負載完成時間的影響

5.4云平臺優化測試

本節測試中，在Yarn平臺中整合上述算法，驗證基于RCE的算法對Yarn平臺的整體優化效果.原Yarn平臺使用LATE算法作為緩慢任務發現算法.測試中分別在獨享和云2種環境中提交不同規模的負載并記錄負載完成時間.

圖14所示為獨享環境測試的負載完成時間.從圖14中曲線可以看出，基于RCE優化后的Yarn平臺在各規模負載測試中均取得了優于原始Yarn平臺的完成時間，并且優化效果隨著負載規模的增大而增大.這是由于隨負載規模增大，RCE方法評估結果越準確，算法的效果越明顯.當負載規模超過14.5時，基于RCE的算法降低負載完成時間穩定在57%左右.

圖15為云環境測試的負載完成時間.優化效果隨著負載規模的增大而顯著，當測試負載規模超過14時，優化后平臺相比原平臺的負載完成時間降低效果穩定在59%左右.另外，在云環境中優化后的平臺降低了規模為2的負載12.09%的完成時間，這遠遠優于獨享環境測試中0.4%的優化效果.這可能由2方面原因共同導致：1)規模較小的負載所需完成時間較少；2)云環境中的其他應用影響了Yarn應用的資源使用.本身較小的負載完成時間受到影響之后大幅增加，也增加了其可被優化的空間.

Fig. 15 Workload completion time in cloud environment圖15 云環境中負載完成時間

從圖14和圖15中的測試結果可以得出結論，基于RCE的算法在獨享和云環境中均能給云計算平臺帶來性能的大幅提升.

6 結 論

針對云平臺中存在的資源供給與需求的匹配問題，本文提出了一種新的解決思路：首先，利用相似任務特性，采用相似任務代替傳統的測試程序，并綜合其他因素建立了運行時計算資源剩余能力評估模型；其次，提出依據該模型的計算資源分類評估方法RCE，得出運行時評估結果；最后，將計算資源剩余能力應用在算法設計和優化中，解決資源供給與需求的匹配問題，并對Yarn平臺進行多方面優化.在獨享和云環境中對本文工作進行驗證，測試結果顯示RCE的評估結果有效、具有時效性且擴展性良好，并為平臺及算法優化提供了有力支持，基于RCE的算法可以提高資源分配與任務資源需求的匹配程度，大幅提高云計算平臺性能.

在未來研究中，我們計劃將RCE應用到更多種類資源的剩余能力評估中，并進一步提高其效率.

[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 平臺下的調度算法及混合調度策略[J]. 計算機研究與發展, 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)(鄭曉薇, 項明, 張大為, 等. 基于節點能力的 Hadoop 集群任務自適應調度方法[J]. 計算機研究與發展, 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

國家重點研發計劃項目(2016YFB0200902)；國家自然科學基金項目(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