IBM的容灾白皮书

iPod

4.2灾难恢复计划项目阶段\r\n\r\n如何制订灾难恢复计划，前面的章节中（参看3.1节 业务连续性）给出了指导性的建议步骤。上述步骤中，每一步都包含了相关方面的各项内容。实际上，在制定灾难恢复计划时，我们可以将这些步骤细化为下图的操作流程。在下图的流程中，包含了灾难恢复计划的各个阶段，并直观的告诉我们，灾难恢复计划的制定是一个循环往复的过程。\r\n\r\n\r\n\r\n图1. 灾备计划不同阶段图表\r\n\r\n对上图的简单分析如下，更详细的内容，将在以下的章节中给出：\r\n\r\n1） 项目启动及项目组的选择\r\n此阶段包括取得管理层的正式同意、选择项目协调人员和项目组成员、信息收集方式的标准化以及项目资源的调度等方面的内容。\r\n2） 数据收集和需求分析\r\n此阶段包括收集业务过程的信息、技术基础架构的支撑环境、潜在的停机费用消耗、灾难类型以及其它公司使用的相应技术和策略等方面的内容。\r\n3） 风险分析\r\n在风险分析阶段，我们将对为达到灾难恢复计划的设定目标收集的数据进行处理，以便对风险以及在可接受的时间范围内恢复所需要的资源有较深的理解。\r\n作为风险分析的结果之一，灾难防范技术的实施可以帮助我们防止可以避免的灾难。比如：火灾的侦测和防止，不间断电源系统等。\r\n4） 数据保护\r\n数据保护是灾难恢复计划中的关键模块。必须清晰、完整地表述出各类数据（记录、胶片、电子及光学数据等）的保护方法。\r\n5） 恢复计划\r\n恢复计划是指对意外事件所采取的策略及明确的规划。如替代的系统、网络和终端用户。\r\n6） 培训和测试\r\n培训和计划性的测试可以对所设计的灾难恢复策略进行测试，并且提供了一种可以对灾难恢复计划中的不足方面进行发现和修改的手段。\r\n7） 计划的维护管理\r\n计划的维护管理提供了一种机制，可以使灾难恢复计划随着业务和IT系统架构的改变而改变。\r\n\r\n下面我们对各个阶段给出较详细的解释。\r\n项目启动和项目组选择的阶段可细分为以下几个主要组成部分：\r\n1 最高管理层的承诺\r\n企业的最高管理层必须支持且参与计划的制定和协调，以确保灾难恢复计划在本公司内的有效作用。制定一个有效的计划，必须要有时间和资源的保证，时间就是计划的制定所需要的时间，而资源则包括预算和人力。\r\n2 建立计划制定委员会\r\n计划制定委员会负责监控计划的制定和实施，由公司各个部门的代表组成，关键的委员会成员应当包括业务运营经理和数据处理部门经理。委员会还应当定义计划的适用范围。委员会的另一个职责是定期把项目信息通知给最高管理层，因为这是一个比较敏感的主题，可能需要花费较多的人力和财力，这些都需要最高管理层来支持。\r\n3 范围\r\n尽管大多数灾难恢复计划只包含数据处理相关的项目，但是一个复杂的计划也包含数据处理以外的操作领域，如果同时考虑到灾难的其它方面，灾备计划涉及的范围是相当广泛的。\r\n4 假定\r\n制定计划要考虑的最基本问题就是设想最坏的场景。对运营系统而言，最坏的场景就是主要设备的损坏。计划的制定就是基于这样一个前提，每一个灾难恢复计划都基于一组假定的设想。这些假定对计划所涉及的环境做了限制，这些限制定义了公司准备接受的灾难量级，它们可以通过以下问题来识别：\r\n\r\na） 哪些设备被破坏\r\nb） 中断的时间是多少\r\nc） 哪些记录、文件和资料需要保护\r\nd） 灾难发生时，哪些资源是可用的\r\n       1） 员工\r\n       2） 设备\r\n       3） 通讯\r\n       4） 传输\r\n       5） 后备场地\r\n在制定灾难恢复计划时，可以借鉴以下典型的假定：\r\na） 公司主要的生产设备被破坏\r\nb） 拥有在可以执行计划之内的关键性功能的员工\r\nc） 员工可以被通知到，并且可以到备份地点执行关键性的恢复和\r\n重建工作\r\nd） 灾难恢复计划是可用的\r\ne） 部分计划可用于恢复相应的环境中断\r\nf） 备份设备是可用的\r\ng） 在异地或别的设备中保存有足够多的备份\r\nh） 备份地点可以处理公司的工作\r\ni） 公司本地和远端的通讯链路是可用的\r\nj） 本地基本的传输是可用的\r\nk） 灾难发生时，供应商应根据承诺对公司提供支持\r\n以上的假定并不包含全部可能性，但在计划制定的开始阶段可供大家参考。\r\n5 项目组及其责任\r\n灾难恢复计划可以按照组的形式来制定，特定的任务可以分配给特定的组。意外发生时的公司架构可能与现有的架构有所不同，那时通常是以组为基础，不同的组负责不同的功能领域，这些组可能包括：\r\na） 管理组\r\nb） 业务恢复组\r\nc） 部门恢复组\r\nd） 计算机恢复组\r\ne） 损坏评估组\r\nf） 安全组\r\ng） 设备支持组\r\nh） 后勤支持组\r\ni） 行政支持组\r\nj） 用户支持组\r\nk） 计算机备份组\r\nl） 异地数据存储组\r\nm） 软件组\r\nn） 通讯组\r\no） 应用组\r\np） 人力资源组\r\nq） 市场和客户关系组\r\n\r\n企业并不需要建立以上所有的这些组，但我们强烈建议与上述的每个组相关联的功能都能被包含在其中。\r\n\r\n根据员工的技能和领导能力，可以将其选入不同的组。一般来讲，各组的成员所拥有的技能应与其平时的工作相一致。例如，服务器恢复组的成员应当包含系统管理员。组成员不仅要知道计划的目的，而且要知道执行恢复策略的过程。考虑到可能会联系不到某些成员的情况，成员的组建应基于“互有备份”的原则。同样，成员也应当了解其它组的目的和执行过程。\r\n\r\n每一个组由组长领导，组长要负责本组的运行，承担同其它组的协调工作，向组员及时传达需要的信息，并在组内做决定。另外，如果组长不能行使其职能，必须指定代理组长。在灾难恢复计划中，最重要的组是管理组。他们在事故发生时负责协调所有组的工作。管理组一般由高级管理经理负责，如CIO。\r\n\r\n以下是各个组的主要职能：\r\na） 负责计划的执行\r\nb） 促进与其它组之间的交流，监督计划的测试和执行\r\nc） 所有或是某一个成员可能领导特定的组\r\nd） 协调恢复过程\r\ne） 评估灾难，执行恢复计划，联系组长\r\nf） 监控并记录恢复的过程\r\ng） 是最终决定优先级设置、各种政策和过程的人\r\n\r\n4.3数据收集和关键需求分析阶段 \r\n\r\n要确定一个企业的关键性需求，每个部门应该将本部门执行的功能文档化，经过一定的分析来确认部门内部和外部的主要职能。\r\n\r\n部门的日操作记录可以对确定关键性需求起到辅助作用。以下是一些辅助问题：\r\n\r\n1） 如果灾难发生而没有现有的设备和部门架构，部门能运转多长时间？\r\n2） 在部门内，什么任务的优先级最高？（包括关键的手工功能和处理）这些任务 被执行的频率是多少？如每天、每星期或每月等。\r\n3） 执行最高级别的任务，需要那些人力、设备、和供应等？\r\n4） 对于关键的设备及供应，在灾难的环境中应如何替换？\r\n5） 上述这些关键信息的替换需要多长时间？\r\n6） 部门内有没有可供参考的手册和操作步骤？灾难发生时这些是如何替换的？\r\n7） 任何供应、设备和操作过程或手册等，有没有在异地存放？\r\n8） 确定原始文档的存储设备和安全性。在灾难的时间中，这些信息如何被替代？有没有更多的地方来保存？\r\n9） 当前计算机的备份过程是什么？如何恢复备份？任何关键的备份拷贝有没有在异地存放？\r\n10） 在灾难发生后，临时性的操作步骤是什么？\r\n11） 一个部门的运转中断，对其它的部门有什么影响？\r\n12） 依赖于正常运转的企业以外的服务商和供应商有哪些？\r\n13） 有没有经过跨部门培训的人员？\r\n14） 谁负责维护部门的异常计划？\r\n15） 灾难恢复计划有没有其它的考虑？\r\n\r\n在上述问题的基础上，我们列出了以下需要进行文档化的信息：备份地址列表，关键电话号码记录，通讯目录，分发记录，文档目录，设备目录，表格目录，保险政策目录，主要的计算机硬件目录，主要客户列表，主要供应商列表，计算机硬件和软件列表，通知列表，办公用品供应列表，异地存储地址列表，软件和数据文件备份和调度，电话目录等资料和文档。\r\n\r\n关键性需求可以通过问卷的方式来获得，问卷主要是将每个部门的关键性工作记录在案，并找出最小的必备资源，如人力、设备、供应商、文档等资源。\r\n\r\n确定了各部门的关键性需求并将其文档化以后，管理层就可以为各部门在整个企业的灾难恢复过程中设置优先级别。每一个部门的操作可以按照下面的方式给出优先级：\r\n\r\n1） 基本操作（必需）：服务中断超过一天，将严重地危害到公司的运转。\r\n2） 推荐操作（关键）：服务中断超过一个礼拜，将严重的危害到公司的运转。\r\n3） 其它操作（非关键）：这些信息的存在可以方便业务操作，如果 一旦丢失也不会 影响到业务的正常运转。\r\n\r\n根据RTO和RPO的不同，各公司采取的策略也会有所不同。以下是一些通用的标准，可以根据这些标准将应用进行分级：\r\n\r\n1） 必需：从停机算起，RTO<8小时，RPO在15分钟以内\r\n2） 关键：从停机算起，RTO<72小时，RPO从停机的那一天开始\r\n3） 非关键：从停机算起，RTO<168小时，RPO48小时以内

iPod

4.4风险分析阶段 \r\n\r\n计划小组负责准备风险管理的流程和业务影响的分析（Business Impact Analysis）。它们包括一定范围内的灾害，如自然、技术或人为的灾害。\r\n\r\n针对于几种假定的灾难设想，企业的每一个职能领域都应当分析和判断相应的潜在结果和影响，在风险分析阶段还将评估关键文档和重要记录的安全性。\r\n\r\n在多样的中断过程中，IT系统更容易受到损害。作为企业风险管理的一部分，有些风险是可以通过技术、管理和操作执行方案来避免的，但不可能避免所有的风险。灾难恢复计划就是一种用来弥补这些风险管理和安全操作不能涉及的灾难的高可用性方案。由此看来，灾难恢复计划可以提供一种紧急事件发生后的快速恢复手段。\r\n\r\n4.4.1风险管理过程\r\n\r\n风险管理过程范围广泛，包括确定、控制和减轻IT系统的潜在风险。从风险管理的行为分析，可以分为两个大的主要功能：\r\n\r\n1） 通过减少或消除风险，进而避免或减少破坏性的事件。这些措施主要是对从自然、 人为和技术方面的威胁进行的安全控制，从而减少或消除风险。\r\n2） 降低或限制灾难对系统造成的后果。主要措施是预估可能的事件，并在相应的事件\r\n发生后采取相应措施，建立基本的灾难恢复计划。\r\n下图示意了预先采取安全控制和灾难恢复计划实施的事件间流程：\r\n\r\n\r\n4.4.2商业影响分析\r\n\r\n商业风险分析是灾难恢复计划过程中的重要步骤，隶属于风险分析阶段。这一过程集中分析系统需求、过程及其内部的依赖关系，并使用这些信息判断可能意外发生的事件及其优先级，图示为风险分析的示例过程：\r\n\r\n\r\n上图的示例分为三个过程：\r\n1） 确定关键资源\r\n2） 确定中断的影响及允许的停机时间\r\n3） 设计恢复的优先级\r\n\r\n4.4.3建立可靠的系统\r\n\r\n业务恢复计划的目的是保证员工和设备在灾难发生过程中的安全。风险分析的主要目的之一是确定在任何时候应采取的正确防范措施。对灾难的防范和准备工作应从企业的最高管理层开始，管理层的支持体现在对先进的安全和风险防范技术的选择，以及对未知风险的准备等方面。灾难预防技术包含两个方面：流程方面的预防和物理方面的预防。\r\n\r\n1 流程方面的预防\r\n\r\n流程方面的预防与日常的操作相关，主要是操作规则的定义，相关主题为安全和恢复。流程防范是同每一个员工的行为相联系的，公司为每一个员工分配相应的职责。流程防范的目标是针对于不同的灾难类型定义相应的操作，并使得这些操作成为规则\r\n\r\n2 物理方面的预防\r\n\r\n从场所的建造就开始为灾害做准备，包括为建筑物配备特殊设备。如为不同的设备配置火灾保护。这些特殊的考虑包括：计算机区域设置，火灾侦测装置和灭火装置，记录保护，空调设备，热敏和通风设备，电子供应系统和UPS系统，双路电源保护，突发事件过程和档案系统。\r\n\r\n4.5 数据保护阶段\r\n\r\n数据保护是指在公司内部为保护公司资产、确保记录的准确性和可靠性以及操作的有效性而采取的措施。可以从履行保险和分类记录各种信息两个方面来考虑。\r\n\r\n  \r\n4.6 恢复阶段\r\n\r\n恢复计划是一种主要考虑在灾难发生后，如何快速有效的恢复IT系统的策略，策略的制定应当考虑商业影响分析中所涉及的风险，而且在系统设计和实施的阶段中，它与系统的架构设计相集成。在设计恢复计划时，应考虑下面的情况：\r\n\r\n1） 系统恢复\r\n系统恢复应针对于关键应用主机，如集中式和分布式\r\n2） 网络恢复\r\n网络恢复计划主要针对以下方面：\r\n     a） 关键商业应用系统的内部局域网和网络设备的支持\r\n     b） 外部广域网和电信服务\r\n     c） 待恢复系统和终端用户间的通讯\r\n     3） 启动各灾难恢复小组\r\n灾难恢复管理组负责协调恢复过程中所涉及的各个项目组。在异常情况下，准确快速的决定会起到关键的作用。管理组将负责包括财务决定在内的所有决定。成功的灾备计划，即使在关键的成员不能工作的情况下，也可以恢复并维持业务的运转。\r\n4） 最终用户恢复\r\n最终用户的恢复计划，在传统的灾备计划中常常被忽略掉，合理的灾备计划为终端用户提供了一种可工作的机制\r\n\r\n4.7测试和培训阶段\r\n\r\n灾备计划的测试是灾备方案准备过程中的一个关键要素。测试可以暴露灾难恢复计划的不足之处，测试也可以帮助我们评估计划执行人员的快速响应能力和效率，灾难恢复计划的每一个要素都必须测试，保证其恢复过程的准确性。测试包含以下几个方面：\r\na） 从备份磁带恢复系统\r\nb） 执行恢复计划的各项目组之间的协调\r\nc） 内部和外部的互连\r\nd） 使用备份设备时的系统性能\r\ne） 正常业务操作的恢复\r\n\r\n这里所推荐的测试过程是让灾难恢复计划的关键人员重复执行灾难恢复计划，这样做可以不断更新文档，并修补可能的遗漏，以保证即使主要人员休假，灾难恢复计划也可以执行。\r\n\r\n培训是对测试过程的补充，主要目的是明确灾难恢复计划中各成员的责任，培训内容包括：\r\na） 计划的目的\r\nb） 跨项目组的协调和沟通\r\nc） 汇报制度的流程\r\nd） 安全要求\r\ne） 项目组特有的流程\r\nf） 成员的责任\r\n4.8 维护和修改阶段\r\n\r\n灾难恢复计划应反映系统的需求、执行的流程和规则。因为商业需求、新技术的不断升级以及新的内部和外部规则的变化，IT系统也会随之改变。所以，要确保灾难恢复计划的有效性，就必须定期的检查和修改计划。一般来说，当每年或当计划涉及到的内容有重大改变时，灾备计划需要作相应的检查，而有些内容更需要作频繁的检查，如人员的联系途径等。以下是至少需要定期检查的几个方面：\r\na） 运行环境要求\r\nb） 安全要求\r\nc） 技术程序\r\nd） 硬件、软件和其它的设备\r\ne） 各项目组的成员名称及联系方法\r\nf） 关键信息记录（电子或书面文档）\r\n\r\n4.9选择灾难恢复方案的步骤介绍\r\n\r\n本节主要介绍制订灾难恢复方案的简单过程，仅供参考。\r\n\r\n1） 按照一定的顺序询问特定的问题\r\n按照一定的顺序，询问一系列与商业灾备需求相关的问题，通过这些问题，可以确定灾备方案的基本环境、基础构件及期望的恢复时间。以下提供一些基本的问题，部分问题答案的给出需要基于风险评估和商业影响的分析。另外一些问题则需要运营部分基于其IT基础架构给出答案：\r\n     a) 哪个或哪些应用需要恢复？\r\n     b) 应用运行的平台是哪些平台？\r\n     c) 期望的RTO是什么？\r\n     d) 灾备实施场所之间的距离？\r\n     e) 连通方式，或者在灾备地点传输数据的基础架构的传输   方式是什么？带宽是多少？ \r\n     f) 有没有特殊的硬件和软件的配置需要恢复？\r\n     g) RPO是什么？\r\n     h) 需要恢复的数据量有多少？\r\n     i) 期望的灾难恢复层次（计划/未计划/交易集成）？\r\n     j) 谁来设计灾备方案？\r\n     k) 谁来实施灾备方案？\r\n\r\n以上并不是所有可能的问题，但这是一个很好的开始，你可以设计其他一些问题，这些问题是如何使用的呢？参考下图：\r\n\r\n\r\n以上模型称为沙漏模型，在沙漏瓶颈以上的问题定义了基本的业务和IT需求，这些基本的问题必须有充分的答复，因为任何问题的缺少都意味着我们要投资的方案可能会没有正确的评估。采用这样的方式，在灾备方案实施前可确保收集到正确的业务和IT基础架构的需求。\r\n\r\n我们必须保证这些问题的答案已经广泛征求了企业管理部门、商务部门、应用组合IT维护组的意见。\r\n2） 使用层/RTO（Tier/RTO）和恢复的层次定位灾备方案的子集\r\n\r\n现在我们可以定义初步的方案，注意：在灾难恢复的七层中，一层总是建立在前一层的基础之上。对应于计划停机、非计划停机和交易一致性，相应的灾备技术和方案也有所不同：\r\n   计划停机：这一方案只有助于计划中的停机或者数据移植，对非计划的停机没有作用。\r\n   非计划停机：在硬件和数据一致性的层面，这一方案有助于非计划停机的恢复，也意味着支持计划停机。在应用和数据库层面，这一层次的恢复不支持交易一致性的恢复。\r\n   交易一致性：对于非计划的停机，方案要求在应用和数据库交易一致性的层面提供恢复的能力。这一方案隐性要求硬件层次支持计划停机和非计划停机。\r\n\r\n确定了合适的恢复层次、结合RTO、参考下图，可以很快的确定需要的灾难恢复方案。\r\n\r\n\r\n3） 排除非方案的东西\r\n\r\n现在我们通过把第一步中收集到的问题答案应用于候选的方案并剔除不合适的方案，来定义初步、候选的灾难恢复方案。请参考下图：\r\n\r\n\r\n通过第一步中获得的问题答案，如距离、不支持的平台等，可以剔除不符合要求的方案。\r\n\r\n如果在这一步骤完成后存在多个灾备方案，这都是正常的，它们都是可用的方案。\r\n\r\n4） 将确定的方案提交给评估组\r\n\r\n经过第三步后，将一组初步的灾备方案和可用的技术提交给资深的评估组，这个组由一些资深的成员组成。他们将详细的比较和分析这些备选方案，同时对有效的候选方案注明所需要的技能。\r\n\r\n评估组需要充分详细的配置每一个候选方案。最后，评估组将决定最终选择最合适的灾备方案。

iPod

第五章 典型方案介绍\r\n   \r\n \r\n   \r\n 基于软件的数据备份技术  |  HACMP高可靠性灾备方案  |  基于磁盘系统的PPRC数据级灾难备份解决方案    \r\n \r\n \r\n \r\n \r\n\r\n5.1 基于软件的数据备份技术\r\n\r\n在应用软件进行灾难备份的解决方案中，应从下面三个层次考虑：\r\n   用户应用程序 \r\n   客户机软件\r\n   数据库引擎\r\n\r\n其中用户应用程序和客户机软件一般不包含关键数据，几乎所有数据都由数据库引擎管理并放置在数据库服务器中。在这三者之中，数据库中的数据保护最为重要。\r\n\r\n一般情况下，用户应用程序和客户机软件只需要将其执行代码和参数配置文件做以备份，当灾难发生时，可以通过这些备份重新安装和配置用户应用程序和客户机软件。\r\n\r\n对数据库的备份，如果采用硬件级灾难备份有两种方法：一是采用备份的方法，即定期地将数据备份到硬盘和磁带/磁带库上，这些磁带可以通过运输的方式运到远程，以防磁带在本地的灾难中发生毁坏。这种方法的缺陷是实时性较差，恢复时间较长；另一种做法就是硬件镜像的做法，这种做法在硬件的投资上较大，对两点间的网络带宽有较大的要求。那么，有没有一种两者兼顾的解决方案呢？数据库产品提供的数据库复制技术就是一种两者兼顾的灾难备份解决方案。在前面提到的灾难恢复方案的7个层次中属于第5或第6层次。\r\n\r\n数据库复制技术在数据库级别的灾难备份解决方案中可以实现远程容灾。目前已有的产品有IBM DB2 HADR、IBM INFORMIX HDR以及ORACLE DATA GUARD。\r\n\r\nIBM DB2 HADR是High Availability Disaster Recovery 的缩写，HADR 将HA（高可用性）和INFORMIX DR的技术紧密结合起来。INFORMIX HDR是High Availability Data Replication的缩写。\r\n\r\nHDR的工作原理是通过将主数据库服务器（简称为A）的逻辑日志缓冲区复制到备份数据库服务器（简称为B），而且能在主数据库服务器操作失败时自动切换到备份数据库服务器。复制方式有同步方式和异步方式两种。我们将在下面详细介绍HDR的工作原理以及同步方式和异步方式。\r\n\r\n\r\n正常状态下，主数据库服务器做数据库的读写操作，备份数据库服务器为只读方式。当主数据库服务器失败时，备份数据库服务器会自动接管主数据库服务器的事务处理。此时，备份数据库服务器作为主数据库服务器进行数据库的读写操作。当主数据库服务器被修复后，主数据库服务器作为新的备份数据库服务器。\r\n\r\n\r\n\r\n此时备份数据库服务器虽为只读方式，但并不是空闲的。它可以分担主数据库服务器的负载，例如执行查询、出报表等任务。\r\n\r\n\r\n\r\n数据库复制对硬件的要求相对较低，只要主数据库服务器和备份数据库服务器的硬件配置相同即可，不是必须使用高端存储设备，例如IBM ESS等。主数据库服务器和备份数据库服务器的距离不受限制，而且对网络的压力并不大，但需要更强的数据库管理能力。 \r\n\r\n下面介绍一下HDR的工作原理。如下图所示：\r\n\r\n\r\n在逻辑日志缓冲区（Logical Log buffer）刷新之前，它里面所有的交易（Transaction ）将拷贝到数据复制缓冲区（Data Replication Buffer）。数据复制缓冲区的大小和逻辑日志缓冲区相同。数据复制缓冲区通过TCP/IP网络将数据发送到备份数据库服务器的数据复制缓冲区中。在备份数据库服务器端，一个数据复制线程接收数据复制缓冲区的数据并把他们放入到恢复缓冲区（Recovery Buffer）. 另一个数据复制线程（或一些线程）记录数据库日志信息。主数据库服务器和备份数据库服务器都有一个“Ping”线程在运行，它会定时唤醒并且检查两个数据库服务器的连接。如果任何一台服务器上的“Ping”线程检测到连接中断，都会发一条出错信息到消息日志中。\r\n\r\nHDR有两种复制方式：同步方式（Synchronous）和异步方式（Asynchronous）\r\n\r\n\r\n\r\n在同步复制的方式下，主数据库服务器的逻辑日志缓冲区只有在下面的过程完成后才可以刷新：\r\n\r\n1. Copy: 逻辑日志缓冲区数据拷贝到数据复制缓冲区；\r\n2. Send: 数据从主数据库服务器的数据复制缓冲区通过网络传送到备份数据库服务器；\r\n3. Acknowledge:当备份数据库服务器接收到数据后发回确认信息；\r\n4. Flush: 此时，主数据库服务器才可以刷新其逻辑日志缓冲区的数据。\r\n\r\n采用同步方式的优点是两边数据库服务器的数据一致，但是由于每笔在主数据库服务期提交的交易需要发送到备份数据库服务器而且得到确认后才算真正成功完成，由此而产生的时间延迟会使性能受到一定的影响。\r\n\r\n如果采用异步复制方式，主数据库服务器的逻辑日志缓冲区只要在逻辑日志缓冲区的数据拷贝到数据复制缓冲区之后就可以进行刷新了。这样做的缺点是在某些系统失败的情况下，可能会有一些数据还没有来得及通过网络传送到备份数据库服务器；优点是主数据库服务器的性能不受影响。\r\n\r\n对于Oracle DATA GUARD的工作原理，大致上与IBM HADR 和INFORMIX HDR的工作原理类似。\r\n\r\nOracle9i DATA GUARD 通过使用称为备份的数据库来防止数据灾难的出现。它通过将源数据库的重做日志传输并应用到备份数据库中，来使备份数据库与源数据库同步： \r\n   可以将重做日志直接从源数据库同步的写到备份数据库，来完成零数据损失的灾难保护，这会给源数据库的性能带来一定的性能损失。\r\n   可以将归档的重做日志从源数据库异步的写到备份数据库，来使源数据库在极少的损失性能的前提下，最小化地减少数据的丢失。 \r\n   如果重做日志数据到达备份数据库后就快速应用到备份数据库，则在源数据库出现问题时便可以快速地切换到备份数据库。然而，如果延缓一定时间后再应用重做日志数据，就可以避免源数据库的错误快速地传播到备份数据库。 \r\n\r\nDATA GUARD同样也有同步和异步复制两种方式可以选择。

iPod

5.2 HACMP高可靠性灾备方案\r\n\r\nHACMP容灾系统在世界范围内广泛应用，具有以下鲜明的特点：\r\n\r\n   简单易用，7x24小时集群应用技术\r\n   显著减少停机时间，允许不间断的进行集群升级和系统维护\r\n   提供多种数据备份和恢复途径，以满足灾备的需求\r\n\r\nHACMP经过十多年的发展，从5.1版本开始，增加的一项新的功能HACMP/XD支持ESS/PPRC和基于IP连接的远端故障切换。\r\n\r\n5.2.1 A.HACMP方案\r\n\r\na) 介绍\r\n     HACMP对关键应用提供良好的保护，提供可信赖的高可靠性服务、监控能力和对应用的失败监测，切换应用环境到备份主机。借助于HACMP/XD功能，也可以将应用切换到远端备份机器。\r\n     在集群中，HACMP使用冗余的硬件配置以保持应用的正常运行，在需要时将应用切换到备份主机，最多可以有32台服务器组成HACMP集群。HACMP也可以监测应用的错误，但这些错误应当不足以影响到系统的正常运行，如进程失败、系统资源消耗过大等。对这些错误事件，HACMP监控、发现并采取相应的措施以保证系统的运行。HACMP可配置为响应几百个系统事件。\r\n     事实上，使用HACMP可以防止一些计划中的停机，如在停机维护的过程中，用户、应用和数据可以转移到备份主机。HACMP可以满足复杂的、各式各样应用的可靠性及其恢复的需要。\r\n\r\nb) 优势\r\n     HACMP充分利用了AIX操作系统的优点，并拓展了AIX系统和网络的管理功能，提供了横向和纵向的灵活性。\r\nc) 功能增强\r\n     IBM HACMP在5.1的版本中，功能进一步增强，这些新的功能包括：\r\n     1) 使用快速硬盘接管技术，减少切换时间，限制在10秒钟之内\r\n     2) 使用流水式配置界面，仅仅需要六次输入就可以配置一个简单的 HACMP集群\r\n     3) 基于硬盘的新的非IP心跳信号保护技术，不需要额外的硬件支持\r\n     4) 增强的安全机制，剔除了对.rhosts的要求\r\n     5) 增加快速的集群配置确认和同步技术，提高管理的效率\r\n     6) 在集群的监控中提供更多的集群状态信息\r\n     7) 增加灾难恢复技术，保证在灾难发生时系统是可控制的\r\n\r\n5.2.2 B.HACMP/XD\r\n\r\n在灾备方案中，如果需要在异地做数据镜像，HACMP/XD（Extended Distance）是必选的功能。对中小企业而言，HACMP/XD的高可靠性解决方案是极具吸引力的，从成本上看，也是可以负担的。在关键的商业应用中，高可靠性是最基本的功能。\r\n\r\nHACMP/XD提供了多项技术以满足远距离的数据镜像、切换和信息同步：\r\n     a) 支持IBM企业级存储服务器ESS的PPRC，即HACMP/XD over PPRC。这允许HACMP集群自动的切换PPRC镜像组（PPRC pairs）中的硬盘，可以设计基于ESS PPRC的强大的容灾方案。HACMP/XD结合PPRC，可以保证集群环境中关键数据始终可用。 \r\n\r\n下图为HACMP/XD PPRC方案的示意图：\r\n\r\n\r\n    b) HACMP/XD基于IP的镜像，提供远端数据镜像，没有距离限制，集成使用HAGEO 的技术。基于IP的镜像技术，允许HACMP集群中的pSeries UNIX服务器放置在任意位置，每台服务器都维护一份精确的应用和数据拷贝。HACMP/XD提供数据的同步、切换和恢复。HACMP/XD基于IP的数据镜像是基于存储介质的逻辑层来实现的。也就是说，本地的数据可以使用RAID或本地镜像保护。\r\n\r\nHACMP/XD, HAGEO技术环境是一个分布式的集群，可以分布在两个足够远的地方，通过冗余的点对点的TCP/IP网络连接，提供应用数据的恢复功能。下图为HACMP/XD:HAGEO的集群示例：\r\n\r\n\r\n\r\n对关键的商业应用和数据，每一个场所都维护一份实时镜像。因而，如果某一场所遭到破坏，HACMP/XD:HAGEO将自动切换和同步，可以保证生产系统在较短的时间内恢复运行。\r\n使用HACMP/XD功能，需要具备以下条件：\r\n\r\ni. HACMP V5.1.0 (cluster.es.server.rte 5.1.0.0) 或以上版本\r\nii. 结合使用ESS/PPRC镜像：\r\n   操作系统AIX 5L Java 运行环境1.3.0.15, 或以上版本\r\n   IBM ESS 微码 2.1.1, 或以上版本\r\n   IBM 2105 命令行接口（Command Line Interface，ibm2105cli.rte32.6.100.13） 或者IBM 2105命令行接口（ibm2105esscli.rte 2.1.0.15）\r\n注意：假定以上命令行接口命令安装在其缺省的目录下/usr/opt/ibm2105cli\r\n   IBM 2105 子系统设备驱动程序（Subsystem Device Driver ），\r\nibmSdd_510nchacmp.rte 1.3.3.6, 或以上版本\r\niii. 使用基于IP的镜像：没有特殊要求

iPod

5.3 基于磁盘系统的PPRC数据级容灾解决方案\r\n\r\n本节介绍的基于磁盘系统的PPRC（Peer-to-Peer Remote Copy）数据级容灾解决方案，是灾难恢复方案的7个级别中的第六个级别，可以保证少量或无数据丢失，实现最高一级数据的实时性，适用于那些几乎不允许数据丢失和要求能快速将数据恢复到应用中的业务。 此种解决方案提供数据的一致性，不依赖于应用而靠大量的硬件技术来实现。\r\n\r\n目前业界有两种基本的基于磁盘系统的远程拷贝形式：\r\n\r\n同步PPRC远程拷贝(synchronous writes)：来自主机的数据被写往本地连接的磁盘系统，该系统将数据转发给远地点连接的磁盘系统。只有当两个系统都拥有数据的拷贝以后，本地系统才会向主机返回一个I/O完成指示。同步远程拷贝能够在远地点提供最新的数据，但应用程序会因等待写I/O操作的完成而被延迟。由于距离的限制这种方式也叫做“同城镜像(Metro Mirror)”\r\n\r\n\r\n异步PPRC远程拷贝(Asynchronous Write )：来自主机的数据被写往本地连接的磁盘系统，该系统立即向主机返回一个I/O完成指示。数据在很短的一段时间(在实际中通常在数秒钟到一分钟左右)以后被送往一个远程磁盘系统。异步远程拷贝对应用程序性能的影响最小，但远程磁盘系统在数据的更新程度上与本地系统相比会有一个延迟。\r\n\r\n\r\n\r\n单纯的异步拷贝由于线路距离较远等原因，本地磁盘和远地磁盘可能会有逻辑卷读写顺序上的差异。这种方式也叫做“全局拷贝(Global Copy)”\r\n\r\n在全局拷贝(Global Copy)的情况下，比如本地磁盘系统提供给主机5个逻辑卷，某一时刻主机对这些逻辑卷发起了A，B，C，D，E，5个写盘请求，本地的磁盘系统的写顺序是A，B，C，D，E。但是由于线路等原因，远地的磁盘系统在接收写请求时，收到的顺序可能是A，C，B，D，E。写盘的顺序也是A，C，B，D，E。我们假设灾难发生在这5个写操作D，B的中间部分，那么这时远地的数据C很有可能是没有意义的，甚至是无理的。\r\n\r\n为了解决本地磁盘和远地磁盘可能存在的逻辑卷读写顺序的差异，有的磁盘系统提供带有一致性组的异步远程数据拷贝。在这种方式下，远地的磁盘系统会将先收到的写请求缓存起来(比如上面的数据C)，等到它前面的数据(A,B)到达后，再按照顺序写盘。这种方式也叫做“全局镜像(Global Mirror)”。见下图:\r\n\r\n\r\nIBM异步PPRC远程拷贝提供带有一致性组的异步远程数据拷贝。\r\n下面，分别针对两种方案在IBM ESS中的实施方案予以介绍。\r\n\r\n5.3.1 同步PPRC数据级灾难备份方案\r\n\r\nIBM的PPRC提供了实现灾难备份的方案基础。PPRC全称Peer-to-Peer Remote Copy，是以存储为基础的实时且与应用程序无关的数据远程镜像功能。PPRC的实现较为简单，是无数据丢失且具有完全恢复功能的灾难恢复解决方案。\r\n\r\nPPRC基于IBM ESS企业级存储服务器，以逻辑卷为基本单位，通过光纤通道将本地ESS上的数据同步镜像到远端的ESS上。\r\n\r\n为了在保证数据的即时性、完整性和系统性能之间达到平衡，PPRC提供了多种工作方式。\r\n\r\n同步方式下:点对点远程拷贝(PPRC)是一种同步远程镜像的工具，可用于相隔距离达103公里的两个ESS系统中指定的逻辑卷。这一距离可以通过第三方提供的通道扩展器加以延长，ESS可以为所有连接的主机支持PPRC功能。\r\n\r\n\r\nPPRC将确保如果备份卷不能被更新，那么即使源卷更新成功，整个写操作也会返回失败---保证源卷和目的卷的数据彻底一致。同步方式可以保证数据不会丢失，更重要的是数据的一致性在这种方式下能够得到很好的保证---数据的不一致意味着相关数据的丢失，此时数据库的数据安全机制无法保证数据的安全，严重时有可能造成数据库无法启动。\r\n\r\nPPRC的同步实现机制如下图所示：\r\n\r\n\r\nPPRC同步工作过程为：\r\n\r\n1、应用程序将数据写入磁盘--在生产系统中的应用程序将数据写到生产系统的磁盘。\r\n2、生产系统中的磁盘数据传输到备份磁盘--对每一个在生产系统的写操作都要将这个写操作送到备份磁盘。\r\n3、备份机磁盘数据复制--备份磁盘复制生产系统的数据。\r\n4、将写完的操作信息返给生产磁盘--当生产系统收到备份系统传回的已写信息之后，生产机的磁盘系统通知主机该写操作已完毕，在此之后生产系统的应用将继续执行。在同步PPRC的建立过程中，卷具有不同的状态，以保证数据的完整性。\r\n\r\n5.3.2 异步PPRC数据级灾难备份方案\r\n\r\nPPRC + FlashCopy数据备份方案\r\n\r\n为了提高PPRC数据备份方案的效率，可以考虑结合IBM公司企业级存储服务器ESS的FlashCopy功能软件，采用异步方式实现PPRC数据备份。在异步工作方式下，PPRC能够在远端更新没有完成的情况下，只要本地更新成功，就可以向主机返回“写成功”的信号。好处是：在主备机房之间的数据链路带宽成为瓶颈时，采用异步方式可以不影响主机房生产系统的性能。坏处是：1、数据将有可能丢失；2、在异步同步不能最终成功完成的情况下，数据的一致性无法得到保证。所以当采用异步方式时，IBM建议先采用IBM ESS的快速拷贝功能FlashCopy备份需同步的数据，再进行数据同步。\r\n\r\n\r\nESS的FlashCopy的使用\r\n\r\nESS的FlashCopy提供了一个“时间点”（Point in time）的拷贝服务功能，从源卷到目标卷快速地复制数据。逻辑拷贝通常可以在数秒内完成，然后就释放源卷，进行正常工作，而物理拷贝操作在后台进行。在物理拷贝的进行过程中，拷贝和被拷贝的数据都能被用户使用。\r\n\r\nIBM ESS的FlashCopy支持两个选项，它提供NO COPY选项来支持灾备的应用需求。以下的内容讨论了在移动灾备的应用环境中是如何使用这些选项的。\r\n\r\nFlashCopy COPY选项\r\n\r\n\r\n对于一般的客户应用，需要生产数据实时的时间点物理拷贝。这样的应用示例包括：日常重要卷的备份、日常报表生成、数据仓库和数据挖掘的应用等。FlashCopy COPY选项能够在磁盘存储设备中产生一份生产数据的真实时间点拷贝。该选项可以满足以下的应用需求：\r\n\r\n1.在磁盘存储设备中保存生产数据的一份时间点拷贝的业务需求。这方面的例子是日常工作系统的备份。\r\n2.生产数据的时间点拷贝将被多个应用重复使用，特别是对每日的结束处理和报表生成。\r\n3.生产数据的时间点拷贝将被某些统计分析类应用，如MIS或数据挖掘应用的频繁使用。\r\n\r\n无论是什么原因，只要是需要生产数据的物理拷贝，就可以使用FlashCopy COPY选项来进行支持。对于该选项而言，所需要的磁盘空间容量是需要拷贝的源磁盘容量的总和。\r\n\r\n下图对FlashCopy COPY选项进行了说明。请注意，生产数据的一份真实拷贝是为其它应用的使用而产生，这些应用通常是办公MIS类应用，如报表的生成。\r\n\r\nFlashCopy NO COPY选项\r\n\r\n\r\n对于IBM ESS独有的NO COPY功能，在异步灾备中有极大的作用。NO COPY也需要实时生产数据的时间点拷贝，但并不需要真正的数据拷贝，即在FlashCopy完成以后，不存在源数据的单独的物理拷贝。这一点可以通过FlashCopy NO COPY选项来实现。使用NO COPY选项的应用通常不需要频繁访问被拷贝映像。NO COPY选项不需要所有的镜像磁盘空间，但是需要一些磁盘空间进行磁盘索引和写I/O缓存的操作。所需磁盘空间的容量取决于FlashCOPY的使用时间（即从建立到删除的时间）和被拷贝卷的更新速度。\r\n\r\n在异步灾备的方案中，本地可以用Flashcopy的NO COPY的选项进行时间点的COPY，以保证数据的完整性，再用PPRC进行远程灾备。\r\n\r\nPPRC/XD数据备份方案\r\n\r\nPPRC/XD为非同步、长距离的拷贝选项，它较适合于数据迁移、数据库日志的传输及定期的异地数据备份，这个功能是集成在ESS的PPRC选项当中的。当ESS运行在非同步方式时，被修改的数据持续的传到备份端，修改主ESS端的I/O的操作在被修改的数据传往备份ESS端之前结束。由于是非同步的操作，这样可以最小的影响主ESS端应用的响应时间，当客户需要时，还可切换至PPRC的同步方式。\r\n\r\n级联PPRC数据备份方案\r\n\r\nESS拷贝服务版本2推出了一种被称为级联PPRC的功能，这一功能允许您将同步PPRC和PPRC/XD组合在一起，从而提供了另一种灾难恢复方法。\r\n\r\nPPRC版本2包括了PPRC版本1的全部功能，还包括了级联功能。它非常适宜于实现基于数据的定期时间点拷贝、远程数据拷贝、远程数据移植、远程备份以及非活动数据库日志传输等灾难恢复解决方案。PPRC版本2支持异步级联功能，这一功能可用于为开放系统和IBM eServer Z系列服务器提供一个长距离的远程拷贝解决方案。这一功能可以在远程站点提供一份完整且一致的数据拷贝，并支持强大的城域和长距离的业务连续性以及灾难恢复功能，可以为使用同步PPRC的两个站点配置这一功能--将主拷贝和中间拷贝存放在同一本地ESS上，同时使用异步PPRC/XD连接到一个远程站点；或在一个三站点的配置中使用这一功能，这样可以实现长距离零数据丢失。\r\n\r\n\r\n利用级联PPRC，可以轻而易举地突破性能、数据完整性和传输带宽的限制，实现高效率、低成本的容灾方案：\r\n   面向开放系统和大型主机的远程数据同步方案，两站或三站式，采用三站式方案可实现“零数据损失”\r\n   本地中心和同城中心实现同步PPRC，对性能的影响微乎其微，并确保数据完整性\r\n   同城中心位于同步PPRC的实施距离内，本地中心的事故不会波及同城中心\r\n   可在距本地/同城中心的任意距离设立远程中心

iPod

附录A.容灾方案演示环境\r\n   \r\n \r\n   \r\n    \r\n \r\n \r\n \r\n \r\n\r\n6.1基于磁盘系统的PPRC数据级灾难备份解决方案典型应用环境\r\n\r\n\r\n\r\n.图：基于磁盘系统的PPRC数据级灾难备份解决方案典型应用环境拓扑图\r\n\r\n6.1.1应用环境基本需求\r\n\r\n1. 硬件环境配置\r\n本地生产中心：\r\n   IBM xSeries 445(4 CPU, 2GB内存) 1 台\r\n   Qlogic 2310光纤通道卡 2 块 \r\n   IBM 2109-F16光纤交换机 2 台\r\n   IBM ESS800 企业级存储服务器 1 台\r\n   客户端PC机 若干\r\n\r\n远程备份中心：\r\n   IBM xSeries 445(4 CPU, 2GB内存) 1 台\r\n   Qlogic 2310光纤通道卡 2 块 \r\n   IBM 2109-F16光纤交换机 2 台\r\n   IBM ESS800 企业级存储服务器 1 台\r\n   客户端PC机 若干\r\n   软件环境配置\r\n   Microsoft Windows Advanced Server(Service Pack 3)\r\n   Qlogic 2310: Bios level 1.35 驱动程序 8.2.2.61\r\n   ESS SDD 1.5.0.1\r\n   ESS 800 微码版本: 2.3.1.124\r\n   ESS Flashcopy 版本2\r\n   ESS PPRC 版本2\r\n   IBM 2109-F16固件版本：3.0.2f\r\n\r\n3. 网络环境配置\r\n\r\n本环境中的网络部分由两部分组成：\r\n\r\n第一部分为公网部分，主要承担应用环境中，服务器与服务器之间，服务器与客户机之间的网络通讯；该部分使用10.1.1.X网段，子网掩码为255.255.255.0。\r\n\r\n第二部分为管理网段，主要承担应用环境中存储服务器ESS800、光纤交换机的通讯，这里我们命名为ESSNet。该部分使用172.31.1.X网段，子网掩码为255.255.255.0。\r\n\r\n4. SAN环境配置\r\n\r\n本环境中在本地生产中心和远程备份中心各配置有独立且冗余的光纤交换机。本地生产中心和远程备份中心的每台服务器都至少配置有两块光纤通道卡。本地生产中心和远程备份中心的存储服务器IBM ESS800配置有4块光纤卡，其中两块光纤卡用于服务器与ESS800的连接；另外两块光纤卡分别应用于本地生产中心和远程备份中心的ESS800之间的专用光纤数据链路。本地生产中心和远程备份中心的光纤卡都通过冗余的方式连接到光纤交换机上。本地生产中心和远程备份中心的光纤交换机采用光纤电缆级联起来，构成一个统一的光纤网络。\r\n\r\n6.1.2基于磁盘系统的PPRC数据容灾及恢复过程\r\n\r\n利用上述典型应用环境，可以实现对相应的生产系统数据进行容灾备份。\r\n\r\nPPRC进行数据恢复非常简单，由于数据在远程同步保存着同样的数据，因此主机部分的容灾操作仅需要在远程重新启动主机，而恢复过程则可以反向执行初始化操作。具体过程如下（只考虑主机、存储部分）\r\n\r\na. 灾难发生\r\n(1) 确认灾难，如果需要切换则执行下一步（可自动，但最好由人工控制）；\r\n(2) 在远程备份中心停止复制操作（数据复制已经停止，只是释放此数据卷）；\r\n(3) 启动远程备份中心主机，主机、数据恢复过程完成。\r\nb. 灾难恢复\r\n(1) 确认原生产中心正常；\r\n(2) 反向建立数据复制对；\r\n(3) 开始同步数据；\r\n(4) 暂停容灾中心业务，然后停止同步过程；\r\n(5) 在生产中心重新启动业务，切换网络，业务恢复；\r\n(6) 建立正向数据同步复制对，容灾业务恢复。

iPod

附录B.术语\r\n   \r\n \r\n   \r\n    \r\n \r\n \r\n \r\n \r\n\r\n中文                                                英文\r\n活动状态的备份中心       Active Secondary Center \r\n高级对等网络                  APPN，Advanced Peer to Peer                                                Networking\r\n美国电话电报公司          AT&T, American Telephone and                                           Telegraph\r\n异步传输模式                 ATM，Asynchronous Transfer Mode \r\n业务连续计划                 BCP, Business Continuity Plan\r\n边界网关协议版本4        BGP-4，Border Gateway Protocol -                                            4\r\n基本输入输出系统          BIOS，Basic Input/Output System\r\n底线                               Bottom Line\r\n业务恢复计划                 BRP, Business Recovery Plan\r\n业务连续性                     Business Continuity\r\n业务影响分析                 Business Impact Analysis\r\n层叠                               PPRC Cascading PPRC\r\n危机通信计划                 CCP, Crisis Communication Plan\r\n首席信息官                     CIO，Chief Information Officer\r\n命令行接口                     Command Line Interface\r\n运行连续性计划              COOP, Continuity of                                                               Operations Plan\r\n信用事件                         Credit event\r\n客户关系管理（软件）   CRM, Customer Relationship                                                    Management\r\n数字数据网                     DDN，Digital Data Network\r\n\"灾难\"恢复                      Disaster Recover\r\n降级操作                         DOO, Degraded Operations Object\r\n灾难恢复计划                  DRP, Disaster Recovery Plan\r\n增强版内部网关路由协议EIGRP，Enhanced Interior Gateway                                            Routing Protocol\r\n电子链接                          Electronic Vaulting\r\n电子链接                          Electronic vaulting\r\n企业系统连接                   ESCON，Enterprise System                                                         Connection\r\n企业级存储服务器           ESS, Enterprise Storage Server\r\n故障切换                          Failover\r\n光纤连接                          FICON，Fiber Connection\r\n地理分布并行系统           GDPS，Geographically Dispersed                                             Parallel Sysplex\r\n高可用性集群多处理软件 HACMP, High Availability                                                         Cluster Multi-Processing\r\n高可用性灾难恢复            HADR, High Availability Disaster                                            Recovery\r\nIBM的一种灾备软件          HAGEO，High Availability                                                           Geography\r\n热交换中心                        Hot Center\r\n国际数据中心                     IDC，International Data Center\r\n事件响应计划                     IRP, Incident Response Plan\r\n管理信息系统                     MIS，Management Information                                                Systems\r\n没有异地数据                     No off-site Data\r\n网络恢复目标                     NRO, Network Recovery Object\r\n场所紧急计划                     OEP, Occupant Emergency Plan\r\n开放最短路由优先协议       OSPF，Open Shortest Path First\r\nPTAM卡车运送访问方式       Pickup Truck Access Method\r\n快照                                   Point-in-time Copies\r\nPPRC镜像对                        PPRC Pairs\r\n对等远程拷贝                     PPRC, Peer-to-Peer Remote Copy\r\n距离扩展的对等远程拷贝  PPRC/XD, Peer-to-Peer Remote                                             Copy/Extended Distance\r\n应用版本的一致性             PTF\r\n磁盘冗余阵列　                 RAID，Redundant Array of Disks\r\n恢复时间点 RPO,               Recovery Point Object\r\n一种串行通信端口             RS232\r\n恢复时间                            RTO, Recovery Time Object\r\n存储区域网络                    SAN, Storage Area Network\r\n小型计算机系统接口         SCSI，Small Computer System                                                Interface\r\n一家商用软件供应商          Siebel\r\n系统网络结构协议             SNA，System Network                                                                  Architecture\r\n光谱共同基金                     Spectra mutual fund\r\n备用服务器                         Standby Server\r\n存储系统级别                     Storage Device Level\r\n子系统设备驱动程序          Subsystem Device Driver\r\n外宕机                                System down\r\n层次                                    Tier\r\n两数据中心，两个阶段的数据传输承诺                                                                                 Two-Site Two-Phase Commit\r\n虚拟磁带服务器                  VTS, Virtual Tape Server\r\n0数据丢失                            Zero Data Loss

emc2665

谢谢LZ分享！！:confused: :confused:

altiris

强啊，文章谈的很全面，不错

wxswxs8029

强啊，文章谈的很全面，不错