移動通信網絡云計算的解決方案

摘要:云計算將計算能力作為通用性資源，提供一種彈性的資源獲得模式，使業務的提供更具伸縮性，使能源在一定程度上得到更為合理的利用。文章從移動通訊運營商的需求入手，介紹了一種業務調度和虛擬化的計算云應用思路，為移動網絡的云化提供了解決方法，使運營商真正能夠以最小的投入，產生最大的收益。

關鍵詞: 資源共享；業務調度；虛擬化

Abstract: Cloud computing makes computing power universally available， and provides flexibility in resource acquisition. It allows for scalable provision of services and more reasonable use of resources. This article considers cloud service deployment and virtualization from the perspective of mobile operators. A solution is proposed which allows mobile operators to maximize profits with minimal investment.

Key words:resource sharing; service deploy; virtualization

1 通信行業的新要求

隨著3G網絡的進一步完善，運營商部署的業務平臺也愈來愈多，除了當前已經廣泛運用的WAP/WEB網關、短信中心、彩信中心等基礎引擎平臺以外，隨著業務的進一步發展，還會陸續出現各種形形色色的業務應用平臺。目前這些業務平臺，不管實現何種業務功能，不管局點大小，都是采用獨立建設的模式。

通過對多個廠家的多類業務產品進行對比分析，我們得到的結論是：除了核心業務處理模塊以外，其余模塊的功能基本上都是雷同的（如：計費管理模塊、用戶管理模塊、配置管理模塊、維護管理模塊、日志/報表模塊等），這些模塊可以通過一定的手段進行融合與集成，從某種角度來講可以實現一定的資源復用。但對于各業務的核心處理部分，由于業務邏輯迥異、流程復雜，無法在業務層面做到能力共享。這種多業務分散建設模式已逐漸成為阻礙移動通信產業高速發展的重要原因。這主要體現在以下幾個方面[1-5]：

各業務平臺采用的外購軟硬件類型各異，對于外購件異常帶來的業務中斷、系統故障等問題較難控制和規避；各廠家業務平臺提供的操作維護手段不同，需要運營商培訓大量的技術人員熟悉各種維護系統，加大了維護成本的投入；業務平臺獨立建設，不同地域、不同業務的處理能力嚴重負載不均，投資建設的硬件資源利用率不高。

從理論上分析，無論是何種業務，其處理邏輯都仍然屬于應用程序范疇，任何應用程序都可以簡單歸納為計算模式+存儲模式+通信模式的集合。為帶來有彈性、容量無限的系統，一般有兩種解決辦法：一是在同一機器上部署單一業務的多模塊或者選擇性地部署多個業務；二是通過虛擬化技術實現統計性復用資源。前者對業務程序的依賴度很高，需要相互之間互不影響，對于同廠家同類型業務相對比較容易實現，只能在一定程度上實現資源共享。而虛擬化技術可以較好地隱藏資源復用和共享的實現細節，能最大程度地減小結構上與業務的耦合性。

當然，僅依靠虛擬化技術還不能完全做到業務級彈性的調用控制，文章在下一章節將重點介紹業務調度和虛擬化的完整解決方案。通過該方案移動運營商可得到：

(1) 業務按實際處理需要合理的獲取計算資源。從而使運營商不用在提供某種業務服務之前就要做計算資源的預測，消除了事先投入的風險，使業務可以從小規模做起，隨著需求的增加通過業務調度和虛擬化技術快速擴展業務占用的硬件資源。

(2) 解決不同地區、不同時段的業務不均衡問題。一方面可以在日常業務量相對較低的情況下通過減少硬件資源的占用降低電源損耗；另一方面可以在節假日或未預期到的業務峰值出現時通過擴大硬件資源占用來規避運營風險。

(3) 提供了一種將大量移動網絡資源對外租借的可能。計算資源虛擬化后，能以短時間為單位付費，租借方可按需申請使用計算資源。

2 業務調度和虛擬化方案

針對上述移動運營商的迫切要求，文章給出了一種將虛擬化與業務調度相結合的整體解決方案，其模型架構如圖1所示[6]。

核心管理部件主要包括虛擬機管理系統及業務調度中心。從方案設計角度將底層物理設備的虛擬化與業務層面的處理能力控制分離。

一個應用程序必然需要一個計算模式、一個存儲模式和一個通信模式。為實現計算資源的彈性和無限鏡像，最現實的辦法就是將這些資源虛擬化，面對應用隱藏它們的復用和共享機制。不同的公用計算會根據抽象性和管理層次加以區分。本方案提出將移動通信業務計算云分為兩級進行管理，其一是將物理硬件虛擬為抽象計算單元的過程，該過程不受上層業務的影響，所有計算單元屬性均保持一致；其二是針對差異化業務的動態調度系統，可根據不同的業務處理邏輯、業務性能要求以及資源占用預期對業務系統進行伸縮性控制。通過業務調度中心與虛擬機管理系統的配合，滿足運營商多業務實時動態資源調整的要求。

目前虛擬機技術已日漸成熟，大多數主流的虛擬機廠家通過XEM、KVM等核心技術實現對硬件CPU、內存資源的虛擬單元構建，虛擬機技術主要包括以下四大特征：

可在單一物理服務器上同時運行多個虛擬單元；

在同一物理硬件設備上的虛擬機之間相互隔離；

可將完整的虛擬單元都保存在文件中，通過移動和復制這些文件的方式來移動和復制該虛擬單元；

可屏蔽虛擬單元與底層物理硬件的關聯，無需修改即可在任何服務器上平滑遷移。

虛擬化技術將物理資源轉化為便于切分的資源池，在設計理念上符合云計算的基本條件，具有通用的資源調度能力；但在通信領域的實際使用過程中，需要調度的資源不僅僅局限于虛擬單元本身，移動運營商急需一種針對不同業務應用進行集中能力控制的解決方案，可以實時監測全網多種業務流量動態，智能判斷各業務間的負荷關系，平衡硬件及虛擬單元的資源分配。

文章通過在虛擬機技術基礎上構建業務調度模塊的方式彌補了虛擬機技術對通信業務控制層面的不足。調度中心與虛擬機管理系統配合完成調度的模型如圖2所示。

調度中心內部可細分為四大功能模塊：

(1) 業務智能調度分析模塊：作為調度中心的核心處理模塊，根據實時監控采集匯總的各業務運行數據，綜合分析當前業務層處理能力情況，對各業務許可證進行調節。在必要時可通過與虛擬機管理系統直接的交互申請空閑計算單元或釋放已占用冗余計算單元，通過自動部署模塊式進行業務快速加載、卸載，動態調整業務許可證處理能力。同時該模塊還負責將業務節點的伸縮情況動態通知到外圍接口分發設備（如：四層交換機、協議接口機設備等）。

(2) 實時處理能力采集模塊：通過與各業務處理之間的交互實現對各業務實時消息處理流量、數據庫資源占用要求、處理能力狀況等信息進行采集。支持兩種采集模式：業務進程定時上報模式，以及調度子系統發消息主動驅動采集模式。并將采集到的數據寫入調度分析庫，以便進行智能調度策略分析。

(3) 自動部署模塊：根據業務智能調度分析模塊的部署消息把指定的業務包加載到指定計算單元上或停止業務清理該計算單元上的業務包程序。

(4) 人機操作維護：提供人機操作界面，一方面可對業務模塊運行狀態進行監控，另一方面可提供人工手動干預調度的功能。

調度中心通過上述的模塊化設計結構與虛擬化管理平臺協同工作，可以真正實現對移動通信領域業務處理的動態調節和資源復用。具體調度過程如圖3所示。

通過對業務處理單元進行實際業務量跟蹤監測，結合智能調度分析中心配置的調度策略與閥值，動態進行業務許可證的彈性伸縮控制。

智能調度分析策略可主要分為以下幾類[7-10]：

(1) 冗災性調度策略：針對某一業務處理單元異常情況下，分析其他同類業務處理單元是否能夠分擔該業務節點的工作，在必要時申請新的虛擬計算單元接管原有業務處理，以確保系統穩定運行。

(2) 周期性休眠策略：根據業務流量的變化識別周期性調整要求，根據規律釋放、申請計算單元。為達到業務快速啟停切換的目的，釋放的計算單元可仍保留原業務程序，僅在狀態上實現休眠和激活，以節約能耗。

(3) 業務發展調整策略：根據業務發展的情況確定是否需要增加或減少計算資源的占用，并完成業務的自動加載和卸載。

以上3種分析策略是由調度中心的核心部件——智能調度分析模塊予以實現，該模塊負責根據監測到的數據對虛擬資源進行整體調控，為實現非人為干預的動態調控需要通過一系列比對算法完成多項指標的評測，根據綜合評測結果發出資源調配指令[11]。為簡化描述，文章僅給出一種通用計算模型：

(1) 采樣條件：

采樣時間間隔：1s。

(2) 采樣數據：

當前采樣點虛擬單元承載“業務類型1”處理許可證為：Llic；

當前采樣點虛擬單元占用CPU為：Lcpu；

當前采樣點虛擬單元占用內存為：Lmemory；

當前采樣點虛擬單元占用輸入輸出端口(I/O)資源：Lio。

上述參數在計算中所占權值分別為R1-R4，該權值表示不同類型的業務應用在計算單元中占用的資源偏差[12]。例如，短消息服務中心(SMSC)業務處理服務器，我們采用以系數{0.3， 0.3， 0.3， 0.1}，這里認為計算單元在承載SMSC業務時CPU占用、許可證處理及內存較其他參數重要一些。若當前的系數Ri（指R1-R4）不能很好地反映應用的負載，可以對系數不斷地修正，直到找到貼近當前應用的一組系數[13-15]。

(3) 采樣值計算公式：

LOAD(Ni)= R1×Llic (Ni)+R2 × Lcpu(Ni )+R3× Lmemory(Ni)+R4 × Lio(Ni)

(4) 判斷周期及方法：

針對上述加權后的負載值，可通過多次連續取樣的方式進行綜合判斷。關于采集權值的周期設置，雖然很短的周期可以更確切地反映各個計算單元的即時負載，但是很頻繁地采集會給調度中心和被檢測計算單元帶來負擔，也可能增加不必要的網絡負荷[16]。為解決該問題可適當地調整采集負載信息的周期（建議可以在10~15 s）；同時使用滑動窗口來避免采樣數據的抖動。

(5) 調度決策：

根據以上多次周期性采樣獲得的數據結合虛擬單元的負載區間進行比對，實現對計算單元負載的智能判斷并采取相應的調度處理策略。

通過以上方案可切實解決移動運營商建設可伸縮性業務平臺的要求，有效降低業務平臺的資本性支出(CAPEX)和運營成本(OPEX)，減少投資浪費，獲取更大的利潤空間。

3 結束語

在目前移動通信網絡各業務平臺仍處于獨立建設的情況下，運營商在前期建設投資過程中往往都是根據預測的節假日最大業務量峰值評估規模，這樣即便峰值預估準確也會造成投資的浪費。同時如果低估了峰值出現配置不足的情況，則可能會導致直接拒絕超量用戶的業務請求。不僅被拒絕的用戶不可能帶來任何收益，而且由于業務服務感知差，致使用戶失去信心不會再次使用，造成用戶流失的嚴重后果。

如圖4所示，通過業務層的動態調度結合虛擬化技術可使資源分配與實際業務量曲線趨于一致，規避上述兩種情況的發生。

文章中提出的“業務調度和虛擬化”是移動通信網絡云化的一種可選方案，具備云計算思想的以下特征：

(1) 可按需獲取看似無限的計算資源，使云計算用戶不用在提供服務很久之前就要做計算資源的計劃。

(2) 消除了云用戶的事先投入，從而使業務可以從小規模做起，隨著需求增加來擴展他們的硬件資源。

(3) 能夠以很短的時間為單位付費按需使用計算資源，不需要的時候就將這些資源釋放。這樣，通過將閑置的機器和存儲器釋放來節省開支。

業務調度和虛擬化技術方案的提出為移動通信產業的計算云落地提供了一種具體的解決思路和方法。相信在不久的將來，業務調度和虛擬化技術的解決方案會逐步成為移動通信產業的主要建設模式。

4 參考文獻

[1] Armbrust m， Fox a， Griffith r，et al. Above the clouds: A Berkeley view of cloud computing[R]. UCB/EECS-2009-28. University of California at Berkeley， 2009.

[2] Washington post case study: Amazon Web services [EB/OL]. [2008-03-13].http://aws.amazon.com/solutions/ case-studies/washington-post.

[3]Amazon.com CEO Jeff Bezos on Animoto [EB/OL]. [2008-04-21].http://blog.animoto.com.

[4] Vouk M A. Cloud Computing-Issues， Research and Implementations[C]// Proceedings of the 30th International Conference on Information Technology Interfaces(ITI’08)，Jun 23-26，2008， ?Dubrovnik， Croatia. Piscataway，NJ， USA: IEEE， 2008:31-40.

[5] BARROSO L A， HOLZLE U. The Case for Energy-Proportional Computing[J]. IEEE Computer，2007，40(12):33- 37.

[6] Bechtolsheim A. Cloud Computing and Cloud Networking. Talk at UC Berkeley[EB/OL]. [2008-08-10]. http://fi.consolidate-it.eu/tool_userfiles/file/CloudNeworkingQandA2008.

[7] 云計算的演進和挑戰性問題(3).[EB/OL]. [2009-05-13].http:// www.cncloudcomputing.com/jinghua/182_3.html.

[8] Dean J， Ghemawat S. MapReduce: Simplified Data Processing on Large Clusters[C]// Proceedings of the 6th USENIX Symposium on Operation Systems Design and Implementation (OSDI'04)， Dec 6-8， 2004， San Francisco， CA USA. Berkeley， CA， USA: USENIX Association，2003:10.

[9] BULKELEY W M. IBM， Google， Universities Combine ‘Cloud’ Foces[J].The Wall Street Journal，2007-10-08.

[10] Demers a j， Petersen k， Spreitzer m j，et al. The Bayou Architecture: Support for Data Sharing Among Mobile Users[C]// Proceedings of the 1st IEEE Workshop on Mobile Computing Systems and Applications (WMCSA’94)， Dec 8-9，1994， Santa Cruz ，CA， USA. Los Alamitos，CA，USA:IEEE Computer Society， 1994: 2-7.

[11] Garfinkel s l. An evaluation of Amazon’s Grid Computing Services: EC2， S3 and SQS [R]. TR-08-07. Harvard University， 2007.

[12] Ghemawat s， Gobioff h， Leung s t，et al. The Google File System[C]// Proceedings of the 19th ACM SIGOPS Symposium on Operating Systems Principles (SOSP’03)， Oct 19 - 22， 2003， Bolton Landing， NY， USA. New York， NY， USA: ACM， 2003: 29-43.

[13] Gray J. Distributed Computing Economics[M]. New York， NY， USA:ACM Press， 2008:63-68.

[14] Gray J， Patterson D. A Conversation with Jim Gray[M]. New York， NY， USA:ACM Press， 2003:8-17.

[15] HAMILTON J. Cost of Power in Large-Scale Data Centers [EB/OL]. [2009-05-13].http://perspectives.mvdirona.com/2008/11/28/CostOfPower.

[16] HAMILTON J. Internet-Scale Service Efficiency[C]. Proceedings of the 2nd Workshop on Large-scale Distributed Systems and Middleware (LADIS'08)， Sep 15-17， 2008， Yorktown Heights， NY，USA. New York，NY，USA: ACM，2008.

收稿日期：2010-08-11

歐陽新志，南京理工大學計算機科學及應用專業畢業，現就職于中興通訊業務研究院消息類產品研發總工；主要研究業務運營融合業務云，曾從事語音、短信、WAP等項目的研發和市場方案推廣工作，對移動增值業務和互聯網業務有多年的了解和研究。