解析中型企业灾难恢复的实用策略

  

 【WatchStor独家译稿】当灾难发生的时候,IT部门最好是有所准备的,因为业务依赖于管理业务的信息和技术。然而对于中型企业来说,规划和配置灾难恢复一直都是具有争议的话题。大型企业有专门的灾难恢复系统来挑选,小型企业往往可以通过特有的措施来应对灾难,而中型企业就身处于夹缝之中——既买不起庞大的灾难恢复系统,离线磁带又不能满足他们的需求。

不管卡特里娜飓风或者最近让服务器中断工作的停电事故是否还让我们印象深刻,CEO们都越来越关注灾难恢复问题。在我们的研究调查中,79%的中型企业表示他们已经制定了业务连续性计划;42%企业的技术层还没有意识到可能阻碍灾难恢复规划的因素。然而,众多企业在恢复速度方面也各不相同:35%的企业表示他们在几天时间就可以恢复正常运作;28%的企业可能需要几周的时间。

中型企业要想加强对灾难的准备措施,就应该采用那些能够彻底改变他们灾难恢复现状的新技术,而且还需要花时间分类应用和管理恢复流程。基本问题是,哪些应用是业务运行必需的、企业能够承担多少数据的丢失以及能够接受多长的等待恢复时间。

例如,一个CAD系统可能对一家企业来说非常重要,但是在发生洪水或者龙卷风的时候,夜间磁带备份或者每星期一次的服务器重建就已经足够工程师恢复任何丢失的工作。在发生局部灾难的时候,他们完全不必为无法找回最近的设计资料而担心。区域因素也能起到不同的作用,如果一家公司在不同地区设置分支机构,那么他们更倾向于选择站点之间的数据复制,虽然灾难事故的发生会降低他们整体的生产率,但是几乎没有任何信息的丢失。

关键的管理措施

有两个需要规划的关键数据,一个是恢复点目标(或称RPO),另一个是恢复时间目标(或称RTO)。RPO指的是业务系统所能容忍的数据丢失量。在上面我们举的那个CAD例子里,也许丢失了大约一天的数据量,因为备份只是在晚上进行的。对于一个电子邮件系统,企业也许能接受的是一个小时的数据量,而对于一个交易处理系统,丢失任何数据都是不能接受的。

恢复时间目标指的是所能容忍的业务停止服务的最长时间。也许让那个CAD系统停止工作一个星期没什么事,但是电子邮件系统就不行了。在这里,系统本身的RTO和其中数据的RTO是不同的。如果电子邮件系统正在运行——2/3的企业在他们的灾难计划中都仍有通信——即使没有后端的电子邮件文件,员工也可能会丢失已经完成了的有效工作。交易处理系统则需要在几分钟之内恢复运转。

IT部门不能凭空决定系统的RPO或者RTO,他们需要对用户进行调查研究,就中断时间和丢失数据的价值咨询负责相关业务的经理以及高管。当部署一个应用的时候,不仅仅需要考虑它的备份策略,还必须考虑设定不同的RPO和RTO。例如,一个RPO和RTO值较低的交易处理型电子商务系统最理想的是选择托管,这样就有冗余的因特网和能源网络连接、发电器以及适当的安全性,而这些项目都是许多中型企业数据中心无法独立承担的。一些中型企业,尤其是位于旧金山和Gulf Coast等地区,都是使用托管设备来满足他们数据中心需求,然后使用他们的本地站点来实施灾难恢复备份。

如果企业希望将RPO从几小时减少到几分钟,他们他们需要实时地将写入请求复制到他们灾难恢复站点的副本库中。现在市场中有很多可供选择的复制产品,每款产品都是以在成本、带宽需求、RPO以及易于管理性之间取得最佳平衡为目的设计的。现在最常见的三种数据复制方法是:同步、异步和快照。

同步复制系统是先对每个写入请求进行复制,然后将副本发送到主数据站点以及二级数据站点中,他们需要等待交易完毕才能完成两个站点的写入。这么做可以将RPO降低为零,但是成本是很高的,而且如果设计不得当的话,这种产品将可能会大大削弱应用的性能。一般只有大型企业机构会采用这种系统,而且使用的是暗光纤或者其他高性能网络。

异步复制也可以将RPO降低为零,不过这种方法不需要等待每个写入请求在本地或者远程数据中心的通过。另外还需要管理和优化方面的技巧将带宽利用将至最低。

快照复制则是在存储层级实施的,是在一定的时间间隔内传输被修改的数据块。这种系统占用的带宽更少,而且不需要应用识别功能。虽然基于SAN的系统是数据复制的最理想选择,但它的成本是大多数中型企业不能接受的。

中型企业越来越青睐基于主机或者基于应用的复制策略以及基于服务器虚拟化的系统。不仅价格更低,而且虚拟化技术能够大大减少启动灾难恢复站点所需的时间和设备。【WatchStor独家译稿未经许可禁止转载,合作伙伴请注明文章出处为WatchStor.com】

 

作者:WatchStor编译

来源:51CTO

时间: 2024-10-31 07:24:00

解析中型企业灾难恢复的实用策略的相关文章

外链之六大最强最实用策略(下篇) 偏门外链

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 这个月是一个看起来很普通但是又不普通的一个月,为什么说不普通呢,因为这个月时我们北京互动SEO论坛三岁的生日.我们要给他过的隆重点.写这编文章就是给送给论坛三个月来一起和我们度过风雨的论坛新来会员的对我们的支持的感谢!礼品小了点.别见怪哦!呵呵. 上次我在A5发了一编文章叫做"外链之六大最强最实用策略(上篇)"很明显的就有

成功运营地方门户实用策略浅析

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 运营网站最头疼的阶段就是网站的发展阶段,从建站到盈利这个阶段是非常折磨人的,甚至有的人受不了这种折磨,远离网络的人也是有不少的,现在还是有不少人非常羡慕那些成功站长,认为他们赚钱就像是在数钱,非常的惬意,可是在运营网站的初始阶段,那种努力工作,通宵达旦却是经常的事情,还要受到各个方面的压力,所以如果大家想要真正成为成功的站长,你一定要准备这个

打破传统 解析云计算灾难恢复新策略

涉及到灾难恢复,大多数人的概念还停留在传统的离线灾难恢复中.而如今随着云计算灾难恢复的发展,不少人对传统离线的灾难恢复和云计算中的灾难恢复这两个概念仍然存在着混淆.弄清楚其中的差异与恢复需求是维持一个固定灾难恢复策略的第一步.下面就来谈一谈云计算灾难恢复作为一种新技术与传统灾难恢复的差别. 无论是否是在云计算中实施灾难恢复,一个成功灾难恢复计划所包含的要素都是相同的: 1.用于灾难的计划 2.记录你的计划 3.测试你的备份文件 4.修正任何存在的问题 5.再次测试,以确保你已解决了所有的问题 6

BitBucket引入灾难恢复和合并策略

最近发布的BitBucket Server和BitBucket Data Center 4.9让定义灾难恢复策略及设置首选合并策略等成为可能. BitBucket Data Center通过将一个BitBucket Server主实例复制到一个"冷备"实例实现灾难恢复支持,这两个实例可以处于不同的地理区域.为了实现灾难恢复,BitBucket的典型部署是,让多个BitBucket节点处于"冷"状态,而共享的文件服务器和数据库处于"热"状态,这样,

解析绿萝算法应对策略和处理方法

2013年伊始,百度又进行了算法的升级,2月19日发布绿萝算法,2月20日晚就进行了大规模的更新.从目前得到的数据来看,行业内一些导出链接过多.友情链接不相关的网站确实受到了一定的影响.由此,联创网络来探讨一下关于绿萝算法的应对策略和中伤后的处理方法. 百度本次调整是针对购买链接的站点进行惩罚,最后演变成了页面过多链接的惩罚.这里所说的,够买链接的站点和页面过多链接的惩罚有着不同的角度.购买链接的人,不一定会把所有购买的链接都指向首页,而是进行分散到各个带有流量词的页面.而百度惩罚的是某一个页面

解析网站产品移动化策略制定过程

当下,移动互联网正随着智能手机和平板电脑的不断推出更新受到追捧,SoLoMo(SocialLocalMobile)概念的提出更将移动互联网作为互联网未来发展的重要方向.在这种情况下,Web网站 作为线上内容及服务的提供者是否应该跟进移动化?网站该如何布局移动化策略?策略该如何实施?下面我们一起来探讨一下. 要想回答是否应该跟进移动化,首先取决于需求,包括用户需求和网站需求.用户需求指用户有迫切需求通过移动设备获取网站信息或服务,比如新浪微博用户就有很强的需求使用移动设备使用微博服务,而OA系统的

ASP.NET技巧:请求网址并解析返回的html_实用技巧

目的,把远程服务器传回的Html,解析到类里面,为GridView等提供数据源 1 .向远程服务器Post数据 public int PostData(string url, string data, out string info)        {            info = "";            CookieContainer cc = new CookieContainer();            HttpWebRequest request = WebRe

解析网站营销部署与营销策略

中介交易 SEO诊断 淘宝客 云主机 技术大厅 俗话说"窈窕淑女,君子好求",倘若一位面容姣好的女子自卑闺中,何来何以引来君子?上周在CnBeta看到一篇<国内免费网盘横向评测>的文章,(见http://cnbeta.com/articles/92048.htm),意外发现这篇文章被众多网站转载,截至发稿,在搜索引 擎上可以看到30,000多条关于这篇文章的记录.在这个数据的驱使下,我做了一翻调查,结果发现是一次有谋略的营销计划,故整理成文,与大家分享. 众所周知,营销方式

Apache Spark源码走读(七)Standalone部署方式分析&amp;sql的解析与执行

<一>Standalone部署方式分析 楔子 在Spark源码走读系列之2中曾经提到Spark能以Standalone的方式来运行cluster,但没有对Application的提交与具体运行流程做详细的分析,本文就这些问题做一个比较详细的分析,并且对在standalone模式下如何实现HA进行讲解. 没有HA的Standalone运行模式 先从比较简单的说起,所谓的没有ha是指master节点没有ha. 组成cluster的两大元素即Master和Worker.slave worker可以有