1. 云容灾的定义

信息系统容灾不是一个新事物。从定义上看,灾难恢复(disaster recovery)是为了将由人为或自然的原因造成的信息系统严重故障或瘫痪,恢复到可正常运行状态,并将其支持的业务功能,从灾难造成的不正常状态恢复到可接受状态,而设计的活动和流程。而云容灾我们可以理解为在传统容灾定义的基础上,将容灾对象重点聚焦在上云的业务。业务上云后,云计算技术为业务容灾提供了更先进以及更高性价比的方案。但同时更复杂的云架构也给容灾带来了更大挑战。

2. 容灾技术演进

不管是传统容灾还是云容灾都有一个共同点,那就是服务于业务系统。而不同业务系统对容灾的要求不尽相同,即RPO、RTO要求不一样。我们很难使用一种技术或产品,满足不同的业务等级要求,融合多种技术手段达到最恰当的效果才是容灾的目标。下面我们将用户需求由简单到复杂来进行说明,并阐述常用的保护手段。

   第一类,冷备:业务的RPO和RTO要求都不高,当发生灾难时,只要数据不丢失就能满足用户要求,可以通过重新部署应用,导入备份数据来恢复业务。这种场景常见的方案和技术是数据备份,通过备份软件定期进行数据备份,由于恢复业务需要手动进行业务重建和恢复数据,因此也叫冷备。

冷备场景除了备份数据,也可以备份应用程序、操作系统甚至是主机,这样可以在进行业务恢复时降低RTO。冷备为一些低要求的应用提供了最省钱省力的方案。但在数据中心级灾难真实发生时,冷备业务恢复往往需要数天甚至数周时间来排队恢复。因此,改进冷备的RTO能力将为用户提供更高的附加价值。

   第二类,热备:业务的RPO和RTO要求都比较高,当发生灾难时,用户希望在最短的时间内恢复业务。在早期,针对此类需求常见的解决方案是热备,即在灾备侧构建出一样的系统,实时同步生产侧和灾备侧的数据和业务状态,当发现生产环境发生故障,立即由备机的应用进行接管。

常用的是双机热备类产品和技术,一般两台机器会涉及到配置VIP和探活心跳,有二层网络要求等。热备的主机需要在线,但不承载业务,资源闲置造成方案成本较高,要求也比较苛刻,一般在同一个机房或者园区内使用,在跨中心或者异地很难构建和使用。

   第三类,双活:业务的RPO和RTO要求更高,当发生灾难时,用户希望业务访问不中断,可以从多入口访问。这类就是典型的应用双活所应对的场景,数据层一般通过数据库的主从同步/异步复制来解决,应用层一般是无状态的,可以直接在主站和灾备站点分别部署。入口处有2个或多个,因此在前端一般还需要一个接入层,对接入请求做负载均衡。

这样任何一台应用服务器故障时,其他机器都可以接管访问流量,对外持续提供服务。该场景涉及到的技术包括数据库的复制技术,负载均衡以及应用读写分离设计等。双活方案一般需要应用和数据库做相应的开发,前期投入比较大。

图:容灾、多活架构演进

对于冷备、热备和双活实现方式和技术比较多,综上所述可以看出,通过数据备份、数据库同步/异步复制、双机热备软件、负载均衡以及业务读写分离等技术和手段基本可以满足业务容灾的需求。但随着用户业务量变大、业务类型增多,用户的需求也更多样化。这会带来大量的手动配置,高成本的复制链路以及复杂的运维工作。尤其是随着业务上云进程的推进,业务形态也更丰富,如容器、裸金属、虚拟机、云数据库、云中间件等算力载体和业务的组合让容灾变得更加复杂。

3.浪潮云海容灾实践

云计算技术的发展让服务形态多样化,但同时也带来了更加先进和高性价比的业务连续性方案,来帮助用户构建最佳的容灾方案。浪潮云海经过大量项目实践,面向用户不断演进的IT系统和环境,打磨出可分级、可继承、可演进的产品方案。我们在做产品规划时一直在不断思考用户需求演进过程中的痛点,以求覆盖演进过程中每一类应用需求,让方案为不同应用提供最佳性价比的容灾方案,降低容灾运维复杂度,缩短业务RPO和RTO,兼顾用户历史资产和未来规划。

图:本地、同城、异地多级灾备体系

3.1可分级技术

可分级是指根据用户业务的分级,提供全面的分级保护能力。我们以两地三中心的方案实践来举例说明。某用户业务上云后大部分应用都以虚拟机或容器形式部署,根据用户业务对RPO和RTO的要求不同,可以分为三类应用。如一类应用需要满足RPO<30分钟,RTO<6小时;二类应用满足RPO<2天,RTO<24小时;三类应用RTO/RPO<7天。

针对三类应用的需求不同,我们为每类应用在本地、同城、异地分别提供不同等级,不同手段的保护方案。如针对二三类应用的容灾,我们提供本地高可用、本地备份、同城和异地虚拟机容灾、容器容灾。在本地应对主机级、机柜级故障可实现分钟级疏散。

早在2020年,浪潮云海联合信通院开展的大规模云性能测试期间,我们就已经向外界展示了5分钟机柜级故障的业务恢复能力,10分钟AZ级故障的业务恢复能力。针对二三类的同城和异地容灾,浪潮云海提供“准热备”级的容灾能力,通过结合浪潮存储的同步/异步复制能力,可以做到RPO≈0。同时结合浪潮自研容灾管理组件Neptune为用户提供便捷的容灾管理工具,可实现最小接近分钟级的RTO恢复能力。针对一类应用,在数据中心内借助SLB本地负载均衡,跨数据中心借助全局负载均衡,数据库双活和读写分离等技术为用户构建业务双活方案。

3.2可继承技术

企业用户的基础设施和业务在不断变化,如出现不同品牌,演进出不同架构,已有独立容灾产品等。这种驱动可能来自于企业多供应商防绑定的策略、分层解耦要求或者市场变化等多种原因。这对构筑容灾方案带来了一定的困难。

目前常见的云容灾方案对已有基础设施并不友好,往往需要推倒重构,要求使用同品牌存储和云平台。浪潮云海在考虑对用户现有资产投资保护时,加大了对异构、利旧基础设施的支持能力。如在数据复制层面,我们即可以整合存储厂商的存储复制技术,提供基于存储同步/异步的数据容灾方案;同时也可以支持文件系统级别的数据复制,这样可以屏蔽存储设备的差异,提供异构存储的容灾方案;在生态方面,我们支持主流容灾备份厂商的产品,可以实现方案整合,同时有效降低重复采购成本。

在异构存储容灾场景,用户可以通过浪潮云海InCloud容灾管理模块将生产站点的虚拟机配置信息、虚拟磁盘数据异步复制到灾备站点,当生产站点故障时,可通过一键切换,使业务系统在数分钟内切换至备份站点运行。容灾功能和存储无关,支持包括分布式存储、集中式存储和双活存储等任意类型,且不要求生产站点和备份站点类型一致。该方案中的数据复制依赖虚拟化层的卷级复制功能,相比传统CDP,无需在虚拟机内安装代理,大大降低了对业务系统的侵入。

图:双站点容灾

3.3可演进技术

提到演进,这里不仅仅是指产品能力的迭代与演进,更多是指能够与用户的IT系统和环境共同演进,在保护老旧资产投资的同时布局未来。如从单一架构到一云多芯演进,从一朵云向多云、分布式云,从中心到边缘,从云就绪到云原生,从计算到智算演进等等。

在向云原生的演进过程,浪潮云海提供虚拟机、容器统一的容灾方案。在容器容灾上,支持一键式容器应用和命名空间级别的备份恢复流程;同时以插件机制,支持多种备份形式,能够实现卷快照级和文件级的容器用户数据的备份恢复;通过云原生灾备,能够在业务系统损坏时,通过备份快速恢复用户业务系统,保证用户的业务连续性和数据安全;能够对容器应用系统整体进行一键备份和恢复,大大简化操作流程,降低用户使用成本。这些设计可以确保用户在转型中保持同等的体验,且不会因为业务架构转型造成服务质量降低。

基于一云多芯技术理念,浪潮云海InCloud OS可兼容全部主流芯片架构,是获得信通院“一云多芯”标准认证“先进级”最高认证的产品。在容灾能力上,浪潮云海可以对不同芯片架构的业务进行保护,还可以借助应用级流量切分,算力等价调度等高阶特性,保障跨架构的业务连续性。

在多芯系统中,云原生应用可以通过网关或负载均衡器将流量分发至各无状态副本实例。当应用在异构节点间迁移或弹性伸缩时,可以通过切分流量,将访问引流至对应节点的副本上。为保证服务质量不降级,根据有效算力、业务算力量化分析确定等价目标副本的规格和数量,并分配其承担的流量比例,流量切换应与业务逻辑充分解耦,采用服务网格的思想实现。

图:业务流量切分技术

4.深耕行业实践

用户的容灾需求是多样化的,浪潮云海以丰富产品能力满足不同客户的不同需求。目前浪潮云海容灾的方案可有效覆盖同城容灾、异地容灾、同城双活、两地三中心场景、异地多活等场景,支持基于超融合的小规模容灾以及超大规模的云容灾:

为某交通行业客户打造的同城容灾方案,满足五级灾难恢复能力。方案中生产中心资源池包括VMware资源池、容器资源池、OpenStack资源池,覆盖多品牌利旧服务器,对接第三方厂商的存储和硬件SDN控制器和防火墙等等。方案最终实现通过浪潮云海InCloud OS一套平台进行容灾管理,覆盖34个政务信息系统容灾。

为某金融行业客户打造“两地三域”解决方案,包括生产、容灾、测试三域,为生产业务提供同城双活以及容灾服务。方案采用一云多芯架构,较好支持了信贷、电销等核心应用上云和容灾,这也是业内较早交付的金融级的一云多芯容灾架构,对行业创新探索起到示范作用。

此外,面向公共事业应用场景,浪潮云海交付超4000物理节点的两地三中心方案。

---

「免责声明」：以上页面展示信息由第三方发布，目的在于传播更多信息，与本网站立场无关。我们不保证该信息(包括但不限于文字、数据及图表)全部或者部分内容的准确性、真实性、完整性、有效性、及时性、原创性等。相关信息并未经过本网站证实，不对您构成任何投资建议，据此操作，风险自担，以上网页呈现的图片均为自发上传，如发生图片侵权行为与我们无关，如有请直接微信联系g1002718958。