容灾技术介绍和IBM容灾方案

容灾方案第14页共79页容灾技术介绍和IBM容灾方案TIME\@"yyyy'年'M'月'd'日'"2022年4月17日目录容灾方案 11 信息——企业的财富与麻烦 61.1 前言 61.2 IT大集中－把蛋都装进篮子里 71.3 容灾－覆巢之下，亦有完卵 82 容灾概述 102.1 概述 102.2 容灾的实质是确保永不停顿的业务运营 132.3 容灾的IT实现 172.3.1 容灾的7个层次 192.3.2 容灾的业务恢复时间段 212.3.3 容灾所涉及的恢复技术 223 容灾方案分析 253.1 业务连续性开发模式 263.1.1 阶段一、灾难类型分析（风险分析） 273.1.2 阶段二、业务冲击分析 273.1.3 阶段三、企业容灾环境分析 293.1.4 阶段四、容灾策略制订 293.1.5 阶段五、容灾方案设计 303.1.6 阶段六、业务连续性流程设计 313.1.7 阶段七、业务连续性流程及容灾方案管理和测试 313.2 七层灾难恢复解决方案 323.2.1 恢复的7个层次 323.2.2 细述7个层次 333.3 如何选择最优的灾难恢复方案 393.3.1 四个关键目标 403.3.2 方案成本与业务停止带来的损失 403.3.3 与系统体系结构的关系 414 容灾系统的设计过程 444.1 灾难恢复计划描述 444.2 灾难恢复计划项目阶段 454.3 数据收集和关键需求分析阶段 504.4 风险分析阶段 524.4.1 风险管理过程 524.4.2 商业影响分析 534.4.3 建立可靠的系统 544.5 数据保护阶段 544.6 恢复阶段 544.7 测试和培训阶段 554.8 维护和修改阶段 564.9 选择灾难恢复方案的步骤介绍 575 典型方案介绍 615.1 基于软件的数据备份技术 615.2 HACMP高可靠性灾备方案 655.2.1 HACMP方案 665.2.2 HACMP/XD 675.3 基于磁盘系统的PPRC数据级容灾解决方案 695.3.1 同步PPRC数据级灾难备份方案 715.3.2 异步PPRC数据级灾难备份方案 726 容灾方案演示环境 77图表目录TOC\h\z\t"附图标题"\c附图1. 停机原因分析－北美 10附图2. 灾难备份方案选择标准 19附图3. 容灾的7各层次 21附图4. 容灾的业务恢复时间段 22附图5. 数据复制技术 24附图6. 灾难备份项目实施过程 27附图7. 风险分析 27附图8. 业务冲击分析曲线 28附图9. 容灾环境分析 29附图10. 容灾策略制订 30附图11. 容灾方案层次 30附图12. 容灾组织架构图 31附图13. 三者的平衡关系 32附图14. 灾难恢复的层次划分 33附图15. 四个关键目标 40附图16. 成本时间窗口 41附图17. 高可用系统的构成因素 41附图18. 灾备计划不同阶段图表 46附图19. 事件间流程 53附图20. 风险分析示例 53附图21. 问题模型 58附图22. 灾备恢复方案矩阵 59附图23. 方案评估矩阵 60附图24. HDR工作原理1 62附图25. HDR工作原理2 62附图26. 63附图27. 数据复制工作原理 63附图28. 同步、异步数据更新 64附图29. HACMP/XDPPRC方案 67附图30. HAGEO集群 68附图31. 同步远程拷贝 69附图32. 异步远程拷贝 70附图33. 全局镜像 70附图34. 71附图35. PPRC同步实现机制 72附图36. ESS的FlashCopy的使用 73附图37. FlashCopyCOPY选项 74附图38. 75附图39. 76附图40. 基于磁盘系统的PPRC数据级灾难备份解决方案典型应用环境拓扑图 77信息——企业的财富与麻烦前言1958年，BillGore和他的太太VieveGore在美国特拉华州Newark市，自己家里的地下室成立了Gore公司。1969年，Gore公司研制成功独特的，具有防风、防水、透气功能的GORE-TEX面料并广泛应用于生产具有功能性、保护性和时尚感的服装和鞋类产品。目前，Gore公司已成为一家在全球拥有6000多名员工、40多间加工厂的跨国公司，并在氟材料的技术研究和应用领域始终占据世界领先地位。对于Gore这样的以研发新型材料作为企业动力的公司而言，材料的研发过程记录、研发历史数据、研发结果数据是企业最可宝贵的财富。请假设这样一种情况，如果这些数据在一次事故中全部丢失，Gore公司会蒙受多么大的损失？1983年，当个人电脑还处于萌芽期的时候，美国青年戴尔成立了自己的个人电脑公司，主要销售IBM的旧电脑和自己组装的品牌电脑。那是一个电脑群雄激烈厮杀的年代，当行业的领导者们争相以引人注目的技术推出计算机时，戴尔注意到了平凡的供应链。戴尔公司利用信息技术全面管理公司生产过程。通过互联网，戴尔公司和其上游的配件制造商能够对客户的定单迅速地做出反应：当定单传至戴尔的控制中心时，控制中心把定单分解为一个个子任务，并通过网络分派给各独立配件制造商进行生产。各制造商按照戴尔的电子定单进行生产组装，并按照戴尔控制中心的时间表来供货。戴尔所需要做的只是在成品车间完成组装和系统测试，剩下的就是客户服务中心的事情了。“经过优化后，戴尔供应链每20秒钟汇集一次定单”，“平均库存时间仅有7小时”。虽然没有傲视群雄的杰出技术，现在的戴尔公司却已成长为一个年销售额达410亿美金的企业。对戴尔公司来说，市场信息的获取、物流信息的传递以及合作伙伴的信息交换，这些共同构成了拉动企业正常运转的信息链。如果有一天，一场意外的事故导致供应链的崩裂，戴尔该如何面对客户恼怒的面容和企业直线下滑的利润？信息，作为企业宝贵的资源，其重要性已经得到了人们的充分认识。但是我们该如何保护这一资源？假设您就是某企业的一位高级管理人员，当您的企业遭遇以下事故时，您将如何去面对：1．某一天，证券公司的交易数据因操作失误而损坏；2．某一天，保险公司的所有保单数据因电源故障而丢失；3．石油勘探公司辛苦一年获取的地质数据因人为的恶意操作而丢失；4．医院保存的所有病历因为磁带的损坏而无法使用；……这样的例子还有很多很多。那么这样的事故所带来的后果是什么？至少，很难想象这个不幸的企业还能毫发无损的健康生存。因为，对于信息时代的企业而言，健全的信息往往是维持其运转所必须的基本条件。所以，如何保护企业的信息资源，如何使企业免遭信息灾难，已经成为企业所必须考虑的沉重问题。IT大集中－把蛋都装进篮子里在计算机应用的早期，是大型主机一统天下的时代。这是一种高度集中的信息应用模式。昂贵的计算机和同样昂贵的存储设备躲藏在幽深的机房里，客户仅能依靠哑终端与主机进行交互，以完成自己的工作。随着IT设备的降价和网络技术的发展，客户机/服务器体系结构和浏览器/服务器体系结构这样的信息应用模式应运而生。这两种全新的信息应用模式，降低了用户进入计算机应用系统的门槛，推进了计算机应用在现代社会的全面普及，并产生了今天计算机应用分布式存在和数据存储分布式存在的局面。合久必分，分久必合。随着网络速度的进一步提高以及高速存储设备的降价，高速信息交换、大容量存储等困扰IT人员多年的问题基本得到了解决。同时，过于分布的应用和数据所导致的日益昂贵的维护和运营费用，已经给大型企业的发展带来了束缚。于是，大集中的号角重新吹响。目前，在银行信息化领域，数据大集中已经成了一个热门的话题。在国内，中国工商银行在2000年就前瞻性地启动了数据大集中工程，并在2002年完成了全部工程的建设。现在，中国工商银行已经将分布在全国各地的四十多个数据中心整合为互相连接、互为备份的北京、上海两大数据中心，建成了全行统一的计算机系统平台。同时，国内的其它银行和大型证券公司也纷纷迎头赶上。大集中已经成为包括银行、证券、保险等行业在内的整个金融信息化发展的大趋势。鉴于信息资源对于企业的宝贵作用，我们不妨把它们比作一枚枚金蛋，而信息基础设施就是用来装这些金蛋的篮子。过去，不同的金蛋分布在不同地域的篮子里，而大集中所带来的信息基础设施整合则意味着我们将把越来越多的金蛋放进同一个篮子。此刻，一个不得不考虑的问题出现了：如果这个篮子翻了，怎么办？覆巢之下，岂有完卵？容灾－覆巢之下，亦有完卵2001年9月11日，美国世贸中心双子大厦遭受了谁也无法预料的恐怖打击。灾难发生前，约有350家企业在世贸大厦中工作。事故发生一年后，重返世贸大厦的企业变成了150家，有200家企业由于重要信息系统的破坏，关键数据的丢失而永远的关闭、消失了。其中的一家公司称，自己要恢复到灾难前的状态需要50年的时间。2003年，当AT＆T无线试图对Siebel客户关系管理（CRM）软件进行升级的时候，原定一个周末就能完成的项目演变为一场历时六个星期的灾难。这次CRM软件的升级使AT＆T无线损失了1亿多美元，仅增加的用户欠款、员工加班费和承包商的佣金就高达7500万美元。此外，技术故障也导致该公司去年第四季度的新增用户数急降82％。而其损失并不仅限于这些，AT＆T无线对分析师发布警告称：“2004年上半年的用户退网率将进一步增加。”2003年，国内某电信运营商的计费存储系统仅发生了两个小时的故障，就造成400多万元的损失。这些尚不包括对公司声誉的影响所导致的无形资产流失。这些灾难的发生或许是偶然而难以预料的，但是，对灾难的预防却绝对不应该是一个偶然的话题。据IDC的统计数字表明，美国在2000年以前的10年间发生过灾难的公司中，有55%当时倒闭。剩下的45%中，因为数据丢失，有29%也在两年之内倒闭，生存下来的仅占16%。国际调查机构GartnerGroup的数据表明，在由于经历大型灾难而导致系统停运的公司中，有2/5再也没有恢复运营，剩下的公司中也有1/3在两年内破产。美国德克萨斯州大学的调查显示：“只有6%的公司可以在数据丢失后生存下来，43%的公司会彻底关门，51%的公司会在两年之内消失。”另一份针对这一课题的研究报告也显示：在灾难之后，如果无法在14天内恢复信息作业，有75%的公司业务会完全停顿，43%的公司再也无法重新开业，20%的企业在两年之内被迫宣告破产。美国明尼苏达大学的研究也表明，在遭遇灾难的同时又没有灾难恢复计划的企业中，将有超过60%在两到三年后退出市场。而随着企业对数据处理依赖程度的递增，此比例还有上升的趋势。灾难的发生对企业的打击往往是致命的。但是，面对灾难，企业就真的不堪一击吗？答案是否定的！同样是令人恐怖的“9.11”，世贸大厦倒塌后，在世贸大厦租有25层的金融界巨头摩根斯坦利公司最为世人所关注。但是事发几个小时后，该公司宣布：全球营业部可以在第二天照常工作。这都是因为该公司建立的数据备份和远程容灾系统，它们保护了公司的重要数据，在关键时刻挽救了摩根斯坦利，同时也在一定程度上挽救了全球的金融行业。这一独特的例子说明了什么？它说明拥有先知先觉的防范意识和充分的技术准备，即使是在突如其来的覆巢之灾下，亦有完卵，亦有企业的一线生机。因此，预防灾难的发生，充分考虑灾难发生后的快速恢复手段，成为现代企业的一门必修课。其实，在这一问题上，中国古代的智者早就提出了自己的观点：生于忧患，死于安乐。无论是对一个国家，还是一个企业，都是如此。容灾概述概述常言道，“知己知彼，百战不殆”。要实现容灾，首先要了解我们的“敌人”－灾难。那么，哪些事件可以定义为灾难呢？典型的灾难事件是自然灾难，如火灾、洪水、地震、飓风、龙卷风、台风等，还有其它如原先提供给业务运营所需的服务中断，如设备故障、软件错误、电信网络中断和电力故障等等。此外，人为的因素往往也会酿成大祸，如操作员错误、破坏、植入有害代码和恐怖袭击。现阶段，由于我国很多行业正处在高速发展的阶段，很多生产流程和制度仍不完善，加之缺乏经验，这方面的损失屡见不鲜。事实上，我国2003年遭遇的“非典”，某种意义上也是灾难。对此，我们认为需要做到两点：一是建立切实可行的应急机制，这主要包含一套基于充分且清楚地将风险予以分类定义的业务持续计划，二是在危机突然降临时，此计划能被有效执行。对于IT系统，除了上述的灾难之外，与系统相关的计划外宕机也可视作灾难（见图1）。停机原因分析－北美自“9.11”之后，全球各企业均认识到灾难防范保护的重要性。某些大型金融机构之所以能够在两天内恢复营业，其主要原因是它们不仅象一般公司那样在内部进行数据备份，而且在数英里外的数据备份中心也保留着数据备份。这些备份都是通过数据备份软件和数据复制软件进行的。采取了这种措施后，一旦工作现场发生意外，企业就可以立即使用另一套数据。华尔街的金融机构重新对灾难恢复的步骤做了评估，并认识到灾难恢复只是技术手段之一，它们开始强调BusinessContinuity-业务连续性而不仅仅是DisasterRecovery-"灾难"恢复。因为过去的"灾难"恢复计划并没有强调全局性及对整个市场的影响，而如何维持业务的连续运作将成为企业运营风险评估中至关重要的一环。事实证明，只有对数据存储备份制定完备、持续且可执行的容灾计划，特别是业务连续计划，才能为人们提供万无一失的数据安全保护。严格的说，容灾计划包括一系列应急计划，如业务持续计划（BCP-BusinessContinuityPlan），业务恢复计划（ERP-BusinessRecoveryPlan），运行连续性计划（COOP-ContinuityofOperationsPlan），事件响应计划（IRP-IncidentResponsePlan），场所紧急计划（OEP-OccupantEmergencyPlan），危机通信计划（CCP-CrisisCommunicationPlan），灾难恢复计划（DRP-DisasterRecoveryPlan）等等。业务持续计划（BCP）它是一套用来降低组织的重要营运功能遭受未料的中断风险的作业程序，它可能是人工的或系统自动的。业务持续计划是高层管理人员的首要职责，因为他们被委任于保护公司的资产及公司的生存。业务持续计划的目的是使得一个组织及其信息系统在灾难事件发生时仍可以继续运作。为了能对灾难事件有适当的对策，严密的计划及相关资源的投入是必须的。业务恢复计划（BRP）它也叫业务继续计划，涉及紧急事件后对业务处理的恢复，但与BCP不同，它在整个紧急事件或中断过程中缺乏确保关键处理的连续性的规程。BRP的制定应该与灾难恢复计划及BCP进行协调。BRP应该附加在BCP之后。操作连续性计划（COOP）COOP关注位于机构（通常是总部单位）备用站点的关键功能以及这些功能在恢复到正常操作状态之前最多30天的运行。由于COOP涉及到总部级的问题，它和BCP是互相独立制定和执行的。COOP的标准要素包括职权条款、连续性的顺序和关键记录和数据库。由于COOP强调机构在备用站点恢复运行中的能力，所以该计划通常不包括IT运行方面的内容。另外，它不涉及无需重新配置到备用站点的小型危害。但是COOP可以将BCP、BRP和灾难恢复计划作为附录。危机通信计划（CCP）机构应该在灾难之前做好其内部和外部通信规程的准备工作。危机通信计划通常由负责公共联络的机构制定。危机通信计划规程应该和所有其它计划协调，以确保只有受到批准的内容公之于众，它应该作为附录包含在BCP中。通信计划通常指定特定的人员作为在灾难反应中回答公众问题的唯一发言人。它还可以包括向个人和公众散发状态报告的规程，例如记者招待会的模板。计划（IRP）事件响应计划建立了处理针对机构的IT系统攻击的规程。这些规程用来协助安全人员对有害的计算机事件进行识别、消减并进行恢复，这些事件的例子包括：对系统或数据的非法访问、拒绝服务攻击、或对硬件、软件、数据的非法更改（如有害逻辑：病毒、蠕虫或木马等）。本计划可以包含在BCP的附录中。灾难恢复计划（DRP）正如其名字所表示的，DRP应用于重大的、通常是灾难性的、造成长时间无法对正常设施进行访问的事件。通常，DRP指用于紧急事件后在备用站点恢复目标系统、应用或计算机设施运行的IT计划。DRP的范围可能与IT应急计划重叠，但是DRP的范围比较狭窄，它不涉及无需重新配置的小型危害。根据机构的需要，可能会有多个DRP附加在BCP之后。场所紧急计划（OEP）OEP在可能对人员的安全健康、环境或财产构成威胁的事件发生时，为设施中的人员提供反应规程。OEP在设施级别进行制定，与特定的地理位置和建筑结构有关。设施OEP可以附加在BCP之后，但是独立执行。BCP关注在中断期间和之后维持机构的业务功能。业务功能的一个可能的例子是工资的支付处理或客户的信息处理。BCP可以专门为某个特定的业务处理编写也可以涉及到所有关键的业务处理。IT系统在BCP中被认为是对于业务处理的支持。在某些情况下，BCP可能没有涉及到对过程的长期恢复并使其回到正常运行状态，而只是包含过渡的业务连续性需求。灾难恢复计划、业务继续计划和场所紧急计划可以附加在BCP之后。在BCP中设定的职责和优先顺序应该和其在操作连续性计划（COOP）中的一致以消除可能的冲突。按一般惯例，备用站点维持机构（通常是总部）要支持长达30天的运行，直到整个系统恢复到正常状态，COOP正是为了达到这个要求而制定的。BCP涉及到在重大中断期间和之后维持业务处理所需的业务功能和IT系统。BRP记录了机构在备用站点进行业务处理的持续规程。与BCP不同，BRP不涉及在紧急事件期间对关键处理的连续性维持。DRP是指设计用于重大和通常是毁灭性灾难之后的目标系统、应用程序或计算机设施的恢复，它是以IT为主的计划。两个计划都提供了IT系统的恢复和继续规程。由于包括了对无需重新部署到备用站点的小型中断进行系统恢复的规程，所以这类计划比DRP的范围更广泛。计算机事件响应计划建立了使安全人员可以确定、防止和恢复针对机构IT系统进行的计算机攻击的规程。OEP则提供了在人员的健康和安全以及环境或财产等受到威胁的紧急情况下，设施工作人员所遵循的指导方针。计划的制定者之间必须进行协调以确保各自的策略和规程能够互为补充，必须将所有有关计划、系统和处理的变化情况反馈给系统和相应处理计划的制定者。容灾的实质是确保永不停顿的业务运营让我们来看一个真实的故事：FredAlger基金管理公司的总部设在世贸中心北楼的93层。在上个世纪90年代，FredAlger曾是美国业绩最好的一家基金管理公司。它旗下的“光谱共同基金”（Spectramutualfund）的年均收益率曾达到让人惊羡的29%。然而，公司2000年的业绩大幅下滑，其前景不容乐观。2001年9月11日上午发生恐怖袭击后，该公司正在上班的35人全部遇难，老板DavidAlger也在其中，这对FredAlger公司来说无疑是灭顶之灾。所幸的是，该公司居安思危，在繁荣期建设的IT系统早早就考虑到容灾的需要，在50英里以外的新泽西中心区建有一个数据备份点。“911”过后的第三天，该公司幸存无几的人在那里发现，袭击之前所有的交易记录和所有的研究报告都有详细备份，并被完好无损地保留了下来。所以，FredAlger公司没有选择关张，而是决定重建。他们并非盲目地不认输。几年前就已退休的FredAlger，在弟弟David去世后立刻再度出山。当整个市场在去年9月17日重新开市时，FredAlger公司成了华尔街经纪公司中的股票大买家。此后，当其他基金管理公司的业绩在去年出现滑坡时，他们的利润反而因此大大增加。很快，FredAlger公司的投资管理队伍也空前兴旺起来，并在第五大道的2层楼建立了新的总部。类似的故事令全世界在一夜之间认识到，金融市场的数据备份和交易备份绝对不能缺少。自美国建国以来，华尔街就一直主宰着美国的金融。而此次袭击已经给了华尔街以致命的一击。事实上，对世贸中心的袭击完全改变了纽约的金融景观。以往，曼哈顿4/5写字楼的底层都是金融服务机构。而如今，这些金融机构中的一半以上都迁走了，大多都换了个小地方。在曼哈顿中心区的5万名金融服务人员中，已有19000名离开了这个城市。其中也有像摩根斯坦利和高盛公司这样的“金融巨人”。因此，即使在曼哈顿区还在燃烧时，监管者们已经开始考虑，如何才能重振金融业，并让它强大到足以抵御下一次灾难。在银行家和监管者们看来，“911”并不能被称为信用事件。但下一次灾难，不论是什么样的灾难，它一定会是一场信用事件。在庞大的支付链条上，一旦某个具有实力的环节受到支付困难的威胁，整个市场，如外汇交易或美国财政债券交易就有可能出现大塞车。为此，英国的金融服务管理局在一个储存有备份数据的秘密地点，进行了多次“业务持续”演习。美国的监管者也抛出一份建议书。这份建议书的目的在于，要保持市场参与者之间实时的信息和通信联系，即保持数据备份点之间的通信联系。监管者和市场应该能够抵御住沉重的打击，并应在4小时以内恢复工作。而对那些由15～20家大银行和5～10家证券公司所组成的金融主干系统来说，在它们主要参与的市场中应享受优先权，须在一天之内恢复营业。在“911”以前，银行之间（包括独立的通信和信息技术系统之间）的应急计划很少有彼此的沟通。为此，设在巴塞尔的发达国家10国“金融稳定性论坛”，已经起草了一个“应急协议名单”。被列入这一名单的，都是些全球最重要的金融实体。根据这个协议，名单中的金融实体的监管方可以在任何情况下及时取得联系。此外，美国监管机构已经提出，要持续不断地进行应急计划测试，以对付“一切可以想象得出的事件”。例如，进行产业范围的战争预演已经提到议事日程，而“无线战争”被最先纳入其中。那么，如何确保企业业务的连续运营以及数据的安全呢？严格的说，业务持续计划的建立和实施过程，实际上是进行一个涉及企业运营的项目，因此也涉及到项目管理的方方面面。标准的业务持续计划项目应按如下流程进行：1、项目启动和管理确定业务持续计划（BCP）实施过程的相关需求，包括获得管理支持、以及组织和管理项目使其符合时间和预算的限制要求。2、风险评估和控制确定可能造成机构及其设施中断的灾难、具有负面影响的事件和周边环境因素，以及事件可能造成的损失、防止或减少潜在损失影响的控制措施，提供成本效益分析以调整控制措施方面的投资，达到消减风险的目的。同时，由于风险会随着系统的发展而变化，所以风险管理过程也必须是动态的。3、业务影响分析确定由于中断和预期灾难可能对机构造成的影响，以及用来定量和定性分析这种影响的技术。确定关键功能、恢复优先顺序和相关性以便确定恢复时间。4、定业务连续性策略确定和指导备用业务恢复运行策略的选择，以便在恢复时间目标范围内恢复业务和信息技术，并维持机构的关键功能。5、应急响应和运作制定和实施用于事件响应以及对事件所引起状况进行稳定的规程，包括建立和管理紧急事件运作中心，该中心用于在紧急事件中发布命令。6、制定和实施业务连续性计划设计、制定和实施业务连续性计划，以便在恢复时间目标范围内完成恢复。7、意识培养和培训项目准备建立对机构人员进行意识培养和技能培训的项目，以便业务连续性计划能够得到制定、实施、维护和执行。8、维护和演练业务连续性计划对预先计划和计划间的协调性进行演练、并评估和记录计划演练的结果。制定维持连续性能力和BCP文档更新状态的方法，使其与机构的策略方向保持一致。通过与适当标准的比较来验证BCP的效率，并使用简明的语言报告验证的结果。9、公共关系和危机通信制定、协调、评价和演练在危机情况下与媒体交流的计划；制定、协调、评价和演练与员工及其家庭、主要客户、关键供应商、业主／股东以及机构管理层进行沟通和在必要情况下提供心理辅导的计划，确保所有利益群体能够得到所需的信息。10、与公共当局的协调建立适用的规程和策略，用于同地方当局协调响应、连续性和恢复活动，以确保符合现行的法令和法规。当然，实际应用中，如果受时间、成本等因素的限制，加之容灾目标有限（企业不需要承担应由政府负责的国计民生之重任），我们可以简化并适当改变上述标准流程。事实上，随着IT系统在企业内部应用的深入，IT系统更容易受到各种灾难的伤害而导致中断，特别是在许多情况下，关键资源可能属于不可控范围（如电力和电信）。对于倚仗IT系统的企业来说，从确保业务连续能力的角度出发，可以依据下列容灾规划步骤：1、灾难类型分析2、业务冲击分析3、当前业务环境及恢复能力分析4、容灾策略制订5、容灾方案设计6、业务连续性流程设计7、业务连续性流程及容灾方案管理和测试每一个步骤的相关职责一般会落在“计划协调人”或“应急计划制订人”的身上，他们通常是职能或资源部门的经理。协调人在其他相关系统或业务处理部门的职能经理和资源经理的协助下制定应急策略；应急计划协调人通常管理应急计划的制定和执行。容灾的IT实现除了详尽的容灾计划，实际上还需要合理的IT系统架构来确保企业的容灾计划得以实现。对于IT系统而言，在技术层面上，容灾需要考虑：*数据版本保护－建立容灾的多版本保护底线（BottomLine）*实时数据保护－数据复制，近乎0的数据丢失，数据一致性*应用系统恢复－恢复时间（包括数据库恢复）、应用版本的一致性（PTF）等*网络系统恢复－数据访问点变化、建立新网络路径、动态路由（收敛时间/稳定性）*容灾切换决策－及时发现灾难（容灾系统管理）、容灾切换的损失和补救办法*容灾切换过程－变更管理同时，无论任何时候，备份都是非常重要的，并要定期测试备份的可靠性。一种技术只能减少或防止某些类型的灾难的影响。除了简单或一成不变的应用，在没有特别要求的情况下，尽量不要采用操作系统层面以上的数据复制技术。而没有文档化的流程就相当于没有流程，没有流程的系统能够在要求时间内恢复完全靠运气（通常不能）。另外，在通常情况下，IT系统相关的灾难备份方案设计都必须考虑以下五大因素，1、灾难类型需要考虑哪些灾难？怎样的灾难？会使业务中断多久？2、恢复速度灾难发生后需要多久来启动及运行系统？能否承受数天或数分钟的等待？3、恢复程度需要恢复每条记录和交易吗？可以使用上星期或昨天的数据吗？需要恢复一切吗？有不相关的文件吗？什么是合法隐含的要求？有少数的一组人输入交易吗？他们可以重新输入灾难期间丢失的交易吗？这些交易十分重要而不容许丢失吗？4、可用的技术必须结合考虑所选技术在本地区的适用性、实现条件以及在实施时是否受某些现有条件的制约？5、方案总体成本实现灾难备份需要多少投资？不实现灾难备份会损失多少钱？综合以上所述，可以如图2所示：灾难备份方案选择标准容灾的7个层次据国际标准SHARE78的定义，灾难恢复解决方案可根据以下主要方面所达到的程度分为七级，即从低到高有七种不同层次的灾难恢复解决方案。可以根据企业数据的重要性以及您需要恢复的速度和程度，来设计选择并实现您的灾难恢复计划（参见图3）。这取决于下列要求：备份/恢复的范围灾难恢复计划的状态在应用中心与备份中心之间的距离应用中心与备份中心之间是如何相互连接的数据是怎样在两个中心之间传送的有多少数据被丢失怎样保证更新的数据在备份中心被更新备份中心可以开始备份工作的能力现已证明，为实现有效的灾难恢复，无需人工介入的自动站点故障切换功能是一个必须被纳入考虑范围的重要事项。目前通用的异地远程恢复标准采用的是1992年Anaheim的SHARE78，M028会议的报告中所阐述的七个层次：0层-没有异地数据（Nooff-siteData）Tier0即没有任何异地备份或应急计划。数据仅在本地进行备份恢复，没有数据送往异地。事实上这一层并不具备真正灾难恢复的能力。1层-PTAM卡车运送访问方式（PickupTruckAccessMethod）Tier1的灾难恢复方案必须设计一个应急方案，能够备份所需要的信息并将它存储在异地。PTAM指将本地备份的数据用交通工具送到远方。这种方案相对来说成本较低，但难于管理。2层-PTAM卡车运送访问方式+热备份中心（PTAM+HotCenter）Tier2相当于Tier1再加上热备份中心能力的进一步的灾难恢复。热备份中心拥有足够的硬件和网络设备去支持关键应用。相比于Tier1，明显降低了灾难恢复时间。3层-电子链接（ElectronicVaulting）Tier3是在Tier2的基础上用电子链路取代了卡车进行数据的传送的进一步的灾难恢复。由于热备份中心要保持持续运行，增加了成本，但提高了灾难恢复速度。4层-活动状态的备份中心（ActiveSecondaryCenter）Tier4指两个中心同时处于活动状态并同时互相备份，在这种情况下，工作负载可能在两个中心之间分享。在灾难发生时，关键应用的恢复也可降低到小时级或分钟级。5层–两个活动的数据中心，确保数据一致性的两阶段传输承诺（Two-SiteTwo-PhaseCommit）Tier5则提供了更好的数据完整性和一致性。也就是说，Tier5需要两中心与中心的数据都被同时更新。在灾难发生时，仅是传送中的数据被丢失，恢复时间被降低到分钟级。6层-0数据丢失（ZeroDataLoss），自动系统故障切换Tier6可以实现0数据丢失率，被认为是灾难恢复的最高级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力，当发生灾难时，能够提供跨站点动态负载平衡和自动系统故障切换功能。容灾的7各层次容灾的业务恢复时间段对于IT系统的容灾指标，我们可以通过下列参数表示：*以恢复点为目标（RPO--RecoveryPointObject）––数据的完整性（无数据丢失）––数据的一致性（数据正确且可用）*以恢复时间为目标（RTO——RecoveryTimeObject）*以网络恢复为目标（NRO——NetworkRecoveryObject）*以服务支持能力为目标（SDO——ServiceabilityDegradeObject）––性能––地域/支持的客户总数––功能的限制图4展示了业务恢复的不同时间段。容灾的业务恢复时间段容灾所涉及的恢复技术DR（容灾DisasterRecovery）项目的实施中涉及到多种技术。这些技术可以分为三类：应用恢复，网络恢复，数据恢复。应用恢复技术常用的应用恢复技术或方法如下：*通过负载均衡提供永不停顿的系统运行能力（Tier-7）例如：IBMS/390的GDPS技术给用户提供一个无中断的操作环境,来运行那些关键业务的应用程序，通过自动应用恢复能力来满足其第7级容灾要求*通过事先写好的脚本来实现自动的热接管（Tier-6）例如：GDPS也可以在热待命状态下运行，来为S/390系统提供第6级解决方案。HAGEO提供与GDPS热待命相似的解决方案，并常被用来作为大型关键业务UNIX数据中心的DR解决方案*按预案手工实现站点接管（Tier4/5）例如：有些设施的DR包括必须有人介入和决策的手动应用恢复程序。在实际灾难发生时，一些这样的设施因为对人工操作的依赖，造成恢复过程的延误。因此，我们认识到，容灾的实施必须包括一定程度的自动化，这也是GDPS和HAGEO这样的软件的主旨。网络恢复技术常用的网络恢复技术或方法如下：*4-7层交换机（Tier-7）例如：无中断的第7级网络恢复需要动态网络路由重选，来保证应用能够在不中断最终用户的情况下转入备用数据中心。在SNA环境下通过APPN来完成，而在IP环境下则通过第4-7层转换来完成。APPN是在IBMS/390GDPS环境下，为动态网络恢复而开发的SNA网络技术。通过标准的基于路由器的技术，可以在通用的IP传输上使用APPN*路由（Tier-6）例如：在第6级DR的实施中，网络恢复可以通过APPN和/或标准的路由协议来完成（OSPF/EIGRP/BGP-4）在非GDPS环境中，APPN应用路由在容灾系统备用路径可用时，自动恢复网络连接*2层Reconnect（Tier-4/5）例如：SNA子网在以太网/SNA中通过ATM/帧中继/DDN链路进行互联，如果发生链路故障，则可以通过手工切换来实现网络恢复数据恢复技术数据容灾系统的实现可以采用不同的技术。一种技术是采用硬件进行远程数据复制，我们称为硬件复制技术。这种技术的提供者是一些存储设备厂商，其技术例如PPRC、SRDF。数据的复制完全通过专用线路实现物理存储设备之间的交换；另一种技术是采用软件系统实现远程的实时数据复制，并且实现远程的全程高可用体系（远程监控和切换）。这种技术的代表则是一些存储软件厂商，其技术例如HAGEO、VVR。数据复制是一个复杂的议题，但一般来说这，它可以在硬件或软件层上实施（参见图5）。今天，市场上的硬件和软件技术提供不同的第4级和第7级数据恢复，对硬件或软件的选择取决于很多与设施相关的因素，如工作量、网络成本要求、工作点和数据恢复点间的距离、同性或异性的平台支持等等。我们将在下面的章节对以上两种技术进行详细的论述。数据复制技术容灾方案分析在现代企业的IT系统管理过程中，常常会遇到各种有关灾难备份范畴的需求，例如：“无论发生任何问题，业务系统必须在最短的时间内恢复！”；“无论发生任何问题，数据绝对不能丢失！”……针对这些问题，有经验的管理人员可能会考虑到一系列由此引发的问题：“究竟有些什么因素可能导致业务中断？”“究竟最短的时间是多长？”“是否所有的应用系统数据都不能丢失？”“这些恢复目标是否合理？”“目前的IT架构是否能够满足所要求的恢复目标？”“是否IT系统得到恢复，就意味着业务部门可以对客户进行服务？”“如何衡量灾难备份方案的投入产出比？”……回答以上这些问题的过程，就是考虑企业业务连续性的过程。事实上，随着IT系统在企业内部应用的深入，灾难备份在企业中已不是IT一个部门的问题，而是整个企业各业务部门与IT部门紧密合作的问题。其内容也不仅局限于数据的备份和应用的接管，还包含了网络的冗余、人员与组织架构的整理、恢复流程的设计等一系列技术以外的范畴。目的在于保证在灾难环境下，企业真正从业务的角度得到保护，而不仅仅是IT环境的恢复。业务连续性开发模式各行各业的用户，需要针对自身情况，设立可行的业务恢复目标，并制订出切合实际、投资合理、可靠的业务连续性及技术方案。这种业务连续性开发模式，体现在业务连续性或灾难备份的项目中，就是灾难备份项目实施的步骤：1、灾难类型分析2、业务冲击分析3、当前业务环境及恢复能力分析4、容灾策略制订5、容灾方案设计6、业务连续性流程设计7、业务连续性流程及容灾方案管理和测试其过程如下图所示，是一个周而复始的过程，随着企业内部环境的变化随时灵活变化：灾难备份项目实施过程阶段一、灾难类型分析（风险分析）在本阶段，需要进行详细而量化的风险分析，以确定当前IT环境之中存在哪些无法接受的物理威胁或者可能发生的灾难，并对灾难发生的可能性、目前可能的防护措施的有效性和该灾难所威胁的资产价值进行分析，最终得到带有优先级别的需要防护的灾难列表，并制订可能的处理方法，如接受该灾难发生的风险而不进行防护、自行制订该灾难的防护方法或者采取购买保险等风险转嫁策略。其结果可以由下图表示：风险分析在该图中，横坐标为风险发生的可能性，纵坐标为风险发生所造成的损失。在某一风险发生的可能性极小时，即使造成的损失极大，也可能属于可接受的风险范畴，例如美国的“911”事件。但该接受程度是与时俱进的，在“911”事件发生后，事实是大部分没有考虑这种大范围灾难性事件的企业基本没有得到恢复的机会。目前业界也已经将低概率事件逐渐纳入防护的范围。阶段二、业务冲击分析在本阶段，应该针对各种业务流程进行分析，通过走访各业务部门的相关人员，了解各种业务流程本身对该企业的重要程度。（例如在银行业里，储蓄和单据、网上支付、电话银行等业务就具有不同的优先等级。）同时根据一定的评判原则，得出在核心流程由于灾难的发生而无法正常进行时对企业本身的损失情况。这种损失可能是可以量化的，例如单据的丢失、计算的错误而导致的直接损失；也可以是无形的损失，例如客户满意度及竞争优势的丢失。通过对可量化和不可量化损失的综合考虑，得出各种核心业务流程由于灾难受损的可容忍程度及损失的决策依据。体现在IT系统上，是三个指标：数据恢复点目标（RECOVERYPOINTOBJECTIVE）：体现为该流程在灾难发生后，恢复运转时数据丢失的可容忍程度；恢复时间目标（RECOVERYTIMEOBJECTIE）：体现为该流程在灾难发生后，需要恢复的紧迫性也即多久能够得到恢复的问题；网络恢复目标（NETWORKRECOVERYOBJECTIVE）：即营业网点什么时候才能通过备份网络与数据中心重新恢复通信的指标；对于不同的业务流程，这三个指标可能相差非常之大，各个流程本身对这三个目标的优先程度也是不一样的，有的流程可能要求数据丢失的程度较小，但恢复时间可以较长，而另一些流程可能要求短时间内恢复，但数据的丢失程度可以放大一些。这三个指标直接影响所使用的容灾策略及技术方案，并指导企业的投入成本。可以用下图表示：业务冲击分析曲线在该图中，横坐标为灾难持续时间，纵坐标为灾难损失，在某一程度以下属于可接受的程度，即横虚线所示。这种可接受决策应该由负责该流程的业务部门综合考虑后做出。阶段三、企业容灾环境分析本阶段主要针对业务冲击分析的结果，对目前的内部环境进行评估，得出与恢复目标之间的差距。分析的对象为业务流程需要的资源，如IT环境等。通过本阶段的工作，得出各业务流程所牵涉的企业资产及资源（人力资源、IT架构、技术储备、技术使用程度、网络环境等），并分析得出目前的业务环境对容灾需求、冗余程度、可能造成的数据损失是否能够支持等方面的报告。用下图表示：容灾环境分析图中右边红线为目前环境所支持的容灾能力，左边红线为经过业务冲击分析所得到的需要达到的恢复能力，在灾难恢复时间和灾难造成损失两个方面都需要得到降低。阶段四、容灾策略制订在本阶段，结合以上各阶段的分析成果，以及企业本身在容灾上的投入能力，制订企业短期、长期范围内的容灾策略和目标，并有意识地将企业本身的人员组成和组织架构做出调整以适应策略要求。最重要的是制订出容灾实施步骤，优先解决最为重点的问题。如下图所示：容灾策略制订阶段五、容灾方案设计容灾方案可供选择的范围很大，但所有的容灾方案都必须考虑的因素包括恢复时间、实施与维护容灾策略所需的投入等。容灾恢复时间的需求越短，所需的实施成本就越大，实施难度也就越高。恢复时间与投入的比值可以用以下这张曲线图加以说明：容灾方案层次图中的各种层次方案可以分别满足不同的数据恢复目标和恢复时间目标，需要根据业务冲击分析的结果，针对每一种业务流程，综合选择能够满足容灾目标的方案。阶段六、业务连续性流程设计有了IT系统的恢复方案，只能够保证在灾难环境下，IT系统的恢复能够保证业务冲击分析的目标，但是业务的连续性并不只是IT系统的恢复，还包括办公场地、办公设备、紧急流程、指挥架构、人员调度等等多方面、各部门的综合考虑。只有业务流程执行过程的每一个环节都达到容灾目标的要求，才能够认为业务冲击分析的目标得到了满足。一般来说，每个企业都应该设立一个由领导挂帅，各业务部门和IT部门联合组成的一个容灾指挥小组：容灾组织架构图由该小组指挥，IT部门和业务部门分别执行，IT恢复计划和业务连续性计划才能得到同步，从而达到容灾设计的目标。阶段七、业务连续性流程及容灾方案管理和测试任何制订的计划，都必须经过不断的测试和修正，才能满足企业不断发展的需求。同时，通过测试过程，也能够使企业内部各部门及人员熟悉自己在业务连续性计划中所扮演的角色，做到胸有成竹，才能够在灾难真正发生的时刻有条不紊地开展恢复的过程。测试的过程可以分为“纸上谈兵”和实地演习两种方式，根据企业需要及对业务影响的不同分别采用。需要注意的是，无论平时的测试如何完善，也没有办法预测可能发生的灾难情况。关键人员的损失或者关键文档的丢失，都有可能对灾难恢复计划的执行造成巨大影响。因此，在灾难演练过程中要注意到人员的交叉备份情况，除了每个人自己所担负的责任外，尽量做到关键步骤有后备人选作为应变。七层灾难恢复解决方案在谈到灾难恢复方案时，经常提到灾难恢复解决方案的7个层次（tier）。那么什么是7层解决方案？该如何为关键的业务应用选择最优的容灾方案？恢复的7个层次灾难保护计划的目的是，确保关键业务持续运行以及减少非计划宕机时间。所有与容灾方案相关的计划都试图在方案本身、宕机时间和实施方案所需成本三者之间找到一个平衡点。三者的平衡关系灾难恢复方案中的恢复时间与下列因素有关：数据有效性的恢复IT基础设施的恢复可操作流程的修复关键业务的修复灾难恢复的层次划分细述7个层次灾难恢复方案的7个层次提供了一个简单方法论--如何定义当前的服务水平、风险以及期望的服务水平和环境。0层：无异地备份数据（Nooff-siteData）对于使用0层灾难恢复解决方案的业务，可称其为没有灾难恢复计划，主要表现为：数据仅在本地进行备份恢复，没有任何数据信息和资料被送往异地，没有处理意外事故的计划。恢复时间：在此种情况下，恢复时间不可预测。事实上也不可能恢复。例如，目前我们通常在机房内所做的数据备份，备份介质保留在机房内，用于本地的数据恢复。当灾难发生时，数据备份和设备有可能一同被毁，无法进行恢复。1层：有数据备份，无备用系统（DataBackupwithNoHotSite）使用1层灾难恢复解决方案的业务，通常将需要的数据备份到磁带上，然后将这些介质运送到其它较为安全的地方。但在那里缺乏能恢复数据的系统，若数据备份的频率很高，则在恢复时丢失的数据就会少些。此类业务应能忍受几天乃至几星期的数据丢失。例如，PTAM（PickupTruckAccessMethod）是一种许多数据中心所采用的标准备份方式。在完成所需的数据备份后，用适当的运输工具将它们送到远离本地的地方，同时备有数据恢复的程序。灾难发生后，一整套系统安装需要在一台未开启的计算机上重新完成，系统和数据可以被恢复并重新与网络相连。这种灾难恢复方案相对来说成本较低（仅仅需要运输工具的消耗以及存储设备的消耗）。但恢复的时间长，且数据不够新。2层：有数据备份，有备用系统（DataBackupwithHotSite）使用2层容灾解决方案的业务会定期将数据备份到磁带上，并将其运到安全的地点。在备份中心有备用的系统，当灾难发生时，可以使用这些数据备份磁带来恢复系统。虽然还需要数小时或几天的时间来恢复数据以使业务可用，但不可预测的恢复时间减少了。2层相当于在1层上增加了备份中心的灾难恢复。备份中心拥有足够的硬件和网络设备来维持关键应用的安装需求，这样的应用是十分的关键的，它必须在灾难发生的同时，在异地有正运行着的硬件提供支持。这种灾难恢复的方式依赖于PTAM方法去将日常数据放入仓库，当灾难发生的时候，再将数据恢复到备份中心的系统上。虽然备份中心的系统增加了成本，但明显降低了灾难恢复时间，系统可在几天内得以恢复。3层：电子链接（ElectronicVaulting）使用3层容灾解决方案的业务，是在2层解决方案的基础上，又使用了对关键数据的电子链接技术。电子链接将磁带备份后更改的数据进行记录，并传到备用中心，使用此种方法会比使用传统的磁带备份更快地得到更新的数据。所以，当灾难发生后，只有少量的数据需要重新恢复，恢复时间会缩短。由于备用中心要保持持续运行，与生产中心间的通讯线路要保证畅通，增加了运营成本。但消除了对运输工具的依赖，提高了灾难恢复速度。例如，某企业在每天下班后，将当日的流水全部记录下来，通过网络传到备份中心；备份中心在备用系统上，重新将所有业务重做，保证与生产中心的一致性。这一领域的产品可以分四层：1）存储设备层：IBM-ESS-PPRC、IBM-DS4000-RM、EMC-SRDF、HP-EVA-StorageWorksContinuousAccess、FALCONSTOR-IPSTOR、NETAPP等。2）操作系统及系统软件层：IBM-GEORM、VERITAS-StorageReplicator/VolumeReplicator、LEGATAL-RepliStor。3）数据库层：IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE-DATAGUARD等。4）应用程序层：应用程序开发时考虑到数据的复制。4层：使用快照技术拷贝数据（Point-in-timeCopies）使用4层灾难恢复方案的业务，对数据的实时性和快速恢复性要求更高些。1-3层的方案中较常使用磁带备份和传输，在4层方案中开始使用基于磁盘的解决方案。此时仍然会出现几个小时的数据丢失，但同基于磁带的解决方案相比，通过加快备份频率，使用最近时间点的快照拷贝恢复数据会更快。系统可在一天内恢复。4层灾难恢复可有两个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个方向发生。接收方硬件必须保证与另一方平台在地理上分离，在这种情况下，工作负载可能在两个中心之间分享，中心1成为中心2的备份，反之亦然。在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。在灾难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢复也可降低到小时级。支持这种工作方式的产品包括IBM-HAGEO、VARITAS-GlobalClusterManager。5层：交易的完整性（TransactionIntegrity）使用5层灾难恢复方案的业务，要求保证生产中心和数据备份中心的数据的一致性。在此层方案中只允许少量甚至是无数据丢失，但是该功能的实现完全依赖于所运行的应用。5层除了使用4层的技术外，还要维护数据的状态-要保证在本地和远端数据库中都要更新数据。只有当两地的数据都更新完成后，才认为此次交易成功。生产中心和备用中心是由高速的宽带连接的，关键数据和应用同时运行在两个地点。当灾难发生时，只有正在进行的交易数据会丢失。由于恢复数据的减少，恢复时间也大大缩短。数据库的数据复制功能一般可以工作在这样的方式下：IBM-DB2-HADR、ORACLE-ORACLE-Replication等。6层：少量或无数据丢失（Zeroorlittledataloss）6层灾难恢复方案可以保证最高一级数据的实时性。适用于那些几乎不允许数据丢失并要求能快速将数据恢复到应用中的业务。此种解决方案提供数据的一致性，不依赖于应用而是靠大量的硬件技术和操作系统软件来实现的。这一级别的要求很高，一般需要整个系统应用程序层到硬件层均采取相应措施。1）应用程序层采用基于交易（TRANSACTION）的方法开发。2）数据库可以采取数据复制。IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE-DATAGUARD等。3）操作系统使用集群软件、站点迁移软件、数据复制软件：IBM-HACMP、VARITAS-GlobalClusterManager等。4）硬件层使用同步的数据复制：IBM-ESS-PPRC、IBM-DS4000-RM、EMC-SRDF或使用带有CONSISTANCY-GROUP功能的异步数据复制IBM-ESS-PPRC、IBM-DS4000-RM。7层：解决方案与具体业务相结合，实现自主管理（HighlyAutomated,BussinessIntegratedSolution）7层灾难恢复方案在第6层的基础上，集成了自主管理的功能。在保证数据一致性的同时，又增加了应用的自动恢复能力，使得系统和应用恢复的速度更快、更可靠（按照灾难恢复流程，手工操作也可实现整个恢复过程）。7层可以实现0数据丢失率，同时保证数据立即自动地被传输到恢复中心。7层被认为是灾难恢复的最高级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力。7层是灾难恢复中最昂贵的方式，但也是速度最快的恢复方式。当一个工作中心发生灾难时，7层能够提供一定程度的跨站点动态负载平衡和自动系统故障切换功能。现在已经证明，为实现有效的灾难恢复，无需人工介入的自动站点故障切换功能需要一个应该纳入考虑范围的重要事项。如何选择最优的灾难恢复方案在选择解决方案时，非常重要的一点是，解决方案所需的投资在IT商业价值中应占切实可行的部分，任何人都希望用较少的投资换取更多的利益--灾难恢复解决方案的投资一定要少于灾难本身带来的财政损失。按照下述目标，为一个商业应用选择解决方案时，决定起来就会简单：（按用户的投入、希望恢复的速度等目标来选择，灾难恢复越快所需的投入就越多）*恢复时间目标（RTO–RecoveryTimeObjective）没有应用系统，可以忍受多长时间？*恢复时间点目标（RPO–RecoveryPointObjective）系统恢复后，可以允许重新创建多少数据？*降级操作目标（DOO–DegradedOperationsObjective）数据中心减少了，会有什么负面影响？*网络恢复目标（NRO–NetworkRecoveryobjective）网络切换需要多长时间？通常，构成应用业务连续可用性的因素只适用于同一机房内的环境。机房本身就是一个单点故障。为了抵抗灾难，我们必须选择一种比连续可用性考虑更多的恢复方案。恢复方案一定是在全面衡量了实施费用、维护费用、灾难对财政的影响，并对业务影响进行了分析后而得出的一个综合方案。四个关键目标每一层灾难恢复方案的恢复时间通常是指恢复处理业务服务所需的安装时间。然而在现实的灾难中，需要对其他更多的事项进行考虑。例如，有些业务可以容忍较长时间的停机服务，但要求一旦业务开始就需要使用最多的实时数据；有些业务必须在尽可能短的时间内恢复服务，而不考虑数据的实时性；还有一些既需要最短的时间内恢复服务，也需要最多的实时数据。通过评估具体场地的实际灾难恢复需求，为恢复计划开好头。四个关键目标方案成本与业务停止带来的损失灾难恢复方案的成本是根据以下两点得出的：*客户需要在多快的时间内恢复数据*不能继续业务处理将带来多少损失恢复数据所需的时间越少，业务处理服务中断的时间就越短，所需的方案成本就越多。另一方面，不能进行业务处理的时间越长，由此带来的损失就越大。最优的方案就是，方案成本曲线和业务停止带来的损失的曲线的交集。成本/时间窗口。成本时间窗口与系统体系结构的关系为了灾难保护，需要建立一个可靠并经过验证的基础结构，系统的每一级部件都一定要有冗余，这是必须的。高可用系统的构成因素存储设备级（StorageDeviceLevel）存储设备级，是指存储的物理实体，如磁盘或磁带机。为了实现设备级的可用性，使用嵌入在设备自身中的功能，这些冗余功能可通过在磁盘中使用备用磁道或在磁带机中使用特定的写机制来实现。存储服务器（存储子系统）控制器级存储控制器自身的接口用于连接SAN或服务器（Servers）和存储设备。存储控制器的内置功能负责所有与存储相关的执行操作。*内置的拷贝功能，如Point-in-Time拷贝，远程镜像*内置高可用性机制（冗余、接管Failover）SAN（StorageAreaNetwork）级SAN级的冗余可通过冗余SAN的基本模块--SAN交换机或使用导向器（Director）来实现。SAN交换机和导向器的主要区别在于可维护性和可用性。导向器类的产品可以在不中断服务的同时，在线进行Microcode/Firmware的升级。在出现硬件故障时，导向器通常只需更换一个部件。操作系统中设备驱动程序级设备驱动程序是存储设备，服务器的操作系统和主机适配卡之间沟通的桥梁，它负责实施与操作系统中所展示的全部硬件功能相关的操作，并负责与存储设备之间的通讯，如光纤通道环境中多路径和通道接管功能。操作系统级在操作系统级，通过使用群集技术可以实现操作系统级的高可用性，如HACMPforAIX，STEELEYEforLINUX和MicrosoftWindowsClustering。可以考虑将群集技术作为灾难保护的一部分。在灾难保护方案中群集本身不代表基础设施。应用级要想在应用级实现冗余，在很大程度上依赖于应用的类型。如在三层的SAN环境中，通过使用多个应用服务器（MultiApplicationServer），应用层可以做到高可用性。如果任何服务器发生故障，加在其上的负载就会被重新分布到其他运行中的服务器上，业务可继续进行。功能级功能级是系统整体架构中最重要的一级，它依赖以下级的可用性：*IT基础设施架构的可用性（操作系统+服务器+存储+网络）*应用的可用性（应用+数据）+IT基础设施架构的可用性*业务流程的可用性（应用的可用性+外部相关条件）在规划灾难保护的功能级时必须包括所有外在因素，如不同企业间的相互协作等。容灾系统的设计过程容灾方案的制定是一个系统的过程，包含一系列的工作及计划的制订，包括BusinessContinuityPlanning（BCP），BusinessRecoveryPlan（BRP），ContinuityofOperationsPlan（COOP），IncidentResponsePlan（IRP），OccupantEmergencyPlan（OEP），DisasterRecoveryPlan（DRP）等计划，在此我们主要介绍灾难恢复计划（DisasterRecoveryPlan或DRP）的制订过程及方法相比于其它机构和领域，IT系统更容易受到各种灾难的伤害而导致中断，特别是在许多情况下，关键资源可能属于不可控范围（如电力和电信），于是有效的灾难恢复计划、履行计划和对计划进行有效地测试对于削减系统风险与各种服务的不可用性就显得非常重要了。为了保证灾难恢复计划的成功，管理者应该做到以下几点：1、灾难恢复计划的全部过程及其在整个运行连续性计划和业务连续性计划过程中的地位。2、或复查其应急策略及计划过程并运用计划周期要素，包括预备计划、业务影响分析、备用站点选择和恢复策略。3、和复查其灾难恢复计划策略，重点在于计划的维护、培训以及对应急计划的演练。灾难恢复计划描述简单地讲，灾难恢复计划的重点在于IT的恢复，如系统、应用、数据和相关的设施（如网络等）。灾备的主要目标是在事件发生时，能够保证全部或部分计算机服务的持续可用。灾难恢复计划就是指，在灾难发生时需要采取的响应步骤的详细过程。灾难恢复计划包含了一系列灾难发生前、过程中和灾难发生后所采取的动作，灾备方案计划书应该文档化，并经过充分的测试，以保证灾难处理过程中各种操作的连续性和关键资源的可用性。根据灾难发生的时段或业务中断的严重程度的不同，一个企业的生存能力也依赖于管理层重建其关键业务的能力。一般来讲，这些业务功能的重建需要几年的时间。但是，对于管理层，必须在几个小时或几天的时间内重建，确实是一个难题。重建复杂的商业环境要求有一个经过慎重考虑且具体的计划，以备在灾难发生时执行。从这份计划中我们可以看到，为恢复初始环境，在重建过程中应该采取的步骤。在一个组织中，灾难的发生是不可预测的。对客户而言，最想知道的事情是灾难什么时候发生。系统和工作人员可以应对灾难，并对可预知的灾难进行反应是最终的目标。换句话说，灾难发生时，不需要等待，而只需要确定你的计划是否可行。灾难发生时，客户、供应商和员工通常会关心中央处理设备的停机时间。在这种情况下，这些人都没有什么过分的要求，只关心停机的等待时间，而停机时间的多少则依赖于灾难恢复方案。通常，这种停机时间可以分为以下两个部分：服务丢失表示从灾难发生到系统恢复正常所损失的时间。数据丢失表示用户数据的丢失，也就是说，系统恢复到灾难发生前的数据层面，要花费多少时间可以重新工作。一个组织的大部分收入，如果过分的依赖于生产系统，一旦应用和网络停机，则将会造成巨额收入的损失。在不同的行业，如果以小时为单位计算收入损失，因灾难而造成的收入减少也是不同的，如能源、电信、制造行业和金融部门，造成巨额收入的损失并不惊奇。另外，实际收入损失所占的百分比也和运营的关键业务有关系总之，灾备计划就是要保证灾难发生后，能及时地按照一定的策略、过程和技术等方法迅速恢复IT系统、操作和数据。灾难恢复计划项目阶段如何制订灾难恢复计划，前面的章节中（参看3.1节业务连续性）给出了指导性的建议步骤。上述步骤中，每一步都包含了相关方面的各项内容。实际上，在制定灾难恢复计划时，我们可以将这些步骤细化为下图的操作流程。在下图的流程中，包含了灾难恢复计划的各个阶段，并直观的告诉我们，灾难恢复计划的制定是一个循环往复的过程。灾备计划不同阶段图表对上图的简单分析如下，更详细的内容，将在以下的章节中给出：1）项目启动及项目组的选择此阶段包括取得管理层的正式同意、选择项目协调人员和项目组成员、信息收集方式的标准化以及项目资源的调度等方面的内容。2）数据收集和需求分析此阶段包括收集业务过程的信息、技术基础架构的支撑环境、潜在的停机费用消耗、灾难类型以及其它公司使用的相应技术和策略等方面的内容。3）风险分析在风险分析阶段，我们将对为达到灾难恢复计划的设定目标收集的数据进行处理，以便对风险以及在可接受的时间范围内恢复所需要的资源有较深的理解。作为风险分析的结果之一，灾难防范技术的实施可以帮助我们防止可以避免的灾难。比如：火灾的侦测和防止，不间断电源系统等。4）数据保护数据保护是灾难恢复计划中的关键模块。必须清晰、完整地表述出各类数据（记录、胶片、电子及光学数据等）的保护方法。5）恢复计划恢复计划是指对意外事件所采取的策略及明确的规划。如替代的系统、网络和终端用户。6）培训和测试培训和计划性的测试可以对所设计的灾难恢复策略进行测试，并且提供了一种可以对灾难恢复计划中的不足方面进行发现和修改的手段。7）计划的维护管理计划的维护管理提供了一种机制，可以使灾难恢复计划随着业务和IT系统架构的改变而改变。下面我们对各个阶段给出较详细的解释。项目启动和项目组选择的阶段可细分为以下几个主要组成部分：1、管理层的承诺企业的最高管理层必须支持且参与计划的制定和协调，以确保灾难恢复计划在本公司内的有效作用。制定一个有效的计划，必须要有时间和资源的保证，时间就是计划的制定所需要的时间，而资源则包括预算和人力。2、计划制定委员会计划制定委员会负责监控计划的制定和实施，由公司各个部门的代表组成，关键的委员会成员应当包括业务运营经理和数据处理部门经理。委员会还应当定义计划的适用范围。委员会的另一个职责是定期把项目信息通知给最高管理层，因为这是一个比较敏感的主题，可能需要花费较多的人力和财力，这些都需要最高管理层来支持。3、范围尽管大多数灾难恢复计划只包含数据处理相关的项目，但是一个复杂的计划也包含数据处理以外的操作领域，如果同时考虑到灾难的其它方面，灾备计划涉及的范围是相当广泛的。4、假定制定计划要考虑的最基本问题就是设想最坏的场景。对运营系统而言，最坏的场景就是主要设备的损坏。计划的制定就是基于这样一个前提，每一个灾难恢复计划都基于一组假定的设想。这些假定对计划所涉及的环境做了限制，这些限制定义了公司准备接受的灾难量级，它们可以通过以下问题来识别：哪些设备被破坏中断的时间是多少哪些记录、文件和资料需要保护灾难发生时，哪些资源是可用的员工设备通讯传输后备场地在制定灾难恢复计划时，可以借鉴以下典型的假定：公司主要的生产设备被破坏拥有在可以执行计划之内的关键性功能的员工员工可以被通知到，并且可以到备份地点执行关键性的恢复和重建工作灾难恢复计划是可用的部分计划可用于恢复相应的环境中断备份设备是可用的在异地或别的设备中保存有足够多的备份备份地点可以处理公司的工作司本地和远端的通讯链路是可用的本地基本的传输是可用的灾难发生时，供应商应根据承诺对公司提供支持以上的假定并不包含全部可能性，但在计划制定的开始阶段可供大家参考。5、项目组及其责任灾难恢复计划可以按照组的形式来制定，特定的任务可以分配给特定的组。意外发生时的公司架构可能与现有的架构有所不同，那时通常是以组为基础，不同的组负责不同的功能领域，这些组可能包括：管理组业务恢复组部门恢复组计算机恢复组损坏评估组安全组设备支持组后勤支持组行政支持组用户支持组计算机备份组异地数据存储组软件组通讯组应用组人力资源组市场和客户关系组企业并不需要建立以上所有的这些组，但我们强烈建议与上述的每个组相关联的功能都能被包含在其中。根据员工的技能和领导能力，可以将其选入不同的组。一般来讲，各组的成员所拥有的技能应与其平时的工作相一致。例如，服务器恢复组的成员应当包含系统管理员。组成员不仅要知道计划的目的，而且要知道执行恢复策略的过程。考虑到可能会联系不到某些成员的情况，成员的组建应基于“互有备份”的原则。同样，成员也应当了解其它组的目的和执行过程。每一个组由组长领导，组长要负责本组的运行，承担同其它组的协调工作，向组员及时传达需要的信息，并在组内做决定。另外，如果组长不能行使其职能，必须指定代理组长。在灾难恢复计划中，最重要的组是管理组。他们在事故发生时负责协调所有组的工作。管理组一般由高级管理经理负责，如CIO。以下是各个组的主要职能：负责计划的执行促进与其它组之间的交流，监督计划的测试和执行所有或是某一个成员可能领导特定的组协调恢复过程评估灾难，执行恢复计划，联系组长监控并记录恢复的过程是最终决定优先级设置、各种政策和过程的人数据收集和关键需求分析阶段要确定一个企业的关键性需求，每个部门应该将本部门执行的功能文档化，经过一定的分析来确认部门内部和外部的主要职能。部门的日操作记录可以对确定关键性需求起到辅助作用。以下是一些辅助问题：1）如果灾难发生而没有现有的设备和部门架构，部门能运转多长时间？2）在部门内，什么任务的优先级最高？（包括关键的手工功能和处理）这些任务被执行的频率是多少？如每天、每星期或每月等。3）执行最高级别的任务，需要那些人力、设备、和供应等？4）对于关键的设备及供应，在灾难的环境中应如何替换？5）上述这些关键信息的替换需要多长时间？6）部门内有没有可供参考的手册和操作步骤？灾难发生时这些是如何替换的？7）任何供应、设备和操作过程或手册等，有没有在异地存放？8）确定原始文档的存储设备和安全性。在灾难的时间中，这些信息如何被替代？有没有更多的地方来保存？9）当前计算机的备份过程是什么？如何恢复备份？任何关键的备份拷贝有没有在异地存放？10）在灾难发生后，临时性的操作步骤是什么？11）一个部门的运转中断，对其它的部门有什么影响？12）依赖于正常运转的企业以外的服务商和供应商有哪些？13）有没有经过跨部门培训的人员？14）谁负责维护部门的异常计划？15）灾难恢复计划有没有其它的考虑？在上述问题的基础上，我们列出了以下需要进行文档化的信息：备份地址列表，关键电话号码记录，通讯目录，分发记录，文档目录，设备目录，表格目录，保险政策目录，主要的计算机硬件目录，主要客户列表，主要供应商列表，计算机硬件和软件列表，通知列表，办公用品供应列表，异地存储地址列表，软件和数据文件备份和调度，电话目录等资料和文档。关键性需求可以通过问卷的方式来获得，问卷主要是将每个部门的关键性工作记录在案，并找出最小的必备资源，如人力、设备、供应商、文档等资源。确定了各部门的关键性需求并将其文档化以后，管理层就可以为各部门在整个企业的灾难恢复过程中设置优先级别。每一个部门的操作可以按照下面的方式给出优先级：1）基本操作（必需）：服务中断超过一天，将严重地危害到公司的运转。2）推荐操作（关键）：服务中断超过一个礼拜，将严重的危害到公司的运转。3）其它操作（非关键）：这些信息的存在可以方便业务操作，如果一旦丢失也不会影响到业务的正常运转。根据RTO和RPO的不同，各公司采取的策略也会有所不同。以下是一些通用的标准，可以根据这些标准将应用进行分级：1）必需：从停机算起，RTO<8小时，RPO在15