SaaS環(huán)境下基于服務(wù)質(zhì)量的資源分配算法

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

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

0 引 言

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

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

1 SaaS服務(wù)模型

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

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

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

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

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

2 資源分配算法

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

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

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

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

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

2.1 基本算法

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

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

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

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

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

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

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

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

2.2.1 虛擬機(jī)分類

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

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

協(xié)調(diào)虛擬機(jī)：當(dāng)公用虛擬機(jī)已滿時(shí)，則使用協(xié)調(diào)虛擬機(jī)來(lái)處理租戶請(qǐng)求。協(xié)調(diào)虛擬機(jī)開(kāi)始使用，則需要生成新的公用虛擬機(jī)，以應(yīng)對(duì)租戶請(qǐng)求的增長(zhǎng)。有多少個(gè)協(xié)調(diào)虛擬機(jī)在使用，則需要生成多少個(gè)公用虛擬機(jī)。

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

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

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

2.2.2 算法描述

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

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

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

圖4 請(qǐng)求處理流程

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

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

3 性能評(píng)估

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

3.1 性能測(cè)試

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

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

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

3.1.1 不同請(qǐng)求變化量對(duì)實(shí)驗(yàn)的影響

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

表1 不同請(qǐng)求變化量下的實(shí)驗(yàn)結(jié)果對(duì)比

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

3.1.2 不同虛擬機(jī)生成時(shí)間對(duì)實(shí)驗(yàn)的影響

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

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

3.1.3 不同租戶數(shù)量對(duì)實(shí)驗(yàn)的影響

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

表2 不同虛擬機(jī)生成時(shí)間下的實(shí)驗(yàn)結(jié)果對(duì)比

表3 不同租戶數(shù)量下的實(shí)驗(yàn)結(jié)果對(duì)比

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

3.2 實(shí)驗(yàn)分析及算法改進(jìn)

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

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

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

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

對(duì)協(xié)調(diào)虛擬機(jī)的數(shù)量設(shè)置有兩種改進(jìn)方法。一種是靜態(tài)的措施，即增加協(xié)調(diào)虛擬機(jī)的數(shù)量，使得在虛擬機(jī)生成時(shí)間內(nèi)總的租戶請(qǐng)求變化量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)的方法是動(dòng)態(tài)的措施，即在協(xié)調(diào)虛擬機(jī)數(shù)量滿足式 （2）或Y 落在協(xié)調(diào)虛擬機(jī)處理能力之內(nèi)的概率較大的條件下，如果在單位時(shí)間 （如一個(gè)小時(shí)）內(nèi)放棄的請(qǐng)求量超出M 的h 倍 （h＞0）時(shí)，則生成一個(gè)新的協(xié)調(diào)虛擬機(jī)。在動(dòng)態(tài)的方案中，并不是不允許有SLA 違背，而是將SLA 違背控制在一定的范圍內(nèi)。因?yàn)閺恼龖B(tài)分布的特點(diǎn)來(lái)看，Y 的值很大的可能性很小，要使得Y 完全在協(xié)調(diào)虛擬機(jī)的處理能力之內(nèi)的話，需要很多協(xié)調(diào)虛擬機(jī)，而大部分協(xié)調(diào)虛擬機(jī)往往大多數(shù)時(shí)間都處于閑置狀態(tài)，同樣也會(huì)造成資源的低效使用，而增加了成本。動(dòng)態(tài)的改進(jìn)方案比靜態(tài)的改進(jìn)方案有更好的適用性。

對(duì)慢收縮策略也可以進(jìn)行改進(jìn)。在實(shí)驗(yàn)中可以看到，仍然有公用虛擬機(jī)剛剛銷毀，又需要生成新的公用虛擬機(jī)的情況出現(xiàn)。一種改進(jìn)的策略是，在對(duì)虛擬機(jī)更新時(shí)，如果有空的公用虛擬機(jī)，則無(wú)條件的保留一定數(shù)量的空的公用虛擬機(jī)，記無(wú)條件保留的空公用虛擬機(jī)數(shù)量為G，而對(duì)超出G 的空公用虛擬機(jī)采用超時(shí)銷毀政策。G 的值可設(shè)置為，單次請(qǐng)求發(fā)送時(shí)的總的租戶請(qǐng)求變化量X 以較大概率落在G 個(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）

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

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

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