一个WAS应用上如何部署多个应用（记录待验证）

72 阅读 0 评论 48 点赞

我是靠谱客的博主含糊酒窝，最近开发中收集的这篇文章主要介绍一个WAS应用上如何部署多个应用（记录待验证），觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

WebSphere Network Deployment 迁移概述
可使用迁移向导或迁移命令执行 WebSphere 迁移。尽管迁移向导提供了一个将配置文件迁移到默认位置的标准方法，但迁移命令可用于将配置文件迁移到安装树以外的位置。

图 1. 迁移向导

在集群生产环境中，系统管理员将使用迁移命令（即 WASPreUpgrade 和 WASPostUpgrade）作为在自动脚本中迁移应用程序和配置的首选方式。这些工具从 WebSphere Application Server Network Deployment V6 复制现有的配置，包括旧的默认值和端口、JVM 参数等设置，并将它们合并到新的 WebSphere Application Server Network Deployment V7 配置中。

WASPreUpgrade 命令创建一个 WebSphere Application Server V6 配置信息的备份，然后，WASPostUpgrade 命令提取由 WASPreUpgrade 创建的备份，将以前的配置移动到 WebSphere Application Server V7 中。WASPostUpgrade 工具在进行任何更改之前还会创建一个 WebSphere Application Server V7 环境的备份，因为如果发生错误，它会尝试回滚这些变更。

图 2. 使用 WASPreUpgrade 和 WASPostUpgrade 命令的迁移过程

迁移过程同步被迁移的节点与部署管理器中的数据，在此过程中，新的配置文件的配置内容被上传到部署管理器，一次上传一个文件。

在迁移过程中，相同的端口值默认情况下会从 V6.0 Deployment Manager 映射到 V7.0 Deployment Manager，包括 SOAP 连接器。在这个过程中，WASPostUpgrade 通过使用 -replacePorts 参数可以纠正可能发生的任何端口冲突。

大型 WebSphere 网络部署拓扑
WebSphere 网络部署拓扑包括部署管理器以及一个或多个节点，应用程序服务器驻留在节点上，以运行应用程序。大型部署拓扑通常包含数百个应用服务器或多个节点。举一个例子，节点和服务器均衡搭配的大型网络部署拓扑可能有 30 个节点，每个节点有 20 个服务器，或者其中的节点更多、服务器更少，可能有 60 个节点，每个节点有 20 个服务器，均由一个部署管理器进行管理。再举一个例子，包含部署管理在内的稍大型部署拓扑可能是，其中有 25 个节点，每个节点至少有一个应用程序服务器。然而出于本练习的目的，在随后的段落中将介绍一个在集群环境中相对较小但复杂的拓扑。

本迁移练习的复杂拓扑
按照以下步骤，针对本次生产中的迁移练习建立一个复杂的拓扑：

在集群环境中，一个部署管理器管理 8 个 AIX 服务器节点，每个节点管理 2 个 WebSphere Application Server 实例。换句话说，集群中将有 1 个部署管理器，8 个节点代理和 16 个 WebSphere Application Server 实例。部署管理器服务器和应用程序服务器都是虚拟服务器。还有一个接受管理的 WebSphere Application Server 与部署管理器驻留在同一个 AIX 服务器上。带有 Message Driven Beans (MDB) 的 J2EE 应用程序被部署在独立的应用服务器 - WAS(MDB)。图 3. 本迁移练习的复杂 WebSphere 部署拓扑

复杂拓扑的运营管理
从部署管理器（如 DMGR1）到单个应用程序服务器的管理请求通过部署管理器流到与服务器所驻留的同一节点上的节点代理，最后到应用服务器本身。部署管理器只和节点代理通信，每一个节点代理与其各自的应用服务器进行通信，如 WAS1 或 WAS(MDB)。

环境
WebSphere Application Server Network Deployment V6.0.2 （现有的）。WebSphere Application Server Network Deployment V7.0.0.13 （新的）。AIX 6.1IBM CICS® 3.2LDAPIBM DB2®WebSphere MQ V6在 WebSphere Application Server V6 中关闭了 Global security （全局安全性）。WebSphere Application Server V7.0 的 Deployment Manager 上的安全性在迁移时被禁用。迁移计划
在 WebSphere Application Server Network Deployment V7 上创建配置文件：
Deployment Manager 配置文件 – 一个部署管理器，管理在其单元中联合的应用程序服务器。 Application Server 配置文件：
在集群环境中的 Application Servers 联合到一个单元中。 Application Server，独立于集群的应用程序服务器，由部署管理器管理。将部署管理器从 WebSphere Application Server Network Deployment V6 迁移到 V7。将集群应用程序服务器的节点从 WebSphere V6 迁移到新的 V7，并将它与新的 WebSphere Application Server Network Deployment V7 部署管理器联合。迁移独立的应用程序服务器与 MDB J2EE 应用程序。网络部署迁移前的考虑因素
除了 WebSphere Application Server V6 的二进制文件和配置文件之外，需要分配足够的文件系统空间来满足 WebSphere Application Server V7 的二进制文件和配置文件。需要设置权限允许在 WebSphere 和 Update Installer 的二进制文件系统上进行读、写或创建。需要安装 WebSphere Application Server Network Deployment V7 产品，并按拓扑创建配置文件（部署管理器和应用程序服务器）。部署管理器 WebSphere V7 需要正常运行，因为联合节点迁移需要一个连接到部署管理器的活动连接。在 WebSphere V7 应用程序服务器上的任何迁移尝试中止，都需要通过还原配置文件的备份，或重新创建配置文件来清理配置文件，然后再进行下一次迁移尝试。请参阅 “如何清理失败的迁移” 一节。迁移步骤
迁移所需的实用工具和命令可以在 WebSphere V7 bin 目录中找到，如 '/usr/Websphere/AppServer/v7.0_app1/bin'。在使用 WASPreUpgrade 和 WASPostUpgrade 命令时，可能会在命令行语法中指定 -traceString 参数，以跟踪代码。本练习所执行的迁移命令及参数是：

清单 1. WASPreUpgrade 命令
/usr/WebSphere/AppServer/v7.0_MNQ/bin >> ./WASPreUpgrade.sh
/waslogs/was6_to_was7/migration/migration_ABCD_MNQ_app01_026
/usr/Websphere/AppServer/v6.0_MNQ
-oldProfile ABCD_MNQ_app01
-traceString "*=all=enabled"
-traceFile /waslogs/was6_to_was7/trace/WASPreUpgrade_trace.log升级前的步骤可能成功完成，也可能因某些问题而失败（在随后的段落中将单独介绍）。

清单 2. manageprofiles 命令
/usr/WebSphere/AppServer/v7.0_MNQ/bin >> ./manageprofiles.sh
-create -profileName ABCD_MNQ_temp
-profilePath /var/opt/websphere/profiles/ABCD_MNQ _temp
-cellName ABCD_MNQ_cell01
-portsFile /tmp/ports_file.txt -hostName 026 -nodeName ABCD_MNQ_app01_026manageprofiles 命令将创建一个配置文件。

清单 3. WASPostUpgrade 命令
/usr/WebSphere/AppServer/v7.0_MNQ/bin >> ./WASPostUpgrade.sh
/waslogs/was6_to_was7/migration/migration_ ABCD_MNQ_app01_026
-oldProfile ABCD_MNQ_app01
-profileName ABCD_MNQ_temp
-traceString "*=all=enabled"
-traceFile /waslogs/was6_to_was7/trace/WASPostUpgrade_trace.log升级后的步骤可能成功完成，也可能因某些问题而失败（在随后的段落中将单独介绍）。

问题及其解决方法
问题：使用 MIGR0484E/MIGR0272E 迁移应用程序服务器时，WASPreUpgrade 迁移命令失败。

清单 4. 使用 MIGR0484E/MIGR0272E 迁移失败
IBM WebSphere Application Server, Release 7.0
Product Upgrade PreUpgrade tool, Version 1.0
Copyright IBM Corp., 1997-2008
MIGR0300I: The migration function is starting to save the existing
Application Server environment.
MIGR0302I: The existing files are being saved.
MIGR0484E: No profiles or instances found with name ABCD_MNQ_app01.
MIGR0001I: The class name of the WASPreUpgrade command is WASPreUpgrade
MIGR0272E: The migration function cannot complete the command.在迁移失败之前执行的步骤是：

WebSphere Application Server V7 Deployment Manager 启动正常运行，并且 WebSphere Application Server V6 节点代理和应用程序服务器已停止。Deployment Manager 已成功从 WebSphere Application Server V6 迁移到 V7。解决方法：为了对该失败进行疑难解答，请通过 ps-ef|grep java 命令的帮助，确保 WebSphere Application Server V6 的 wasprofile 命令没有运行。还需要确保配置文件注册表中引用了 ABCD_MNQ_app01 配置文件，可以在文件 profileRegistry.xml 中检查这一点，该文件位于 '/usr/WebSphere/AppServer/v6.0_MNQ/properties'。

清单 5. ProfileRegistry.xml 文件
profile isDefault="true" name="ABCD_MNQ_app01"
path="/var/opt/websphere/profiles/ABCD_MNQ_app01"
template="/usr/Websphere/AppServer/v6.0_MNQ/profileTemplates/managed"另外，请确认不存在 'profileRegistry.xml_LOCK 文件。

确认所有上述条件后，请注意，ABCD_MNQ_app01 配置文件未在 fsdb 目录中引用，并且由于这个原因造成迁移失败。需要将下面的脚本复制到目录 WAS_HOME Directory /properties/fsdb 中。

清单 6. 复制到 fsdb 目录的脚本
#!/bin/sh
WAS_USER_SCRIPT=/var/opt/websphere/profiles/ABCD_MNQ_app01/bin/setupCmdLine.sh
export WAS_USER_SCRIPT执行该步骤之后，迁移命令成功运行。

问题：使用 MIGR0286E 时，WASPostUpgrade 迁移命令失败，原因是 Illegal State Exception。

清单 7. 使用 MIGR0286E 时迁移失败，原因是 java.lang.IllegalStateException
DSRA7602I: Attempting to delete newly created Derby database
/var/opt/websphere/profiles/ABCD_MNQ_app701/databases/ABCD_MNQ_app01_027.
ABCD_MNQ_app01_027_s01-ImmediateBatchBus_027_s01_122132600_

CLOUDSCAPE_MIGRATION_DELETION_DONE
java.lang.IllegalStateException: java.lang.IllegalStateException:
Depth value 3 must be set
at com.ibm.ws.runtime.component.VariableMapImpl.reload(VariableMapImpl.java:238)
at com.ibm.ws.runtime.component.VariableMapImpl.refresh(VariableMapImpl.java:152)...
at com.ibm.ws.migration.postupgrade.WASPostUpgrade.restore(WASPostUpgrade.java:246)
at com.ibm.ws.migration.postupgrade.WASPostUpgrade.main(WASPostUpgrade.java:539)

Caused by: com.ibm.websphere.management.exception.RepositoryException:
com.ibm.websphere.management.filetransfer.client.TransferFailedException:
Error occurred during upload to: upload/cells/ABCD_MNQ _cell01/nodegroups/
DefaultNodeGroup/nodegroup.xml.
Exception: java.io.IOException: Read error

Caused by: java.io.IOException: Read error
at java.io.FileInputStream.read(FileInputStream.java:191)
at com.ibm.ws.management.repository.TempFileInputStream.read
(TempFileInputStream.java:91)
at com.ibm.websphere.management.repository.RepositoryInputStream.read
(RepositoryInputStream.java:120)...
at com.ibm.ws.management.filetransfer.client.FileTransferClientImpl.uploadFile
(FileTransferClientImpl.java:302)
.. 30 more

MIGR0286E: The migration failed to complete.解决方法：迁移中同步进程失败了，因为系统用户在 AIX 环境中缺少文件句柄。将 AIX nofiles 限制设置（即，ulimit-n）从默认的 2000 增加到 10000，从而解决这个问题。

问题：将集群应用服务器从 WebSphere Application Server ND V6 迁移到 V7 时，部署管理器似乎在寻找其他应用程序服务器配置，但它无法找到，并发生了迁移失败。

解决方法：在本练习特定的这个复杂拓扑中，独立的应用程序服务器与部署管理器 (DMGR1) 位于相同的 AIX 服务器上，该应用程序服务器的迁移需要在集群应用服务器的迁移之后进行。决定以这个特定的顺序执行迁移，从而解决了这个迁移问题。

问题：因明显的 “网络连接复位” 或 “网络读错误” 造成迁移失败。在迁移过程中的文件上传期间，网络连接被复位，这导致文件上传失败。同步进程向迁移工具报告了失败，迁移工具中止迁移操作。在其他时间，同步进程报告网络读错误，从而导致迁移操作中止。这是在处理与第一次尝试所不同的文件时发生。看来，节点和部署管理器之间的网络连接在迁移发生时被中断。

解决方法：初看起来，这似乎是一个网络问题，因为部署管理器切断了连接，迁移节点只能感知其连接莫名其妙地被中止。不需要考虑网络问题，因为部署管理器服务器和故障的应用服务器都是在虚拟机管理程序中的虚拟服务器。事实上，迁移工具的传入数据使部署管理器的连接达到饱和，并且部署管理器达到了对在该通道允许的开放连接数所设置的上限。我们注意到，在部署管理器的 SystemOut 日志中，TCP Channel 'TCP_1' 已经超过了配置的最大开放连接数量 100。

下图说明了这个设置：

图 4. WC_adminhost 端口上的 TCP 通道的最大开放连接数

图 5. WC_adminhost_secure 端口上的 TCP 通道的最大开放连接数

这个问题解决方法是，在迁移练习中将 WC_adminhost 和 WC_adminhost_secure 端口的 TCP 通道的最大开放连接数从 100 提高到 20000。

问题：作为迁移验证的一部分，应用程序服务器在启动时就出现了问题，'ibmasyncrsp' 进程无法启动。

清单 8. 系统应用程序 'ibmasyncrsp' 无法启动
00000021 ApplicationMg A WSVR0200I: Starting application: ibmasyncrsp
00000021 ApplicationMg A WSVR0203I:
Application: ibmasyncrsp Application build level: 1 [2]
00000020 ApplicationMg A WSVR0200I: Starting application: MNQ_v3.30_HF11
ApplicationMg A WSVR0204I: Application: MNQ_v3.30_HF11
Application build level: Unknown
00000021 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I:
FFDC Incident emitted
00000021 DeployedAppli W WSVR0206E: Module, ibmasyncrsp.war, of application,
ibmasyncrsp.ear/deployments/ibmasyncrsp, failed to start
00000021 ApplicationMg W WSVR0101W: An error occurred starting, ibmasyncrsp
00000021 ApplicationMg A WSVR0217I: Stopping application: ibmasyncrsp
00000021 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I:
FFDC Incident emitted解决方法：在本练习中，在开始迁移之前，已经通过 Admin Console 将“default_host” 的定义从 'default_host' 修改为 'MNQ_default_host'，并且已为应用程序更新了 Virtual Host 映射。但是，在迁移之后，系统应用程序似乎仍引用 'default_host' 而不是 'MNQ_default_host'，并且 Application Server 启动跟踪显示 “open for e-business, problems occurred during startup”。

经确定，系统安装了应用程序 ibmasyncrsp.ear，它用于接收 SIBus 中的异步消息，Web 服务运行时已被映射到默认主机 'default_host'，而不是所需的 'MNQ_default_host' 虚拟主机。

清单 9. 已安装了应用程序 'ibmasyncrsp.ear' 的系统的映射
profile_root>/config/cells/ELN1_mwp_cell01/applications/ibmasyncrsp.ear
/deployments/ibmasyncrsp/ibmasyncrsp.war/WEB-INF/ibm-web-bnd.xmi

com.ibm.ejs.models.base.bindings.webappbnd:WebAppBinding
xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:com.ibm.ejs.models.base.bindings.webappbnd="webappbnd.xmi"
xmi:id="WebAppBinding_1155152745161" virtualHostName="default_host"因为无法从 Admin Console 访问 WebSphere 应用程序 ('ibmasyncrsp.ear')，所以更新文件 ibm-web-bnd.xml，指向选定的虚拟主机 'MNQ_default_host'。

通过这一修改，这个问题得到了解决，并且应用服务器的启动过程没有再出现任何问题。

问题：迁移后，如果没有启用 FIPS（美国联邦信息处理标准算法），在 WebSphere Application Server V6 中所使用的 TLS （传输层安全性）密码将不能在 WebSphere Application Server V7 中使用，启用 FIPS 可以重新建立 MDB 应用程序服务器和WebSphere MQ V6 之间的连接。

解决方法：需要识别 WebSphere Application Server V7 和 WebSphere MQ V6 中都能使用的密码，并且不需要启用 FIPS。在 WebSphere MQ V6 中提供的 SSL（安全套接字层）CipherSpecs 使用的名称与 WebSphere Application Server V7 中的密码不同，从而对兼容的密码进行比较。在 “SSL configurations” 中的 “Quality of protection (QoP) settings”，需要 WebSphere Application Server V7 配置更改。还需要修改通道上的 WebSphere MQ V6 SSL 配置，以使用新的密码。

如何清理失败的迁移？
任何中止的迁移将使 WebSphere 应用程序服务器配置文件停留在部分迁移的状态，这对于数据采集和疑难解答是有用的。将执行以下操作来清理失败的迁移：

WebSphere Application Server V7
我们必须通过 'manageprofiles' 命令的帮助，删除在中止的迁移中所创建的新配置文件（例如，部署管理器和应用程序服务器配置文件）。

清单 10. 删除配置文件的命令 'manageprofiles'
/install_root/v7.0/bin/>>
./manageprofiles.sh -delete -profileName NewProfileNameForVersion7配置文件被删除后，该配置文件的任何剩余目录都需要被手动删除。

清单 11. 检查要删除的配置文件子目录
/install_root/profiles/NewProfileNameForVersion7/>> ls -la现有的配置文件目录也需要被删除。只应保留日志子目录。

清单 12. 删除配置文件目录
/install_root /profiles/NewProfileNameForVersion7>>cd ..
/install_root /profiles/>> rm -r NewProfileNameForVersion7WebSphere Application Server V6
我们必须删除用 WASPreUpdgrade 命令创建的备份目录（如 /waslogs/was6_to_was7/migration）。另外，当再次运行迁移命令时，我们也可以指定另一个备份目录（如 /waslogs/was6_to_was7/migration1）。

迁移后的步骤和验证
停止和启动 WebSphere V7 的部署管理器。启动 Admin Console，然后单击 System administration > 节点，验证新节点已经联合到 WebSphere V7。从 WebSphere Application Server V7 配置文件中删除旧的 JVM 设置 - 1.6 JVM 中不需要从 JVM1.4.2 带来的 JVM 参数，应予删除。例如：
-Xloratio0.2-Xp32K,4K-Xminf0.25-Xpartialcompactgc-Xk64000将 WC_adminhost 和 WC_adminhost_secure 端口上的 TCP 通道的最大开放连接数恢复为 100。监测在 1.6 JVM 中引入的压缩引用所带来的任何性能影响。这可以通过删除 "-Xcompressedrefs" JVM 命令行参数进行监测。验证 WebSphere Application Server V7 Deployment Manager 的安全性已被改为 “on”，并且该拓扑的服务集成总线安全性已被禁用。验证 WebSphere Application Server V7 上的 SSL 配置。验证应用程序服务器启动，并且已部署的应用程序正常运行。结束语

本文涵盖在集群环境中发现的一些 WebSphere 迁移问题，以及在 AIX 平台上克服这些迁移问题所采取的步骤。这对于执行类似迁移路径的人来说可能很有帮助。

原文链接

https://zhidao.baidu.com/question/1731710042306940827.html