服务热线
4001-021-758
作者： 来源： 阅读量： 发布时间：2020-01-03 15:29:46
医院信息业务持续解决方案
随着医院信息化的不断建设和完善，各种信息系统的全面使用，信息化已渗透到医院活动的各个方面，医院对于信息系统的依赖程度日益增强。
信息系统一旦中断或数据丢失，会对医院运营造成重大影响，这些直接的影响包括：
正常医疗秩序受阻，严重时耽误正常治疗和处置，造成医疗纠纷和事故。
数据错误或丢失，导致医疗纠纷以及重大经济损失。毁灭性的数据丢失将导致医院运营中断或无法运营。
较长时间的系统中断，将对医院公信力造成影响，严重时还会演变成社会事件，影响社会和谐。
但是，我们又不能完全防止信息系统内外部安全风险、系统本身的漏洞和故障、机房及其它运行环境安全，以及IT新旧技术、新老系统混杂、人员流动大、保障能力等因素，使得信息业务的持续不间断运行面临挑战。
从信息系统的运行维护和管理指标，目前面临的主要难题是：
业务中断（RTO指标）。
数据丢失（RPO指标）。
维护力量不足（连续运营能力）。
目前，XX医院核心医疗信息系统都已实现信息化。其中，核心业务主要包括HIS门诊系统数据库、HIS住院系统数据库、HIS电子病例系统数据库、检验系统等，其中HIS门诊系统数据库以双机集群方式部署在两台服务器上，其它系统均部署在单机服务器上。系统拓扑图1：
图1 核心信息系统拓扑图
目前HIS门诊系统数据库采用了集群方式。集群虽然实现了高可用，但是并不能完全避免故障，实现故障快速恢复。
集群技术避免了由于硬件个体单元故障造成的业务中断；但是共用同一版本数据，当逻辑错误发生时，无法保证数据库业务数据有效可用，从而也就没有在意外发生时，业务体系迅速恢复运营的基础保障。在这种情况下，集群技术就显示出巨大的不足，主要包括以下几个方面：
由于集群是“孪生”同构，当工作机出现上述问题崩溃时，备机极有可能被波及。由于仅有一个版本的操作系统及应用软件，该版本出现问题时，备机不能成功接管业务；
当业务数据出现逻辑错误导致工作机崩溃时，由于共享存储，且只拥有单一版本的数据库业务数据，备机所接管的数据库业务数据不可用，备机不能成功接管业务；
集群软件本身的不稳定导致切换应用失败。
利用集群进行快速恢复显然是不够的。
HIS住院系统数据库、HIS电子病例系统数据库、检验系统等应用服务器均为单机运行，无应急手段，一旦出现硬件故障或软件故障，系统将陷于瘫痪。
出现故障时，如果是硬件故障，首先要对硬件进行维修或者更换， 具体时间要取决于厂商的维修时间或者订货周期。
硬件修复或者更换之后还要进行系统恢复、应用软件安装、数据恢复，这将花费几个小时至几天的时间，其中应用软件的安装往往还需要开发厂家的现场支持，恢复过程中数据的丢失也不可避免。
如使用冷备机技术进行应急，需专业人员现场实施，并对数据一致性进行人工处理，业务恢复时间及数据恢复程度将不受控。
服务器虽然对磁盘做了Raid，为系统提供了相对安全、可靠的运行和存储环境，但也成了系统的单一故障节点。虽然Raid本身有一定的安全策略，但是极端情况下发生故障（控制器、RAID卡故障或其它软硬故障），医院的业务将全部中断，数据将可能永久丢失。
操作、应用与数据无多历史版本，服务器在某些情况下，如应用软件、操作系统、数据发生错误的情况下，信息系统没有可以用于回滚可用版本，如果全部重装，将耗时耗力且产生巨大的数据丢失。
目前采用手工、定时自动备份方式，工作量大，数据不能验证，数据安全不能保证。
目前，采用数据库自身机制对日志文件做定时自动或手动备份，无其它本地快速恢复手段，一旦出现硬件故障或软件故障时：
备份的数据无法验证。备份数据是否可用需经验证才能确定，传统验证方法需将备份的数据回写到原应用环境下进行测试，这意味着要中断现有系统运行；
数据需要从备份服务器中回写至应用服务器，本地再还原，因此一旦发生医院业务系统中断情况，业务恢复时间较长；
恢复过程复杂不可控。安装业务系统往往比较复杂，而且很多时候需要业务系统的开发方或集成商进行安装，这将导致数据的恢复过程复杂而且不可控。
2.2.3.1 预检维护制度落实难度大
系统持续运行的要求比较高，基本无主动停机进行维护维修的机会，预检维护制度无法落实。即便有数据备份的措施，但也无法确认备份的数据是否有效，因为如需验证，就必须将数据倒回原系统运行，原系统就需停顿。
2.2.3.2 专业要求高、人员流动大
新旧技术、新老系统混杂，未来IT新技术层出不穷，值勤人员和维护人员需要具备较高的专业背景和业务能力，这给经常性的运行维护带来较大的难度。
2.2.3.3 应急演练、快速恢复手段少
单机单系统设计，在不中断业务情况下，无法组织组织经常性的应急演练，平常也很难进行实际操作的训练，无法保证维护人员在灾难情况下的处置水平。
目前的系统维护都是面向维护工程师专业设计，一线值勤维护人员缺少简单有效的快速恢复业务的技术手段。在灾难发生时，一线值班人员实际上基本做不到现场快速恢复，需等待相关维护人员、厂商服务商到场，业务中断时间、数据丢失的风险不可控。
按照“高可用、容灾、持续运营”的全面业务持续管理思想，保持现有网络架构、容灾设计不变，增加一套统一容灾系统做全方面容灾部署。 提升统一容灾、持续运营能力，实现“业务不中断、数据不丢失、简单可控”的运维目标，达到运行维护管理的“可控、简单”。
保持现有的系统构架基本框架不变，部署统一容灾系统；
HIS门诊系统数据库、HIS住院系统数据库数据丢失约等于0；
数据库双活、数据恢复点目标RPO约等于0。
HIS电子病例系统数据库、检验系统等应用服务器数据丢失小于1小时；
数据恢复点目标RPO小于1小时。
业务快速恢复时间约为五分钟；
业务中断时，由“统一容灾系统”直接接管故障系统工作。实际业务恢复时间等于原系统重启时间，一般在五分钟以内。
极简操作，随时演练；
采用“应急、统一、简单”设计，在统一平台上完成全方位数据、系统的备份、实时保护，向现场维护人员提供极简应急的“单键”抢通体验，并可随时提供应急演练和业务训练。
建立基础平台，容灾系统功能可扩展。
在保持现在基础平台的基础上，未来根据经费和管理目标要求，方便地通过增加授权和功能模块，来扩展对其他业务系统的保护或提升维护指标。
根据XX医院的实际情况与切实需求，HIS门诊系统数据库、HIS住院系统数据库、HIS电子病例系统数据库、检验系统等作为本医院核心业务，具有访问量大，系统硬件性能要求高，系统实时性要求高，数据完整性要求高的特点。因此，在医院信息中心部署一套UNIDR（统一容灾系统）对信息中心的所有业务系统进行保护。
根据信息系统的IT基础架构现状，根据网络的情况、服务器的情况及应用保护的需要，应急容灾拓扑结构如图2：
统一容灾系统（UNIDR）的作用首先是给被保护的服务器增加一个逻辑存储空间，并通过网络映射给被保护服务器，服务器的操作系统、应用环境、相关数据自动备份到逻辑存储空间中。
当服务器发生任何软硬件故障时，服务器转换为虚拟机启动应急模式，UNIDR将按照事先设置的策略将备份在逻辑存储空间中的操作系统、应用环境、相关数据映射到统一容灾系统内置虚拟平台上，通过虚拟机接替故障服务器，快速恢复业务运行。
数据库双活。针对HIS门诊、住院系统数据库采用启智数据库同步进行保护，实现数据库的实时数据捕获、数据分析合成、数据存储、数据应用、系统管理等整个系统架构。当业务系统发生故障时，通过简单的IP地址切换，即可立即恢复数据库业务。
HIS电子病例系统、检验系统等应用服务器，统一容灾系统对被保护服务器的数据变化，进行定时快照，实现快速恢复和多版本保存。
通过制定不同、合理的复制策略，实现集中、无人值守、自动化的数据在线复制。在灾难发生时，对系统和数据进行应急接替，及时恢复业务运行，使损失减至最小。
在系统第一次复制时，通过初始复制模式对整个系统盘进行复制，在以后运行中可按需要进行计划性的增量复制，可设置具体复制策略：
服务器名称 | 复制策略 | 实现指标 |
HIS电子病例系统数据库服务器、检验系统等应用服务器 | 定时R ｜ 根据需要可设定天级别或更小级别的在线定时复制 | RTO<5分钟，RPO<60分钟 |
HIS门诊、住院系统数据库服务器 | 实时R ｜ 实时在线同步 | RTO<5分钟，RPO≈0 |
应用服务器快速恢复。当业务系统出现故障，容灾系统能快速接管业务系统的运行，并重新提供业务服务， 业务中断时间RTO小于5分钟，实际业务恢复时间等于原系统重启时间；
HIS系统数据库的实时保护。数据完整性指标RPO≈0，业务恢复及时性指标RTO小于5分钟；
数据查询分离：为HIS门诊、住院系统核心数据库系统复制出多1个服务子系统，提供面向其他单位的数据查询和检索功能，隔离核心数据库和外界的联系，降低核心系统的资源消耗。
HIS电子病例系统数据库服务器、检验系统等应用服务器。采用64快照技术，对数据库服务器上的数据变化，形成连续时间点快照。当灾难发生时，可以选择任意时间点的快照形成副本，保证业务数据丢失小于1小时；
极简操作模式，一线值班人员可以简单完成业务容灾；
采用虚拟机、网络启动应急方式，适应各种软硬件故障导致的业务系统应急。
在线复制与在线还原，不影响系统的正常运行；
复制的系统、应用和数据独立于生产系统之外；
自动生成多版本快照，确保可用、可靠；
完全国产自主可控技术，独立于第三方的运维工具；
不影响生产系统的正常工作，方便进行经常性应急演练；
具有充分的可扩充的网络容灾应急设计，最大程度保护前期投资。
当发生中断时，使用容灾系统直接接替故障系统工作，不需要长时间的硬盘数据回写，几分钟即可恢复业务运行。确保业务系统同时具备高可用和快速的灾难恢复能力，使业务的连续性得以保障。
对核心数据库实现数据库数据实时同步，实现核心数据库系统的实时数据捕获、迁移，当发生故障时，可立即恢复数据库业务。
为核心数据库系统复制出多1个服务子系统，提供面向其他单位的数据查询和检索功能，隔离核心数据库和外界的联系，降低核心系统的资源消耗。
一线值班人员可以软件一键切换方式完成业务容灾；
容灾系统不仅仅复制业务系统的数据，而且复制包括业务服务器操作系统以及业务运行的完整软件环境，包括：
操作系统；
数据库系统；
中间件系统；
各种应用系统等。
备份的数据和运行环境是否可恢复，是灾备系统有效性的重点，灾难恢复演练作为业务连续性管理的一个重要环节，通常具有操作复杂、资源占用较大的问题，成功进行一次演练的难度很高。
使用容灾系统，可以大大降低演练的技术难度，只需要部署一个简单的演练环境，就可以使用容灾系统中虚拟机应急的功能，极短的时间就可以将所有的业务系统运行起来，从而实现检验容灾备份的可用性、灾难恢复应急预案的可执行性等演练目的，从而使业务系统在发生灾难后进行恢复得以保障。
容灾系统采用软、硬件一体化设计，可方便地进行“交钥匙”方式业务功能交付，部署、管理便利。
容灾系统采用模块化设计，可根据需要灵活选择相应的功能模块，同时，当应用环境变化时，可以方便地进行升级扩展：包括存储容量的扩展、应急方式的扩展、保护服务器数量的扩容等，可有效地保护用户的初期投资。
容灾系统的操作管理采用全中文的WebUI，不需要安装任何管理软件，任何具有网络互通能力的终端都可以方便地通过浏览器登陆容灾系统管理程序，进行操作和管理。
在统一容灾系统部署完成后，将为每台生产服务器分配一组容灾存储，配合安装在生产服务器上的客户端软件，根据预先设定的策略，自动对各服务器的操作系统、应用软件、数据及数据库实施动态差异量在线复制，复制后在统一容灾系统系统上生成用于应急、容灾的快照，供应急、容灾、恢复时选用。
DSS是一种基于Oracle 在线日志（Redolog）分析技术的结构化数据实施复制备份软件产品，备份数据库始终处于OPEN状态。DSS通过在源端（生产）数据库服务器和目标端（备份端）数据库服务器各自配置一个代理程Sourage Agent 和Target Agent，DSS Agent程序是绿色免安装的程序，直接解压配置启动参数就可以进行数据实时同步。
DSS利用数据库日志在线跟踪、分析技术，将生产数据库的交易信息以事务为单位，通过异步的方式，实时的传递、装载到目标数据库中，以达到源端、目标端复制数据保持同步的目的。
生产服务器故障时，使用统一容灾系统管理器中提供的虚拟机应急功能，统一容灾系统会将容灾副本以自身集成的虚拟化平台启动，启动时不需要进行任何P2V的操作，可以正常启动该容灾副本上的操作系统及其上的所有应用和服务，启动完成后，业务系统恢复正常功能。
总之，一旦服务器发生任意故障，通过多种应急手段（网络启动、FC启动、虚拟机启动）使用简单的操作，即可在分钟级内恢复故障服务器业务，实现RTO≦5分钟。
当实施网络启动操作系统、应用软件并恢复业务功能后，可在系统I/O比较少的时间（如深夜），使用统一容灾系统的恢复功能，自动或手动对各服务器原有的磁盘进行恢复操作；将存放在网络存储里的可用的操作系统、应用软件、数据及数据库恢复（回写）到本地盘，该操作支持对数十台服务器的自动恢复，非常便于运营管理。
当完成对本地盘的全部系统和数据的恢复后，根据需要只需重启系统，并选择本地启动即可将运营切换到本地盘上。
RTO≦5分钟；
RPO ≈ 0或RPO ≦1小时。
内置一体化虚拟机平台；
支持软、硬件一键虚拟机快速应急启动。
虚拟机P2V动态迁移
每个快照均可支持虚拟机直接启动应急。
跨网段应急启动
支持多网段跨网段应急网络启动。
数据保护
支持实时复制， RPO≈0；
支持定时复制， RPO ≦1小时；
提供任快照点回滚的数据保护和恢复功能。
应急方式
支持软、硬一键切换模式。
恢复还原方式
采用PXE协议的网络启动应急模式在线恢复还原；
支持手动还原。
快照版本
提供64快照版本，可扩展到2048快照版本。
保护范围
操作系统、应用程序、数据库、数据文件、服务器硬件等。
复制方式
在线复制，支持增量复制、全量复制
支持的操作系统
Microsoft Windows 2000/2003/2008 Server；
Microsoft Windows XP；
Linux；
国产操作系统：麒麟、红旗。
Microsoft SQL Server；
Oracle；
MySQL；
Sybase；
DB2；
国产数据库：GBase。
统一容灾系统的存储容量：
集成存储：16TB；
扩展存储：支持FC SAN、iSCSI SAN、DAS等方式的存储容量扩展，扩展容量无上限。
业务持续管理功能
内置BCM管理模块
操作界面
支持中文操作界面，支持Web管理方式。
自身安全
系统自身采用自主专用操作平台。
