Chinaunix首页 | 论坛 | 博客
  • 博客访问: 191024
  • 博文数量: 77
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 45
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-25 10:50
文章分类

全部博文(77)

文章存档

2018年(1)

2017年(3)

2016年(4)

2015年(4)

2014年(16)

2013年(7)

2012年(20)

2011年(22)

分类: LINUX

2011-09-02 08:40:25

一、容灾项目需要多大的投资?
  其实这个问题也可以被反问为:你希望容灾系统能达到什么效果?要想阐述清楚此问题,首先要明白两个指标:RTO和RPO。

  RTO,Recover Time Object,恢复时间指标,是指当灾难发生后,生产系统需要多长时间能够恢复生产,它是衡量企业在灾难发生后多长时间能重新开始运转的指标。

  RPO,Recover Point Object,恢复点指标,是指灾难发生后,容灾系统能把数据恢复到灾难发生前的哪一个时间点的数据,它是衡量企业在灾难发生后会丢失多少生产数据的指标。

  理想状态下,我们希望RTO=0,RPO=0,即灾难发生对企业生产毫无影响,既不会导致生产停顿,也不会导致生产数据丢失。从当前计算机技术水平来说,我们可以为用户建设这种类型的容灾系统,其中最著名的例子当属VISA和Master的结算系统,由于这两个银行结算组织占据了全球银行结算业务的重要地位,他们的结算系统不允许发生任何停顿和数据丢失的情况,即使在"911"这种极端情况下。但实现这样的容灾系统的投资巨大,它结合了存储数据复制技术、服务器操作系统镜像技术、集群技术、数据库高可用性设计、应用系统高可用性设计、同步容灾技术、异步容灾技术、同城容灾方案、异地容灾方案,以及相应的管理流程和意外事件反映处理流程等详细的规章制度,和人员配备、行政保障手段(通信、交通等),综合在一起完成一个完整的容灾方案(实际是双生产中心或多生产中心方案,并没有单纯的容灾中心)。但是这种方案的投资过于巨大,目前中国可能除了中国银联这种特殊性质的企业外,不会有太多的企业会去实现这个系统。

  因此,在电信企业BSS/OSS系统容灾系统建设中,投资规模为多少是合理的?如果业务部门能确认RTO/RPO指标,那技术部门选择了合适的容灾技术以及配套的管理流程就可以确定投资规模了。例如,如果业务部门确认,灾难发生后,3个小时内营业厅恢复生产就可以满足用户需求,且营业系统数据不能丢失,那RTO=3小时,RPO=0,那就必须选择基于存储平台数据复制技术的同步容灾方案;如果业务部门确认,灾难发生后,3天能恢复经营分析系统工作,且以前的数据丢失可以忽略不计,那RTO=3天,RPO无,那选择ATA磁盘实现异地备份,就能满足要求。

  另外需要提的是,为了百年不遇的灾难投入巨资建设一个容灾中心,容灾中心的设备在灾难发生前不能给企业带来效益,这是企业决策者很难接受的,因此如何合理分配投资,将容灾中心建设成为第二生产中心,与生产中心成为企业支持企业正常运行的双中心,并实现互为容灾,是降低总体拥有成本(TCO,Total Cost of Ownership),提高投资回报率(ROI,Return Of Investment)的一个重要措施,应该得到企业的高度重视。

二、容灾项目对生产系统性能的影响

  容灾系统的本质是将生产系统的数据以及这些数据的变化,完整地复制到容灾系统中,并通过相关技术手段,确保容灾系统中数据的完整性和一致性。容灾系统对生产数据和生产数据的变化的复制操作,必然需要与完成这些操作相对应的CPU资源(存储的CPU、或服务器的CPU)、内存资源(存储的Cache、或服务器的RAM)、网络资源(TCP/IP、FC或FICON),如果这些资源不能独立分配给容灾系统(实际上不可能独立),则必然会影响生产系统的性能。

  因此更准确的问题是,如何确保容灾系统上线后,在可以实现既定的RTO/RPO指标的同时,不会影响生产系统的正常运行?答案是可以通过技术手段实现的。

  要想实现,则必须对现有生产系统进行详细的性能分析,包括系统I/O特性(IOPS,Respond Time,读写比,I/O块大小,I/O峰值、均值,时间特性等等)、系统内各子系统业务特点、存储空间分配、服务器CPU和RAM资源的使用状况、SAN网络情况(端口使用状况、Zoning划分状况、端口IOPS等)、能够使用的数据复制链路(FC、TCP/IP、ATM、E1/E3)以及链路的QoS保障等。获得这些数据后,通过对容灾系统I/O分布的详细设计,将I/O均匀分布到更多的设备上,从而确保生产系统实现容灾后,不会造成性能下降影响正常生产的情况出现。

三、容灾不能替换备份

  容灾系统会完整地把生产系统的任何变化复制到容灾端去,包括不想让它复制的工作,比如不小心把计费系统内的用户信息表删除了,同时容灾端的用户信息表也会被完整地删除。如果是同步容灾,那容灾端同时就删除了;如果是异步容灾,那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统中取出最新备份,来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。

  反过来,建设了备份系统,是否就不需要容灾系统?这还要看业务部门对RTO/RPO指标的期望值,如果允许RTO=14天,RPO=1天,那备份系统就能满足要求。不过,可要考虑清楚了:从磁带上恢复50TB的数据,并要确保数据完整恢复回数据库,是否能在2周内完成?

四、选择什么容灾技术能保证项目实施成功?

  容灾项目实施成功,与技术关系不大。能举出成功案例的容灾技术,则必有它的可行性。但作为一个工程师,除了考虑项目的可行性外,还要考虑项目的不可行性。任何技术的实现,都有它的制约条件。在自己的生产环境中,能否避免这些制约条件的出现?或者出现后,是否有资源可以解决它?

  比如ORACLE在中国实施了一个基于DataGuard的容灾方案,但在实施过程中出现了大量意想不到的问题和BUG,作为对中国电信客户的重视,ORACLE甚至派遣R&D人员到现场编制PATCH以保证项目能实施,但这种资源,是否每个客户都能向ORACLE索取?

  因此,选择一个简单的容灾方案,并选择一个曾经成功实施过该方案的工程团队,才是确保容灾项目实施成功的关键。
本文转载自:http://tote.itpub.net/category/28921/45900
阅读(537) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~