一種云平臺彈性性能檢測方法

武文 李欣 張曉峰

摘 要：目前云計算平臺彈性性能越來越受到用戶重視。為了提升云平臺提供商的服務質量，保證用戶能夠準確獲取所購買云服務的彈性性能，基于目前云計算服務提供商的服務等級協議，從第三方角度提出一種量化分析方式，通過對云平臺CPU利用率進行實時檢測與計算，得出云平臺的實際彈性性能。利用Openstack開源云平臺進行仿真實驗，驗證設計工具的有效性，對用戶測試云平臺彈性性能有指導意義。

關鍵詞：云平臺;云平臺彈性;自動伸縮;工作負載;云計算

DOI：10. 11907/rjdk. 182453

中圖分類號：TP393文獻標識碼：A文章編號：1672-7800（2019）002-0165-04

Abstract： Currently， the elastic performance of cloud computing platforms is getting more and more attention from users. In order to enhance the service quality of cloud platform providers， we should ensure that users can accurately acquire the elastic performance of the purchased cloud services. In view of the service level agreement （SLA） of current cloud computing service providers， it is proposed from the perspective of third parties. Through the real-time detection and calculation of the CPU utilization of the cloud platform， the actual elastic performance of the cloud platform is obtained. Openstack is a open source cloud platform. It is used for simulation experiments to verify the effectiveness of the design tools and provide guidance for users to test the elastic properties of the cloud platform.

Key Words： cloud platform; cloud platform elasticity; autoscaling; workload; cloud computing

0 引言

云計算是目前較為完善的一種商業服務模式[1，2]?；ヂ摼W公司通過搭建云計算服務平臺，虛擬化計算、網絡、存儲等資源，依照按需付費方式將其出售給用戶使用。按需付費優勢在于用戶可以用更加合理的價格滿足需求，閑時可減少實例以降低開銷，忙時可增加實例以保證服務，是目前云計算能夠占據市場的根本原因。按需付費模式技術核心由云計算平臺的彈性服務保障。彈性是指云計算平臺的資源調配能力，能夠根據用戶需求自動增減資源以提供高效優質服務，是云計算服務平臺最為突出的一個特性[3，4]。

目前國內外對于云計算平臺彈性性能展開了大量研究。就彈性伸縮方式而言，其分為橫向伸縮和縱向伸縮[5]。橫向擴展基于分布式系統的發展而發展，因此它集成了許多分布式系統的優越性能，比如故障影響范圍小、易于開發擴展、技術成熟等[6，7]。而且，從自動擴展與手動擴展角度，橫向擴展方式也更易于機器自動完成擴展，縱向擴展難免會遇到停機維護升級的困擾[8，9]。但是，伴隨橫向擴展出現的是各虛擬機之間負載均衡問題與不同虛擬機之間任務分配問題，同時也會導致彈性計算性能的測量數值產生異動。Koperek[10]通過設置一種簡單的閾值判斷CPU負載是否超過80%，以判定是否觸發了預先彈性規則。Hasan[11]通過設置閾值上限和下限的方式進行判定。

本文提出一種量化監測云計算服務平臺彈性性能方案。通過對用戶租用虛擬機實例的各項基礎指標如CPU、帶寬、內存等進行監控，綜合判斷該運行實例是否正常工作，之后進行負載壓力測試，分別考察在高負載和低負載情況下，云計算服務平臺能否根據負載變化彈性分配資源給用戶，保證服務平穩運行。

1 彈性云服務現狀

目前國內云計算服務提供商有阿里云、騰訊云、華為云、360云、青云等，國外有亞馬遜、微軟、谷歌等，不同云服務商提供的產品性能有一定差異[12]。從各廠商產品的服務等級協議（Service-Level Agreement，SLA）或者服務介紹中獲取到一些基本信息，進行分析比對（見表1）。

在表1中，華為彈性云主機由于產品分類細粒度更高，包括通用型、內存密集型、計算密集型、存儲密集型、計算加速型5類，因此不同類型產品自動擴展實例上限數略有不同，在16～60臺之間。青云的最大自動擴展數在其產品介紹中并沒有提及，可以根據用戶需求自由定義。在計費方式上，所有云計算服務提供商都沒有對自動伸縮功能計費，而是將其計算在擴展或收縮的資源實例上。青云因為其服務更加精準實時，計費上采用了逐級非線性遞增方式，相較于其它云計算服務提供商使用相同資源實例，需要付出額外金錢。360云主機在其服務中使用了均衡負載技術，但是并不提供自動伸縮服務，需要手動操作。同時，其它云計算服務商均提供手動擴展或收縮資源實例服務，而且手動操作擴展的資源實例無法通過自動伸縮功能釋放資源，其實例擁有更高優先級。

在目前大多數云計算服務提供商的SLA中，彈性多表述為資源調配能力或自動伸縮性能[13]。從表1各項對比可以看出，不同云計算服務商提供的彈性服務性能不盡相同。因此需要對SLA中有關云彈性性能指標進行標準化定義以及檢測，便于對比不同云計算平臺提供的彈性性能優劣[14]。

2 彈性定義及指標量化

2.1 彈性定義

目前對于彈性定義有以下幾個方面觀點：NIST[15]提出云計算提供的快速彈性通過縮減或擴展資源實現。該定義強調彈性能力的實時與動態性，但是僅反映了理想狀態下的彈性。IBM[16]認為云計算系統資源的擴展或者縮減過程不需要人工操作，即自動實現，并認為彈性和擴展性是等同的。該定義著重關注彈性的自動化實現，但是將擴展性與彈性等同看待，沒有關注云平臺下資源的實時動態變化，而且全自動化實現就目前應用來看仍然不現實。ODCA將彈性定義為是一種解決云計算資源調度中能夠改變配置和進行擴展的方案，基于負載的增減改變云計算系統資源能力為彈性，關注了配置問題，并將其作為彈性能力的一部分，但其沒有反映云平臺彈性的實時性、動態性，不能體現其快速伸縮的特點[17]。Reuven[18]將彈性視為在本地與遠程資源組成的資源池中進行資源管理、測量、預測和調整適應并實時處理申請的一種可被計量能力。該定義認為彈性可以作為一種能夠被量化的能力反映，但未闡述清楚彈性如何被計量的問題。

本文對云平臺彈性性能的定義為：云服務提供商能夠在規定時間內根據用戶需求，動態分配資源，在性價比最優的同時，保證用戶服務正常運行。

2.2 彈性性能測量

云平臺彈性性能測量一般通過對運行實例的CPU、I/O、帶寬、內存等資源狀態進行分析，從而判斷云平臺的彈性性能是否滿足要求。本文通過對運行實例CPU指標研究進行彈性檢測。

從上述對各廠商彈性性能研究可以得知，一般云平臺彈性觸發時間都在5min以內。因此以5min為閾值，彈性反應時間超出閾值，則表明彈性不達標;在5min內完成彈性伸縮，則表明彈性達標。同時，對彈性性能等級進行劃分，超出時間越多，表明彈性性能越差;若發生系統宕機情況，則直接記為零分。

本文中，云平臺彈性性能記為Y，被測試運行實例CPU負載持續高于80%的時間為X，則云平臺彈性性能為：

3 彈性測試實驗

3.1 彈性檢測原理

本文通過對云平臺上運行實例的CPU狀態進行分鐘級實時監測，同時進行數據分析，判斷其能否在不同負載情況下實時觸發云平臺彈性性能，保證服務正常運行。

首先運行Linux系統下性能監控工具sar，獲取該實例的CPU使用狀態，時間間隔設置為每分鐘檢測一次，并將檢測數據保存在以該時間命名的日志文件中。然后設置一段檢測時間，本文選擇1 000s，大于一般彈性觸發所需時間5min，保證了合理觸發時間。最后通過awk語句對采集到的日志文件進行數據處理，判斷云平臺彈性性能是否及時觸發。

如果運行實例的CPU負載在80%以上，且持續時間超過5min，那么判定云平臺并沒有按照要求觸發彈性性能，不能保證服務正常運行。如果運行實例的CPU負載在達到80%之后，5min內逐漸回落到80%以下，那么說明云平臺及時觸發了彈性性能，保證了服務正常運行。如果運行實例的CPU負載一直低于80%，說明負載壓力給予不夠，應該提升負載壓力。

3.2 負載設計

云計算中常見負載類型有起伏可控的平穩型、可以預知的漸變型、不可預知的激變型3種[19]。其分別對應云平臺運行時彈性服務的3種狀態：非觸發彈性狀態、手動調整伸縮組狀態以及自動伸縮彈性狀態。

起伏可控的平穩型一般出現在客戶服務淡季，資源需求量較低，在一定時間內云平臺上的負載變化很小。如12306鐵路部門在運行服務淡季，網易、騰訊等游戲服務商在工作日時間。

可以預知的漸變型是指云計算服務提供商能夠通過分析判斷或者前期經驗總結，提前對接下來一段時間內可能發生的負載變化進行預判，用戶通過手動添加伸縮組的方式保證服務正常運行。如游戲提供商在工作日19-22點以及周末大型游戲活動期間，高校選課系統在學期初學生選課期間。

不可預知的激變型通常出現在用戶業務量暴增期間，用戶并不清楚自己將在接下來一段時間內可能接受到多大負載量。如新開發某款APP突然變得火爆，運營商如果沒有接入云架構做好準備，就很可能由于突增的訪問導致業務崩潰;淘寶在“雙十一”活動期間、12306在春運或者旅游黃金周之前，雖然都會有一定分析預判，但是仍然無法獲知具體業務量大小。

3.3 核心代碼實現

核心代碼實現如下：

4 實驗仿真與分析

4.1 實驗環境

實驗環境為利用Openstack開源資源搭建的一個測試云平臺，實例上運行的操作系統為64位Ubuntu14.04。

表2中，os01上部署的主要是各部件控制器，包括計算節點nova、網絡節點neutron、塊存儲節點cinder、對象存儲節點swift;os02、os03為計算節點;os04、os05、os06為存儲節點ceph;os07為身份認證管理系統Keystone;os08為服務頁面Web;os09、os10為測試實例。

4.2 實驗過程與數據分析

通過3種實驗，在前文提出的3種不同負載情況下對云平臺彈性性能進行測試。

實驗一：開啟os10，利用loadrunner對os09運行實例的CPU進行加壓，使其CPU利用率介于30%～80%之間，持續1 000s。

實驗二：開啟os10，利用loadrunner對os09運行實例的CPU進行線性加壓，使其CPU利用率逐步達到80%，持續1 000s。

實驗三：將os10關閉并脫離云計算平臺，利用loadrunner對os09運行實例的CPU進行加壓，模擬暴增壓力，極短時間內使其CPU利用率達到80%以上，持續1 000s。

如圖1所示，為方便集中展示，將處理結果統一保存在文件result.txt中，并將其反饋到控制主機Os01，可以根據實驗次序分別查看。在實驗一中，由于loadrunner產生的負載壓力不足，沒有達到云平臺觸發彈性要求，因此并沒有觸發彈性規則。在實驗二中，由于Os09實例的CPU負載超過了80%，在規定時間5min內觸發了彈性規則，通過均衡負載降低了CPU利用率，因此滿足彈性要求，彈性指數為100%。在實驗三中，由于提前關閉了備用彈性實例os10，因此在os09實例的CPU利用率達到80%后無法觸發彈性規則，在1 000s內其利用率一直高達80%以上，所以根據公式計算得知彈性指數為31.3%。

綜上所述，該檢測工具能夠正確檢測云平臺彈性性能。

5 結語

本文提出一種基于第三方的云平臺彈性性能檢測工具，算法通過對連續時間內用戶實例CPU的負載情況進行監控分析，判斷該云平臺彈性性能是否有效，為云計算彈性性能檢測提供了技術保障[20]。但是該工具還存在一定缺陷：僅部署在一個運行實例上，因此無法獲取其它實例的運行情況，不能完整得出整個云平臺的彈性性能。同時，單一CPU檢測僅能從一個側面反映實例的運行情況。因此，下一步研究重點為多運行實例和多指標檢測分析與算法優化。

參考文獻：

[1] ARMBRUST M，FOX O，GRIFFITH R，et al. Above the clouds：a berkeley view of cloud computing[J]. Eecs Department University of California Berkeley，2009，53（4）：50-58.

[2] LIMRUNGSI N，ZHAO J，XIANG Y，et al. Providing reliability as an elastic service in cloud computing[C]. IEEE International Conference on Communications，2012，11（18）：2912-2917.

[3] CALHEIROS R N，TOOSI A N，VECCHIOLA C，et al. Acoordinator for scaling elastic applications across multiple clouds[J]. Future Generation Computer Systems，2012，28（8）：1350-1362.

[4] MOLDOVAN D，COPLI G，TRUONG H L，et al. Mela：monitoring and analyzing elasticity of cloud services[C]. Cloud Computing Technology and Science，2013，1：80-87.

[5] SHARMA U， SHENOY P， SAHU S， et al. Kingfisher： a system for elastic cost-aware provisioning in the cloud[J]. Infocom，IEEE，2011，28（6）：206-210.

[6] KHATUS S， GHOSH A， MUKHERJEE N. Optimizing the utilization of virtual resources in Cloud environment[J]. IEEE International Conference on Virtual Environments Human-computer Interfaces & Measurement Systems，2010：82-87.

[7] GHANBARI H， SIMMONS B， LITOIU M， et al. Optimal autoscaling in a IaaS cloud[C]. International Conference on Autonomic Computing ACM，2012：173-178.

[8] GALANTE， GUILHERME， BONA L C E D. A survey on cloud computing elasticity[C]. IEEE Fifth International Conference on Utility and Cloud Computing，2013：236-270.

[9] COUTINHO E F， SOUSA F R D C， REGO P A L， et al. Elasticity in cloud computing： a survey[J].? Annals of Telecommunications，2015，70（7）：289-309.

[10] KOPEREK P，FUNIKA W. Dynamic business metrics-driven resource provisioning in cloud envuionments[C]. International Conference on Parallel Processing and Applied Mathematics，2016：171-180.

[11] HASAN M Z， MAGANA E， CLEMM A， et al. Integrated and autonomic cloud resource scaling[J]. Network Operations & Management Symposium，2012，104（5）：1327-1334.

[12] 王曉鈺. 基于云平臺可彈性擴展的Web應用系統的研究與實現[D]. 北京：北京郵電大學，2018.

[13] 徐勁松. SLA約束下的云資源調度關鍵技術研究[D]. 南京：南京郵電大學，2011.

[14] 李喬，鄭嘯.? 云計算研究生現狀綜述[J]. 計算機科學，2011，38（4）：32-37.

[15] MELL P，GRANCE T.The NIST definition of cloud computing[J]. Communications of the ACM，2011，53（6）：50.

[16] SCHOUTIOU E. Rapid elasticity and the cloud，September 2012[EB/OL]. http：//thoughtsoncloud.com/index.php/2012/09/rapid-elasticity-and-the-cloud.

[17] 邊爽. 云計算系統資源彈性調度的評測方法研究[D]. 哈爾濱：哈爾濱工業大學，2015.

[18] COHEN R. Defining elastic computing，September 2009[EB/OL]. http：//www.elasticvapor.com/2009/09/defining-elastic-com-putting.html，2013.

[19] 陳龍，張國慶，陳寧江，等. 可區分服務的反饋式Web應用負載均衡策略[J]. 廣西大學學報：自然科學版，2012，37（6）：1170-1176.

[20] 楊祥宏. 基于IaaS云平臺的性能評測與建模方法研究[D]. 杭州：杭州電子科技大學，2016.

（責任編輯：何 麗）