云應用引擎的資源監控和計費機制研究

任怡，張菁，陳紅，吳慶波，孔金珠，戴華東，管剛

（1. 國防科學技術大學 計算機學院, 湖南 長沙 410073；2. 騰訊研究院，北京 100080）

1 引言

按照服務交付模式的不同，云計算分為軟件即服務（SaaS, software as a service）、平臺即服務（PaaS,platform as a service）和基礎架構即服務（IaaS,infrastructure as a service) 3個層次。其中，PaaS平臺作為云應用引擎，為分布式或互聯網應用開發者提供一個透明、安全、高效的應用開發和運行環境，提供應用所需的各種核心功能，并支持將開發的應用程序部署到該平臺上。目前，商用PaaS平臺的典型代表包括GAE(google app engine)、Salesforce.com的Force.com、微軟的Azure等，開源的PaaS平臺主要是AppScale。

PaaS平臺資源規模龐大、管理集中、支持大量用戶并發請求，為保證其穩定高效運行，資源監控功能必不可少。資源監控可以實現對平臺內各種資源使用和負載情況的有效監測，并為資源動態部署和負載均衡提供依據；通過對系統資源實時監控，提取平臺資源使用信息，便于更好地完成系統資源的分配和管理。與此同時，作為商用PaaS平臺獲取和掌握用戶使用資源情況的最直接途徑，資源監控功能也為客觀、公正、合理地進行資源計費起到了不可替代的作用，它是PaaS平臺向用戶收取服務費用的最根本數據來源。

AppScale的開發和運行接口與GAE兼容，是具有代表性的開源云應用引擎平臺[1～3]。以AppScale為研究平臺，分析了其架構及特點，探討了其資源監控功能的實現機理和不足。在研究已有云計算平臺計費策略的基礎上，基于AppScale資源監控機制，采用Ruby on Rails Web架構，設計和開發了具有進程級資源監控和面向多租戶的資源計費功能的CloudMB。

2 AppScale云應用引擎的組成與架構分析

AppScale平臺與GAE的開發和部署接口兼容，實現并擴展了GAE的 SDK及其開放API。AppScale可自動、透明地運行于Amazon EC2和Eucalyptus等云基礎架構之上，其目標一方面是在應用部署到GAE平臺前，向用戶提供一個部署、測試、調試、估量、監控GAE應用的PaaS平臺，使其可在自身集群之上運行和驗證GAE應用，另一方面是在服務、運行時環境與底層云基礎設施的互操作方面對PaaS平臺進行擴展。

AppScale的開源、兼容GAE應用、便于搭建私有云、適于實驗等特點，使其適用于針對云計算PaaS平臺各項功能實現的研究工作。另外，該平臺提供了普適而完善的資源監控系統，對研究云計算平臺的資源監控十分具有代表性。

2.1 AppScale平臺組成

AppScale平臺由工具包、AppServer（AS）、AppLoadBalancer（ALB）、AppController（AC）、AppDB（application distributed database support）等組成。

工具包提供命令行和Web界面工具支持，系統管理員可以通過上述工具配置、啟動、停止AppScale實例、上傳/移除部署的應用、監控資源/應用的狀態。該工具支持在基于Xen的虛擬集群、EC2或Eucalyptus上部署AppScale平臺。

AS是應用程序的執行引擎，它通過HTTPS協議與AppDB交互來存儲和訪問數據。每個AS一次只可執行一個應用程序。為了托管多個應用程序，可以添加多個AS。

AC負責啟動、初始化、停止AppScale實例，支持AppScale各組件之間進行交互（系統中的所有通信均通過SSL加密）。

ALB負責初始化用戶與AS中運行的應用之間的連接，即在用戶成功登錄后，將請求路由給指定的、唯一的 AS以便為該應用程序實際處理請求，ALB不參與用戶應用請求的處理。因此，通過記錄用戶被指定的AS所執行過的應用信息，便可以對用戶應用情況進行統計。

AppDB分為DBM（database support master）和DBS（data base support slave）2種。前者實現AS與多種數據存儲之間的透明訪問，后者代表具體的數據存儲服務。

在上述組件的基礎上，AppScale還支持Memchache、Email、數據存儲、內嵌認證、Hadoop等服務。通過在AS與數據存儲實體之間引入與GAE兼容的協議緩沖服務器（PBS, protocol buffer server），實現了AS到多種分布式數據存儲機制之間的接口映射。目前，數據存儲服務支持Cassandra、Voldemort、MySQL、MongoDB、MemCacheDB、HBase、HyperTable 7種數據存儲機制。

2.2 AppScale平臺架構

每個AppScale實例被部署在一個到多個虛擬操作系統實例（即客戶VM）之上。其中，客戶VM是運行在Xen VMM、KVM或EC2/Eucalyptus之上的虛擬Linux系統，每個客戶VM也稱一個節點。每個AppScale實例中包括一個ALB、一個或多個AS、一個DBM、一個或多個DBS。其中，ALB所在的節點被稱作是頭節點（head node）,在一個AppScale平臺部署中，只能有一個頭節點實例。AC被部署在每個節點上，頭節點上的AC還負責監控和管理資源的使用、從其他節點周期地收集應用程序信息、節點的使用、根據系統需要和開發人員的要求增加和收縮AppScale部署的節點數量、監視系統中是否有故障節點、在需要的時候重啟故障組件和重新生成節點。DBM通過PB（protocol buffer）Datastore API訪問PB Server，后者會訪問DBS，不同的DBS代表不同的數據存儲機制。

AppScale的組成和部署結構如圖1所示，系統各組成部分之間的通信分為3類：1）各個節點上不同AC之間的通信；2）AppScale工具相關的交互；3）用戶與所部署Web應用之間的基于HTTPS的通信。

圖1 AppScale的組成和部署結構

2.3 AppScale平臺的資源監控

AppScale平臺節點部署采用主從式結構，主節點負責應用的負載均衡，從節點負責計算和存儲服務。同樣，其監控架構也是采用集中式的，由主節點定時向從節點獲取監控數據，并保存在主節點上，而從節點只是定時將監控數據傳送給主節點。AppScale通過整合資源監控工具Collectd及環狀數據庫工具RRDtool（round robin database tool）實現資源監控、狀態存儲及資源使用情況的可視化。

Collectd以后臺守護進程的形式運行于各個節點上，主動以周期性的方式從工作節點獲取CPU、內存、磁盤、網絡等監控數據。Collectd具有良好的性能和可移植性，支持網絡、RRDtool、Process、Exec等多種插件，功能靈活多樣，但不能將監控到的數據可視化成統計圖形。為監控和收集各個節點的資源，需在對應節點加載Collectd的相應資源插件；為了將監控數據傳送到主節點并保存，則需加載其網絡插件，該插件利用多播技術可以保證每個節點之間通信；為利用RRDTool在主節點上存儲并用圖形顯示監控的數據，需在主節點上加載RRDtool插件，將各節點上收集的數據完整地存儲在其固定大小的.rrd數據庫文件中，并支持以圖表方式顯示。AppScale資源監控實現原理如圖2所示。

圖2 AppScale資源監控的實現原理

3 主流云平臺計費方法分析

在云計算環境下，眾多企業等用戶摒棄固有的購買服務器、存儲設備的模式，轉向選擇更富有靈活性的服務模式。在該模式下，云計算提供商亟需解決的重要問題之一就是該商業模式下的計量、定價和收費等核心問題。

傳統網絡環境中，服務器、存儲等設備以私有財產的方式存在，用戶只需一次性投入，之后需付給第三方的服務費用主要包括網絡使用費等。傳統網絡計費模式存在基于時長的計費、基于流量的計費、基于服務質量的計費和基于內容的計費等多種模式[4]。其中，基于時長的模式由于具有簡單、計費成本低的特點而被廣為采用。而考慮到了網絡資源的稀缺性，基于流量的計費考慮了資源的實際使用量，基于服務質量的計費考慮應用對網絡的不同要求，基于內容計費則考慮了各種業務所具有的不同商業價值。

在云計算環境下，計費不再只是對網絡資源進行計費，而是涉及更多的軟硬件資源，更多的資源類型和計費因子給云計算平臺的計費帶來了挑戰——從所需存儲空間、到所使用的時間周期、再到每個月的流量分配、以及SLA隱性因素等，還需要考慮到不同的服務類型和特色。

3.1 IaaS平臺的計費方法

IaaS云平臺的重要推動者Amazon公司向用戶提供了彈性計算云EC2、簡單存儲服務S3、彈性MapReduce、CloudFront、SimpleDB、關系數據庫服務、簡單隊列服務SQS、云資源監控服務CloudWatch、虛擬私有云等多個層面的云產品。其中，在IaaS層面，彈性計算云EC2和簡單存儲服務S3成為其營收的兩大來源，這2種服務的計費模式很大程度上代表了IaaS平臺的主流模式。

Amazon將全球劃分為若干個地理區域，對于不同區域，其數據中心提供的服務收費有所區別。Amazon提供費用計算器供用戶評估需求與預算，支持針對不同產品的計費策略，提供計費和支付服務Amazon FPS和DevPay。由于EC2和S3本身產品形式不同，其計費模式也不同。

1) Amazon EC2的計費[5]

Amazon EC2提供給用戶的是計算資源，其交付物表現為定制的虛擬機實例。EC2向用戶提供按需型（on-demand）、預約型（reserve）和限價型（spot）三個類型的計費模式。

按需型：無須支付預付費用，按時長計費，且可通過Auto Scaling功能自動增刪所租用的虛擬資源，適用于“即買即用”的短期用戶。

預約型：按時長計費，與按需型不同之處在于需簽訂長期合同（如1年），并預支一定費用，此后的實際使用中仍按時長收費，但平均單價低于按需型收費，服務等級高于按需型。

限價型：根據供求情況周期性地發布即時價格，而用戶也給出可接受的最高價格。當用戶最高限價低于即時價格時，系統自動終止服務，否則為用戶提供所需服務。該計費模式使得用戶以較低價格充分利用系統的閑散資源，適合于需要大量計算能力但對計算響應要求不高的用戶。

Amazon EC2提供標準、小型、高內存、高CPU、集群、集群GPU共6種類型的定制虛擬機實例，每種實例按照不同規格還可細分為若干種，每一種按時長計費的定價有所區分。目前，定制虛擬機所支持的操作系統有Redhat企業級Linux、Windows Server、Oracle企業級 Linux、SUSE企業級 Linux和Amazon Linux AMI，同時安裝了DBMS、Web服務器、資源管理、應用服務器、媒體播放等軟件。

2) Amazon S3的計費[6]

Amazon S3是一種安全、可靠、可伸縮的在線存儲服務，用戶可通過授權訪問其標準Web接口來隨時存儲及獲取存放在Amazon數據中心中的數據。使用S3的費用包括存儲費用、請求費用和數據遷移費用。存儲費用由選定的數據中心、服務質量等級和數據量確定；請求費用由選定的數據中心、各種存儲請求的種類和數量確定；數據遷移費用則是由數據量決定（受數據源和目的地影響）。

目前S3提供2種服務質量等級。

標準存儲（standard storage)：提供99.99%的可用性保障，一年的數據丟失率不高于0.000 000 001%，可以從2個存儲設備同時失效中恢復，該級別用以存儲關鍵數據。

去冗余存儲（RRS, reduced redundancy storage)：提供99.99%的可用性保障，一年的數據丟失率不高于0.01%，可以從一個存儲設備的失效中恢復，價格相對便宜，該級別用于存儲重要程度相對較低的數據，如圖片緩存等。

目前，針對S3，Amazon將數據量從1TB到數千TB以上劃分為若干計費區間，不同區間價格不同；數據量越大，存儲費用單價越低。

對訪問請求計費的原因很大程度上是對基于S3的分布式存儲應用開發者的一種制約，促使其采用訪問數較少的設計，達到優化S3訪問量的目的，價格相對低廉。將請求分為2種定價，第一種包括PUT、COPY、POST、LIST請求，第二種包括GET和其他請求。

數據傳入、傳出流量主要是指跨數據中心的數據遷移費用，同一數據中心內部的數據遷移不收費。數據遷移采取單向收費原則，通常數據傳入流量單價按0計算，數據傳出流量單價隨著數據量的增大而降低。

3.2 PaaS平臺的計費方法

與IaaS層相比，PaaS平臺的計費不僅僅局限于虛擬機操作系統或存儲等層面，還涉及應用層的進程、調用等細粒度的資源監控和計費。目前，在PaaS領域，GAE占據著主導地位，其計費模式也具有典型的代表性[7]。

GAE早期采用較為簡單的計費標準，分別對傳出/傳入帶寬（以千兆計）、CPU時間（以小時計）、存儲數據（以千兆字節×月計）、接收電子郵件的接收人等計費，低于限額以下免費使用，超出部分單價固定且收費的資源單位粒度較大。支持配額管理，允許用戶設置最高預算閥值，從而資源使用會控制在預算以內。

2011年9月，Google宣布將結束預覽期，正式對外收費，其計費模式和資費標準也發生了調整。新的收費模式下，收費對象調整為輸出帶寬（以千兆計）、前端/后端/打折實例（以instance-hours計，其中后端實例分為4個級別，不同級別價格不同）、數據存儲（分級別以千兆字節×月計）、channel（以打開的channel數計）、郵件收件人（以Email數計）、XMPP（以stanza計）等。

其中最主要的變化表現為從按CPU使用時間付費（CPU cycles）轉向按進程實例時間（instancehours）付費。在新的計費模式下，即使某個應用大部分時間處于空閑狀態，如I/O等待中，用戶仍需要為運行的所有應用實例付費，不同于早期的計費標準，多個進程并發執行會被分別計費。另外，新模式的免費資源用量和API調用數有所下降。總之，新計費模式的資源粒度更加細化，費用有所提升。

為了防止費用增加帶來的用戶流失，GAE在功能和工具方面有所改進，支持用戶付費管理、查看付費歷史、優化資源使用、用量報告以及相應的分析工具。

與AWS（amazon Web services）相比，在CPU使用方面，GAE按進程實例用時計費，而AWS則以虛擬機實例用時計費，前者粒度更細，即使進程在空閑或等待過程中仍需收費。因此，在多進程并發情況下，為減低平臺使用成本，用戶可選擇AWS平臺或者優化自身程序以提高CPU利用率。

3.3 SaaS平臺的計費方法

SaaS平臺通過Internet向用戶提供應用級軟件服務，用戶可根據其需求訂購所需服務。SaaS模式下，用戶的使用方式發生了變化，從傳統的擁有軟件向租賃軟件發展。SaaS支持多租戶的方式來降低提供商軟件部署費用，通過規模經濟和專業化來降低供應商軟件服務的成本及用戶費用。

由于應用軟件的豐富多樣性，SaaS平臺的計費需考慮不同服務中的各個計算點的分析和控制，另外，還需考慮多租戶前提下各個用戶的使用生命周期以及系統如何進行定價和組裝[8]。從通用的角度看，SaaS平臺的計費一般遵循按需訂閱、按量計費的原則，提供商與用戶在一定協議期內，在每月訂閱費用上達成一致。根據使用人數或數據量等，可支持對計費和定價進行優化。

這種按月計費的模式取代了以往初期軟件投資成本高的傳統軟件使用模式，有助于以較低的花銷快速部署運行所需軟件，并獲得更好的可伸縮性，降低維護成本。

3.4 分析與小結

可以看出，云平臺計費具有以下特點。

1) 計費因子多。包括CPU、內存、存儲、數據傳輸、虛擬機實例等多種基礎資源的使用計量。

2) 靈活的計費策略。可根據服務等級、資源子類型細化計費因子，并可根據所處地區、時間段、資源消耗量等的不同采用多種計費方式，支持通過非線性、分級等靈活定價策略平衡稀缺資源和用戶使用量關系。

3) 支持多租戶。多租戶是公有云使用的基本特征之一，支持多租戶資源使用計量的獨立性和隔離性。

4) 提供計費管理輔助工具。提供需求與預算評估、計費分析等軟件供用戶使用，界面簡單、易操作。

4 CloudMB的設計與實現

對外租賃使用是云平臺區別于網格等分布式計算環境的一個重要特征，該使用模式要求云平臺能支持多租戶使用和計費。作為開源云應用引擎平臺，目前AppScale尚未實現資源計費功能，其資源監控也是以單個節點為基礎，不支持面向多租戶的資源監控。改進了AppScale 1.5的資源監控機制，基于AppScale 1.5源代碼實現了資源監控和計費軟件CloudMB，該軟件針對云計費的多租戶需求，采用進程級資源監控的方式，從而支持多租戶資源使用的細粒度計量。

4.1 設計思路

4.1.1 資源監控粒度

云平臺通常由眾多計算集群組成，集群軟件安裝在虛擬機或物理機上，虛擬機則部署在物理機之上。云平臺的資源監控通常包括2種粒度：一是對集群、物理機以及其上部署的虛擬機的數量、運行狀態等的監控，主要用于向用戶提供全系統總體可用資源信息；二是對虛擬機/物理機內部資源使用等情況的監控，該類監控信息可作為平臺自動部署、系統性能分析的依據。

目前，AppScale提供的主要是以虛擬機/物理機為單位的單節點資源監控。在每個節點內部，提供CPU、內存、存儲等資源甚至更細粒度的使用及特有屬性信息，但并不針對每個租戶加以區分。每個租戶部署在AppScale平臺上的應用是以實例的形式存在的，而一個實例對應一個進程。為了面向多租戶實現計費，需要跟蹤進程的資源狀態和使用信息，即實現進程級的資源監控，再通過合理的計費策略進行計量，最終獲得用戶的使用費用。

4.1.2 計費策略及其有效性分析

CloudMB實現中用以計算租戶U的應用app在第k個節點上的資源使用費用的基本公式如下

其中，系統中各種資源共有m類，每個資源又可以細分成更小粒度的多種資源，例如CPU用時可根據進程實例進一步細分為前端、后端等多種，網絡流量可分為流入和流出等，Cij是第i類資源的第j種細分資源的消耗量，Wij是第i類資源的第j種細分資源的計費權重，Pi是第i類資源的單價。CloudMB調用Collectd統計資源使用量，使用RRDtool存儲上述信息，并支持通過時間、已消耗資源量等系統狀態信息動態自動配置Wij。

MB支持可定制的計費策略。通過對參數進行配置，系統管理員可根據自身計費策略設定各類資源的權值、各類資源單價、查詢時間范圍等，并支持根據時間段、資源消耗量等值的變化來動態確定計費參數，從而能夠滿足面向不同應用類型的多種用戶的需求，提供靈活的計費策略支持。

4.1.3 主要功能分析與設計

云應用引擎平臺向應用開發者提供開發和運行接口，允許后者開發、調試、部署、運行面向最終用戶的分布式應用程序；平臺本身的資源管理、監控恢復、性能調優、結構擴展等則由平臺管理員來負責。因此，云應用引擎平臺主要面向2類用戶：應用開發者和平臺管理員。從這2類角色出發，平臺計費需滿足以下功能。

平臺管理員：登錄計費功能軟件，管理應用開發者的賬號；查看周期時間內平臺計費匯總以及消費清單；支持根據某種計費因子對應用的資源消費進行排序；增刪計費因子；修改計費權重或編寫計費權重設置腳本，從而支持根據系統參數動態自動改變計費權重，實現靈活的計費策略；查詢每個節點的資源使用情況和系統性能參數。

應用開發者：登錄計費功能軟件；查看所部署應用的清單；查看周期時間內應用的消費清單及匯總；按消費量對應用進行排序；回溯歷史消費清單；查看每個應用的運行概況，包括請求數、響應延遲等。

4.2 結構和組成

基于AppScale開發的資源監控和計費軟件CloudMB主要由資源監控模塊、數據組織與存儲模塊、資源計費模塊和Web界面4部分組成，如圖3所示。其中，資源監控模塊負責單節點進程級資源監控及全系統資源使用情況匯總。資源計費模塊根據資源監控模塊產生的原始數據，整合生成用戶應用的資源消耗數據，根據計費策略、單價和使用量計算費用。數據組織與存儲模塊保存了以.rrd文件形式存儲的原始監控數據以及以關系數據庫表形式存儲的用戶、應用、計費數據等信息及其關聯信息。Web界面由Ruby on Rails實現，包括登錄管理、節點監控信息、用戶應用監控信息、計費信息等的顯示。

圖3 CloudMB的結構和組成

4.2.1 資源監控模塊

目前，AppScale不支持面向用戶應用的進程級的資源監控，為此需對其源碼進行改進。注意到每個租戶通常部署有一到多個應用，AppScale在同一節點上為同一應用創建3個進程（以冗余換取可靠性）。因此，當系統中應用名唯一時，要獲取某用戶的某個應用的資源使用情況，可通過計算單個節點中此用戶對應的該應用所有進程的資源使用情況，并將各節點使用情況進行累積即可。

Collectd的Exec插件支持運行用戶自定義的腳本，通過自定義腳本可收集所需信息并寫入RRDtool數據文件中。利用Linux自帶的進程監控工具編寫了app_monitor.sh，該腳本主要流程如下：

1) 查看主機名稱；

2) 設定Collectd監控時間間隔；

3) 通過傳入方式獲取被監控的應用名；

4) 獲取應用對應的進程信息；

5) 初始化CPU、內存、磁盤等資源參數；

6) 獲取各個進程的資源使用量；

7) 計算此節點該應用使用的各種資源量；

8) 將計算出的數據按照監控時間間隔寫入數據庫文件中。

接著，在Exec插件配置文件指定運行app_monitor.sh，并在collectd.rb文件的write_app_config函數中加入應用和自定義腳本信息即可實現對單節點的進程級資源監控。在此基礎上，通過Collectd及其網絡插件以及RRDtool，實現對整個系統的進程級資源監控。

4.2.2 資源計費模塊

資源監控模塊為資源計費提供了原始的計費數據，利用這些數據進行整合、處理和計算可以獲得用戶的各個應用的資源使用情況，然后根據計費策略和單價即可計算出各種資源的使用費用。

由于Collectd周期性監控數據，RRDtool中存儲的是平臺實時運行數據的周期性采用，需對其進行處理以得到時段性數據。為此，對不同的資源采用不同的計算方法。例如，進程時間通過該進程運行時間、CPU頻率、各個采樣點的CPU使用率等計算而來；內存使用量的采樣點形成了與時間軸的不連續函數，通過求解近似曲線函數與橫軸的面積，然后再除以時長，即得到內存較為準確的使用量；網絡流量采用累加的方式。目前，磁盤使用量不進行細分，按照實際分配給租戶的量計算。

CloudMB中擁有權限的平臺管理員可設置計費權重。系統將根據某些參數（如時間段）的變化而動態調節計費權重，從而支持靈活的計費策略。目前支持通過修改配置腳本來設置計費權重等。

整合出的統計數據、計費權重等被寫入應用表單數據庫，該數據庫中還存儲有用戶、用戶與應用、應用與進程之間的關聯信息以及各種資源的單價，通過讀取這些信息，并進行計算，CloudMB資源計費模塊完成資源的計費。

資源的使用量以天為單位存儲在系統中，根據請求，可對某租戶的某個或幾個應用的總資源使用量進行統計，系統支持歷史賬單的查詢。

4.2.3 數據組織與存儲模塊

數據是計費的基礎，CloudMB中有2類數據：一類存儲的是從各個節點收集的各類資源的原始監控數據以及這些數據的初步匯總信息；另一類平臺管理員和應用開發者的賬號信息、部署的應用信息、計費策略設置信息、資源單價、整合的計費數據、歷史賬單等應用相關信息。

第一類數據的數據量更新頻率高、在不斷變化中，累積數據量大，常規數據庫的結構對于這類數據不適合；第二類數據相對穩定、需要持久性存儲，且涉及用戶體驗，要求較高的存取效率。2類數據具有不同特點，其存儲方式也有所差異。

通過分析RRDtool數據庫的特點，發現該數據庫適合動態監控數據的存儲，可在一定程度上整合監控數據而不丟失監控的真實性，且其數據庫文件具有循環記錄的特點，其大小固定，能有效控制存儲空間的大小，有利于存儲可擴展性管理。因此，對原始監控數據及其初步整合的數據存儲在RRDtool中，而應用相關信息則選取MySqL存儲。

為方便原始數據的存儲和查詢，按照數據的層次關系設置數據庫表，主要數據庫表包括節點表、資源類別表、細化資源表和細化資源參數配置表。其中，每張表都包含有對應層次的實體名稱、ID、計量、創建時間和修改時間，以適應其動態更新的特點。應用相關的數據對應的數據庫表則主要包括管理員賬號表、應用開發者賬號表、應用-進程關聯表、計費權重表、資源單價表、歷史賬單表等。

因此，數據組織與存儲模塊包括原始監控和應用相關2部分數據，該模塊與資源監控模塊和資源計費模塊交互，為Web界面顯示提供數據依據。

4.2.4 Web界面顯示

CloudMB前端采用Ruby on Rails實現Web網頁顯示功能，包括登錄管理、節點監控信息的顯示、節點計費顯示、用戶應用的計費顯示、歷史賬單顯示等。為簡化實現，采用與AppScale資源監控相同的局部模板。當有頁面請求到來時，首先到應用相關信息數據庫中查詢，若查到相關數據，則隨即在頁面中顯示，若無所需信息，則需從原始監控信息數據庫中調取相關信息進行整合和計算，然后保存在應用相關數據庫中，并在Web頁面中顯示。

4.3 系統代價分析

資源監控和計費機制作為輔助功能，理想的狀況是占用盡可能少的平臺資源。目前，CloudMB對系統潛在的影響主要在于以下3個方面：1）Collectd周期性采集數據并存入數據庫，被監控資源細分種類多，采樣周期短，會帶來一定的I/O和CPU損耗；2）Collectd將各節點的監控數據匯總到主節點，由于原始監控數據更新周期短、種類多，就使得主節點網絡帶寬受到影響；3）從原始監控數據到匯總數據以及最終計費數據過程中的整合、計算代價。

實驗的硬件環境為Intel(R) Core(TM)2 DUO CPU T5 870 CPU、2G內存、250G Sata硬盤。軟件環境為Ubuntu 10操作系統、Ruby1.8.7和Rubygem2.4.2。Ubuntu中共部署3個虛擬機，平分系統內存。平臺中部署了4個節點，一個主節點（節點1），2個從節點（節點2和3）和一個數據存儲節點（節點4）。測試時，分別針對系統輕負載和重負載2種情況，以4個不同組成節點的CPU占用率作為觀察對象，對比在未運行CloudMB與運行了CloudMB之后的CPU占用率，如圖4所示。2種情況下，分別測試50次，取CPU占用率的平均值。

圖4 使用CloudMB前后系統CPU占用率的對比

無論在平臺輕負載或是重負載下，未部署運行CloudMB時平臺消耗的CPU資源比部署運行CloudMB時消耗的CPU資源要少，但總的差異不超過系統CPU總量的3%。

5 結束語

本文在研究已有云計費機制以及AppScale源碼的基礎上，改進了AppScale 1.5的資源監控機制，基于AppScale 1.5實現了資源監控和計費軟件CloudMB，該軟件針對云計費的多租戶需求，采用進程級資源監控的方式，對多租戶細粒度資源使用計費進行了有益的探索。下一步將研究如何確定較優的監控數據采樣周期，考慮服務質量以及其他細化因素，建立更為合理的計費模型和算法。

[1] CHOHAN N, BUNCH C, PANG S, etal. AppScale: scalable and open appengine application development and deployment[A]. Proceedings of First International Conference on Cloud Computing[C]. Berlin, Germany, 2009. 57-70.

[2] CHOHAN N, BUNCH C, PANG S, etal. Appscale design and implementation[EB/OL]. www. cs.ucsb.edu/～ckrintz/papers/appscale 2009-02TR. pdf, 2009.

[3] BUNCH C, CHOHAN N, KRINTZ C. Appscale: open-source platform-as-a-service[EB/OL]. http://www.cs.ucsb.edu/research/tech_reports/ reports/ 2011-01. pdf, 2011.

[4] 唐國芳. 基于QoS 服務級別的內容計費及其在3G 中的應用[D].南京：南京郵電大學,2008.TANG G F. QoS based Content Billing and Its Applications in 3G Services[D]. http://Nanjing: Nanjing University of Posts and Telecommunications, 2008.

[5] Amazon EC2 pricing[EB/OL]. http://aws. amazon.com/ec2/ pricing/,2011.

[6] Amazon simple storage service (amazon S3) pricing[EB/OL]. http://aws. amazon.com/s3/#pricing,2011.

[7] Google app engine-pricing and features[EB/OL]. http://www.google.com/enterprise/cloud/appengine/pricing. html,2012.

[8] Meter, price & bill for cloud services[EB/OL]. http://www.zuora.com/why-zuora-subscription-management/technology.html,2011.