基于CDP技术构建高可用HIS数据库

吴光珍, 严跃宁, 曾梅芳

(第九〇九医院(厦门大学附属东南医院), 福建, 漳州 363000)

0 引言

第九〇九医院(厦门大学附属东南医院)作为漳州市三级甲等综合性医院之一,每日平均门诊量达4000余人次。医院信息系统(HIS)数据库伴随着医院医疗信息化建设的快速发展,围绕其建设的系统和应用规模也在不断增加。统一支付、预约挂号、微医疗、医联体、异地医保等[1]系统的上线更是让HIS系统支撑范围由院内保障逐渐延伸到院外成为了整个医院信息系统的心脏。但是在平时数据库运维管理过程中难免需要对生产数据库进行测试、调试或大规模查询等操作,极易造成数据库运行不稳定,临床业务随之出现波动进而导致业务陷入瘫痪。信息科为此制定了非常严格的数据库运维管理准则和步骤,仍无法避免对生产数据库形成干扰,数据库宕机时有发生,勒索病毒肆虐更是让数据库险象环生。如何有力保障数据库高可用性成为摆在信息管理人员面前的一道难题。

1 医院数据库现有架构

1.1 基本情况

医院数据库是一套版本为10.2.0.5的4个节点ORACLE RAC集群数据库,平均分布在2个机房2套刀片服务器上,通过SAN网络连接到EMC VNX5500存储上,2套存储通过底层的MIRRORVIEW技术实现2个机房间的LUN级数据实时同步。数据库架构如图1所示。

图1 连续性数据保护(CDP)实施前本院数据库架构图

1.2 现有架构存在的问题

1.2.1 测试库的不足之处

为了保障生产数据库的稳定,避免非必要动作对生产数据库造成影响,现有架构一般是通过搭建测试数据库来分流的[2]。当下得到一套测试数据库主要的方案有以下几种。

系统层:通过ORACLE自带RMAN技术来恢复数据库,作为数据库传统备份手段而被大量采用。但从备份数据恢复成测试库,存在恢复时间长、技术难度高、异步等特点[3]。

网络层:DataGuard是甲骨文推出的一种高可用性数据保护方案,在节点与备用节点间通过日志同步来保证数据的同步,实现数据库快速切换和灾难性恢复[4]。但是受制于版本(10.2.0.5)的原因,仅能作为数据库备份的补充手段。

存储层:HIS数据库生产数据存储卷通过底层MIRRORVIEW技术镜像同步到同型号的存储上,在需要时可以将同步手动断开,将备份端存储数据卷挂载到额外的服务器进行读取。操作难度系数大、风险高。一般只适用于生产业务的数据应急恢复。

1.2.2 生产库大规模统计查询

数据库管理实践中对生产数据库进行大规模的数据统计查询是常见的,例如医保检查、药品耗材统计、医务统计等。时间急、任务赶、数据准确、耗时长是它的基本特色。该行为势必造成生产数据库的卡机,是生产数据库最为忌讳的。

1.2.3 生产库数据库导入导出

医院在运行过程中经常接收到来自不同单位的数据导入导出需求,特别是医保全国统一编码、绩效考核、字典库、病案ICD编码、数据上报等。直接在生产库进行极有可能对HIS数据库正常运行造成影响。

1.2.4 生产库意外宕机

目前比较主流的生产意外宕机接管方案是Oracle数据库卫士DataGuard。这种方案在实践中经常遇到生产库与DataGurad之间数据不同步,导致无法完成接管动作。同时接管动作需要专业人员进行操作才能完成,稍不留神就会造成部分数据丢失,给数据库带来难以挽回损失的同时必然伴随着造成业务的长时间停机。

1.2.5 勒索病毒

勒索病毒一旦加密生产数据库后只能通过支付高昂的解密费用来恢复正常使用。传统的备份方案诸如Rman、备份软件产生的数据都在病毒侵袭的范围之内,难逃病毒的魔掌。传统解决思路是选择异地异机备份来躲避病毒的攻击,这些备份的弊端是都无法保持与主库的实时同步。通过备份来恢复生产数据库需要耗费大量的资源和人力才能完成,也势必丢失一部分数据。长时间中断势必给医院形象带来极为不利的影响[5]。

1.3 现有架构问题分析

通过对以上问题的综合分析,在平时的工作中始终避不开对生产数据库的访问。生产数据库是源头,也是数据来源,需求和操作都围绕其才能顺利完成。导致生产数据库不稳定的因素是多方面的。创建测试库是一种办法,但测试库终究是生产数据库过去某一时刻的形态,数据无法时刻与生产数据库保持一致。加之测试库随着测试行为的发生,数据库已经无法保证其准确性。为了保证统计查询的准确性,信息科就必须重新生成测试库来应对检查。如此反复,工作量极为繁重。因此在生产库出现意外宕机时寄希望于测试库来挽救无异于天方夜谭。其自身的局限性导致对勒索病毒的应对也无从谈起。亟须可替换方案来解决这个难题。

2 HIS数据库高可用性需求分析

针对现有架构在实践中出现的问题进行整理分析,实现HIS数据库高可用性,有以下几个方面的需求。

2.1 生产库影子系统

采用非传统手段建立一套HIS生产数据库镜像库。该系统能实时与HIS数据库生产环境保持一致。必要时可以回滚到过去一段时间内任意时刻,满足数据库持续性保护的需求。

2.2 生产系统高可用性需求

数据库作为医疗业务流程运转的核心,需要具有连续稳定的运行能力。作为一家三甲医院,每天需要面对数以千计的患者,数据库不稳定导致医疗业务长时间卡顿,影响患者的就诊体验,降低了医院的公众形象。

2.3 简单易得

数据库异机备份恢复或者存储挂载都需要复杂冗长的操作步骤,甚至需要专业技术人员配合才能完成。即使有详细操作步骤和丰富经验在面临紧急情况时也会捉襟见肘。为此形成一套简单易得的稳定测试库方案是当务之急[6]。将数据库统计、测试、导出等操作分流到测试库上,尽量减少对生产库的干扰。

2.4 快速有效

在管理过程中经常接到大规模查询的需求,又都需要在短时间内完成。在白天正常工作时间进行此类动作势必造成数据库大面积的死锁,造成大面积的业务卡顿。通过测试库查询面临着数据不一致的问题。因此,快速有效且能与生产库保持数据同步的测试库是十分必要的。

2.5 战平两用

在生产数据库出现意外宕机且短时间又无法恢复的情况下,DBA既要保证生产环境的故障有利于后期分析和恢复又要保持全院业务持续进行。拥有与生产库同等的计算存储资源的容灾端来临时接管是最为快速有效合理的选择。在生产环境得到恢复后又自动切换回原来的角色达到战平两用,使容灾端存储和计算资源都得到更为合理的利用。

3 基于连续性数据保护的数据库高可用性架构和原理

为了满足数据库高可用性的需求,必须根据自身业务的特点、模式和未来的趋势来规划数据库架构。鉴于医院IT系统的特点,即采用的数据集中存放、集中处理的大集中模式存在一定弊端,如果一旦生产中心核心系统和集中存储等重要系统或设备发生故障,将会影响HIS数据库高可用性进而导致全院业务中断。基于前期对数据库稳定运行需求,在最大程度保留数据库原有环境的条件下,形成一套召之即来战平两用的新型数据高可用架构[7],为此经过专家论证选型采用了易安信厂家(EMC)的VPLEX+RecoverPoint的组合。架构图如图2所示。

图2 连续性数据保护(CDP)实施后本院数据库环境结构图

方案实施后利用EMC VPLEX来进行EMC存储的数据双活,即通过VPLEX Metro将两套VNX5500组成一个镜像组,从而保证两套存储之间互为备份,任何一台存储出现故障都不会导致业务停止或者数据丢失。

3.1 连续性数据保护(CDP)原理

VPLEX提供存储虚拟化、镜像和拆封器的功能,快照、复制等特性由RecoverPoint实现。连续性数据保护持续抓取变化数据库并将其保存到本地,保证了本地数据可以恢复到任何一个时间点而无数据丢失。CDP能够在本地群集内的一个阵列或多个阵列中本地复制LUN。其流程如图3所示,第一步应用服务器向LUN发送一个受RecoverPoint保护的写请求;第二步VPLEX拆分器会截取这个写请求,拆分器拆分了写请求并将它同时发送到生产卷和RPA;当RPA收到写请求时,第三步将确认信息发送回拆封器;第四步RPA将数据连同时间戳以及任何与该写操作相应的应用、时间或用户生成的标签一起写入本地日志卷;RPA成功地将数据存储在日志卷之后,第五步再将他分发到CDP拷贝,在分发过程中保留原来的写顺序。

图3 连续性数据保护(CDP)原理图

CDP是一种连续捕捉和保护数据变化并将变化后的数据独立于初始数据进行保护的方法,而且该方法可以实现过去任意一个时间点的数据恢复[8]。可以基于块、文件或应用,并且为数量无限的可变恢复点提供精细的恢复对象。数据的改变受到连续的捕获和跟踪、所有的数据改变都存储在异地机房、恢复点目标是任意的。恢复出来的数据可以支持修改或者写入。

3.2 基于CDP的HIS环境架构设计

CDP技术是基于VPLEX+Recoverpoint的一种连续性数据保护解决方案,两套EMC VNX5500分别存放于综合楼和门诊楼两个机房,通过VPLEX Metro将存储卷镜像后形成分布式卷通过SAN交换机挂载生产数据库使用,RecoverPoint(RPA)以旁路方式接入SAN网络并注册到VPLEX系统中(见图4),将生产分布数据卷和备份存储VNX5100的镜像卷和日志卷(见图5)同时挂载给RPA管理(见图6),VPLEX通过自带的拆封器(见图7)将写入IO拆封给分布式卷和RPA(见图8),RPA通过实时监控并记录整个业务系统的数据变换情况,将变换记录捕获拆分写入I/O生产存储VNX5500到第三套存储VNX5100上。RecoverPoint对VPLEX拆分器发来的IO数据打上时间戳(见图9)并记录到IO日志卷中,根据IO日志生成任意时间点的数据。容灾端服务器利用RecoverPoint提供的任意时间点的快照磁盘,将磁盘以映射的方式提供给容灾端服务器使用,可以随时按照任意时间戳提供一套跟生产数据库完全一致的影子数据库。在必要的时候可开启容灾服务器接管生产系统的业务,保障HIS数据库的高可用性。

图4 RECOVERPOINT注册到vplex

图5 CDP日志卷

图6 分布式卷和备份卷一一对应

图7 VPLEX拆分器

图8 VPLEX拆封器拆分IO给生产数据卷和RPA

3.3 基于CDP技术构建高可用HIS数据库实际效果展示

图10是RecoverPoint处于持续保护状态下的示意图,左边HIS_CDP代表容灾端,右边HIS代表生产端,生产端的存储卷经RPA实时同步到备份端存储VNX5100上,实时复制机制使得容灾存储与生产存储的数据保持一致性和可用性,完成容灾接管的基本条件,并记录时间戳和日志保存在日志卷上。

3.3.1 容灾卷启用(test copy)

在发生误删除或者误操作导致文件丢失时通过在RecoverPoint界面简单的几步操作就可以让容灾端服务器取得存储VNX5100存储的读写权限。而且存储数据可以根据实际需要快照回滚到任意时间点,交由容灾端服务器读取找到所需文件,并将复制到生产服务器中。这种模式下容灾端就相当于生产数据库某个时刻的影子,跟生产数据库数据完全一致,且可读可写,非常适合大规模统计查询和数据导入导出,即可以保证数据准确又能测试效果与生产库完全一致,保证了测试有效性[9]。容灾端随时可以灾难演练校验,数据库脚本校验,保证备份数据的可用性,规避直接在生产库进行可能发生的数据库宕机。

3.3.2 全库恢复

可以通过Recover Product实现生产库的回滚回退,这些在平时需要专业人员耗费大量时间才能完成的操作在RecoverPoint上仅仅通过简单的鼠标点击就可以完成。

3.3.3 故障切换(failover)

容灾端可以应急接管任意时间点的数据库状态。当生产库服务器意外宕机,可以随时failover到容灾端且保持原有生产数据库的数据,无缝衔接完成数据库割接,保证数据库高可用性。信息管理人员从容修复生产库,不用担心业务中断。认真仔细梳理生产数据库故障发生的原因,彻底完成修复工作以防止故障的再次发生[10]。当故障修复后再次进行角色互换回迁到原生产库,由原生产库继续对外提供服务。角色自由切换、方便灵活、操作简单。

4 基于CDP技术构建高可用HIS数据库取得的成效

市面上大部分CDP解决方案需要在生产数据库安装代理客户端或者将备份卷挂载到生产数据库实现连续性数据保护,两者都需要对生产环境进行修改并消耗主机的资源来达到效果。这对于已经上线的数据库是难以接受的,实施过程和运行中都可能会对生产环境造成干扰,不利于数据库稳定运行。架构底层通过存储网络拆分方式完成,免代理、免安装、免操作,真正意义上对生产数据库架构实现了无感升级。

系统可以在保持生产数据库正常运行的情况下通过容灾备份服务器对数据镜像卷进行手动进行数据库不完全恢复。该数据库可读可写,用户可根据实际需求对任意时间点的数据进行挂载,恢复数据、日志校验、文件验证、服务验证、数据库脚本验证,免于在生产数据库运行时可能产生的风险[11]。

在生产数据库出现故障的时候可以手动启动容灾备份服务器对同步数据卷进行挂载临时接管生产数据库业务对外提供服务,实现零数据丢失和故障期间业务持续性,信息科有充足的时间对生产数据库进行故障分析和定位,避免因仓促行事造成不可挽回的损失。生产数据库故障恢复后可通过数据回写,由生产数据库继续提供服务。灵活机动给数据库管理工作提供了更多的选择。

5 总结

HIS数据库高可用性对信息管理人员提出了近乎苛刻的要求,医院将CDP技术延伸到HIS数据库高可用性应用中,通过与实际需求有效结合充分发挥CDP技术的长处全面提升了医院业务信息系统的高可用性,极大地降低非必要动作对生产库带来的风险,使医院信息系统能真正进入安全可靠的状态中。该架构不足之处在于容灾端在绝大多数时间处于待用状态,形成了一定程度上的资源浪费。后续容灾端将尝试在待用状态下直接用于统计查询甚至支持生产和容灾双写,推动整个架构的持续升级,提供更为完善的功能,推动医院基础信息化建设,为医院信息化建设核心系统注入能量,使围绕HIS展开的软件系统得到稳定的信息支撑,推进线上线下、区域信息的互联互通,为互联网医院平台功能建设打好坚实的基础条件,充分发挥互联网医院的价值。