APP下载

医院数据库高可用设计浅谈

2018-12-13

数字通信世界 2018年11期
关键词:高可用性停机业务流程

吴 健

(安徽省无为县人民医院,芜湖 238300)

医院越来越依赖于信息化管理,各业务应用的数据信息,主要存储在数据库中,医院对这些数据访问的连续性要求越来越高,为了避免因为数据库原因导致各种损失,数据库的高可用已成了信息化建设的重中之中。数据库高可用设计尤其重要,通过数据库高可用性解决方案可以帮助最大化系统可用性并满足业务的最高SLA要求。

1 什么是高可用

高可用性是指按需访问应用程序、数据库、服务或功能的程度。高可用性是通过最终用户的感知来衡量的。

1.1 高可用性主要特征

可靠性:可靠的硬件是高可用性解决方案的一个组成部分。可靠的软件(包括数据库,Web服务器和应用程序)对于实现高可用性解决方案同样至关重要。例如,低成本商用硬件与系统集群、数据库集群等软件相结合,可用于实现非常可靠的系统,因为即使单个服务器可能出现故障,数据库也可以继续提供访问。

可恢复性:由于从故障中恢复可能有很多选择,因此确定高可用性环境中可能发生的故障类型以及如何及时从这些故障中恢复以满足业务需求非常重要。

及时错误检测:如果架构中的组件发生故障,则快速检测对于从意外故障中恢复至关重要。虽然可以从停机中快速恢复,但如果发现问题需要额外的90分钟,那么可能无法满足SLA。监视环境的运行状况需要可靠的软件来快速查看它,并能够通知数据库管理员一个问题。

持续运行:当执行维护活动的停机时间非常短或没有时,提供连续访问数据的能力至关重要。诸如将系统升级或服务器增加硬件等活动对于高可用性体系结构中的最终用户应该是透明的。

1.2 高可用重要性

高可用性的重要性因应用环境而异。系统设计方案依赖于对关键业务数据的即时访问。当数据不可用时,操作可以停止运行。停机可能导致效率下降,收入损失,医患关系受损,宣传不力和诉讼。

停机成本中需要考虑的其他因素是单个意外中断的最大可容忍长度以及允许事件的最大频率。如果事件持续时间少于30秒,那么它可能会造成很小的影响,并且最终用户可能几乎感觉不到。随着中断的长度增加,效果可能呈指数级增长,并对业务产生负面影响。或者,频繁停电,即使持续时间很短,也可能同样扰乱医院业务运营。在设计解决方案时,了解停机的真实成本非常重要,以了解医院业务如何通过可用性改进而受益。

2 确定高可用性要求

确定高可用性要求的分析框架:

2.1 业务影响分析

严格的业务影响分析可识别医院中的关键业务流程,计算影响每个业务流程的计划外和计划IT中断的可量化损失风险,并概述这些中断的影响。它考虑了基本业务功能,人员和系统资源,政府法规以及内部和外部业务依赖性。

2.2 停机成本

完整的业务影响分析提供了量化计划外和计划内停机成本所需的洞察力。了解此成本至关重要,因为这有助于确定高可用性投资的优先级,并对所选的高可用性技术产生直接影响,以最大限度地降低停机风险。

2.3 恢复时间目标(RTO)

业务影响分析将确定恢复时间目标(RTO)。RTO定义为在开始遭受不可接受的后果(财务损失,对客户满意度,声誉等的影响)之前,基于IT的业务流程可能会停机的最长时间。RTO表示业务流程或组织的停机容忍度。RTO要求由业务的关键任务性质驱动。因此,对于运行证券交易所的系统,RTO为零或非常接近零。

2.4 恢复点目标(RPO)

业务影响分析还确定了恢复点目标(RPO)。RPO是基于IT的业务流程在对组织造成有害损害之前可能丢失的最大数据量。RPO表示业务流程或组织的数据丢失容忍度。这种数据丢失通常以时间来衡量,例如,数据丢失5小时或2天。

3 数据库高可用解决方案

3.1 系统恢复能力性能指标

恢复时间目标(RTO:Recovery time objective)和恢复点目标(RPO:Recovery point objective)用于计划外停机和计划维护

3.2 可管理性开销(MO:Manageability Overhead)

总体拥有成本(TCO:Total Cost of Ownership)和投资回报率(ROI:Return On Investment)

3.3 高可用架构建议

根据RTO,RPO,MO,可伸缩性和其他因素的业务要求高可用性架构建议:

4 医院数据库最佳实践

4.1 医院数据库架构设计实践

数据库系统环境:

数据库版本:SQL SERVER 2012

操作系统版本:Windows 2012

集群环境:Windows MSCS

运行业务:HIS数据库、LIS数据库等

系统架构考虑:

合理利用硬件性能,提供硬件使用率。这种架构故障最大RTO或节点故障以秒为单位,MO(可管理性开销)中等,ROI(投资回报率)很高。

实现数据库负载均衡,数据库读、写离。所有报表查询、其它平台接口在只读数据库操作,避免对主数据库性能和安全影响。

避免数据库单点故障,故障自动切换,服务器和数据库例实级故障对门诊访问是透明的。数据是冗余存储,避免存储级单点故障。

系统架构设计:

在HIS、LIS数据库环境配置两个数据库集群环境,每个集群两个数据库节点。每个数据库集群分别安装和配置HIS、LIS两个数据库实例。

集群内部数据库节点自动故障切换,例如:当HIS主节点故障时,HIS数据库会自动切换到LIS辅助节点,且不影响HIS主数据库访问。

集群之间数据库实时同步,且实现数据库读、写分离,例如:当主数据存储故障导致主数据集群不可用时,HIS主、LIS辅助节点业务自动切换到辅助数据库集群,所有连接IP信息是虚拟VIP,也可以自动迁移,对于门诊业务是透明的。

HIS和LIS主数据库分别在两个集群环境,防止HIS和LIS数据库在门诊高峰期发生资源争用。两个集群主、辅助节点数据实时同步,并且读、写分离。

猜你喜欢

高可用性停机业务流程
质量管理工具在减少CT停机天数中的应用
RPA机器人助业务流程智能化
STK业务流程优化的探究
企业财务管理、业务流程管理中整合ERP之探索
超长公路隧桥高可用性监控平台方案分析
基于财务业务流程再造的ERP信息系统构建探析
校园一卡通服务端高可用性改造实施方案
OpenStack云计算平台高可用性的研究
雷克萨斯NX200t车停机和起动系统解析
一种虚拟化集群心跳算法