大型医院DB2数据库群集建设探讨*

单红伟 张小亮 蔡雨蒙 刘 云

(1南京医科大学医学信息学与管理研究所 南京 210096 2南京医科大学第一附属医院(江苏省人民医院)信息处 南京210029) (南京医科大学医学信息学与管理研究所 南京 210096)

1 引言

医院信息系统是信息化社会医院业务的运行支撑，数据库又是重中之重。医院信息系统(Hospital Information System,HIS)、检验信息系统、影像存储与传输系统等核心业务的架构基本为数据库-客户端两层架构，随着医院信息化的快速发展和IT技术在医疗行业的广泛应用，医院对信息系统中处于核心地位的数据库提出更高的可靠性要求。数据库系统是医院信息化系统的基础，包含大量的患者基础信息和诊疗信息。当前医院信息化正在从传统的面向收费的HIS逐渐向面向医护服务的临床一体化系统过渡，从初期的功能性需求到以用户满意度为导向的高层次需求过渡。因而，如何保证数据库系统的安全和稳定，提升医护人员的用户体验度，成为医院信息化建设的首要任务。且前很多大型三甲医院的HIS仍在使用DB2数据库作为核心系统，而业内普遍为，构建数据库集群架构是目前保证数据库安全和稳定的主要方式[1-4]。

2 HIS数据库现状及存在问题分析

传统HIS多采用High Availability Disaster Recovery(HADR)技术实现业务的高可用容灾恢复，DB2 HADR是基于日志传送功能实现的，提供充分的粒度来满足医院的高可用性需求，见图1，可保证业务的高可用性及数据的安全性。但随着门诊量的迅速增长，医院要求建设新一代HIS满足业务发展，面临业务高并发压力，传统的数据库主备架构切换时间较长，发生故障时虽然备用数据库服务器能够很快恢复，但是无法支撑全院上千台终端的并发要求，影响全院整体业务无障碍运行，信息部门承担大的运维压力。同时，现有服务器及存储环境随着业务增长，核心HIS中的热点数据要求系统低延时、高IOPS，核心HADR架构的HIS数据库由于同时只有单个节点在线的天然缺陷，导致数据库中热点数据存在读写瓶颈，数据库响应速度无法满足业务系统的需求。因此医院进行数据库系统高可用性能优化迫在眉睫。

图1 传统HIS数据库架构

3 升级方案及实施

3.1 升级原则

3.1.1 独立服务器架构，保证数据库横向扩展能力 数据库的升级不是仅仅通过增加服务器，以空间换时间的方式进行改造，而是需要考虑到横向扩展的独立资源方案，这样既可以避免因性能需求提高导致的成本过度增大，又能够防止共享存储带来的单点故障。

3.1.2 在集群方案中尽量采用简单方式进行部署 避免增加管理运维成本，管理运维简单化是大势所趋，通过提高存储的在线扩展能力，借助于管理工具进行便捷化管理，提升DBA的管理水平，便于全院信息化的发展。

3.1.3 数据库的日志和备份管理 与高可用性的目标统一实现，对于关系型数据库来说，日志管理、数据定期备份是非常重要的环节。通常RTO和RPO是基于日志的保障，日志重要性不言而喻。所以数据库的高可用性保障，一方面需要提高集群之间服务器自愈性和本身的可靠性，另一方面有效降低医院业务中部分连续操作和提交数据库的日志压力。

3.1.4 采用新型服务器和存储，保证业务数据安全性 数据库的升级往往具有一定风险，使用新型服务器和存储，停用原有的HIS数据库，将原始数据迁移至新的数据库中，在新的升级方案出现问题时，可快速回退到原有的数据状态。

3.2 架构选择

由于数据库双活集群具有高性能和高持续可用性的特点，数据库单点故障不影响业务全局，即数据库单点故障对业务透明，针对传统HIS架构的不足，选择IBM DB2 PureScale架构方案对HIS数据库系统进行优化，PureScale的应用透明性使传统应用平滑迁移到双活集群上，见图2。服务器采用Power8 System，可以降低延迟和占用空间，提高数据库和应用的速度和效率，最佳支持DB2 PureScale，为未来灵活扩展奠定计算资源基础。SVC既可实现生产阵列数据的实时镜像和对Flashsystem的充分利用，保证数据的安全、高效，又可保证存储资源统一分配和管理，为未来灵活扩展及统一容灾奠定基础。Flashsystem作为全闪存系统，可降低HIS读写等待时间，实现SAN环境下达到的最低延迟，提高小型机CPU Core的利用率。

图2 HIS数据库集群架构

3.3 方案实施

HIS作为医院的核心系统，在升级时要尽量保证其离线时间较短，且故障发生时可快速回退。在升级前3个月，医院信息部门联合医务部门及部分临床科室按照既定的方案进行3次演练，以确保顺利切换。实施开始前全院启动应急系统，以保证业务数据的电子化存储及医生操作的便捷性。实施过程包括：通过HIS生产库暂停服务、HIS生成表结构和权限迁移、HIS生产库数据迁移、断开生产库网络连接、修改集群系统IP为生产库IP、修改归档模式及集群系统上线，总共7步完成数据库系统的正式升级改造。其中第3步HIS生产库数据迁移需要提前编写脚本，将原有数据迁移至新的生产库中，同时校验导入数据的一致性，耗时180分钟。总计耗时392分钟，和既定方案相差无几。

3.4 实施经验

考虑到医院业务的特殊性，在升级过程中有一些经验和教训供其他医院参考。一是系统的升级尽量以旧换新，切忌在原有系统上直接操作，以防止故障发生时原始数据无法恢复。二是升级前需要对既定方案进行演练，保证质控落实到每个环节。三是升级过程中需要对医疗业务数据进行电子化记录，以确保后期数据能够导入到生成数据的完整性。

3.5 升级效果

DB2数据库的升级一方面提高系统的稳定性和安全性，另一方面提升系统的性能。升级之后,见表1，可以看出升级后DB2性能有显著提升。

表1 DB2升级前后性能对比

4 结语

针对传统HIS核心数据库系统的硬件架构已无法满足现有的性能负载现状及架构本身存在的不足，本文结合江苏省人民医院实际情况，对医院数据库服务器环境进行升级改造，实际验证方案的可行性。不仅运用数据库高级特性保障高可用性，还充分挖掘数据库集群资源以合理支撑不同实例，达到负载平衡和高可用的双重优化效果，以期为其他医院DB2数据库系统升级提供参考方案。此次系统升级不仅可以使服务器长期不间断稳定运行，确保系统性能及客户端使用速度，还实现真正的双活数据中心，增加系统弹性，提高服务能力及资源整合、利用能力，保障信息安全。目前使用两个服务器节点提供对外服务，未来可考虑增加两个高速缓存节点，作为HIS热点数据的专用区域，以进一步提高数据库的响应速度，更好地为患者服务。