XX医院信息系统业务持续保障解决方案上海XX 人民医院社区卫生服务中心信息系统业务持续保障解决方案2016年6月签署页 XX医院信息系统业务持续保障解决方案 版本1.0拟制: 2016年4月5日审核: 2016年4月5日标批: 2016年4月5日审批: 2016年4月5日 更改历史页序号版本号日期更 改 条 款作者（更改者）1V1.02016.4.5梁浩1 前言12 需求分析12.1 核心医疗信息系统现状12.2 业务持续风险分析22.2.1 业务中断风险（软件硬件问题）22.2.2 数据丢失风险32.2.3 维护难度大，维护力量不足43 解决方案53.1 设计思路53.2 业务持续保障63.2.1 系统拓扑63.2.2 方案概述73.2.3 复制策略83.2.4 实现效果83.2.5 方案特点94 统一容灾系统工作原理114.1在线复制114.2启智数据库同步（DSS）124.3应急启动134.4事后恢复145 方案主要技术指标146 配置及报价17 XX医院信息系统业务持续保障解决方案XX医院信息业务持续解决方案1 前言随着医院信息化的不断建设和完善，各种信息系统的全面使用，信息化已渗透到医院活动的各个方面，医院对于信息系统的依赖程度日益增强。信息系统一旦中断或数据丢失，会对医院运营造成重大影响，这些直接的影响包括：1) 正常医疗秩序受阻，严重时耽误正常治疗和处置，造成医疗纠纷和事故。2) 数据错误或丢失，导致医疗纠纷以及重大经济损失。毁灭性的数据丢失将导致医院运营中断或无法运营。3) 较长时间的系统中断，将对医院公信力造成影响，严重时还会演变成社会事件，影响社会和谐。但是，我们又不能完全防止信息系统内外部安全风险、系统本身的漏洞和故障、机房及其它运行环境安全，以及IT新旧技术、新老系统混杂、人员流动大、保障能力等因素，使得信息业务的持续不间断运行面临挑战。从信息系统的运行维护和管理指标，目前面临的主要难题是：1) 业务中断（RTO指标）。2) 数据丢失（RPO指标）。3) 维护力量不足（连续运营能力）。2 需求分析2.1 核心医疗信息系统现状 目前，XX医院核心医疗信息系统都已实现信息化。其中，核心业务主要包括HIS门诊系统数据库、HIS住院系统数据库、HIS电子病例系统数据库、检验系统等，其中HIS门诊系统数据库以双机集群方式部署在两台服务器上，其它系统均部署在单机服务器上。系统拓扑图1：图1 核心信息系统拓扑图2.2 业务持续风险分析2.2.1 业务中断风险（软件硬件问题）目前HIS门诊系统数据库采用了集群方式。集群虽然实现了高可用，但是并不能完全避免故障，实现故障快速恢复。集群技术避免了由于硬件个体单元故障造成的业务中断；但是共用同一版本数据，当逻辑错误发生时，无法保证数据库业务数据有效可用，从而也就没有在意外发生时，业务体系迅速恢复运营的基础保障。在这种情况下，集群技术就显示出巨大的不足，主要包括以下几个方面： 由于集群是“孪生”同构，当工作机出现上述问题崩溃时，备机极有可能被波及。由于仅有一个版本的操作系统及应用软件，该版本出现问题时，备机不能成功接管业务； 当业务数据出现逻辑错误导致工作机崩溃时，由于共享存储，且只拥有单一版本的数据库业务数据，备机所接管的数据库业务数据不可用，备机不能成功接管业务； 集群软件本身的不稳定导致切换应用失败。利用集群进行快速恢复显然是不够的。HIS住院系统数据库、HIS电子病例系统数据库、检验系统等应用服务器均为单机运行，无应急手段，一旦出现硬件故障或软件故障，系统将陷于瘫痪。1) 出现故障时，如果是硬件故障，首先要对硬件进行维修或者更换， 具体时间要取决于厂商的维修时间或者订货周期。2) 硬件修复或者更换之后还要进行系统恢复、应用软件安装、数据恢复，这将花费几个小时至几天的时间，其中应用软件的安装往往还需要开发厂家的现场支持，恢复过程中数据的丢失也不可避免。3) 如使用冷备机技术进行应急，需专业人员现场实施，并对数据一致性进行人工处理，业务恢复时间及数据恢复程度将不受控。2.2.2 数据丢失风险2.2.2.1 本地存储数据存在安全隐患1) 服务器虽然对磁盘做了Raid，为系统提供了相对安全、可靠的运行和存储环境，但也成了系统的单一故障节点。虽然Raid本身有一定的安全策略，但是极端情况下发生故障（控制器、RAID卡故障或其它软硬故障），医院的业务将全部中断，数据将可能永久丢失。2) 操作、应用与数据无多历史版本，服务器在某些情况下，如应用软件、操作系统、数据发生错误的情况下，信息系统没有可以用于回滚可用版本，如果全部重装，将耗时耗力且产生巨大的数据丢失。2.2.2.2 无实时数据保护技术目前采用手工、定时自动备份方式，工作量大，数据不能验证，数据安全不能保证。2.2.2.3 数据库自身机制不能快速恢复数据目前，采用数据库自身机制对日志文件做定时自动或手动备份，无其它本地快速恢复手段，一旦出现硬件故障或软件故障时：1) 备份的数据无法验证。备份数据是否可用需经验证才能确定，传统验证方法需将备份的数据回写到原应用环境下进行测试，这意味着要中断现有系统运行；2) 数据需要从备份服务器中回写至应用服务器，本地再还原，因此一旦发生医院业务系统中断情况，业务恢复时间较长；3) 恢复过程复杂不可控。安装业务系统往往比较复杂，而且很多时候需要业务系统的开发方或集成商进行安装，这将导致数据的恢复过程复杂而且不可控。2.2.3 维护难度大，维护力量不足2.2.3.1 预检维护制度落实难度大系统持续运行的要求比较高，基本无主动停机进行维护维修的机会，预检维护制度无法落实。即便有数据备份的措施，但也无法确认备份的数据是否有效，因为如需验证，就必须将数据倒回原系统运行，原系统就需停顿。2.2.3.2 专业要求高、人员流动大新旧技术、新老系统混杂，未来IT新技术层出不穷，值勤人员和维护人员需要具备较高的专业背景和业务能力，这给经常性的运行维护带来较大的难度。2.2.3.3 应急演练、快速恢复手段少单机单系统设计，在不中断业务情况下，无法组织组织经常性的应急演练，平常也很难进行实际操作的训练，无法保证维护人员在灾难情况下的处置水平。目前的系统维护都是面向维护工程师专业设计，一线值勤维护人员缺少简单有效的快速恢复业务的技术手段。在灾难发生时，一线值班人员实际上基本做不到现场快速恢复，需等待相关维护人员、厂商服务商到场，业务中断时间、数据丢失的风险不可控。3 解决方案3.1 设计思路按照“高可用、容灾、持续运营”的全面业务持续管理思想，保持现有网络架构、容灾设计不变，增加一套统一容灾系统做全方面容灾部署。 提升统一容灾、持续运营能力，实现“业务不中断、数据不丢失、简单可控”的运维目标，达到运行维护管理的“可控、简单”。 保持现有的系统构架基本框架不变，部署统一容灾系统； HIS门诊系统数据库、HIS住院系统数据库数据丢失约等于0；数据库双活、数据恢复点目标RPO约等于0。 HIS电子病例系统数据库、检验系统等应用服务器数据丢失小于1小时；数据恢复点目标RPO小于1小时。 业务快速恢复时间约为五分钟；业务中断时，由“统一容灾系统”直接接管故障系统工作。实际业务恢复时间等于原系统重启时间，一般在五分钟以内。 极简操作，随时演练；采用“应急、统一、简单”设计，在统一平台上完成全方位数据、系统的备份、实时保护，向现场维护人员提供极简应急的“单键”抢通体验，并可随时提供应急演练和业务训练。 建立基础平台，容灾系统功能可扩展。在保持现在基础平台的基础上，未来根据经费和管理目标要求，方便地通过增加授权和功能模块，来扩展对其他业务系统的保护或提升维护指标。3.2 业务持续保障3.2.1 系统拓扑根据XX医院的实际情况与切实需求，HIS门诊系统数据库、HIS住院系统数据库、HIS电子病例系统数据库、检验系统等作为本医院核心业务，具有访问量大，系统硬件性能要求高，系统实时性要求高，数据完整性要求高的特点。因此，在医院信息中心部署一套UNIDR（统一容灾系统）对信息中心的所有业务系统进行保护。根据信息系统的IT基础架构现状，根据网络的情况、服务器的情况及应用保护的需要，应急容灾拓扑结构如图2：图2 应急容灾拓扑图3.2.2 方案概述统一容灾系统（UNIDR）的作用首先是给被保护的服务器增加一个逻辑存储空间，并通过网络映射给被保护服务器，服务器的操作系统、应用环境、相关数据自动备份到逻辑存储空间中。当服务器发生任何软硬件故障时，服务器转换为虚拟机启动应急模式，UNIDR将按照事先设置的策略将备份在逻辑存储空间中的操作系统、应用环境、相关数据映射到统一容灾系统内置虚拟平台上，通过虚拟机接替故障服务器，快速恢复业务运行。数据库双活。针对HIS门诊、住院系统数据库采用启智数据库同步进行保护，实现数据库的实时数据捕获、数据分析合成、数据存储、数据应用、系统管理等整个系统架构。当业务系统发生故障时，通过简单的IP地址切换，即可立即恢复数据库业务。HIS电子病例系统、检验系统等应用服务器，统一容灾系统对被保护服务器的数据变化，进行定时快照，实现快速恢复和多版本保存。3.2.3 复制策略通过制定不同、合理的复制策略，实现集中、无人值守、自动化的数据在线复制。在灾难发生时，对系统和数据进行应急接替，及时恢复业务运行，使损失减至最小。在系统第一次复制时，通过初始复制模式对整个系统盘进行复制，在以后运行中可按需要进行计划性的增量复制，可设置具体复制策略：服务器名称复制策略实现指标HIS电子病例系统数据库服务器、检验系统等应用服务器定时R 根据需要可设定天级别或更小级别的在线定时复制RTO5分钟，RPO60分钟HIS门诊、住院系统数据库服务器实时R 实时在线同步RTO5分钟，RPO03.2.4 实现效果 应用服务器快速恢复。当业务系统出现故障，容灾系统能快速接管业务系统的运行，并重新提供业务服务， 业务中断时间RTO小于5分钟，实际业务恢复时间等于原系统重启时间； HIS系统数据库的实时保护。数据完整性指标RPO0，业务恢复及时性指标RTO小于5分钟； 数据查询分离：为HIS门诊、住院系统核心数据库系统复制