定义恢复时间目标 (Recovery Time Objective, RTO)

1 灾难恢复介绍 从根本上说，企业灾难恢复 (Disaster Recovery, DR) 的最佳做法包括设计和实施可以抵御灾难（“业务连续性”）并恢复正常运行（“业务恢复”）的容错硬件和软件系统，同时干预最少，理想情况下没有数据丢失。构建容错环境来实现企业 DR 目标并满足实际预算约束可能成本高昂而且耗费大量时间，并且需要企业强有力的承诺。 DR 规划通常可以应对下面一种或多种类型的灾难： 由于自然灾害（地震、风暴、洪水等）或其他原因（火灾、故意破坏、盗窃等）导致的大面积或广泛性 IT 设备损坏。 广泛失去 IT 设备关键服务，例如断电、无法进行冷却或网络访问。 失去关键人员。 DR 规划过程首先是确定业务必须抵御并从其恢复运行的灾难类型并描述其特征。规划过程要确定高层面的业务连续性 (business continuance, BC) 和业务恢复 (business resumption, BR) 要求，包括必需的容错程度。DR 规划的产物是一个恢复体系结构，使容错系统、应用程序和数据能够在既定的约束下满足这些要求。典型的 DR 约束包括恢复时间目标 (recovery time objective, RTO)、恢复点目标 (recovery point objective, RPO) 和可用预算。DR 体系结构加上业务约束使得 DR 过程以真正的“端到端”方式集成所有系统元素，以保证整个 DR 过程产生可预测的结果。 容错系统通常通过冗余实现稳健性和弹性。全冗余系统构建成本非常高昂，这种系统的体系结构中不会发生单点故障，可以在其限度内可能最严重的灾难发生期间运行并从灾难中恢复运行。航天飞机和航空飞机控制系统就是很好的全冗余系统的例子。不太关键的 IT 应用程序通常使用冗余较低的不太强大的系统。这些系统构建成本较低，灾难过后必然会引发服务中断，在中断期间，企业将努力复原可恢复的系统、应用程序和数据。 最后，企业的性质、客户的要求和 DR 的可用预算是构想 DR 要求的关键因素。全面的 DR 解决方案可能成本非常高昂，但是不得不构建。您不能让资金、硬件和软件面临潜在的灾难，盼望着抵御灾难并恢复业务运营。不过，如果您明智地规划和构建，可能不得不遭受更长时间的中断、服务降级或两者，直到全部服务可以恢复，但是您仍然可以拥有一个可靠的有限 DR 解决方案。 然而要明白，或许再多的规划也不能预料和应对全部可能的 DR 情形。例如，起初一个系统上有一个显然微不足道的问题，该问题可能会随着时间的推移蔓延进而以不同方式影响其他系统，全部加起来造成了没有恢复情形的灾难。同样，如果关键的假设不成立（例如，如果关键部件或服务不可用，或者如果 DR 提供商的交付能力不像宣传的那样强大），企业履行服务协议的能力可能会变差。不过，真正的关键在于，如果发生的灾难超过您规划的最严重的情形，可能无法进行恢复。 更广泛地说，RPO 规划必须确定要复原每个可恢复系统而必须存在的所有支持元素，包括数据、元数据、应用程序、平台、设备和人员。规划还必须确保这些元素在所需的业务状况级别可用以实现恢复。BC 数据状况要求对于 RPO 规划尤为重要。例如，如果 BC 要求规定了一小时的 RPO，则输入恢复过程的任何数据或元数据都必须在 RPO 之前保持最新，否则将无法实现 RPO。组织的 DR 过程将指定在规定的 RTO 内实现定义的所有 RPO 的步骤。 RPO 恢复需要的系统元数据包括 OS 目录结构和磁带管理系统信息。这些项目必须在灾难恢复过程中进行更新才能启用选择的所有 RPO。例如，要确保 DR 恢复过程的各种元数据输入之间的一致性，必须为将在 RPO 时重新创建的现有数据集取消目录编制；必须将在 RPO 与灾难发生时间之间更新的数据集恢复到 RPO 时或之前存在的版本；必须将与磁带相关的任何目录更改与磁带管理系统同步。 在其他时候，BC 要求可能证明将 RPO 置于同步点之间是合理的。在这些情况下，同步点之间的恢复依赖于描述任何关键应用程序状态更改或建立最新同步点后所发生事件的补充数据。例如，考虑一下灾难发生前一分钟的 RPO。假设将一个可恢复的应用程序设计成使用检查点记录其进度，但是假设无法承受在一分钟的时间间隔内创建这些检查点的开销。一个解决方案是降低创建检查点的频率并记录在检查点之间提交的所有事务。该事务日志随后将成为检查点恢复过程用于从最新同步点之后的某个 RPO 重新启动的补充输入数据。在此示例中，应用程序重新启动过程将访问最新的检查点数据并应用补充事务日志来复原在检查点之后且在 RPO 之前处理的所有已提交事务（图 1-3）。这样一来，同步点恢复便可使用来自多个来源的输入数据实现目标 RPO。在 RPO 后直到发生灾难时处理的所有事务都假定为不可恢复。 如果每个物理位置都有自己独立的 CDS，即如果每个位置的硬件代表单独的 TapePlex，您也可以在不同的物理位置创建两个或多个物理磁带副本。通过使用 SMC 客户机/服务器功能并定义用于使数据集副本指向远程 TapePlex 的策略，作业可以在另一个 TapePlex 中的 ACS 中创建磁带副本而 JCL 没有变化。 VSM 群集由两个或多个为了通过通信链路 (CLINK) 进行数据交换而联网的 VTSS 设备（节点）组成。CLINK 是单向或双向通道。最简单的 VSM 群集配置包括两个 VTSS 节点，它们在使用单向 CLINK 连接的同一个 TapePlex 中，但是一般部署双向 CLINK（图 1-6）。每个群集节点可能位于不同的站点。VSM 单向存储策略控制通过单向 CLINK 从 VTSS A 到 VTSS B 的虚拟磁带卷 (virtual tape volume, VTV) 自动复制。双向存储策略和双向 CLINK 允许从 VTSS A 复制到 VTSS B，反之亦然。 借助 VSM 扩展群集，可以在一个 TapePlex 中的三个或更多 VTSS 设备之间建立多对多连接，从而实现更高级别的数据可用性（图 1-7）。如图所示在一个 TapePlex 内的两个或多个站点中安装 VTSS 群集设备可通过消除每个站点作为单点故障来提高冗余。 Oracle 的 LCM 产品可通过管理保管库与生产磁带库之间的回收过程来简化 MVC 卷的异地保管过程。当过期数据量超过指定的阈值时，LCM 保管功能将计划退还保管的 MVC 卷。 VSM 跨 Tapeplex 复制 (Cross-Tapeplex Replication, CTR) 群集允许 VTSS 群集设备位于不同的 Tapeplex 中，并提供了将 VTV 从一个 Tapeplex 复制到一个或多个其他 Tapeplex 的功能，从而通过单向或双向 CLINK 启用多对多群集复制模型（图 1-8）。发送和接收 Tapeplex 可能位于不同的站点。复制的 VTV 作为只读卷装入到接收 Tapeplex 的 CDS 中。这样提供了强大的数据保护，以防在 Tapeplex 中运行的应用程序对其进行更改。接收 Tapeplex 的 CDS 还会指明 CTR 复制的 VTV 副本由发送 Tapeplex 拥有，作为附加保护措施，CTR 将确保 Tapeplex 无法修改它不拥有的任何 VTV。 这种对等 CTR 群集设计的对称性意味着，在对等站点进行测试的恢复的应用程序在 DR 测试期间的运行与在生产期间一样。对等 CDS 包含 DR 测试需要的所有复制的卷信息，DR 测试与生产并行进行，并且相同的 VTSS 硬件支持由生产和 DR 测试工作负荷并发使用。生产 VTSS 群集可能存在于每个 TapePlex 中，并且无需拆分即可在 TapePlex 之间共享硬件以便进行 DR 测试。从中执行应用程序 DR 测试的生产 TapePlex 无法修改任何 CTR 复制的 VTV，因此所有复制的生产数据在 DR 测试周期内完全受到保护。最重要的是，基于 CTR 的 DR 测试可保证经验证的 DR 测试过程在真正的灾难恢复期间将产生完全相同的结果。如果尝试更新一个 CTR 复制的 VTV，而它用来将应用程序标识为修改现有输入数据集的一个应用程序，则 SMC 主机软件将发出一条消息。按照上述管理同步点的最佳做法，您应该确保生产环境在应用程序修改该数据集之前保存该数据集的副本，以备同步点恢复需要备份副本。