医院灾备建设选型分析

李 征

（宁波市第九医院，浙江 宁波 315020）

医院灾备建设选型分析

李 征

（宁波市第九医院，浙江 宁波 315020）

笔者根据医院核心系统HIS的灾备选型和分析，阐述当前业界的主流的容灾模型的优缺点，然后根据笔者医院的信息化规划和医院的后续业务需要进行容灾架构选型。

医院；HIS；容灾模型；容灾架构

宁波第九人民医院经过几年的发展，已经建设为现代化的综合性医院，为实现医院管理的科学化、现代化、数字化，与国际、国内信息化建设的新技术接轨，适应现代化医院的医疗、科研、教育和管理要求，医院建立起的信息系统（HIS）主要以一体化的临床系统、LIS系统、PACS系统、EIS系统、PIS系统等为基础，实现数据全面共享，共同形成全面的医院信息管理系统。庞大的系统必然产生海量数据，对于软件系统而言数据就是根本，任何操作、分析、结算等等都从数据库中提取。从某种意义上说，数据安全成为现代医院信息系统安全的重中之重。一旦数据丢失，对任何一家医院来说都会产生重大影响。

1　数据安全影响

根据长期的一线运维经验，对应用和数据安全的影响主要有以下几种情况。

1.1系统硬件故障

如系统磁盘或数据盘的损坏将导致数据不能访问，进而可能导致应用进程终止或系统停机，甚至系统不能重启动。网卡的损坏会使终端用户无法访问系统服务。CPU或内存的失效则会导致系统死机。

1.2应用程序或操作系统出错

由于操作系统或应用程序中存在BUG，当碰到某种事件符合BUG的激发条件时，应用程序会非正常终止或系统崩溃。

1.3人为错误

一些人工的误操作，如删除系统或应用文件，终止系统或应用服务进程，升级覆盖安装等，也会导致数据丢失或系统服务无法访问。

1.4电脑病毒/黑客入侵

由于目前大多数计算机系统均连接在网络上，若缺少有效的防范机制，很容易遭受病毒感染或黑客入侵，轻者数据被损坏，重者系统瘫痪。

1.5自然灾害

由于一些意外的不可抗拒的因素，如雷击、火灾、洪灾等导致的计算机系统破坏，会使一般系统的恢复非常困难且耗时，导致业务系统长时间中断（通过容灾系统来解决）。

2　主流灾备方案分析

笔者根据本院的实际情况，考察了以下几种灾备模式，同时根据本院实际的业务情况、工程师配置情况和医院后续发展的需求等综合进行总结和归纳。

2.1基于SAN网络的数据容灾

基于SAN网络的容灾当前最常用的方式是存储虚拟化与远程复制相结合的灾备架构，在前端应用服务器与后端存储系统之间的存储区域网络（SAN），加入一层存储网关，前端连接服务器主机，后端连接存储设备。它的角色就好像是存储网络中的跨海大桥，所有的数据和I/O都交由它来控制管理、分发。当然，现在的存储网关即可进行带内控制，也兼具out-bound控制方式，对于I/O流量进行旁路监控和分流，实现本异地数据复制。由于数据复制是通过存储网关来执行，应用服务器只需执行代理程序，相对于基于主机层的技术，它的性能影响更低。另外，通过存储网关的虚拟化技术，可整合前端异构平台的服务器和后端不同品牌的存储设备，本地端和灾备端的设备无须成对配置，用户可根据RTO和RPO，在远端建立完整的热备份中心。

测试缺点：灾备的数据如果要求是同步复制的，那么不同存储间的性能影响较大，会按照差的性能的存储运行，对ISCSI等网络存储整合较差。灾备的数据无法实时可查看，对灾备数据的完整性和安全性无法进行考究，只有在拉起的时候才能进行数据验证，操作较为复杂，同时，逻辑错误发生后，部分情况下恢复模式恢复的数据恢复丢失量较大，如单表误删等，均需要全盘恢复。另外，现场测试对维护人员的技术要求和运维规范性要求极高。

2.2基于主机的容灾技术

一般是通过复制主机逻辑卷的方式实现。灾备管理软件将主机端系统卷上每次I/O的操作数据发生变化的数据块实时（或者准实时、或者延时）复制到灾备节点的相应位置上，实现远程两个卷之间的数据同步（或准同步）。主、备节点之间通常需要配置相应的IP通道。根据数据的更新频度、带宽条件和质量等因素，可将数据复制设置成同步、准同步或者定期同步等方式（或自动适应）。另外，有一些基于主机的复制软件只能够实现文件级别的复制，虽然缺乏对裸设备卷的支持，但是融入了CDP的功能。远端灾备主机不但能够实现容灾切换，而且可支持将生产系统恢复到任意的历史事件点，相对的对大文件的复制效率较低。

基于主机的远程数据复制会增加各节点主机的一些处理性能需求，在主机性能和通信带宽的要求得到满足时，远程复制效率和数据一致性可得到保证。基于主机的远程数据复制一般与数据类型、物理存储系统设备无关，与操作系统结合紧密，有较好的可管理性，也便于主、备系统的扩充和发展；同时，也可方便地做到多对一或者一对多的远程复制；对存储硬件设备的选择也比较灵活。

测试缺点：当I/O或需要复制的文件变化量过大时，会在源端生成较大的缓存空间，部分软件无缓存空间限定的时候会直接写满空间，直接导致源端宕机。如重建数据库缩影，数据库日志收缩等环境下。无法断点续传或者断点续传条件苛刻，由于CDP等卷复制无法校验数据复制的具体情况，当主机端重启、网络中断、灾备端重启或Agent重启等情况下，无法进行数据的断点续传，要么需要进行全数据校验，要么需要进行重新全同步，对业务的影响较大。卷复制等技术同样存在着备机无法查询的情况，需要对备机数据和应用可用性进行校验时，必须要中断复制，而中断复制重启灾备系统后又需要进行全量同步，故而灾备的可用性较低，适合用于实时备份恢复。最大的缺点是绝大多数的CDP复制软件都无法支持Oracle RAC的同步复制，在Oracle环境中无法适用。

2.3基于数据库的数据容灾

大部分的数据库软件厂商提供了基于数据库复制事务日志的容灾技术，基于数据库的复制技术传输的是SQL指令或重作日志文件，在新数据没有被业务系统写入存储子系统前，就被指定发送到异地灾备中心的数据库进行相关交易处理。数据库复制技术采用的是异步传输方式，通过IP网络传输，支持一个生产系统向多个备份系统的数据库进行复制的要求，或多个生产系统向一个备份系统复制的要求。

这里由于本院的信息系统核心数据库为Oracle数据库，所以在这里以Oracle数据的复制技术为例，Oracle数据库层面的数据复制，业界大部分以Data Guard的机制做的，还有一部分是按照Streams模式做的。

2.4Data Guard模式的容灾过程

Data Guard主要提供两种服务，分别为Redo传输服务和Redo应用服务。传输服务即把Primay端的Redo日志传输到一个或多个Standby目的地；应用服务即在Standby端应用从Primay端传输过来的Redo日志。

Data Guard的日志传输模式有同步和异步等多种模式，异步模式采用的是使用ARCn传输Redo日志：Primay段ARC0一旦完成日志切换，ARC1就将新生成的归档日志传输到Standby端；Standby端由RFS进程接受日志，如果配置了Standby Redo Log，记录至Standby Redo Log，等Standby Redo Log做Log Switch形成归档日志，再应用归档日志做恢复；如果没有配置Standby Redo Log，RFS进程接收到日志后，放到Standby端归档目录下，Standby再应用归档日志做恢复。

同步或准同步模式采用LGWR传输Redo日志：一旦Primary有Redo日志产生，LGWR将触发LNSn进程传输Redo只Standby Redo Log；网络传输模式可选择Sync或Async，Sync是指当Primary提交时，必须得等Redo传输至Standby成功后，才能返回。Async是指Primary提交是否成功和日志是否传输成功没有关系，这样对Primary的性能影响最小；Standby端的RFS进程把Redo写入Standby Redo Log，如果开启了实时应用，就将Redo应用至Standby数据库，如果没有开启实时应用，等Standby Redo Log归档后再应用到Standby数据库。

从以上可看出在Data Guard容灾过程中，备份中心的数据库是否处于打开状态跟Redo日志的同步模式有关，笔者测试了2种类型的产品，各有优缺点，准实时同步的情况下均存在有几秒数据延迟情况，对逻辑错误的防护能力较低，测试时主机端逻辑错误导致数据库无法启动，灾备端数据库也无法启动。

2.5Streams模式的容灾过程

Streams灾备系统通过分析Oracle Redo Log获得实时交易信息，完成Schema或Table级别的数据复制。区别于早期的日志分析技术，Streams对日志的整合和传输以交易为单位，在拥有高性能的同时还能更好的保证数据传输的一致性和完整性。对生产数据库也不会增加负载。

Streams从Oracle Redo Logs里面获取所有的数据库改变信息。通过对信息的分析整合，Streams将完整的交易信息复制到目的端。

Streams不是等待Oracle Redo Log文件写满之后再处理，而是随时读取其数据块内容，间隔时间可用参数指定，一般是秒级。Streams也不会复制Oracle Redo Log的全部内容到目的端数据库，除指定复制对象（数据表）相关的DML/DDL操作之外，其他的信息将丢弃处理。

Streams的机制需要打开数据库的Supplemental Logging 和Force Logging参数以便Streams能获取完整的数据信息。

置于裸设备或文件系统中的Oracle Redo Log均可被Streams正常读取。如果将Redo Log保存在ASM（一种新的Oracle存储格式）中，则需要在裸设备或文件系统上手动创建一组与原有日志同步的Redo Log Member，供Streams复制使用。

Oracle有两种类型的日志：在线日志和归档日志。一般情况下，Streams从一组在线日志读取信息，因此，不要求Oracle数据库必须打开归档日志。但在某些特殊情况下，Online Redo Log没来得及分析就被覆盖，此时，如果Oracle是归档模式，则Streams将从归档日志读取需要的信息。

Streams支持两种级别的复制，用户（Schema）级复制和表级复制。用户级复制表示源端数据库指定用户（Schema）下的所有表、视图、索引、过程、函数、包、序列等数据对象全部复制到目标端数据库指定的用户下；表级复制表示源端数据库指定用户（Schema）下的单个表复制到目标端数据库指定用户下的单个表。

在使用Streams时，用户通过编辑配置文件指定源端和目的端复制对象的映射关系，包括源端对象名，目的端对象名，目的主机编号等。源端和目的端对象名称可不同，但结构必须一致。软件运行过程中，复制对象的映射参数会驻留内存，Streams通过日志分析过滤，只处理指定复制对象有关的交易，其他用户或表的操作信息则被丢弃。

因此，Streams数据库容灾技术属于热容灾方式，主备机均在线可用。Streams数据库容灾技术与存储子系统的类型、业务系统服务器的平台无关，与数据库的版本有一定关系，Streams数据库容灾解决方案有较好的灵活性。可实现跨操作系统平台数据复制、跨数据库平台数据复制，同时可提供上层BI数据分析使用。

由于复制的目的端数据库始终处于打开状态，因此，当生产数据库遇到计划内或非计划停机时，Streams的灾备端能够支持前端应用程序快速、无缝的切换到灾备数据库。与其他基于磁盘或文件系统的物理复制技术相比，不但省略了漫长的数据库Recovery和启动时间，而且能够保证100%的切换成功率。

测试缺点：缺少全系统备份模块，业务恢复需要手动搭建业务系统，搭建好后才能进行数据反向同步复制来恢复。

3　结 语

根据系统的测试，最后选择了基于Oracle Streams架构的灾备系统作为HIS数据安全的建设平台。当然，数据库容灾技术只能作为数据库应用的容灾解决方案，如果需要其他非结构数据的容灾，还需要其他容灾技术作为补充。如CDP复制、事务日志复制等灾备平台和普通备份平台多维解决方案于一体的综合应用安全架构体系，充分保障了数据和业务的分级灾备和存储，全方位保障了结构化数据和非结构化数据的安全。

10.3969/j.issn.1673 - 0194.2015.20.120

TP309.3

A

1673-0194（2015）20-0154-02

2015-08-27