云計(jì)算中的服務(wù)可用性保障機(jī)制

沈時(shí)軍，劉欣然,2，張鴻，朱春鴿,2

（1. 國(guó)家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心，北京 100029；2. 北京郵電大學(xué) 信息安全中心，北京 100876）

1 引言

云計(jì)算通過(guò)虛擬化技術(shù)動(dòng)態(tài)整合 IT基礎(chǔ)設(shè)施與平臺(tái)資源，利用互聯(lián)網(wǎng)絡(luò)為企業(yè)與個(gè)人用戶(hù)提供按需的、廉價(jià)的計(jì)算、存儲(chǔ)、軟件、平臺(tái)等服務(wù)。近年來(lái)，隨著國(guó)外Amazon EC2、Google App Engine、Microsoft Azure及國(guó)內(nèi)阿里云等一系列云計(jì)算產(chǎn)品的成功以及OpenStack、CloudStack、Eucalyptus、Open Nebula等許多開(kāi)源云平臺(tái)的推廣，云計(jì)算已被認(rèn)為是繼大型計(jì)算機(jī)、個(gè)人計(jì)算機(jī)、互聯(lián)網(wǎng)之后的又一次IT產(chǎn)業(yè)革命。

安全問(wèn)題一直是云計(jì)算面臨的最重要挑戰(zhàn)之一，如數(shù)據(jù)泄密、服務(wù)可用性、拒絕服務(wù)攻擊等[1,2]。雖然云計(jì)算因其良好的可擴(kuò)展性被稱(chēng)為彈性計(jì)算，但當(dāng)大量服務(wù)請(qǐng)求在同一時(shí)間到達(dá)時(shí)仍可能耗盡云計(jì)算平臺(tái)中的所有資源。此時(shí)若有新的請(qǐng)求，特別是重要用戶(hù)的請(qǐng)求到達(dá)時(shí)，將無(wú)法得到滿(mǎn)足?？紤]到投資回報(bào)，絕大多數(shù)云計(jì)算平臺(tái)都不會(huì)長(zhǎng)期維持大量的空閑資源，因此這種服務(wù)可用性的威脅無(wú)論在商業(yè)云還是私有云中都是常見(jiàn)的[3,4]。

為了應(yīng)對(duì)這種服務(wù)可用性威脅，價(jià)格調(diào)控與資源預(yù)留是2種主要的手段。價(jià)格調(diào)控存在于絕大多數(shù)商業(yè)云中。服務(wù)商根據(jù)當(dāng)前的資源緊張程度動(dòng)態(tài)調(diào)整服務(wù)價(jià)格，使供需保持相對(duì)的平衡，減少資源耗盡的危險(xiǎn)。例如在Amazon EC2中，服務(wù)商推出了按需支付(on-demand instance)服務(wù)、預(yù)約支付(reserved instance)服務(wù)、競(jìng)價(jià)支付(spot instance)服務(wù)3種不同的收費(fèi)服務(wù)模式[5]。資源預(yù)留策略存在于各種云平臺(tái)中。在一些私有云中，由于服務(wù)是免費(fèi)的，價(jià)格調(diào)控?zé)o法進(jìn)行，資源預(yù)留成為保障重要用戶(hù)服務(wù)可用性的主要手段[6]。由于用戶(hù)需求的不可知性，預(yù)留的資源過(guò)多可能造成浪費(fèi)，預(yù)留的資源過(guò)少又可能無(wú)法滿(mǎn)足用戶(hù)需求。在文獻(xiàn)[7]中，用戶(hù)提前向云計(jì)算服務(wù)商預(yù)訂可能用到的資源，服務(wù)商收集這些用戶(hù)的需求后，通過(guò)資源新增、任務(wù)調(diào)度等手段，保證特定時(shí)間的資源可用性。由于用戶(hù)通常很難回答“什么時(shí)間、需要多少資源”，這種策略可能有一定的局限性。

文獻(xiàn)[6]指出，“在沒(méi)有價(jià)格調(diào)控的情況下，如何既保證重要用戶(hù)的請(qǐng)求得到滿(mǎn)足，又不因資源過(guò)度預(yù)留而造成浪費(fèi)，是云計(jì)算中的重要挑戰(zhàn)之一”。本文提出了一種云計(jì)算中的服務(wù)可用性保障機(jī)制——基于滑動(dòng)窗口的資源預(yù)留(SWRR,sliding window based resource reservation)算法。它將云平臺(tái)用戶(hù)提交的任務(wù)分為普通任務(wù)與重要任務(wù)(VIP任務(wù))。SWRR的基本思想是：在云計(jì)算平臺(tái)中為VIP任務(wù)預(yù)留一定數(shù)量的優(yōu)秀資源，并將這部分優(yōu)秀資源在整個(gè)資源池中所占的比例稱(chēng)為窗口。窗口的“滑動(dòng)”包含 2層含義：1）窗口大小動(dòng)態(tài)變化，即在VIP任務(wù)增加時(shí)擴(kuò)大窗口以保證優(yōu)先調(diào)度，在VIP任務(wù)減少時(shí)縮小窗口以減少資源浪費(fèi)；2）窗口內(nèi)容動(dòng)態(tài)刷新，即每隔一段時(shí)間會(huì)評(píng)估窗口中的預(yù)留資源，淘汰差的資源，引入新的優(yōu)秀資源。

SWRR已被應(yīng)用于一個(gè)大型的云計(jì)算應(yīng)用平臺(tái)iVCE中，如圖1所示。目前，該平臺(tái)包含分布于全國(guó)各地的300多臺(tái)物理機(jī)，可支持每天百萬(wàn)級(jí)的任務(wù)吞吐量。平臺(tái)中用戶(hù)每天提交的任務(wù)數(shù)隨時(shí)間的波動(dòng)很大且很難預(yù)測(cè)，在高峰時(shí)段大量的用戶(hù)請(qǐng)求可能相互搶占資源，平臺(tái)的服務(wù)可用性變差。為了體現(xiàn)差分服務(wù)的特點(diǎn)，iVCE授予某些用戶(hù)提交VIP任務(wù)的權(quán)限，并采用SWRR優(yōu)先調(diào)度。實(shí)際運(yùn)行結(jié)果表明，SWRR可以保證VIP任務(wù)的服務(wù)等待時(shí)間（一般小于5 s）遠(yuǎn)小于普通任務(wù)（平均約60 s），保障重要用戶(hù)的服務(wù)可用性。

圖1 SWRR算法示意

由于在實(shí)際環(huán)境中直接調(diào)試 SWRR參數(shù)可能影響平臺(tái)穩(wěn)定性，本文實(shí)現(xiàn)了一個(gè)SWRR仿真器，并通過(guò)多方面的分析比較，論證 SWRR在資源預(yù)留、保障重要用戶(hù)服務(wù)可用性方面的優(yōu)勢(shì)。

2 基于滑動(dòng)窗口的資源預(yù)留算法

2.1 資源的定義

云計(jì)算平臺(tái)中可用的資源集合記為Φ={ri| i=1,2,…,n}，該集合動(dòng)態(tài)變化。對(duì)每一個(gè)資源ri，定義資源評(píng)價(jià)函數(shù)V(ri)為ri在過(guò)去一段時(shí)間內(nèi)的任務(wù)執(zhí)行成功率，V(ri)越大表示ri越優(yōu)秀。

SWRR算法將Φ劃分為普通資源池Φbase與預(yù)留資源池Φresv，分別存放普通資源與預(yù)留資源。初始時(shí)，Φbase=Φ，Φresv為空。

2.2 任務(wù)的定義

云計(jì)算平臺(tái)中需調(diào)度的任務(wù)集合記為Ψ={tj| j=1,2,…,m}，該集合動(dòng)態(tài)變化。對(duì)每一個(gè)任務(wù)tj，令I(lǐng)(tj)表示任務(wù)tj的重要程度，若I(tj)=true，表示tj為VIP任務(wù)；否則，為普通任務(wù)。

任務(wù)分為z個(gè)優(yōu)先級(jí)，記為Z={1,2,…,z}。對(duì)每一個(gè)任務(wù) tj，令 P(tj)表示任務(wù) tj的優(yōu)先級(jí)，則優(yōu)先級(jí)為k的任務(wù)集合記為Ψk={tj|P(tj)=k,k∈Z}。任務(wù)集合 Ψk中的任務(wù)按先入先出（FIFO）算法組成隊(duì)列，任務(wù)從隊(duì)首開(kāi)始調(diào)度。

2.3 SWRR算法

根據(jù)任務(wù)優(yōu)先級(jí)的不同，用戶(hù)提交的任務(wù)被保存在相應(yīng)的任務(wù)隊(duì)列Ψk中，并按照FIFO的順序進(jìn)行調(diào)度。SWRR算法包括任務(wù)調(diào)度與窗口滑動(dòng)2個(gè)階段，如算法1所示。

在算法的任務(wù)調(diào)度階段，采用“輪盤(pán)賭”選擇需要調(diào)度的任務(wù)隊(duì)列Ψk，并且優(yōu)先級(jí)k越大的隊(duì)列被選中的概率越大。如果任務(wù)tj為VIP任務(wù)，優(yōu)先在預(yù)留資源池 Φresv中查找資源，在Φresv查找失敗后繼續(xù)在Φbase中查找；如果任務(wù)tj為普通任務(wù)，則僅在Φbase中查找資源。標(biāo)志位 fbase、fresv反映當(dāng)前的資源池狀態(tài)。當(dāng)Φbase資源不足時(shí)，fbase=false；當(dāng)Φresv資源不足時(shí)，fresv=false。

在算法的窗口滑動(dòng)階段，根據(jù)標(biāo)志位fbase、fresv調(diào)整滑動(dòng)窗口大小ω。如果預(yù)留資源池Φresv資源不足，則擴(kuò)大滑動(dòng)窗口；如果預(yù)留資源池Φresv資源充足并且普通資源池Φbase資源不足，則縮小滑動(dòng)窗口；否則窗口大小不變。系統(tǒng)預(yù)設(shè)滑動(dòng)窗口的最大值 ωmax、最小值 ωmin，ω∈[ωmin,ωmax]。在每一個(gè)調(diào)度周期結(jié)束后，根據(jù)V(ri)重新評(píng)估所有資源，并將 Φresv中最差的部分資源與 Φbase中最優(yōu)秀的部分資源互換，以保證Φresv始終維持最優(yōu)秀的資源。

算法1 SWRR算法

給定資源集合Φ，任務(wù)集合Ψ，滑動(dòng)窗口大小ω。給定常數(shù)：滑動(dòng)窗口的最大值ωmax、最小值ωmin，窗口調(diào)整步長(zhǎng)ω'∈(0,1)，資源交換率λ∈(0,1)。初始時(shí)，令 ω=ωmin。

在每一個(gè)任務(wù)調(diào)度周期，進(jìn)行如下步驟。

1)初始化標(biāo)志位fbase=true，fresv=true。

2)采用“輪盤(pán)賭”算法選取一個(gè)需要調(diào)度的任務(wù)隊(duì)列 Ψk（k∈Z）。

3)從Ψk中取出第一個(gè)需要調(diào)度的任務(wù)tj。

① 若tj為VIP任務(wù)，即I(tj)=true，則從Φresv中選取若干符合 tj條件的資源組成備選資源池Φ(tj)。

若Φ(tj)非空，從Φ(tj)中隨機(jī)選取資源ri，將tj下發(fā)到資源ri上執(zhí)行，然后轉(zhuǎn)步驟4)。

若Φ(tj)為空，設(shè)置fresv=false，并將tj當(dāng)成普通任務(wù)繼續(xù)步驟3)中的②。

② 從Φbase中選取若干符合tj條件的資源組成備選資源池Φ(tj)。

若Φ(tj)非空，從Φ(tj)中隨機(jī)選取資源ri，將tj下發(fā)到資源ri上執(zhí)行，然后轉(zhuǎn)步驟4)。

若Φ(tj)為空，設(shè)置fbase=false，增加tj的調(diào)度失敗次數(shù)，將tj放回Ψk，然后轉(zhuǎn)步驟4)。

4)循環(huán)進(jìn)行步驟2)、步驟3)，直到本次調(diào)度時(shí)間結(jié)束，或者所有任務(wù)隊(duì)列都沒(méi)有需調(diào)度的任務(wù)。

5)確定新的滑動(dòng)窗口大小ω。

① 若 fresv=false，則設(shè)置 ω=min(ωmax,ω+ω')。

② 若fresv=true并且fbase=false，則設(shè)置ω=max(ωmin,ω-ω')。

③ 否則ω不變。

6)令 a=|Φbase|表示普通資源數(shù)，b=|Φresv|表示預(yù)留資源數(shù)。從Φresv中選擇V(ri)評(píng)價(jià)最差的λb個(gè)資源，從 Φbase中選擇 V(ri)評(píng)價(jià)最優(yōu)的 max{(a+b)ω?(b?λb),0}個(gè)資源，對(duì)以上兩部分資源互換。

在算法1中，如果找不到合適的資源，任務(wù)tj調(diào)度失敗后將重新被放回隊(duì)列Ψk中。為了避免同一個(gè)任務(wù)不斷地被選中調(diào)度，當(dāng)任務(wù)tj調(diào)度失敗后，它將等待一定時(shí)間才能被再次調(diào)度，并且等待時(shí)間隨著調(diào)度失敗次數(shù)的增長(zhǎng)而指數(shù)遞增。

SWRR算法具有如下特點(diǎn)。

1)自適應(yīng)地資源預(yù)留。通過(guò)滑動(dòng)窗口大小調(diào)整與資源交換，始終維持合適的預(yù)留資源，保證VIP任務(wù)的調(diào)度。

2)兼顧所有任務(wù)調(diào)度。通過(guò)限制滑動(dòng)窗口大小ω∈[ωmin,ωmax]，保證普通任務(wù)的調(diào)度；通過(guò)“輪盤(pán)賭”算法，低優(yōu)先級(jí)的任務(wù)也有被調(diào)度的概率。

3)對(duì) VIP任務(wù)突發(fā)性激增的適應(yīng)性。算法中滑動(dòng)窗口調(diào)整到合適的位置需要一定的時(shí)間，為保證服務(wù)質(zhì)量，若VIP任務(wù)暫時(shí)在Φresv中找不到資源時(shí)，將繼續(xù)在Φbase中尋找。

3 仿真實(shí)驗(yàn)

本文實(shí)現(xiàn)了一個(gè)SWRR仿真器，并通過(guò)多方面的分析比較，論證SWRR在資源預(yù)留、保障重要用戶(hù)服務(wù)可用性方面的優(yōu)勢(shì)。實(shí)驗(yàn)中，SWRR參數(shù)采用與云計(jì)算平臺(tái)iVCE中相同的設(shè)置，即滑動(dòng)窗口最小值ωmin=0.2、最大值ωmax=0.6，窗口調(diào)整步長(zhǎng)ω'=0.02，資源交換率λ=0.2。在本節(jié)最后，會(huì)進(jìn)一步討論這些值的選擇依據(jù)。

仿真中最大資源數(shù)|Φ|=1000，每個(gè)資源的性能在資源初始化時(shí)隨機(jī)生成，該指標(biāo)將影響任務(wù)的執(zhí)行時(shí)間與執(zhí)行成功率。實(shí)驗(yàn)通過(guò)一個(gè)任務(wù)生成器，每秒生成一定數(shù)目的 VIP任務(wù)與普通任務(wù)，以模擬用戶(hù)提交任務(wù)的行為。每個(gè)任務(wù)在生成時(shí)會(huì)附帶一個(gè)截止時(shí)間的屬性，如果任務(wù)在截止時(shí)間到達(dá)時(shí)仍沒(méi)有執(zhí)行完成，將標(biāo)識(shí)為失敗，并以此統(tǒng)計(jì)任務(wù)執(zhí)行成功率。任務(wù)在截止之前，如果沒(méi)有找到合適的資源，它將處于等待狀態(tài)，并以此統(tǒng)計(jì)任務(wù)等待時(shí)間。

仿真器運(yùn)行于Linux平臺(tái)。實(shí)驗(yàn)在運(yùn)行穩(wěn)定后，截取其中的60 min，并分析其結(jié)果。

3.1 SWRR算法性能

圖2（a）給出了實(shí)驗(yàn)中每分鐘的任務(wù)提交情況。參考云計(jì)算平臺(tái)iVCE的任務(wù)提交行為，實(shí)驗(yàn)分別模擬了普通任務(wù)突發(fā)性激增（第10～11 min）、VIP任務(wù)突發(fā)性激增（第20～21 min）、普通任務(wù)與VIP任務(wù)持續(xù)高負(fù)載（第30～45 min）的情況。

實(shí)驗(yàn)可以分為5個(gè)階段。

第0～10 min為第1階段。此時(shí)系統(tǒng)資源足夠，可處理所有的普通任務(wù)與VIP任務(wù)，系統(tǒng)處于平穩(wěn)運(yùn)行狀態(tài)，滑動(dòng)窗口ω約為0.24，如圖2(b)所示。

圖2 VIP任務(wù)與普通任務(wù)的運(yùn)行比較

第10～20 min為第2階段。在第11 min，普通任務(wù)出現(xiàn)激增，如圖 2(a)所示，普通資源池 Φbase出現(xiàn)資源不足，滑動(dòng)窗口ω降為最小值0.2，如圖2(b)所示，以盡可能減少預(yù)留資源占用。但Φbase仍不能滿(mǎn)足需要，大量普通任務(wù)的等待時(shí)間增加，如圖 2(c)所示，執(zhí)行成功率下降，如圖 2(e)所示。在這個(gè)階段，VIP任務(wù)的執(zhí)行未受影響。在接近20 min時(shí)，系統(tǒng)再次趨于平穩(wěn)狀態(tài)。

第20～30 min為第3階段。在第21 min，VIP任務(wù)出現(xiàn)激增，如圖2(a)所示，預(yù)留資源池Φresv出現(xiàn)資源不足，滑動(dòng)窗口 ω迅速升為最大值 0.6，如圖2(b)所示。大量的VIP任務(wù)導(dǎo)致了任務(wù)等待時(shí)間的少量增加，如圖2(c)所示，但VIP任務(wù)的執(zhí)行成功率基本沒(méi)有變化。在這個(gè)階段，雖然普通任務(wù)在數(shù)量上沒(méi)有變化，但滑動(dòng)窗口調(diào)整導(dǎo)致普通資源池 Φbase變小，因此仍然對(duì)普通任務(wù)的等待時(shí)間、執(zhí)行成功率造成影響，分別如圖2(c)、圖2(e)所示。

第30～45 min為第4階段。在這個(gè)階段，普通任務(wù)與VIP任務(wù)先后出現(xiàn)了增長(zhǎng)，并持續(xù)了較長(zhǎng)時(shí)間，如圖2(a)所示，導(dǎo)致系統(tǒng)中的資源嚴(yán)重不足。為了優(yōu)先滿(mǎn)足VIP任務(wù)的調(diào)度，滑動(dòng)窗口最終穩(wěn)定在0.4左右，如圖 2(b)所示。在這個(gè)過(guò)程中，VIP任務(wù)的執(zhí)行基本沒(méi)有受到影響，但普通任務(wù)的等待時(shí)間、執(zhí)行成功率均受到了嚴(yán)重影響，分別如圖2(c)、圖2(e)所示。

第45～60 min為第5階段。隨著提交的任務(wù)數(shù)量回到正常水平，系統(tǒng)又回到平穩(wěn)狀態(tài)。

在圖2展示的整個(gè)實(shí)驗(yàn)過(guò)程中，用戶(hù)提交的任務(wù)數(shù)隨時(shí)間波動(dòng)很大，SWRR算法與資源池大小固定的算法相比的優(yōu)勢(shì)在于，它通過(guò)動(dòng)態(tài)窗口滑動(dòng)，合理資源預(yù)留，始終保證VIP任務(wù)一個(gè)較穩(wěn)定的任務(wù)等待時(shí)間與執(zhí)行成功率。

從圖2(d)進(jìn)一步看出，VIP任務(wù)的執(zhí)行時(shí)間明顯小于普通任務(wù)。這是因?yàn)镾WRR算法通過(guò)資源交換，在預(yù)留資源池中維持了最優(yōu)秀的資源。作為證明，圖3給出了第5 min、第21 min時(shí)的滑動(dòng)窗口快照。資源評(píng)分通過(guò)函數(shù)資源評(píng)價(jià)函數(shù)V(ri)得到，它反映了資源在過(guò)去一段時(shí)間內(nèi)的任務(wù)執(zhí)行成功率。從圖3可以看出，SWRR算法總是將系統(tǒng)中評(píng)分最高的那些資源作為預(yù)留資源。

3.2 資源負(fù)載率

通過(guò)預(yù)留足夠多的資源，一些靜態(tài)的資源預(yù)留算法也能保證VIP任務(wù)的調(diào)度。文獻(xiàn)[6]指出一個(gè)優(yōu)秀的資源預(yù)留算法不僅要保證 VIP任務(wù)的及時(shí)調(diào)度，而且要減少資源浪費(fèi)。圖4給出了在上述實(shí)驗(yàn)過(guò)程中，普通資源池與VIP資源池的資源負(fù)載情況。

圖3 滑動(dòng)窗口快照

圖4 資源負(fù)載率

對(duì)比圖2(e)和圖4可以看出，在資源不足而導(dǎo)致任務(wù)執(zhí)行成功率下降的第12～15 min、第22～25 min、第35～45 min，僅在第12～15 min預(yù)留資源池的負(fù)載率未接近 100%，即存在一定的資源空閑。造成此現(xiàn)象的原因是在第12 min時(shí)，滑動(dòng)窗口已達(dá)到最小值，如圖2（b）所示，無(wú)法進(jìn)一步縮小以將資源用于普通任務(wù)的調(diào)度，因此這不是SWRR算法本身的缺陷。

在實(shí)際部署時(shí)，滑動(dòng)窗口最小值、最大值的設(shè)置都需要考慮具體的應(yīng)用場(chǎng)景。窗口最小值設(shè)置過(guò)大可能造成資源浪費(fèi)，設(shè)置過(guò)小可能瞬間不能適應(yīng)VIP任務(wù)的激增；窗口最大值設(shè)置過(guò)小可能不能為VIP任務(wù)預(yù)留足夠的資源，設(shè)置過(guò)大可能瞬間不能適應(yīng)普通任務(wù)的激增。由于 SWRR算法可以自適應(yīng)調(diào)整窗口大?。ǖ枰欢ǖ臅r(shí)間），在應(yīng)用場(chǎng)景不能確定時(shí)，可以設(shè)置一個(gè)較小的最小值、較大的最大值。另外，窗口調(diào)整步長(zhǎng)、資源交換率實(shí)際反映了算法的響應(yīng)速度與調(diào)整粒度，一般來(lái)說(shuō)，對(duì)于任務(wù)波動(dòng)較大的場(chǎng)景，可以選擇較大的窗口調(diào)整步長(zhǎng)、資源交換率。

4 結(jié)束語(yǔ)

本文提出了一種云計(jì)算中的服務(wù)可用性保障機(jī)制——基于滑動(dòng)窗口的資源預(yù)留算法。通過(guò)動(dòng)態(tài)窗口滑動(dòng)、合理資源預(yù)留，SWRR算法在兼顧所有任務(wù)調(diào)度的基礎(chǔ)上，重點(diǎn)提升VIP任務(wù)的調(diào)度效率與執(zhí)行成功率，保障重要用戶(hù)的服務(wù)可用性。

SWRR算法已被應(yīng)用于一個(gè)大型的云計(jì)算平臺(tái)iVCE中。接下來(lái)的工作主要包括算法執(zhí)行效率的優(yōu)化，并對(duì)算法在實(shí)際系統(tǒng)中的性能進(jìn)行更深入分析。

[1]SUBASHINI S,KAVITHA V. A survey on security issues in service delivery models of cloud computing[J]. Journal of Network and Computer Applications,2011,34(1): 1-11.

[2]CARLIN S,CURRAN K. Cloud computing security[J]. International Journal of Ambient Computing and Intelligence (IJACI),2011,3(1):14-19.

[3]PAWAR C S,WAGH R B. A review of resource allocation policies in cloud computing[J]. World Journal of Science and Technology,2012,2(3):165-167.

[4]ENDO P T,DE ALMEIDA PALHARES A V,PEREIRA N N,et al.Resource allocation for distributed cloud: concepts and research challenges[J]. Network,IEEE,2011,25(4): 42-46.

[5]Amazon elastic compute cloud(EC2)[EB/OL]. http://aws.amazon.com/ec2/.

[6]SEMPOLINSKI P,THAIN D. A comparison and critique of eucalyptus,opennebula and nimbus[A]. IEEE 2nd Int Conf on Cloud Computing Technology and Science[C]. Indianapolis,2010.417-426.

[7]FUNKE D,BROSIG F,FABER M. Towards truthful resource reservation in cloud computing[A]. IEEE Int Conf on Performance Evaluation Methodologies and Tools[C]. Cargese,2012.253-262.