IT容灾系统设计的级别与层次

简介:

一、

容灾从保障的程度上一般分为三个级别:数据级、系统级、业务级。
数据级别容灾的关注点在于数据,即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏。数据级容灾与备份不同,它要求数据的备份保存在异地,也可以叫异地备份。初级的数据容灾是备份的数据人工方式保存到异地;高级的数据容灾是建立一个异地的数据中心,两个数据中心之间进行异步或同步的数据同步,减少备份数据与实际数据的差异。数据级别容灾是容灾的基本底线,因为要等主系统的恢复,所以也的恢复时间最长的一种容灾方式。
  系统级容灾是在数据级容灾的基础上,再把执行应用处理能力 ( 业务服务器区 ) 复制一份,也就是说,在备份站点同样构建一套支撑系统。系统级容灾系统能提供不间断的应用服务,让用户应用的服务请求能够透明地继续运行,而感受不到灾难的发生,保障系统的服务的完整、可靠、安全。
  数据级容灾和系统级容灾都是在 IT 范畴之内,然而对于正常业务而言,仅 IT 系统的保障还是不够的。有些用户需要构建最高级别的业务级别容灾。业务级容灾的包括很多非 IT 系统,比如电话、办公地点等。当一场大的灾难发生时,用户原有的办公场所都会受到破坏,用户除了需要原有的数据、原有的应用系统,更需要工作人员在一个备份的工作场所能够正常地开展业务。实际上,业务级容灾还关注业务接入网络的备份,不仅考虑支撑系统的服务提供能力,还考虑服务使用者的接入能力、甚至备份的工作人员。

二、容灾系统的层次

容灾是为了灾难后的服务恢复,而容灾后恢复到原系统的程度取决于数据备份的方式,也就是主备系统的同步程度,参照IBM公司对容灾解决方案的七层理论,我们进行了分析与整理,并做了适当的简化,从国内实用化的角度,针对IT容灾系统的设计,把容灾系统从恢复的层度上分为六个层次:
1)         一层:有数据备份,无备用系统
属于数据级别的容灾。将备份的数据定期人工存放到异地,离线存储。当灾难发身时,采用新的一套IT支撑系统,将备份的数据恢复后继续提供服务支撑。
2)         二层:有数据备份,有备用系统,没有网络连接
建立了系统的容灾的,但主备系统之间没有网络连接,将备份的数据人工存放在备份系统。当灾难发生时,启动备份系统,恢复到最新备份的数据就可以提供服务。这比上一层方式减少了重新寻求系统的环节,也增加了系统提供服务能力的保证。
3)         三层:主备系统有网络连接,异步存储连接
在主备系统之间建立网络连接,采用存储系统自动备份技术,自动进行数据的备份处理,可以节省人工备份的工作,同时也可以提高备份的速度与减小备份的时间天窗。当灾难出现时,备份系统可以自动成为主系统提供服务。
当时系统的数据量比较大时,远程备份数据的速度不能作到与实际系统同步,所以出现了异步备份方式与同步备份方式。本层容灾实现的是异步备份,一般是定期地把备份数据送往备份系统。两次备份的时间差称为备份天窗,也就是若灾难发生时,数据损失的最大时间长度。
4)         四层:主备系统有网络连接,同步存储连接
为了减小备份的天窗,就必须加快备份,但存储的容量一般都很大,备份时对系统的效率影响很大,为了不影响实际业务的服务,存储厂家采用快照的方式增量备份,就先做一个基础的全部备份,在对数据变化的定期产生空间快照Snapshot,只对快照备份,备份的天窗就小多了。
随着备份天窗的缩小,主备数据之间的差异减小,这对误操作、病毒修改等异常情况对数据的破坏就产生负面影响,所以在建立本层容灾的同时,在主系统另外建立本地数据备份机制是必要的。
5)         五层:业务同步写入
在存储层次的容灾备份,总是要把存储空间复制到异地,主备总有时间差,备份天窗不可能为零。业务服务的过程是业务处理进程把结果数据提交给存储系统,存储系统再存储到物理磁盘上。存储备份就是存储系统再把要备份的数据从磁盘上读出,写到备份系统中。若是业务处理进程在提交数据的同时,把数据也提交给备份系统,那么就可以实现主备系统的数据同步化,这就是业务同步写入,数据的同步更新。本层次可以实现数据备份天窗为零。
同步写入的实现方式有多种:一是业务系统直接把数据提交给主与备的数据库系统,同时成功才为写入成功,读出时从主系统读出就可以。二是业务系统只提交给主系统数据库,数据库在写入本系统时,把数据的操作日志直接给备份系统,在备份系统上执行同样的数据库操作。
6)         六层:业务系统同步工作
主备系统的特点是主系统工作,备系统备用,不直接接受业务。若主备系统同时接受业务数据,同时进行业务处理,但备用系统不输出给用户。主备系统之间有单独的“心跳”连线,同步主备系统内部的“工作环境”,这种方式实际就是异地的双机热备。当灾难发生时,备系统直接延续主系统提供服务。本层次可以实现接近“零延迟”的业务切换,但用户的业务需要重新连接,业务系统没有提交的业务要重新提交,对用户来说,业务不会因为灾难而损失。




本文转自 zhaisj 51CTO博客,原文链接:http://blog.51cto.com/zhaisj/40986,如需转载请自行联系原作者
目录
相关文章
|
25天前
|
监控 Java 数据库
揭秘Java性能调优的层次 | 综合多方向提升应用程序性能与系统高可用的关键(架构层次规划)
揭秘Java性能调优的层次 | 综合多方向提升应用程序性能与系统高可用的关键(架构层次规划)
36 0
|
6月前
|
SQL 监控 安全
架构设计第五讲:数据巡检系统的设计与应用
架构设计第五讲:数据巡检系统的设计与应用
135 0
|
3月前
|
数据采集 设计模式 架构师
|
9月前
|
存储 缓存 运维
|
11月前
|
存储 IDE 数据可视化
【架构治理】在代码存储库中记录软件架构
【架构治理】在代码存储库中记录软件架构
|
11月前
|
测试技术
【系统架构】可靠性测试用例设计时重点考虑的特殊情况
【系统架构】可靠性测试用例设计时重点考虑的特殊情况
81 0
|
运维 安全 开发工具
系统之业务设计原则
系统之业务设计原则
79 0
|
存储 缓存 运维
系统稳定性设计原则:简单、冗余、标准化、健壮
系统稳定性设计原则:简单、冗余、标准化、健壮
545 0
系统稳定性设计原则:简单、冗余、标准化、健壮
|
运维 监控 数据可视化
架构设计60-落地原则02-故障隔离(故障的传播方式与隔离办法)
架构设计60-落地原则02-故障隔离(故障的传播方式与隔离办法)
492 0
架构设计60-落地原则02-故障隔离(故障的传播方式与隔离办法)
产品设计-服务拓扑关系-apm-基础设施-paas-产品设计-调用关系-性能
产品设计-服务拓扑关系-apm-基础设施-paas-产品设计-调用关系-性能
71 0
产品设计-服务拓扑关系-apm-基础设施-paas-产品设计-调用关系-性能

热门文章

最新文章