原文：https://www.ibm.com/developerworks/cn/websphere/techjournal/0905_webcon/0905_webcon.html

修改主机名

让我们首先从修改部署管理器机器上的主机名开始。初始配置如图 1 所示，其中部署管理器节点 SONOMACellManager01 位于主机 SONOMA.xd61stew.ibm.com 中。

图 1. 初始配置

停止部署管理器后，在作出任何改变之前，使用 WebSphere Application Server 备份工具 backupConfig.(sh/bat) 对您的配置进行备份始终是个好主意，如清单 1 所示。并不是说您希望出现任何错误，但是在出现问题时能够恢复到起点总是不错的。

清单 1

现在应当启动 wsadmin，但是不要连接到 WebSphere 进程。这可以通过指定 -conntype NONE 完成，如清单 2 所示。

清单 2

如果这是您第一次使用 Jython 运行 wsadmin，而不是使用默认的 Jacl，那么当第一次处理 Jython JAR 文件时，将看到大量类似于下面的信息：

*sys-package-mgr*: processing new jar,
'/opt/IBM/WebSphere/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime/batch.jar'

准备好 wsadmin 之后，对 AdminTask 对象调用 changeHostName 实用命令。清单 3 所示的 AdminTask 输出显示了交互模式，它提示您进行输入并根据您的输入构建 wsadmin 命令。

在本例中，主机名由 “SONOMA.xd61stew.ibm.com” 修改为 “NAPA.xd61stew.ibm.com”（图 1）。nodeName 参数告诉 wsadmin 哪个特定节点被修改；在本例中，这个节点是托管部署管理器的节点，而主机名参数则指定新的主机名。可以看到，我们还选择重新生成 SSL 证书作为修改的一部分。您还将注意到 AdminTask 根据您的输入显示它生成的命令，这使您能够将未来要使用的命令拷贝到一个文件中。一旦 AdminTask 生成的命令得到执行后，修改将被保存并且您将退出 wsadmin。

清单 3

重新启动部署管理器后，可以看到修改被反映到管理控制台中，如图 2 所示，其中部署管理器节点的主机名现在变为 “NAPA.xd61stew.ibm.com”。顺便提一下，如果您在输入主机名时出现错误，那么很可能无法启动部署管理器，并且将需要查看日志。表示新主机名拼写错误的消息为：

<your new host name> and the exception is java.net.UnknownHostException:

另一个相关的错误消息为：

Host name <your new host name> is not registered in DNS.

如果是这样的话，只需重新运行 AdminTask.changeHostName 并正确地输入新的主机名，然后像往常一样保存并退出。

图 2. 修改主机名后的配置

这时应该逐一停止所有节点代理并使用新的部署管理器主机名运行 syncNode，如清单 4 所示，然后在 syncNode 完成后启动节点代理。

清单 4

将概要文件迁移到一个新主机

当然，并不是所有情况都像在服务器上保持 WebSphere Application Server 等中间件并仅需要修改主机名这么简单。更常见的情况是，您需要将运行时从一台机器迁移到另一台机器，修改主机名只是迁移过程中的一个步骤。假设您并不仅仅是将现有服务器的主机名从 “SONOMA” 修改为 “NAPA”，您实际上希望将部署管理器（或任何其他 WebSphere Application Server 进程）移动到另一台机器，并修改 WebSphere Application Server 配置来反映新服务器上的主机名。如果结合使用 manageprofiles 命令和 AdminTask.changeHostName，那么您就可以实现上述目的。

要开始此过程，首先停止服务器上运行的所有进程，然后使用 backupProfile 选项运行 manageprofiles 命令，同时指定将要备份的文件和所需的文件名，如清单 5 所示。

清单 5

当备份完成后，使用您喜欢的文件拷贝工具将备份文件从旧服务器上转移到新服务器上。新服务器需要安装 WebSphere Application Server，但是不需要创建任何概要文件，但是有一个预配置项可以使您的转移更加顺利：目标系统上的目录结构应当匹配源系统上的目录结构。虽然 WebSphere Application Server V7 似乎消除了大部分（但不是全部）指向 WAS_HOME 目录位置的硬编码目录路径，但是目前为止 Version 6.1 中还有超过 200 个路径。因此，如果您没有在机器之间维护目录结构的一致性，您将需要手动修改目录结构，以及对目录路径 in setupCmdLine.sh(bat) 和 variables.xml 的引用。当然，我不会对这 200 多个实例以及修改方式进行归档。相反，我仅仅是建议您将 WebSphere Application Server 安装到源机器和目标机器上的相同位置。这样的话，只需要使用 restoreProfile 选项运行 manageprofiles，如清单 6 所示。

清单 6

现在，只需调用 wsadmin AdminTask.changeHostName 命令，如前所示，保存您的修改并退出。部署管理器（或其他 WebSphere Application Server 进程）现在已经准备好在新的服务器上启动。WebSphere Application Server 概要文件以外的任何配置内容（比如在非默认位置展开的应用程序、共享库 JAR、JDBC 提供者使用的数据库驱动器、独立的连接器模块，等等）都必须手动拷贝。此外，如果是在使用 Sun™ Solaris™ 或 HP JDK 的机器和运行 IBM JDK 的机器之间迁移（反之亦然），那么也必须手动修改 JVM 设置中的任何 Sun、HP 或 IBM JDK 特定的 -X 标志。

在结束本节之前，需要注意上述过程也可以用于将您的 WebSphere Application Server 配置从 32 位安装迁移到 64 位安装，反之亦然。您可能会问，为什么要从 64 位迁移到 32 位？这是因为，在完成测试后，您可能会发现 64 位的性能不如您预期的那样好，这可能有多个原因。

另一个选项

AdminTask.changeHostName 命令的另一个选择是使用基于属性文件的配置实用工具，该工具是 WebSphere Application Server V7 附带的一部分。在本例中，仍然使用 wsadmin 来提取配置，然后验证并应用变更。

如前所述，在不使用连接的情况下启动 wsadmin（-conntype NONE）并且将被修改的进程会停止。这一次，AdminTask extractConfigProperties 实用工具按以下方式调用：

清单 7

在本例中，创建了一个属性文件 SONOMA.cell.props，您可以使用任何文本编辑器进行编辑。只需要找到 “from” 主机名，在本例中为 “SONOMA.xd61stew.ibm.com”（清单 8），将其修改为新主机名，保存文件并退出。

清单 8

编辑完文件后，在退出 wasdmin 前需要运行另外三个 wsadmin 命令（清单 9）：

• AdminTask.validateConfigProperties 将验证所做的修改。
• AdminTask.applyConfigProperties 将所做的修改应用到库。
• AdminConfig.save 将保存修改。

清单 9

如前所述，启动部署管理器并运行 syncNode，在停止每个节点代理后确保修改被全部传播，然后重启节点代理。

真正执行修改

如果您仍然在运行 WebSphere Application Server V5.x —— 即使它不再受到支持 —— 并且您需要对 Version 5.x 环境做出修改，那么您可以使用一些工具，但是这些工具不同于 V6.x 和 V7.0 中使用的工具。要在 WebSphere Application Server V5.x 中修改现有系统的主机名，可以使用与 在 V7.0 中修改主机名 相同的过程；由于这个过程提供了 wsadmin Jython 语法而 V5.x wsadmin 使用的是 Jacl，我在清单 10 中提供了修改后的 Jacl 语法。

清单 10

除了像上面那样修改主机名外，WebSphere Application Server V7.0 Information Center 中还提供了一组 wsadmin 样例脚本，应该能够用于这个目的。