从计划外部署管理器故障转移中更快速、更容易地恢复

引言

从本质上讲，WebSphere Application Server Network Deployment 是跨多台计算机的分布式系统。尽管计划外停机让人感到压力重重和灰心丧气，但是有一些方法可以减轻这种影响。本文的目的是向您介绍如何控制此系统，并使恢复成为一项快速而又简单的任务。

本文假设您非常了解 WebSphere Application Server Network Deployment 和网络配置的一些知识。

回页首

示例计算单元

考虑到本文的目的，我们假设一个计算单元有五个节点（图 1）。节点数虽然不重要，但是节点越多，在丢失部署管理器时影响就越大。

此计算单元分布在五个不同的系统中：

• 系统 1：节点 1（1 个节点代理/20 台应用服务器）
  主机：node1.samplecompany.com (10.10.0.1)

• 系统 2：节点 2（1 个节点代理/20 台应用服务器）
  主机：node2.samplecompany.com (10.10.0.2)

• 系统 3：节点 3（1 个节点代理/20 台应用服务器）
  主机：node3.samplecompany.com (10.10.0.3)

• 系统 4：节点 4（1 个节点代理/20 台应用服务器）
  主机：node4.samplecompany.com (10.10.0.4)

• 系统 5：部署管理器节点
  主机：dmgr.samplecompany.com (10.10.0.5)

在每个集群上，为全部 20 个应用程序安装了单个应用程序。如果这是生产计算单元，部署管理器所在的计算机已死机，并且完全不可恢复，那么快速地重新构建此计算单元会非常困难。最好的方法是尝试从某个备份还原部署管理器（假设进行了备份）。

部署管理器会为整个计算单元保存配置（主存储库）。如果您看一下部署管理器上的文件系统，就会看到定义的所有四个节点以及部署管理器节点。此配置构成整个计算单元。

                
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/dmgrNode/...
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/node1/...
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/node2/...
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/node3/...
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/node4/...

不过，应用服务器节点不需要整个计算单元配置；相反，它们仅需要本身所需的配置的子集。每个单独节点都有属于其本身节点的整个配置，并且只具有其他节点的 serverindex.xml。

                
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/node1/...
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/node2/
   serverindex.xml
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/node3/
   serverindex.xml
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/node4/
   serverindex.xml
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/dmgrNode/
   serverindex.xml

回页首

方法 1：设置备份节点

这里的计划是将应用服务器节点用作备份。通过将整个配置树从实际的部署管理器节点复制到另一个应用服务器节点，部署管理器可以在备份节点上快速重启。要开始该过程，首先需要一个应用服务器节点。在生产环境中，最好不要使用服务于应用程序的节点，而是选择一个专用作备份的新节点。

A. 创建备份节点

1. 我们首先在一个新系统（系统 6）上安装 WebSphere Application Server。当安装产品时，将该产品安装到文件系统上与部署管理器系统相同的位置。如果您将 WebSphere Application Server 安装在部署管理器系统上的 /WebSphere/AppServer 目录中，则请确保将其安装在同一位置的备份系统上。

2. 创建一个新的自定义概要或独立概要。我们将使用的节点名称是 backupNode。然后，将新的节点联合到现有计算单元。

                
/WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/backupNode/...

• 系统 6：备份节点
  主机：backup.samplecompany.com (10.10.0.6)

此节点的用途严格限于备份/故障转移，而不能用于承载任何应用服务器。当备份部署管理器运行时，它将在与部署管理器系统完全相同的位置创建其日志。即使概要管理工具没有创建 /WebSphere/AppServer/profiles/Dmgr01/logs，运行的服务器也会创建它。

B. 配置备份节点

目前，备份节点就像任何其他节点一样；它仅管理自已的配置和其他节点的小子集 (serverindex.xml)。要将此节点设置为备份，您需要自动复制部署管理器的计算单元范围的配置。为此，您需要使用管理控制台或使用简单的 jython 脚本在备份节点的节点代理上设置自定义属性。

使用管理控制台：

3. 可以在管理控制台上通过导航到 System Administration => Node Agents => nodeagent => File Synchronization Service => Custom Properties => New 设置自定义属性（图 2）。

   
   
   图 2. 使用管理控制台添加自定义属性
   
   
   

   要创建的新属性为：

   • 名称：recoveryNode
   • 值：true
   • 描述：（可选）

4. 设置此属性后，必须重新启动节点代理。下一次同步节点代理时，它将提取整个计算单元配置，而不只是提取自已的配置。每当对部署管理器进行配置更改并同步时，此备份节点也将下载新的更改，而不考虑更改实际指向的节点。

5. 您不需要在备份节点上创建任何应用服务器。只需让节点代理启动并运行，以保持配置最新即可。

或者，您也可以使用 jython 脚本来设置自定义属性。下面是一个简单的脚本，它说明了如何在备份节点的节点代理上设置自定义属性。（在运行之前，将脚本中出现的所有 <node> 更改为实际的节点名称。）

                
#Script to create the recoveryNode custom property

#Step 1: Get a handle to the nodeagent
nodeagent = AdminConfig.getid('/Node:<node>/Server:nodeagent/')
print nodeagent

#Step 2: Get a handle to the ConfigSynchronizationService
syncservice = AdminConfig.list('ConfigSynchronizationService', nodeagent)
print syncservice

#Step 3: Create the custom property
AdminConfig.create("Property", syncservice, [["name", "recoveryNode"],["value", "true"]])

#Step 4: Save
AdminConfig.save

C. 创建启动部署管理器的脚本

您已经在备份节点上自动复制了部署管理器配置，现在您需要一种方法来启动它。您不能使用标准的 StartServer.sh 脚本，因为该脚本假定是在本地节点上运行。StartServer [.sh | .bat]/ startManager [.sh | .bat] 的工作方式是读取本地节点的配置并在该节点上启动服务器。如果您尝试在备份节点上运行 startManager [.sh | .bat]，则该节点将不允许您启动部署管理器；部署管理器没有使用 backupNode 作为其节点名称，而是使用 dmgrNode。

由于您不能使用现有的 startManager 脚本，所以必须创建另一个脚本才能启动服务器：

6. 运行 ./startNode.[sh | .bat] -script。此命令将生成 start_nodeagent.sh（如果是 Windows 系统，则将生成 .bat）。然后，您必须对该脚本进行编辑，以将其指向部署管理器配置，而不是节点代理。

7. 将脚本重命名为 start_backup_dmgr.sh。

8. 更改文件的内容；在 exec 调用中，关键更改位于文件的结尾：
   
   清单 5. 修改 start_backup_dmgr.sh
   

   exec "/build/websphere/WASX/u0622.06.wasx/AppServer/java/bin/java" ... "/build/websphere/WASX/u0622.06.wasx/AppServer/profiles/AppSrv01/config" "productionCell" "backupNode" "nodeagent" ""

   
   

9. 将“backupNode”更改为 dmgrNode，将“nodeagent”更改为 dmgr 以读取：
   
   清单 6. 修改 start_backup_dmgr.sh
   

   exec "/build/websphere/WASX/u0622.06.wasx/AppServer/java/bin/java" ... "/build/websphere/WASX/u0622.06.wasx/AppServer/profiles/AppSrv01/config" "productionCell" "dmgrNode" "dmgr" ""

   
   

新的 start_backup_dmgr.sh 的输出与预期的 startManager [.sh | .bat] 的输出差别很大。备份部署管理器应仅用于操作控制，因为对系统进行的任何更改都不能反映初始的部署管理器。

回页首

方法 2：共享的文件系统

第二个选择是使用在主要部署管理器系统和备份系统之间共享的文件系统。您可以设置另一个系统，使其共享部署管理器概要本身，并在该系统上启动部署管理器。如果检查一下安装的 V6.0.X 或 V6.1，可以发现属于部署管理器（或该部署管理器的任何概要）的所有数据都存储在 WAS_HOME/profiles/<profile> 目录下。

请考虑一下前面的示例，其中部署管理器安装到系统 5 上的 HFS: /WebSphere/AppServer/profiles/Dmgr01/config/cells/productionCell/nodes/dmgrNode/... 下。

而且，您还需要将 WebSphere Application Server 安装到系统 6 上。不过，这次您无需创建任何概要，您可以改为共享部署管理器的概要目录。通过将共享目录装入系统 6 上完全相同的位置，您实际上已复制了系统。概要的副本允许在其他系统上共享同一部署管理器。共享此目录后，您可以从备份系统运行 startManager [.sh | .bat]。

此方法的缺点是您必须维护共享的文件系统。在主系统和备份系统上使用共享的文件系统时，还可能有很大的性能开销。此系统的一个主要优点是，在使用备份系统时，对部署管理器的主存储库所做的任何更改都会被提交。重新构建主要部署管理器计算机后，在重新安装文件系统时，更改不会丢失。

回页首

为多主主机配置 DNS

找到在远程系统上启动部署管理器的方法后，您可能仍有一些问题需要解决。在最初配置该部署管理器时，便给出了解析为特定 IP 的特定主机。在我们的示例中，主机名 dmgr.samplecompany.com，被解析为 10.0.0.5。要让部署管理器位于备份系统 (10.0.0.6) 上，我们需要设置所谓的多主 DNS 项。在我们的示例中，我们在多台计算机上使用多个接口，每台计算机的每个接口都有一个 IP 地址。下面是 DNS 项的示例：

                
ADMIN:SYSTEM6:/u/ADMIN>nslookup dmgr.samplecompany.com
Defaulting to nslookup version 4
Starting nslookup version 4
Server:  dnsserver.samplecompany.com
Address:  10.0.0.100

Name:    dmgr.samplecompany.com
Addresses:  10.0.0.5, 10.0.0.6

通过为两个主机配置 DNS 项，可以容易地在它们之间进行转换，因为不需要进行任何重新配置。在任何给定的时间内，只要任一主机上只有一个系统在运行，就会仅使用一个部署管理器。节点代理和客户机将自动尝试第一个（主要）地址，然后进行故障转移，尝试第二个（备份）地址。按此方式设置了计算单元后，必须重新启动部署管理器和所有节点代理才能重新读取配置。在缺省情况下，JVM 缓存 DNS 项，并且需要重新启动才能对其刷新。

回页首

结束语

本文介绍了使用 WebSphere Application Server Network Deployment V6.x 中的功能构建容错性较强的部署管理器的一种方法，并描述了如何使用 WebSphere Application Server 配置选项或共享文件系统将整个计算单元范围的配置自动复制到备份系统。此备份系统然后使用预配置的 DNS 项来启动，并替换有故障的部署管理器。部署管理器丢失对生产计算单元是一个巨大的打击，所以此服务器务必保持运行并发挥功能，从而确保拓扑具有较高的可用性。