业务平台云化评估方法研究
2013-02-28谭志远宫云平周文红
谭志远,宫云平,周文红
(1.中国电信股份有限公司广东研究院 广州510630;2.中国电信集团公司 北京100032)
1 引言
云计算虚拟化技术的引入为业务网络演进、资源整合提供了新的技术手段。云计算虚拟化技术越来越成熟,应用越来越广泛,并经过近两年来基于云计算技术对业务平台进行关停并转的现场试验,验证了基于云计算虚拟化技术在整合资源、提高资源利用率、降低维护成本、增加业务平台的整体容灾性能等方面的能力,能给现阶段业务平台的运营维护带来质的变化。
现阶段对于重要业务平台(如WAP网关、彩信中心、短信中心等),是否进行云化始终存在顾虑,因为这些业务平台其承载的业务量大、用户量多、影响面广,担心云化后可能给这些业务平台的安全运行带来诸多不可预测的隐患,因此在推进重要业务平台云化方面始终比较慎重。
究竟哪些业务平台适合云化,哪些业务平台不适合云化,如何评估,其评估的依据和方法是什么?本文结合云计算技术的特点和业务平台的实际情况,探索了一套针对业务平台是否可云化的评估方法,并形成了可量化、可操作的评估体系,希望能对业务平台的云化起到指导作用。
2 业务平台云化的定义
(1)业务平台云化
业务平台云化是把现有业务平台迁移到云计算资源池承载的简称,即针对现有业务平台,经过云化评估后,把可云化的业务平台通过P2V(physical-to-virtual,把物理机中的应用系统迁移到虚拟机中)模式或者新建模式(在云计算资源池中的虚拟机上重新部署业务平台运行环境)把业务平台迁移到云计算资源池中。
(2)部分云化
根据业务平台的实际情况或需要,把业务平台中部分模块迁移或部署到云资源池中,而业务平台中的其他模块保持传统的承载方式不变(直接使用物理机)。
(3)融合云
本文中融合云的概念是指x86云与小型机云混合组网的解决方案,即根据实际需要,把业务平台的部分模块迁移或部署到x86云,部分迁移或部署到小型机云的混合解决方案。
3 服务器虚拟化技术及特点
根据目前云计算服务器虚拟化技术的发展,主要存在两个不同的发展方向,即“1变多”和“多变1”两种方式,两种方式的比较见表1。根据现网业务平台云化实际应用场景和云资源池的建设情况,本文主要讨论“1变多”的情况(大型机的虚拟化除外),即把一台物理服务器虚拟成多台虚拟机供业务平台使用。根据资源池服务器类型的不同,云资源池也存在如下几种情况:使用小型机虚拟化技术构建的云资源池(以下简称小型机云)、使用x86服务器构建的云资源池(以下简称x86云)以及小型机云和x86云混合使用构建的融合云资源池。
表1 服务器虚拟化的两个方向
服务器虚拟化后,最显著的特点是实现计算、内存、存储、网络等资源的共享,并且各虚拟机的资源可按需分配。与传统的业务平台部署不同,各虚拟机与底层硬件之间多了如图1所示的虚拟化层(hypervisor),因此需要结合这些特征以及业务平台的实际情况综合评估业务平台是否可云化,是否适合云化。
图1 服务器虚拟化“1变多”
4 云化评估方法
基于云计算的虚拟化技术可以把现网设备老化、资源利用率低、生命周期短、业务突发性高且符合云化条件的各种业务平台(优先考虑对小业务平台、短生命周期平台、离线分析平台、硬件故障率高、过保或维保即将到期的业务平台)迁移到云平台统一承接,实现业务平台的资源整合。
根据现网业务平台实际云化的经验和云计算技术的特点,不是所有的业务平台都适合迁移到云资源池中,业务平台是否可以云化会受制于诸多因素,因此在实施业务平台云化前务必做好充分的评估,什么类型的业务平台适合云化,需要从哪些方面评估业务平台是否可云化。
为了更充分地评估业务平台是否可以云化,在评估前需要先收集现有待云化业务平台的一些基本数据,通过业务平台的现状,再结合云计算的特点综合评估业务平台是否可云化。
4.1 业务平台资料收集
收集待云化平台的基本资料,主要包括平台设备使用情况和业务特性方面的资料。在物理设备方面,收集业务平台的服务器设备、网络设备、存储设备以及其他特殊设备(信令卡、加密狗等)等相关资料,主要包括平台涉及服务器的数量,各服务器的操作系统种类和版本、CPU数量、核数和CPU利用率、内存容量及当前平均利用率、已使用磁盘空间大小、使用网络带宽大小,平台使用外接存储资源大小、IP地址情况,使用防火墙情况以及安全控制策略、外接设备情况等。
业务特性方面收集的资料包括业务的忙/闲时情况、业务实时性要求、业务的重要程度、用户量、业务所需的I/O吞吐量等。
待云化业务平台需要采集的信息包括表2和表3所涉及的评估数据。
4.2 业务平台云化评估要素
收集到待迁移平台的资料后,从虚拟化技术特性、业务特性、维护管理要求等几个方面分析是否对业务平台进行可云化或部分云化评估。
4.2.1 云计算技术制约
根据表1所示,目前“1变多”虚拟化技术根据平台架构的不同主要有x86云和小型机云两种技术实现方式(两者组合可以构建融合云),而不同实现方式下,各厂商的虚拟化产品所实现的功能是有所差异的,因此在进行云化评估时,首先必须根据现有资源池所使用虚拟化产品的功能情况进行评估。主要有如下几个方面的评估内容。
表2 待云化平台资源使用情况汇总(1)
表3 待云化平台资源使用情况汇总(2)
(1)平台架构
待云化的业务平台如果是x86架构,可接入x86架构的云资源池(如使用VMware、Citrix、RedHat等厂商虚拟化技术的资源池);非x86架构(RISC架构)的平台,如可通过软件移植方式转换成x86架构,也可以接入x86架构的云资源池,否则只能根据平台所使用操作系统的种类选择对应厂商的小型机云(如使用HP UX的业务平台只能接入HP小型机云,使用IBM AIX的业务平台只能接入IBM小型机云)。
(2)x86资源池支持的客户操作系统
待接入x86云资源池的业务平台各模块或子系统(业务平台全部云化或部分云化)所使用的操作系统必须是资源池所使用虚拟化软件支持的客户操作系统(含版本)。虚拟化产品所支持的客户操作系统及版本情况可查询对应公司虚拟化产品支持GuestOS的兼容性列表。
(3)不能虚拟化的特殊外接设备
对于业务平台中使用特殊外接设备(如信令卡、语音板卡、传真卡、调制解调器、安全软件狗、硬件加密设备等)的模块,当服务器虚拟化软件不支持对特殊设备的虚拟化,且无法通过其他技术(如通过USB over Network技术解决虚拟化软件不支持特殊USB设备的问题)解决业务平台使用特殊设备的问题时,将无法云化,这种情况下可对平台中符合条件的模块进行部分云化。
4.2.2 业务特性需求制约
云计算虚拟化“1变多”的技术就是把物理机虚拟成多台虚拟机使用,其目的是提高服务器资源的利用率,但当需要把一个本身对资源要求高且平时资源利用率就很高的平台迁移到虚拟机上运行时,这就违背了虚拟化的初衷,并且由于实施虚拟化后物理服务器上需要运行Hypervisor软件,将更加降低服务器的利用率。这种业务平台就不建议迁移到云资源池中。同时对于高I/O要求的业务平台也不建议云化,一方面虚拟化层的增加会对I/O处理有所牺牲(虽然虚拟化产品厂商承诺影响较小);另一方面资源池需要使用共享存储以实现高可靠性和动态迁移等功能,如果大量高I/O要求的平台统一承载在一个共享存储上,共享存储将是一个较大的瓶颈。另外,鉴于目前云计算技术在安全领域尚未给人们足够的信心,对于承载安全性比较重要的业务平台,也是必须要评估的因素。综上所述,在业务特性方面,结合云计算的特点建议从如下几个方面进行评估。
(1)CPU资源
对于CPU资源要求非常高的业务平台,如现有系统或应用运行在8核及以上(因目前虚拟化厂商的产品最大支持8核,今后可根据虚拟化厂商产品的发展,修订评估依据)的CPU物理服务器上,且平时平均利用率超过50%,暂不建议进行虚拟化或把该平台对CPU资源需求低的模块进行部分云化。
(2)I/O吞吐量
对于I/O吞吐量大的业务平台,如系统或应用运行在每块网卡上的平均网络带宽需求超过100 Mbit/s,对存储LUN的平均IOPS大于2 000,平均吞吐量大于100 Mbit/s的DISK I/O暂不建议进行虚拟化或采用部分云化吞吐量小的模块。
(3)安全敏感性
对于安全等级高或涉及敏感数据的业务平台,暂不建议云化。
4.2.3 维护管理制约
业务平台云化后,在日常维护管理手段和云化可操作性方面也必须进行一定的评估,主要评估内容如下所述。
表4 业务平台云化评估
(1)维护手段或方式
对于云化后,无法按照维护界面要求或无技术手段实现对业务平台远程监控和维护的平台,不建议云化。
(2)网络迁移的可行性
评估业务平台云化后网络迁移的可行性,特别是部分云化的业务平台,从效益、效率、可执行性方面进行组网方案的评估。
(3)业务的忙/闲时
在实际云化时,可根据业务平台的忙、闲时的不同,把能实现错峰填谷效果的业务平台配置在资源池的同一个集群中,将能更好地提高资源池的利用率,不建议把峰谷同步的业务平台整合在一个集群中承载。
4.2.4 云化评估
将上述评估要素整理成评估模板,见表4,在云化过程中可根据业务平台的实际情况,对照评估模板进行评估,可得到业务平台是否可云化的结论。
5 结束语
本文总结笔者近几年在实施业务平台云化方面的工作经验,结合云计算虚拟化技术发展的现状,根据业务平台的实际情况,摸索出了一套业务平台云化的评估方法,探讨了在实施业务平台云化过程中需要重点关注和评估的3个方面,并针对3个方面的评估提出了具体的评估要求和参考指标,希望能在实施业务平台云化工作中给读者以指导和启迪。
1 谭志远,宫云平.云计算给业务平台的发展与运维带来的机遇与挑战探讨.电信科学,2011,27(10A):6~10
2 谭志远.中国电信移动增值业务平台快速云化解决方案.中国电信集团公司网络运行维护事业部,2012