IBM Business Process Manager 灾难恢复指南

简介

业务流程管理是一种运行继续在加快发展的业务交易的概念和方法。全功能的业务流程管理系统以一种敏捷、灵活和一致的方式为利益相关者提供了价值。您的组织可能刚开始在业务中应用 IBM BPM，所以您可能还未遇到对健全的灾难恢复解决方案的需要。但是，许多组织已在其 IBM BPM 系统中承载任务关键型应用程序。如果您的组织是它们之一，那么您已理解与在灾难事件中 IBM BPM 系统的故障相关的成本，以及在灾难发生后恢复业务运营的过程。

这篇使用业务流程管理系统的通用指南重点介绍在市场中提供了业务竞争优势或独特价值的高价值流程。无论优势是成本效益、客户保留率还是业务价值的另一种度量指标，业务流程都常常需要高度可用且能够满足越来越激进的灾难恢复需求。

当然，灾难恢复需求使用恢复时间目标 (RTO) 和恢复点目标 (RPO) 来度量。最近几年，对 IBM BPM 系统的灾难恢复需求已超越传统的 RTO 和 RPO 数字，延伸到更加激进的目标。举例而言，对在 30 分钟内恢复正常运营的渴望，促使大型企业寻找新的和额外的灾难恢复执行方式。

Charlie Redlin 的启发性文章 用于灾难恢复环境的 WebSphere Process Server 和 WebSphere Enterprise Service Bus 异步复制 （于 2008 年发表在 developerWorks 上）为灾难恢复战略建立了基准，定义了一种方法，该方法由于其广泛的吸引力和成功而被称为 “经典灾难恢复”。Charlie 描述的战略在 IBM BPM 客户中仍在流行，它依靠在以下各节中称为克隆单元和存储托管复制的技术。Hong Yan Wang 和其他人在 将事务和补偿日志存储在关系数据库中以在 IBM Business Process Manager 中实现高可用性和灾难恢复 （2014 年发表在 developerWorks 上）中介绍了一种备用方法。她的方法使用新的 WebSphere Application Server 功能和新的拓扑结构来解决 Charlie Redlin 6 年前解决的相同技术问题。哪种方法更好？您应使用哪种方法作为自己的灾难恢复设计的基础？当然，答案取决于许多因素。第一步是了解灾难恢复中对所有 IBM BPM 工作负载至关重要的关键概念，以及 IBM BPM 系统常常管理的工作负载的有状态性质带来的关键挑战。第二步是注意成功的 IBM BPM 灾难恢复解决方案中的常见模式，以理解每种模式的一些优点和缺点。有了这两部分信息，理解了要解决的挑战和解决它们的常见技术，您作为 IBM BPM 就可以开始设计满足您的业务需求的灾难恢复战略了。

如果想利用 IBM BPM 作为平台来运行一组全面的业务流程，包括组织中最关键的任务和业务流程，您应该继续阅读。您可能是应用程序架构师、企业架构师或高级业务专员，熟悉在发生灾难时保持可用性的业务驱动需求。所讨论的技术适用于 IBM BPM 版本 8.0.1.3、8.5.0.1、8.5.5.0 和 8.5.6。

回页首

IBM BPM 灾难恢复中的关键概念

业务流程管理平台由协同运行的硬件和软件组件组成，任何一个组件都可能发生故障。系统架构师和系统管理员的一个目标是确保有足够的冗余性，以便业务活动可继续进行，甚至在信息技术资源发生故障和它们在修理或更换时。

举例而言，物理磁盘驱动器分组到由一个控制器控制的阵列中，这个控制器在整个分组中分发数据，并在一个磁盘发生故障时自动重定向流量。类似地，IBM WebSphere Network Deployment 将应用服务器分组到集群中并协调它们之间的通信，使这个分组能够容忍损失任何成员。这些构建块组成了一个工具集，用于使业务流程管理系统高度可用，以及成功地使用此系统来自动适应任何单个元素的损失。这两个例子解决了高可用性事件，也就是涉及大型系统中单个组件的故障的事件。相较而言，灾难是一种毁灭性的事件，涉及整个数据中心中多个组件同时损失。尽管如此，可扩展冗余的核心概念，以包含跨数据中心边界的关键产品组件和运行时数据复制，以便业务可继续运行，即使整个主要数据中心损失了。

设计灾难恢复战略时的一个重要考虑因素是，在设计时，基础设施架构师必须假设用于持久保存业务状态的主要存储空间损失了。因此，除了更换业务流程管理系统的所有相关的硬件和软件组件，灾难恢复解决方案还必须更换表示业务状态的数据。这使用复制来解决：将一个数据副本保存在一个与主要数据中心完全分离的位置（并保持最新），以确保两个数据集不会都受同一次灾难影响。复制对业务流程管理系统特别重要，因为它们管理的数据对维护业务所依赖的活动的状态至关重要，常常是跨多个数据存储系统的协调活动。要更好地理解复制需求，可将要复制的数据划分为两个类别：配置数据和运行时数据。

配置数据

顾名思义，配置数据包含定义业务流程管理系统的状态所需的所有元数据，包括安装的 IBM BPM 所在的 IBM WebSphere Network Deployment 拓扑结构的定义，以及连接外部资源和数据来源所需的所有信息。如果熟悉 IBM WebSphere Application Server，您可将配置数据视为 IBM WebSphere Application Server 概要文件的内容。此外，IBM BPM 配置数据也包含定义业务流程的元数据，业务流程在创作环境中构建并部署到运行时服务器。此流程定义元数据同时包含在 WebSphere Application Server 概要文件和 IBM BPM 数据库中。

出于复制的目的，配置数据的一个重要特征是离散、隔离的事件会更改它。例如，在管理控制台中对概要文件信息的更改，向流程应用程序应用代码更改，或者更新 IBM BPM，都会更改配置数据。通常，操作过程会将对配置数据的这些类型的更改收集到分组中，以便一起应用到系统，或许在维护期限内应用。因此，对配置数据使用离散复制技术，在应用每组更改并确认获得了想要的效果后收集配置状态的快照，这会得到稳定的系统。

运行时数据

与配置数据不同，运行时数据包含描述业务所处理的流程实例的所有信息。描述流程实例的当前状态的元数据存储在 IBM BPM 数据库中，包括哪些任务目前是活跃的和关联的业务数据变量的值。

因为 IBM BPM 为内部和外部通信都使用消息引擎，所以运行时数据也包含存储在队列上的消息中的信息。IBM BPM 允许应用程序开发人员将他们的业务流程与应用程序数据库相集成，使用内置于业务流程实现中的 Java Database Connectivity (JDBC) 通信来保持一致性。这些应用程序数据库的内容（如果存在）也属于运行时数据的范围。

最后，IBM BPM 依靠 WebSphere Application Server 事务服务来协调数据更改，并将它们分组到原子单元中，确保所有更改要么都执行，要么都不执行。所以，与 WebSphere Application Server 事务服务关联的日志文件是运行时数据的关键部分，将 IBM BPM 资源与特定于应用程序的资源链接起来。

出于复制的目的，运行时数据的一个重要特征是它会持续更改。因此，自然需要使用持续战略来复制运行时数据，无论该战略是同步（提交给来源的每个更改可保证同时提交给副本）还是异步的（对来源的更改可定期按批次发送和复制到副本中）。无论如何，复制并不像一系列离散的快照，而是一个从来源传递到副本的稳定信息流。通常，同步复制技术不是灾难恢复的理想选择，因为它们在跨地理上分离的站点应用时会导致不可接受的性能成本。因此，异步复制通常是运行时数据的首选方法。

尽管从性能角度讲是首选的（且许多时候是强制性的），但异步复制运行时数据会带来一致性挑战。因为运行时数据分布在多个资源上，所以在任何时间点，其中一个资源的异步更新副本可能与另一个资源的独立的异步副本不一致。在恢复时，这种不一致性会导致损坏，进而导致业务数据丢失或阻止锁定的资源（比如数据库行）在事务超时之前释放。

许多基于存储的复制管理技术（例如一个存储区域网络提供的技术）提供了一个称为一致性分组的特性来解决此问题。通过一致性分组，您可将一组在物理上和逻辑上不同的存储卷分组到一起，以方便复制。通过这种方式，复制经理可确保在所有卷上保持写入顺序的一致性，甚至在使用异步复制时。所以，即使副本上的映像从不会与来源上的起源映像匹配（由于异步批处理），但它忠实地反映了来源在过去某个时间点的状态。

恢复指标

考虑基于异步复制的运行时数据映像的恢复原理时，需要理解灾难恢复的两个关键指标：恢复点和恢复时间。

恢复点是来源上和副本上的运行时数据状态之间的滞后的度量指标（通常按经过的时间来度量）。同步复制可提供一个具有零滞后的副本，因此恢复点与来源准确匹配。因为异步复制无法保证对来源的所有更新都同时应用在副本上，所以恢复点指标很重要。滞后量将依赖于复制管理软件的细节，但一般来讲更小的恢复点指标（更小的滞后）需要的成本更高。大多数企业建立了一个容错目标，称为恢复点目标 (RPO)，用于描述在灾难事件和后续恢复过程中允许丢失的最大数据量。

恢复时间指标描述从灾难发生到恢复业务运营所经历的时间。同样地，不同的企业（以及事实上同一个企业中的不同应用程序）在灾难事件中可容忍不同的宕机时间量。这种感对宕机时间的容忍通常表示为恢复时间目标 (RTO)。

回页首

IBM BPM 的灾难恢复选项

IBM BPM 团队测试并认证了基于两种迥然不同的 IBM WebSphere Network Deployment 拓扑结构和两种不同的运行时数据复制方法而建立的灾难恢复战略。您可组合这些技术，为 IBM BPM 解决方案生成完成灾难恢复的 4 种不同选项。添加另一种更简单的方法和将这些基本概念扩展大更高级的混合环境，可进一步扩展可供 IBM BPM 使用的各种灾难恢复方法。

在每种情况下，一定要确保主要数据中心中的 IBM BPM 安装遵守良好的高可用性实践和 IBM 红皮书出版物 业务流程管理部署指南：使用 IBM Business Process Manager V8.5 中的建议。

下一节探讨可应用的灾难恢复选项的一些关键特性。

复制配置数据：克隆单元与离群节点 (stray node)

上一节介绍了需要将来自主要数据中心的 IBM WebSphere Application Server 和 IBM BPM 配置数据复制到远程的灾难恢复数据中心。通过逐个文件地将配置数据从来源复制到副本的来实现此目的的战略，称为克隆单元拓扑结构。远程数据中心中的单元准确地复制了主要数据中心中的单元。单元名称、节点名称和服务器名称都相同。事实上，WebSphere Application Server 和 IBM BPM 代码用于描述单元的所有组件的通用唯一标识符 (UUID) 是相同的。此外，WebSphere Network Deployment 所管理的事务恢复处理要求，与服务器部署到的操作系统关联的主机名必须在两个数据中心中匹配。因此，辅助数据中心中的 WebSphere Network Deployment 拓扑结构的构造方式是，从主要数据中心备份构成拓扑结构定义的文件，并将它们还原到辅助数据中心。尝试使用并行安装和运行概要文件创建脚本来构造辅助单元，将不起作用（因为 UUID 及其他信息不匹配）。

离群节点拓扑结构使用一种完全不同的方法。无需将来自主要数据中心的服务器复制到备用数据中心中，离群节点方法可将 IBM BPM 单元扩展到两个数据中心中。这样，单元同时包含两个数据中心中的节点，以及两个数据中心中连锁到同一个单元中的集群成员。一般而言，不鼓励让一个单元跨越多个数据中心，因为这有可能导致数据损坏（由分区网络导致）和性能问题（由连接两个数据中心时网络中的高延迟导致），所以必须采取额外的步骤来减轻这些风险，这些步骤将在以下段略介绍。

IBM BPM 和 IBM WebSphere Network Deployment 的工程设计基于的预期是，组成整个单元的服务器由一个快速、可靠的局域网 (LAN) 连接，而不是一个较慢、不太可靠的局域网 (WAN)。离群节点拓扑结构引入一种重要的额外需求：必须存在操作过程来确保应用服务器一次仅可在一个数据中心中启动。正常操作期间，这些服务器是主要数据中心中的服务器。发生灾难之后，这些程序确保主要数据中心中的所有服务器实际停止运行，然后恢复数据中心中的服务器才能启动。这样，就不会发生跨数据中心的运行时通信。许多团队发现，使用脚本来自动化操作过程的运行，是一种改善效率、正确性和可重复性的宝贵技术，有助于减少总体恢复时间和避免违规，比如意外地同时在两个数据中心中启动节点。

相较而言，在离群节点拓扑结构中，跨数据中心传输配置数据是可接受的。这意味着节点代理可同时在两个数据中心中运行，通过在部署管理器与节点代理之间通信来传播配置更改。最终结果是，与使用克隆单元方法的备份和还原技术相比，配置更改会自动跨数据中心边界而保持。因此，离群节点拓扑结构的实现和维护可能比克隆单元拓扑结构更快、更简单且更经济，因为所有配置和复制功能都在 WebSphere Network Deployment 基础设施中。

复制运行时数据：存储子系统与数据库

正如上一节介绍的，许多企业级存储解决方案提供了一些可用于跨多个卷而协调异步复制的特性。例如，基础设施管理员可使用存储区域网络来向 IBM BPM 基础设施提供两个卷，使用存储区域网络所提供的工具来建立一个同时包含两个卷的一致性组。存储区域网络可确保在两个卷中保持写入顺序一致性，甚至在使用异步复制时。一个卷可以提供给数据库管理器，用于构造将供 IBM BPM 使用的数据库容器和日志。对于包含与 WebSphere Application Server 事务服务和补偿服务关联且由 IBM BPM 使用的恢复日志的分布式系统（网络文件系统、一般并行文件系统或类似系统），可使用一致性分组中的另一个卷作为备用存储。

许多数据库管理系统提供了复制特性，，比如 Oracle Data Guard Replication 和 IBM DB2 中的高可用性灾难恢复 (HADR) 特性，就像存储子系统一样。以前无法为 IBM BPM 使用这些数据库复制特性，因为它们未提供在数据库内容与拥有 WebSphere Application Server 恢复日志的系统之间保持一致性的途径。但是，最新的 WebSphere Application Server 版本包含一个选项，IBM BPM 服务器可使用它将恢复日志存储在数据库中，而不是直接存储在文件系统上，如 IBM 知识中心中的 WebSphere Application Server 文档中的 将事务日志和补偿日志存储在关系数据库中以获得高可用性 。如果此数据库是包含 IBM BPM 数据库的同一个数据库，那么数据库管理技术就行得通。

如果想要将事务和补偿日志存储在数据库中，请注意与将此信息直接存储在配置良好的文件系统上相比，这么做可能会给一些工作负载带来额外的性能开销。这种额外的开销对不同的 IBM BPM 应用程序的影响不同。使用 Business Process Modeling Notation (BPMN) 所实现的 IBM BPM 标准实现和流程受到的影响最小，而 Business Process Execution Language (BPEL) 流程，尤其是具有复杂事务的宏观流应用程序，会受到更大的影响。与平常一样，评估新技术时，一定要度量特定于您自己的流程和基础设施的性能变量。尽管存在性能因素，在数据库中存储事务和补偿日志所带来的简单性和灵活性仍使它成为许多应用程序的流行选项。

恢复 WebSphere Application Server 部署管理器

发生灾难后，最优先的事项是恢复业务运营，这需要启动可用来查看和处理业务流程的备用 IBM BPM 服务器。WebSphere Network Deployment 基础设施的其他元素（最明显的是部署管理器）需要更改系统的配置并最终被替换。

IBM WebSphere Developer Technical Journal 中的WebSphere 反向投资者 专栏中的 运行时管理高可用性选项，终极版 介绍了一些技术，在发生灾难时，可使用它们复制部署管理器配置，建立部署管理器所提供的管理功能的替代者。

一种流行的技术涉及部署管理器配置的基于文件的复制，这与前面讨论的克隆单元战略中做法完全相同。所以，也可自然地将此方法扩展到部署管理器。这种部署管理器复制和更换方式同样适用于离群节点方法，即使剩余单元配置不需要复制。WebSphere Network Deployment 基础设施在正常操作期间会直接保留离群节点配置。

辅助数据中心中的容量

无论使用离群节点还是克隆节点来复制 IBM BPM 配置信息，在从灾难恢复后为辅助数据中心计划充足的容量都很重要。一般而言，组织在从灾难恢复后需要与正常运行期间相同的容量（节点数和每个节点的核心数）。毕竟，灾难恢复计划的目标是将系统还原到正常行为。

但是，灾难恢复计划的一个常见不足是，无法确保备用数据中心中有足够的可用容量来支持全生产负载。在这些情况下，灾难恢复过程可以成功完成，但您会发现替代的 IBM BPM 和数据库服务器立即过载。出于此原因，需要在辅助数据中心中配置与主要数据中心相同的备用容量。当然，辅助数据中心中的服务器不需要在正常运行期间保持空闲。它们可用于其他低优先级的工作，只要此工作可在发生灾难恢复过程后立即从系统删除。

灾难恢复战略

有 7 种恢复方法，它们涵盖了可在 IBM BPM 中用来满足业务可用性和恢复需求的丰富技术。

简单的灾难恢复

在复制期间确保一致性的最简单方式是让整个系统静默。使用管理工具停止 IBM BPM 服务器时，参与业务流程的所有资源都是一致的，无论它们使用何种存储子系统，而且可以单独复制。这样，您就有了一种简单的灾难恢复方法，这种方法在可容忍定期的计划性系统宕机或缺乏跨资源管理器统一复制能力的情形中很有用。事实证明此战略在需要复制测试和性能验证系统时很有用。无论是离群节点，还是克隆单元拓扑结构，都可用于基于离线备份的复制模式。克隆单元拓扑结构是典型的，因为在维护窗口中所有配置数据和运行时数据都会一起复制，如图 1 所示。

图 1. 简单的灾难恢复

点击查看大图

经典灾难恢复（存储区域网络复制）

结合克隆单元拓扑结构与存储管理的复制，为 IBM BPM 生成了一种最流行的灾难恢复方法。它仍然是在 IBM 开发实验室和客户安装中经过最广泛检验的方法。图 2 中给出了图解。使用克隆单元拓扑结构的要求是，恢复过程确保来自主要数据中心的主机名可用在辅助数据中心中。

图 2. 经典灾难恢复（存储区域网络复制）

点击查看大图

经典灾难恢复（数据库复制）

拥有基于 Oracle Data Guard Replication 或 DB2 HADR 特性而不是存储子系统组件的既有复制实践的组织，可能将 WebSphere Application Server 事务和补偿日志直接放在 IBM BPM 数据库中，以便也为 IBM BPM 使用其现有的操作过程（参见图 3）。广泛的测试已证明此方法很可靠。同样地，因为辅助数据中心中备份数据库服务器的存储在正常操作期间仍挂载上，所以此方法可提供比存储子系统所管理的复制更快的总体恢复时间。

图 3. 经典灾难恢复（数据库复制）

点击查看大图

离群节点（数据库复制）

离群节点拓扑结构与数据库管理的复制相结合，已在内部测试中证明具有最快的总体恢复时间。除了辅助数据中心中的数据库存储在正常操作期间让挂载上，离群节点方法还允许辅助数据中心中的节点代理正常运行，减少了在恢复过程中运行的步骤数量。自从在 IBM BPM 版本 8.5.0.1 和 8.0.1.1 中引入以来，此方法已证明非常流行，尤其是在依赖于 Oracle Data Guard Replication 的 IBM BPM Standard Edition 安装中。参加图 4。

基于此拓扑结构而创建一个 IBM BPM 单元所需的配置步骤的详细描述，可在 2014 年 9 月版 Business Process Management Journal 中发布的 将事务和补偿日志存储在关系数据库中以在 IBM Business Process Manager 中实现高可用性和灾难恢复 中找到。

图 4. 离群节点（数据库复制）

点击查看大图

离群节点（存储区域网络复制）

也可将离群节点配置与一种依赖于存储子系统的运行时数据复制战略配合使用，如图 5 所示。这种组合在已为其他应用程序使用存储区域网络复制，还想将此实践应用到其 IBM BPM 应用程序中的组织中特别流行。这种组合提供了使用存储区域网络进行复制的强大功能和灵活性，以及离群节点所带来的更简单的 IBM BPM 单元恢复。

图 5. 离群节点（存储区域网络复制）

点击查看大图

都市对 (Metro pair)

使用包含多个数据中心中的活跃成员的单个 IBM BPM 单元，仍然是一种一般不推荐用于灾难恢复用途的实践。IBM BPM 服务器广泛使用了它的数据库，而且这些方法所要求的网络分离提高了由于网络分区而带来性能问题和数据损坏问题的风险（分裂脑场景）。为了减少出现网络问题的风险，这些安装通常依靠一对彼此邻近且通过冗余、高容量网络基础设施连接的数据中心（这就是该方法称为 “都市对” 的原因），如图 6 所示。这种邻近性减少了防御自然灾难和其他影响大范围地理区域的事件的需求。出于此原因，此类型的方法被视为一种高级的高可用性技术，而不是灾难恢复解决方案。

实现一种基于没有地区分散性的都市对的方法后，需要仔细考虑所有可用性和恢复需求，确保收益对风险大于风险。具体来讲,考虑主要数据中心宕机时数据库服务器的行为。如果从一个都市对数据中心切换数据库需要重新启动 IBM BPM 服务器，您就会失去该拓扑结构努力实现的恢复时间优势。

许多组织发现，拆分到多个数据中心中的单个单元形成了他们的整体可用性和恢复战略的重要元素。有快速、可靠的网络配合，而且拥有描绘了实际故障转移时间和数据损坏风险的充分测试支持后，像都市对这样的拓扑结构就能够满足某种用途。当扩展来包含真实、远程的灾难恢复站点时，如都市对和灾难恢复节中所介绍的，这些战略可能成为宝贵的企业级解决方案。

图 6. 都市对

都市对和灾难恢复

您可通过一种使用跨地理上分散的数据中心而使用复制的灾难恢复战略，将都市对拓扑结构方法扩展到被动备用系统。此解决方案消除了在仅使用一种都市对拓扑结构时，在发生自然灾难时失去整个系统的风险。因为都市对拓扑结构无非是单一、扩展的 IBM BPM 单元，所以您可使用前面描述的 4 种核心灾难恢复战略中的任一种来实现此扩展。

出于简单性，图 7 描绘了一个具有数据库托管复制的克隆单元，而离群节点和存储区域网络托管的复制技术同样适用于这种类型的方法。因为引入了第三个数据中心，所以管理此基础设施类型所需的操作过程比所描述的其他方法更复杂。

图 7. 都市对和灾难恢复

点击查看大图

灾难恢复战略总结

前面几节介绍了针对 IBM BPM 配置数据（离群节点和克隆单元）和运行时数据（存储托管和数据库托管）的核心复制技术，得出了 4 种主要的灾难恢复战略。通过扩展这 4 种灾难来包含简单的灾难恢复战略和两个基于 IBM BPM 数据中心都市对的战略，得到了 7 种方法，它们涵盖了可用于 IBM BPM 来满足可用性和恢复业务需求的众多技术。图 8 提供的快速参考表比较了区分这些方法的特性。

图 8. 灾难恢复战略总结

点击查看大图

回页首

灾难恢复的检验

与任何非功能性需求一样，验证恢复行为的业务需求是否得到满足，是灾难恢复计划的一个重要元素。因为包含跨站点故障转移的模拟具有破坏性，所以为这种类型的测试配置一个专用的测试环境非常有用。主要目标包括检验跨站点配置以确保所有系统都在恢复后正常连接和通信，度量总体恢复时间以在实际灾难事件中设置合适的预期。此外，随着管理员对要运行的步骤越来越熟悉和自信，许多组织通过实践改善了执行效率。除此之外，编写脚本和执行其他类型自动化的新机会，在反复执行后也变得明朗起来。

回页首

灾难恢复的未来

尽管克隆单元、离群节点、数据库托管复制和存储托管复制等就似乎起源于传统的内部部署环境，但我们自然地会考虑同样的技术能多大程度地应用或扩展到虚拟环境。除此之外，基础设施的虚拟化带来了对成功的灾难恢复过程所依赖的操作过程执行自动化的新机会。我们期待看到未来有 IBM 内容基于主导着 IBM BPM 系统的基础设施和拓扑结构领域的各种虚拟化方法，更深入地介绍如何实现灾难恢复。

除了虚拟化影响，越来越多的 IBM BPM 工作负载在各种云配置中运行，包括公共云、托管云和私有云环境，比如在 IBM PureApplication System 上运行的云。我们期待看到有关如何在这些环境中最佳地实现灾难恢复的更新，为本更新提供补充。

对于 IBM PureApplication System 上运行 IBM BPM 系统的主题，预先透露一下，最新发布的IBM BPM 8.5.5 模式 支持在复制物理系统中的配置数据和运行时数据时流行使用的灾难恢复方法。

回页首

结束语

确保运行任务关键型业务流程的业务流程管理系统可在灾难事件中恢复，仍是大型企业的一个重要需求。有状态工作负载带来了传统无状态工作负载所没有的挑战。

您可配置 IBM BPM V8.x 来使用各种技术从灾难中恢复。IBM BPM 在配置和运行方式上的最新进步，提供了新的和宝贵的配置选项，这些选项将可能的 RTO 值显著降低到不到 1 小时。您现在应已熟悉当前的选项集合，使用这些选项在拓扑结构方面的当前影响，以及实现以前被认为无法实现的激进的 RTO 数字十多必要的底层基础设施功能。

每种可能的配置都会影响底层基础设施，都拥有关联的成本。在客户要求实现激进的 RTO 和 RPO 数字时，Charlie Redlin 用一句简单的话回应了他们：“您有多少钱来实现需要的数字？”尽管激进的灾难恢复目标仍会花钱和需要大量基础设施投入，但好消息是，借助最新的基础设施和数据库功能，成本正在降低到更可承受的水平。您可使用这些功能实现激进的 RTO 和 RPO 灾难恢复。

致谢

感谢 Hong Yan BJ Wang、Yu Zhang、Uday Pillai 和 Mahesh Sharma 审阅并提供高贵的意见。