《中国人寿IT战略规划项目灾备中心高端设计报告.docx》由会员分享，可在线阅读，更多相关《中国人寿IT战略规划项目灾备中心高端设计报告.docx（56页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、中国人寿IT战略规划项目灾备中心高端设计报告中国人寿IT战略规划项目灾备中心高端设计报告版本号 V3.0起草人:中国人寿IT规划项目组北京市朝阳区建国路112号中国惠普大厦（100022）电话：010-65643888传真：010-65668278版权说明本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属中国惠普有限公司咨询与集成事业部和中国人寿共同所有，受到有关产权及版权法保护。任何个人、机构未经中国惠普有限公司咨询与集成事业部和中国人寿共同的书面授权许可，不得复制或引用本文件的任何片断，无论通过电子形式或非电子形式。文档信息项目名称：中国人寿信息化
2、战略规划文档版本号：3.0文档作者：中国人寿信息化战略规划项目组生成日期：2003-12-2文档审核者：中国人寿信息化战略规划项目组审核日期：2004-3-8目 录1概述72灾备中心建设的策略72.1业务连续的几个层次102.1.1 高可用性102.1.2 灾备中心112.1.3 业务永续运行112.2业务影响分析132.3业务永续运行计划142.4结论213灾备中心建设的建议223.1灾备中心的建设方案223.2灾备中心建设要求233.3灾备中心的建设与数据中心的关系233.4灾难恢复基本模式243.5省市灾备中心建设253.6机房建设264灾备中心的功能要求264.1灾备环境264.2开发
3、测试环境264.3预生产环境274.4演习环境274.5灾备中心功能示意图285灾备中心设备、网络性能要求295.1灾备中心的容量295.2恢复时间的要求305.3体系架构315.3.1 灾备中心的主机、存储布局395.4灾备中心的网络425.4.1 灾备中心与生产中心之间的网络425.4.2 灾备中心的广域网架构445.5灾备中心的安全体系456灾备中心的管理体系456.1业务永续管理与中国人寿其他管理流程的关系466.2业务永续管理流程476.3计划的测试、培训和演习476.4业务永续运行计划的维护496.5恢复组组织结构图526.5.1 角色和职责537缩略语59图表目录图 21停机因素
4、8图 22中国人寿IT高可用性环境建设线路图9图 23业务连续的层次10图 24中国人寿业务永续运行环境实施方法12图 25中国人寿业务影响分析方法14图 26中国人寿开发业务永续运行计划的方法15图 41容灾中心的功能28图 51校园集群体系架构33图 52城间集群体系架构34图 53广域集群体系架构35图 54中国人寿灾备中心假设方案38图 55 灾备中心主机、存储布局39图 56 灾备中心与生产中心的数据链路43图 57灾备中心广域网逻辑架构示意图44图 61业务永续管理与ITSM其他流程的关系46图 62中国人寿永续运行管理流程概览47图 63中国人寿业务永续运行计划的维护流程50图
5、64灾备中心永续运行管理组构成53表 51技术手段与RPO、RTO的对应关系36表 52业务类型的服务级别分类36表 53中国人寿关键应用RTO与RPO要求（来源：中国人寿IT规划项目组）401 概述 根据项目第一阶段的调查和在在中国人寿IT战略的要求，我们认为中国人寿有必要建立一个灾备中心和相应的业务永续运行计划。本文是中国人寿IT战略规划项目的高端设计之一灾备中心高端设计。其中涉及到如下问题： 灾备中心建设的策略提出了业务永续运行的概念，并建议中国人寿的灾备中心具有保证关键业务永续运行的能力 灾备中心建设的建议介绍了灾备中心建设应该考虑的问题，例如灾备中心地点的选择，技术的选择，关于省市级
6、数据中心的灾备中心建设的考虑等 灾备中心的功能要求 灾备中心设备、网络性能要求，以及灾备中心的安全体系 灾备中心的管理体系介绍灾备中心的组织架构以及管理流程，质量控制等2 灾备中心建设的策略 在信息时代，数据是企业创造商业价值的生产资料，数据的丢失将为企业带来毁灭性的灾难。 据Gartner Group的调查数据表明：在经历过大型灾难或长时间系统停运的公司中，有2/5的公司再也未恢复运行，而在其余的公司中，有1/3的公司在两年内破产。面对各种未可预知的灾难，越来越多的企业将容灾作为企业安全的保障。 根据Gartner Group在2003年9月分表的报告，由于硬件故障而导致的系统停机只占非计划
7、停机的21。因此，减少系统的停机时间不能仅仅靠加大硬件的投入，还有兼顾其他因素，例如加强员工的教育，强化管理流程，成立专门的机构应对突发事件等。通过我们第一阶段的调研，也发现中国人寿从自身的发展出发，有建立灾备中心的需求。建议中国人寿的灾备中心建设成一个能构保证关键业务能够永续运行的数据中心。图 21停机因素惠普公司在总结了大量经验的基础上提出了建设高可用性环境的5个步骤。这5个步骤将伴随建设的全过程，是一个不断循环往复的过程。这5个步骤分别是：分析，设计，建设，管理，提高。图 22中国人寿IT高可用性环境建设线路图高可用性只有通过技术，服务和最佳管理实践三者的完美结合才能达到。2.1 业务连
8、续的几个层次 图 23业务连续的层次如图2-3所示，根据受保护对象的不同，保证业务连续运行所使用的技术不尽相同，当然，实现的成本也有较大的差异。2.1.1 高可用性 可用性并不是一个模糊概念，实际上它能用数学方法来精确地表示。简单地讲，一个高可用性系统就是一个用户能随时使用的系统，例如当用户需要在早上8点到下午5点启用该系统时，该系统就应该在这段时间内保证良好的可用状态，其余的时间可以用来进行定期维修保养。可用性常被定义为实际的服务时间和要求的服务时间的比值，常用百分比表示。许多现代化系统需要一天24小时、一年365天连续不间断运转(有时也称为724或36524)。一个可用性为99.9%的36
9、524系统一年的平均故障时间为8.76小时(525分钟)，而要想让系统的中断时间在一年中只有3分钟的话，系统必须有99.999%的可用性。我们将图2-3中对应于数据，应用/数据库，系统和网络的解决方案称为高可用性解决方案。我们这里所说的高可用性解决方案是指利用冗余设备在本地（机房内部）完成的，一般恢复时间在几分钟之内。在使用高可用性方案进行系统恢复时，一般只需要IT部门参与，而与业务部门无关。2.1.2 灾备中心 当遇到大规模的自然或人为灾害，例如火灾，地震等，办公场所/机房也许会遭到破坏。灾备中心就是为了应对这种情况而诞生的。灾备中心位于与生产中心不同的建筑物中，距离因容灾目的而不同。灾备中
10、心强调的是灾难恢复功能，重点在灾难发生后。而要保证关键业务在灾难发生到灾备中心开始工作期间不中断运行，仅仅靠IT部门的力量是远远不够的，还需要各个业务部门的积极参与，利用技术，服务和管理的手段才能做到。2.1.3 业务永续运行 所谓业务永续，是指在遇到严重灾害事件时（物理场所的灾难，人为破坏，自然灾害等），仍能够提供保证业务运行的环境。它包括一个持续不断的评估，计划，实现和支持流程，还要求利用必要的技术和服务来为基础架构提供支持。业务永续不是专门的技术，产品或服务。也不是高可用性，灾难恢复或者容灾的实现。业务永续运行应该包括风险评估，中断影响分析，以及避免中断策略，必须将这些因素充分考虑进综合
11、性业务持续性计划即要根据关键性业务程序而不是技术来进行调整。然而，无论在高可用性、冗余、容错、群集和镜像策略等方面考虑得多么全面，仍然没有哪个业务持续性计划能保证业务万无一失。业务永续的关键，在于了解什么业务程序在业务中事关重大，并确定影响该程序的所有因素。综合性风险分析，有助于企业做出有关应对，迁移或转移风险的业务决策。根据中国人寿的具体情况，我们建议中国人寿灾备中心的建设分4个阶段进行：图 24中国人寿业务永续运行环境实施方法2.2 业务影响分析执行业务永续运行项目的第一步就是做业务影响分析(Business Impact Analysis)。以后的基础架构设计和业务永续运行计划都是根据业
12、务影响分析的结果。业务影响分析是确定不同业务流程对企业的影响程度。优先级的制订主要根据分析有形的和无形的影响，对停止业务时间长短的接受情况和为使影响降至最低的最低需求。这些数据可以用来做制订恢复和业务永续运行策略的基础。BIA的目标： 识别和量化每个业务单元或者资源对整个企业在财务和运行方面的影响 识别潜在的失效场景和评估潜在的威胁 帮助定义针对不同的可用性/灾难恢复要求所需要的不同级别的投资情况 规定恢复策略 建立灾难恢复时的恢复流程优先级我们认为，中国人寿应该按照如下步骤进行业务影响分析：图 25中国人寿业务影响分析方法2.3 业务永续运行计划业务永续运行计划是关于一些流程的正式文件，这些
13、流程是制订企业面对不利的意外事件时的策略和行动计划的。使用这些策略和行动计划可以使企业在预先定义的时间段内恢复关键业务的运行，从而使灾难的影响降至最小，使受影响的业务尽快的恢复。业务永续运行计划是灾备中心最重要的文件之一。我们根据中国人寿的情况制订了如下开发业务永续运行计划的方法：图 26中国人寿开发业务永续运行计划的方法根据中国人寿的具体情况，我们认为中国人寿在制订和执行业务永续运行计划时应参考如下原则：原则 1: 董事会和管理层应该对其企业的业务永续运行计划准备情况负责。1. 企业的业务永续运行计划是董事会和管理层的责任。管理层应该通过对业务永续运行计划准备情况的定期验证来表明其对于风险及
14、其消减措施的充分了解和重视。2. 验证的内容应该明确包括： 企业的准备情况 企业考虑到其业务活动水平、风险管理策略和在保护保险体系系统稳定性方面所扮演的角色这些因素的情况下，选择遵循本文中原则的程度 3. 这些验证应该提交给董事会。企业业务优先情况的变化可能影响到其业务永续运行计划准备的效率。所以验证应该定期进行更新。4. 越来越多的客户和合作伙伴也在寻求为其提供金融服务的企业在业务永续运行计划准备方面的保证。所以，如果适当，应该将这些验证与客户、合作伙伴以及其它有关方面共享。原则 2：企业应该将业务永续运行计划融入到日常的业务活动中使之成为良好的工作习惯。1. 业务永续运行计划是面向风险和事
15、先反应的方法，它包括对业务分枝的全面理解、事件响应、危机管理和对外联络。它通过制定恢复业务功能以履行业务职责的方法和规程来处理风险。2. 业务永续运行计划应该是可信的，包含清晰的策略和职责，具有可操作性，随着业务变化得到更新并经过切实的测试。依据企业业务规模和范围的不同，良好的工作措施可包括： 明确业务永续运行计划政策和策略 明确业务永续运行计划项目中的角色和责任 进行业务影响分析 制定、部署、测试和维护业务永续运行计划 不断对员工进行相关的意识培养和技能培训 应急响应和操作规程 对外联络和危机管理协调规程 对外协调规程（包括管理当局和相互依赖的团体等） 3. 一旦建立了业务永续运行计划，就应
16、该定期对其进行检查、维护和测试以确保其具有及时性、高效性和可操作性。企业应该努力将面向风险的业务永续运行计划融入到日常运行和管理中并使之成为企业文化的一部分。原则 3：企业应该定期、全面和切实地测试其业务永续运行计划。1. 需要通过测试来确定业务永续运行计划的有效性。技术、业务方法以及员工角色和责任的变化将影响和降低业务永续运行计划的效率并最终影响到企业的准备状态。因此，通过对业务永续运行计划的测试来测量其可用性和有效性是很重要的。测试还将使员工熟悉恢复站点的位置以及中断期间所需的恢复规程。测试的目标是确保企业在启动业务永续运行计划后能够按照计划可靠、及时和有效地恢复运行。2. 定期：企业对其
17、业务永续运行计划一年至少要测试一次。经常性的测试对于保证业务永续运行计划的效率是至关重要的。一些企业发现，每月或每季度进行测试能够有效帮助其进行中断处理的准备。管理层应该参与到测试中并熟悉其在计划启动时的角色和责任。3. 全面和切实：业务方法的所有部分都应该得到切实的测试（比如从前台到支持和处理部分），其中包括测试恢复站点所提供基础设施的连接性、功能性和负载能力。企业应该能够证明其测试项目充分涵盖了定性和定量等各方面的问题。所有的策略和计划的假设都应该定期地被检讨以确保其适当性，在业务范围和方向发生变化时尤其应该如此。全面性还包括测试人员的意识和准备情况以及对外协调情况。相互依赖性，特别是对企
18、业控制范围之外的外部团体的依赖性应该被全面测试。这包括在新加坡以外工作的企业官员、分枝或服务提供商。4. 其它可能的测试包括： 整个系统的桌面排演测试 员工呼叫测试（人员调动和无调动情况下） 备份站点到备份站点的测试（包括与外部服务提供商） 共享服务替代测试 备份磁带还原测试以及 关键记录恢复（数字的或书面的） 应该准备好正式的测试文档和列有经验教训以及风险消减措施的测后分析报告供管理层签署。原则 4：企业应该制定恢复策略和关键业务功能的恢复时间目标。1. 建立恢复策略可以使企业以有序和事先定义的方式执行业务永续运行计划以减少中断时间和经济损失。它是定义关键业务功能的恢复时间目标 的基础。没有
19、这些清晰的定义，有限的资源就有可能被不恰当的用于次要的活动。这样就可能对企业的信誉和生存能力造成负面的影响。关键业务功能2. 在危机中，全部恢复所有的业务功能可能是不实际的。所以，企业应该确定其关键的业务功能以及这些操作中断情况下的潜在损失（经济或非经济方面）。获取这些信息的常用方法是进行业务影响分析 。这种方法也用来凸现各种关键功能之间的相对优先顺序并帮助企业确定其恢复策略和恢复时间目标。3. 由于不同企业的业务导向和顾客预期不同，所以其关键业务功能也有所不同。但是，与完成大额支付业务、清算和结算事务、履行每日资金和担保职责、管理客户风险以及维护客户、投资者或公众信心有关的功能通常被视作关键
20、的。恢复时间目标4. 不同企业的恢复时间目标可能不同，范围从中断后的一天之内到数分钟之内，非常重要的企业功能比其它企业要求有更快的恢复能力。原则 5：企业应该了解和适当地消减关键业务功能互相依赖的风险。1. 企业具有将风险和过程分散和分布在本地、区域内和全球范围的倾向。这使其增加了对其它团体（内部或外部的）的依赖。任何对互相依赖风险的不当管理都可能造成风险叠加而降低运行或系统效率，从而有可能损害企业的运行。2. 在制定关键业务功能的应急计划时，企业应该考虑到这些功能的相互依赖性及其相互依赖的程度。企业也应该了解支持这些关键功能的相关业务方法，尤其是业务永续运行计划准备和恢复优先顺序方面的。这些
21、依赖性的例子有： 企业中的 企业之间（如银保通） 对供应商（如灾难恢复服务供应商） 对基础设施提供者（如电信） 业务永续运行计划应该将复杂的依赖关系考虑进去并且尽可能地消减这些风险。这些依赖关系应该在制定恢复策略和恢复时间目标时做为考虑因素。3. 虽然有些依赖性风险不在企业的控制范围内而无法彻底消减（如无法使用电信网络），但是这并不能降低其客户和合作伙伴对企业服务和履行职责的期望。最终，依赖性风险将会落在企业身上而无法回避。所以，企业应采取合理的步骤消减这些风险（如同电信供应商讨论确保通信线路通过不同的交换局进行路由的问题）。4. 在与任何外部供应商签订合同之前，企业都应该确信外来风险在当前风
22、险策略可接受的范围内，并且不会破坏自己的业务永续运行计划。它们应该确定其服务供应商也有相应的应急计划，即使这些计划没有自己的业务永续运行计划准备的那么充分。企业还应该事先向其服务供应商寻求其业务永续运行计划得到定期测试的保证。5. 在外部供应商异常终止或破产的事件中，企业寻找其它合适的供应商并进行安置和部署可能要花费数月的时间，这样的过渡期风险是无法接受的。企业应该采取合理步骤以保持适当的控制水平并保留采取适当措施继续其关键业务运行和维护其业务永续运行计划不容破坏的权力。原则 6：企业应该为大范围中断情况制定计划。1. 911事件表明，企业应该为大范围中断情况制定计划。范围被定义为同一中断所影
23、响的可能区域 。企业考虑的因素还应该包括什么情况下关键人员可能会遭受严重损失或无法使用，什么情况下诸如电信这样的关键服务会大面积中断。企业应该在业务永续运行计划中考虑到多个区域中断的情况，考虑到各关键业务活动的水平、风险承受能力和风险管理策略。另外，它们还应该考虑到长期中断情况下对业务永续运行计划的范围进行扩大和深化的问题。2. 大范围中断可能会增加依赖性风险。同一区域的关键功能和服务提供者的相互依赖性应该得到适当消减。对于企业与客户、合作伙伴和服务供应商的主站点在同一区域的情况，其恢复站点之间应该安排有电信链接。这些链接应该得到测试。原则 7：企业应该采用分离策略来消减集中风险。1. 关键人
24、员和信息是难以快速替代的重要资产。当业务运行及其支持技术（IT设备和人员）被安排在同一区域时，企业应该评估其集中风险。例如，当今的许多企业设想将主站点的同一批人员用于在恢复站点对其关键业务功能进行恢复的工作。这在中断造成人员无法使用的情况下通常是行不通的。2. 所以说，既要消减集中风险和提高人员安全性，又不能损失业务处理和关键人员集中带来的高效率，这两者之间作出平衡是很重要的。在应对大范围中断的准备中，企业应该尽量采用以下三种关键业务功能的分离策略：第一：主站点和恢复站点分离。关键业务功能的主站点和恢复站点应在不同的区域内。第二：事务操作和IT操作分离。关键的事务操作和支持事务操作的IT操作应
25、该在不同的区域。例如，结算操作人员与其IT操作（包括IT设备和人员）应该在不同的区域。第三：功能内分离。部署在另外区域的一批工作人员用于接管关键业务功能。解决方案可能包括处于两个分离的操作地点的人员和得到交叉培训的另一个地点的人员。企业应该确定和设计减少集中风险的最适当的消减措施组合。2.4 结论综上所述，结合中国人寿IT战略规划和中国人寿IT架构的要求，我们认为中国人寿灾备中心的建设应按照如下策略进行： 灾备中心的建设需要得到高层领导的支持灾备中心的建设和运维需要大量人力、物力的配合，涉及到许多部门。没有企业高层领导的支持是不行的。 灾备中心的建设要满足业务的需求灾备中心的建设资金投入、功能
26、、处理能力、管理方式等必须满足目前的业务需求，同时还要兼顾未来发展的要求。 灾备中心需要建立高可用性的架构灾备中心启用后，就开始做为生产中心提供服务。因此灾备中心也应该与生产中心一样，对关键业务应用采用高可用性架构，以防止由于单点故障而引起宕机 灾备中心应该可以提供演习环境演习是保证业务永续运行计划有效性的重要手段，每年至少应该举行一次。演习环境是为了保证在演习是正常的业务处理仍能继续而建立的。 灾备中心的设备应该得到充分利用灾备中心的建设不仅要考率到紧急情况下的使用情况，还要考虑日常如何利用。例如，为了在平时提供灾备中心设备的利用率，可以利用灾备中心的设备进行应用的开发和测试。 灾备中心的建
27、设以用先进、成熟的方法论做为指导，分阶段进行先进、成熟的方法论为灾备中心建设的成功提供了保障。 灾备中心与生产中心使用结构相同的IT基础架构和管理流程这样可以大大降低管理与运行维护的复杂度。灾备中心的处理能力可以与生产中心不同，但是要满足业务需要。3 灾备中心建设的建议 根据中国人寿的未来IT架构，我们建议中国人寿建设一个灾备中心，以保证中国人寿因重大灾难事件而使一级数据中心无法继续提供服务时，继续为关键企业应用提供运行平台。我们的设计基于如下假设：由于连续性灾难（即主数据中心发生灾难尚未恢复正常运行时，灾备中心又因发生重大灾难而停止运行）发生的概率极小，我们在设计中不考率对于连续性灾难的恢复
28、问题。3.1 灾备中心的建设方案灾备中心的建设方案由两种：1. 建立一个独立的灾备中心2. 建立两个数据中心，两个中心之间互为备份但是，如果建立两个数据中心，管理流程会变得复杂，人员配备会增加，运行成本也会提高（例如，为了进行双向数据同步，要租用多条通信线路）。所以，我们建议采用第一种方案。 容灾备份系统建设内容 在灾备中心建设中，不仅要考虑数据中心端的容错，还要考虑对重要关键业务系统进行异地容灾备份和对重要数据的定时和实时备份。 灾备中心建设的内容包括： 1. 面向数据中心提供网络通讯设备、通讯线路、存储网络设备的全面容错和异地容灾。 2. 面向数据中心提供部分关键业务系统的容错和异地容灾。
29、 3. 提供数据中心和容灾中心本地数据备份。 3.2 灾备中心建设要求 灾备中心的建设须满足以下要求： 1. 备份中心与数据中心在地理位置上保持较远的距离(例如1000公里)，使得当数据中心遭受灾害破坏时，不会影响到备份中心。 2. 交通便捷3. 主要电信服务商可以提供语音及专用数据网络服务4. 机房环境要求与主中心相同5. 可以容纳足够的工作人员办公6. 备份中心的所有应用系统必须经过严格的测试，确保业务系统能够正常运行 7. 备份中心与数据中心间网络带宽应能保证两地间数据的可靠同步。 8. 备份中心计算机系统有足够的处理能力来接管数据中心的业务；同时应具有不低于数据中心的安全防护能力9.
30、重大灾难发生时，灾备中心和数据中心可以通过手工操作的方式切换10. 数据中心或灾备中心发生小范围事故时，系统在数据中心或灾备中心内部可以自动切换3.3 灾备中心的建设与数据中心的关系灾备中心机房建设的前提条件是 完成BIA分析和灾备中心IT基础架构设计 生产数据中心开始运行理由如下：1. 没有BIA的分析结果，无法明确灾备中心到底针对何种灾害设计，即无法决定灾备中心的物理地点2. 没有BIA的分析结果，无法决定中国人寿对灾备中心的投资规模3. 没有BIA的分析结果，无法确定灾备中心运行的核心应用种类及其对恢复时间和数据丢失量的要求；无法确定核心业务流程之间的依赖关系，也就是说无法明确核心业务应
31、用之间的数据传递关系及对数据完整性的要求，所以无法进行IT基础架构设计。4. 没有BIA的分析结果，无法确定中国人寿在发生灾难后所希望达到的服务标准，即是否关闭一些保险业务，是否关闭一些分支机构（如区县级机构），是否限制使用系统的用户数量，是否改变正常的业务处理流程等。这些都决定者与灾备中心相连的广域网布局如何设计。5. 没有IT基础架构设计，无法明确灾备中心需要的设备类型和数量，所以无法进行设备选购，无法得出对机房配电，空调，地板承重以及布线的具体要求6. 如果数据中心的应用部署没有最终完成，无法得到详细的应用之间的数据依赖关系，无法得到应用正常运行需要何种质量的数据，无法取得应用正常启动和
32、异常启动需要的时间，这些都是决定采用何种恢复技术的关键因素，也是衡量灾备中心的设计是否能够达到要求的恢复时间的重要依据。3.4 灾难恢复基本模式 1. 本地容错 本地故障、错误可以分为几种类型：网络设备宕机、服务器宕机、数据库宕机、存储设备宕机、线路中断、操作系统故障、应用系统故障、硬件设备故障、磁盘故障。本地设备和软件发生故障时，本地冗余和备份的设备和软件可以帮助恢复故障。 2. 异地容灾 大灾难包括：自然灾难（地震、台风、洪水等）、突发事件（业务系统中断、通讯中断、计算机病毒、计算机网络犯罪、火灾影响、恐怖活动）等。大灾难使得本地的网络、服务器、存储设备宕机，技术支持人员不能及时到现场恢复
33、，业务系统中断，从而造成重大损失和灾难。 异地容灾是在本地发生大灾难时由异地设备提供业务容灾恢复。高端异地容灾由本地运行中心和异地备份中心组成，异地备份中心具有本地运行中心的相同业务系统，两个中心的数据是同步的。在无大灾难时，本地运行中心正常运行。在有大灾难时，关键业务的客户端的请求自动被送往异地备份中心的服务器，而异地备份中心的数据库提供已同步的数据响应客户端的请求，从而保证数据的完整性和一致性，保证业务7天24小时不间断运行。中端异地容灾与高端异地容灾大部分相同，所不同的是对重要业务采用中端容灾硬件和软件，有数据丢失，业务短暂间断，投资成本较低。低端异地容灾可以对一般业务采用远端磁带库和磁
34、盘进行定期备份，业务恢复时间长，数据丢失多，投资成本最低。 3.5 省市灾备中心建设 由于未来中国人寿的核心业务系统和关键数据都集中在一级数据中心，省市级数据中心的数据量较少，主要是办公自动化数据，所以建议在省市级数据中心不建立灾备中心。影像系统虽然在二级数据中心，但是在一级数据中心保存有影像数据，所以二级数据中心发生故障时，用户可以使用一级数据中心的影像数据。地市系统先通过公司内部专用网络连接到二级数据中心，然后再连接到一级数据中心。当二级数据中心发生灾难无法工作时，地市用户可以通过因特网上的VPN直接与一级数据中心通信。3.6 机房建设请参照数据中心高端设计的相应章节。4 灾备中心的功能要
35、求如果灾备中心平时处于冷备份状态，那么为了更有效地利用灾备中心的设备，灾备中心除了担负灾难发生时的应急处理中心的任务外，在平时还可以做为应用开发中心使用。这要求用于应用开发的主机配有2套系统启动硬盘。灾备中心在平时做为开发测试中心基于如下假设：灾备中心在需要启动时，所有服务器冷启动就可以满足“恢复时间”的要求。4.1 灾备环境 平时，灾备系统的主机用于应用开发机，但应用数据必须保持与生产系统同步，这就要求应用数据要保存在基于硬件同步的磁盘阵列中。灾难发生时，用灾备系统的启动硬盘启动，系统进入灾备系统状态工作。4.2 开发测试环境 由于开发测试不稳定，经常会进行修改或者重新启动系统，所以要求开发
36、测试环境的数据与灾备环境的数据分开存储存储在不同的物理设备上或同一设备的不同分区上。开发测试环境还可以用作业务永续运行计划的演习环境。4.3 预生产环境 预生产环境主要用于系统正式投产前的验收测试。主要进行的是压力测试，系统联调等。其技术实现方面的要求与开发测试环境相同，即也需要独立的存储环境支持。4.4 演习环境为了更好的对实际情况进行模拟，建议演习环境与灾备环境使用统一运行平台。环境的相互切换通过使用不同的系统启动硬盘实现。演习环境应该有不同于灾备环境的磁盘空间存储演习用数据。例如，可以在演习前停止测试环境，并对测试环境的数据进行全备份。演习时使用原来测试环境使用的磁盘阵列。演习除了包含主
37、机系统的切换外，还应该包括广域网的切换，所以在演习前还应该通知相应的电信运营商做好配合。4.5 灾备中心功能示意图图 41容灾中心的功能如图4-1所示，一级数据中心内部有生产环境，运行维护环境，IT 服务管理环境和响应中心。响应中心的人员可以访问生产环境，IT服务人员 可以访问运行维护系统。二级数据中心有生产环境，运行维护环境和响应中心。二级数据中心的响应中心主要解决本地的故障，当遇到故障无法解决时，将问题转给位于一级数据中心的响应中心处理。灾备中心有开发组，应用支持组，开发环境，测试环境和预生产环境。当一级数据中心的响应中心有关于应用的问题无法解决时，将问题传递给位于灾备中心的应用支持组。应
38、用支持组也无法解决时，再将问题交给开发组。当有灾难发生时，停止开发环境，测试环境和预生产环境的运行，启动备份生产环境。同时响应中心，IT服务管理环境和运行维护环境也切换到灾备中心。5 灾备中心设备、网络性能要求 5.1 灾备中心的容量灾备中心的处理能力受到几方面的制约： 运行与灾备中心的关键应用系统的数量 灾备中心运行时的联机系统用户的数量 灾备中心运行时能够提供的应用系统响应速度所以灾备中心的容量必须等到业务影响分析完成后才能明确。容灾中心的设备要与数据中心的设备兼容，具体配置通过下述述手段获得：1. 根据对处理性能的要求并参照数据中心的配置给出初步建议2. 搭建测试环境进行测试（兼容性测试
39、和压力测试）3. 对初步建议进行调整，给出最终建议现假设灾备中心只有保险核心应用、财务系统、销售支持系统、客户服务系统和电子商务系统，且灾备中心这些应用系统的处理能力与生产系统相同。5.2 恢复时间的要求RPO（Recovery Point Objective）：即数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。 RTO（Recovery Time Objective）：即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。 RPO针对的是数据丢失，而RTO针对的是服务丢失，二者没有必然的关联性。RTO和RPO的确定必须
40、在进行风险分析和业务影响分析后根据不同的业务需求确定。对于不同企业的同一种业务，RTO和RPO的需求也会有所不同。RPO和RTO是业务影响分析的结论之一。恢复时间是指从确认生产中心切换至灾难中心到灾难中心接替生产中心工作的时间。 而RTO的实现以以下两个主要方面为前提条件： 第一，实现灾难恢复的主要步骤及操作模式。包括：由灾难中心主管确认灾难的确发生；在灾难中心主机作断点分析，查明交易情况；完成网络物理切换（手工或自动）；启动灾难中心主机应用系统（手工或自动）；主机系统重新与分支机构连线，完成灾难中心切换任务。 第二，灾难恢复有关制度及运作模式的建立。包括灾难恢复的运作完全采用实时自动方式，及
41、灾难恢复的运作采用人工干预与部分自动相结合的方式。可见，RTO不仅受到技术的影响，还跟管理流程和具体的业务操作密不可分。所以，目前我们尚无法估计出符合中国人寿实际情况的RTO指标。5.3 体系架构容灾的体系架构不仅要能处理单点故障，还要能处理多点故障，甚至能处理数据中心、整个企业甚至某一区域性的灾害。能够抵御多点故障甚至区域故障的集群结构是一种特殊的集群结构，称为容灾体系架构。这种架构可以提供灾难发生后的自动切换或者手工切换功能。一般来说，只有当整个数据中心都失效时，才启动切换功能。在地理位置上分离的容灾体系架构可以对非计划的停机提供保护，因为一个地点的故障影响不到另一点。为了能评估不同的容灾
42、方案需要知道： 灾难的风险。需要针对台风，洪水还是地震设计容灾方案。要应对什么样的灾难，决定了选择什么样的容灾方案。例如，如果所在地易发生地震，那么另一处容灾站点就不应选择在相同的城市，因为地震会影响相当大的区域。另外，灾难发生的频率也影响是否选择一个快速的恢复方案。例如，可能会针对每个季节都发生的飓风设计一个快速恢复方案，而不会针对100年都没有喷发的火山设计方案。 业务的弱点。业务到底能承受多长时间的宕机？一些业务也许可以承受1或2天的恢复时间，而另一些业务可能需要在几分钟内恢复。一些应用可能只需要提供本地保护，另一些应用可能既需要本地保护，又需要具有远程容灾功能。重要的是要考虑容灾中心担
43、任的业务角色。例如，生产线生产可能需要非常快的恢复速度。但是，如果最容易发生的灾难是地震，生产线和为生产线服务的计算机会在灾难中同时损坏，在这种情况下，容灾就没有什么必要了。而实现本地切换会更有意义。又如，订单处理中心是完全依靠计算机工作的，为避免灾害对这些设备造成损害而造成业务停顿而建立灾备中心是有意义的。决定采用什么容灾方案需要权衡灾难风险和在灾难发生时的业务弱点。针对不同的需求有不同的方案，但是无论什么容灾方案都会遵循一些基本原则： 通过地理位置上的分离保护节点 通过复制保护数据 使用冗余电源 建立高可用性网络这些指导原则还要加上标准的高可用性原则，例如采用冗余的物理访问通道（主机到磁盘
44、阵列的连接）、网卡、电源和硬盘。容灾中心的数据复制方式的选择与应用的RPO密切相关。 对于RPO要求低的应用（例如，一天以上），可以采用磁带备份的方法进行数据复制。这种应用对于生产中心与灾备中心之间的网络连接无要求。 对于RPO要求较高的应用（例如，几个小时），可以采用异步数据同步的方式 对于RPO要求高的应用（例如，几分钟），可以采用同步数据同步的方式针对数据同步方式（同步或者异步），有两类方案1. 采用基于主机上运行的软件进行要求生产中心与灾备中心之间有高速IP网络2. 采用磁盘阵列进行要求生产中心与灾备中心之间有高速存储网络容灾的体系架构可以分成以下三种： 校园容灾 包含多个建筑物 可以
45、自动切换的单一集群结构 不同站点间的磁盘镜像图 51校园集群体系架构 城市间容灾 本地网络和磁盘保护优先 可以自动切换的单一集群结构 站点间使用物理数据复制图 52城间集群体系架构 广域容灾 租用的高速交换网络 (用于数据链路) 多集群架构 站点间可以采用物理数据复制或逻辑数据复制 物理数据复制是指利用硬/软件进行的磁盘裸设备复制 逻辑数据复制指利用文件系统或数据库进行数据复制图 53广域集群体系架构数据同步技术及相关指标：技术手段RPORTO磁带备份几小时几星期硬盘间在线复制映像（快照）几分钟一天异步复制几秒钟几分钟同步复制0几秒钟基于广域网的集群几分钟一天磁带恢复几天几星期表 51技术手段
46、与RPO、RTO的对应关系不同业务类型的服务级别：Gartner根据业务类型的不同，提出了如下的RTO和RPO要求（参见Best Practices and Trends in Business Continuity Planning2002年版）。级别业务服务级别一级 直接面对客户或者合作伙伴 对企业收入和正常生产有严重影响 提供24X7服务 可用性达到99.9%(停机时间45分钟/月) RTO=2小时；RPO=0小时二级 供应链 对企业收入和生产有一定的影响 可用性达到99.5%(停机时间3.5小时/月) RTO=8-24小时；RPO=4小时三级 企业后端应用 可用性达到99%(停机时间5.5小时/月) RTO=72小时；RPO=24小时四级 部门