三甲医院HIS系统升级改造难点分析探讨

字数 6454阅读 7930评论 4赞 17

医院管理信息系统 (Hospital Information System,HIS) 有广义和狭义之分。广义的医院 HIS 是医院管理和医疗活动中进行信息管理和联机操作的计算机应用系统的统称；狭义的医院 HIS 单指医院门诊及住院信息管理业务系统。而本文所述 HIS 系统通指其狭义概念。

医院 HIS 作为医院最重要的信息系统，其稳定、可靠、高效运行以支持医院业务发展需要是医疗信息化研究的重要方向。随着信息技术日新月异的发展及医院业务需求的不断扩展，如何采用新技术和新架构促成医院 HIS 系统的软硬件升级与改造已然成为国内众多医院亟待解决的重要课题。

本文根据某三甲医院 HIS 系统升级改造的案例，详细进行阐述分析，以期提供相应的经验分享。

一、背景介绍

该院 HIS 系统采用的是 C/S 架构，数据库服务器为两台 2010 年采购的 P570 服务器，所用存储为 IBM DS4800 。服务器上所采用的操作系统平台为 AIX 5.3 ，数据库为 Oracle 9i ，版本为 9.2.0.8 。服务器采用 AIX 的双机集群 HACMP 以及 Oracle RAC ，将两台服务器做成了一个群集，底层 DS4800 存储通过 RemoteMirror+FlashCopy 实现两个机房间的两台存储之间的远程物理层面的容灾。容灾环境由一台 P550 服务器接管，该服务器通过 Oracle Data Gurad 方式实现 Oracle 数据库的逻辑容灾， HIS 架构如图 1 所示。

图 1 HIS 架构

二、存在问题及升级改造的需求分析

1 、架构需优化

HIS 系统作为最重要的业务系统，系统的建设目标是追求 RTO 和 RPO 均等于 0 。由上述架构可知，由于当时的技术限制，虽然架构上考虑到物理层及数据逻辑层的容灾，但是无法实现 RTO 和 RPO 均等于 0 。物理层面上，两台 DS4800 之间通过 RemoteMirror+FlashCopy 实现同步容灾，可实现 RPO 等于 0 ，但是因为容灾存储及服务器的启用仍需要进行相应的切换操作才可使容灾环境支持业务系统，理论 RTO 时间为 5-10 分钟；而逻辑层面上，因为 Oracle Data Guard 的配置因素，生产及容灾环境之间的数据一致性依赖于生产数据库的在线及离线日志是否正常传输至容灾服务器，而突发的意外宕机极有可能损失一部分日志文件，并且容灾环境的启用也需要比较复杂及专业的环境切换操作，故 RPO 及 RTO 均不可能等于 0 。

除此之外，容灾体系也不够全面完善。虽然 Oracle 9i 的 Data Gurad 可支持对 Oracle 数据逻辑层的回退操作，但是其前提是相应的离线日志尚未被 recover 恢复。如果已执行 recover 恢复，则无法实现相应的回退目标，致使无法实现业务的回退容灾，存在相当的风险隐患，需要引入诸如全量备份、增量备份及持续数据保护 CDP 等方式加强数据的逻辑层保护。

2 、性能需优化

主机性能方面，通过 AIX nmon 工具对医院 HIS 的两台服务器进行监控分析发现，单台服务器 Power6 CPU 的总核数为 16 核，平均使用率在 80% 以上，高峰达到 90% ， 64G 内存使用也在 90% 左右。如果两台服务器中的其中一台出故障，另外一台在如此压力之下无法胜任支撑业务系统的要求，相对配置更低的容灾服务器 P550 更加无法满足业务系统容灾的需要。网络吞吐方面，数据库的两个实例间的心跳网络为千兆网络， HIS 高峰业务期心跳网络的吞吐量长期维持在 80-100M/S ，已经达到了千兆网络的瓶颈速度。磁盘 IO 方面， DS4800 的存储配备的是 10k 的 SAS 盘，总共 32 块盘，每 8 块做 raid5 形成一个 raid 组，每个 raid 组分配一个 lun 给服务器提供存储，通过存储监控工具及主机 nmon 的分析可知，存储的总体 IO 也在 80% 以上，存在瓶颈需要优化。

3 、数据库需优化

当前 HIS 的数据库版本为 Oracle 9208 ，属于 Oracle 较旧的软件版本，其数据库访问速度、支持的访问需求、容错和安全、性能监控及数据库管理方面均无法胜任医院日益增长的业务需求。而且该版本官方早已停止发布更新，数据库层面存在漏洞无法更新、 bug 问题无法得到支持的窘境。

4 、管理与功能需优化

随着医院业务的不断扩展， HIS 系统也要频繁进行更新与升级，这就要求有近似生产环境的测试环境进行功能及性能方面的全面测试，以保障更新与升级的顺利进行。医院现有架构无法实现近似生产环境的快速部署。除此之外，因为 HIS 容灾环境的机械性，导致 HIS 系统的一些大数据量的查询及分析的需求只能压在生产环境，从而导致生产环境压力过大，不利于日常业务的稳定与高效运行。

三、医院 HIS 系统升级改造平台的架构设计

基于上述 HIS 系统架构存在问题、痛点及迫切改进的需求，采用现有主流先进的软硬件产品和技术，对医院现有 HIS 系统进行升级改造，升级改造的整体架构设计如图 2 所示。

存储层面上，采用现今主主流的存储双活技术，在医院生产及容灾的两个机房，分别放置一套 EMC VPLEX 双活网关及 EMC VMAX 250F 全闪存储，形成双活集群。存储配置高速 SSD 磁盘，为业务提供高 IOPS 。每个机房放置一套 EMC RecoverPoint 并使用原来生产存储 IBM DS4800 作为其存储空间，提供实时的数据保障，可提供任意时间点的、 IO 级、秒级的恢复保障，弥补了原来容灾架构的不足，可应对物理部件故障及逻辑故障等多重风险。

主机层面上，采用两台浪潮商用机器有限公司的 K1 Power E870 小型机作为生产主机，并配备多张万兆网卡，通过心跳万兆交换机互联形成集群，突破原来集群心跳带宽的瓶颈限制。单台 K1 Power E870 的主要配置为： 64-core 4.02GHz Power8 CPU/512GB DDR4 内存 /4 块 775GB SSD 磁盘，整体服务器性能是原有配置的 4 倍多，主机配置的 4 个 SSD 磁盘为主机 AIX 操作系统提供高 IO 的存储空间，防止了设备的短板。

数据库层面上，将原来的 Oracle 9i 升级成为 Oracle 11g ，并重做数据库 Data Guard 。采用 11g 的 ADG 功能，把 DG 数据库置为只读数据库，并修改 HIS 应用指向，分担业务数据库的压力。业务数据库原来采用裸设备的方式存放数据文件，升级成 11g 改成自动存储管理 ASM 功能，可以大幅减少维护的工作量，并减少误操作的风险。 11g 的其它优点包括：

① 支持自动坏块检测和修复，可以通过 DG 可以自动修复生产数据库的坏块；

② 提供数据库回收站和闪回功能，具有一定的预防逻辑错误能力；

③ 提供数据库 AWR 性能监控，相比 9i 的 Statspack 能更详细更直观找到数据库潜在瓶颈和 TOP SQL ；

④ 提供自动内存管理 AMM 功能，能自适应管理内存，简化数据库管理。

容灾层面上，上述双活存储及双机集群均为物理层面上的容灾冗余，可有效应对存储、主机及操作系统等物理层面上的宕机或故障风险。数据库逻辑层面上，通过原来生产的两台 P570 作为容灾主机，容灾机房的 IBM DS4800 作为容灾存储，构建 Oracle 11g 的 Data Gurad ，以应对数据库逻辑故障风险。除此之外，通过 EMC RecoverPoint ，对 HIS 数据进行持续保护，设置备份策略，为系统提供历时数据的备份、实时的数据保护及任意时间点的、 IO 级、秒级的恢复保障，可应对物理部件故障及逻辑故障等多重风险，极大完善现有 HIS 容灾架构。新架构 RTO/RPO 接近于 0 。

图 2 医院 HIS 系统升级改造平台架构设计

四、医院 HIS 系统升级改造硬件 + 软件难点分析

医院 HIS 系统升级改造的目标是结合医院的 HIS 系统实际需求，通过迄今为止最优化的软硬件技术及方案，为系统提供更稳定的架构和更高效的性能，为运维管理人员提供更便捷的管理和更全面的系统功能，为用户提供更流畅的系统体验。医院 HIS 系统升级改造涉及存储、主机、操作系统、数据库、网络、上层应用及容灾架构等方方面面，任何一方面考虑不周或存在瓶颈，会使得整体的系统升级改造存在短板瓶颈，甚者导致升级改造项目的功亏一篑。如何做好升级改造，兼顾升级改造的方方面面内容，最重要的是要做好全面、客观并有效的系统分析，解决攻克升级改造过程中遇到的硬件 + 软件的难关。下面，结合医院的 HIS 系统升级改造的设计实践，对医院 HIS 系统升级改造硬件 + 软件的难点进行详细分析。

1、做好现有环境的全面分析，为升级改造提供可靠依据

升级改造要做好，现有环境的全面分析是前提。如何做好现有环境的全面分析，具体来说就是要明确现在系统硬件 + 软件环境的客观情况、存在问题、未来业务发展需求、现有可实行的软硬件升级改造技术及方案、升级改造的要求与条件、升级改造的难点及可实行的解决办法等。

立足医院 HIS 系统本次的升级改造，全面分析工作包括：

① 现有 HIS 系统的软硬件情况的详细了解。存储层面上，包括存储型号、磁盘类型、是否有用快照复制等备份技术、存储最大 IOPS 及吞吐量、存储池 /RAID/LUN/HOST GROUP 等配置情况；光纤交换机层面上，包括光纤交换机模块速率、剩余模块数量、级联情况、 alias/zone 等配置情况；主机层面上，包括 CPU 的类型、核数、主频及使用情况，内存的类型、大小及使用情况，磁盘类型、负载、 PV/VG/LV/fs 等 LVM 管理情况，网卡类型、速率及负载， HBA 卡的类型、速率及负载，其它主机配置情况如 PCI 、串口线等；操作系统层面上，包括用户、组、 IP 网络、防火墙、访问控制列表、磁盘 / 网卡 /HBA 卡 / 系统环境参数等系统配置参数的具体情况；数据库层面上，包括数据库版本及补丁、数据库用户、数据量大小、表空间及数据文件、临时文件、在线及离线日志配置情况、表 / 索引 / 存储过程 / 触发器 / 序列 /DBLINK 等数据库对象的情况、数据库 job 情况等；网络层面上，交换机接口速率、网络接口类型（电口 / 光纤）及剩余口等情况；容灾层面上：物理层、逻辑层、数据层及应用层等容灾方式建设情况，各种风险应对措施及应急方案情况。

值得提出的是，系统的软硬件情况的详细了解是一个整体的过程，例如系统的 IO 性能，不仅要通过存储专业的监控软件对系统存储的使用情况做一个长期的监控及评估，而且还要从主机 AIX 操作系统层面通过诸如 nmon 等监控工具以及数据库 Oracle 层面上通过 Statspack 监控系统 IO 的整体性能，综合多个层面多个角度的数据，客观分析系统现有情况。

② 现有 HIS 系统存在问题及未来业务发展需求分析

详细了解 HIS 系统现有架构、配置、性能等情况后，列出 HIS 系统存在问题清单，结合医院业务发展趋势，预估医院未来业务增长对系统的要求，包括医院未来新上线系统的对接要求、互联网 + 医疗如微信、支付宝、银联、配药等业务模式扩展对系统的压力要求等，列出 HIS 系统未来性能瓶颈清单，结合两者，为后续升级改造的架构设计提供参考。

③ 现有可实行的软硬件升级改造技术及方案分析

对不同厂家、不同品牌的软硬件产品、技术及方案进行审慎评估，结合医院 HIS 实际，对各类软硬件厂家技术及方案进行综合考量，列出不同技术及方案的优缺点，为后续架构设计及设备选型提供参考

④ 升级改造的要求与条件、难点及可实行的解决办法分析

升级改造涉及机房配电环境、地板承重、机柜空间、综合布线、不同机房间的网络链路、网络网口、升级改造项目完成时间、切换停机窗口时间等要求和条件，要充分评估升级改造的要求、风险及难点，拟定升级改造风险应对表，做好升级改造的风险应对。

2、做好升级改造架构的设计，为升级改造指明方向

升级改造要做好，架构的科学设计是关键。架构的设计要充分结合现有环境的全面分析的结果，充分评估业务未来需求的增长、升级改造的要求与条件、现有先进技术及方案等多方面内容。架构设计应体现架构稳定可靠、方法科学、技术先进、体系完备、性能卓越和有一定的前瞻性的原则，邀请国内外知名的医疗 IT 专家对医院现有 HIS 架构进行整体设计与咨询，为后续升级改造指明方向。

3、做好设备选型，为升级改造提供可靠设备支持

升级改造要做好，合理的设备选型是重要基础。架构设计完成后，在项目预算范围内，选择哪种技术，如双活存储架构方面包括了 EMC VPLEX 和 IBM SVC 的硬件虚拟化网关方式 /HDS 高端存储虚拟化软件方式；选择哪种设备，如存储方面包括了 EMC Vmax F 全闪系列 /HDS F 系列等，主机方面包括了 K1 Power E870 小型机 / 富士通 M12-2S/HP Unix 小型机；选择哪种数据库升级迁移方式，包括 GoldenGate/RMAN/ExpImp 导入导出方式等。设备选型要结合现有环境选择方案最先进、产品最稳定、性能最优越、经济效益最优化、升级改造工作最简化平稳的设备。

4、做好升级改造方案，为升级改造提供可靠技术路线

升级改造要做好，方案的细化及落实是重点也是难点。升级改造涉及系统的方方面面，方案既要统筹兼顾，又要细化可落实。存储层面，如何划分存储池 /RAID 组 /LUN/Host ，快照、精简等存储功能如何配置使用；操作系统层面上， AIX 系统安装何种版本，文件系统如何划分，计算内存及非计算内存、存储的队列深度等系统关键参数如何配置，网卡是否聚合绑定等；数据库层面上，升级改造后的 Oracle 11g 版本与 HIS 应用的兼容性风险问题，升级改造后的 HIS 系统与医院其它系统通过 DBLINK 的存储过程进行数据交互的兼容性问题，与医院在用的 Oracle 9208 客户端之间的兼容性问题等。升级改造方案制定后需要搭建与现有生产环境一致的测试环境进行完备的测试，包括系统参数设置的测试确认、功能测试、性能的测试等，方案的所有内容需要测试确认后方可作为最终升级改造的切换方案进行实施。另外，要反复测试确认升级改造切换的停机所需时间，所有切换操作形成可执行命令行及步骤，确保停机时间窗口尽可能短。