張 靜

(常州信息職業(yè)技術(shù)學(xué)院 江蘇 常州 213164)

0 引 言

云計(jì)算將傳統(tǒng)的計(jì)算能力獲取模式轉(zhuǎn)變?yōu)楫?dāng)前的服務(wù)租用模式[1]，基于資源的實(shí)際使用情況，按需以即付即用的彈性服務(wù)利用方式向用戶提供資源。云數(shù)據(jù)中心是云服務(wù)的支撐基礎(chǔ)設(shè)施。為了滿足巨量規(guī)模云服務(wù)不斷增長(zhǎng)的計(jì)算需求，數(shù)據(jù)中心需要配置數(shù)以千計(jì)的服務(wù)器。然而，數(shù)據(jù)中心同時(shí)需要消耗巨大的能量提供云服務(wù)。根據(jù)美國(guó)能源部的報(bào)告[2]，美國(guó)的數(shù)據(jù)中心消耗了其國(guó)家總能量的2%(約7×1010kWh)。數(shù)據(jù)中心不僅消耗能量，同時(shí)還會(huì)產(chǎn)生巨量的溫室氣體，導(dǎo)致很高的碳排放。具體地，每年有430億噸CO2排放，每季度在以13%的速度增長(zhǎng)[3-4]。因此，改進(jìn)數(shù)據(jù)中心的能效對(duì)于云計(jì)算的可持續(xù)發(fā)展和營(yíng)運(yùn)代價(jià)將是至關(guān)重要的。

云數(shù)據(jù)中心的主要能耗來(lái)源于計(jì)算系統(tǒng)和冷卻系統(tǒng)，基本上，冷卻系統(tǒng)的能耗等于計(jì)算系統(tǒng)的能耗[5]。因此，數(shù)據(jù)中心資源管理系統(tǒng)需要同步考慮計(jì)算和冷卻系統(tǒng)，從而實(shí)現(xiàn)全局整體能效的改進(jìn)。

為了降低計(jì)算能耗，將負(fù)載合并至更少的主機(jī)上是一種有效方法，這樣可以保持未使用的主機(jī)處于低功能狀態(tài)[6-9]。然而，這種激進(jìn)的合并可能導(dǎo)致局部熱點(diǎn)的產(chǎn)生。熱點(diǎn)主機(jī)的產(chǎn)生對(duì)于整個(gè)數(shù)據(jù)中心系統(tǒng)的可靠性具有很大的不利影響[10]。此外，若超過(guò)主機(jī)的溫度閾值也會(huì)導(dǎo)致CPU硅組成的損壞，進(jìn)而導(dǎo)致主機(jī)的失效。為了進(jìn)一步解決散熱問(wèn)題，冷卻系統(tǒng)會(huì)傳輸很多的冷空氣進(jìn)而增加冷卻系統(tǒng)的代價(jià)。而通過(guò)最優(yōu)的負(fù)載分布的熱量管理方法可以有效避免熱點(diǎn)出現(xiàn)，并同步降低數(shù)據(jù)中心的能耗。

數(shù)據(jù)中心的溫度變化也與多個(gè)因素相關(guān)。首先，主機(jī)功耗所揮發(fā)的熱量會(huì)分布至數(shù)據(jù)中心環(huán)境中[11]，這種功耗與資源的利用率是成正比的。其次，機(jī)房空調(diào)系統(tǒng)CRAC所提供的冷空氣本身也會(huì)攜帶一定溫度，即所謂的供冷溫度。最后，主機(jī)的入口溫度具有時(shí)空現(xiàn)象[12]。從一臺(tái)主機(jī)所揮發(fā)的熱量會(huì)影響其他主機(jī)的溫度。由于熱空氣熱力學(xué)的特征，這種熱量會(huì)在數(shù)據(jù)中心內(nèi)循環(huán)存在。經(jīng)過(guò)主機(jī)的空氣并不會(huì)完全到達(dá)回流口，部分仍將留在主機(jī)所在空間。解決這種時(shí)空特征也可以優(yōu)化能量使用。

此外，估算數(shù)據(jù)中心溫度也有一定難度。目前主要有三種方法：(1) 計(jì)算流體動(dòng)態(tài)模型進(jìn)行精確預(yù)測(cè)[13]，這種方法固有的復(fù)雜性使其應(yīng)用在實(shí)時(shí)在線調(diào)度問(wèn)題上計(jì)算代價(jià)太高；(2) 利用如機(jī)器學(xué)習(xí)的預(yù)測(cè)模型，這種方法極大地依賴于預(yù)測(cè)模型和數(shù)據(jù)的數(shù)量和質(zhì)量；(3) 分析模型，主要根據(jù)熱量的熱力學(xué)特征和數(shù)據(jù)中心的物理屬性進(jìn)行預(yù)測(cè)。

動(dòng)態(tài)虛擬機(jī)合并是數(shù)據(jù)中心節(jié)省能耗的有效手段，而這些合并算法對(duì)于實(shí)體布局和物理主機(jī)的位置并不可知。進(jìn)一步，由于數(shù)據(jù)中心內(nèi)部溫度的分布，將負(fù)載合并至較少的主機(jī)上并不一定會(huì)節(jié)省能耗，這可能導(dǎo)致冷卻系統(tǒng)的代價(jià)升高和創(chuàng)建一些熱點(diǎn)主機(jī)，但部分合并的確能解決部分能耗問(wèn)題。

相關(guān)研究中，文獻(xiàn)[7]設(shè)計(jì)了一種功耗感知的PABFD算法。該算法是一種基于功耗感知的修改最佳適應(yīng)算法，但僅僅考慮了合并過(guò)程中的CPU利用率，并沒(méi)有考慮虛擬機(jī)合并和部署過(guò)程的主機(jī)熱量問(wèn)題。文獻(xiàn)[14]在異構(gòu)數(shù)據(jù)中心中提出一種功耗和溫度感知的負(fù)載分配算法，但算法中沒(méi)有對(duì)空調(diào)系統(tǒng)的制冷模型進(jìn)行建模和考慮，導(dǎo)致最終的負(fù)載分配得到的能耗并不是全局最佳的。文獻(xiàn)[15]提出基于DVFS的對(duì)偶時(shí)空感知的作業(yè)調(diào)度算法，但是這些方案均不能直接應(yīng)用于虛擬云數(shù)據(jù)中心中。文獻(xiàn)[16]提出一種GRANITE算法，該算法是一種以最小化數(shù)據(jù)中心能耗為目標(biāo)的貪婪虛擬機(jī)調(diào)度算法，可以動(dòng)態(tài)地進(jìn)行虛擬機(jī)遷移，從而將負(fù)載均勻分配，使主機(jī)溫度在確定的溫度閾值以內(nèi)。然而，貪婪算法的尋優(yōu)解雖然可以控制主機(jī)溫度不超過(guò)閾值，但實(shí)際溫度距離閾值仍有距離，即主機(jī)利用率并未達(dá)到最優(yōu)，總體能耗仍有下降的余地。文獻(xiàn)[17]提出了一種TAS算法，該算法是一種溫度感知調(diào)度算法，所選目標(biāo)主機(jī)是溫度最低的主機(jī)。文獻(xiàn)[18]設(shè)計(jì)了一種二階段啟發(fā)式虛擬機(jī)部署算法，先降低主機(jī)利用數(shù)量，再進(jìn)行虛擬機(jī)遷移。文獻(xiàn)[19]提出一種能耗與性能協(xié)調(diào)的虛擬機(jī)重部署方法，同樣使用了與上文類(lèi)似的裝箱思想對(duì)主機(jī)利用數(shù)量進(jìn)行優(yōu)化。以上兩篇文獻(xiàn)的問(wèn)題在于僅僅以最小化主機(jī)使用量來(lái)降低總體能耗，沒(méi)有考慮冷卻系統(tǒng)帶來(lái)的能耗問(wèn)題，因此最終能耗并不一定是最優(yōu)的。

本文使用溫度狀態(tài)的分析模型提出一種基于動(dòng)態(tài)虛擬機(jī)合并的在線調(diào)度算法，同步考慮主機(jī)能量利用和冷卻系統(tǒng)的能耗問(wèn)題，利用貪婪隨機(jī)自適應(yīng)搜索機(jī)制求解能效更高的虛擬機(jī)合理部署方案，并通過(guò)在實(shí)際負(fù)載下的一系列仿真實(shí)驗(yàn)，驗(yàn)證算法在能效提高和性能提升上的優(yōu)勢(shì)。

1 系統(tǒng)模型

表1為本文涉及的主要符號(hào)和說(shuō)明。

表1 參數(shù)說(shuō)明

1.1 主機(jī)模型

數(shù)據(jù)中心由若干具有不同處理能力的異構(gòu)主機(jī)組成，主機(jī)功耗主要由其資源利用等級(jí)決定，本文利用以下的線性功耗模型：

(1)

1.2 溫度模型

(2)

考慮到在數(shù)據(jù)中心內(nèi)部以及主機(jī)的物理機(jī)架部署情況下熱量再循環(huán)的存在，本文將這種熱量再循環(huán)的影響量化為一種熱量分布矩陣D，每個(gè)元素di,k表示主機(jī)i對(duì)主機(jī)k的進(jìn)氣溫度的影響因子，這種影響因子為主機(jī)k的功耗Pk(t)的數(shù)量級(jí)。由式(2)可知，盡管機(jī)房空調(diào)系統(tǒng)CRAC能夠傳送類(lèi)似的冷氣溫度至所有數(shù)據(jù)中心內(nèi)的主機(jī)，但每個(gè)主機(jī)由于其物理位置不同和熱量再循環(huán)的影響，其進(jìn)氣溫度依然是變化的。

主機(jī)i的CPU溫度由其CPU的散熱決定，根據(jù)RC模型可定義時(shí)間t時(shí)的溫度為：

(3)

式中：e為自然常數(shù)，Tinitial為CPU初始溫度。根據(jù)式(3)可知，主機(jī)CPU溫度不僅由功耗控制(主要因素，正比于CPU速率或負(fù)載級(jí)別)，還由硬件特定量R和C以及進(jìn)氣溫度決定，說(shuō)明式(3)所使用的CPU溫度分析模型可以捕捉主機(jī)溫度的動(dòng)態(tài)行為。

1.3 機(jī)房空調(diào)系統(tǒng)CRAC模型

數(shù)據(jù)中心的熱量管理主要由機(jī)房空調(diào)系統(tǒng)CRAC進(jìn)行。現(xiàn)代數(shù)據(jù)中心中，機(jī)架通常安排在通風(fēng)口，冷空氣從機(jī)架底部向上流通。假設(shè)數(shù)據(jù)中心由多個(gè)CRAC單元組成，表示為CRAC={CRAC1,CRAC2,…,CRACn}?？紤]CRAC為數(shù)據(jù)中心內(nèi)唯一可用的冷卻來(lái)源。這種冷卻系統(tǒng)的效率以性能度量系數(shù)CoP進(jìn)行度量。CoP是冷氣提供溫度Tsup的函數(shù)，定義為計(jì)算系統(tǒng)的總體功耗與冷卻系統(tǒng)的總功耗之比：

(4)

數(shù)據(jù)中心的CoP對(duì)于不同的數(shù)據(jù)中心環(huán)境配置也不相同，它取決于物理布局及數(shù)據(jù)中心熱力學(xué)特征。本文使用HP Lab數(shù)據(jù)中心的性能度量模型：

(5)

式(5)表明，通過(guò)增加Tsup值，可以增加冷卻系統(tǒng)的效率和降低冷卻功耗。

1.4 負(fù)載模型

用戶向云數(shù)據(jù)中心發(fā)送的請(qǐng)求可考慮為任務(wù)形式，假設(shè)n為任務(wù)總量，也可理解為任務(wù)執(zhí)行請(qǐng)求n個(gè)虛擬機(jī)，將其表示為VM={VM1,VM2,…,VMn}。根據(jù)虛擬機(jī)建立負(fù)載模型，每個(gè)虛擬機(jī)可執(zhí)行單個(gè)任務(wù)，每個(gè)任務(wù)擁有CPU請(qǐng)求Rcpu、內(nèi)存請(qǐng)求Rmem、任務(wù)長(zhǎng)度l。因此，每個(gè)任務(wù)可表達(dá)為三元組{Rcpu,Rmem,l}。為了解決動(dòng)態(tài)虛擬機(jī)合并問(wèn)題，實(shí)驗(yàn)中將一次性發(fā)送所有任務(wù)請(qǐng)求，在每個(gè)間隔中利用調(diào)度策略進(jìn)行動(dòng)態(tài)的虛擬機(jī)合并和部署，并分析算法性能。

2 能量和熱量感知的虛擬機(jī)合并

2.1 問(wèn)題描述

數(shù)據(jù)中心能耗主要產(chǎn)生于計(jì)算和冷卻系統(tǒng)，計(jì)算系統(tǒng)由主機(jī)構(gòu)成，其能耗可定義為：

(6)

根據(jù)式(6)計(jì)算系統(tǒng)能耗為所有主機(jī)能耗之和。變量xj表示：若主機(jī)j為活躍狀態(tài)，則其值為1；否則為0。計(jì)算系統(tǒng)的能耗由所有活躍主機(jī)能耗組成，因此，在每個(gè)調(diào)度間隔中優(yōu)化活躍主機(jī)的數(shù)量是至關(guān)重要的。

冷卻系統(tǒng)CRAC能耗定義為熱負(fù)荷與數(shù)據(jù)中心CoP之比?？紤]到計(jì)算系統(tǒng)能耗基本隨著熱量消散至數(shù)據(jù)中心的周?chē)h(huán)境，可將熱負(fù)荷表示為PC。因此，冷卻系統(tǒng)能耗可定義為：

(7)

式中：ThermalLoad表示熱負(fù)荷。

根據(jù)式(7)，冷卻系統(tǒng)能耗可通過(guò)增加CRAC提供的冷氣溫度或降低熱負(fù)荷的方式降低。因此，通過(guò)虛擬機(jī)合并，可以降低數(shù)據(jù)中心熱負(fù)荷，并同步在給定冷氣溫度下主動(dòng)地避免產(chǎn)生熱點(diǎn)主機(jī)。數(shù)據(jù)中心總體能耗表示為：

(8)

虛擬機(jī)部署與合并算法需要同步感知計(jì)算系統(tǒng)和冷卻系統(tǒng)能耗，由于過(guò)多虛擬機(jī)合并會(huì)導(dǎo)致熱點(diǎn)主機(jī)，而負(fù)載過(guò)于分散又會(huì)導(dǎo)致過(guò)高的能耗。因此，本文的最優(yōu)化問(wèn)題可定義為：

目標(biāo)函數(shù)：

(9)

約束條件：

u(hi)≤Umax

(10)

Ti(t)≤Tred

(11)

(12)

xj∈{0,1}

(13)

式(9)為最小化數(shù)據(jù)中心總體能耗；式(10)確保主機(jī)利用率需小于或等于占用閾值；式(11)確保主機(jī)溫度需小于或等于最高溫度閾值；式(12)確保主機(jī)必須具有滿足需求的CPU和內(nèi)存資源才可以進(jìn)行虛擬機(jī)部署，即能力約束；xj為二進(jìn)制變量，若虛擬機(jī)部署于主機(jī)i，則取值為1，否則為0?？紤]到目標(biāo)函數(shù)最優(yōu)化求解在一定規(guī)模的數(shù)據(jù)中心內(nèi)是一個(gè)NP問(wèn)題，本文將設(shè)計(jì)一種基于貪婪隨機(jī)自適應(yīng)搜索機(jī)制GRASP的啟發(fā)式算法進(jìn)行虛擬機(jī)能效部署求解，并以合理的時(shí)間復(fù)雜度得到近似最優(yōu)解。

2.2 算法設(shè)計(jì)

本節(jié)設(shè)計(jì)基于貪婪隨機(jī)自適應(yīng)搜索機(jī)制GRASP的虛擬機(jī)部署算法。GRASP是一種迭代式隨機(jī)優(yōu)化方法，其每次迭代由兩個(gè)階段組成：1) 貪婪構(gòu)建階段，即通過(guò)從解空間中隨機(jī)取樣的方式基于貪婪函數(shù)構(gòu)建解列表；2) 局部搜索階段，即從先前貪婪構(gòu)建列表中通過(guò)鄰居搜索方式尋找當(dāng)前最優(yōu)解。迭代過(guò)程到達(dá)確定的終止條件為止。GRASP的自適應(yīng)特征可以動(dòng)態(tài)地更新目標(biāo)的貪婪值，而基于概率的取樣特征則有機(jī)會(huì)完成近似最優(yōu)解。同時(shí)，其解空間規(guī)模的靈活選擇特征以及終止條件的設(shè)置也可以調(diào)整貪婪值和計(jì)算復(fù)雜性的程度。

動(dòng)態(tài)虛擬機(jī)部署主要由三步構(gòu)成：

1) 發(fā)現(xiàn)熱點(diǎn)主機(jī)和低負(fù)載主機(jī)。

2) 從步驟1得到的主機(jī)中選擇需要遷移的虛擬機(jī)。

3) 將所選虛擬機(jī)重新部署至新的目標(biāo)主機(jī)上。

對(duì)于動(dòng)態(tài)合并的前兩個(gè)步驟，使用如下策略。為了發(fā)現(xiàn)超載主機(jī)，算法利用靜態(tài)CPU利用率閾值Umax和CPU溫度最高閾值Tred作為門(mén)限參數(shù)。若兩個(gè)參數(shù)其一被超過(guò)，則視為超載主機(jī)。低載主機(jī)的發(fā)現(xiàn)思想是：對(duì)于所有未超載的活躍主機(jī)，如果這類(lèi)主機(jī)上的所有虛擬機(jī)可遷移至其他主機(jī)上，則該主機(jī)視為低載主機(jī)。對(duì)于動(dòng)態(tài)合并的第二個(gè)步驟，需要從超載主機(jī)選擇虛擬機(jī)遷移至其他主機(jī)直到該主機(jī)不超載。算法主要思想是選擇擁有最小遷移時(shí)間的虛擬機(jī)進(jìn)行遷移，從而降低主機(jī)負(fù)載，由于這類(lèi)虛擬機(jī)擁有更小的內(nèi)存使用，在帶寬有限的情況下，其遷移過(guò)程花費(fèi)的時(shí)間更少。

假設(shè)在優(yōu)化開(kāi)始之前，數(shù)據(jù)中心已經(jīng)到達(dá)穩(wěn)定狀態(tài)，即所有請(qǐng)求的虛擬機(jī)已經(jīng)部署至主機(jī)上，且數(shù)據(jù)中心的溫度狀態(tài)已經(jīng)達(dá)到穩(wěn)定。算法1在每個(gè)調(diào)度間隔(5分鐘)開(kāi)始時(shí)執(zhí)行，得到此時(shí)需要遷移的虛擬機(jī)以及目標(biāo)主機(jī)。

算法1能量和熱量感知的虛擬機(jī)合并算法

輸入:VMList,hostList。

輸出:energy,number of hotspot,SLA violation。

1. Initialize Tred,α,ε

2. for t=0 to T do

3. VMList←getVMsFromOverAndUnderUtilizedHosts()

4. for each vm in VMList do

5. allocatedHost=null

6. isSolutionNotDone←true

7. while isSolutionNotDone do

8. SolutionList←ConstructGreedySolution(VM,hostList)

9. newHost←LocalSearch(SolutionList)

10. δ=allocatedHost.τ-newHost.τ

11. if δ>ε then

12. allocatedHost←newHost

13. else

14. isSolutionNotDone←false

15. end if

16. end while

17. if allocatedHost==null then

18. allocatedHost=getNewHostFromInactiveHostList()

19. end if

20. end for

21. end for

算法1的第一步需要對(duì)紅線溫度Tred、GRASP中的約束候選解的規(guī)模α及解的改進(jìn)質(zhì)量控制參數(shù)ε進(jìn)行初始化。在每個(gè)間隔中，步驟3對(duì)超載和低載主機(jī)上的所有虛擬機(jī)進(jìn)行標(biāo)識(shí)。對(duì)于來(lái)自于遷移列表中的每個(gè)虛擬機(jī)，步驟5將初始化待分配的主機(jī)為空，步驟7-步驟16則為貪婪隨機(jī)自適應(yīng)搜索機(jī)制中的貪婪策略。該階段中，每次迭代有兩個(gè)步驟：1) 在搜索空間中構(gòu)建可行解列表，即一個(gè)容納當(dāng)前虛擬機(jī)的可能的主機(jī)列表；2) 執(zhí)行局部搜索，尋找局部最優(yōu)候選解，即子最優(yōu)解。為了達(dá)到全局最優(yōu)，在每次迭代中，所分配的主機(jī)需要根據(jù)步驟12中構(gòu)建階段的貪婪值τ進(jìn)行更新。如果當(dāng)前分配的主機(jī)和新分配的主機(jī)貪婪值τ之差大于預(yù)定義參數(shù)ε，則迭代過(guò)程繼續(xù)；否則，終止迭代，將當(dāng)前分配的主機(jī)返回為最終結(jié)果，即步驟11-步驟15。這里，ε是決定在先前解的基礎(chǔ)上新解改進(jìn)質(zhì)量的參數(shù)。如果當(dāng)前迭代中的新解比較先前迭代時(shí)的ε沒(méi)有得到改進(jìn)，則終止過(guò)程。若該過(guò)程無(wú)法找到容納當(dāng)前虛擬機(jī)的可用主機(jī)，則從空閑主機(jī)列表中啟動(dòng)新主機(jī)，即步驟17-步驟18。

算法2是貪婪構(gòu)建解階段。算法將虛擬機(jī)和主機(jī)列表作為輸入，并輸出可行部署解。過(guò)程第一步是構(gòu)建RCL，它代表在有限解搜索空間中所構(gòu)建的一個(gè)解列表。RCL的形成可以限制解空間中的搜索數(shù)量，降低算法時(shí)間復(fù)雜度。最后，需要排列不活躍主機(jī)，并從活躍主機(jī)中選擇百分比為α的主機(jī)進(jìn)入RCL，這可以確保搜索空間進(jìn)一步降低。另外，通過(guò)隨機(jī)取樣方式選擇活躍主機(jī)的百分比α進(jìn)入RCL即為GRASP的概率機(jī)制。RCL中的每個(gè)主機(jī)的代價(jià)可表示為τ。

算法2貪婪構(gòu)建可行部署解算法(Construct Greedy Solution)

輸入:VM,hostList。

輸出:SolutionList。

1. SolutionList←null

2. RCL←makeRCLFromActiveHostList

3. for each s in RCL do

4. if s is suitable for VM then

5. s.τ←(1+1/CoP(Tsup))Pi

6. end if

7. SolutionList←∪S

8. end for

9. return SolutionList

算法3顯示了局部搜索機(jī)制，以尋找每次迭代中的局部最優(yōu)解。基于所計(jì)算的貪婪值τ，最優(yōu)局部候選解被返回為算法3的解。該算法不僅可以降低能耗，而且可以在滿足資源能力在CPU、內(nèi)存、帶寬約束下避免溫度高于閾值。算法2的步驟4即可滿足式(9)的約束條件。并且，參數(shù)α和ε起到了調(diào)節(jié)參數(shù)作用，用于調(diào)整算法的貪婪程度和決策時(shí)間。若系統(tǒng)精確度要求較高，則可設(shè)置更大的參數(shù)值，但可能在搜索最優(yōu)解時(shí)需要花費(fèi)更長(zhǎng)的時(shí)間。

算法3最優(yōu)候選解局部搜索算法(Local Search)

輸入:SolutionList。

輸出:Host with local optima。

1. LocalOptimalHost←null

2. for each s in SolutionList do

3. if s.τ

4. LocalOptimalHost=s

5. end if

6. end for

7. return LocalOptimalHost

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

3.1 實(shí)驗(yàn)配置

本節(jié)評(píng)估算法可行性和性能，在cloudsim中構(gòu)建仿真環(huán)境，模擬云計(jì)算系統(tǒng)。數(shù)據(jù)中心基礎(chǔ)設(shè)施由1 000臺(tái)異構(gòu)主機(jī)組成，主機(jī)配置的處理能力參考IBM x3550 M3，處理器為Intel Xeon X5670和X5675，具體參數(shù)如表2所示。采用內(nèi)核較少的CPU的原因在于可以展示在大量的虛擬機(jī)遷移下動(dòng)態(tài)合并的效率。若內(nèi)核較多，其容納虛擬機(jī)數(shù)量也越多，則虛擬機(jī)遷移機(jī)會(huì)也會(huì)降低。系統(tǒng)功耗利用SPECpower實(shí)驗(yàn)床中的數(shù)據(jù)，它提供了在不同CPU利用率情況下對(duì)應(yīng)主機(jī)的功耗情況，兩種主機(jī)類(lèi)型的功耗情況如表3所示。

表2 主機(jī)CPU和虛擬機(jī)類(lèi)型和配置

表3 主機(jī)功耗情況 W

虛擬機(jī)參考AWS給出的配置，如表2所示。主機(jī)配置在機(jī)架結(jié)構(gòu)上，機(jī)架安排在若干區(qū)域內(nèi)，每個(gè)區(qū)域配置10個(gè)機(jī)架，總共10行，每行10臺(tái)主機(jī)。假設(shè)在單個(gè)區(qū)域內(nèi)存在熱循環(huán)，但在不同區(qū)域間不存在。實(shí)驗(yàn)利用PlanetLab系統(tǒng)[20]生成仿真的負(fù)載流，該負(fù)載流統(tǒng)計(jì)了若干月份中數(shù)千臺(tái)虛擬機(jī)的資源利用率狀況，數(shù)據(jù)記錄每5分鐘進(jìn)行一次，利用一天的數(shù)據(jù)流生成虛擬機(jī)的負(fù)載。

3.2 對(duì)比算法

Random算法：將所有虛擬機(jī)隨機(jī)部署在所選主機(jī)上，不考慮主機(jī)熱量或功耗狀態(tài)。

RR算法：輪轉(zhuǎn)法，所有虛擬機(jī)以輪轉(zhuǎn)方式部署至主機(jī)上，試圖以均勻方式將負(fù)載分布至活躍主機(jī)上。

PABFD算法[7]：一種基于功耗感知的修改最佳適應(yīng)算法，但僅僅考慮了合并過(guò)程中的CPU利用率，而沒(méi)有考慮熱量問(wèn)題。

GRANITE算法[16]：一種以最小化數(shù)據(jù)中心能耗為目標(biāo)的貪婪虛擬機(jī)調(diào)度算法，可以動(dòng)態(tài)地進(jìn)行虛擬機(jī)遷移，從而將負(fù)載均勻分配，使主機(jī)溫度保持在確定的溫度閾值以內(nèi)。

TAS算法[17]：一種溫度感知調(diào)度算法，所選目標(biāo)主機(jī)是溫度最低的主機(jī)。

3.3 參數(shù)選擇

式(3)中的熱電阻和熱容分別為0.34 K/W和340 J/K，初始的CPU溫度設(shè)置為318 K，CRAC提供的冷氣溫度Tsup=25 ℃。主機(jī)最高溫度閾值設(shè)置為95 ℃。需要注意的是，主機(jī)溫度并不是CPU散熱的唯一因素，還包括CRAC提供的冷氣。將CPU的動(dòng)態(tài)最大溫度閾值設(shè)置為70 ℃。換言之，主機(jī)最大溫度閾值為95 ℃，在排除靜態(tài)部分Tsup之后，動(dòng)態(tài)閾值溫度為70 ℃。CPU靜態(tài)利用閾值Umax設(shè)置為90%，參數(shù)α和ε設(shè)置為0.4和10-1。

3.4 性能指標(biāo)

能耗：主機(jī)執(zhí)行負(fù)載帶來(lái)的能耗，單位kW。

由于過(guò)量訂購(gòu)原因，主機(jī)可能達(dá)到滿利用率等級(jí)100%，此時(shí)，這類(lèi)主機(jī)上的虛擬機(jī)會(huì)表現(xiàn)較差性能，即出現(xiàn)單個(gè)活動(dòng)主機(jī)的SLA違例SLATAH，定義為式(14)。進(jìn)一步，由于虛擬機(jī)遷移所帶來(lái)的虛擬機(jī)合并還會(huì)帶到性能開(kāi)銷(xiāo)。這種虛擬機(jī)遷移所帶來(lái)的性能下降PDM可定義為式(15)。SLA違例：該指標(biāo)描述由于動(dòng)態(tài)合并帶來(lái)的性能開(kāi)銷(xiāo)，定義為式(16)。

(14)

(15)

SLAviolation=SLATAH×PDM

(16)

式中：N為主機(jī)總量;Tmax為主機(jī)經(jīng)歷100%占用時(shí)間;Tactive為主機(jī)總活躍時(shí)間;M為虛擬機(jī)總量;pdmj為由于虛擬機(jī)j遷移帶來(lái)的性能下降，實(shí)驗(yàn)設(shè)置為10%;Cdemandj為虛擬機(jī)j在周期內(nèi)請(qǐng)求的CPU資源總量?？傮wSLA違例SLAviolation為兩個(gè)指標(biāo)的乘積。

熱點(diǎn)主機(jī)：描述超過(guò)閾值溫度的主機(jī)數(shù)量。

活動(dòng)主機(jī)：描述整個(gè)實(shí)驗(yàn)過(guò)程中活躍主機(jī)的數(shù)量。

峰值溫度：描述調(diào)度間隔中任意主機(jī)的最大溫度。

3.5 結(jié)果分析

圖1是算法的能耗情況，隨機(jī)算法最高能耗有363 kW·h，RR、PABFD、GRANITE和TAS算法分別達(dá)到342、235、265、327 kW·h，本文算法約為250 kW·h，同時(shí)還具有95%的置信區(qū)域CI，即(247，252)。換言之，本文算法比較隨機(jī)算法、RR、GRANITE和TAS算法能耗分別降低了31%、27%、23%。比較PABFD，本文算法能耗略高6%，這是由于PABFD算法比較本文算法進(jìn)行了更積極的虛擬機(jī)合并，所使用的主機(jī)數(shù)量更少。但這種極端合并忽略了潛在的熱量約束，可能導(dǎo)致熱點(diǎn)。

圖1 能耗

圖2是算法得到的熱點(diǎn)主機(jī)情況，盡管PABFD比本文算法的能耗更少，但其創(chuàng)造了大量熱點(diǎn)主機(jī)。隨機(jī)算法的隨機(jī)順序?qū)τ谀芎暮蜔狳c(diǎn)的產(chǎn)生均有較大影響，熱點(diǎn)最多。RR算法的均勻分布策略比較隨機(jī)算法具有一定優(yōu)勢(shì)，熱點(diǎn)降低至約416臺(tái)，然而其能耗太高。PABFD約有123臺(tái)熱點(diǎn)主機(jī)，本文算法沒(méi)有產(chǎn)生一臺(tái)熱點(diǎn)主機(jī)。本文算法雖然能耗略高于PABFD，但沒(méi)有產(chǎn)生熱點(diǎn)，其優(yōu)勢(shì)在于：1) 溫度過(guò)高可能使服務(wù)器失效；2) 熱點(diǎn)產(chǎn)生后，數(shù)據(jù)中心管理員需要進(jìn)一步降低冷卻溫度，這會(huì)進(jìn)一步增加冷卻系統(tǒng)能耗。

圖2 熱點(diǎn)主機(jī)數(shù)量

圖3是算法的SLA違例情況。算法的總體SLA違例需要計(jì)算出單個(gè)活動(dòng)主機(jī)的SLA違例和所有的虛擬機(jī)遷移所帶來(lái)的性能下降。由式(14)可知，實(shí)驗(yàn)中通過(guò)統(tǒng)計(jì)所有主機(jī)的總活躍時(shí)間和滿負(fù)載時(shí)間兩個(gè)參數(shù)值即可計(jì)算出單個(gè)活動(dòng)主機(jī)的SLA違例。由式(15)可知，實(shí)驗(yàn)中僅僅需要記錄虛擬機(jī)在周期內(nèi)請(qǐng)求的CPU資源總量這一個(gè)可變參數(shù)即可計(jì)算出虛擬機(jī)遷移所帶來(lái)的性能下降。結(jié)合這兩個(gè)參數(shù)值，即可計(jì)算出算法在整個(gè)虛擬機(jī)部署周期內(nèi)的SLA違例情況。隨機(jī)算法、PABFD和TAS的SLA違例較多，其他三種算法較少。盡管RR算法在做出部署決策時(shí)沒(méi)有考慮SLA需求，但其固有的負(fù)載均勻分布特征較隨機(jī)算法、PABFD和TAS算法還是可以降低一定SLA違例的。本文算法在SLA違例上表現(xiàn)得足夠優(yōu)秀，同時(shí)還可以降低能耗和避免熱點(diǎn)主機(jī)產(chǎn)生，綜合性能最優(yōu)。

圖3 SLA違例

圖4是算法活躍主機(jī)數(shù)量情況。標(biāo)記時(shí)間是每隔一小時(shí)得到的均值結(jié)果。PABFD得到更少的活躍主機(jī)，而本文算法在PABFD的基礎(chǔ)上仍有增加，GRANITE則又高于本文算法，這種結(jié)果也可從圖1的能耗結(jié)果中推斷出來(lái)。隨機(jī)算法擁有最多活躍主機(jī)數(shù)量，TAS的增加幅度最小，并小于RR算法。同時(shí)，活躍主機(jī)數(shù)量、熱點(diǎn)主機(jī)及能耗之間的關(guān)系也可被推斷出來(lái)，擁有更少活躍主機(jī)的算法也傾向于會(huì)產(chǎn)生較多熱點(diǎn)主機(jī)。隨機(jī)算法顯得比較異常，由于它是隨機(jī)選擇主機(jī)的?？傮w來(lái)看，活躍主機(jī)數(shù)量在所有算法間并未表現(xiàn)出很大不同，原因在于算法在超載主機(jī)和低載主機(jī)發(fā)現(xiàn)機(jī)制上采用了相同策略。本文算法雖然沒(méi)有得到最少的活躍主機(jī)，但較PABFD能夠避免負(fù)載過(guò)于集中，溫度過(guò)高并避免熱點(diǎn)主機(jī)產(chǎn)生。

圖4 平均資源利用率

圖5是算法主機(jī)的峰值溫度情況。本文由于利用其熱量感知的虛擬機(jī)部署機(jī)制從未超過(guò)紅線溫度，并接近于紅線溫度，這樣極大提高了資源利用率，降低了冷卻代價(jià)。TAS總是運(yùn)行在一個(gè)更低的溫度等級(jí)，而PABFD幾乎均運(yùn)行在紅線溫度周?chē)?，甚至超過(guò)紅線溫度70 ℃。GRANITE的主機(jī)峰值溫度一直是最低的，由于該算法僅僅考慮了溫度閾值，高溫度主機(jī)上的虛擬機(jī)會(huì)被遷移出去，從而均衡負(fù)載。盡管RR是均勻分配負(fù)載，但由于主機(jī)性能的差異以及未進(jìn)行熱量感知，部分主機(jī)會(huì)超過(guò)紅線溫度。同時(shí)需要注意，圖5中的溫度結(jié)果并非所有主機(jī)的溫度均值結(jié)果，而是所有主機(jī)中最高的溫度。

圖5 主機(jī)的峰值溫度

4 結(jié) 語(yǔ)

本文提出一種同步優(yōu)化計(jì)算系統(tǒng)和冷卻系統(tǒng)能耗的虛擬機(jī)合并算法。算法利用貪婪隨機(jī)自適應(yīng)搜索機(jī)制，可以均衡虛擬機(jī)的合并積極度和虛擬機(jī)的稀疏分布，并有效避免產(chǎn)生熱點(diǎn)主機(jī)，導(dǎo)致主機(jī)溫度過(guò)高，使系統(tǒng)失效。大量仿真實(shí)驗(yàn)結(jié)果證明，本文算法不僅可以節(jié)省更多能源，避免熱點(diǎn)主機(jī)生成，而且在性能保障方面(SLA違例)也表現(xiàn)出很好的性能。下一步的研究可考慮將機(jī)房空調(diào)系統(tǒng)CRAC的冷氣輸出溫度根據(jù)數(shù)據(jù)中心的運(yùn)行狀況設(shè)置為變化的溫度，并在此基礎(chǔ)上設(shè)計(jì)虛擬機(jī)能效部署與合并算法，更好地節(jié)省能耗。