1 通信行業(yè)的新要求

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

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

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

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

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

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

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

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

2 業(yè)務調度和虛擬化方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1) 采樣條件：

采樣時間間隔：1s。

(2) 采樣數據：

當前采樣點虛擬單元承載“業(yè)務類型1”處理許可證為：Llic；
   　 當前采樣點虛擬單元占用CPU為：Lcpu；
 　   當前采樣點虛擬單元占用內存為：Lmemory；
 　   當前采樣點虛擬單元占用輸入輸出端口(I/O)資源：Lio。

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

(3) 采樣值計算公式：

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

(4) 判斷周期及方法：

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

(5) 調度決策：

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

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

3 結束語

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

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

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

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

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

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

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

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] 云計算的演進和挑戰(zhàn)性問題(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.

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