医院信息系统业务可持续性建设方案探讨

张琼瑶

福建省立医院 信息科，福建 福州 350001

医院信息系统业务可持续性建设方案探讨

张琼瑶

福建省立医院 信息科，福建 福州 350001

Abstract: This article focuses on how to ensure the sustainability of hospital information systems business to run. It conducts a detailed analysis and comparison of several solutions such as replication software, database replication, disk array replication, disk array replication clusters, mirrored volumes clustering. Therefore it illustrates the advantages and reasons for the choice of mirrored volumes clustering solution in our hospital, reference to our construction experience. It also sums up the experiences of system implementation and the effect of use, and provides reference informations for the colleagues.

Key words: HIS; high availability; business sustainability

本文就如何保证医院信息系统业务可持续性运行，结合本院的建设经验，对基于复制软件、数据库复制、磁盘阵列复制、磁盘阵列复制的集群、镜像卷的集群等解决方案进行了详细分析比较，阐明了我院选择基于镜像卷的集群解决方案的优点和理由，同时总结了系统实施经验和使用效果，为同行提供借鉴参考。

HIS；高可用性；业务可持续性

0 前言

我院是一所集教、科、研为一体的综合性三甲医院，开放床位1800多张，年门急诊量150多万人次。随着医院信息化建设的深入，计算机网络应用已经渗透到医院管理及业务的方方面面，目前工作站达1600多台，一旦计算机系统停止运行，对病人及医院所造成的影响是难以估量的。本文就如何保证医院信息系统业务可持续性运行并结合本院的建设经验进行方案探讨。

1 系统状况

我院信息系统由HIS、RIS、PACS、LIS、电子病历、麻醉系统、重症监护、合理用药系统、体检系统以及其他辅助系统组成，各系统之间的关系如图1。

图 1 信息系统关系图

由图1可见HIS是医院信息系统的核心，其它系统均需要与HIS进行数据交换。要保证医院信息系统的可持续性运行，首先要保证HIS系统可持续运行。

我院未改造前的系统是HIS采用了两台HP DL760服务器与EMC CX400磁盘阵列构成双冗余通道的SAN存储系统，数据库采用微软SQL Server 2000，并通过微软MSCS集群软件构成了双机集群系统，我院网络骨干采用了双冗余光纤网络。随着本院新病房大楼的启用，在新病房大楼也设置了一个网络机房，从而为进一步建设高可用性系统提供了基础。

要实现信息系统业务可持续性，我们认为最重要的是要做到以下七个字：不停、不丢、可恢复。“不停”的意思就是采用各种技术及管理手段确保应用系统不停机；“不丢”的意思就是说若发生灾难等意外事件，即使导致系统停止了运行，但也要保证系统业务数据不丢失；“可恢复”的意思就是说必须采取各种手段，确保系统和业务数据在任何情况下都可以恢复到最新的备份点，从而实现系统和业务数据可恢复。“不停”是我们实现业务可持续性的最高目标，“可恢复”是实现业务可持续性的基本保证。同时，由于各种技术本身的局限性，因此要实现系统业务可持续性需要综合采用多种技术手段互补才能实现。

结合我院的实际情况，我们提出了建设HIS业务可持续性系统的建设目标：首先必须要保证HIS数据库可持续访问，允许的中断时间应小于5min（为服务器正常切换所需要的时间）；即使发生意外事件，系统应做到不丢失数据。

下面结合我院的建设目标，来探讨我院在系统建设过程中对各种解决方案的比较分析。

2 方案选择

根据我们的实现目标，有以下几种方案可供选择：

(1) 基于复制软件的解决方案；

(2) 基于磁盘阵列复制的解决方案；

(3) 基于数据库的解决方案；

(4) 基于磁盘阵列复制的集群方案；

(5) 基于镜像卷的集群解决方案。

下面我们分别对各个方案进行阐述和比较。

2.1 基于复制软件的解决方案

该方案基本思路是：在中心机房和新大楼机房的服务器上分别安装复制软件，通过院内网将HIS数据库的数据文件实时复制到新大楼机房内的服务器上，使得在不同大楼分别有一份完全相同的数据文件副本。一旦中心机房发生意外事件，造成系统无法工作，此时可以手工使用备用服务器上的数据副本，在新大楼内启动数据库服务器；并通过修改业务系统中间层服务器的数据库配置使其指向新数据库服务器，使得业务终端可以使用备用服务器继续进行业务操作。通过这种解决方案可以达到发生意外时，数据不丢失，且可以尽快恢复业务系统运行的目的。

基于复制软件的解决方案示意图如图2。

图 2 基于复制软件解决方案示意图

为了对解决方案有一个全面的认识，我们从以下6个方面对它进行分析：

2.1.1 系统资源。复制软件根据实现层次的不同可以分为文件级和逻辑卷级。虽然逻辑卷级由系统底层实现，比文件级实现在系统资源占用更少和复制性能上会更高。但是由于均需要在服务器上安装复制软件，因此会占用生产服务器不少系统资源（包括CPU资源和内存资源），一般都在25%以下。

2.1.2 网络资源。由于复制软件通过TCP/IP网络进行复制，在大数据流复制时将对网络造成较大冲击。一般可以通过限制网络带宽使用或建立专门的复制网络来解决复制与业务争用网络的问题，并且受到网络带宽的限制，也影响了复制的速度。同时由于使用TCP/IP网络，理论上可以在任何距离的地方设置复制目的地，从而可以实现远距离容灾。

2.1.3 复制方式。基于逻辑卷级的复制软件能够支持同步/异步复制方式，基于文件级的复制软件一般只支持异步方式。采用同步复制方式能够保证两份数据副本实时完全一致，采用异步复制方式无法保证该点，但能保证数据在时序上一致。同步复制由于网络延迟的原因，将对系统性能造成较大影响，通常采用异步复制方式。

2.1.4 业务接管。采用该方案，业务接管需采用手工方式进行。由于各业务系统均与HIS系统有数据交换接口，手工业务接管的时间大约需要30min，才能将各业务系统均切换到新服务器上工作。

2.1.5 应对文件物理损坏。由于复制原理本身的原因，因此主服务器上数据文件所做的任何改变均将同样在复制副本上发生，包括对数据文件所造成的物理损坏。这将导致在特定的条件下严重时使用复制的副本无法启动数据库。这种问题只能通过数据备份软件中的备份来解决。

2.1.6 投资。采用这种方案，只需要购买复制软件，对服务器和存储硬件无特殊要求，只要服务器有足够的处理能力和足够的存储空间就行。

2.2 基于磁盘阵列复制的解决方案

该方案基本思路是：在新大楼机房也配置一台EMC磁盘阵列，通过光纤连接新旧两台EMC磁盘阵列，原阵列的数据由磁盘阵列控制通过SAN复制到新的磁盘阵列，使得在两个磁盘阵列上各有一份业务数据库的实时拷贝。一旦中心机房发生意外，磁盘阵列中的数据无法访问或服务器停止工作，可以启用新大楼机房中的服务器和磁盘阵列。通过利用磁盘阵列中的数据库文件副本，启动业务数据库，并通过修改业务系统中间层服务器的数据库配置使其指向新数据库服务器，使得业务终端可以继续进行业务操作。通过这种解决方案也可以达到发生意外时，数据不丢失，且可以尽快恢复业务系统运行的目的。

基于磁盘阵列复制的解决方案示意图如图3

图 3 基于磁盘阵列复制解决方案

下面我们也从6个方面对该解决方案进行分析：

2.2.1 系统资源。采用基于磁盘阵列复制的解决方案，由于复制工作由磁盘阵列承担，服务器不参与任何工作，因此不占用任何服务器资源，对系统无影响。

2.2.2 网络资源。基于磁盘阵列的复制是通过SAN进行数据复制，因此其对业务网络无影响。

2.2.3 复制方式。基于磁盘阵列的复制支持同步和异步两种复制方式，考虑到通常SAN环境的带宽比较高，通信条件好，一般都采用同步方式进行复制。因此能够保证两个磁盘阵列具有完全一样的数据拷贝。

2.2.4 业务接管。采用该方案，若不另行配置软件，则只能够手工进行业务的接管。因此接管过程和采用基于复制软件的解决方案差不多，也需要约30min。

2.2.5 应对文件物理损坏。同基于复制软件的解决方案一样，基于磁盘阵列的复制也会忠实地将源磁盘阵列的所有变化复制到目标磁盘阵列，包括错误。

2.2.6 投资。基于磁盘阵列的解决方案对磁盘阵列的要求比较高，通常是中高端的产品才能够支持基于磁盘阵列的复制。另外，一般要求两台磁盘阵列是同一产商的产品才能够实现。这导致了该方案需要比较高的投资。

2.3 基于数据库的解决方案

该方案基本思路是：采用数据库本身提供的复制能力，将生产数据库的数据复制到目标数据库，从而保证在源服务器和目标服务器各有一份完整拷贝。在生产服务器发生意外无法对外提供服务时，手动启用备用服务器，从而在意外情况下达到数据不丢失，并且可以尽快接替业务服务的目的。

下面我们从6个方面对该解决方案进行分析：

2.3.1 系统资源。针对我院所使用的微软SQL Server 2000数据库，实现数据库复制方案有两种，一种是利用数据库的复制功能，另一种是利用数据库的日志传送功能。采用数据库复制功能将对生产数据库产生较大的负载压力；而采用日志传送方式，消耗的系统资源将较少。

2.3.2 网络资源。由于数据库复制将通过网络进行传送，因此将占用网络带宽。采用日志传送方式所占用的带宽将大大少于基于数据库复制功能所使用的带宽。

2.3.3 复制方式。采用数据库复制功能的复制一般都采用定时的方式进行复制。因此生产库和备份库之间的数据存在时间差。

2.3.4 业务接管。采用数据库复制的方案，业务接管需要通过手工的方式进行。

2.3.5 应对文件物理损坏。由于数据库复制是在应用级，亦即逻辑级进行复制。因此对数据库文件所造成的物理破坏操作不会被复制到目标数据库。基于数据库复制的方案能够防范文件物理损坏复制到目标服务器。

2.3.6 投资。采用数据库复制的方案，由于所采用的功能均是数据库自带的功能，因此无需增加额外投资，只要购买必要的服务器、操作系统及数据库软件即可。

2.4 基于磁盘阵列复制的集群方案

该方案基本思路是：在基于磁盘阵列复制方案的基础上增加集群软件，从而弥补原方案无法自动切换的问题。具体做法是在磁盘阵列复制方案的基础上将两台HP服务器移一台到新大楼机房，采用EMC Fulltime Autostart软件构成双机系统。原EMC磁盘阵列的数据由磁盘阵列控制通过SAN复制到新的EMC磁盘阵列，使得在两个磁盘阵列上各有一份业务数据库的实时拷贝。一旦中心机房发生意外，数据库将自动切换到新大楼机房的服务器和存储上运行。无需修改业务系统中间层服务器的配置，业务终端就可以使用备用服务器继续进行业务操作。通过这种解决方案可以在发生意外时数据不丢失，且可以自动恢复业务系统运行的目的。

基于磁盘阵列复制的集群方案的示意图如图4。下面我们从以下几个方面分析这个解决方案：

2.4.1 系统资源。采用该方案，由于服务器不参与数据复制，因此不占用系统资源。

图 4 基于磁盘阵列复制的集群方案

2.4.2 网络资源。由于数据是通过SAN进行复制，因此不占用网络带宽。

2.4.3 复制方式。正如前面方案所述，可以支持同步或异步复制。

2.4.4 业务接管。由于采用了EMC Fulltime Autostart集群软件，所以系统能够自动进行业务切换操作。若中心机房发生故障，Autostart软件自动将数据库服务切换到新大楼机房内的服务器上运行，而各系统无需修改配置，仍可继续正常运行。但当服务器切换回主服务器时，存在着需要先把数据往回进行复制，在数据同步后才能进行切换的问题，因此不能在两个中心间反复自由切换。

2.4.5 应对文件物理损坏。由磁盘阵列复制的原理决定了文件的物理损坏也将被复制软件同样复制到目的服务器上。

2.4.6 投资。由于需新购一台EMC磁盘阵列，且需更换集群软件，因此系统的投资比较高。

2.5 基于镜像卷的集群解决方案

该方案基本思路是：将已有的两台HP DL760服务器移一台到新大楼机房，并且在新机房购置一台新的光纤磁盘阵列，两台磁盘阵列通过光纤连接在同一个SAN内。在两台服务器上安装Veritas Storage Foundation卷管理软件，然后建立跨越两个磁盘阵列的镜像卷，将集群数据库建立在镜像卷上。这样无论是哪一台磁盘阵列发生故障，都不会引起集群发生切换导致业务中断，并且将原微软MSCS集群的仲裁磁盘也改为镜像卷，这样就弥补了MSCS集群的不足，消除了系统单故障点，从整体上提高了系统的高可靠性。

基于镜像卷的集群解决方案的示意图如图5。

如图5所示，通过采用Veritas Storage Foundation软件建立跨磁盘阵列的镜像卷作为MSCS集群的共享盘，对MSCS工作方式来说没什么改变。只是共享盘的可靠性提高了，不会因为单个磁盘阵列的宕机而导致整个集群停止服务。即使某个机房内的服务器和磁盘阵列同时发生故障，由于在另一个机房内仍有一套完整的服务器和磁盘阵列，集群仍可以正常工作。

图 5 基于镜像卷的集群解决方案

下面我们从以下几个方面来分析这个解决方案：

2.5.1 系统资源。采用本方案，由于服务器上需要安装卷管理软件来做逻辑卷镜像，因此需要消耗部分服务器资源，根据实际测试所得CPU增加不足15%，内存多占用几十兆字节。

2.5.2 网络资源。由于不通过网络进行复制，因此不占用网络资源。

2.5.3 复制方式。采用该方案，两台磁盘阵列上的数据是通过卷管理软件做镜像来保证两者完全一致的。套用复制的说法，可以认为是采用类似同步复制的方式来保证数据的一致性。

2.5.4 业务接管。采用本集群方案，集群软件使用的仍旧是微软的MSCS集群软件。因此业务的接管完全是自动进行的，无需人为干预。并且由于是基于镜像卷的方式，避免了采用磁盘阵列复制的集群方式所需要的在回切时数据需先要往回复制的问题，可以随时在两台服务器上进行切换。由此提高了系统抵御复杂故障的能力，并且便于系统维护。

2.5.5 应对文件物理损坏。由于两台磁盘阵列的数据通过镜像保持同步，因此对文件的物理损坏操作将同时在两台磁盘阵列上造成破坏。该问题只能通过备份或逻辑复制来消除。

2.5.6 投资。该方案由于需增购磁盘阵列和卷管理软件，因此其造价也是比较高的。但由于其是基于软件的解决方案，因此对新购的磁盘阵列无特殊要求，不要求与原磁盘阵列为同一产商，故可节省投资。

2.6 方案比较

通过上面对各个方案的阐述，我们可以看到各个方案各有优缺点，汇总对比见表1。

2.7 方案说明

根据以上对各种方案的比较，结合我院的实际情况，我们采用了基于镜像卷的集群方案来实现系统“不停”，采用数据库日志传送方案来实现系统“不丢”数据，并结合我院已有的数据备份系统来确保实现系统和业务数据“可恢复”。从各个方面实现我院HIS系统业务持续运行。方案示意图如图6。

表 1 各方案优缺点对比

图 6 HIS系统业务可持续性解决方案示意图

方案说明如下：

(1) 将一台HP DL760移到新机房，同时新购一台EMC CX3-20磁盘阵列。

(2) 配置Veritas Storage Foundation卷管理软件，建立跨磁盘阵列的镜像卷。

(3) 将原MSCS集群的共享磁盘由基本磁盘更改为镜像卷。

(4) 配置1台服务器作为MS SQL Server的日志传送服务器，以消除物理文件损坏导致数据丢失的隐患。

(5) 通过备份服务器定时对HIS数据库进行备份，并适当增加增量备份的频度，以消除数据库逻辑错误造成数据丢失的隐患。

3 方案实施及效果

本方案实施的难点是如何在最短停机时间内完成系统的升级改造工作。我们的经验是在医院业务较少的节假日（我们是在2007年春节初一晚上）进行。首先将业务数据完全迁移到一台备用服务器上运行，使其临时接替生产服务器工作，从而保证系统停机时间最短。然后对生产服务器进行升级改造和调试，并进行测试。在确认系统升级改造成功后，由备用服务器重新将数据库迁移回生产服务器，重新投入运行。

在整个项目的施工过程中，事先应进行充分的准备，做好模拟和准备工作，制定详尽的计划文档，并做好应急预案。在实际施工工程中，依照事先制定好的步骤，逐步操作并检查。在充分的准备下，我们在预定的时间依照计划顺利完成了系统实施。

本项目实施至今，在我院已正常运行达三年的时间，这期间曾出现过一次EMC CX400故障，由于我们采取了镜像卷因此没有对HIS的正常运行造成任何影响，同时为了确保系统能在硬件出现故障时主动切换，我们在长假日如国庆、春节等总是把HIS切换到备用机房工作。系统投入使用的三年来我院HIS一直持续不间断运行，真正实现零宕机，为保障我院信息系统业务可持续性做出了突出贡献。

4 结束语

通过本项目的实施，充分保证了我院HIS系统安全可靠地持续运行，为我院今后信息系统的可持续运行建设积累了宝贵的经验。我们深切体会到在系统建设时必须进行详细的测试和评价，这样才能选择出最适合自己的解决方案，在实施前必须制定周密的计划，进行多次的模拟测试，实施时严格按照文档进行，从而才能保证实施的顺利完成，使医院业务正常开展。

[1] 李枫,陈明生,孙志挥.使用负载均衡技术的高可用性主机服务器集群[J].计算机工程与应用,2003,39(16): 97-99.

[2] 潘传迪.高可用性医院信息系统核心部件的构建与实现[J].医学信息,2006,19(5):768-770.

[3] 顾树华.利用Windows群集服务构建双机互备系统[J].计算机系统应用,2006(2):60-61.

Discussion on the Solutions of the Sustainability of Hospital Information Systems Business

ZHANG Qiong-yao
Information Department, Fujian Provincial Hospital,Fuzhou Fujian 350001, China

R197.324

B

10.3969/j.issn.1674-1633.2010.08.002

1674-1633(2010)08-0004-05

2010-03-02

作者邮箱：zqy@fjsl.com.cn