SaaS環境下基于服務質量的資源分配算法

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

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

0 引 言

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

在本文提出的算法中，利用SaaS服務的多租戶特性，采用多個租戶共用虛擬機的方式以節省底層資源。本文采用協調虛擬機處理增長的租戶請求，根據協調虛擬機的使用情況，以提取適當的虛擬機資源。采用協調虛擬機機制，可以更精確更及時地提取適當底層資源，以保證租戶的服務質量。在租戶請求減少時，本文則采用慢收縮策略來防止租戶請求量反彈。通過模擬實驗驗證了算法的有效性。

1 SaaS服務模型

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

圖1 SaaS服務的系統模型

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

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

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

2 資源分配算法

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

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

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

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

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

2.1 基本算法

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

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

在每個請求發送間隔結束時，對虛擬機更新的算法BaseAlg＿VmsUpdate如下：

當IaaS層生成了新的虛擬機時，需要對記錄虛擬機生成狀態的狀態值tenantVmCreating 進行更新，并將虛擬機加入到對應租戶的專用虛擬機列表中。其算法BaseAlg＿VmsCreated如下：

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

圖2 BaseAlg算法的虛擬機

2.2 基于服務質量的資源分配算法

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

2.2.1 虛擬機分類

在算法中，將虛擬機分為兩類：公用虛擬機和協調虛擬機。

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

協調虛擬機：當公用虛擬機已滿時，則使用協調虛擬機來處理租戶請求。協調虛擬機開始使用，則需要生成新的公用虛擬機，以應對租戶請求的增長。有多少個協調虛擬機在使用，則需要生成多少個公用虛擬機。

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

圖3 QoSBasedAlg算法的虛擬機

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

2.2.2 算法描述

在QoSBasedAlg算法中，用pubVmCrtCnt來記錄正在生成的公用虛擬機的數量。

算法初始值如下：pubVmCrtCnt的值為0，公用虛擬機的數量按式 （1）來確定，協調虛擬機的數量按式 （2）來確定。

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

圖4 請求處理流程

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

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

3 性能評估

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

3.1 性能測試

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

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

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

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

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

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

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

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

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

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

3.1.3 不同租戶數量對實驗的影響

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

表2 不同虛擬機生成時間下的實驗結果對比

表3 不同租戶數量下的實驗結果對比

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

3.2 實驗分析及算法改進

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

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

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

為了能更好的提高服務質量，QoSBasedAlg算法可以在以下方面做進一步改進。

對協調虛擬機的數量設置有兩種改進方法。一種是靜態的措施，即增加協調虛擬機的數量，使得在虛擬機生成時間內總的租戶請求變化量Y 落在協調虛擬機處理能力之內的概率更大，由標準正態分布表可知Φ（3.0）＝0.99865，可令協調虛擬機數量K 滿足式 （3）

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

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

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

4 結束語

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

［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）. ［盛驟，謝式千，潘承毅，等.概率論與數理統計［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.