为 WebSphere Application Server Community Edition V2.1 构建 WADI 集群环境

转自：http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0912_chirh_wascewadi/index.html

从 WebSphere Application Server Community Edition ( 以下简称 WAS CE) 版本 2.1 以来，WAS CE 在 Tomcat native 集群之外，新增了对 WADI 集群的支持。相比于 Tomcat native 集群，WADI 集群同样提供了集群成员间 Session 复制来避免单点失效并实现灾难恢复，同时利用负载平衡来提高应用程序的可用性。另外在一个部署了 Farming 的 WAS CE 集群环境中，如果您在某个节点上进行应用程序部署或者生命周期管理，集群内的所有节点都会同步响应这些请求。 Farming 这个特性使得应用程序的管理 ( 如部署、启动、停止、以及卸载 ) 更加的逻辑化和透明化：通过一次部署 , 便可以将应用部署到 WAS CE 服务器集群中的每个节点；同样，只需一次操作，便可以管理集群内所有节点上该应用程序的生命周期。这篇文章将从实现机制和示例配置两方面对 WAS CE WADI 集群和 Farming 插件进行介绍

引言

WebSphere Application Server Community Edition（以下简称 WAS CE）是一个完全符合 Java Platform, Enterprise Edition 5（Java EE 5）规范、经认证的应用服务器。也就是说 WAS CE 包含所有支持 Java EE 5 实现的组件：Web 容器、EJB 容器、消息服务、命令行管理等开发和运行 Java EE 应用程序所需的环境。尽管 Java EE 5 的规范中并没有提供对集群实现的规范要求，但在实际的应用环境中，集群做为提供应用程序的扩展性以及保证其高可用性的常见解决方案，得到了非常广泛的使用。要实现集群，常见的做法是通过扩展多个服务器节点，使得会话以及节点信息在集群内复制传递，以此来保证应用程序的高可靠性。但随着集群内节点的增多，怎样保证集群的效率以及应用程序的可用性呢？尤其是在异构的应用服务器环境中，有什么较理想的解决办法吗？另外，为了实现集群中各个节点能够协调统一，每个节点上面都需要配置相同的应用程序，有什么比较好的办法能够进行批量部署，从而提高集群管理的效率？本文依次通过介绍 WAS CE 服务器中集成的 WADI 模块和 Farming 模块，向读者解答前面提到的问题，并将在文末通过具体实例演示在 WAS CE 服务器环境中如何使用 WADI 和 Farming 模块搭建 WAS CE 集群。文中所提及的内容为作者的学习总结，仅供读者参考，以帮助读者了解相关概念并熟悉部署过程，所述观点并不代表 IBM 。

WADI 集群的实现机制

WADI 的全称是 Web Application Distribution Infrastructure, 即 Web 应用程序分布式架构，从它的名字我们可以看出，WADI 这个项目设立的初衷是为了解决集群环境中 Web 层应用程序状态的管理。随着项目的逐渐成熟，再加上 WADI 自己独有的特性和解决方案，它已经演变成一个更加通用的分布式状态和服务管理框架。由于 WADI 是一个独立的开源项目，不依赖于任何现有的应用程序容器，因此在一个异构的环境中，WADI 的作用和意义就更为突出。

WAS CE 从版本 V2.1 开始，便将 WADI 集成到了自己的服务器分发包中，这样，WAS CE 的用户除了选用原有的 Tomcat 集群以外，还可以考虑选用 WADI 的集群方案。

WADI 简介及其特性

WADI 的设计目标简要概括为如下几点：

• 为分布式环境中提供可插拔的、栈式的页面调度（paging）和持久化（persistence）机制；
• 提供一个伸缩性强、可用性高、自分割（self-partitioning）和自愈合 (self-healing) 的集群基础；
• 提供状态到请求（State to Invocation）或者请求到状态（Invocation to State）的透明迁移（migration）；
• 提供可插拔的状态复制机制。

具体到 Web 层则为：保证在应用程序以及容器空间 HTTP 会话的一致性问题；提供 HTTP 请求和 会话迁移、HTTP 会话复制、以及 HTTP 会话序列化策略等。

WADI 的分布式会话查找机制使得无论集群中节点的数量是多少，会话的定位（location）、迁移（migration）以及插入（insertion）等操作所消耗的系统资源都保持为常量。另外，WADI 的会话复制机制只为每个会话复制指定数量的会话副本，这也保证了 WADI 集群在会话复制上的开销只和复制数量成比例，而不受集群节点的影响。WADI 的上述特点使得 WADI 集群具有很强的可扩展性，当业务需要的时候可以增加 WADI 集群的节点而不会为集群管理带来额外的开销。

下面我们来简单了解一下 WADI 在具体实现过程时所涉及到的几个关键概念。

分区（Partition）：用来记录会话的位置。在每个集群的服务空间（Service Space）中，分区的数量在集群的配置期间被指定，在运行时由分区管理器进行动态的管理，被平均地分配到每个节点。当集群的节点数量发生变化（新节点加入集群、或者现有节点退出集群）的时候，分区管理器会重新分配分区在节点上的分布，以确保分区数在集群的各个节点间上是平均的。WADI 中的分布式会话查找机制所利用的正是这一概念。

会话定位：WADI 集群的每个节点可以通过对会话 ID 进行一个简单的算法运算，从而得到该会话属于哪个分区；同时每个节点也知道每个分区具体由哪个节点负责管理（关于分区的信息，在每次分区重新分配的时候都通过集群中散发给每个节点）。所以，对于任何会话，任何节点都可以通过它的 ID 很快的找到这个会话的位置信息被保存在集群的哪个节点上。

会话复制：WADI 的会话复制策略决定会话副本的数量，以及由哪些节点来保存这些副本。当每次请求处理完成以后，会话就被更新到它的副本所在节点。另外，当某个节点离开集群的时候，复制策略将重新选择节点来保存会话副本。因此，它的会话复制策略更像一种“会话冗余”策略，因为会话复制通常是指在集群中的所有节点间复制会话的信息

会话迁移：当节点接收到请求的时候，如果节点拥有该请求所对应的会话，那么请求立即可以就在当前节点被处理；如果该节点上没有请求所对应的会话，那么节点就会请求分区管理器将会话迁移到当前节点，同时更新分区管理器中关于该会话的位置记录，然后请求在当前节点被处理。

WADI 集群在 WAS CE 中的实现

WAS CE 中集成了 Tomcat 作为 Java EE 应用服务器中的 Web 容器， 在 为 WAS CE 构建集群环境一文中，作者介绍了 WAS CE V1.0.1 中利用集成的 Tomcat V5.0 实现上下文级别 (Context level) 的集群功能。而从 V2.0 开始， WAS CE 所集成的 Tomcat V6.0 本身就提供了一个进行节点管理的模块 modules/groupcom，叫做 Tribes，以此来实现节点之间的通信；同时还有一个模块 module/ha 用于提供会话之间的复制，但是随着节点或者会话数量的增加，用于维护会话或者节点状态的内存开销也会越来越大，最终有可能导致整个集群停止工作。

从版本 2.1 开始， WAS CE 将 WADI 做为一个插件集成到服务器中，从而为用户提供了另一种集群方式。与先前版本中完全利用 Web 容器 Tomcat 所提供的集群功能相比，WADI 集群通过自己的会话管理机制协调 Web 层各个会话的状态，并同样可以利用 mod_proxy/mod_jk 的负载平衡功能来提高应用程序的灾难恢复能力。

在 WAS CE V2.1 中的 WADI+Tomcat 模式中， Tomcat 仅作为 Web 容器用于 Web 应用程序解析，节点和会话的管理则通过 WADI 自己的机制来实现，通过在固定数目的节点之间维护指定数量的 HTTP 会话副本，系统的开销不会因为节点或者会话数目的变化而出现较大的起伏，从而可以保证集群的性能能够稳定持久；由于 WADI 是一个独立的集群实现框架，它可以完全独立于 Java EE 容器，实现分布式 Java EE 环境的集群，同时配合使用相应的 EJB 容器，如 WAS CE 中已经集成的 OpenEJB，用户也可以实现有状态会话 Bean 的集群。本文中我们将仅介绍 Web 层面的 WADI 集群实现。另外 WAS CE 中特有的 Farming 特性将会使得应用程序的管理变得更加轻松，用户只需要在集群内的任一节点上使用部署命令，WAS CE 就会在集群中的其他节点上批量部署并启动应用程序。

在 WAS CE 中，WADI 和 Tomcat 都是以插件的形式存在的，因此我们来认识一下相关的插件：

表 1. WADI 在 WAS CE 中的对应插件

插件名称	对应的功能
Geronimo Plugins, Clustering :: WADI	提供了 Geronimo 和 WADI 的集成。
Geronimo Plugins, Clustering :: Clustering	提供了基本的 WADI 集群支持。
Geronimo Plugins, Tomcat :: Clustering Builder for WADI	提供了 WADI 集群在 Tomcat 6 上的部署支持。
Geronimo Plugins, Tomcat :: Clustering over WADI	提供了 WADI 和 Tomcat 的集成。

在上文我们提到 WADI 提供各种参数使得用户可以根据自己的业务需求灵活配置，在 WAS CE 中，这些可配置的参数直接作为 GBean 的属性值提供给用户。

由于 GBean 是 WAS CE 所使用的 Geronimo 架构中的最小可管理单元，服务器中的每个模块或者系统服务都对应到一组 GBean；为了向服务器中加入新的功能或者服务，需要相应的实现一组 GBean，并部署到 WAS CE 运行环境中。因此，要配置这些属性，需要知道相应的 GBean 名称和其含义：

表 2. WADI 在 WAS CE 中的 GBean 实现

Gbean类名	对应的功能
org.apache.geronimo.clustering.wadi.RoundRobinBackingStrategyFactoryGBean	实现与指定数目节点之间的会话的复制，默认为 2
org.apache.geornimo.clustering.wadi.TribesDispatchHolder	用于读取和设置 WADI 集群的名称、监听端口、是否采用广播还是静态成员模式等。. 默认采用广播模式监听集群内节点的变化。
org.apache.geornimo.clustering.wadi.BasicWADICluster	用于读取和设置 WADI 节点的信息以及监听策略，默认值为 NODE。
org.apache.geornimo.clustering.wadi.WadiStaticMember	用于设置节点作为为静态成员的配置信息
org.apache.geornimo.clustering.wadi.BasicWADISessionManager	用于读取和设置 WADI 会话管理器信息，如 Partition 的数目、SessionTimeOut、WadiSweepInterval 等

从 WAS CE 所提供的 GBean 信息可以看出，WADI 在 WAS CE 中的集群实现同样可以采用广播或者静态指定集群成员的方式，通常在单个节点的 WAS CE 环境中，用户只需要启动相应的模块就可以启动 WADI 集群功能，默认的广播模式和会话管理策略即可满足用户的需求。 节点（clusterNodeName）以及集群名称 (clusterName) 会由 WADI 插件自动从 WAS CE 安装目录下的 var\config\config-substitions.properties 配置文件中读取。同样，如果用户需要更改 WAS CE 节点上的 WADI 配置，只需要找到这个文件，然后更改以下参数即可：

DefaultWadiSweepInterval=36000 WebConnectorConTimeout=20000 DefaultWadiNumPartitions=24 ReplicaCount=2

Farming 的实现机制

Farming 也可以叫做“数据中心”或者“服务器农场”，用于批量化管理服务器上的资源或者应用程序。在 WAS CE 中，实现批量化管理的 Farming 模块也是以插件的形式集成到 WAS CE 服务器中。在同一个“农场”中的各个 WAS CE 服务器之间通过 JMX 连接器进行通讯，整个“农场”中所有的应用程序或者资源的部署和生命周期管理操作只需要在其中一台 WAS CE 服务器上进行。

在 WAS CE 中提供 Farming 功能的插件如下：

表 3. Farming 在 WAS CE 中的对应插件

插件名称	对应的功能
Geronimo Plugins, Clustering :: Farming	提供了对 Farming 的支持。

同样，用户也可以通过 Gbean 配置单个节点的属性：

表 4. Farming 在 WAS CE 中的 Gbean 实现

GBean名称	对应的功能
org.apache.geronimo.farm.config.BasicNodeInfo	用于读取和设置 Farming 环境中的节点信息
org.apache.geronimo.farm.config.BasicClusterInfo	用于读取和设置 Farming 环境中的集群信息
org.apache.geronimo.farm.deployment.MasterConfigurationStore	用于指定应用程序的目标部署位置，默认值为 /master-repository
org.apache.geronimo.farm.deployment.BasicClusterConfigurationStore	用于指定应用程序的目标部署位置，默认值为 /cluster-repository

为实现当前节点能够响应集群中其他节点所发起的部署命令，用户必须用当前节点的主机名或者 IP 地址指定在 config-substitions.properties 文件中的 RemoteDeployHostname参数。

图 1. WADI 和 Farming 在 WAS CE 集群环境中的逻辑

WAS CE 中 WADI 集群和 Farming 的示例配置

示例说明

本文章下载区提供了示例程序包（wadi-webapp.zip）可供用户下载，在这个示例程序包中有一个用于演示集群环境的 wadi-cluster 的示例。通过此示例应用程序，我们将对 WAS CE WADI 集群的实现机制有更加清晰的理解，对配置过程有更加具体的掌握。在这个示例中，我们将构建运行在两台不同机器上的 WAS CE 服务器组成的集群。

示例程序包含以下几个文件：

wadi-webapp-2.0.war

plan.xml( 支持 wadi cluster)

应用程序如果支持 WADI 集群，必须更新标准部署文件和 WAS CE 部署文件。

1. 配置标准部署文件，比如 web.xml, Web 应用程序必须标记为 ，表示在分布式环境中，当前节点上所有的会话信息，无论是新加入的还是对已有会话信息的更改，都将依照会话复制管理器的安排，复制到集群中的其他节点上。

   ..... .....

   
   
2. WAS CE 部署文件，比如 geronimo-web.xml, 在本文章的实例中该文件为 plan.mxl, 必须使用 属性值，它是由 geronimo-tomcat-clustering-wadi-X.xsd 定义的，在 WAS CE 安装目录的 schema 目录下，表示使用 WAS CE 中集成的 WADI+Tomcat 会话管理器。如下例所示：
   
   清单 1 . 部署计划文件配置示例
   

   <?xml version="1.0" encoding="UTF-8"?> yourGroupIdyourArtifactIdYourVersionwar/yourPath

   
   

实验环境说明

1）所有机器必须处于同一子网（subnet）中，并且支持广播（multicast）。

2）所有集群成员必须尽可能保证系统时间一致，较大的系统时间差异可能会出现问题。

3）本示例程序已在以下操作系统上进行了验证：

Linux IA32 – RHEL5.2, Suse10Sp2
Linux PPC64 – SuSe10Sp2
Windows IA32 - Windows 2003 Server SP1, Windows XP SP2

各节点配置说明

1）在 server 1 上更新 WAS CE 服务器配置，启动 farming 部署功能以及 WADI 集群功能

需要在 WAS CE 服务器停止的状态下，修改成员服务器 server1 安装目录下。

如下修改 server1 配置文件 var\config\config-substitutions.properties：

clusterNodeName=NODE1 RemoteDeployHostname=NODE1_IP

如下修改 server1 的配置文件 var\config\config.xml，启动并添加 Gbean 至 farming 模块：

清单 2.farming 部署模块配置

NODE2systemmanagerrmiNode2_IP1099JMXConnectorfalse${clusterNodeName}${clusterName} .....

其中

• org.apache.geronimo.configs/farming/2.1.4/car模块实现了 farm 部署功能，用户可以批量将应用程序部署到各个节点，而不需要逐节点部署；
• org.apache.geronimo.configs/tomcat6-clustering-wadi/2.1.4/car和 org.apache.geronimo.configs/wadi-clustering/2.1.4/car模块实现了 WADI 集群功能，启动模块后，server1 将会自动检测网络上的其他节点，将他们加到该集群中，如果其中一个节点出现意外情况关闭，那么其他组员也会检测到该节点退出集群。

2）在 server 2 上更新 WAS CE 服务器配置，启动 farming 部署功能以及 WADI 集群功能

需要在 WAS CE 服务器停止的状态下，修改成员服务器 server2 安装目录下

如下修改 server2 配置文件 var\config\config-substitutions.properties：

clusterNodeName=NODE2

RemoteDeployHostname=NODE2_IP

如下修改 server2 的配置文件 var\config\config.xml，同 server 1 配置文件比较，注意以下区别：

NODE1_IP

3）启动各节点：

在 GShell 中启动 server1, 该命令将从后台运行 WAS CE 服务器 r，并设置系统属性 node.name 为黄色，代表当前节点为节点 1，这个属性将被示例程序读取，用黄色方块标示在应用程序运行过程中节点 1 所响应的 HTTP 会话请求。

geronimo/start-server -D node.name=yellow – b

在 GShell 中启动 server2，即节点 2，并设置系统属性 node.name 为红色，所相应的会话请求标示为红色方块

geronimo/start-server -D node.name=red -b

使用 Farming 部署应用程序

在 server1 上通过如下命令行使用 farming 部署应用程序至 server1 和 server2

清单 3. 部署命令

deploy.bat/sh --user system --password manager \ deploy --targets org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=\ org.apache.geronimo.configs/farming/2.1.4/car, j2eeType=ConfigurationStore,name=MasterConfigurationStore SAMPLE_HOME\wadi-webapp-2.0.war $SAMPLE_HOME\plan.xml

注：通过 farming 模块统一部署、启动，卸载应用程序必须使用命令行方式，如下所示：

deploy.bat/sh --user system --password manager stop org.codehaus.wadi/wadi-webapp//war deploy.bat/sh --user system --password manager start org.codehaus.wadi/wadi-webapp//war deploy.bat/sh --user system --password manager undeploy org.codehaus.wadi/wadi-webapp//war

访问 server1：http://:8080/wadi-webapp/

图 2. 访问节点 NODE1 上示例程序

图 2 中黄色计数值 1 表明当前会话由黄色节点上的 WAS CE 服务器进程响应 .

访问 server2: http://:8080/wadi-webapp/

图 3. 访问节点 NODE2 上示例程序

图 3 中红色计数值 1 表明当前会话由红色节点上的 WAS CE 服务器进程响应。

下面我们将两个集群节点放至 Apache Web 服务器后进行负载均衡配置。

使用 mod_jk 配置 Apache http server

与上一系列中的应用示例相似，我们通过配置 Apache HTTP Server 作为我们的 LoadBalancer，实现 HTTP 请求的分发。略微不同的是，我们在这里使用 mod_jk 模块。下载 mod_jk.so放置 http 安装目录下的 modules 目录中，在安装路径下的 cofig 目录中 添加如下内容至文件 httpd.conf：

清单 4 .httpd.conf 文件配置示例

LoadModule jk_module modules/mod_jk.so # Loads the Jakarta Tomcat Connector module JkWorkersFile Install_Dir/conf/workers.properties # Tells the module the location of the workers.properties file JkLogFile Install_Dir/logs/mod_jk.log # Specifies the location for this module's specific log file JkLogLevel debug # Sets the module's log level to info JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " # Sets the module's log time stamp format JkAutoAlias Install_Dir/config-store # Automatically Alias webapp context directories into the Apache document space. JkMount /wadi-webapp/* loadbalancer

在 config 目录下创建文件 workers.properties，文件内容如下：

清单 5 .workers.properties 文件配置示例

worker.list=loadbalancer worker.node1.port=8009 worker.node1.host= worker.node1.type=ajp13 worker.node1.lbfactor=1 worker.node2.port=8009 worker.node2.host= worker.node2.type=ajp13 worker.node2.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 worker.status.type=status

访问应用程序 http://your_http_server_host/wadi-webapp/

首次打开页面，初始计数加一

图 4. 通过 Web 服务器访问示例

对页面刷新四次，计数为 4。帧背景颜色红黄混合表明会话在红色和黄色节点间迁移，这个取决于 Apache mod_jk 对每个帧运行的目标服务器的选择。

图 5. 会话保存状态示例

在页面上有 9 个帧，9 个帧均指向 session.jsp 页面，每刷新页面一次，历史纪录将保留，计数同步增加 1，每个数字单元背景颜色表示当前会话所在的节点。黄色代表节点 1，红色代表节点 2。数字颜色变换表示当前会话内容在不同节点间转移。

验证会话复制功能

在 Tomcat 集群中，通过 shutdown 命令关闭一个集群成员时，会话复制就会被激活并启用，然而在 WADI 集群中，要激活会话复制功能，必须使 WADI 集群中的某个节点非正常关闭，因此不能使用 shutdown 命令关闭集群成员，用户可以使用 Ctrl+C 或者 Kill 命令模拟 WAS CE 服务器进程的非正常关闭。

使用 Ctrl+C 停止 server1, 即黄色节点上运行的 WAS CE 进程 , 刷新页面后，会发现历史数据依然保留，并且计数仍然持续增加，背景颜色全部为红，表明当前会话被复制至红色节点。如果集群中有 3 个以上成员，可以通过

var/config/config-substitutions.properties 文件中的 ReplicaCount 参数设置复制会话的份数，默认值为 2。

图 6. 会话复制示例

总结语

本文介绍了利用 WAS CE 中的 WADI 和 Tomcat 构建 Web 集群环境，使用 WAS CE 独有的 Farming 插件实现 Web 应用程序批量部署的原理、方法和步骤，并通过具体示例演示了如何配置应用程序和实际的生产环境。

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

转载于:http://blog.itpub.net/14789789/viewspace-623483/