張志超，彭 蓉＋，黃 華，2

（1.武漢大學(xué) 計算機(jī)學(xué)院 軟件工程國家重點實驗室，湖北 武漢430072；2.景德鎮(zhèn)陶瓷學(xué)院 信息工程學(xué)院，江西 景德333001）

0 引 言

在云計算環(huán)境下，面對的一個重要問題是：需要設(shè)計有效的資源分配算法，以保證租戶的服務(wù)質(zhì)量，并最小化底層資源的使用。大量研究試圖提供云服務(wù)在質(zhì)量上的保障。文獻(xiàn) ［1］通過虛擬機(jī)復(fù)用進(jìn)行有效的資源管理；文獻(xiàn)［2］根據(jù)任務(wù)的緊張程度，基于SLA 來為任務(wù)提取資源；文獻(xiàn) ［3］通過應(yīng)用加載分析來動態(tài)的提取底層資源，以滿足SLA；文獻(xiàn) ［4，5］通過在線資源需求預(yù)測來提取底層資源。SaaS提供商，如Compiere ERP［6］，為每個租戶維護(hù)一個虛擬機(jī)，并在租戶請求擁堵時，實時添加應(yīng)用實例，是保證租戶服務(wù)質(zhì)量的一種基本做法，但由于為每個租戶提供單獨的虛擬機(jī)，大多數(shù)租戶都會有一個沒有完全使用的虛擬機(jī)，造成底層資源低效使用，增加了底層資源成本。文獻(xiàn) ［7］提出通過多租戶技術(shù)，以一個虛擬機(jī)應(yīng)用實例來為多個租戶服務(wù)來節(jié)省資源。不過，多租戶共用虛擬機(jī)的方式會更容易受到租戶請求變化的影響，如不能及時提取足夠的資源，則會造成大量的SLA 違背及賠償。

在本文提出的算法中，利用SaaS服務(wù)的多租戶特性，采用多個租戶共用虛擬機(jī)的方式以節(jié)省底層資源。本文采用協(xié)調(diào)虛擬機(jī)處理增長的租戶請求，根據(jù)協(xié)調(diào)虛擬機(jī)的使用情況，以提取適當(dāng)?shù)奶摂M機(jī)資源。采用協(xié)調(diào)虛擬機(jī)機(jī)制，可以更精確更及時地提取適當(dāng)?shù)讓淤Y源，以保證租戶的服務(wù)質(zhì)量。在租戶請求減少時，本文則采用慢收縮策略來防止租戶請求量反彈。通過模擬實驗驗證了算法的有效性。

1 SaaS服務(wù)模型

云計算主要可以分為底層架構(gòu)即服務(wù) （IaaS）、平臺即服務(wù) （PaaS）和軟件即服務(wù) （SaaS）。在云計算中的SaaS模型如圖1所示［7］。SaaS層管理SaaS提供商提供給租戶的所有服務(wù)的應(yīng)用。PaaS層包含映射和調(diào)度政策，以將租戶的服務(wù)質(zhì)量需求轉(zhuǎn)換為底層架構(gòu)參數(shù)，并分配虛擬機(jī)以處理租戶的服務(wù)請求。IaaS層控制虛擬機(jī)的實際的初始化和銷毀。IaaS層，如Amazon EC2service［8］，提供多種類型的虛擬機(jī)，其處理能力、內(nèi)存及I／O 性能均不一樣，客戶可以購買所需要的虛擬機(jī)實例，并按實際使用收費。這樣，SaaS應(yīng)用可以按實際需求，動態(tài)提取所需要的底層資源。

圖1 SaaS服務(wù)的系統(tǒng)模型

在SaaS服務(wù)模型下，PaaS平臺為SaaS服務(wù)提供底層資源運行環(huán)境，并對SaaS服務(wù)對應(yīng)的底層資源進(jìn)行監(jiān)控和管理。當(dāng)租戶請求到來時，PaaS平臺獲取租戶請求信息，將請求發(fā)送到SaaS服務(wù)對應(yīng)的底層資源，使租戶請求得到服務(wù)。當(dāng)租戶請求增長，現(xiàn)有的底層資源已不能處理租戶請求時，PaaS平臺則需要為SaaS服務(wù)提取新的底層資源。由于IaaS層創(chuàng)建新的虛擬機(jī)，并部署相應(yīng)的應(yīng)用實例是需要時間的，為了能提取恰當(dāng)?shù)馁Y源，在PaaS平臺的資源分配算法中，需要一些值記錄IaaS層正在為SaaS服務(wù)提取的底層資源。當(dāng)IaaS層為SaaS服務(wù)創(chuàng)建的底層資源已經(jīng)生成時，PaaS平臺則對SaaS服務(wù)與底層資源的映射關(guān)系及這些狀態(tài)值進(jìn)行更新。同時，根據(jù)SaaS服務(wù)的底層資源使用狀態(tài)，PaaS平臺需要定期對底層資源進(jìn)行更新，當(dāng)租戶請求減少時，及時釋放底層資源，以節(jié)省成本。

一般而言，SaaS環(huán)境下的資源分配算法包括3個部分。一是在租戶請求到來時，對租戶請求的處理。在該算法中，當(dāng)現(xiàn)有的資源不能處理租戶請求時，則需要提取新的底層資源。二是定期的對底層資源進(jìn)行更新。對底層資源的定期更新，是為了在租戶請求減少時，及時的釋放底層資源，以節(jié)省成本。三是當(dāng)IaaS層生成了需要提取的新的虛擬機(jī)時，PaaS層對SaaS服務(wù)映射的底層資源及記錄正在生成的虛擬機(jī)的記錄值進(jìn)行更新。

SaaS提供商與租戶需要簽訂SLA 協(xié)議，以保證SaaS服務(wù)質(zhì)量，并對違背SLA 做出賠償。響應(yīng)時間是SaaS 服務(wù)質(zhì)量好壞的一個重要標(biāo)準(zhǔn)。SLA 協(xié)議往往需要規(guī)定請求響應(yīng)時間上限，并保證在租戶請求中響應(yīng)時間超出SLA 響應(yīng)時間上限的請求量低于某個概率值，如5%，當(dāng)SLA 違背的請求量超出該概率值時，對超出的請求做出一定的賠償。故SaaS環(huán)境下的資源提取算法，需要最小化SLA 違背，并最小化SaaS提供商的底層資源成本。

2 資源分配算法

記云平臺生成新的虛擬機(jī)應(yīng)用實例的時間為T，SLA規(guī)定的響應(yīng)時間上限為tr。

在SaaS服務(wù)模型下，為了使得被處理的租戶請求都能在tr內(nèi)得到服務(wù)，需要根據(jù)虛擬機(jī)的處理能力及虛擬機(jī)現(xiàn)有的待處理請求數(shù)量，對租戶請求作請求處理時間預(yù)測。虛擬機(jī)的處理能力可通過壓力測試獲得。一個請求到來時，當(dāng)虛擬機(jī)可以在tr內(nèi)處理該請求時，則將該請求發(fā)送到該虛擬機(jī)。當(dāng)SaaS服務(wù)現(xiàn)有的虛擬機(jī)資源都不能保證在tr內(nèi)處理該請求時，則放棄當(dāng)前請求 （此時是SLA 違背），并令I(lǐng)aaS層生成新的虛擬機(jī)應(yīng)用實例，以適應(yīng)租戶請求的增長。

在現(xiàn)實的SaaS環(huán)境下，租戶請求的到來是隨機(jī)離散事件，在模擬環(huán)境下，為了方便觀察租戶請求量變化對底層資源的影響，我們以一個固定時間為間隔來發(fā)送租戶請求。記請求發(fā)送間隔為ts，并設(shè)置ts＝tr。即以tr為間隔來發(fā)送請求，并在每個請求發(fā)送間隔結(jié)束時，對虛擬機(jī)進(jìn)行更新。由于預(yù)測處理時間超出tr的請求被放棄，本文假定請求處理時間預(yù)測是有效的，則在tr時間后虛擬機(jī)資源就會完全恢復(fù)處理能力。若ts＜tr，每次請求發(fā)送時，底層資源要以部分處理能力來處理上一次未處理完的請求，而只能以剩余處理能力來處理該次發(fā)送的請求，則此時間段放棄的請求量不能真實的反映該時間段內(nèi)請求量變化對底層資源的影響。若ts＞tr，則底層資源在每次請求發(fā)送間隔的 ［tr，ts］時間內(nèi)處于閑置狀態(tài)。故設(shè)置ts＝tr時，可以更好的觀察請求變化量對底層資源的影響。

一個SaaS應(yīng)用可以有多個版本，如標(biāo)準(zhǔn)版、專業(yè)版和企業(yè)版等。以下討論均指部署為同一個版本的SaaS應(yīng)用，并且SaaS提供商對該版本的SaaS應(yīng)用只使用同種類型的虛擬機(jī)，即下文所說的所有虛擬機(jī)都有相同的處理能力、內(nèi)存及I／O 性能等。

如引言所述，Compiere ERP［6］為每個租戶維護(hù)單獨的虛擬機(jī)，并在租戶請求擁堵時，可以為各個租戶生成新的虛擬機(jī)應(yīng)用實例，以保證服務(wù)質(zhì)量。本文把Compiere ERP的資源分配算法作為一個基本的算法進(jìn)行介紹。然后描述了本文提出的基于服務(wù)質(zhì)量的資源分配算法。

2.1 基本算法

我們用BaseAlg來表示基本算法。在該算法中，為各個租戶都分別維護(hù)了專用虛擬機(jī)列表。數(shù)組tenantVmCreating［N］（N 表示租戶的數(shù)量）表示各個租戶是否有新的專用虛擬機(jī)正在生成中。各個租戶的請求，都只使用該租戶的專用虛擬機(jī)來處理，當(dāng)專用虛擬機(jī)不能在tr時間內(nèi)處理時，則為該租戶生成一個新的專用虛擬機(jī)。

算法初始時，每個租戶的專用虛擬機(jī)列表都只有一個虛擬機(jī)，數(shù)組tenantVmCreating 中的各個元素都為0。當(dāng)一個租戶請求c到來時，對請求處理的算法BaseAlg＿RequestSolve如下：

在每個請求發(fā)送間隔結(jié)束時，對虛擬機(jī)更新的算法BaseAlg＿VmsUpdate如下：

當(dāng)IaaS層生成了新的虛擬機(jī)時，需要對記錄虛擬機(jī)生成狀態(tài)的狀態(tài)值tenantVmCreating 進(jìn)行更新，并將虛擬機(jī)加入到對應(yīng)租戶的專用虛擬機(jī)列表中。其算法BaseAlg＿VmsCreated如下：

BaseAlg算法的虛擬機(jī)如圖2所示。這一算法為各個租戶提供單獨的虛擬機(jī)，并且能在租戶請求增長時，生成新的虛擬機(jī)，以處理增長的租戶請求。不過，在該算法中，首先，為每個租戶提供單獨的虛擬機(jī)，大多數(shù)租戶都會有一個沒有完全使用的虛擬機(jī)，故會造成虛擬機(jī)的低效使用，增加了底層資源成本；其次，當(dāng)租戶請求量增長，需要生成新的虛擬機(jī)應(yīng)用實例來處理租戶請求時，在生成新的虛擬機(jī)應(yīng)用實例期間，會造成SLA 違背，即不能及時響應(yīng)租戶請求的增長。

圖2 BaseAlg算法的虛擬機(jī)

2.2 基于服務(wù)質(zhì)量的資源分配算法

我們用QoSBasedAlg來表示本文提出的基于服務(wù)質(zhì)量的資源分配算法。SaaS服務(wù)可分為四級成熟度模型［9］。在第四級SaaS成熟度模型下，SaaS服務(wù)有規(guī)模可伸縮，可定制和多租戶效應(yīng)。通過多租戶和定制技術(shù)，一個SaaS服務(wù)實例可以為多個租戶服務(wù)。在QoSBasedAlg算法中，在多個租戶共用虛擬機(jī)應(yīng)用實例的基礎(chǔ)上，將虛擬機(jī)分成了兩類：公用虛擬機(jī)和協(xié)調(diào)虛擬機(jī)，以實現(xiàn)在保障租戶的服務(wù)質(zhì)量的基礎(chǔ)上，最小化底層資源的成本。本小節(jié)首先對虛擬機(jī)分類進(jìn)行介紹，然后對算法進(jìn)行描述。

2.2.1 虛擬機(jī)分類

在算法中，將虛擬機(jī)分為兩類：公用虛擬機(jī)和協(xié)調(diào)虛擬機(jī)。

公用虛擬機(jī)：是所有租戶都可以使用的虛擬機(jī)。與基本算法相比，其優(yōu)勢在于可以減少非滿負(fù)荷運行的虛擬機(jī)，從而減少對虛擬機(jī)資源的占用。

協(xié)調(diào)虛擬機(jī)：當(dāng)公用虛擬機(jī)已滿時，則使用協(xié)調(diào)虛擬機(jī)來處理租戶請求。協(xié)調(diào)虛擬機(jī)開始使用，則需要生成新的公用虛擬機(jī)，以應(yīng)對租戶請求的增長。有多少個協(xié)調(diào)虛擬機(jī)在使用，則需要生成多少個公用虛擬機(jī)。

QoSBasedAlg算法的虛擬機(jī)如圖3所示。QoSBasedAlg算法使用多租戶共用虛擬機(jī)的方式來處理所有租戶的請求，可以高效的使用虛擬機(jī)，節(jié)省底層資源。不過，多租戶共用虛擬機(jī)的方式會更容易受到租戶請求變化的影響。當(dāng)租戶請求增長時，如不能及時的提取足夠的資源，則會造成大量的SLA 違背。故本文提出了協(xié)調(diào)虛擬機(jī)來處理增長的租戶請求，并根據(jù)協(xié)調(diào)虛擬機(jī)的使用數(shù)量來確定所需要提取的底層資源數(shù)量。協(xié)調(diào)虛擬機(jī)機(jī)制可以減少及避免租戶請求增長時，生成新的虛擬機(jī)期間的SLA 違背。

圖3 QoSBasedAlg算法的虛擬機(jī)

記租戶的數(shù)量為N，初始時，各個租戶的請求發(fā)送量為ri（i＝1，2，…N），公用虛擬機(jī)數(shù)量的初始值J 則要求其總的處理能力不小于初始時總的租戶請求量。記虛擬機(jī)在響應(yīng)時間tr內(nèi)的最大并發(fā)處理能力為M。故J 的值為式（1）所示

2.2.2 算法描述

在QoSBasedAlg算法中，用pubVmCrtCnt來記錄正在生成的公用虛擬機(jī)的數(shù)量。

算法初始值如下：pubVmCrtCnt的值為0，公用虛擬機(jī)的數(shù)量按式 （1）來確定，協(xié)調(diào)虛擬機(jī)的數(shù)量按式 （2）來確定。

當(dāng)一個租戶請求c到來時，對租戶請求處理的流程如圖4所示。對租戶請求進(jìn)行處理的算法QoSBasedAlg＿RequestSolve描述如算法4所示。

圖4 請求處理流程

多租戶共用虛擬機(jī)的方式會更容易受到租戶請求變化的影響。在某個時刻租戶請求量減少之后，在下一個時刻有可能會增加。如果在租戶請求量減少時，立刻釋放空的公用虛擬機(jī)，在下一個時刻租戶請求量增加時，又需要生成新的公用虛擬機(jī)，這無疑會增加SLA 違背的可能性，并影響算法的健壯性。為了防止租戶請求量減少了之后再反彈，對虛擬機(jī)更新則采用了慢收縮策略，即對所有空閑的公用虛擬機(jī)采用超時銷毀政策。每個請求發(fā)送間隔結(jié)束時，對虛擬機(jī)更新的算法QoSBasedAlg＿VmsUpdate如下：

新的虛擬機(jī)生成時的算法QoSBasedAlg＿VmsCreated如下：

3 性能評估

本文通過模擬實驗來評估QoSBasedAlg 算法的性能。在實驗中，本文使用CloudSim［11］來模擬在SaaS環(huán)境下的資源分配算法。如上節(jié)所述，本文假定SaaS提供商只使用同一種類型的虛擬機(jī)，則BaseAlg算法和QoSBasedAlg算法中的所有虛擬機(jī)都有相同的處理能力、內(nèi)存及I／O 性能。在實際情況下，為確定虛擬機(jī)在SLA 響應(yīng)時間上限內(nèi)的最大處理能力，需要考慮不同請求類型及其比例。本文的主要目的是驗證QoSBasedAlg算法的有效性，為簡單起見，本文只考慮所有請求都為同一種類型的情況。在性能評估中，主要以SLA違背量、SLA 違背率以及底層資源的使用數(shù)量作為評估標(biāo)準(zhǔn)，并在不同的實驗環(huán)境參數(shù)下，對BaseAlg算法和QoSBasedAlg算法的實驗結(jié)果進(jìn)行比較分析。

3.1 性能測試

實驗環(huán)境的主要配置參數(shù)如下：數(shù)據(jù)中心的每個主機(jī)包含4 核處理器，16GB 的RAM，每個核的處理能力為1000mips。每個虛擬機(jī)的處理能力為250 mips，1GB 的RAM。每個服務(wù)請求需要處理15 million條指令。響應(yīng)時間tr為6s。租戶請求發(fā)送間隔tr為6s。QoSBasedAlg算法中空虛擬機(jī)保留時間為31s。在模擬環(huán)境下，測試得：在6s的響應(yīng)時間內(nèi)，SaaS服務(wù)的最大并發(fā)處理能力M 為99個請求。每個租戶的初始請求量ri（i＝1，2，…N）都為50個請求。在實驗中，本文分別在不同請求變化量、不同虛擬機(jī)生成時間、不同的租戶數(shù)量的實驗條件下，對比BaseAlg算法和QoSBasedAlg 算法的底層資源使用量與SLA 違背量及SLA 違背率。

為了保證可比性，首先對QoSBasedAlg進(jìn)行實驗，在實驗中記錄每個租戶每次發(fā)送的請求數(shù)量。然后在BaseAlg實驗中，按照QoSBasedAlg中記錄的每個租戶每次的請求發(fā)送量，來發(fā)送租戶請求。

在下面的每個實驗條件下，對每個實驗都重復(fù)5 次，每次實驗的實驗時間為半個小時。在每次實驗中，取平均虛擬機(jī)使用量作為底層資源 （虛擬機(jī)）使用量的衡量標(biāo)準(zhǔn)，即各個請求發(fā)送間隔內(nèi)的虛擬機(jī)使用量的總和與請求發(fā)送間隔總數(shù)量之比；SLA 違背量則取每次實驗中放棄的請求的總數(shù)量；SLA 違背率取每次實驗中放棄的總的請求量與總的請求發(fā)送量之比。每個實驗條件下，虛擬機(jī)使用量、SLA 違背量及SLA 違背率都取5次實驗的平均值作為最終的評估標(biāo)準(zhǔn)。

3.1.1 不同請求變化量對實驗的影響

在實驗下，主要看不同的租戶請求變化量對實驗的影響。設(shè)置租戶數(shù)量N 為200，虛擬機(jī)生成時間T 為40s。請求變化量分別設(shè)置為n＝4、8、12、16、20 時，對比BaseAlg與QoSBasedAlg算法。初始時，在BaseAlg實驗中有200個專用虛擬機(jī)。初始時在各個實驗中都有，ri＝50（i＝1，2，…N），M ＝99，N ＝200，由式 （1）得QoSBasedAlg的公用虛擬機(jī)J 都為102；當(dāng)n＝4 時，T＝40，N＝200，M＝99，tr＝6s，代入式 （2）計算得協(xié)調(diào)虛擬機(jī)數(shù)量K 為3。類似地，當(dāng)n 分別為8、12、16、20 時由式（2）可計算得協(xié)調(diào)虛擬機(jī)的數(shù)量K 分別為5、7、9、11。實驗結(jié)果見表1。

表1 不同請求變化量下的實驗結(jié)果對比

從實驗結(jié)果中可以得出，在不同的請求變化量條件下， QoSBasedAlg算法都比BaseAlg有更少的SLA 違背及底層資源的使用量，并且QoSBasedAlg算法在各次實驗中的SLA違背率低于1%。同時，QoSBasedAlg算法的SLA 違背量也隨請求變化量的增長而增長。由2.2.1節(jié)的分析可知，當(dāng)各個租戶的請求變化量n更大時，在新的虛擬機(jī)生成期間，總的請求變化量Y 有更大的變化區(qū)間，故會有更多的SLA違背。

3.1.2 不同虛擬機(jī)生成時間對實驗的影響

在實驗下，主要看不同虛擬機(jī)生成時間對實驗的影響。設(shè)置租戶數(shù)量N 為200，請求變化量n 設(shè)置為12。虛擬機(jī)生成時間T 分別為20、30、40、50、60時，對比BaseAlg與QoSBasedAlg算法。初始時，在BaseAlg 實驗中有200個專用虛擬機(jī)。初始時，由式 （1）得QoSBasedAlg的公用虛擬機(jī)數(shù)量J 都為102；由式 （2）計算得協(xié)調(diào)虛擬機(jī)數(shù)量K 分別為5、6、7、8、8。實驗結(jié)果見表2。

從實驗結(jié)果中可以得出，在不同的虛擬機(jī)生成時間條件下，QoSBasedAlg算法都比BaseAlg有更少的SLA 違背及底層資源的使用量，并且QoSBasedAlg算法在各次實驗中的SLA 違背率低于1%。QoSBasedAlg算法的SLA 違背量受虛擬機(jī)生成時間變化的影響并不是很明顯。

3.1.3 不同租戶數(shù)量對實驗的影響

在實驗下，主要看不同租戶數(shù)量對實驗的影響。設(shè)置請求變化量n為12，虛擬機(jī)生成時間T 為40s。租戶數(shù)量N 分別為50、100、200、300、400、500時，對比BaseAlg與QoSBasedAlg算法。初始時，在各次實驗中，BaseAlg算法的專用虛擬機(jī)數(shù)量分別為50、100、200、300、400、500。初始時，在各次實驗中，由式 （1）得QoSBasedAlg算法的公用虛擬機(jī)的數(shù)量J 分別為26、51、102、152、203、253；由式 （2）計算得協(xié)調(diào)虛擬機(jī)數(shù)量K 分別為4、5、7、9、10、11。實驗結(jié)果見表3。

表2 不同虛擬機(jī)生成時間下的實驗結(jié)果對比

表3 不同租戶數(shù)量下的實驗結(jié)果對比

從實驗結(jié)果中可以得出，在不同租戶數(shù)量條件下，QoSBasedAlg算法都比BaseAlg有更少的SLA 違背及底層資源的使用量，并且QoSBasedAlg 算法在各次實驗中的SLA 違背率低于1%。同時，QoSBasedAlg算法的SLA 違背量也隨請求變化量的增長而增長。由2.2.1 節(jié)的分析可知，當(dāng)租戶數(shù)量N 更大時，在新的虛擬機(jī)生成期間，總的請求變化量Y 有更大的變化區(qū)間，故會有更多的SLA違背。

3.2 實驗分析及算法改進(jìn)

從實驗結(jié)果中可以得出，與BaseAlg算法相比，QoSBasedAlg算法使用更少的底層資源，達(dá)到了更少的SLA 違背。并且在每一次實驗中，QoSBasedAlg算法的SLA 違背率都低于1%，各個實驗條件下，其平均SLA 違背率甚至都低于1‰。實驗結(jié)果表明，在QoSBasedAlg 算法中，使用多租戶共用虛擬機(jī)的方式可以有效地節(jié)省底層資源，協(xié)調(diào)虛擬機(jī)機(jī)制和慢收縮策略可以有效地減少SLA 違背及改進(jìn)服務(wù)質(zhì)量。

通過實驗可以得到，在請求變化量更大、虛擬機(jī)生成時間更長、租戶數(shù)量更多時，QoSBasedAlg算法也趨向于產(chǎn)生更多的SLA 違背。一方面，由于實際的租戶請求量不可能為負(fù)數(shù)，故在每次請求發(fā)送時，對于請求量r 小于n的租戶，則在下一次請求發(fā)送時，這些租戶的實際請求發(fā)送量只能在 ［－r，n］之間變化，而不是在 ［－n，n］之間隨機(jī)變化。因此在實驗中，每次發(fā)送租戶請求時，總的租戶請求發(fā)送量往往呈現(xiàn)增長的趨勢。從實驗結(jié)果來看，QoSBasedAlg算法這種請求增長趨勢具有一定的適應(yīng)能力。另一方面，雖然在協(xié)調(diào)虛擬機(jī)數(shù)量滿足式 （2）的條件下，Y 的數(shù)量超出協(xié)調(diào)虛擬機(jī)處理能力的概率為0.82%，但仍然有可能會超出協(xié)調(diào)虛擬機(jī)處理能力。當(dāng)請求變化量更大、虛擬機(jī)生成時間更長、租戶數(shù)量更多時，在虛擬機(jī)生成時間內(nèi)總的租戶請求變化量Y 有更大的變化區(qū)間，超出協(xié)調(diào)虛擬機(jī)處理能力的請求量會更大，故SLA 違背量也更大。

需要指出的是，QoSBasedAlg算法的核心就是確定協(xié)調(diào)虛擬機(jī)的數(shù)量，因為它決定著是否能及時提取恰好足夠的資源來為租戶服務(wù)。如果協(xié)調(diào)虛擬機(jī)的數(shù)量相對不足，而實際的租戶請求變化量較極端的情況下，仍然會有可能出現(xiàn)SLA 違背率超出SLA 違背賠償率的情況。

為了能更好的提高服務(wù)質(zhì)量，QoSBasedAlg算法可以在以下方面做進(jìn)一步改進(jìn)。

對協(xié)調(diào)虛擬機(jī)的數(shù)量設(shè)置有兩種改進(jìn)方法。一種是靜態(tài)的措施，即增加協(xié)調(diào)虛擬機(jī)的數(shù)量，使得在虛擬機(jī)生成時間內(nèi)總的租戶請求變化量Y 落在協(xié)調(diào)虛擬機(jī)處理能力之內(nèi)的概率更大，由標(biāo)準(zhǔn)正態(tài)分布表可知Φ（3.0）＝0.99865，可令協(xié)調(diào)虛擬機(jī)數(shù)量K 滿足式 （3）

另外一種改進(jìn)的方法是動態(tài)的措施，即在協(xié)調(diào)虛擬機(jī)數(shù)量滿足式 （2）或Y 落在協(xié)調(diào)虛擬機(jī)處理能力之內(nèi)的概率較大的條件下，如果在單位時間 （如一個小時）內(nèi)放棄的請求量超出M 的h 倍 （h＞0）時，則生成一個新的協(xié)調(diào)虛擬機(jī)。在動態(tài)的方案中，并不是不允許有SLA 違背，而是將SLA 違背控制在一定的范圍內(nèi)。因為從正態(tài)分布的特點來看，Y 的值很大的可能性很小，要使得Y 完全在協(xié)調(diào)虛擬機(jī)的處理能力之內(nèi)的話，需要很多協(xié)調(diào)虛擬機(jī)，而大部分協(xié)調(diào)虛擬機(jī)往往大多數(shù)時間都處于閑置狀態(tài)，同樣也會造成資源的低效使用，而增加了成本。動態(tài)的改進(jìn)方案比靜態(tài)的改進(jìn)方案有更好的適用性。

對慢收縮策略也可以進(jìn)行改進(jìn)。在實驗中可以看到，仍然有公用虛擬機(jī)剛剛銷毀，又需要生成新的公用虛擬機(jī)的情況出現(xiàn)。一種改進(jìn)的策略是，在對虛擬機(jī)更新時，如果有空的公用虛擬機(jī)，則無條件的保留一定數(shù)量的空的公用虛擬機(jī)，記無條件保留的空公用虛擬機(jī)數(shù)量為G，而對超出G 的空公用虛擬機(jī)采用超時銷毀政策。G 的值可設(shè)置為，單次請求發(fā)送時的總的租戶請求變化量X 以較大概率落在G 個虛擬機(jī)的處理能力之內(nèi)。由2.2.1 節(jié)可知，X ～N（Nμ，Nσ2），又由μ ＝0，σ2＝n（n＋1），故有X ～N（0Nn（n＋1））。由標(biāo)準(zhǔn)正態(tài)分布表可知Φ（2.0）＝0.97725，可取G 的值滿足式 （4）

本文主要是針對各個租戶請求變化量在 ［－n，n］之間的隨機(jī)變化的情況進(jìn)行了分析驗證。實際的SaaS服務(wù)的各個租戶的請求變化量可能有各自的特點，并不一定服從［－n，n］之間的隨機(jī)分布。要推斷租戶的請求變化規(guī)律，以確定協(xié)調(diào)虛擬機(jī)的數(shù)量，并不是一件容易的事。此時，則可以使用動態(tài)的協(xié)調(diào)虛擬機(jī)生成方案，根據(jù)單位時間內(nèi)的SLA 違背量，動態(tài)的生成協(xié)調(diào)虛擬機(jī)，以控制單位時間內(nèi)的SLA 違背量低于預(yù)期值，進(jìn)而保證SLA 違背率低于SLA 違背賠償率。

4 結(jié)束語

本文提出的資源分配算法，利用SaaS應(yīng)用的多租戶特性，在各個租戶共用虛擬機(jī)資源的基礎(chǔ)上，將虛擬機(jī)分為兩類：公用虛擬機(jī)和協(xié)調(diào)虛擬機(jī)。通過公用虛擬機(jī)為多個租戶服務(wù)，以節(jié)省底層資源；通過協(xié)調(diào)虛擬機(jī)來處理增長的租戶請求，并根據(jù)其使用狀態(tài)來提取適當(dāng)?shù)馁Y源。本文采用慢收縮策略以防止租戶請求量減少之后再反彈。對照實驗結(jié)果表明，本文提出的資源分配算法可以最小化SLA違背及底層資源使用量。根據(jù)實驗結(jié)果，對算法提出了進(jìn)一步控制SLA 違背并改進(jìn)服務(wù)質(zhì)量的方法。

［1］Meng X，Isci C，Kephart J，et al.Efficient resource provisioning in compute clouds via VM multiplexing ［C］／／ACM International Conference on Autonomic Computing，2010：11－20.

［2］Das A K，Adhikary T，Hong C S.An intelligent approach for virtual machine and QoS provisioning in cloud computing［C］／／International Conference on Information Networking，2013：462－467.

［3］Calheiros R N，Ranjan R，Buyya R.Virtual machine provisioning based on analytical performance and QoS in cloud computing environments ［C］／／International Conference on Parallel Processing，2011：295－304.

［4］Gong Zhenhuan，Gu Xiaohui，Wilkes John.Press：Predictive elastic resource scaling for cloud systems ［C］／／International Conference on Network and Service Management，2010：9－16.

［5］Shen Zhiming，Subbiah Sethuraman，Gu Xiaohui，et al.Cloudscale：Elastic resource scaling for multi－tenant cloud systems［C］／／The ACM Symposium on Cloud Computing，2011.

［6］Compiere.Compiere ERP on cloud ［EB／OL］.［2014－03－10］.http：／／www.compiere.com／.

［7］Wu L，Garg S，Buyya R.Sla－based resource allocation for software as a service provider（SaaS）in cloud computing environments ［C］／／IEEE／ACM International Symposium on Cluster，Cloud，and Grid Computing，2011：195－204.

［8］Amazon EC2.Amazon elastic compute cloud ［EB／OL］.［2014－03－10］.http：／／aws.amazon.com／ec2／.

［9］Kang Seungseok，Myung Jaeseok，Yeon Jongheum，et al.A general maturity model and reference architechture for SaaS service ［G］.LNCS 5982：Database Systems for Advanced Applications，2010：337－346.

［10］SHENG Zhou，XIE Shiqian，PAN Chengyi，et al.Probability and mathematical statistics ［M］.4th ed.Beijing：Higher Education Press，2008（in Chinese）. ［盛驟，謝式千，潘承毅，等.概率論與數(shù)理統(tǒng)計［M］.4版.北京：高等教育出版社，2008.］

［11］Calheiros Rodrigo N，Ranjan Rajiv，Beloglazov Anton，et al.CloudSim：A toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms［J］.Software：Practice and Experience，2011，41（1）：23－50.