云應(yīng)用引擎的資源監(jiān)控和計費(fèi)機(jī)制研究

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

（1. 國防科學(xué)技術(shù)大學(xué) 計算機(jī)學(xué)院, 湖南 長沙 410073；2. 騰訊研究院，北京 100080）

1 引言

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

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

AppScale的開發(fā)和運(yùn)行接口與GAE兼容，是具有代表性的開源云應(yīng)用引擎平臺[1～3]。以AppScale為研究平臺，分析了其架構(gòu)及特點，探討了其資源監(jiān)控功能的實現(xiàn)機(jī)理和不足。在研究已有云計算平臺計費(fèi)策略的基礎(chǔ)上，基于AppScale資源監(jiān)控機(jī)制，采用Ruby on Rails Web架構(gòu)，設(shè)計和開發(fā)了具有進(jìn)程級資源監(jiān)控和面向多租戶的資源計費(fèi)功能的CloudMB。

2 AppScale云應(yīng)用引擎的組成與架構(gòu)分析

AppScale平臺與GAE的開發(fā)和部署接口兼容，實現(xiàn)并擴(kuò)展了GAE的 SDK及其開放API。AppScale可自動、透明地運(yùn)行于Amazon EC2和Eucalyptus等云基礎(chǔ)架構(gòu)之上，其目標(biāo)一方面是在應(yīng)用部署到GAE平臺前，向用戶提供一個部署、測試、調(diào)試、估量、監(jiān)控GAE應(yīng)用的PaaS平臺，使其可在自身集群之上運(yùn)行和驗證GAE應(yīng)用，另一方面是在服務(wù)、運(yùn)行時環(huán)境與底層云基礎(chǔ)設(shè)施的互操作方面對PaaS平臺進(jìn)行擴(kuò)展。

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

2.1 AppScale平臺組成

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

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

AS是應(yīng)用程序的執(zhí)行引擎，它通過HTTPS協(xié)議與AppDB交互來存儲和訪問數(shù)據(jù)。每個AS一次只可執(zhí)行一個應(yīng)用程序。為了托管多個應(yīng)用程序，可以添加多個AS。

AC負(fù)責(zé)啟動、初始化、停止AppScale實例，支持AppScale各組件之間進(jìn)行交互（系統(tǒng)中的所有通信均通過SSL加密）。

ALB負(fù)責(zé)初始化用戶與AS中運(yùn)行的應(yīng)用之間的連接，即在用戶成功登錄后，將請求路由給指定的、唯一的 AS以便為該應(yīng)用程序?qū)嶋H處理請求，ALB不參與用戶應(yīng)用請求的處理。因此，通過記錄用戶被指定的AS所執(zhí)行過的應(yīng)用信息，便可以對用戶應(yīng)用情況進(jìn)行統(tǒng)計。

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

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

2.2 AppScale平臺架構(gòu)

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

AppScale的組成和部署結(jié)構(gòu)如圖1所示，系統(tǒng)各組成部分之間的通信分為3類：1）各個節(jié)點上不同AC之間的通信；2）AppScale工具相關(guān)的交互；3）用戶與所部署Web應(yīng)用之間的基于HTTPS的通信。

圖1 AppScale的組成和部署結(jié)構(gòu)

2.3 AppScale平臺的資源監(jiān)控

AppScale平臺節(jié)點部署采用主從式結(jié)構(gòu)，主節(jié)點負(fù)責(zé)應(yīng)用的負(fù)載均衡，從節(jié)點負(fù)責(zé)計算和存儲服務(wù)。同樣，其監(jiān)控架構(gòu)也是采用集中式的，由主節(jié)點定時向從節(jié)點獲取監(jiān)控數(shù)據(jù)，并保存在主節(jié)點上，而從節(jié)點只是定時將監(jiān)控數(shù)據(jù)傳送給主節(jié)點。AppScale通過整合資源監(jiān)控工具Collectd及環(huán)狀數(shù)據(jù)庫工具RRDtool（round robin database tool）實現(xiàn)資源監(jiān)控、狀態(tài)存儲及資源使用情況的可視化。

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

圖2 AppScale資源監(jiān)控的實現(xiàn)原理

3 主流云平臺計費(fèi)方法分析

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

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

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

3.1 IaaS平臺的計費(fèi)方法

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

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

1) Amazon EC2的計費(fèi)[5]

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

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

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

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

Amazon EC2提供標(biāo)準(zhǔn)、小型、高內(nèi)存、高CPU、集群、集群GPU共6種類型的定制虛擬機(jī)實例，每種實例按照不同規(guī)格還可細(xì)分為若干種，每一種按時長計費(fèi)的定價有所區(qū)分。目前，定制虛擬機(jī)所支持的操作系統(tǒng)有Redhat企業(yè)級Linux、Windows Server、Oracle企業(yè)級 Linux、SUSE企業(yè)級 Linux和Amazon Linux AMI，同時安裝了DBMS、Web服務(wù)器、資源管理、應(yīng)用服務(wù)器、媒體播放等軟件。

2) Amazon S3的計費(fèi)[6]

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

目前S3提供2種服務(wù)質(zhì)量等級。

標(biāo)準(zhǔn)存儲（standard storage)：提供99.99%的可用性保障，一年的數(shù)據(jù)丟失率不高于0.000 000 001%，可以從2個存儲設(shè)備同時失效中恢復(fù)，該級別用以存儲關(guān)鍵數(shù)據(jù)。

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

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

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

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

3.2 PaaS平臺的計費(fèi)方法

與IaaS層相比，PaaS平臺的計費(fèi)不僅僅局限于虛擬機(jī)操作系統(tǒng)或存儲等層面，還涉及應(yīng)用層的進(jìn)程、調(diào)用等細(xì)粒度的資源監(jiān)控和計費(fèi)。目前，在PaaS領(lǐng)域，GAE占據(jù)著主導(dǎo)地位，其計費(fèi)模式也具有典型的代表性[7]。

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

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

其中最主要的變化表現(xiàn)為從按CPU使用時間付費(fèi)（CPU cycles）轉(zhuǎn)向按進(jìn)程實例時間（instancehours）付費(fèi)。在新的計費(fèi)模式下，即使某個應(yīng)用大部分時間處于空閑狀態(tài)，如I/O等待中，用戶仍需要為運(yùn)行的所有應(yīng)用實例付費(fèi)，不同于早期的計費(fèi)標(biāo)準(zhǔn)，多個進(jìn)程并發(fā)執(zhí)行會被分別計費(fèi)。另外，新模式的免費(fèi)資源用量和API調(diào)用數(shù)有所下降。總之，新計費(fèi)模式的資源粒度更加細(xì)化，費(fèi)用有所提升。

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

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

3.3 SaaS平臺的計費(fèi)方法

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

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

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

3.4 分析與小結(jié)

可以看出，云平臺計費(fèi)具有以下特點。

1) 計費(fèi)因子多。包括CPU、內(nèi)存、存儲、數(shù)據(jù)傳輸、虛擬機(jī)實例等多種基礎(chǔ)資源的使用計量。

2) 靈活的計費(fèi)策略?？筛鶕?jù)服務(wù)等級、資源子類型細(xì)化計費(fèi)因子，并可根據(jù)所處地區(qū)、時間段、資源消耗量等的不同采用多種計費(fèi)方式，支持通過非線性、分級等靈活定價策略平衡稀缺資源和用戶使用量關(guān)系。

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

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

4 CloudMB的設(shè)計與實現(xiàn)

對外租賃使用是云平臺區(qū)別于網(wǎng)格等分布式計算環(huán)境的一個重要特征，該使用模式要求云平臺能支持多租戶使用和計費(fèi)。作為開源云應(yīng)用引擎平臺，目前AppScale尚未實現(xiàn)資源計費(fèi)功能，其資源監(jiān)控也是以單個節(jié)點為基礎(chǔ)，不支持面向多租戶的資源監(jiān)控。改進(jìn)了AppScale 1.5的資源監(jiān)控機(jī)制，基于AppScale 1.5源代碼實現(xiàn)了資源監(jiān)控和計費(fèi)軟件CloudMB，該軟件針對云計費(fèi)的多租戶需求，采用進(jìn)程級資源監(jiān)控的方式，從而支持多租戶資源使用的細(xì)粒度計量。

4.1 設(shè)計思路

4.1.1 資源監(jiān)控粒度

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

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

4.1.2 計費(fèi)策略及其有效性分析

CloudMB實現(xiàn)中用以計算租戶U的應(yīng)用app在第k個節(jié)點上的資源使用費(fèi)用的基本公式如下

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

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

4.1.3 主要功能分析與設(shè)計

云應(yīng)用引擎平臺向應(yīng)用開發(fā)者提供開發(fā)和運(yùn)行接口，允許后者開發(fā)、調(diào)試、部署、運(yùn)行面向最終用戶的分布式應(yīng)用程序；平臺本身的資源管理、監(jiān)控恢復(fù)、性能調(diào)優(yōu)、結(jié)構(gòu)擴(kuò)展等則由平臺管理員來負(fù)責(zé)。因此，云應(yīng)用引擎平臺主要面向2類用戶：應(yīng)用開發(fā)者和平臺管理員。從這2類角色出發(fā)，平臺計費(fèi)需滿足以下功能。

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

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

4.2 結(jié)構(gòu)和組成

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

圖3 CloudMB的結(jié)構(gòu)和組成

4.2.1 資源監(jiān)控模塊

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

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

1) 查看主機(jī)名稱；

2) 設(shè)定Collectd監(jiān)控時間間隔；

3) 通過傳入方式獲取被監(jiān)控的應(yīng)用名；

4) 獲取應(yīng)用對應(yīng)的進(jìn)程信息；

5) 初始化CPU、內(nèi)存、磁盤等資源參數(shù)；

6) 獲取各個進(jìn)程的資源使用量；

7) 計算此節(jié)點該應(yīng)用使用的各種資源量；

8) 將計算出的數(shù)據(jù)按照監(jiān)控時間間隔寫入數(shù)據(jù)庫文件中。

接著，在Exec插件配置文件指定運(yùn)行app_monitor.sh，并在collectd.rb文件的write_app_config函數(shù)中加入應(yīng)用和自定義腳本信息即可實現(xiàn)對單節(jié)點的進(jìn)程級資源監(jiān)控。在此基礎(chǔ)上，通過Collectd及其網(wǎng)絡(luò)插件以及RRDtool，實現(xiàn)對整個系統(tǒng)的進(jìn)程級資源監(jiān)控。

4.2.2 資源計費(fèi)模塊

資源監(jiān)控模塊為資源計費(fèi)提供了原始的計費(fèi)數(shù)據(jù)，利用這些數(shù)據(jù)進(jìn)行整合、處理和計算可以獲得用戶的各個應(yīng)用的資源使用情況，然后根據(jù)計費(fèi)策略和單價即可計算出各種資源的使用費(fèi)用。

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

CloudMB中擁有權(quán)限的平臺管理員可設(shè)置計費(fèi)權(quán)重。系統(tǒng)將根據(jù)某些參數(shù)（如時間段）的變化而動態(tài)調(diào)節(jié)計費(fèi)權(quán)重，從而支持靈活的計費(fèi)策略。目前支持通過修改配置腳本來設(shè)置計費(fèi)權(quán)重等。

整合出的統(tǒng)計數(shù)據(jù)、計費(fèi)權(quán)重等被寫入應(yīng)用表單數(shù)據(jù)庫，該數(shù)據(jù)庫中還存儲有用戶、用戶與應(yīng)用、應(yīng)用與進(jìn)程之間的關(guān)聯(lián)信息以及各種資源的單價，通過讀取這些信息，并進(jìn)行計算，CloudMB資源計費(fèi)模塊完成資源的計費(fèi)。

資源的使用量以天為單位存儲在系統(tǒng)中，根據(jù)請求，可對某租戶的某個或幾個應(yīng)用的總資源使用量進(jìn)行統(tǒng)計，系統(tǒng)支持歷史賬單的查詢。

4.2.3 數(shù)據(jù)組織與存儲模塊

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

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

通過分析RRDtool數(shù)據(jù)庫的特點，發(fā)現(xiàn)該數(shù)據(jù)庫適合動態(tài)監(jiān)控數(shù)據(jù)的存儲，可在一定程度上整合監(jiān)控數(shù)據(jù)而不丟失監(jiān)控的真實性，且其數(shù)據(jù)庫文件具有循環(huán)記錄的特點，其大小固定，能有效控制存儲空間的大小，有利于存儲可擴(kuò)展性管理。因此，對原始監(jiān)控數(shù)據(jù)及其初步整合的數(shù)據(jù)存儲在RRDtool中，而應(yīng)用相關(guān)信息則選取MySqL存儲。

為方便原始數(shù)據(jù)的存儲和查詢，按照數(shù)據(jù)的層次關(guān)系設(shè)置數(shù)據(jù)庫表，主要數(shù)據(jù)庫表包括節(jié)點表、資源類別表、細(xì)化資源表和細(xì)化資源參數(shù)配置表。其中，每張表都包含有對應(yīng)層次的實體名稱、ID、計量、創(chuàng)建時間和修改時間，以適應(yīng)其動態(tài)更新的特點。應(yīng)用相關(guān)的數(shù)據(jù)對應(yīng)的數(shù)據(jù)庫表則主要包括管理員賬號表、應(yīng)用開發(fā)者賬號表、應(yīng)用-進(jìn)程關(guān)聯(lián)表、計費(fèi)權(quán)重表、資源單價表、歷史賬單表等。

因此，數(shù)據(jù)組織與存儲模塊包括原始監(jiān)控和應(yīng)用相關(guān)2部分?jǐn)?shù)據(jù)，該模塊與資源監(jiān)控模塊和資源計費(fèi)模塊交互，為Web界面顯示提供數(shù)據(jù)依據(jù)。

4.2.4 Web界面顯示

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

4.3 系統(tǒng)代價分析

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

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

圖4 使用CloudMB前后系統(tǒng)CPU占用率的對比

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

5 結(jié)束語

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

[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 服務(wù)級別的內(nèi)容計費(fèi)及其在3G 中的應(yīng)用[D].南京：南京郵電大學(xué),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.