摘 要: 提出了一種評價云中心綜合性能指標的分析架構。基于性能代理和服務接口方式(PASI)建立分析架構,該接口方式由性能客戶端(PMC)、性能代理(PMA)和性能服務端(PMS)組成(CAS),并提出了一個基于排隊原理的數學模式來論證這個方法的可行性。實驗結果表明,以PASI 模式對云中心性能指標進行采集和評估的方式是非常有效的。
關鍵詞: 云計算;排隊原理;性能分析;采集模式
云計算使得通過運用分布式組件海量池建立高性能應用成為可能。對于一個致力于優化為獲取應用服務、信息和存儲以及計算能力相關服務預算為其主要戰略的企業來說,這將成為不可或缺的一部分。伴隨著對云計算架構的需求性和復雜性的增加,性能分析和管理熱點引起了業界強烈的關注。
雖然業界在定義云概念存在著分歧,但仍可以找到一些共同的關鍵點[1]。首先,云計算是特定的分布式計算范疇。它與傳統分布式計算的區別在于:(1)可大批量升級的;(2)可以被封裝為一個抽象的實體以向云外部用戶傳遞不同水平的服務;(3)強烈地受到經濟規模的驅動;(4)其服務可以通過虛擬化或其他途徑被動態配置和按需分發[2]。由于云計算主要被定義為服務層面,所以它應該提供穩固和平滑的服務,并避免發生由于請求消息及任務激增而引起的執行需求超過云中心響應處理能力的情況。
綜上所述,能提供充足云組件的性能信息是非常必要的,并且建立高質量云計算服務很明顯已經成為一個重要的研究領域[3]。
一個典型的云計算應用通常由多種云組件組成,它們之間主要通過應用程序接口來進行相互通信[4],本文提出了一個由客戶端及服務端模式組成的系統級性能收集架構。從部署于不同云組件性能客戶端(PMC)的性能代理(PMA)獲取相關參數,并且采集和匯聚這些數據部署在云計算任務隊列管理簇的性能服務端(PMS)中。
1 相關工作
近些年,性能分析已經成為云計算相關眾多領域中的研究熱點。對云計算性能分析的研究工作按照研究對象可以分為如下幾類:對云計算中心的性能分析、對云計算應用層面的性能分析以及對云計算組件的性能分析。并且可以按照實施切入點被識別為兩個層面:性能預測和性能實時狀態檢測[5]。
云計算的性能分析模型可以被描述為一個近似分析模型,該模型建立在阻塞預警控制和完全拒絕策略為保證的前提下[6]。
這里展現了一個典型的云環境,它包括了數以千計的云服務端(宿主機),每一個都能被嵌入一定數量的獨立的或內部交互的虛代理(虛擬機),并且服務可以被恰當地分布在不同的虛擬機或宿主機上。本文關注重點在于云計算應用的性能分析測量。
下面詳細說明這種針對云計算應用和組件的性能分析方法。就像計算網格用來在小數據集上處理大量的計算密集型問題一樣,它展現了結合若干抽象任務的復雜功能的實現。每一個任務都可以從一系列功能相同的候選組件中選擇一個優化的云計算組件。云計算應用通過構建可選組件為任務執行實施提供保障,候選組件分布于不同的區域,并能被通過通信鏈接所調用。本文提出了一個性能監控背景下的控制和預測模型,用來監控云計算組件中的用戶側實時性能,目標是獲取云計算環境中更準確的性能分析結果。
在本文中,焦點是基于PASI模式下的性能相關數據的收集。通過基于該模式收集的性能數據與之前的數據的完整性和有效性相比,證明該模式的效用。
2 基于云計算環境的PASI模式
如圖1所示,性能客戶端、代理和服務端信息收集架構建立在云宿主機和云虛擬機的門戶應用部署之上。PMS應用是嵌入在云門戶中的,它主要由宿主機隊列映射表組成,該主機映射表包括了宿主機以及運行于其中的虛擬機性能信息等。應用執行模塊需要在選擇前在未使用的網絡服務中基于其服務質量進行預測。通常,這種預測基于其他的應用執行經驗。性能數據從部署于宿主機的代理應用收集而來,而代理的這些數據又從部署于虛擬機的客戶端應用獲取而來。因為從用戶側角度來看,所有以評估為目的而設立的可用云組件都是奢侈和不實際的, 性能服務端的性能管理表包括了主機映射表、主機數據表、主機占用或閑置表等。
另外置于主機映射表的關鍵信息包括虛擬機映射表、數據表、占用或閑置表、當前數據表、歷史15 min數據表以及歷史24 h數據表等。存在于性能表中的關鍵數據主要包括采樣請求周期時間、周期中空閑時間、周期中平均請求時間和周期內請求平均失敗率。并且數據組織粒度主要按照當前15 min、當前24 h、歷史15 min和歷史24 h來設置。
性能客戶端上報的性能數據來源于虛擬機,并被部署于宿主機的性能代理接收捕獲。性能代理在采集周期內計算上報數據,繼而在采樣周期到達時將數據同步到性能服務端。性能數據傳輸到性能服務端后將被統一計算匯總,并按照排隊論原理模型產生最終的統計信息。所有性能客戶端嵌入在不同虛擬機中,這些虛擬機分布在單個云節點或多個云節點中,性能代理便運行在其中。
由于面向的是基礎設施即服務(IAAS)類型,從而需要廣泛地吸收云計算資源,獲取準確的性能評估信息,以滿足要求。即允許服務提供者在其資源上標明可用標簽,以達到其用戶需求。
3 模式架構和分析
從虛擬機簇采集性能信息數據并加以分析。云計算組件的響應時間指從請求到達虛擬機到響應結束的時間、性能客戶端解碼時間以及對CPU利用率、內存利用率等相關信息進行處理的時間。
如圖2所示,性能代理端收到從性能客戶端轉發來的數據,接著進行統計處理。當一個15 min周期到達后,性能代理端將把本周期內的完全統計數據進行打包,并轉發給性能服務端。這里的信息包括了性能客戶端每一個周期片段響應上報后被性能代理端處理過后的數據,這部分信息涵蓋了周期性請求采樣時間、周期內空閑時間總和、周期內平均請求時間以及相應性能客戶端周期內平均請求失敗率。在性能服務端獲取到從性能代理端發送的性能信息數據后,這些數據將被累加統計到當前24 h數據中,如果條件達到則會一并同步到歷史15 min和歷史24 h隊列中。當然通常的用戶請求響應將被開啟的實時監控任務所處理。
采用排隊原理作為獲取虛擬機周期內平均運行總時間結果的抽象模式。為了獲取最大網絡效益,被服務端統計和統一安排的數以千計的可用客戶端隊列被登記在空閑表中。按照消費能力將被請求的應用合理地安置到可用計算服務單元是非常重要的。
4 數字化論證
通過實驗論證上述數學過程,且通過不同的配置來估算外部請求到達與y個性能客戶端處理系統的概率x之間的關系。在配置1中,性能客戶端以平均到達率θj=1接收到請求,并且以配置2平均到達率θj=1+(j+1)×Pr進行試驗,Pr是部署系數。定義Tm為指定周期內的負載率, 數字驗證結果SE(i)和Dcloud為CAS系統中持續運行態概率和平均負載度。部署不同的參數配置作為試驗的條件,如表1~表4所示。
綜上可以給出TM、SE和DQ/D配置效果間關系,如圖3所示。
從表1~表4,可得到如下結論:y、K、θ、σ的改變對TmQ/D的結果產生了明顯的影響,而TmQ/D的結果改變將引起DQ/D的變化。
本文中描述了IAAS模式下基于代理服務接口的云計算性能信息采集模型。在這種模型下,可以從客戶端、代理端及服務端獲取性能信息,并最終通過它們獲得云中心的平均負載度。云中心系統可以通過其門戶調整云計算組件的組成。
將來的工作將把注意力重點轉向基于云計算性能分析模型的反壓機制以及相應的調整策略上。
參考文獻
[1] SYS-CON Media Inc.Twenty experts define Cloud Computing[S].2008.
[2] FOSTER I,Zhao Yong,RAICU I,et al.Cloud Computing and Grid Computing 360-degree compared[C].Grid Computing Enviroments Worksshop.2008.
[3] Zhang Yilei,Zheng Zibin,LYU M R.Real-time performance prediction for Cloud Components[C].2012 IEEE 15th International Symposium.2012.
[4] GOSWAMI V,PATRA S S,MUND G B.Performance analysis of Cloud with Queue-dependent virtual machines[C].RAIT-2012.
[5] KHAZAE H.Performance analysis of Cloud centers under burst arrivals and total rejection Policy[C].IEEE Globecom 2011 Technical Symposium Program.2011.
[6] RAAJESWARI R,SELVARANI.A performance analysis method for service-oriented Cloud applications(SOCAs)[C].Coimbatore,INDIA.2012.