IBM WAS ND 分布式网络环境的理解与集群的实现

核心提示：如今的电子商务及电子政务应用系统的发展已经到了一个新的阶段，应用系统的成熟度和可用性都达到了更高的水准，IBM WAS ND 分布式网络环境的理解与集群的实现，因此庞大的部署规模和海量的用户访问成为目前大型电子商务及电子政务应用系统的显著特征，在这样的情况下，只有理解这些定义和架构，才可以在实际工程的集成与部署工作中拿

如今的电子商务及电子政务应用系统的发展已经到了一个新的阶段，应用系统的成熟度和可用性都达到了更高的水准。因此庞大的部署规模和海量的用户访问成为目前大型电子商务及电子政务应用系统的显著特征。在这样的情况下，企业对系统关键业务：如金融信息，通信，交通等要求确保系统24*7*365不停歇运行业务的分布式部署结构和负载抗压能力，以及高可用性都提出了更高的要求。IBM WAS ND产品可以帮助我们在多应用服务器分布式部署环境下实现集群，确保系统的负载能力和高可用性。

下面按照逻辑概念的层次关系，由大到小依次了解IBM WAS ND产品定义的分布式网络环境中的相关概念。

单元（Cell）

单元是整个分布式网络中一个或多个节点的逻辑分组。单元是一个配置概念，是管理员将节点间逻辑关联起来的实现方法。管理员根据具体的业务环境，制定对其整体系统集成环境有意义的条件来定义和组织构成单元的节点。如图1所示，就一般情况来说，可以将单元看作是最大的作用域。

在IBM WAS ND产品中，管理配置数据都存储在 XML 文件中。单元保留了它每个节点中每台服务器的主配置文件。同时每个节点和服务器也有其自己的本地配置文件。如果服务器已经属于单元，则对于本地节点或服务器配置文件的更改都是临时的，通过在本地提交更改生效时，本地更改覆盖单元配置，但是当执行单元配置文档同步到节点的操作时，在单元级别上对主控服务器和主节点配置文件所作的更改将会替换对该节点所作的任何临时更改。

同步操作在指定的事件发生时进行，例如服务器启动时等很多操作。也就是说，通过对本地节点或服务器配置文件进行修改而达到调整节点或服务器配置的做法不是安全的，临时修改很容易被同步操作所覆盖。

图 1. 单元的作用域

Deployment Manager

Deployment Manager 是管理代理程序，它提供集中式管理单元中所有节点的可视化人机交互管理视图。之前提到单元是一个逻辑上的配置概念，那么Deployment Manager 就为单元中所有元素提供了单一的管理控制中心点。每个单元都会包含一个 Deployment Manager，由Deployment Manager提供管理功能来修改单元的主配置文件。在最新的v6.x版本中还提供集群管理以及在一个或多个节点作用域内进行应用程序服务器工作负载平衡。

图 2. 由Deployment Manager提供管理功能来修改单元的主配置文件

节点（Node）

节点是受管服务器（Server）的逻辑分组。节点通常与具有唯一 IP主机地址的逻辑或物理计算机系统对应，节点不能跨多台计算机。节点分为受管节点与非受管节点。

IBM WAS ND 拓扑中的节点可能是受管的，也可能是非受管的。受管节点有相应的 Node Agent 进程来管理它的配置和服务器。非受管节点没有 Node Agent。Node Agent 表示管理单元中的节点并负责保持配置始终处于最新状态。非受管节点对于单元来说是未知的，所以 Deployment Manager 无法对其进行管理。

分布式网络环境中的非受管节点可以有服务器定义（例如 Web 服务器），但不能有应用程序服务器定义，并且非受管节点无法添加 Node Agent，因此它不能成为受管节点。另外一种情况在独立应用程序服务器环境中，节点尚且没有 Node Agent，它们也可以暂时被视为非受管节点，但是这类节点可以通过联合独立应用程序服务器而变为单元中的受管节点。通过调整独立应用程序服务器概要文件，将单独的Server节点添加到单元，这个过程称为联合。在联合独立应用程序服务器时，节点将自动创建 Node Agent，该节点就可以被Deployment Manager 管理。

图 3. IBM WAS ND 拓扑中的受管节点与非受管节点

Node Agent

Node Agent 是将管理请求路由至服务器的管理代理程序。Node Agent 是服务器，是一个管理代理程序，并不涉及应用程序服务功能。Node Agent 进程在每个受管节点上运行，并专门执行特定于节点的管理功能，如服务器进程监视、配置同步、文件传输和请求路由。Deployment Manager通过与Node Agent的交互完成对单元内节点的控制。

图 4. Node Agent

WAS Plug-in

在前面的章节我们讨论过受管节点是通过Node Agent进程与Deployment Manager交互。而非受管节点，最常见的是web服务器节点（如IBM HTTP Server），则是通过Web 服务器插件方式来接受Deployment Manager管理，加入到单元当中来的。IBM WAS ND产品支持所有符合规范的Web 服务器的基本管理功能，可以为所有支持的 Web 服务器生成插件配置。插件生成之后，对于非受管节点，可以通过“传播给远程 Web 服务器”完成插件配置；如果定义在受管节点上，则直接通过节点间同步即可完成插件配置的传播。

Web 服务器插件允许 Web 服务器将动态内容的请求发送到应用程序服务器。Web 服务器插件与每个 Web 服务器定义关联。为每个插件生成的配置文件（plugin-cfg.xml）基于通过关联的 Web 服务器路由的应用程序。Web 服务器插件帮助面向的网络中的应用程序服务器之间的工作负载平衡，改进请求响应时间。

图 5. 非受管节点通过插件接受管理

概要文件（Profile）

概要文件定义一个独立应用程序服务器（Server）的运行时环境，包括服务器在运行时环境中处理的所有文件。创建独立应用程序服务器时应该使用概要文件而不是多个产品安装，这样只需要保留一组产品核心文件即可，管理能力将得到极大的增强。不仅节省了磁盘空间，而且简化了产品的更新，只需要保留一组产品核心文件即可。而且与完整产品安装相比，创建新概要文件更快速，而且减少了出错的可能性，这允许开发者创建单独的产品概要文件以进行开发和测试。核心产品文件是由所有概要文件共享的产品二进制文件,如果希望二进制文件位于不同服务级别，在应用安装时设置。概要文件管理工具未提供删除功能，所以必须使用 manageprofiles 命令来删除概要文件。

使用概要文件创建独立应用程序服务器，则每个定义的应用程序服务器进程都在 profiles 目录内，除非在创建概要文件时指定新目录。如果将概要文件放在安装根目录中，则存在概要文件可能被例行系统维护破坏的风险。这些文件在随创建新的概要文件、重新配置现有的概要文件或删除概要文件等操作而更改。

IBM WAS ND提供了多种类型的概要文件，以下是最常用的三种：

单元概要文件

基本功能是在 Deployment Manager的管理下将应用程序提供给因特网或内部网。创建单元概要文件其实就是同时创建Deployment Manager 概要文件和已联合到单元的节点概要文件，构建一个最简单的单元环境。在创建初始单元概要文件后，可单独创建定制概要文件或独立概要文件，再通过联合操作将他们添加到 Deployment Manager管理的单元环境中。

Deployment Manager 概要文件

基本功能是将应用程序部署到WAS的管理单元。每个属于该单元的Server都作为受管节点引用。

Application Server 概要文件

基本功能是将应用程序提供给因特网或内部网。IBM WAS ND 产品的重要功能就是通过将 Server 节点添加到单元，调整独立应用程序服务器概要文件。单元中的多个应用程序服务器进程可以部署它需要的应用程序。也可以从单元除去 Server 节点以将节点返回到独立应用程序服务器的状态。每个独立应用程序服务器都具有其自己的管理控制台应用程序，可以使用它来管理Server。

图 6. 一个节点对应一个概要文件，一个节点内可以有多个Server

集群（Cluster）

集群是一起进行管理并参与工作负载管理的多个服务器集合。作为集群成员的服务器可以位于不同的主机上，与此相对的是作为同一节点下的服务器必须位于同一台主机上。单元可以没有集群，也可以有一个或多个集群。集群负责平衡服务器之间的工作负载。作为集群一部分的服务器称为集群成员。当在集群上安装应用程序时，会在每个集群成员上自动安装此应用程序。当删除集群时，也就同时删除了该集群的成员的任何应用程序服务器。没有办法保存任何集群的成员。除去集群成员的仅有方法就是删除应用程序服务器。如果希望保留要删除的集群中的应用程序或模块，则应该先将这些模块重新映射至另一集群。

图 7. 由两个节点内的三个Server组成的集群

关于Node、Profile与Server

这三个概念比较容易混淆，我们拿出来对比说明：Node=Profile。Node是管理上使用的概念，Profile是实际的概要文件，它们代表同一事物。Server 就是所谓的 Application Server Instance , 这是我们实际要布署 Application 的地方。在IBM WAS ND 产品中受管节点的Node Agent 目的就是让 Deployment Manager Server 可以透过 Node Agent 来管 Node (Profile) 中的 Application Server Instance，一个 Node (Profile) 中可以有多个 Application Server Instance。

如果是非ND版本 , 则属于 Single Server 版本，那么一个 Node (Profile) 中只能有一个 Application Server Instance，如果你希望在一台机器上有多个 Application Server Instance，那就只能透过创建多个 Profile (Node) 来达成，但这些 Node (Porfile) 彼此独立没有管理上的关系 (RelationShip)，只要使用的 TCP/IP Port 不要冲突即可。

一个较为复杂的实例

在完成了对IBM WAS ND 产品中相关概念的理解之后，我们通过一个较为复杂的实例来了解一个集群的构建过程。此次搭建的集群环境使用了三台测试服务器：

Table 1. 测试服务器情况

服务器地址	安装节点	其他资源
192.9.100.14	一个非受管节点	独立环境安装IBM HttpServer v6.1
192.9.100.17	一个DM节点和两个受管的应用服务器节点	/
192.9.100.19	一个受管节点，一个应用服务器节点	IBM DB2 v9.0数据库

客户端直接访问192.9.100.14上的IBM HttpServer，由IBM HttpServer根据节点本身设置的负载权重，分发访问请求。

图 8. 集群拓扑结构图

以下是该集群拓扑结构的安装步骤，只描述需要提示的关键步骤。

首先创建运行时环境。打开Profile Management Tool概要文件管理工具创建概要文件。选择创建单元概要文件，即同时创建一个Deployment Manager 概要文件和一个已经被联合的应用服务器节点概要文件，也可以创建DM概要文件再联合已存在节点。

图 9.

创建成功后在Deployment Manager 概要文件环境中登录到管理控制台，可以在“系统管理”中看见DM相关资源。

图 10.

节点列表。可以看见各种类型的节点：应用服务器节点、单元节点、HttpServer非受管节点。可以在此添加新的节点或联合已有非受管节点。各节点与单元主配置文件的同步操作也可以在这里完成。

图 11.

Node Agent列表。可以看见3个应用服务器节点被联合到单元之后，成为受管节点，开启了Node Agent进程。Node Agent在这里只能停止和重新启动。停止了之后就不能在此启动，需要回到Node下的概要文件中使用命令行去启动Node Agent。

图 12.

在“服务器”中选择“集群”，新建。一般来说，如果创建了集群，那么对各个单独节点的操作都应该在集群或DM中操作，而不应该去“服务器”中的“应用程序服务器”中单独操作。

图 13.

为集群添加成员（节点），并且在添加成员的同时重命名一个短名称。分配负载权重。指定分配给应用程序服务器的工作量。值的范围是 0 到 20。权重值越大表明将分得越多的工作量。

图 14.

可以对集群进行启动和停止操作。对集群进行启动停止，就是对集群内的成员节点进行启动停止。

图 15.

接下来安装web服务器，本例中采用IBM HTTP SERVER（IHS）。安装IHS的过程中注意在安装WAS IHS插件，填写Application Server主机名或IP时，如果是在集群环境下，就填写DM所在节点的主机名或IP地址。其他步骤没有困难。

图 16.

安装IHS结束之后会有Admin Server和HTTP Server两个Server。HTTPServer是通常意义上的Web Server。Admin Server是IHS用来配合IBM WAS ND产品提供远程管理服务的。启动Admin Server则可以在远程节点加入该Web Server节点，并对其进行启动、停止等管理。也可以直接将插件配置文件传播到这个节点上。

图 17.

安装插件，选择要配置的web服务器

图 18.

主要的生产配置是一台机器上的应用程序服务器和另一台机器上的 Web 服务器。此配置称为远程配置。与远程配置相对的是本地配置，其中应用程序服务器和 Web 服务器在同一台机器上。

图 19.

指明web服务器插件在IBM WAS ND中安装的位置。默认位置即可。

图 20.

指明IHS配置文件httpd.conf的位置和Web服务器的端口。在IHS那一端。

图 21.

接下来设置IHS中plugin-cfg.xml文件的位置，默认位置即可。IBM WAS ND上也有这样一个文件，可以通过手工COPY或“远程传播”的方式使二者保持一致。然后指明标示应用程序服务器的主机名或IP地址，推荐使用DM所在机器的主机名或IP地址。连续“下一步”至安装结束。

接下来需要将安装好的IHS及WAS插件加入到集群中去。可以通过管理控制台添加，也可以通过命令行形式添加，通过管理控制台添加比较简明，但步骤很多。下面描述一下快速命令行加入的方式：

1. 开启IHS的admin管理，在{IHS-install}/bin目录下运行

httpasswd -cm {install_dir}confadmin.passwd admin
　　
(admin 是管理IHS的用户名). 接着输入两次密码.

2. 在IHS节点中启动IBM HTTP Server 和 IBM HTTP Admin Server.

3. 将IHS节点的{plunin-install}/bin/configurewebserver1.bat文件拷贝到安装时填写的WAS服务器的{was-install}/bin目录.当时推荐的是DM所在服务器。

4. 在DM所在服务器上启动DM服务

5. 在DM所在服务器上打开一个命令行窗口,运行

{was-intall}/bin/configurewebserver1.bat

6. 如下图所示在配置管理控制台确认Web Server被成功加入。由于启动了Admin Server，所以这个Web Server 还可以在WAS的管理控制台被管理。版本处写的“不适用”是因为这个Web Server 节点是一个非受管节点。

图 22.

全部安装配置完毕后，还需要为每一个server设置一个端口号为80的虚拟主机，以便接收来自IHS的请求 。

图 23.

部署应用则按照常规方式安装应用即可。注意在映射至服务器时，需要将该应用同时映射到集群和HttpServer上去。如果不是web模块则不必映射到HttpServer上去，如EJB。这样应用会同时安装在集群环境中的所有Node下的所有Server中。安装后需要重启Cluster和重新生成、传播WAS Plug-in。

图 23.

为了让发布在Cluster上的应用能连接到数据库, 我们需要在所有的受管节点上创建相同的数据源。创建数据源的过程与普通过程无异，需要注意的是创建Jdbc Provider时作用域应该选择在节点范围。如果在Cluster级别，某些版本的ND可能出现问题。重启DM服务,并且重启所有受管节点的NodeAgent服务。

图 24.

至此，集群的全部搭建步骤就完成了，重新启动Deployment Manager、NodeAgent以及集群的服务。如拓扑结构中所示，可以通过访问WEB服务器来访问应用，即：http://192.9.100.14 或 http://192.9.100.14:80。也可以尝试将其中的一个或两个Node停止，以确认是否能继续访问。

结束语

越来越多的企业及政府应用系统提出了对集群环境的要求，本文的主要目的是想阐述清楚IBM WAS ND产品对集群及整个分布式网络环境的理解和定义。只有理解这些定义和架构，才可以在实际工程的集成与部署工作中拿出好的设计方案来，并最大程度的发挥IBM WAS ND产品的能力。