计算机中文核心论文业务云平台容灾策略探讨
所属栏目:计算机网络论文
发布时间:2014-09-27 14:13:06 更新时间:2014-09-27 14:35:04
计算机专业研究生中文核心论文发表期刊有《电子科技》创刊于1987年,月刊,每月15日出版。主要刊登高等院校、科研院所、电子行业企事业单位等科研机构在电子技术应用、通信工程、计算机科学技术与应用、网络安全及信息、光电子材料等领域最新的学术、技术论文、工程技术应用研究、教学实践总结、行业综述等稿件。
【摘 要】云资源池集中承载业务平台实现了资源共享,降低了投资,节省了维护成本,推进了平台的集约化维护,但同时也带来了新的安全隐患,所有风险都将集中在云资源池,一旦云资源池出现问题,将严重影响其所承载的所有业务平台的安全。基于此,通过结合云计算技术特征及业务平台容灾的实际需求,从资源池的硬件层、虚拟化层、业务平台层等多个维度探讨了业务云平台的整体容灾策略。
【关键词】云平台,容灾策略,高可用性,数据保护,灾难恢复
1 引言
随着云计算虚拟化技术的逐渐成熟,在电信行业有越来越多的新建业务平台都将部署在云资源池上,并且部分传统业务平台也将陆续迁移到云资源池上。云资源池集中承载业务平台可实现各平台间的资源共享,但同时所有的风险都集中在云资源池,一旦云资源池出现问题,如云资源池的共享存储瘫痪,将严重影响其所承载的业务平台的安全。另外,通过资源共享统一承载业务平台这种新的承载模式,传统业务平台的容灾策略也需要适应这种新的变化做出相应的调整。
在此背景下,本文尝试从多个维度来分析云资源池所承载业务平台的整体容灾策略。
2 业务云平台容灾策略
云平台容灾的目的是为了保障其所承载业务的连续性,而业务的连续性涉及到三个方面的要素,即:HA(High Availability,高可用性)、DP(Data Protection,数据保护)、DR(Disater Recovery,灾难恢复)。
要实现容灾,必然离不开资金的投入,根据云平台的特点,要实现这三个要素所投入的资金或者说付出的代价是不一样的。因此,在实际规划或建设中,可以根据需要并结合业务平台的重要程度,实现不同级别的容灾(即通过容灾要素的不同组合实现不同级别的容灾),如图1所示:
云平台的高可用性(HA)是基础,在此基础上,对于一般性业务平台实现数据保护(DP),对于重要的业务平台为确保业务的连续性,实现灾难恢复(DR)。因此,实际部署资源池(或选择业务平台所承载的资源池)时,可结合业务平台的重要程度部署或选取具备HA、DP、DR等不同组合的资源池。
另外,各要素的实现对于云平台以及所承载的业务平台来说,涉及到不同的容灾策略和措施。因此,本文探讨的容灾策略是根据上述三要素,分析各要素所涉及的内容,再根据具体的内容有针对性地探讨容灾策略和解决思路,如表1所示。
2.1 高可用性(HA)
为提高云平台以及其所承载业务平台的高可用性,可以在硬件层、虚拟化层、应用层等维度分别考虑实现高可用性。
(1)硬件层
对于云平台所使用的硬件,主要包括:服务器、路由器、交换机、负载均衡器、防火墙、光纤交换机、网卡、电源等。
要确保硬件层面的高可用性,必须保障所有硬件设备的冗余配置。根据现网的实际情况,服务器、交换机、防火墙、路由器、负载均衡器、供电等都有冗余配置,而共享存储由于投资成本的考虑,目前一个资源池只有一套共享存储。因此从硬件层面来说,共享存储是主要的隐患来源。但共享存储一般都会配置双控制器、双电源模块、多路径访问等,相对来说具备一定的冗余性。
服务器中要求都配置双硬盘,在安装虚拟化软件前要求把磁盘进行镜像管理(Raid10),对于共享存储至少要采用Raid5以上的容灾配置。
(2)虚拟化层
要实现虚拟化层的高可用性(HA),必须启用虚拟化厂家所提供HA功能和DRS功能,并确保资源池内有足够的资源供虚拟机运行,要求所有主机都连接同一个共享存储,配置一个专用的心跳网络。
为确保VMotion的正常运作,需同一个集群中各物理服务器的CPU型号兼容(最好是同一型号);使用专用的网络来迁移虚拟机,要求网络带宽至少为千兆,并且源和目标主机具有相同的网络配置(包括网络类型、网络标签);要求虚拟机一定要位于共享存储上,并且源和目标ESXi主机都能访问到此共享存储。
(3)应用层
在应用层,建议各业务平台对于处理能力要求高的模块,尽量设计为可负载均衡或分布式计算的模块,这样可以通过多虚拟机的部署提高平台的处理能力及冗余能力。对于重要程度较高且不能通过多模块部署成负载均衡方式的虚拟机,可类似传统业务平台一样部署双机。
可根据不同业务平台的忙闲时特征,把可以实现错峰填谷效果的业务平台部署在同一个集群中,以提高资源的利用效率。为避免异常时的网络冲击,可针对各虚拟机根据业务量的估算,对出入带宽进行控制。
可根据业务平台的重要程度,部署在不同容灾等级的云资源池中,而部署在云资源池中的业务平台,在正式上线前务必经过安全扫描和加固。
2.2 数据保护(DP)
实现云资源池及其所承载业务平台数据保护功能,基于目前的技术,可分别由虚拟化层、存储系统层或应用层来实现数据保护,但从成本、备份效率等因素来考虑,可以利用现有虚拟化厂家或存储厂家提供的备份解决方案。
(1)虚拟化层实现
可以利用虚拟化厂家所提供的备份技术,例如VMware公司的VDP或VDPA备份解决方案,VMware VDPA技术实现对虚拟机的备份,其支持重复数据删除、增量、全量备份以及备份Schedule等。支持文件级别的恢复(虚拟机通过自服务门户来恢复文件),可以用于用户数据的错误删除后的恢复,与快照相比有周期性的特点,且不影响性能,业务数据可恢复过去1个月甚至1年任意时间的文件。
(2)存储系统实现
利用存储设备厂家的相关备份解决方案,例如Symantec公司的NetBackup产品,Symantec公司在其NetBackup最新产品上专为 VMware vSphere和Hyper-V虚拟化环境备份做了定制开发。NetBackup通过直接调用VMware的vStorage API实现与vCenter的集成,不需要在ESXi和虚拟机上部署任何脚本,也不需要安装VCB组件,不需要Backup Proxy就可实现VMware vSphere环境下的虚拟机备份。或者可以使用EMC Awamar的备份解决方案。 (3)应用层实现
数据保护由应用层实现,即由云平台所承载业务平台各自负责各自平台的数据保护,类似于传统业务平台的处理。操作系统、数据库等都按照传统业务平台备份思路进行数据备份和恢复。这种方式的优点是各业务平台可根据需要自行定制适合自己的备份解决方案,但各业务平台独立规划备份系统,会造成投资浪费、资源利用率低。
2.3 灾难恢复(DR)
通过建立异地容灾节点实现资源池的灾难保护,在资金允许的情况下,生产节点和容灾节点间可以通过大二层组网实现无需人工干预的自动化切换的容灾解决方案。在建设成本不足时,可以对相对重要的业务平台实现资源池异地容灾,这种情况下生产节点和容灾节点采用独立组网的方式,可以通过路由方式或DNS(Domain Name System,域名系统)方式来实现主节点到容灾节点的业务切换。
(1)大二层组网
生产节点与容灾节点间通过大二层组网实现网络互通,在虚拟化层实现虚拟机跨节点迁移,而在迁移过程中无需变更云平台上承载业务平台的IP地址,不影响外围系统的正常通讯,从而保证业务的连续性。
基于VMware、EMC、Cisco的联合解决方案如图2所示,可以实现应用/虚拟机在数据中心之间迁移,即可以实现:虚拟机在2个节点间进行 VMotion,基于EMC VPLEX本地联合和跨数据中心联合的虚拟存储,OTV(Overlay Transport Virtualization,虚拟化中继传输技术)无缝二层多站点扩展,LISP(Location-ID Separation Protocol,名址分离网络协议)优化用户到云的访问路径。
(2)独立组网
两个数据中心独立组网,生产节点和容灾节点存储间数据采用准实时同步,当生产节点异常时,通过容灾节点承载业务。例如,VMware Site Recovery Manager(SRM)是一个业务连续性和灾难恢复解决方案,可实现一个站点(受保护站点)和另一个站点(恢复站点)之间vCenter虚拟机的恢复,其中存储间可以配置使用第三方磁盘复制机制(基于阵列的复制)或VMware vSphere Replication,如图3所示。
当生产节点和容灾节点采用独立组网的解决方案时,有两种方式实现生产节点和容灾节点的业务切换:一种是DNS方式,即所有在云平台上承载的业务平台对外通过 DNS的方式互访,当主节点出问题后,外围系统访问平台时可无感知的切换到容灾节点所承载的业务平台处理(DNS与IP地址对应的关系应提前在相关系统做好数据,而业务平台中各虚拟机使用内部IP地址,通过NAT映射的方式出公网);另一种方式是修改路由的方式,通过在网络设备上修改路由指向,切换到容灾节点。当云平台承载成百上千个业务平台时,后者的可行性不大,后续维护工作量相当大。
3 结束语
云平台的高可用性(HA)是容灾的前提和基础,在此基础上实现一定的数据保护,对于特别重要、影响大的业务平台建设容灾资源池,即把重要程度非常高的业务平台承载在具备HA、DP、DR等容灾措施的资源池上,普通业务平台具备HA和DP即可。
本文根据当前传统业务平台容灾解决方案的现状,结合多年来业务平台运行的实际经验及业务平台各种故障发生的概率情况,探讨了承载在云资源池上的业务平台容灾解决方案,并提出了根据平台的重要程度采用不同级别的容灾措施,希望能对云平台相关维护人员或云资源池建设人员有所参考。
参考文献:
[1] 谭志远,宫云平,陈喜洲. 云计算给业务平台的发展与运维带来的机遇与挑战[J]. 电信科学, 2011,27(10A): 6-10.
[2] 许辉阳,李