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

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

1 引言

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

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

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

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

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

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

2.1 AppScale平臺(tái)組成

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

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

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

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

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

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

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

2.2 AppScale平臺(tái)架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

3.1 IaaS平臺(tái)的計(jì)費(fèi)方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 PaaS平臺(tái)的計(jì)費(fèi)方法

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

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

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

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

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

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

3.3 SaaS平臺(tái)的計(jì)費(fèi)方法

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

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

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

3.4 分析與小結(jié)

可以看出，云平臺(tái)計(jì)費(fèi)具有以下特點(diǎn)。

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

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

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

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

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

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

4.1 設(shè)計(jì)思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.4 Web界面顯示

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

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

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

實(shí)驗(yàn)的硬件環(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個(gè)虛擬機(jī)，平分系統(tǒng)內(nèi)存。平臺(tái)中部署了4個(gè)節(jié)點(diǎn)，一個(gè)主節(jié)點(diǎn)（節(jié)點(diǎn)1），2個(gè)從節(jié)點(diǎn)（節(jié)點(diǎn)2和3）和一個(gè)數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)（節(jié)點(diǎn)4）。測試時(shí)，分別針對(duì)系統(tǒng)輕負(fù)載和重負(fù)載2種情況，以4個(gè)不同組成節(jié)點(diǎn)的CPU占用率作為觀察對(duì)象，對(duì)比在未運(yùn)行CloudMB與運(yùn)行了CloudMB之后的CPU占用率，如圖4所示。2種情況下，分別測試50次，取CPU占用率的平均值。

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

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

5 結(jié)束語

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