WebSphere Process Server 产品的运行时升级和移植策略及参考实现

本文将对 WebSphere Process Server 的运行时系统升级和移植策略进行全面系统的介绍，并结合一些典型的拓扑结构给出相应的参考实现。通过阅读本文，读者可以根据自己生产环境目前的状况，清楚、准确的选择相应的升级策略并加深对 WebSphere Process Server 产品的认识。

概述

随着面向服务的架构（SOA）的概念日渐深入人心，越来越多的企业采用面向服务的架构来改造企业的现有 IT 架构或者升级企业的现有服务。WebSphere Process Server（简称 WPS）作为 IBM 面向服务架构战略的核心产品之一拥有众多的客户，IBM 于 2005 年底推出该产品的第一个版本 WPS6.0，并在随后的几年中陆续推出了几个新版本和一些补丁包，目前最新的版本是 WPS6.1.0.1。随着新版本的不断推出，已经在以前的 WPS 版本上部署应用的客户也非常希望利用新版本提供的丰富功能，但同时又希望保留原有的配置信息和部署的应用程序以节省投资和降低系统当机时间。WPS 提供的运行时升级功能可以满足客户的这个需求。然而对于不同的升级路径和 WPS 版本，客户需要采用不同的升级策略，目前 WPS 提供本地升级（In-place upgrade）和版本移植 (Version-to-Version migration) 两种形式的运行时升级支持 , 但是升级支持的文档信息比较分散，给客户和支持人员带来了一些困扰。本文将对 WPS 的升级策略进行系统的阐述并结合一些常见的拓扑结构给出具体的建议。通过阅读本文，读者将对 WPS 的运行时升级支持有个清晰的理解，可以更加准确的应用该功能升级自己的系统本文将对这两种更新方式进行系统的介绍并结合一些典型的拓扑结构给出了运行时更新的参考实现。

1.1 本地升级

WPS 的运行时本地升级基于 WebSphere Application Server Network Deployment 的运行时本地升级系统。本地升级的过程可以用一个图形工具（Update Installer）来交互的安装 WPS 的补丁包，也可以用补丁包中提供的命令行工具来自动完成运行时的本地升级。需要的 Update Installer 的版本和要安装的 WPS 补丁包的版本有对应关系，在实际执行本地升级时要注意检查相关的版本信息，否则本地升级有可能遇到问题而失败。运行时本地升级是通过更新已有的 WPS 安装目录下的文件来实现的，以单个的 WPS 安装目录为单位，每次本地升级操作会将某一个安装目录下所有的概要（Profile），节点（Node）和服务器（Server）进行更新。已部署的应用程序可以在更新后的系统上继续运行，无需进行任何更改或重新配置操作。

图 1. 本地升级图

2.2 版本移植

WPS 从 V6.1 开始提供版本移植（Version-to-Version migration）功能。同本地升级类似，WPS 提供了图形化工具和命令行工具供用户选择。在进行版本移植前，需要在装有要移植的 WPS 系统的机器上安装最新版的 WPS，而且新版本 不 能装在和原有的 WPS 相同的安装目录内。版本移植是以单个概要（Profile）为操作单位，依次进行的。版本移植的过程分成两个大的阶段：在第一个阶段，移植工具会将低版本 WPS 概要（Profile）上的应用程序及配置信息备份到本机的一个临时目录；在第二个阶段，移植工具从临时目录读取信息，将其中的应用程序自动安装到新版本的 WPS 概要（Profile）上，并根据临时目录中已保存的配置信息对新版本概要（Profile）进行相应配置。移植后的新系统仍旧使用原来的数据库来存储信息，但数据表的 Schema 有可能会更新。移植完成后，原有的 WPS 系统可以被完全卸载也可以原封不动，但原有系统不能再被启动。

图 2. 版本移植示意图
 

WPS 的版本策略

在上一章节中多处提到了 WPS 的版本信息，本地升级时对升级工具和 WPS 的补丁包都有版本要求。本章节将对 WPS 的版本划分策略做一个简单介绍。WPS 产品是基于 WebSphere Application Server Network Deployment ( 简称 WAS ND) 产品的，所以 WPS 采用和 WAS ND 相同的版本演进策略。版本信息最长用四个数字表示，数字中间以点号分割，表示为 Vx.y.m.n。x 位指示版本号（version），y 指示发布版号（release），m 指示改进版号（modification），n 指示修正版号（fix）。

由 Vx.y 表示的发布版本含有重要的功能更新，可以独立安装例如：V6.1；由 Vx.y.m 表示的升级包版本含有少量功能更新，一般不能单独安装，只能基于相应的发布版进行安装例如：V6.0.2；由 Vx.y.m.n 表示的修正版例如：V6.0.2.2 是最近发布的补丁（ifix）以及一些小的改动的集合，一般也不能单独安装。升级包版本和修正版本统称补丁包。除此之外，WPS 还会经常的发布一些单个的补丁对已发布版本中发现的问题进行及时的纠正。所有的补丁包都能从 IBM 的官方网站 下载。

WPS 本地升级和版本移植的选择策略

虽然 V6.0 是 WPS 的第一个版本，但 v6.0.1 是推荐的可以用来作为升级或移植的起点的版本，目前已经推出的最新版本是 v6.1.0.1。v6.1 是一个里程碑版本，v6.1 之前的版本，只能通过版本移植来更新到 v6.1。在下图 3 中，分界线两侧集合中的任一低版本 WPS 可以通过本地升级方式更新到本集合中的任何一个高版本的 WPS，而左侧集合中的任何一个版本只能通过版本移植方式更新到右侧集合中的任何一个版本中。版本移植后的 WPS 也可以继续进行本地升级，例如 WPS v6.0.2 -> WPS v6.1 -> WPS v6.1.0.1。

图 3. 本地升级和版本移植策略
 

WPS 本地升级典型拓扑及参考实现

WPS 本地升级的具体操作步骤和现有系统的拓扑结构有紧密的联系。本章节将列出一些典型的拓扑结构并给出其参考实现。

4.1 本地升级的注意事项

1. 在对环境进行升级之前，建议先对环境进行备份（包括对所有数据库和配置文件的备份），有两种方式可以进行备份配置文件操作
   • 使用 WPS 的 backupConfig 命令备份配置文件
   • 压缩整个 WPS 安装目录，或者安装目录下的概要（Profile）目录
2. WPS 支持卸载补丁包文件，但是卸载过程是无法恢复对概要（Profile）配置文件所做的修改的，所以如果升级失败或者由于其它原因需要恢复备份环境，不能通过简单的卸载补丁包来实现，而是首先在升级前要选择以上两种方式之一对系统环境进行有效备份，恢复的时候采用 restoreConfig 命令或者直接恢复备份好的 WPS 目录。
3. 用 Update Installer 图形安装工具安装补丁包时，补丁的安装必须按照补丁包安装说明里指定的顺序进行安装

4.2 独立概要服务器（stand alone profile）

独立概要服务器的拓扑（如图 4 所示）是最简单的一种拓扑，一般用在开发环境中。该拓扑结构的特点是只含有一个概要（profile），且该概要（profile）中只有一个应用程序服务器。

图 4. 独立概要服务器拓扑示意图

独立概要服务器拓扑本地升级的参考实现

1. 停止应用服务器（application server）
2. 用 Update Installer 或命令行工具安装补丁包。
3. 在 /ProcessChoreographer 目录下，用以下命令手动执行 bpeupgrade.jacl 脚本：
   ..\bin\wsadmin -conntype NONE -profileName -f config\bpeupgrade.jacl

注意： 指的是 WPS 的安装根目录，下同。 指的是配置了业务流程编排器（Business Process Choreographer ）的概要名称。

4.3 不含集群（Cluster）的网络部署（Network Deployment）

不含集群的网络部署拓扑结构（如图 5 所示）的特点是，单元（cell）中有一个部署管理器节点（Deployment Manager），该节点负责管理其它的节点（node），且部署管理器节点和其它的节点不在同一个安装目录下，但是该单元中不含任何的集群（cluster）。

图 5. 不含集群的网络部署拓扑示意图

不含集群的网络部署拓扑本地升级的参考实现

1. 停止部署管理器（Dmgr）
2. 在部署管理器安装目录上应用补丁包
3. 启动部署管理器（Dmgr）
4. 对于同一单元（cell）里的各个节点（node）Node01、Node02, 重复以下步骤 逐一顺序 升级。

1. 1. 停止该节点（node）上的所有应用服务器（application server）和节点代理（node agent）
   2. 在节点所在安装目录上应用补丁包
   3. 如果升级路径是从 WPS 6.0.2.x 到 6.0.2.y （y > x），需要在 节点 所在机器上，切换到 /ProcessChoreographer 目录，用以下命令手动执行 bpeupgrade.jacl 脚本：..\bin\wsadmin -profileName -f config\bpeupgrade.jacl
      注意： 指的是该节点上的概要名称。
   4. 重新启动该节点上的节点代理（node agent）和所有应用程序服务器 (application server).
   5. 升级过程完毕。

4.4 含有集群（Cluster）的网络部署（Network Deployment）

含有集群的网络部署拓扑（如图 6 所示）是最常用的生产环境拓扑，也叫做黄金拓扑（Golden Topology）或 ND7。该拓扑的特点是在单元（cell）中有一个部署管理器节点， 且该部署管理器节点单独占用一个 WPS 安装目录 。在其它的节点上有多个集群，其中有一个专门的消息集群（MECluster）为整个单元提供消息服务。在单元中有一个应用集群（APPCluster）用来部署业务流程编排器（Business Process Choreographer），还有一个支持集群（CEICluster）用来提供 CBE（Common Base Event）事件服务。

图 6. 含有集群的网络部署拓扑示意图

含有集群的网络部署拓扑本地升级的参考实现

1. 停止部署管理器（Dmgr）
2. 在部署管理器安装目录上应用补丁包
3. 启动部署管理器（Dmgr）
4. 对于同一单元（cell）里的所有节点（node），停止节点上的所有应用服务器（application server）和节点代理（node agent）
5. 在各个节点所在安装目录上应用补丁包
6. 在部署管理器 (Dmgr) 机器上，切换到 /util 目录，用以下命令对同一单元里的 每个 集群手动执行 WbiProfileUpgrade.jacl 脚本：
   ..\bin\wsadmin -profileName -cluster -f WbiProfileUpgrade.jacl
   注意： 指的是部署管理器所在的概要名称， 指的是单元中每个集群的名称。
7. 重新启动整个环境
8. 升级过程完毕

4.5 部署管理器和节点在同一个安装目录下

当部署管理器和某一个节点创建在同一个安装目录下（如图 7 所示）时，升级步骤和 含有集群的网络部署拓扑参考实现 步骤大致相同，唯一的区别是升级部署管理器时需要同时停止 Node01 的节点代理（node agent）以及 Node01 上的应用服务器，当在部署管理器安装目录应用补丁包时，Node01 以及 Node01 上的应用服务器是被同时升级的。

图 7. 部署管理器和节点在同一个安装目录
 

服务停止时间敏感（downtime critical）的升级方法

客户的环境对于升级过程中的停机时间是非常敏感的，客户总是希望在升级过程中系统停机时间越短越好，WPS 的本地升级对于客户的这个需求提供了支持。停止服务时间敏感的升级是一种升级的方式，被升级的系统中需要有水平集群（horizontal cluster）。以 图 6 所示拓扑结构 为例，实施停止服务时间敏感的升级过程需要如下关键步骤：

1. 升级部署管理器
2. 识别出单元中的所有水平集群，在图 6 的拓扑中有三个 APPCluster，CEICluster 和 MECluster
3. 将步骤 1 识别出的水平集群的成员所在的节点划分到几个集合，每个集合中的节点只能包含每个水平集群中的一个成员（cluster member），图 6 的拓扑中节点被划分成两个集合 Node01 和 Node02，步骤 2 和 3 非常关键，要仔细进行划分。
4. 停止 Node01 上的节点代理和所有应用服务器，但 Node02 上的服务继续运行。
5. 在节点 Node01 上应用补丁包
6. 停止 Node02 上的节点代理和所有应用服务器并应用补丁包
7. 在部署管理器 (Dmgr) 机器上，切换到 /util 目录，用以下命令对同一单元里的 每个 集群手动执行 WbiProfileUpgrade.jacl 脚本：
   ..\bin\wsadmin -profileName -cluster -f WbiProfileUpgrade.jacl
   注意： 指的是部署管理器所在的概要名称， 指的是单元中每个集群的名称。
8. 重新启动整个环境
9. 升级过程完毕

WPS 版本移植典型拓扑及参考实现

版本移植使用不同于本地升级的工具来完成，本章以 WPSv6.1 作为目标版本，给出了版本移植的典型拓扑结构和参考实现。

6.1 版本移植的注意事项

1. 在对环境进行移植之前，建议先对环境进行备份（包括对所有数据库和配置文件的备份）
2. 在移植之前，需要在已经装有 WPS 的机器上安装最新版本的（至少是 v6.1）WPS，且安装在和原有 WPS 不同的目录下
3. 图形的移植工具可以帮助用户在移植过程中自动的创建目标概要（target profile），但用户也可以在移植开始之前手工的创建目标概要，手工创建的目标概要必须和源概要（source profile）使用相同的单元名（cell name）和节点名（node name）
4. 如果目标概要属于一个网络部署结构（Network Deployment），手工创建的目标概要在移植之前不能联合（federate）到任何单元中。
5. 如果目标版本是 WPS v6.1，在安装 WPS v6.1 后并开始进行任何操作前，必须立即应用 WPS v6.1 的关键补丁（mandatory critical ifix）

6.2 独立概要服务器（stand alone profile）

版本移植中的独立概要服务器的拓扑示意图和本地升级的相同，如 图 4 独立概要服务器拓扑示意图 。

独立概要服务器拓扑版本移植的参考实现

1. 在 WPS 先前版本所在的机器上，安装要移植到的 WPS 版本 WPSv6.1
2. 停止已有 WPS 安装上的应用服务器
3. 用图形工具或命令行工具进行移植操作
4. 根据系统中通用数据库（common database）使用的数据库类型，运行 /dbscripts/CommonDB 下的脚本升级通用数据库的 schema，例如 WPRCSDB 的 schema
5. 根据系统中业务流程编排器使用的数据库类型，运行 /dbscripts/ ProcessChoreographer 目录下的脚本升级业务流程编排器数据库的 schema，例如 BPEDB 的 schema
6. 启动新的应用服务器
7. 移植完毕

对于 WPS 独立概要服务器拓扑，还支持跨机器的移植（仅支持 Windows 操作系统平台和 RedHat Linux 操作系统平台），这就需要在迁移之前，用 WPS 发布包里特别提供的的命令行移植工具对以前的环境进行备份，然后将备份文件拷贝到目标机器，再利用 WBIPostUpgrade 命令进行迁移。

6.3 不含集群（Cluster）的网络部署（Network Deployment）

版本移植中不含集群的网络部署拓扑示意图和本地升级的相应拓扑相同，如 图 5 不含集群的网络部署拓扑示意图 。

不含集群的网络部署拓扑版本移植参考实现

1. 在单元（cell）中的所有机器上，安装要移植到的 WPS v61 版本并应用关键补丁
2. 停止部署管理器（Dmgr）以及单元中所有的节点代理和应用服务器
3. 对部署管理器进行移植
4. 根据系统中通用数据库（common database）使用的数据库类型，运行 /dbscripts/CommonDB 下的脚本升级通用数据库的 schema，例如 WPRCSDB 的 schema
5. 启动部署管理器
6. 对单元中的所有概要，逐一进行移植
7. 根据系统中业务流程编排器使用的数据库类型，运行 /dbscripts/ ProcessChoreographer 目录下的脚本升级业务流程编排器数据库的 schema，例如 BPEDB 的 schema
8. 启动新的单元中的节点代理和应用服务器
9. 移植完毕

6.4 含有集群（Cluster）的网络部署（Network Deployment）

版本移植中含有集群的网络部署拓扑示意图和本地升级的相应拓扑相同，如 图 6 含有集群的网络部署拓扑示意图

含集群的网络部署拓扑版本移植参考实现

1. 在单元（cell）中的所有机器上，安装要移植到的 WPS v61 版本并应用关键补丁
2. 停止部署管理器（Dmgr）以及单元中所有的节点代理和应用服务器
3. 对部署管理器进行移植
4. 根据系统中通用数据库（common database）使用的数据库类型，运行 /dbscripts/CommonDB 下的脚本升级通用数据库的 schema，例如 WPRCSDB 的 schema
5. 启动部署管理器
6. 对单元中的所有概要，逐一进行移植
7. 在 WPSv6.1 的部署管理器所在机器的 目录，对单元中已经被移植的每一个集群运行如下命令： \bin\ws_ant –f PS61 _INSTALL _ROOT >\util\WBIProfileUpgrade.ant –DmigrationDir= -Dcluster=
8. 根据系统中业务流程编排器使用的数据库类型，运行 /dbscripts/ ProcessChoreographer 目录下的脚本升级业务流程编排器数据库的 schema，例如 BPEDB 的 schema
9. 重新启动 WPSv6.1 单元中的节点代理和集群
10. 移植完毕

服务停止时间敏感（downtime critical）的版本移植方法

同服务停止时间敏感的本地升级类似，WPS 也支持服务停止时间敏感的版本移植。在进行此类版本移植之前，也需要对拓扑中的水平集群进行仔细分析，将概要分类成几个集合，然后对集合中的概要分别进行移植。

WPS 本地升级和版本移植的展望

联机热升级

在目前版本的 WPS 中，进行本地升级或版本移植的时候都需要把服务器停掉，即使是服务停止时间敏感的升级方法也会有一段停机时间，在这段时间内客户的系统是没有办法给外界提供服务的。这种停机时间在银行，电信等对停机时间高度敏感的行业会带来很大的负面影响。联机热升级（不停机升级）可以解决这个问题，WPS 在这个方面还需加强。

验证工具

目前的 WPS 并没有一个统一的工具对升级或移植之后的系统进行验证，用户只能通过检查升级或移植过程中生成的日志文件来对系统进行初步的验证。一个准确的验证工具将大大方便最终用户。

升级或移植过程

通过阅读上面的章节用户会发现，对 WPS 进行升级或移植是一个繁琐的过程，急需要分析目前的拓扑，又需要执行一些很琐碎的命令。如果能仅仅通过点击少量的按钮就能完成升级或移植，将大大提升产品的用户满意度。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-417711/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-417711/