本科毕业设计论文--人民医院社区卫生服务中心信息系统业务持续保障解决方案.docVIP

人民医院社区卫生服务中心 信息系统业务持续保障解决方案  1 前言 1 2 需求分析 1 2.1 核心医疗信息系统现状 1 2.2 业务持续风险分析 2 2.2.1 业务中断风险（软件硬件问题） 2 2.2.2 数据丢失风险 3 2.2.3 维护难度大，维护力量不足 4 3 解决方案 5 3.1 设计思路 5 3.2 业务持续保障 6 3.2.1 系统拓扑 6 3.2.2 方案概述 7 3.2.3 复制策略 8 3.2.4 实现效果 8 3.2.5 方案特点 9 4 统一容灾系统工作原理 11 4.1在线复制 11 4.2启智数据库同步（DSS） 12 4.3应急启动 13 4.4事后恢复 14 5 方案主要技术指标 14 6 配置及报价 17  医院信息业务持续解决方案 1 前言 随着医院信息化的不断建设和完善，各种信息系统的全面使用，信息化已渗透到医院活动的各个方面，医院对于信息系统的依赖程度日益增强。 信息系统一旦中断或数据丢失，会对医院运营造成重大影响，这些直接的影响包括： 正常医疗秩序受阻，严重时耽误正常治疗和处置，造成医疗纠纷和事故。 数据错误或丢失，导致医疗纠纷以及重大经济损失。毁灭性的数据丢失将导致医院运营中断或无法运营。 较长时间的系统中断，将对医院公信力造成影响，严重时还会演变成社会事件，影响社会和谐。 但是，我们又不能完全防止信息系统内外部安全风险、系统本身的漏洞和故障、机房及其它运行环境安全，以及IT新旧技术、新老系统混杂、人员流动大、保障能力等因素，使得信息业务的持续不间断运行面临挑战。 从信息系统的运行维护和管理指标，目前面临的主要难题是： 业务中断（RTO指标）。 数据丢失（RPO指标）。 维护力量不足（连续运营能力）。 2 需求分析 2.1 核心医疗信息系统现状 目前，XX医院核心医疗信息系统都已实现信息化。其中，核心业务主要包括HIS门诊系统数据库、HIS住院系统数据库、HIS电子病例系统数据库、检验系统等，其中HIS门诊系统数据库以双机集群方式部署在两台服务器上，其它系统均部署在单机服务器上。系统拓扑图1： 图1 核心信息系统拓扑图 2.2 业务持续风险分析 2.2.1 业务中断风险（软件硬件问题） 目前HIS门诊系统数据库采用了集群方式。集群虽然实现了高可用，但是并不能完全避免故障，实现故障快速恢复。 集群技术避免了由于硬件个体单元故障造成的业务中断；但是共用同一版本数据，当逻辑错误发生时，无法保证数据库业务数据有效可用，从而也就没有在意外发生时，业务体系迅速恢复运营的基础保障。在这种情况下，集群技术就显示出巨大的不足，主要包括以下几个方面： 由于集群是“孪生”同构，当工作机出现上述问题崩溃时，备机极有可能被波及。由于仅有一个版本的操作系统及应用软件，该版本出现问题时，备机不能成功接管业务； 当业务数据出现逻辑错误导致工作机崩溃时，由于共享存储，且只拥有单一版本的数据库业务数据，备机所接管的数据库业务数据不可用，备机不能成功接管业务； 集群软件本身的不稳定导致切换应用失败。 利用集群进行快速恢复显然是不够的。 HIS住院系统数据库、HIS电子病例系统数据库、检验系统等应用服务器均为单机运行，无应急手段，一旦出现硬件故障或软件故障，系统将陷于瘫痪。 出现故障时，如果是硬件故障，首先要对硬件进行维修或者更换， 具体时间要取决于厂商的维修时间或者订货周期。 硬件修复或者更换之后还要进行系统恢复、应用软件安装、数据恢复，这将花费几个小时至几天的时间，其中应用软件的安装往往还需要开发厂家的现场支持，恢复过程中数据的丢失也不可避免。 如使用冷备机技术进行应急，需专业人员现场实施，并对数据一致性进行人工处理，业务恢复时间及数据恢复程度将不受控。 2.2.2 数据丢失风险 2.2.2.1 本地存储数据存在安全隐患 服务器虽然对磁盘做了Raid，为系统提供了相对安全、可靠的运行和存储环境，但也成了系统的单一故障节点。虽然Raid本身有一定的安全策略，但是极端情况下发生故障（控制器、RAID卡故障或其它软硬故障），医院的业务将全部中断，数据将可能永久丢失。 操作、应用与数据无多历史版本，服务器在某些情况下，如应用软件、