2024年3月9日发(作者：)
移动通信网络云计算的解决方案
欧阳新志
【摘 要】云计算将计算能力作为通用性资源,提供一种弹性的资源获得模式,使业务
的提供更具伸缩性,使能源在一定程度上得到更为合理的利用.文章从移动通讯运营
商的需求入手,介绍了一种业务调度和虚拟化的计算云应用思路,为移动网络的云化
提供了解决方法,使运营商真正能够以最小的投入,产生最大的收益.
【期刊名称】《中兴通讯技术》
【年(卷),期】2010(016)006
【总页数】4页(P35-38)
【关键词】资源共享;业务调度;虚拟化
【作 者】欧阳新志
【作者单位】中兴通讯股份有限公司,业条研究院,江苏南,210012
【正文语种】中 文
【中图分类】TN929.5
1 通信行业的新要求
随着3G网络的进一步完善，运营商部署的业务平台也愈来愈多，除了当前已经广
泛运用的WAP/WEB网关、短信中心、彩信中心等基础引擎平台以外，随着业务
的进一步发展，还会陆续出现各种形形色色的业务应用平台。目前这些业务平台，
不管实现何种业务功能，不管局点大小，都是采用独立建设的模式。
通过对多个厂家的多类业务产品进行对比分析，我们得到的结论是：除了核心业务
处理模块以外，其余模块的功能基本上都是雷同的（如：计费管理模块、用户管理
模块、配置管理模块、维护管理模块、日志/报表模块等），这些模块可以通过一
定的手段进行融合与集成，从某种角度来讲可以实现一定的资源复用。但对于各业
务的核心处理部分，由于业务逻辑迥异、流程复杂，无法在业务层面做到能力共享。
这种多业务分散建设模式已逐渐成为阻碍移动通信产业高速发展的重要原因。这主
要体现在以下几个方面[1-5]：
各业务平台采用的外购软硬件类型各异，对于外购件异常带来的业务中断、系统故
障等问题较难控制和规避；各厂家业务平台提供的操作维护手段不同，需要运营商
培训大量的技术人员熟悉各种维护系统，加大了维护成本的投入；业务平台独立建
设，不同地域、不同业务的处理能力严重负载不均，投资建设的硬件资源利用率不
高。
从理论上分析，无论是何种业务，其处理逻辑都仍然属于应用程序范畴，任何应用
程序都可以简单归纳为计算模式+存储模式+通信模式的集合。为带来有弹性、容
量无限的系统，一般有两种解决办法：一是在同一机器上部署单一业务的多模块或
者选择性地部署多个业务；二是通过虚拟化技术实现统计性复用资源。前者对业务
程序的依赖度很高，需要相互之间互不影响，对于同厂家同类型业务相对比较容易
实现，只能在一定程度上实现资源共享。而虚拟化技术可以较好地隐藏资源复用和
共享的实现细节，能最大程度地减小结构上与业务的耦合性。
当然，仅依靠虚拟化技术还不能完全做到业务级弹性的调用控制，文章在下一章节
将重点介绍业务调度和虚拟化的完整解决方案。通过该方案移动运营商可得到：
(1)业务按实际处理需要合理的获取计算资源。从而使运营商不用在提供某种业务
服务之前就要做计算资源的预测，消除了事先投入的风险，使业务可以从小规模做
起，随着需求的增加通过业务调度和虚拟化技术快速扩展业务占用的硬件资源。
(2)解决不同地区、不同时段的业务不均衡问题。一方面可以在日常业务量相对较
低的情况下通过减少硬件资源的占用降低电源损耗；另一方面可以在节假日或未预
期到的业务峰值出现时通过扩大硬件资源占用来规避运营风险。
▲图1 业务调度和虚拟化概念模型
(3)提供了一种将大量移动网络资源对外租借的可能。计算资源虚拟化后，能以短
时间为单位付费，租借方可按需申请使用计算资源。
2 业务调度和虚拟化方案
针对上述移动运营商的迫切要求，文章给出了一种将虚拟化与业务调度相结合的整
体解决方案，其模型架构如图1所示[6]。
核心管理部件主要包括虚拟机管理系统及业务调度中心。从方案设计角度将底层物
理设备的虚拟化与业务层面的处理能力控制分离。
一个应用程序必然需要一个计算模式、一个存储模式和一个通信模式。为实现计算
资源的弹性和无限镜像，最现实的办法就是将这些资源虚拟化，面对应用隐藏它们
的复用和共享机制。不同的公用计算会根据抽象性和管理层次加以区分。本方案提
出将移动通信业务计算云分为两级进行管理，其一是将物理硬件虚拟为抽象计算单
元的过程，该过程不受上层业务的影响，所有计算单元属性均保持一致；其二是针
对差异化业务的动态调度系统，可根据不同的业务处理逻辑、业务性能要求以及资
源占用预期对业务系统进行伸缩性控制。通过业务调度中心与虚拟机管理系统的配
合，满足运营商多业务实时动态资源调整的要求。
目前虚拟机技术已日渐成熟，大多数主流的虚拟机厂家通过XEM、KVM等核心技
术实现对硬件CPU、内存资源的虚拟单元构建，虚拟机技术主要包括以下四大特
征：
可在单一物理服务器上同时运行多个虚拟单元；
在同一物理硬件设备上的虚拟机之间相互隔离；
可将完整的虚拟单元都保存在文件中，通过移动和复制这些文件的方式来移动和复
制该虚拟单元；
可屏蔽虚拟单元与底层物理硬件的关联，无需修改即可在任何服务器上平滑迁移。
虚拟化技术将物理资源转化为便于切分的资源池，在设计理念上符合云计算的基本
条件，具有通用的资源调度能力；但在通信领域的实际使用过程中，需要调度的资
源不仅仅局限于虚拟单元本身，移动运营商急需一种针对不同业务应用进行集中能
力控制的解决方案，可以实时监测全网多种业务流量动态，智能判断各业务间的负
荷关系，平衡硬件及虚拟单元的资源分配。
文章通过在虚拟机技术基础上构建业务调度模块的方式弥补了虚拟机技术对通信业
务控制层面的不足。调度中心与虚拟机管理系统配合完成调度的模型如图2所示。
调度中心内部可细分为四大功能模块：
(1)业务智能调度分析模块：作为调度中心的核心处理模块，根据实时监控采集汇
总的各业务运行数据，综合分析当前业务层处理能力情况，对各业务许可证进行调
节。在必要时可通过与虚拟机管理系统直接的交互申请空闲计算单元或释放已占用
冗余计算单元，通过自动部署模块式进行业务快速加载、卸载，动态调整业务许可
证处理能力。同时该模块还负责将业务节点的伸缩情况动态通知到外围接口分发设
备（如：四层交换机、协议接口机设备等）。
(2)实时处理能力采集模块：通过与各业务处理之间的交互实现对各业务实时消息
处理流量、数据库资源占用要求、处理能力状况等信息进行采集。支持两种采集模
式：业务进程定时上报模式，以及调度子系统发消息主动驱动采集模式。并将采集
到的数据写入调度分析库，以便进行智能调度策略分析。
(3)自动部署模块：根据业务智能调度分析模块的部署消息把指定的业务包加载到
指定计算单元上或停止业务清理该计算单元上的业务包程序。
(4)人机操作维护：提供人机操作界面，一方面可对业务模块运行状态进行监控，
另一方面可提供人工手动干预调度的功能。
调度中心通过上述的模块化设计结构与虚拟化管理平台协同工作，可以真正实现对
移动通信领域业务处理的动态调节和资源复用。具体调度过程如图3所示。
▲图2 调度管理模型
通过对业务处理单元进行实际业务量跟踪监测，结合智能调度分析中心配置的调度
策略与阀值，动态进行业务许可证的弹性伸缩控制。
智能调度分析策略可主要分为以下几类[7-10]：
(1)冗灾性调度策略：针对某一业务处理单元异常情况下，分析其他同类业务处理
单元是否能够分担该业务节点的工作，在必要时申请新的虚拟计算单元接管原有业
务处理，以确保系统稳定运行。
(2)周期性休眠策略：根据业务流量的变化识别周期性调整要求，根据规律释放、
申请计算单元。为达到业务快速启停切换的目的，释放的计算单元可仍保留原业务
程序，仅在状态上实现休眠和激活，以节约能耗。
(3)业务发展调整策略：根据业务发展的情况确定是否需要增加或减少计算资源的
占用，并完成业务的自动加载和卸载。
以上3种分析策略是由调度中心的核心部件——智能调度分析模块予以实现，该
模块负责根据监测到的数据对虚拟资源进行整体调控，为实现非人为干预的动态调
控需要通过一系列比对算法完成多项指标的评测，根据综合评测结果发出资源调配
指令[11]。为简化描述，文章仅给出一种通用计算模型：
(1)采样条件：
▲图3 调度处理流程图
采样时间间隔：1s。
(2)采样数据：
当前采样点虚拟单元承载“业务类型1”处理许可证为：Llic；
当前采样点虚拟单元占用CPU为：Lcpu；
当前采样点虚拟单元占用内存为：Lmemory；
当前采样点虚拟单元占用输入输出端口(I/O)资源：Lio。
上述参数在计算中所占权值分别为R1-R4，该权值表示不同类型的业务应用在计
算单元中占用的资源偏差[12]。例如，短消息服务中心(SMSC)业务处理服务器，
我们采用以系数{0.3,0.3,0.3,0.1}，这里认为计算单元在承载SMSC业务时CPU占
用、许可证处理及内存较其他参数重要一些。若当前的系数R i（指R1-R4）不能
很好地反映应用的负载，可以对系数不断地修正，直到找到贴近当前应用的一组系
数[13-15]。
(3)采样值计算公式：
LOAD(N i)=R1×Llic(N i)+R2×Lcpu(N i)+R3× Lmemory(N i)+R4× Lio(N i)
(4)判断周期及方法：
▲图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 ofcloud
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]．aws．amazon．com/solutions/case-studies/washington-post．
[3]Amazon．com CEO Jeff Bezos on Animoto[EB/OL]．[2008-04-
21]．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]．fi．consolidate-
it．eu/tool_userfiles/file/CloudNeworkingQandA2008．
[7]云计算的演进和挑战性问题(3)．[EB/OL]．[2009-05-
13]．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 WM．IBM,Google,Universities Combine‘Cloud’Foces[J]．The WallStreet
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]Garfinkels 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 ACMSIGOPS 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]．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．
发布评论