WebSphere 迁移: 计划从高可用性环境到 WebSphere Application Server V6.1 的迭代迁移

引言

本文可帮助您将使用 IBM WebSphere Application Server 5.0.x、5.1.x 或 6.0.x 版的高可用性环境迁移到版本 6.1。您将了解到如何计划迁移，如何最小化停机时间以及如何在发生问题时迅速恢复。本文重点关注当环境中需要高可用性服务器时，如何以迭代方式迁移环境。

要获得关于迁移过程的全面说明，请一起学习本文与 developerWorks 文章迁移到 IBM WebSphere Application Server V6.1 快速指南（这两篇文章的作者相同）。

在本文中，V5 指的是 WebSphere Application Server 5.0.x 和 5.1.x 版，而 V6 则专指 V6.0.x。

本文档使用的术语

本文档中所用术语的定义：

迁移

此术语具有多种定义，涵盖较广。在本文中，迁移的含义仅限于在将 Java™ 2 Enterprise Edition (J2EE™) 应用程序 (EAR) 和 WebSphere Application Server 配置数据（例如资源和安全设置）从 WebSphere Application Server 的以前版本移到 V6.1 中时的关联操作。

迭代迁移

此概念是指，在迁移分布式环境（一个部署管理器以及一个或多个联合节点）时一次迁移一个节点，而其间未被迁移的所有其他节点则照常运行。当同一计算单元中的节点运行不同版本的 WebSphere Application Server 时，该计算单元就称为混合版本单元。

概要

此概念对 V5 中的“实例”概念进行了扩展，用于指 V6 和 V6.1 中应用程序服务器的配置数据集合。WebSphere Application Server V6 和 V6.1 只安装一次二进制文件即可提供多个概要。对于从以前版本迁移的数据而言，需要使用单一概要作为目的地。（请参阅迁移到 IBM WebSphere Application Server V6.1 快速指南。）

计算单元

指由单个部署管理器控制的一个或多个节点的集合。

联合或被联合

指向计算单元添加节点的操作；也指从属于计算单元的节点。

部署管理器概要（dmgr 概要）

此概要充当部署管理器的角色，是 V5 或 V6 部署管理器的迁移目的地。每个计算单元只能有一个部署管理器概要。（请参阅迁移到 IBM WebSphere Application Server V6.1 快速指南。）

独立或 Application Server 概要

指类似于 WebSphere Application Server 的单节点安装的概要。此类概要是计算单元内外节点的迁移目的地，但对于联合节点，建议使用自定义概要。

回页首

如何基于高可用性环境制定计划

迁移的目标是尽可能顺利地将配置升级到新的软件版本。高可用性环境具有特殊的需要，因为它们必须维护最低级别的服务器停机时间，才能保证客户机事务能够得到持续处理。迁移此类环境的最佳策略是制定一份详细的迁移计划，经常对稳定状态进行备份，并在迁移的每个阶段都准备多种回滚和恢复选择。下面是迁移方面需要注意的一些关键要点：

保持现有环境

在您未对整个迁移结果完全满意之前，请不要破坏现有的 WebSphere Application Server 环境。

• 如果使用 WebSphere Application Server 迁移工具，则需要保留原有的环境，因为它将被用作迁移的起点。
• V6.1 安装过程会将 WebSphere Application Server 的新版本安装到新目录中。保留旧的 WebSphere Application Server 安装并让其处于脱机状态并不影响新的版本。
• 新旧版本之间不存在任何冲突（例如端口冲突），因为在任何给定的时间内，都只有一个版本的 WebSphere Application Server 处于运行状态。

计划回滚时，只需保留现有的应用程序服务器环境即可，再无其他要求。

稳定状态

在执行迁移之前以及在迭代升级的每个阶段之后都应进行检查，以确保您处于稳定状态。稳定状态是指部署管理器和节点按既定方式通信，且应用程序已成功启动并在正常运行的状态。下面提供了一份针对部署管理器和联合节点的详细检查清单。其目的是通过检查来确保您在执行每个迁移步骤之前都处于稳定状态：您需要在迁移部署管理器之前确保自己处于稳定状态，并需要在迁移每个节点之前再次进行检查。

何时设置检查点和执行备份

在确定稳定状态后，您还应该经常对 WebSphere Application Server 配置进行备份。之所以需要如此多的备份，是因为它们可以在您需要时让您轻松返回计算单元迁移中的任何步骤。例如，假设您在迁移第四个联合节点之前未创建备份，但还是继续执行迁移和其他系统更改。如果您后来发现该计算单元已受到损坏，将无法回滚到开始迁移第四个联合节点之前的状态。通过在迁移的每个阶段都进行备份，您可以回滚到迁移过程中的任何特定时点。

要能够在很多上述情况下实现回滚，关键是要经常对稳定状态环境进行备份。如果您想在以后再现某个稳定状态，则可以使用最适于您的技术执行备份，包括使用 WebSphere Application Server 备份工具、基于操作系统的备份工具或其他工具。

为备份建立富有逻辑性的特定命名约定也非常重要。很多情况下，基于日期的简单命名方案并不能满足需要，因为随着创建的备份越来越多，这些名称将变得十分模糊，令人难以区分。

恢复和回滚决策

在典型的迁移过程中，您可能会遇到可恢复错误。产生这些错误的原因很多，包括管理员对混合单元的配置更改、对已部署应用程序的更新以及其他对稳定状态貌似善意的修改。出现这些问题时，您可以撤消更新，也可以通过还原环境的稳定状态来恢复更改之前的状态。但是，并非所有更改在创建后即可被立即检测到，因此，您可能在出现可恢复错误后又继续迁移了另一个节点。在此情况下，将需要执行回滚。

如果出现意外情况，并且无论您计划多么周密、测试多么详细，该情况都仍然出现，则此时也可能需要执行回滚。例如，根据在迁移测试环境时执行的负载模拟，迁移可能获得完全成功。接下来迁移生产环境。当负载自然增加时，可能会公开一些时间窗口，进而可能导致不良的应用程序行为。除非您使用代表性数据和错误插入对环境进行大量负载测试，否则仍可能出现此类问题。在此情况下，您也需要迅速回滚到现有的 WebSphere Application Server 环境。

如果您按照我们的建议制定了迁移计划并运行备份，则可以在需要时轻松地返回以前的版本。在将整个计算单元回滚到以前的版本时，需要运行 JACL 脚本并还原部分节点配置。但是，如果要返回到某个增量计算单元迁移步骤，则还需要执行更多操作；例如，在将部署管理器迁移到 V6.1 后但在迁移第二个节点（存在多个节点）之前。要返回迁移第一个节点之前的状态，则需要在开始迁移部署管理器之前对部署管理器进行备份。

通过记录最小化停机时间

回滚允许您将环境还原到迁移中的某个稳定状态，从而可最小化停机时间。其缺点在于，一旦执行回滚，在备份该稳定状态之后所进行的任何配置或应用程序更改都将丢失，这意味着您需要重新创建丢失的更新。解决此问题的最佳方式是在迁移完成之前避免或尽量减少对环境进行更改，但如果无法做到这一点，则可以记录这些更新，以便于重新创建它们。

请维护详细的文档记录，并存档更新稳定状态时使用的任何脚本解决方案。当需要执行恢复或回滚操作时，此文档记录应足以用于重新创建各个更新。我们强烈建议您记录每项操作的时间、目的、所需元素以及负责执行该操作的个人、集体或团队。每个人的文档解决方案都是唯一的，因此应确保对该解决方案进行自定义，以使其符合您的环境。图 1 是一个不错的日志风格的条目方案示例，它说明了为提供此类文档而建议的最低级别的详细信息。您可以按照自己的意图改写此示例。

图 1. 记录稳定状态后的配置和应用程序更新的示例文档

回页首

检查和备份稳定状态的过程

以下两个列表是帮助您确定配置是否稳定的常规检查清单。这些检查清单适用于从 V5 开始的所有 WebSphere Application Server 版本，而无论这些特定安装是否处于迁移范围之内。另外，您也可以将这些列表用作指导原则，并据此创建特定于自己的硬件和软件解决方案的自定义稳定状态检查清单。

联合节点的稳定状态检查清单

如果满足下列条件，则可以将配置视为处于稳定状态：

1. 节点代理已启动。请启动节点代理服务器，并验证系统输出和错误日志中是否包含任何异常。
2. SyncNode 成功。验证同步操作是否成功完成。另外，您可以通过部署管理器对此进行测试，也可以从该联合节点进行手动测试。
3. 服务器已启动。联合节点上的服务器应已按配置要求启动。其中包括集群服务器和非集群服务器。
4. 应用程序已通过验证。应用程序已成功启动并通过您的验证测试。
5. 服务器状态得到可视确认。管理控制台（也称为 wsadmin 接口）正确显示了该节点上所有服务器的状态。

部署管理器的稳定状态检查清单

如果满足下列条件，则可以将配置视为处于稳定状态：

1. Dmgr 已启动。部署管理器服务器已启动，且系统输出和错误日志中未记录任何异常或错误消息。
2. 可以执行管理操作。可以访问管理控制台应用程序（也称为 wsadmin 脚本编程接口），并可以查看配置信息。
3. 节点代理已启动。具有最新配置副本的节点代理服务器成功启动，且系统输出和错误日志中未记录任何明显异常或错误消息。
4. SyncNode 成功。如果 dmgr 已被迁移，则它必须在首次启动后与所有节点重新同步。另外，无论采用任何配置，都应对所有节点成功完成 syncNode。
5. 服务器已启动。联合节点上的服务器应已按配置要求启动。其中包括集群服务器和非集群服务器。
6. 应用程序已通过验证。应用程序已成功启动并通过您的验证测试。
7. 服务器状态得到可视确认。管理控制台（也称为 wsadmin 接口）正确显示了该计算单元中 dmgr、节点代理及服务器的状态和版本信息。

如何执行备份

BackupConfig 工具

WebSphere Application Server BackupConfig 工具是为 WebSphere Application Server 环境执行压缩配置备份的极佳资源。本文将介绍此工具的基础知识，并重点关注混合单元迁移中的各种备份选择。

概要的 bin 目录中存在一个脚本文件。该脚本将称为 backupConfig.sh 或 backupConfig.bat，具体则取决于所用的操作系统。请考虑使用下列命令行参数：

• -nostop
  此参数可防止 backupConfig 关闭正在运行的服务器。警告：如果使用此选项，则必须保存最新的配置，且备份期间不得在管理控制台中进行任何编辑。
• -profileName
  此参数会显式指定应备份的概要，从而使脚本文件的任何副本都可以备份所有概要。
• -username <username> -password <password>
  当配置中启用了安全设置，但客户机属性文件中未提供用户名和密码时，就需要使用这两个参数。

这两个参数的命令行为：

backupConfig.<extension> <filename> [options]

下面是用于 AIX® 计算机的示例：

./backupConfig.sh dmgr6.1_1.zip -nostop -profileName dmgrProfileName -username USER -password plaintextpassword

有关 BackupConfig 工具的更多信息，请参阅与您所运行的 WebSphere Application Server 版本相应的信息中心（请参阅参考资料）。

哪些内容未得到备份

WebSphere Application Server 提供的 BackupConfig 工具会备份 ${USER_INSTALL_ROOT}/config 目录树中维护的所有内容。这意味着，如果您要更改在此目录之外引用的任何内容，则还需要对该内容进行备份。

较为常见的示例是 installedConnectors 目录、WebSphere 嵌入式数据库目录（Cloudscape™ 或 Derby）的内容、installedApps 目录以及属性目录。由于 bin 目录中的 setupCmdLine 脚本包含计算单元特定的信息，因此也需要对该脚本进行备份。

另外，还需要保存在 WebSphere 安装树之外存储的所有内容。其中包括 RAR 文件、库文件以及自定义 SSL 信任存储库和密钥存储库文件。

这些列表并不全面，也不是常见配置决策的子集。您应该根据自己的具体环境来生成要备份的文件和目录的完整列表。

BackupConfig 工具的备选方案

您可以考虑的另一种选择是使用系统实用工具备份文件系统。与 BackupConfig 工具相比，此备份选择所涉及的范围要大得多，它需要用到多个系统工具。其具体做法为：使用特定于操作系统的文件系统备份方法（此处不再赘述）保存部署管理器的整个概要目录。您可以将此步骤与现有的文件系统备份策略集成在一起，以确保所有相关的 WebSphere Application Server 信息都得到备份。另外，还应当备份位于 ${WAS_ROOT}/properties 目录下的 profileRegistry.xml 文件。这样将可以保存足够的信息来重新构建部署管理器。

要确保成功回滚环境，您可能需要：

• 备份整个 V6.1 概要目录

  迁移涉及要修改的一组预定义目录和文件，但根据 V5 或 V6 配置数据中指定的说明，还需要修改其他目录和文件。因此，保证信息完整的唯一方法是备份整个 V6.1 概要目录。

• 备份所有 V5 和/或 V6 应用程序二进制文件

  缺省情况下，所有 V5 和 V6 应用程序将被重新安装到 V6.1 概要下的 installedApps 目录中。如果不覆盖迁移的缺省安装目录，则当您备份了整个 V6.1 概要目录时，将不必执行进一步的操作。您可以使用 -keepAppDirectory 参数覆盖此缺省位置，此时，应用程序将被安装到它们的原始位置。如果选择此选项，则需要备份所有 V5 和/或 V6 应用程序二进制文件。

回页首

通过回滚到稳定状态最小化停机时间

回滚整个计算单元

回滚计算单元时，需要回滚所有联合节点和部署管理器。这是因为，WebSphere Application Server 要求部署管理器的版本和修补程序包级别等于或大于计算单元中的所有节点。因此，在将部署管理器回滚到以前的版本后，还必须回滚具有较高版本的所有节点。（请参阅下一部分。）

缺省情况下，迁移工具会在执行迁移之前禁用旧版本的 dmgr 和节点代理服务器。但是，在迁移部署管理器时，可以使用 -keepDmgrEnabled 命令跳过此禁用步骤。这样可以防止禁用旧版本的部署管理器，从而也可以跳过启用旧版部署管理器的步骤。如果您无法确定是否已禁用部署管理器，则安全做法是始终运行启用操作，而不论部署管理器是否处于禁用状态。

回滚部署管理器计算单元的方法是：

1. 关闭迁移后的安装。

   必须关闭所有迁移到 V6.1 的节点代理、应用程序服务器以及迁移到 V6.1 的部署管理器。我们建议删除 V6.1 概要，但这并不是成功完成回滚所必需的。

2. 启用以前的安装。

   您必须重新启用迁移中涉及的所有节点，包括部署管理器和联合节点。有一个名为 migrationDisablementReversal.jacl 的 JACL 脚本可在节点上重新启用以前的版本。在迁移期间，该脚本位于旧版概要根目录的 bin 目录中。例如：

   • C:\WebSphere\AppServer5\bin\migrationDisablementReversal.jacl
   • C:\WebSphere\AppServer6\profiles\node1\bin\migrationDisablementReversal.jacl

   请使用 wsadmin 工具运行适当的脚本。例如：

   • 在 Linux® 或 UNIX 上：
     $USER_INSTALL_ROOT/bin/wsadmin.sh -f migrationDisablementReversal.jacl -conntype NONE
   • 在 Windows® 上：
     %USER_INSTALL_ROOT%\bin\wsadmin -f migrationDisablementReversal.jacl -conntype NONE

   另外，如果要对以前的版本应用自定义备份解决方案，则可以使用该解决方案还原以前的配置。

3. 启动以前版本的部署管理器。

   在启用所有迁移的联合节点和部署管理器后，请启动部署管理器。所有与新部署管理器连接的节点代理都必须与旧版部署管理器同步。WebSphere Application Server 的缺省设置会使正在运行的节点代理自动进行同步。而对于所有脱机节点代理，请从其中手动调用 syncNode。

4. 重新启动其他节点。

   在启用迁移的节点并将其与以前版本的部署管理器同步后，请启动其他节点。

仅回滚托管节点

当回滚已迁移节点的子集或整个计算单元时，将出现回滚托管节点的行为。如果回滚了迁移后的部署管理器和所有联合节点，就会实现整个计算单元的回滚。在回滚一个或多个托管节点时，需要已创建部署管理器的稳定状态备份，并且该备份必须包含处于旧版级别的所需联合节点；从本质上说，回滚就是将配置还原到反映所需配置快照的备份的过程。

启用以前版本的联合节点是回滚步骤之一。当配置已得到成功更新后，迁移工具将禁用以前版本的节点代理。与部署管理器迁移不同，联合节点迁移不提供跳过禁用节点代理的选项。

下面的说明需要使用部署管理器的稳定状态备份。如果您没有此类备份，请不要按照这些步骤操作；在此情况下，请改为回滚整个计算单元（详见上文）。

还原稳定备份和回滚托管节点的方法：

1. 备份部署管理器配置。

   如果不存在稳定状态备份，且当前配置并未被完全破坏，则最好现在就执行备份。备份多一点总比备份过少要好。

2. 选择部署管理器配置的稳定备份。

   系统将基于稳定配置的备份执行回滚，因此必须回滚创建该备份后迁移的所有联合节点。正如我们前面提到的，部署管理器的稳定状态备份是执行托管节点回滚所必需的。如果没有此类备份，您的唯一选择将是回滚整个计算单元。

3. 关闭服务器。

   请停止将要回滚的部署管理器和所有联合节点。

   • 请不要删除 V6.1 部署管理器概要。
   • 我们建议删除 V6.1 联合节点概要，但这并不是成功回滚所必需的。

4. 还原部署管理器。

   请从要回滚的节点（一个或多个）处于正确版本级别的配置中还原部署管理器的稳定状态备份，即您在步骤 2 中选择的备份。有关还原由 BackupConfig 创建的备份的说明，请在信息中心（请参阅参考资料）中参阅其配套工具 RestoreConfig 下的内容。实现还原的快捷方法是执行概要 bin 目录中的 RestoreConfig 脚本，同时指定由 BackupConfig 工具创建的备份：

   • 对于 Windows：
     restoreConfig.<extension> <filename> [options]
   • 对于 AIX：
     ./restoreConfig.sh dmgr6.1_1.zip -profileName dmgrProfileName -username USER -password plaintextpassword

   在使用 RestoreConfig 工具还原配置后，请从上文列出的位置中复制回已保存的任何更改信息。

5. 启用联合节点。

   您必须为要回滚的所有节点启用以前版本的安装。有一个名为 migrationDisablementReversal.jacl 的 JACL 脚本可重新启用以前版本的节点。在迁移期间，该脚本位于以前版本概要根目录的 bin 目录中。例如：

   • C:\WebSphere\AppServer5\bin\migrationDisablementReversal.jacl
   • C:\WebSphere\AppServer6\profiles\node1\bin\migrationDisablementReversal.jacl

   请使用 wsadmin 工具运行此脚本，例如：

   • 在 Linux 或 UNIX 上：
     $USER_INSTALL_ROOT/bin/wsadmin.sh -f migrationDisablementReversal.jacl -conntype NONE
   • 在 Windows 上：
     %USER_INSTALL_ROOT%\bin\wsadmin -f migrationDisablementReversal.jacl -conntype NONE

   另外，如果要对以前的版本应用自定义备份解决方案，则可以使用该解决方案还原以前的配置。

6. 启动部署管理器。

7. 同步所有节点。

   由于配置已发生更改，因此计算单元中的所有联合节点都需要下载新的配置。所有运行中的节点代理将自动完成同步。对于所有已停止的节点代理，应该使用 syncNode 脚本。

8. 启动回滚后的节点。

   启动其他节点代理。

回页首

结束语

高可用性环境需要保证正常运行时间，而良好的 WebSphere Application Server 迁移计划可帮助您实现这些承诺。本文讨论了制定高可用性环境迁移计划时的各个关键点，包括如何及何时执行备份，以及如何通过还原这些备份来恢复环境，以令其持续运行。最佳策略是制定一份详细的迁移计划，记录对稳定状态的更改，选择一种备份解决方案并了解回滚和恢复说明，这一切将有助于最小化停机时间，从而最大化您的工作成果。