XXX人民医院SYMC容灾备份技术方案.docx
- 文档编号:10556274
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:28
- 大小:568.07KB
XXX人民医院SYMC容灾备份技术方案.docx
《XXX人民医院SYMC容灾备份技术方案.docx》由会员分享,可在线阅读,更多相关《XXX人民医院SYMC容灾备份技术方案.docx(28页珍藏版)》请在冰点文库上搜索。
XXX人民医院SYMC容灾备份技术方案
XXX人民医院
存储容灾、系统高可用及备份项目
技术方案
一、前言3
二、容灾需求分析4
2.1关于容灾4
2.2业务连续性参数4
2.3核心业务现状5
2.3存储容灾、系统高可用与备份需求分析6
三、存储容灾与系统高可用架构设计和技术选择8
3.1容灾整体架构8
3.2方案描述9
3.3技术实现10
3.4存储容灾与系统高可用故障响应11
3.5产品选型14
3.6StorageFoundation技术特点14
存储在线管理14
多层存储与在线迁移15
存储多路径管理18
存储快照管理20
3.7本方案能达到的技术指标21
四、备份架构设计和技术选择23
4.1方案架构设计23
4.2方案描述24
4.3产品选型25
4.4本方案能到达的技术指标25
一、前言
随着社会及公众对医疗业务的服务要求不断的提高,管理水平和服务功能的强化及发展将对医院办公方式产生极大的推动作用。
近几年,XXX人民医院在信息化方面正在逐步走向成熟,并形成了一定的规模。
XXX人民医院现有主要的信息系统包括HIS医院信息系统、LIS系统、PACS影像系统等,分别部署在多台服务器上。
由于医疗行业的特殊性,医院信息系统需要7×24小时连续运行,对于系统的安全、稳定要求很高,医院的主要诊疗活动都依赖于信息系统的运行。
因此为了保障医院系统的高可用性,医院信息系统迫切需要从简单的单存储双机系统更改为双服务器双存储集群容灾系统,确保发生存储、服务器故障时能做到“数据0丢失,应用0切换”。
二、容灾需求分析
2.1关于容灾
有句古谚叫“别把鸡蛋放在一个篮子里”。
现在的信息系统,将各种数据高度集中,“鸡蛋”全放在一个篮里了。
一旦出现突然停电、意外死机或者人为破坏,便会造成数据丢失,后果非常严重。
容灾备份系统就是防止意外情况而采取的一种解决方案,其目的只有一个,那就是保证数据安全和业务应用连续。
理想的容灾备份系统是能够进行两个机房数据的实时同步和重要应用的自动切换。
2.2业务连续性参数
考虑容灾或业务连续性需求和方案选择时必需对业务系统以及业务系统的RPO和RTO进行分析,其中:
∙RecoveryPointObjective(RPO)
oThepointtowhichdatamustberestored
o能够接受的最大数据损失量
∙RecoveryTimeObjective(RTO)
oThetimebywhichdatamustberestored
o能够接受的最长停机时间
二者之间的关系如下图所示:
2.3核心业务现状
目前,XXX人民医院运行2套HIS系统,其中支撑灏瀚公司HIS系统的数据库服务器是2台IBMP570(8个2.2GCPU32G内存),运行Oracle数据库,配置为HA模式;运行兰德HIS系统的数据库服务器是1台HPDL580,运行SQLServer数据库。
在P570上的数据库中,除了HIS数据之外,还有浙江图特公司的OA、成本核算、体检、等系统的数据。
有三台存储:
1台为EMCCX-500,保存灏瀚HIS和兰德HIS系统以及数字图书馆的数据,容量1.5T;1套EMCCX4-480,保存PACS系统的数据,容量为12TB,以及1台EMCAX4-5的NAS存储,容量是12TB。
主要设备配置如下表:
主要设备一览表
服务器型号
配置
数据库
应用
IBMP570-A
8个2.2的CPU,32GB内存
ORACLE
灏瀚HIS
IBMP570-B
8个2.2的CPU,33GB内存
ORACLE
灏瀚HIS
IBM刀片
2*2.5G/2*4G/146G*2/RAID1/HBA卡
SQL2005
智方LIS
IBM刀片
2*2.5G/2*4G/146G*2/RAID1/HBA卡
SQL2005
智方LIS备机
IBM刀片
2*2.5G/2*4G/146G*2/RAID1/HBA卡
SQL2000
内镜
IBM刀片
2*2.5G/2*4G/146G*2/RAID1/HBA卡
移动办公
IBM刀片
2*2.5G/2*4G/146G*2/RAID1/HBA卡
蓝德测试
IBM刀片
2*2.5G/2*4G/146G*2/RAID1/HBA卡
图特测试
IBM刀片
2*2.5G/2*4G/146G*2/RAID1
SQL2000
超声
IBM刀片
2*2.5G/2*4G/146G*2/RAID1
医保前置机
IBM刀片
2*2.53G/12GB/300G*2/RAID1/HBA卡
预约挂号
IBM刀片
2*2.53G/12GB/300G*2/RAID1/HBA卡
ORACLE
供应室管理
IBM刀片
2*2.53G/12GB/300G*2/RAID1/HBA卡
ORACLE
心电信息系统
IBM刀片
2*2.53G/12GB/300G*2/RAID1/HBA卡
IBM刀片
2*2.53G/12GB/300G*2/RAID1/HBA卡
IBM刀片
2*2.53G/12GB/300G*2/RAID1/HBA卡
HPDL580
4个Xeon3.4四核CPU/8GB内存
SQL2000
蓝德HIS
HPDL380
1个Xeon2.66四核CPU/4GB内存
ORACLE
OA、体检、物资
IBMX3650
Xeon2.8双核CPU/4GB内存
灏瀚中间件
IBMX3650
Xeon2.8双核CPU/4GB内存
灏瀚中间件
IBMX3650
Xeon2.8双核CPU/4GB内存
灏瀚域控
IBMX3650
Xeon2.8双核CPU/4GB内存
灏瀚域控
IBMX3650
Xeon2.8双核CPU/4GB内存
SQL2000
用药防火墙
IBMX3650
Xeon2.8双核CPU/4GB内存
SQL2000
桌面管理
IBMX3650
Xeon2.8双核CPU/4GB内存
SQL2000
数字图书馆
IBMX3650
Xeon2.8双核CPU/4GB内存
ORACLE
病理系统
EMCCX500存储
6*146GB+19*300GB硬盘
灏瀚HIS、蓝德HIS、蓝德HIS备份、OA\体检\物资
EMC4-480存储
30*450GB硬盘
GEPACS在线图像
EMCAX4-5NAS存储
12*1TB硬盘
GEPACS离线图像
从以上表格可以看出,XXX人民医院核心业主要包括HIS和PACS两套系统,HIS系统肩负着医院日常的门诊、急诊和住院业务。
可以说HIS系统是医院的核心信息系统,所有医院日常工作都依赖于HIS系统的正常运转。
2.3存储容灾、系统高可用与备份需求分析
根据对XXX人民医院业务系统的了解,发现HIS系统是XXX人民医院核心系统,非常关键,灾难性事故仍影响着系统可靠运行。
系统风险总结如下:
∙新HIS系统服务器高可用性:
目前医院只有两台IBMP570小型机,同时这两台小型机还运行灏瀚HIS系统,切换时无法停止灏瀚系统的运行,所以对新HIS系统的高可用性无法得到保障。
∙没有独立的备份系统。
在XXX人民医院信息化的前期建设中,没有建立独立的备份系统,数据均备份与主存储的硬盘上,一旦主存储系统故障,将造成系统停机、关键数据可能丢失,因此,需要建立数据冗余备份系统,保证关键数据的安全。
∙存储系统性能和稳定性问题。
目前HIS系统核心数据库的存储设备EMCCX500已使用六年,硬件出现故障风险极大,而且存储背板有故障报警,但由于没有冗余的存储备份,不能停机更换,无论从性能和稳定性方面都无法满足新HIS系统核心数据库的存储要求。
因此,需要考虑新增一台高性能、全冗余、模块化的存储系统。
∙部分应用服务器单机运行,存在单点故障,需进行高可用改造。
因此为了以防万一,能够在灾难发生时保证数据的安全性,同时快速恢复生产业务,XXX人民医院需要实现业务系统高可靠和容灾备份。
根据XXX人民医院目前应用状况和未来的扩展性,由于新HIS系统服务器是管理和处理大量关键业务数据的平台,不但要保证数据高可用而且需要保证数据能够被准确及时的处理,必需提供一个尽可能连续运行的服务器和存储平台。
因此,此次升级方案如下:
∙将现有运行老HIS系统的IBMP570服务器释放出一台,原有的灏瀚HIS系统通过技术切割方式,单机运行;
∙购置一台性能与现有的IBMP570性能相当的小型机服务器,与切割下来的IBMP570服务器组成双机模式,同时数据库层面配置OracleRAC组建,以并行负载模式对外提供服务,实现Oracle数据库的应用级容灾。
∙采购1套高性能、全冗余、模块化的存储设备,保障核心HIS系统的业务连续性和数据的完整性,同时对EMC4-480进行扩容,新存储设备与EMC4-480能通过数据镜像、存储虚拟化等方式实现数据的自动移动,搭建可靠、弹性的存储基础架构。
∙对现有的EMCAX4存储进行扩容,并购置系统备份软件,实现所有运行的系统的逻辑数据备份,保障应用系统数据的安全性。
∙采购集群软件,对超声、病理、内镜等系统的服务器进行高可用改造,对采用相同数据库的系统进行整合,Oracle数据库尽量在小型机上运行,SQLServer数据库按版本进行整合。
三、存储容灾与系统高可用架构设计和技术选择
3.1容灾整体架构
XXX人民医院目前HIS信息系统所有硬件设备放置在同一个机房,根据升级后的硬件条件,具备主机与存储全冗余,我们建议通过SymantecStorageFoundationHA软件搭建成“2+2”集群模式,即2台P570小型机构成ORACLERAC双机集群,2台存储实现同步镜像。
为了充分保证HIS业务数据连续不中断,我们建议今后在两个大楼分别放置一台HIS服务器与存储(即两台IBMP570服务器与存储分开部署在两个机房),如果一个机房发生灾难性事件,灾备机房可以迅速接管主机房的业务。
当然在部署了SymantecStorageFoundationHA后,这种设备的迁移将不会影响业务的运行,也不会增加任何投资。
对于超声、病理、内镜等3个系统的集群,同样通过SymantecStorageFoundationHA实现。
所以本次XXX人民医院存储容灾与系统高可用方案中需要考虑两方面:
∙一方面实现两HIS系统数据在两套存储上的完全一致;
∙另一方面实现对关键应用切换,在主机发生故障时,能将业务应用切换到备用系统主机;
因此建议的逻辑结构如图所示:
3.2方案描述
对于HIS服务器,使用StorageFoundationHA集群。
将容灾阵列上划分出一个单独的存储区域,用以存放HIS灾备数据,此存储池大小不能小于现有HIS存储池的大小。
在服务器上部署SymantecStorageFoundationHA,使用软件内的镜像技术实现磁盘阵列上的HIS数据存储的全实时同步,任何一个磁盘阵列出现故障,另一个磁盘阵列自动接管,对于应用的影响为零,即实现“数据0丢失”。
并且SymantecStorageFoundation可以实现各种不同品牌磁盘阵列产品间和不同型号间的镜像,在非常多的医院中都有实际案例可供参考。
这样可以充分使用现有的硬件资源,保护了用户的硬件投资。
由于HIS系统将部署ORACLERAC组件,所以能做到数据库层的0切换。
超声、病理、内镜3个系统,通过StorageFoundation实现双机集群,当任一台服务器出现故障,另一台能自动接管。
3.3技术实现
Symantec利用StorageFoundation系列软件的镜像技术,来构建容灾方案。
利用StorageFoundation的镜像技术构建容灾系统是非常简单的,它只有一个条件,就是将两台存储部署在同一个SAN网络内,对于XXX人民医院来说,在硬件系统升级后,现阶段所有硬件设备将安装在一个机房内,即满足两台存储在一个SAN的条件。
当今后当扩展到两个机房时,只需要将主机房和灾备机房之间的SAN存储区域网络通过光纤连接起来,建立城域SAN存储网络即可。
然后,我们就可以通过StorageFoundation提供的非常成熟的跨阵列磁盘镜像技术来实现同城容灾了,容灾方案的结构如下图所示(现阶段所有设备均部署在一个机房内):
当今后具备两个机房的条件时,只需要将服务器与存储设备分开安装在两个机房,即可实现园区级容灾。
方案的结构图如下所示:
从镜像原理上讲,在城域SAN存储网络上的两套磁盘系统之间的镜像,和在一个机房内的SAN上的两个磁盘系统之间的镜像并没有任何区别。
我们可以看到,利用StorageFoundation,我们可以创建任意一个逻辑卷(Volume)供业务主机使用,实际上是由两个完全对等的,容量相同的磁盘片构成的,两个磁盘片上的数据完全一样,业务主机对该Volume的任意修改,都将同时被写到位于灾备机房和主机房的两个磁盘系统上。
采用这种方式,主机房的磁盘阵列与容灾中心的磁盘阵列对于两地的主机而言是完全同等的。
利用城域SAN存储网络和StorageFoundation镜像功能,我们可以非常轻松的实现数据系统的异地容灾。
并且消除了复制技术(无论是同步还是异步)的切换的动作,从而保证零停机时间,零数据损失的实现。
3.4存储容灾与系统高可用故障响应
一个完整的高可用系统,除了在数据灾难发生时,能够完成灾备的使命,需要考虑灾备系统本身的可维护性和可操作性,以及对系统尽可能快的恢复。
当单个主机或存储节点故障
对于HIS系统来说,StorageFoundationHA软件不仅实现了两数据在两个磁盘阵列上的镜像,而且配置HA的功能,能实现各种应用的切换。
同时由于HIS系统数据库部署了RAC组件,所以当任何一个主机节点出现故障时,另一个节点将继续工作,而不需要资源的切换,此时用户继续访问系统。
对于HIS的数据存储来说,由于数据镜像到两个阵列上,两个阵列是平等的,不存在主次之分,所以当任何一个存储节点发生故障时,都不存在资源切换,所有系统将继续工作。
当今后系统分散到两个机房,构成园区级容灾系统后
当主机房全部发生故障
主机房数据系统故障意味着灾难,磁盘故障,链路故障,或者数据系统的计划内停机时间,也就一切导致主机无法访问主机房数据系统的情况。
当主机房的磁盘系统发生故障(灾难)时,由于同城容灾中心的磁盘是它的镜像,所以操作系统会自动隔离主机房的磁盘,转而对容灾中心的数据进行访问。
业务系统可以通过城域SAN网络直接访问灾备机房的磁盘系统的数据,而不需要有任何针对业务系统的动作。
也就是说,主机房磁盘系统的灾难,对业务系统是透明的,应用和数据库不会因为主机房磁盘系统的故障而停止;更重要的是,因为应用和数据库不会因为灾难而异常中止,从而避免了发生数据库损坏(数据一致性风险)的可能。
值得注意的是:
整个过程对应用完全透明,不需要也不会中断业务系统的正常运行。
这是基于磁盘系统间复制技术构建的容灾系统无法实现的。
灾备机房数据系统故障以及主机房和灾备机房SAN链路故障
灾备机房数据系统故障,以及主机房到灾备机房的链路故障,我们都可以把其看成是容灾部分的故障,其原理和后果与生产中的数据系统故障相同。
都是导致了镜像的破坏。
而后,系统将自动的只与状态健康的磁盘阵列继续工作。
整个过程对应用完全透明。
故障修复后的恢复(远程镜像快速恢复)
磁盘系统故障修复之后,我们需要尽可能快的将远程镜像系统恢复起来,以确保容灾的功能继续得以实现,同时,在整个镜像恢复的过程中,势必会对应用造成影响。
因为磁盘数据的同步,一定会造成I/O的极度繁忙而导致应用性能下降,如果镜像恢复无法快速完成,其后果跟系统应用停机也非常接近了。
因此,如何快速有效的实现镜像的重新同步,同样是一个容灾方案是否成功的关键因素。
传统的镜像技术(如OS的镜像技术),在镜像链路被中断以后,中断的镜像会被认为完全作废,在链路恢复以后,我们不得不将数据完整地从主机房拷贝一份到容灾中心。
这种方式,对于用户的的应用是无法接受的。
链路方面的故障如果经常发生,我们就需要不断的重复将主机房的数据全部同步到灾备机房的磁盘系统上,实际上,这种方案不具有可实施性和可维护性,是不现实的。
这也是什么主机厂商虽然也有类似镜像功能,但不会用于容灾的根本原因。
为了解决这个问题,SymantecStorageFoundation提供了DCO+FMR技术,其中DCO(DataChangeObject)是一种针对镜像的Log技术,该技术允许StorageFoundation在镜像链路中断后记录逻辑卷的数据变化情况,以便在镜像链路恢复后,由FMR实现数据的增量恢复。
所谓FMR,其全称是FastMirrorResync,意思就是“镜像的快速再同步”,FMR是和DCO技术对应的镜像快速恢复技术,利用SymantecStorageFoundation的DCO和FMR技术,我们现在可以不用再担心容灾系统本身的可维护性了。
利用DCO和FMR,我们的应对步骤如下:
1.一切故障,导致镜像被破坏。
2.主机房的StorageFoundation利用DCO日志记录因业务数据的变化而变化的数据块。
3.一旦故障被修复,StorageFoundation的FMR功能模块,会根据DCO日志记录的情况,将链路中断后更新的业务数据(变化量)同步到灾难端实现增量更新。
4.镜像快速同步的过程中,用户的应用始终可以正常工作。
整个过程的发起,只需要执行一条命令即刻完成。
整个过程的速度,由于只是同步增量,时间远远小于整个数据系统的完全同步。
从而大大减小对用户应用的影响,这也是传统镜像技术如OS镜像所以不具备的。
3.5产品选型
针对系统
产品名称和描述
超声、病理、内镜
VRTSSTORAGEFOUNDATIONENTERPRISEHA5.1WINSTDLICEXPRESSBANDS
VRTSSTORAGEFOUNDATIONENTERPRISEHA5.1WINME112MONTHSEXPRESSBANDS
HIS系统
VRTSSTORAGEFOUNDATIONENTERPRISEFORORACLERAC5.1UNXSTDLICEXPRESSBANDS
VRTSSTORAGEFOUNDATIONENTERPRISEFORORACLERAC5.1UNXINITIALESSENTIAL12MONTHSEXPRESSBANDS
介质
VRTSSTORAGEFOUNDATIONANDHIGHAVAILABILITYSOLUTIONS5.1AIXENDVDMEDIA
介质
VRTSSTORAGEFOUNDATIONANDHIGHAVAILABILITYSOLUTIONS5.1WINDVDCSMEDIAKIT
3.6StorageFoundation技术特点
存储在线管理
在今天数据量快速膨胀的环境中,服务器和存储的重新分配已成为一项日常工作:
应用的数据增长超过了原来分配的存储容量;一些数据的价值日益增加,需要更高级的保护;需要将系统上多余的存储容量转分配给容量不足的其他系统……这些都属于存储管理的范畴。
无论出于何种原因而进行存储重新分配,通常都会导致应用程序“停机”,这对于需要保障应用程序不间断运行的管理员来说是个难题。
从业务角度来看,停用大型文件系统或数据库,以将其备份并恢复到较大设备的做法往往不可行。
即使将数据集从镜像设备直接复制到非冗余设备所需的时间也会对运营产生负面影响。
VxVM的体系结构允许数据被应用程序联机使用状态下执行重新配置操作,从而消除或至少减少重新配置存储带来的问题。
调整卷的大小既可以在应用程序需要多余空间时增加其容量,也可以在需要将未使用的存储重新部署到其他主机时减少其容量。
可以在线卷的配置,包括添加或删除镜像、增加或减少条带卷中的列数等。
VxVM可以在磁盘或LUN之间重定位条带卷的单个镜像或列。
如果怀疑存在潜在的磁盘故障,则可以使用该功能,即将数据从故障磁盘移至另一个正在使用的备用磁盘。
另外,还可以使用它将数据从旧设备迁移到新设备中。
VxVM使用存储中的空闲容量在后台执行上述所有重新配置操作。
需要注意的是,重新配置卷操作需要大量I/O,因此应谨慎地安排在生产应用程序未承担峰值负载时执行这些操作。
VxVM联机重新配置可避免停机,在执行重新配置时,即使应用程序达不到峰值性能,也完全可正常运行。
因此,联机重新配置功能解决了这一难题。
VxVM在重新配置存储时无需停止应用程序,只需在安排重新配置时,将其安排在从业务角度看可以承受任何潜在的性能下降的时间。
多层存储与在线迁移
企业使用通常与业务目的密切相关的文件来组织它们的数字信息,这些信息包括文档、事务、图像、音频曲目和其他数字业务对象,每个都具有业务价值。
因此,优化存储及I/O成本和性能的工作显然要围绕文件这个对象来展开。
企业会出于多种原因而需要控制在两个或多个存储层内放置数据对象:
■不同类型的数据具有不同I/O性能需要。
数据流需要较高的数据传输性能,但可以接受中等的I/O请求速率。
事务需要较高的I/O请求速率,但只需要中等的数据传输性能。
■同时运行的应用程序可能会争用I/O资源,除非它们的数据放置在具有单独访问路径的单独存储设备上。
■不同数据集具有不同可用性要求。
通常,企业可以在缺少人力资源系统的情况下经营业务,但却不能在缺少销售点或客户关系管理系统的情况下经营业务。
■不同数据集具有不同的价值。
丢失一天的业务事务会对企业产生明显影响,但仍可恢复正常。
丢失年度结算数字可能会带来一场灾难。
丢失一整天的工作对于视频编辑人员来说可谓损失惨重,但丢失完成的产品可能使组织遭受更大挫折。
另外,文件的合适存储类型会随着时间而变化这一事实构成了更大的挑战。
当文件变旧、变为不活动状态、增大或者缩小、或在目录之间移动时,适用于该文件的合适的存储设备类型也会发生变化。
手动在存储设备层中重定位数百万个文件会成为一项永无休止的任务。
自动化对于有效利用多个存储层是一个必要条件,特别是对于包含大量文件的文件系统。
VxFS动态存储分级(DST)包含两个部分:
多卷文件系统以及文件系统存储内基于策略的自动化文件放置。
顾名思义,多卷文件系统就是占用两个或更多虚拟存储卷的文件系统。
VxFS多卷文件系统显示单一名称空间,因此多个卷的存在对于用户和应用程序是透明的。
但是,VxFS内部仍清楚每个卷的标识,这使得管理员可以定义策略来控制单个文件的位置。
在其上构建多卷VxFS文件系统的VxVM卷也称为VxFS文件系统的卷集。
卷可能具有不同的类型(例如,条带卷、RAID-5卷、镜像卷,等等),并可能基于不同的硬件技术(如不同类型的磁盘阵列LUN和不同技术的直接磁盘挂接)。
将存储层构建在VxVM卷之上具有一个重要的优点:
出于I/O性能或容错方面的原因,卷可以具有任何
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- XXX 人民医院 SYMC 备份 技术 方案
![提示](https://static.bingdoc.com/images/bang_tan.gif)