ITPub博客

首页 > Linux操作系统 > Linux操作系统 > WebSphere Process Server 移植最佳实践

WebSphere Process Server 移植最佳实践

原创 Linux操作系统 作者:CloudSpace 时间:2009-05-06 15:52:01 0 删除 编辑

引言

从 WebSphere Process Server (WPS) 6.1 版本开始,WPS 支持运行时的版本移植,这意味着客户可以通过图形化向导工具(GUI)或命令行工具,对 WPS 进行版本的升级,而不需要重新搭建新版本环境。已部署的应用程序可以在更新后的系统上继续运行,无需进行任何更改或重新配置操作,这一功能对客户是十分关键的。

对于含有集群的网络部署环境,有两种方式进行移植:服务停止时间不敏感移植和服务停止时间敏感移植。服务停止时间不敏感移植是目前推荐的最安全的移植方案。在集群停止服务时间不为主要考虑因素的前提下,我们推荐使用此方案对您的环境进行移植。本文以 WPS 6.1.2 移植到 WPS 6.2 为例,讲述了通过服务停止时间不敏感的移植方式对 WPS 移植的主要步骤。

注意:本文只适用于在分布式平台上的移植过程。

移植前 WPS 6.1.2 的拓扑结构

您可以通过阅读 developerWorks 网站文章,了解更多关于 WebSphere Process Server 的迁移及移植策略:

要了解更多关于 WebSphere Process Server 的信息,请查看: WebSphere Process Server 产品专题,其中为您提供了关于 WebSphere Process Server 的最新技术资源。

本文中,我们进行的移植的拓扑结构如图 1 所示:


图 1. 远程消息和远程支持集群拓扑
远程消息和远程支持集群拓扑

这个集群环境由三个集群组成:

应用程序集群——Application Target Cluster (App Target);

远程支持集群——Support Cluster (Support);

远程消息集群——Messaging Cluster (Messaging)。

以上集群成员分布在三个自定义节点(custom node):Node01,Node02 和 Node03 上。

注意:在以上拓扑结构中使用了两个数据库。除了为 Business Process Choreographer Observer 组件配置了单独的数据库 ----- OBSVRDB 以外, WPS 的其它组件都共用一个数据库—— WPRCS612。

移植之前的注意事项

在系统移植之前,需要做好旧环境的确认和备份工作(其中包括对 WPS 概要配置文件和数据库的备份)。

移植前环境的确认

1. 重新启动整个环境,检查重启后的日志文件,确保日志中没有错误和警告信息。

2. 停止所有的应用服务器,节点和部署管理器。

环境备份

1. WPS 6.1.2 环境备份。有两种方式可以完成备份工作:

a. 备份整个 WPS 6.1.2 的安装目录。根据您的操作系统平台,具体操作如下:

Windows 环境,把整个安装目录压缩成 zip 文件格式;

Unix 环境,应用 "tar -cvf" 命令备份整个安装目录

需要恢复环境的时候,只要删除旧的 WPS 6.1.2 安装目录,然后把备份文件解压缩到相应目录就可以了。

b. 运行 backupConfig 命令备份部署管理器和其它几个节点的概要配置文件。

具体命令语法如下:

backupConfig [options]

backup_file 为备份后保存的文件名称。如果不指定保存文件名称,backupConfig 命令会自动生成一个唯一文件名。恢复环境时,应用 restoreConfig 命令进行操作。

2. 备份数据库:备份 WPRCS612,OBSVRDB 和其它所部署的应用所用到的数据库。

移植步骤

在本章中我们将讲述如何采用服务停止时间不敏感的移植方式对 WPS 进行移植。这里,我们只列出了移植过程的主要步骤和需要注意的一些特殊事项,详细步骤请参阅本文附件。

安装 WPS 6.2 版本

1. 在每台需要做移植的机器上安装 WPS 6.2 版本。这里先不要创建概要文件。

2. 阅读移植信息即时更新站点,检查 WPS 6.2 是否需要安装补丁。

3. 在移植工作之前,对 WPS 6.2 的安装目录也做一个备份,以便在移植的过程中发生异常后可以迅速的回退到最初环境,重新进行移植。

移植部署管理器(dmgr)

1. 部署管理器(dmgr)移植。有两种方式可以对部署管理器进行移植——图形化用户界面(GUI)方式和命令行方式。本例中我们用 GUI 方式对部署管理器进行移植。

2. 在部署管理器的安装目录运行以下命令,启动图形界面移植向导:

/bin/wbi_migration.[bat | sh].

3. 根据图形界面移植向导的具体提示,选择要被移植的源概要文件,然后创建目标概要文件。

注意:在移植前不要提前手动的在 WPS 6.2 安装目录中创建概要文件,否则有可能会遇到异常错误。

4. 根据图形界面移植向导的具体提示,填写移植的备份目录。

5. 如果在移植前的环境中启动了管理安全设置,则需要在此步骤中输入设置的用户名和密码,如图 2。


图 2. Additional migration options 窗口
Additional migration options

6. 直至向导提示移植完成 --"The migration completed successfully"。

7. 检查日志文件里是否有错误信息。如果发现有异常信息,需要恢复一个干净的 WPS 6.2 环境,然后重新按照以上步骤再次进行移植工作。

以下是在移植完成后需要检查的日志文件:

a. WBIPreUpgrade.

b. WBIPostUpgrade..

c. WBIProfileUpgrade.ant. .

d. WBIMigration..log;此日志文件保存在移植备份目录中。

e. _create.log;此日志文件保存在 /logs/manageprofiles 目录中。

更新 CommonDB 的数据库模式

将部署管理器所在机器中的 /dbscripts/CommonDB/DB2/ 目录拷贝到数据库服务器,在数据库服务器上运行该目录下的命令 upgradeSchema.bat。根据命令窗口中的提示逐一输入要迁移的 WPS 版本、数据库名称以及数据库用户名等信息,如图 3。


图 3. 更新 CommonDB 数据库模式命令窗口
更新 CommonDB 数据库模式命令窗口

启动部署管理器(dmgr)

启动移植后的 WPS 6.2 部署管理器:在目录 /profiles//bin 下,运行 startManager.sh/startManager.bat 命令。

移植自定义节点

完成部署管理器的移植后,同样可以使用 GUI 和命令行两种方式对单元中其它的自定义节点进行移植。

注意:

①在移植自定义节点前,必须保证已移植的部署管理器处于启动状态;

②要逐一迁移同一单元中的自定义节点,不能同时升级多个节点;

③自定义节点移植完成后,不要立即启动节点和集群服务器,还有其它步骤需要完成;

④如果在自定义节点移植的日志文件中发现异常信息,需要恢复环境重新对部署管理器和所有自定义节点进行再次移植,而不是简单的只对移植失败的节点进行重新移植。因为在第一次的移植过程中,新建立的节点已经联合到了部署管理器概要中,不恢复整个环境而只对失败节点进行移植,会导致移植工作的再次失败。

自定义节点 GUI 方式移植的具体步骤与部署管理器的移植过程相似。本例采用 GUI 方式来移植单元中的第一个和第二个自定义节点。采用命令行的方式来对单元中的第三个自定义节点进行移植。需要执行两个命令(WBIPreUpgrade 和 WBIPostUpgrade),具体语法如下:

WBIPreUpgrade.sh backupDirectory 
 currentWebSphereDirectory
 [-profileName profile_name]
 [-username userID]
 [-password password]
 [-traceString trace_spec [-traceFile file_name ]]

WBIPostUpgrade.sh backupDirectory
 [-username userID]
 [-password password]
 [-oldProfile profile_name]
 [-profileName profile_name]
   [--createTargetProfile]
 [-scriptCompatibility true | false]
 [-portBlock port_starting_number]
 [-backupConfig true | false]
 [-replacePorts true | false]
 [-keepAppDirectory true | false]
 [-keepDmgrEnabled true | false]
 [-appInstallDirectory user_specified_directory]
 [-traceString trace_spec [-traceFile file_name]]

注意:运行 WBIPostUpgrade 命令时的参数“-createTargetProfile”是用来在 WPS 6.2 版本上创建新的概要文件,相当于图形化移植工具中建立的目标概要。这两个命令在自定义节点的 /bin 目录下。

更新集群

在迁移过的 WPS 6.2 部署管理器所在机器上,进入部署管理器概要的“bin”目录,依据操作系统平台,对单元中移植过的每一个集群执行以下命令:

Windows 环境:

\bin\ws_ant –f \util\WBIProfileUpgrade.ant –DmigrationDir= -Dcluster=

UNIX and Linux 环境:

/bin/ws_ant.sh –f < WPS6.2_HOME >/util/WBIProfileUpgrade.ant –DmigrationDir= -Dcluster=

注意: 指的是部署管理器的移植备份目录, 指的是 WBIProfileUpgrade 命令执行的目标集群名称。

更新业务流程编排器数据库模式

1. 在启动移植完成的自定义节点和集群之前,需要将脚本 \dbscripts\ProcessChoreographer\\upgradeTablespaces612.sql 和 upgradeSchema612.sql 拷贝到数据库服务器,手动的运行脚本从而实现对数据库(WPRCS612)模式的更新。如果在您的环境中为业务流程编排器(Business Process Choreographer )功能配置了专门的 BPEDB,则对 BPEDB 运行脚本进行模式更新。

2. 修改 upgradeTablespaces612.sql 脚本,用 DB2 数据表空间容器所在目录来替换脚本中的‘@location@’字符串(本文中替换为‘D:\DB2’)。 upgradeTablespaces612.sql 脚本只是针对 DB2 数据库,如果您应用的是其它类型的数据库,可忽略此步骤。

3. 登录管理控制台,检查业务流程编排器数据源的模式(schema),下图可以看到本文中业务流程编排器数据源的模式为‘WPRBE00’。


图 4. 数据源
数据源

4. 在 db2 命令行,连接数据库,将模式(schema)设置为‘WPRBE00’,然后执行 upgradeSchema612.sql。

注意:

①脚本名称末尾的数字表示被移植 WPS 环境的版本号,例如本例中是从 WPS6.1.2 移植到 WPS6.2,则需要运行的脚本名称末尾数字应该为“612”。如果找不到相应名称的脚本文件,就表示在进行移植的两个版本之间,数据库模式没有变化。

②如果为业务流程编排器配置了单独的数据库( BPEDB),就要对相应的业务流程编排器数据库执行以上更新模式脚本。

③如果数据库是在默认用户表空间中建立,则运行后缀为“nonp”的脚本 upgradeSchemanonp.sql ;否则运行脚本 upgradeSchema.sql 完成数据库模式更新。

5. 更新数据库模式后,还要选择一个应用程序集群成员所在的节点,在该节点上相对于本应用集群所用到的数据库手动运行脚本—— migrateDB.py(注意:如果单元中有多个应用程序集群,而且都已经完成移植,则需要针对每一个应用集群执行该脚本)。在 WPS 6.2 的移植过程中这一步骤是必须执行的。

用法:

wsadmin -conntype NONE -f migrateDB.py -dbUser -dbPassword

([-node ] -server ) | (-cluster )

[-dbUser ] -dbPassword [-dbSchema ]

注意:参数 -node,-server 和 -cluster 表示迁移完成的配置了业务流程编排器(Business Process Choreographer )的节点、应用服务器和集群名称;

参数 -dbUser 和 -dbPassword 指的是连接数据库所用的用户名和密码;

参数 -dbSchema 为该应用程序集群所用到的数据库模式名称。

移植后的其它工作

1. 在启动移植完成的自定义节点和集群之前,在数据库服务器上手动运行以下脚本更新 Business Space 所用到的数据库模式(注意:如果移植前的环境中未配置 Business Space,请忽略此步骤。):

/dbscripts/BusinessSpace/DB2/ upgradeSchema612_BusinessSpace.sql

/dbscripts/BusinessSpace/DB2/ upgradeData612_BusinessSpace.sql

2. 在 WPS6.2 以前的版本中,BPC Observer 是做为一个单独的应用。从 6.2 版本开始, BPC Observer 的功能可以在移植后集成到 BPC explorer。如果您想在移植后二者集成,需要在配置 BPC Explorer 的节点执行 migrate_BPCObserver__.jacl 脚本。

移植后环境的确认

1. 在启动移植后应用服务器前,检查各节点的移植日志:

a. WBIPreUpgrade.

b. WBIPostUpgrade..

c. WBIProfileUpgrade.ant. .

d. WBIMigration..log,此日志文件保存在移植备份目录中。

e. _create.log,此日志文件保存在 /logs/manageprofiles 目录。

2. 在启动移植后应用服务器后,检查如下功能是否正常工作:

a. 进入管理控制台,检查数据源连接是否正确

b. 确认所有的消息引擎处于正常启动状态。本例中需要检查以下总线的消息引擎:

BPC.suse40Cell612.Bus

CommonEventInfrastructure_Bus

SCA.APPLICATION.suse40Cell612.Bus

SCA.SYSTEM.suse40Cell612.Bus

c. 检查能否正常使用公共事件基础设施(CEI)

d. 检查能否正常使用错误事件处理器(Failed Event Manager )

e. 检查能否正常使用商业规则管理器(BRM)和 BPC Explorer

f. 检查能否正常使用 Business Space

g. 检查能否正常访问 BPC observer

h. 检查概要文件下的 SystemOut.log 日志文件是否有异常信息

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

请登录后发表评论 登录
全部评论

注册时间:2008-07-08

  • 博文量
    355
  • 访问量
    860180