云計算計費問題研究

陳 豪，陶 冶，張 尼，張云勇

（中國聯合網絡通信有限公司研究院 北京 100032）

1 引言

云計算是一種將規模可動態擴展的虛擬化資源通過網絡提供對外按需使用服務的計算模式，用戶無需了解提供這種服務的底層基礎設施，也無需去擁有和控制[1]。云計算具有資源共享、彈性調度、按需分配等特點。云計算的興起將使很多企業摒棄原有購買服務器、存儲設備的模式，轉而選擇更靈活的服務模式。目前以包月為主的計費方式的最大特點是用戶為其單位時間的服務支付固定的費用而與其用量無關，這種計費方式卻與云計算所提倡按需服務的目標背道而馳，已經無法適應云計算的發展需求[2]。從技術角度看，云服務作為綜合性資源和內容服務資源的多樣性和內容的動態組合，傳統網絡資源計量方法難以勝任，需要對差異性服務進行動態跟蹤和計量，針對服務模塊的組合進行定價，并根據不同用戶的行為進行收費。因此云計算環境下的計費問題是保證云計算快速發展且保障產業鏈各參與方利益的重要問題。

現有關于云計算的理論研究多從技術的視角，探討云計算體系架構、云數據管理、云安全、編程模型等[3～5]，針對云計算整體計費系統的研究尚不多見。另外，目前的研究多集中在計費策略上，參考文獻[6]中通過對服務等級協議（SLA）內容監測及用戶評估的分析，提出了一種基于效用的云計算動態資源計費策略，參考文獻[7]運用隨機Petri網進行動態流程建模與追蹤，提出分層計費體系下的流程計費模型。參考文獻[8]在對比幾種典型公有云服務提供商的計費方式的基礎上，指出云計費應滿足用戶差異化需求和多樣化應用的場景。這些研究并沒有明確各種云服務的計費指標，沒有考慮計費信息的采集、存儲以及展現等實際問題。

2 主流云平臺計費現狀

云計算按服務類型大致可以分為3類：基礎設施即服務（IaaS）、平臺即服務（PaaS）、軟件即服務（SaaS）。這 3 種服務類型的云計算系統中，所有的用戶需求被看作是一種云計算服務請求，即所有的用戶需求將面臨計費的問題。對于上述3種服務類型，應考慮什么樣的服務可以免費，什么樣的服務按照數據的存儲量、計算量、存儲時間等方面以怎么樣的收費標準來計費。這些問題是云計算計費主要考慮的核心問題之一。

作為IaaS標桿的亞馬遜云服務（AWS），現在共提供12類33項服務，基礎設施功能已經相當豐富，能滿足構建超大互聯網應用的大多數需求，并面向開發者提供工具包、SDK、文檔、社區和技術支持等服務。具體來看，大致可分為計算、存儲、應用架構、特定應用、管理這五大類。在此不窮舉這些服務的計費指標，僅選擇其中最具代表性的3種服務的計費情況進行討論，見表1。

PaaS的典型代表是Google App Engine（GAE）應用平臺服務，用戶可以在GAE平臺使用Python和Java語言開發各種Web應用，通過Google App Engine運行大型并行應用程序。而企業也可以在這一平臺上定制開發適合自己的軟件應用。GAE應用程序易于構建和維護，并可根據用戶訪問量和數據存儲需要的增長輕松擴展。使用GAE，將不再需要維護服務器，只需上傳企業自己的應用程序，便可立即為企業的客戶提供服務。GAE的計費情況見表2。

SaaS的典型代表是Salesforce基于網絡向企業用戶提供在線CRM銷售云和服務云，使用戶可以避免購買硬件、開發軟件等前期投資以及復雜的后臺管理問題。它的計費以用戶為單位，不同版本的軟件對每個用戶收取的費用不同，越專業的版本每個用戶收費越高。

通過對以上3種模式的計費情況進行對比，發現IaaS的計費主要是對主機、網絡、存儲、應用環境等資源的使用情況分別進行計量，然后分別定價（受時間、區域等因素影響）形成賬單進行收費。一般有包月和按需計費兩種方式。

PaaS的計費與IaaS類似，PaaS平臺通過分布式計算基礎架構管理系統向用戶提供資源服務，因而每種資源的使用都需要計費。不同的是PaaS的計費點更側重于平臺開發接口的調用情況。

SaaS是通過網絡向用戶提供軟件服務，采用多租戶的技術來降低軟件部署費用，通過專業化和規模經濟來降低供應商軟件服務成本和用戶的支付費用，主要采用的是訂閱式計費機制。SaaS的計費則更多以用戶或軟件實例為基礎進行計費。

表1 亞馬遜典型云服務計費情況

表2 Google典型云服務計費情況

這3種模式的云服務的計費歸根結底都是對底層各種資源使用情況的計費，因此本文對最復雜的IaaS模式的計費系統進行進一步研究，其他兩種模式的計費系統可以通過類比掌握。

3 云計算計費系統構建

云計算計費系統可按基礎設施層、數據處理層和數據展現層來構建。基礎設施層為中間處理層準備其所需的計算、存儲、數據庫、網絡等資源；數據處理層對計量數據進行分析并負責持久化，采用一定的模型和算法處理，供展示層調用；展示層通過多種途徑展示計量數據，并通過配置各種策略實現經營活動，最終形成計費賬單。云計算計費系統如圖1所示。

圖1 云計算計費系統分層結構

3.1 數據采集

對物理資源的計量數據采集有很多成熟的技術和工具，但是云計算環境不僅需要對物理資源的使用情況進行計量，更重要的是對虛擬資源進行計量，目前對虛擬資源的計量數據采集有部署代理與無代理兩種模式[9]。

代理模式一般將定制的數據采集代理植入宿主機（虛擬機資源或物理資源）中，這種方式采集的數據更加準確，指標擴展也比較容易。這種模式需要額外的安裝部署及維護工作，工作量與采集對象數量成線性關系，即采集對象越多就需要安裝越多的代理程序。在云計算環境使用大量虛擬機的場景下，手工安裝代理程序效率低下，需要使用自動化部署技術，例如從服務器將代理程序推送到采集對象上安裝。

無代理模式不需要安裝代理程序，通過遠程調用虛擬化層或操作系統提供的接口實現數據采集。

本文結合使用上述兩種數據采集方式，功能結構如圖2所示。

圖2 數據采集方案

該方案使用無代理方式采集服務器、路由器、交換機等物理資源的計量參數，而部署定制化代理的方式采集開源與商業云化資源的使用情況。這個方案主要有以下優點：由于服務器、交換機等物理設備對通用的SNMP/Telnet/SSH等標準接口已具備較成熟的支持能力，所以采用通用的標準化無代理采集方法，既可減少代理部署成本，也可以最低限度地降低宿主機的性能與工作效率。

如前文所述，由于云化資源如虛擬機、開源云計算系統組件、云數據庫、云存儲服務尚無標準化的數據采集標準，使用無代理方式無法滿足云計費的數據需求。所以針對不同的資源類型，定制化開發計量數據采集代理，既可以根據用戶及云平臺計費需求，拓展或減少計量指標，又可以利用云計算按需拓展、自動化部署等技術優勢，隨用戶的資源申請自動部署計量采集代理，實現計量數據收集。

而對于商業云化資源，一般能力提供商都已提供較為完善的計量功能或相應的數據開放接口，云管理平臺只需要根據數據接口，定制標準化的數據格式轉換系統，對接至云管理平臺即可實現對商業云化資源的計費。

3.2 數據存儲

如果要做到按使用量計費，計費數據的采集頻率就不能太短，再加上云服務種類很多，每種服務有不同的計費指標，且每種服務又有許多用戶等原因導致了計費數據需要解決存儲的問題。另外計費數據還需要隨時可供查詢，需要保證計費數據的高可用性。

如圖3所示，本文采用LVS（Linux虛擬服務器）+Keepalived作為支持高可用的計費數據存儲解決方案，LVS提供負載均衡，Keepalived作為故障轉移，提高系統的可用性。

圖3 數據存儲方案

一般的MySQL高可用為了實現MySQL數據的一致性，都是采用單點寫入，本方案采用Keepalived中的sorry server來實現寫入數據庫為單點的需求。本方案實現的功能是當網絡有問題、MySQL有問題、服務器宕機或Keepalived服務停止后，服務器能自動跳轉到備用機，當主服務器服務啟動起來后會自動切換回來。

Keepalived基于虛擬路由冗余協議 （virtual router redundancy protocol，VRRP）實現高可用解決方案，利用其避免單點故障，通常這個解決方案中，至少有2臺服務器運行Keepalived，即一臺為主服務器，另一臺為備份服務器，但對外表現為一個虛擬IP地址，主服務器會發送特定消息給備份服務器，當備份服務器收不到該消息時，則認為主服務器出現故障，備份服務器會接管虛擬IP地址，繼續提供服務，從而保證了高可用性。這個方案的優點是：

· 安裝配置簡單，實現方便，高可用性好，可以根據服務與系統的可用性多方面進行切換；

·可以將寫虛擬IP地址和讀虛擬IP地址分別進行設置，為讀寫分離做準備；

· 可以在后面添加多個備份服務器，并做到負載均衡。

3.3 計費模型

計費模型應該同時考慮云服務商和用戶的利益。作為提供商與用戶之間云服務價值實現的橋梁，云計算服務的計費模式必須能夠在滿足用戶使用需求的同時，客觀地衡量用戶使用服務時對提供商資源的占用情況[8]。

在計費模型中加入用戶的因素，例如用戶滿意度、用戶QoS等，將增加用戶與云服務商的粘合度。在社交網絡十分繁榮的今天，通過用戶之間的推薦將進一步增加云服務商的用戶數，從而增加云服務商的利潤，達到共贏的目標。另一方面，對云服務商而言，如何盡量降低成本提高利潤是其主要訴求，云服務商也可能會采用分地域、分時段的計費策略和優惠手段等，這些也是計費模型應該考慮的因素。

本文令N={N1，N2，…，Nm}，其中，N1，N2，…，Nm分別代表某一種計費因子。采納的計費因子如下。

· 用戶的資源使用量：用戶申請的虛擬機資源、存儲資源、數據庫資源、網絡資源等。可將資源按不同的規格進行搭配，對打包的資源進行統一計費。

· 用戶租借時間：根據用戶租借時間的長短，可采取不同的計費策略。一次租借時間越長，給予的優惠力度越大。

·用戶要求的服務質量：用戶要求的服務質量越高，所需費用就越多。

· 網絡繁忙程度：當網絡處于空閑狀態時，用戶單位用量的價格較低，隨著網絡繁忙程度的增強，用戶單位用量的價格將會增加。

· 服務源和申請用戶之間的距離：云服務提供商通常將云資源分成不同的區域，源和用戶在一個服務區域內的用戶為區內請求，否則為區外請求，一般對區外請求給予適當的優惠。

· 用戶行為：通過對用戶行為進行分析，對惡意使用云環境（如部署惡意應用程序，使用申請的虛擬資源從內部發起攻擊等）提出警告或處罰。

· 云服務故障造成的影響：網絡癱瘓、數據丟失等造成用戶利益受損，應考慮給予用戶補償。

將這些計費因子分配相應的指標權重W，W={W1，W2，…，Wm}，Wm分別代表針對每一Nm指標的權重。其中，W=1，0≤W1，W2，…，Wm≤1，W1+W2+ …+Wm=1。基于計費因子加權的計費可表示為：Bill=W1×f(N1)+W2×f(N2)+…+W3×f(Nm)，其中f(N1)為以N1為參數的函數，其他各項以此類推。

3.4 數據展現

圖4 云計算計費系統部署

由于采集的指標種類繁多，展現方式也多種多樣，包括表格、拓撲圖、柱狀圖、餅圖等，沒有統一的標準。數據展現需要體現邏輯性，例如在展現虛擬機使用情況的同時，應該能關聯展示與虛擬機結合使用的網絡資源、存儲資源、應用環境等的使用情況。

計量數據需要計費劃價處理，按照相關費率以及云計算服務具體發生狀況，計算用戶的云計算服務費用，并形成詳細賬單。數據展現還應該支持自定義報表、數據管理、配置費率，如更加靈活地調整資費策略、實施多層次優惠方案，及時配合面向用戶的經營戰略調整，提高服務質量。

4 云計算計費系統部署

根據云計算計費系統構建方案，本文以OpenStack（i版本）為虛擬化管理平臺進行了系統部署，部署網絡如圖4所示。其中主要節點部署的應用包括：在控制節點部署OpenStack的Nova-API、Nova-scheduler、noVNC、Keystone、Glance、Quantum、Cinder等應用；在計算節點部署Compute、監控代理等應用；在門戶節點部署Tomat應用；在資源節點部署MySQL、rabbitMQ應用；在MySQL數據庫部署Keepalive應用。部署網絡將業務和管理隔離，分配不同的網段和默認網關。通過實際部署運行驗證了本文方案的可行性。

5 結束語

本文在分析了現有主流云平臺計費機制的基礎上，采用3層模型構建云計算計費體系，并對各層的關鍵技術進一步細化。在數據采集方面，采用無代理結合定制化代理的方式采集計費數據，底層設置支持開源云化資源、商業化云化資源以及非云化資源。在數據存儲方面采用LVS結合Keepalive提供支持高可用的數據存儲方案，然后設計了一個基于計費因子加權的計費模型，同時考慮用戶和云服務提供商的利益。最后對計費系統數據展現提出建議。本文下一步工作將圍繞海量計費數據存在的大數據問題以及計費系統的安全問題展開進一步研究。

1 張尼，劉鏑，張云勇等.云計算安全技術與應用.北京：人民郵電出版社，2014

2 胡軍.云計算環境下計費系統的設計與實現.北京郵電大學碩士學位論文，2013

3 房秉毅，張云勇，程瑩等.云計算國內外發展現狀分析.電信科學， 2010（S1）

4 Shaikh F B，Haider S.Security threats in cloud computing.Proceedings of Internet Technology and Secured Transactions(ICITST),Abu Dhabi,2011

5 吳吉義，傅建慶,平玲娣等.一種對等結構的云存儲系統研究.電子學報，2011（5）

6 劉國奇，劉慧，高宇等.一種基于效用的云計算動態資源計費策略.吉林大學學報(工學版)，2013（6）

7 黃衛東，于瑞強.云計算環境下基于 Petri網的流程計費模型.北京郵電大學學報，2013（1）

8 吳俊，徐溟.公有云服務計費模式比較研究.電信科學，2012，28（1）：127～132

9 Wiki.http://en.wikipedia.org/wiki/Agentless_data_collection，2014