王景艳,刘 洋
(中国铁路信息科技集团有限公司 运行维护与生产调度部,北京 100844)
中国铁路主数据中心是铁路一体化信息集成平台的核心,承担着铁路信息资源服务、关键业务计算、数据存储备份等重要任务[1]。主数据中心基础设施基于云平台搭建,实现重要信息资源的集中存储、管理和综合利用,确保核心业务应用系统的安全性、可靠性和连续性[2]。为保证业务连续性要求和信息系统合规性要求,铁路灾备中心即将投入建设,如何利用基础设施云平台满足铁路应用系统灾备需求是亟待研究解决的重要课题。
灾备技术自上世纪70 年代起源,经历了信息系统备份、灾难恢复规划(DRP)、业务连续性规划(BCP)3 个阶段,关注重点由备份技术本身逐渐发展为生产中心保障,再到业务保障和恢复。随着业务连续性要求的不断提升,越来越多的行业加强了灾备技术的研究与灾备中心的建设[3-4]。铁路灾备技术研究起步较早,目前12306 互联网售票和电子支付应用已完成双活中心建设,货运票据电子化应用双中心也已上线,实现跨不同数据中心的高可用[5]。传统灾备技术(如数据复制技术、双活技术、业务切换等)已在铁路信息系统灾备建设中有较为成熟的应用经验[6]。在云环境下,大量灾备新技术逐渐取代传统技术,如IP 存储网络替代FC 存储网络,通过域名系统(DNS)实现大二层网络[7];通过智能DNS 实现应用双活,满足基于域名的灾备切换需求[8];使用虚拟机、容器代替实体机,实现整体系统灾备和灾备调度[9];基于虚拟机的CDP 技术,实现数据同步和灾备等[10]。
本文主要研究铁路主数据中心适用的灾备关键技术,并根据铁路应用系统特点提出灾备等级划分建议。
数据复制技术由下至上可分为存储和操作系统层、数据库层、应用层,如图 1 所示。
图1 数据复制技术层次划分
(1)基于存储和操作系统层的数据复制:基于系统底层物理卷、数据块,通过存储硬件、虚拟化存储等实现,与上层的应用和逻辑无关。
(2)基于数据库层的数据复制:大部分数据库提供数据复制工具,实现数据的物理复制和逻辑复制,主要有日志复制重做、日志交易解析复制重做等几种方式。
(3)基于应用层的数据复制:通过双写实现,可根据需要采用强一致性、弱一致性、最终一致性设计。
(4)数据备份:利用备份软件实现数据复制,复制成本低,可节约传输带宽和存储空间;其缺点是RTO 相对较高,一般作为最后的恢复手段。
应用系统的双数据中心部署通常有4 种模式:主备、互备、双活、准双活。
(1)主备模式:只有生产中心承担业务,灾备中心作为生产中心的备份;当生产中心出现故障时,灾备中心接管生产中心的业务,如图2a 所示。
(2)互备模式:主备中心互为备份,生产中心和灾备中心可同时承担业务,避免浪费灾备中心资源;当一个中心故障时,其业务转移至另一中心,如图2b 所示。
(3)双活模式:双活应用部署在两个数据中心/ 机房,同时在线运行,用户请求通过负载均衡设备分配到不同数据中心的应用服务器,两中心的数据库实时同步;当一个中心出现故障时,通过负载均衡将请求切换到另一中心,如图2c 所示。
(4)准双活模式:与双活模式的主要区别是,不进行两中心的数据库实时同步,应用服务器与指定中心的数据库进行实时数据交换,两中心的数据库定期同步,如图2d 所示。
图2 数据中心主备/双活部署模式
这4 种部署模式中,双活模式可最大程度保障业务连续性。采用双活技术建设容灾系统,涉及接入层、应用层、数据库层、存储层和网络层的改造,各层次中均有相应的解决方案。
(1)接入层双活一般可采用DNS 和全局负载均衡(GSLB)机制构建接入层双活架构,根据后端服务器负载和链路状况实现不同中心间流量调配。
(2)应用层双活需要在每个数据中心分别部署一套完整的且规模相同的服务和应用,平时每个中心均为生产中心,具备接管其它中心业务的能力。
(3)数据库层包含物理数据库和内存数据库两类,物理数据库层可采用Active-Standby、Active-Active 或第三方数据复制软件实现,内存库双活集群部署可采用读写分离、读写并行、线性拆分或分布式集群4 种模式实现。
(4)存储层双活实现方式包括基于远程卷管理软件的虚拟化、基于存储网关虚拟化、基于存储自身卷镜像3 种技术。
1.3.1 业务切换
业务切换技术主要包括接入层切换、应用系统间/应用系统内切换和数据复制切换。
(1)接入层切换:在网络接入层面将源端业务切换到备端数据中心,以保障业务的连续性,包括网络切换、安全切换、负载均衡切换。
(2)应用系统间/应用系统内切换:在灾备切换过程中,应用系统之间、应用系统内子系统之间可能存在技术依赖关系,由此产生应用系统间或应用系统内不同的灾备切换次序要求,灾备管理人员需要制定合理的灾备切换策略,通过灾备切换流程文档或灾备切换管理软件来设计实现相应的流程。
(3)数据复制切换:许多高可用软件提供切换能力,支持存储、存储网关、数据库、应用等各层次切换。存储切换需要先将上层的应用和数据库停止,反转存储的远程复制关系,启动数据库和应用,向灾备中心的存储写入数据,将数据同步复制到生产中心的存储上。数据库切换主要依赖数据库提供的工具,先将生产中心的主数据库降级为备用数据库,再将灾备端备用数据库提升为主数据库,反转数据库的远程复制关系,将灾备中心主数据库生成的日志传送回生产中心的备用数据库。
1.3.2 故障自愈
云平台承载的应用灾备设计可以从数据中心本地高可用、数据中心内自愈、跨数据中心自愈3 个方面进行考虑。(1)数据中心本地高可用:通过集群的保护方式,实现应用在多个宿主机之间故障迁移;当集群中单点故障时,可通过集群高可用实现应用的连续性保护,即数据中心本地高可用。
(2)数据中心内自愈:通过云服务中心动态检查应用健康状态,当发现问题时自动创建新的应用容器,同时进行应用内部的环境和应用的配置工作,启动服务继续处理用户请求;当整个应用集群出现故障时,通过镜像或容器复制的方式,镜像管理在同一数据中心的其它集群上重新生成应用,继续对外提供服务,即数据中心内自愈。
(3)跨数据中心自愈:通过云平台底层存储、对象存储或数据复制组件的同步能力,进行镜像和容器的异地数据中心保护;当数据中心出现灾难时,通过跨数据中心镜像复制的异地保护功能,在另外一个数据中心动态生成相同的应用,继续对外提供服务,即跨数据中心自愈。
云灾备服务基于云的自动化资源管理,通过将灾备服务化,提供按需服务和自服务能力,用户可在云管理平台上,按需选择备份、恢复及监控服务,根据使用情况计量和计费。
灾难恢复即服务(DRaaS)是一种云计算和备份服务模型,使用云资源来保护应用程序和数据免受灾难造成的中断,整合业务应急、切换演练等容灾调度服务,保障业务连续性。通常在应用层实现DRaaS,并与备份即服务(BaaS)集成,提供最佳的托管备份/恢复和灾难恢复,如图 3 所示。
图3 云灾备服务化模型
DRaaS 将资源复制到多个不同站点,以确保在一个或多个站点不可用的情况下进行连续备份,同时对跨备份域的各数据中心实现统一管理,解决传统灾备系统数据分散、管理难度大的问题,极大地降低扩容和维护成本。
依据对数据及业务的保障程度,应用系统灾备一般分为3 个级别:数据级、应用级和业务级。
数据级灾备是建立一个异地灾备系统作为本地关键数据的可用复制,利用网络数据复制工具,实现生产中心和灾备中心之间异步/同步的数据传输。
应用级灾备在数据级灾备的基础上,在异地灾备中心另外构建一套支撑系统,具有应用接管能力,减少系统停机时间,提高业务连续性。
业务级灾备在信息系统之外的还需考虑业务因素,包括备用办公场所、办公人员等。
应用系统不同灾备等级的特点见表 1。为每个业务系统制定灾备方案时,需要先对现有业务系统进行充分的调研和业务影响分析(BIA),确定业务系统的关键程度以及业务系统的RTO 和RPO 要求,进而确定业务系统的灾备范围和方案。表 2 列出不同等级灾备要求的应用系统推荐采用的灾备方案及应用示例。
表1 数据级、应用级、业务级灾备的特点
表2 同城/异地灾备模型
对于连续性需求高的运作类关键应用,其影响范围大,实时性要求高,RTO 要求小于6 h,不允许数据丢失。在同城数据中心/机房宜采用双活技术,将应用系统同时部署在两个数据中心/机房,同时接收用户读写请求,实现数据库双活和存储双活;异地灾备中心可使用主备模式,由主数据中心负责读写数据,备用数据中心提供热备,两个数据中心之间实现双向数据复制。这类应用双活架构如图 4 所示。
主备中心均部署应用服务器和数据库,同时承载业务;服务器和数据库采用集群形式部署,实现本地高可用。应用服务器读写本地数据库,主数据中心和灾备中心库实现同步双向数据复制,同时各自备份本地数据。用户请求通过CDN 分发给主数据中心和灾备中心;当某一中心出现故障时,可通过CDN 迅速将流量切换至另一中心,实现业务连续性保护。
云计算等新技术的日趋成熟为容灾备份提供了更多选择,铁路信息系统云化也对灾备提出新的要求。系统灾备方案设计需考虑云环境场景,确定合适的灾备连续性保护策略,对云平台与承载应用进行统一的灾备规划,并根据应用的不同灾备需求,采用不同灾备方案实现连续性保护。
图4 运作类应用双活架构
本文根据铁路信息系统实际需求,重点探讨数据复制等4 种灾备关键技术,并以典型应用为例,提出适用于不同业务需求的灾备方案。下一步的研究可针对铁路信息系统未来的“两地三中心”布局,结合业务应用灾备需求进一步细化灾备方案,深化灾难恢复即服务研究,充分发挥云环境特性,满足铁路业务系统灾备需求。