内容


用于灾难恢复环境的 WebSphere Process Server 和 WebSphere Enterprise Service Bus 异步复制

Comments

引言

在灾难恢复计划中包括次要数据中心,而且主要数据中心中包括 IBM®WebSphere® Process Server 或 IBM WebSphere Enterprise Service Bus 时,您需要采用适当的拓扑和进行持续的维护活动来保证灾难数据中心恰当地完成其任务。虽然多种拓扑都能够满足这些需求,不过本文将介绍利用磁盘复制系统的拓扑。

通过磁盘复制系统,将捕获主要数据中心的状态数据的快照并以异步方式传输到灾难数据中心。通过这种类型的拓扑,可以获得短恢复时间目标(Recovery Time Objective,RTO)和相对较短的恢复点目标(Recovery Point Objective,RPO)。

本文针对的读者是操作中心的架构师和规划人员。在阅读本文前,您应该对 Process Server 部署环境以及 WebSphere Application Server Network Deployment 环境有很好的了解。此外,还应该熟悉高可用性、灾难恢复、持续可用性和与信息技术运营相关的其他服务质量的相关科学(或技术)知识。

环境概述

下图(请参见图 1)描述了具有主要数据中心和灾难数据中心的拓扑。这些数据中心以活动/待机模式运行,在主要数据中心不可用之前,灾难数据中心都处于空闲状态。当然,主要数据中心处于活动状态时,灾难数据中心的硬件和其他计算资源不必处于空闲状态。例如,可以将其用于灾难数据中心可以处理的较低优先级的活动,如作为测试环境,或用于一组其他应用程序。

每个数据中心中所示的 LPAR 数量仅为演示之用。您数据中心中的 LPAR 的实际数量和用途应该根据应用程序的需求加以定义。这里的重要方面包括:SAN 的存在、SAN 内数据的划分以及 SAN 中的数据复制到灾难数据中心这一事实。

除了数据中心之间共享数据外,数据中心的配置需要足够类似,以便数据能够在两个数据中心中使用。

图 1. 所复制的磁盘作为灾难数据中心的基础
复制的磁盘
复制的磁盘

您将需要在原始数据中心捕获三种类型的数据,并将该数据移动到灾难数据中心:

  • 安装数据,或与 WebSphere 产品关联的数据。
  • 配置数据,或与应用程序及运行应用程序所需的资源关联的数据。
  • 运行数据,或与进程的特定实例或其他业务状态关联的数据。

捕获此数据后,需要进行一些修改,才能在灾难数据中心中使用。

基本操作流程

此部分包含管理与此环境关联的数据所需的过程。这些过程包括与主要数据中心管理关联的过程、持续数据更改过程以及与启动灾难数据中心关联的过程。

进行主要数据中心的常规管理工作时,将执行需要在灾难数据中心中加以反映的操作。这些操作和为了将数据传输到灾难数据中心所需的关联操作如下面的表 1 中所示:

表 1. 主要数据中心的常规数据管理所导致的操作

更改类型所需过程
安装更改捕获安装数据的快照,并将其传输到灾难数据中心。
概要更改捕获配置数据快照和安装数据快照,并将其传输到灾难数据中心。
安装或卸载应用程序在保存更改前捕获运行数据快照。保存更改后,捕获运行数据快照和配置数据快照。
任何其他配置更改捕获配置数据快照,并将其传输到灾难数据中心。

持续捕获运行数据快照,并将其传输到灾难数据中心。

使用以下步骤启动灾难数据中心:

  1. 确定为每个数据卷使用的快照。
  2. 在磁盘上提供该数据。
  3. 向灾难数据中心的 LPAR 提供磁盘映像。
  4. 更改主机名或 IP 地址(如果需要)。
  5. 启动数据库和 WebSphere 管理进程。
  6. 启动 WebSphere 集群,以恢复所有动态工作(首先是消息传递,接着是支持,然后是应用程序部署)。
  7. 开放数据中心处理新工作。

灾难恢复配置注意事项

除了环境的常规配置外,还将需要注意一些特定于灾难恢复要求的配置注意事项。这些注意事项大部分都与磁盘管理方面的事情相关,但也包括一些 WebSphere 配置。此部分将对这些主题进行讨论。

磁盘管理

应该注意环境中涉及的三个相关但又彼此独立的一致性分组的数据:

  • 计算单元中的每个 LPAR 的安装数据包括在相同的一致性分组中。
  • 计算单元中每个 LPAR 的配置数据包括在相同的一致性分组中。
  • 环境中的每个 LPAR 的运行数据包括在相同的一致性分组中。

之所以将数据划分为这些独立的一致性分组,是因为导致每个分组的数据不一致的操作彼此有所差别。如果没有划分一致性分组,对于安装或配置数据不一致的任何情况,都不能在灾难数据中心使用运行数据。

之所以将所有 LPAR 的数据包括在单个一致性分组中,是因为:

  • 运行数据需要这些数据,没有选择的余地。
  • 可以通过将事项进行组合来减少要管理的事项数目。随着节点数的增加,这一点将变得越来越重要。

安装数据

系统的安装数据包括 WebSphere 产品的二进制文件。

您将希望灾难数据中心使用与原始数据中心相同的 WebSphere 产品版本以及特定的修补程序包和其他修补程序,以便应用程序能在灾难数据中心以一致的方式运行。

此安装数据包括安装根目录、保留更新安装程序的目录和安装注册表文件。与 WebSphere Process Server 关联的三个安装注册表文件为:.nifregistry 文件(V6.1 中引入)、vpd.properties 文件以及本机或操作系统安装注册表。.nifregistry 文件在 linux 系统中位于 /opt/.ibm/.nif/.nifregistry,其他平台的位置与此类似。vpd.properties 文件位于 linux 的根目录中,其他平台的位置与此类似。本机安装注册表由各个操作系统进行管理。

请通过以下配置将此数据包括在磁盘复制系统中:

原始数据中心的配置

  • 创建加载 SNA 所需的目录,例如:
    /opt/ibm/WebSphere/install

    /opt/.ibm/。
  • 加载 SAN 驱动器。
  • 在 SAN 上为 .nifregistry 文件创建目录并放置对应的链接。
    (/opt/ibm/WebSphere/install/.nif

    /opt/ibm/WebSphere/install/.nif /opt/.ibm/.nif 中)
  • 将 WebSphere Process Server 或 WebSphere Enterprise Service Bus 安装到加载点的子目录(例如,/opt/ibm/Websphere/install/ProcServer)。
  • 将更新安装程序安装到相同加载点的子目录中(例如,/opt/ibm/WebSphere/install/UpdateInstaller)。

灾难数据中心的配置

  • 创建类似的目录、加载点和符号链接。
  • 为安装复制卷加载灾难站点恢复脚本或过程

开发

  • 需要的情况下在灾难站点上加载驱动器的脚本或过程。

下图中显示了此配置的一个示例。在图中,目录结构映射到磁盘系统。 不过,.nifRegistry 文件的位置在不同平台上可能会不同,不安装在根目录中时也会有所变化。通过此图,我们还发现,数据中心的所有操作系统映像的 WebSphere 安装都包括在相同的复制卷中。

不应根据计划捕获此复制卷的快照,而要在每次安装映像之一发生更改时捕获快照。在安装尚未完成时捕获的快照都是无法使用的安装映像视图。尝试在灾难中心使用此类快照时,将得到无法预测的结果。为了防止出现有问题的快照,应该使用“随需应变”模型捕获安装卷的快照,并在每次安装数据发生变化时捕获快照。

导致安装数据变化的操作类型包括:

  • 安装新 WebSphere 实例
  • 将修补程序包应用到 WebSphere 实例
  • 将修补程序应用到 WebSphere 实例
  • 安装 UpdateInstaller
  • 更新 UpdateInstaller

由于所有映像都在单个复制卷上,因此能够准确地在灾难数据中心复制原始数据中心配置。如果在环境中实施某个安装更改时出现灾难事故,然后灾难数据中心中的环境将允许您按照自己定义的速度实施安装更改。

图 2. 安装数据的目录结构
目录结构
目录结构

安装注册表的可用性至少能够支持使用卸载机制。如果选择使用依赖于这些安装注册表的机制管理灾难数据中心,则要在灾难中心的 LPAR 上安装 WebSphere。安装之后,您能够根据此部分前面给出的复制模型进行替换。

配置数据

系统的配置数据描述 WebSphere 环境。

您将希望灾难数据中心具有与主要数据中心相同的配置,以便完成任何恢复工作。

您的配置数据包括概要根和在 <install root> 子文件夹中的数个其他文件。这些文件包括:properties/profileRegistry.xml、properties/fsdb/* 和 properties/Profiles.menu。另外还包括 logs 目录中的文件,此目录包含与概要操作相关的错误,可能在灾难数据中心中有用。

请通过以下配置将此数据包括在磁盘复制系统中:

原始数据中心的配置

  • 创建用于加载 SAN 的目录,如:(/opt/ibm/WebSphere/profiles)。
  • 加载 SAN 驱动器。
  • 在该加载目录的子目录中创建概要 (/opt/ibm/WebSphere/profiles)。

灾难数据中心的配置

  • 创建用于加载的类似目录。
  • 为配置复制卷加载灾难站点恢复脚本或过程。

开发

  • 用于加载磁盘的脚本或过程。
  • 用于处理主机名变更的脚本。
  • 用于启动灾难中心的管理流程的脚本。
  • 用于启动灾难中心资源的脚本。

过程

  • 还需要考虑概要更改,因为其中也包括安装更改。这意味着,创建概要、删除概要、添加节点、删除节点操作均应触发安装数据的快照捕获。这需要为存在的这些配置更改捕获安装数据快照,因为这些更改中修改的一些文件包含在安装数据中。(此类文件示例已在前面列出,位于安装根目录的子目录中。)

下图中显示了此配置的一个示例。在图中,目录结构映射到磁盘系统。在概要根目录外的文件将被忽略,因为在概要操作更改中包括安装卷快照时,这些文件将变得不相关。

图 3. 配置数据的目录结构
配置数据
配置数据

不应根据某种计划捕获此复制卷的快照,而要在每次配置映像之一发生更改时捕获快照。保存更改时以及配置更改复制到节点时,配置映像将发生更改。在配置更改尚未完成时捕获的快照都是无法使用的安装映像视图。尝试在灾难中心使用此类捕获时,将获得无法预测的结果。为了防止出现有问题的快照,应该使用“随需应变”模型捕获配置卷的快照,并在每次配置发生变化时捕获快照。

由于所有映像都在单个复制卷上,因此能够准确地在灾难数据中心复制原始数据中心配置。如果在环境中实施更改时出现灾难,则在灾难数据中心中重新启动环境时,将继续实施配置更改,不会强制比您预期的速度更快的速度实施更改。

运行数据(持续复制)

系统的运行数据为与应用程序相关的信息。这包括事务和业务流程状态。

您将希望运行数据的所有组件保持一致,以便灾难站点将具有一致的数据。由于运行数据在持续变化,因此希望灾难数据中心具有与主要数据中心相同的状态的想法并不合理,除非使用了同步复制。在很多情况下,同步复制都不是有效的选项,因为同步实现对性能影响非常大。

运行数据包括 WebSphere 事务日志、与流程服务器数据库关联的一些文件以及与任何其他资源管理器关联的一些文件。我们所感兴趣的文件是反映数据库表的当前状态、事务的当前状态以及任何反映资源的当前状态的由资源管理的其他数据。这些文件将根据所选的数据库产品或资源管理器和供应商的不同而不同。在此运行数据中包括的数据库表至少包括与您的流程服务器配置相关的所有表(消息传递引擎、业务流程、人工任务、失败事件、关系等的持久存储区)。

请通过以下配置将此数据包括在磁盘复制系统中:

原始数据中心的配置

  • 创建加载 SAN 所需的目录,如在 WebSphere 计算机上创建 /opt/ibm/WebSphere/tranlogs 目录,在数据库计算机上创建 /opt/ibm/WebSphere/database 目录。
  • 加载 SAN 驱动器。
  • 配置 WebSphere 事务服务,将此加载用于其事务日志。
  • 配置数据库,将此加载用于其数据库和日志。

灾难数据中心的配置

  • 创建用于加载的类似目录。
  • 为运行数据复制卷加载灾难站点恢复脚本或过程。
  • 安装和配置数据库目录,以查找相应的文件。

图 4 显示了此配置的示例。此图显示了映射磁盘系统的目录结构。所有运行数据的数据都需要包括在相同的快照中,而且快照需要即时捕获。您的性能需求可能需要将数据库日志文件放置在与数据库数据不同的磁盘上,或需要采取其他放置方式。您将需要与数据库供应商、SAN 供应商和操作系统供应商进行协作,以确定满足您需求的最优配置。与 SAN 供应商协作时,您需要确保快照和副本中保留了写入顺序。只有数据快照实现了写入顺序一致,才能保证运行数据的一致性。

图 4. 运行时数据的目录结构
运行时数据
运行时数据

您将希望设置此卷的某种快照捕获计划。此计划将确定是否能够满足恢复点目标 (RPO)。例如,如果 RPO 为 30 分钟,则将需要捕获间隔时间小于 30 分钟的快照。您需要考虑实际捕获快照并将其传输到灾难数据中心所需的时间。但您的 SAN 提供商可以帮助您确定所有这些细节。

WebSphere 配置

安全性

您将在一个系统上创建并写入文件,然后在其他系统上读取相同的文件。由于使用操作系统级别的安全性,因此将需要确保系统间的用户和组保持一致。这些操作系统可以使用 ID(而不是名称)实际管理所有权和文件访问权限。您需要两个系统都能识别相同的 ID。

使用 LDAP 管理安全性时,将需要确保原始数据中心的 LDAP 服务器提供的 ID 与灾难数据中心的 LDAP 服务器提供的 ID 相同。使用操作系统安全性时,需要确保两个系统会将相同的名称转换为相同的 ID。可以通过在管理操作系统上的标识时使用 ID 来实现这个一致性。(例如,如果使用 Unix 操作系统,则需要使用 adduser 命令的 –u 选项。)

主机名

由于恢复数据中心与原始数据中心实际并不是同一套系统,因此可能希望恢复数据中心中的操作系统映像使用与原始数据中心中不同的主机名。您将需要考虑两种类型的主机名:安装 WebSphere 的主机名和数据库的主机名。

承载 WebSphere 概要的 LPAR 的主机名包含在名为 serverindex.xml 的一组配置文件中。计算单元中的每个节点的每个概要中都包含一个此类文件。例如,某个计算单元具有 15 个节点,其中的节点之一名为 Node1,则 Node1 将有 16 个 serverindex.xml 文件副本。所有 15 个节点和 dmgr 都将具有一个 config 目录,每个 config 目录都将具有一个与 Node1 对应的目录。在该目录中,将会有名为 serverindex.xml 的文件。该文件中包含的主机名需要从原始数据中心中使用的主机名更改为灾难数据中心中使用的主机名。如果您在命名方面很谨慎,则能够创建可自动修改这些名称的脚本,此脚本可以与复制 profileRegistry.xml 文件的脚本同时执行。例如,可以采用此命名方案:将原始数据中心中的主机命名为 DC1xxxxx,将灾难数据中心中的主机命名为 DC2xxxxx。还可以使用短名称,甚至使用相同的名称而仅仅更改域名。不过,需要对要包含在 serverindex.xml 文件中的名称进行解析。

承载数据库的 LDAP 的主机名在 WebSphere 中配置,并作为二进制条目包含在事务日志中。因此,没有办法通过更改配置值来更改主机名。替代方法是,在两个数据中心中为数据库主机使用相同的 IP,或使用某种其他机制来将工作路由到多个目的地。有些数据库提供能够为数据库配置多个 IP 地址的功能。当主要目的地不可用时,此数据库功能会将通信定向到灾难数据库(例如:DB2 HADR 或 Oracle RAC)。不要将此与数据库的异步复制功能混淆,因为用于异步复制数据的数据库功能效率低下,不应该予以采用。

文件同步

因为对何时将出现灾难不能控制,因此可能需要控制灾难中心中的节点和 dmgr 的同步方式。因为这个需求的原因,您将需要关闭启动时重新同步节点的功能。可以通过设置节点代理的文件同步服务的配置来关闭节代理上的自动重新同步。

持续维护

持续管理此环境的过程包括数据的管理,以及启动灾难数据中心来验证环境是否完整。管理数据的过程属于快照管理工作的一部分。应该在灾难计划持续测试中包括灾难数据中心的启动。

管理快照

您需要两个模型来管理快照:

  • 随需应变模型
  • 定期计划模型

进行安装更改时,将要捕获安装的快照。安装更改包括应用修补程序或修补程序包或创建新安装映像。

有一段时间安装映像会存在不一致,在此期间捕获的任何快照都不能在灾难数据中心中使用。这个时间段从开始安装更改时开始,到安装更改完成时结束。安装更改的最后一步应是捕获安装更改的快照。如果通过脚本应用安装更改,则还应该在脚本中最后包含与 SAN 交互的调用,以捕获和复制快照。

如果实施安装更改,则应该在更改实施到每个实例后捕获快照。通过此行为,可以启动灾难数据中心,但无需首先完成安装更改的实施。

与此类似,有一段时间配置映像会存在不一致,在不一致期间捕获的任何快照都不能在灾难数据中心中使用。

dmgr。对于 dmgr,此时间段从指示应该保存配置更改时开始,到保存完成时结束。

节点。对于每个节点,此时间段从指示应该与 dmgr 同步配置更改时开始,到同步完成时结束。

创建、删除、扩充或精简概要。此时间段也从创建、删除、扩充或精简概要时开始,在概要命令完成时结束。

联合概要或删除节点。此时间段也从联合概要或从计算单元删除节点时开始,在联合命令完成时结束。

配置更改的最后一步应该包括捕获配置数据的命令。此外,如果更改涉及到概要命令或概要联合命令,则还应该捕获安装映像的快照。

运行数据不是使用“随需应变”模式处理的复制卷,应该设置为定期捕获快照。这个时间段确定了您的灾难数据中心的恢复点目标 (RPO)。对于安装和配置更改,可以创建相应的构建流程,以免数据中心丢失任何配置或安装数据更改。不过,可能很难在运行数据方面实现“无数据丢失”的环境。因为其变化非常快,而又选择了异步复制,因此灾难数据中心将丢失上次快照之后到出现故障之前由主要数据中心处理的所有数据。

事实上,您可能会希望保持数个数据快照,以在上个快照不能用的情况下救急。磁盘上数据的状态可能不可用,因为捕获快照时,磁盘上的数据被视为处于崩溃一致状态。也就是说,恢复到快照的磁盘上的数据与操作系统崩溃前磁盘上的数据接近。当这导致某些扇区或节点无效时,将最终丢失宝贵的数据。如果是这样,可能会需要恢复到之前的检查点时间。请与 SAN 提供商和操作系统提供商核实详情。

测试环境

最糟糕的情况是,由于灾难而需要启动灾难数据中心时,却发现在灾难恢复中未设置某些项目。这种情况可以通过进行一些测试予以消除。测试灾难流程的一种方法是将灾难数据中心隔离,首先不允许任何出站通信流量传出数据中心。然后停止定期复制,并将磁盘供灾难中心用于进行恢复。隔离之后,应该测试环境,并验证灾难中心是否能够使用复制的数据进行恢复,并验证灾难中心是否能够处理负载。进行此工作时,应该选择能够承受由于不复制数据而导致风险升高的时间。验证恢复完成后,可以重新连接副本,继续使用之前的保护级别。

启动灾难中心

启动此数据中心需要进行一系列工作。其中大部分工作都可以很早就完成,可以使用脚本来保持一致性、简单性和可重复性。启动此数据中心所需的步骤为:

  1. 将存储设备连接到灾难数据中心的操作系统映像。
  2. 启动 WebSphere 环境。
  3. 开放数据中心处理工作。

选择快照

启动灾难数据中心时,将需要选择快照。选择运行数据快照,通常为传输到灾难数据中心的最后一个快照。如果出现故障时正在安装或卸载应用程序的话,则是例外。在此情况下,您将需要选择在保存更改前捕获的运行数据快照。

所选择的配置数据和安装数据通常为传输到灾难数据中心的最后一个快照。当两个快照是由于单个安装或配置操作导致时例外。在此情况下,您需要选择两个快照一致的最后一个快照。

流程

与将存储设备连接到操作系统的关联的活动为:

  1. 将磁盘的模式从复制原始数据中心的数据更改为作为操作系统映像的数据源使用。
  2. 将最后的良好快照恢复到将用于恢复数据中心的磁盘。例如,安装卷、配置卷和运行数据的最后快照。要使用哪个快照,取决于在捕获快照时所处于活动状态或非活动状态的安装和配置操作。使用与运行数据一致的快照。
  3. 使磁盘对操作系统映像可用。这可能需要执行一些过程来检查和修复任何由于“崩溃”状态被破坏的文件。

与启动 WebSphere 环境关联的活动:

  1. 启动数据库服务器。
  2. 启动 dmgr 和节点代理。
  3. 启动消息传递集群。
  4. 启动支持集群。
  5. 启动应用程序部署集群。

要开放数据中心处理工作,请将路由器设置为指向新环境。

不要低估构建到复制数据的可靠且可重复的连接所需的工作。另外,请确保不断对此路径进行测试。如果在此流程中出现任何错误,复制的数据对操作系统不可用,则灾难的影响将会加剧。这是应该经常进行全面测试的关键路径之一。

灾难数据中心中的重要事项

进行以下监视:

  • 启动消息传递集群后,可以查看消息传递引擎中的消息。这样可以看到在捕获快照时队列上的任何消息。不应对其进行任何操作,但可以通过这样了解一些队列的队列深度。
  • 如果选择查看消息,可能会看到其中一些具有与其关联的事务。与此事务关联的消息是正在放入队列或从队列删除的消息以及事务正在处理的消息。
  • 启动支持集群后,将会注意到与业务事件关联的消息将会开始进行处理,任何与其关联的事务将会完成(除非需要应用程序集群来完成事务)。
  • 启动了应用程序集群后,将会注意到与应用程序关联的消息将会得到处理,与其关联的事务将会完成。
  • 当整个灾难数据中心完成启动流程后,应该看到所有业务流程都处于一致状态,准备好进行后续操作了。

扩展本文中给出的理论

本文中所述的环境细节取决于一系列设计选择。在此部分,我们将分析一些功能的备选选项以及这些选项对目前所描述的环境的影响。

灾难数据中心容量较少

如果灾难数据中心的容量比主要数据中心少,仍然需要灾难中心具有与主要数据中心相同的配置。不过,可以将恢复序列化,以减少所需的即时容量。此序列化允许在整个计算单元进行恢复,但仅仅需要足够支持少于完整拓扑的容量即可。

以此方式进行恢复时,将需要一定的开发工作来对恢复进行编排。例如,不需要为恢复启用故障转移消息传递,因此支持将消息仅传递到具有活动消息引擎的服务器所需的服务器数量更少。此外,可以将每个应用程序集群成员的恢复序列化,允许集群成员恢复任何活动,然后在完成后停止该群集成员并处理下一个成员的工作。

以分阶段方式恢复的另一个示例是环境中包括 WebSphere Business Monitor 时的情况。您可以首先恢复生成事件的所有应用程序,然后再恢复这些事件的处理工作。

不过,如果决定使用较少的容量进行恢复,将需要开发恢复活动的编排,这很可能需要非常了解应用程序。

不要将磁盘复制用于安装和配置数据

您可以选择使用其他方法将数据复制到灾难数据中心。例如,您可能会希望考虑 backupConfig 和 restoreConfig 命令。 您可能还有兴趣试试自定义安装技术(Installation Package Technology,CIP)。在考虑任何此类技术时,都应该始终考虑消息传递引擎的数据和事务管理器的数据只能供具有完全相同配置的服务器使用的条件。

对于安装映像,可以使用“双维护”方法,通过运行相同的命令创建两个“完全相同”的数据中心。不过,不能使用相同方法创建配置映像。在两个不同的数据中心运行相同的命令将为资源生成不同的 UUID。 只有两个数据中心具有相同的 UUID,主要数据中心中的数据才能在灾难数据中心中使用。因此,在灾难数据中心中运行与主要数据中心相同的配置命令无法实现我们在本文中描述的灾难恢复解决方案。

在灾难中心使用相同的主机名

在原始数据中心和灾难数据中心中使用相同的主机名或相同的 IP 时,并不需要包括更改主机名或主机 IP 的脚本,也不需要更改虚拟名称来处理主机名更改。

使用数据库复制产品

如果使用异步复制,则不需要尝试使用数据库复制产品进行运行数据复制。这是因为由数据库管理的数据并不够。数据库复制产品并不进行任何工作来同步 WebSphere 事务日志,将会导致灾难数据中心处于不一致状态。运行数据的快照需要包括数据库数据和事务日志。其他任何东西都会导致灾难恢复站点处于不一致状态。

利用安装注册表

与通过在两个数据中心上应用相同的安装操作来管理灾难数据中心的安装相比,使用安装数据副本的缺点之一是,无法在灾难数据中心上卸载二进制文件。这是因为卸载代码使用安装注册表来识别所安装的组件。如果希望创建灾难中心,以便其利用这些注册表,则将需要在灾难中心上安装 WebSphere Process Server 或 Enterprise Service Bus,而不是仅仅依赖于所加载文件系统的存在。

进行这些安装时,应该为安装加载将由所复制的安装映像副本替换的卷。(ismp 注册表保存在位置类似于 /root/vpd.properties 的文件中。)

与数据中心的其他部分集成

本文讨论了数据中心的 WebSphere 组件。您可能会将数据中心的其他组件(例如,数据库)的安装和配置包括进来。不过,将不会在这里讨论如何进行此工作以及应该在每个卷中包括哪些内容。当然,数据库的运行数据是此集成的例外。数据库的表和日志以及 WebSphere 的事务日志包括在相同的一致性分组中。

总结

本文介绍了使用磁盘复制系统的异步复制来实现包括 WebSphere Process Server 或 WebSphere Enterprise Service Bus 的灾难恢复数据中心的环境。以下是一些灾难恢复配置注意事项和基本操作流程的简单总结。

灾难恢复配置注意事项

配置注意事项包括:

  1. 磁盘子系统,可以捕获主要数据中心中的数据的快照,并将复制到灾难数据中心。此子系统可以作为网络连接存储(Network Attached Storage,NAS)设备或存储连接网络(Storage Attached Network,SAN)进行连接。
  2. 三个复制卷,经过恰当设置,能保证每个卷的一致性。一个卷用于安装,一个卷用于配置,剩下一个卷用于运行时数据。运行时数据包括 WebSphere 的事务日志和数据库的日志与数据。
  3. 安装和配置的快照,根据需要捕获,是任何安装或配置更改的最后一步。运行数据快照将定期捕获,这个定期时间间隔定义灾难数据中心的恢复点。
  4. 选择在灾难数据中心中使用与原始数据中心不同的主机名,则需要在配置文件中进行一些更改,以便移动到灾难数据中心。也必须仔细管理配置为供 WebSphere 使用的数据库的主机名。

基本操作流程(持续操作)

执行以下持续操作:

  1. 进行安装更改时,请捕获安装数据的快照并将其传输到灾难数据中心。
  2. 进行概要更改时,获取配置数据快照和安装数据快照,并将其传输到灾难数据中心。
  3. 安装或卸载应用程序时,在保存更改前捕获运行数据快照。保存更改后,捕获运行数据快照和配置数据快照。
  4. 进行任何其他配置更改时,请捕获配置数据的快照并将其传输到灾难数据中心。
  5. 持续捕获运行数据快照,并将其传输到灾难数据中心。

启动灾难数据中心:

  1. 确定为每个数据卷使用的快照。
  2. 在磁盘上提供该数据。
  3. 向灾难数据中心的 LPAR 提供磁盘映像。
  4. 更改主机名或 IP 地址(如果需要)。
  5. 启动数据库和 WebSphere 管理进程。
  6. 启动 WebSphere 集群,以恢复所有动态工作(首先是消息传递,接着是支持,然后是应用程序部署)。
  7. 开放数据中心处理新工作。

必须定期测试环境,以验证用于将磁盘连接到操作系统的机制仍然是可靠的连接。


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=378405
ArticleTitle=用于灾难恢复环境的 WebSphere Process Server 和 WebSphere Enterprise Service Bus 异步复制
publish-date=04012009