WPS Network Deployment 经验分享

当前，越来越多的企业用户基于 WebSphere 应用服务器和 DB2 数据库环境搭建业务系统。随着业务量的增大，企业对系统的负载量和高可用性提出了更多的要求。Network Deployment（简称 ND）环境允许您从部署管理器（Deployment Manager）集中管理一组服务器。部署管理器负责管理其单元中的所有受管节点的配置和状态，并且将应用程序部署至该单元中的任何受管节点。通过 ND 集群，可以实现包含多个应用服务器的分布式环境，确保系统的吞吐量和高可用性。

<!-- START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!-- END RESERVED FOR FUTURE USE INCLUDE FILES-->

介绍

什么是集群？集群由一组应用服务器组成，每个服务器上部署了同样的应用程序。通过集群可以实现可扩展性（服务更多客户，提高吞吐量），负载均衡（平衡负载 资源，使资源得以有效利用），高可用性（提供故障恢复和补偿机制，在关键性业务中提供容错功能）。ND提供水平集群和垂直集群两种形式，垂直集群是指同一 机器上部署多个服务器，充分利用硬件资源，而水平集群利用多台机器资源，每台机器部署相同的应用。本文主要侧重水平集群，但是其中的很多概念对于垂直集群 也是适用的。

本文主要介绍了搭建WPS的Network Deployment环境搭建及相关的配置等方面的经验。

 

回页首

第一部分：基本概念

ND分布式环境的体系结构，主要包括单元、节点、服务器、集群等基本概念，下面进行简单的介绍。

1.1 Cell - 单元

单元用来集中管理节点，每个单元里可以存在单个节点，节点下是单个服务器(server)。独立概要文件(standalone profile)就是这样。这种配置比较简单，适用于一般的开发或测试。

通常单元下面可能存在多个节点(Node)，这些节点通过部署管理器(deployment manager)来集中管理。服务器中应用程序的安装和卸载，以及环境的各种配置都通过部署管理器来更改，之后同步到各个节点。

1.2 Node - 节点

节点主要用来管理单台物理主机上的服务器(server)。每台主机上可以存在多个节点，但每个节点只可以存在于单台主机上，并且节点由部署管理器集中管 理。

1.3 Server - 服务器

服务器由节点管理，服务器是完成具体应用的实体。

1.4 Cluster - 集群

集群由单个或多个服务器作为成员组成。

集群里的服务器成员具有工作负载(workload)管理和失败补偿(failover)的能力。例如集群中有两个服务器成员，那么它们的工作负载可以平 均分配或其他比例分配。这个也就是集群的特点之一，负载均衡(load balance)。负载均衡可以避免某台服务器负载过重。集群的工作负载能力仅限于EJB相关，HTTP请求并不在其内。例如发送到服务器一的http请 求不可能被分到服务器二上。对于Http请求的分发我们推荐的是使用IBM Http 服务器，先请求IBM Http 服务器，再由IBM Http 服务器去完成负载均衡。失败补偿是指某个任务本应在服务器一上处理，但服务器一由于某种原因不处于活动状态，那么这个任务可以被转移到处于活动状态的服务 器二上面去完成。

综上所述，集群的行为与服务器类似，但它有负载均衡和失败补偿的能力。

1.5 Profile - 概要文件

安装完WPS后才可以创建概要文件，我们有以下三种概要文件可供选择：

部署管理器概要文件(Deployment Manager Profile)：用来创建部署管理器。

自定义概要文件(Custom Profile)：用来创建空的节点，空节点可以被添加入单元。

独立概要文件(Standalone Profile)：用来创建独立的服务器(standalone server)。独立服务器具有独有的节点和单元，通常应用于开发或测试环境，不应用于生产环境。

1.6 A Overall Picture - 拓扑结构

图1. 典型的拓扑结构图

图中标示了DMZ(demilitarized zone)地带。Web Server 就在DMZ里，负责分发Http请求和Http的负载均衡。Http 服务器，Server A。

DMZ之后是一个具有3个成员的集群，Server B。集群和部署管理器都处于局域网内，外部不能访问。

外部只可以通过Http服务器ServerA进行Http访问。

了解了这个拓扑结构后通常会有几个问题被读者提出来：

• a.外部可不可以访问集群上的web服务?答案是可以，因为web服务使用的是http协议。
• b.外部可不可以访问集群上的无状态会话bean?答案是不可以
• c.外部可不可以直接访问集群里某个服务器上的http页面?答案是不可以
• d.外部可不可以直接访问部署管理器?答案是不可以

下面是一个思想试验。设想用户登陆，然后进行一些操作的场景，简化为：

1.登陆:http：//www.sample.com/login.jsp?user=xxx

2.浏览:http：//www.sample.com/view.jsp

先看`登陆'。用户选择登陆，Server A收到请求(login.jsp?user=xxx)后分发给集群里面的3个服务器进行处理。假设请求分给了server 1。server 1得到请求后，首先验证用户名和密码并创建一个会话(session)，返回客户端一个cookie。server 1得到这个cookie后认为用户已经通过登陆验证，下次访问时不需重复验证。

接下来用户选择浏览受限网页view.jsp。假设Server A得到请求，分发请求至server 1。因为server 1可以得到cookie，判定该用户已经登陆，可以继续浏览。但一旦请求被分发给server 2，server 2上没有cookie对应的会话，那么server 2就认为用户没有登陆。这里牵涉到会话的管理，可以采用分布式会话来解决这个问题。注重安全的会话，可以选择数据库的方式；注重效率的会话，可以选内存复 制的方式。

1.7 ND的种类

目前ND的分类还没有统一的规定，根据日常使用，整理如下，仅供读者参考。

简单ND分类

Topology Identifier Topology SS ND1 ND2 ND3 ND4 ND5 ND6 ND7 ND8

Standalone Server

ND – no clusters

Application cluster, Messaging engines (ME) and destinations not clustered

ME cluster, Applications and destinations not clustered

ME and destinations clustered, Applications not clustered

Applications and ME clustered – same cluster, Destinations not clustered

Applications, ME and destinations clustered – same cluster

Applications and ME clustered but different clusters, Destination not clustered

Applications, ME and Destinations clustered, but different clusters

现在又有一种新的分类说法ND-A，ND-B，ND-C，ND-D，为了避免读者产生迷惑，这里也简单介绍一下：

另一种ND分类

Topology Identifier Topology ND-A ND-B ND-C ND-D

one DM，one single server

one DM，two single server

one DM，one cluster，two cluster-members in two nodes

one DM，two cluster，every cluster have two members and the two members in two nodes

 

回页首

第二部分：网络环境问题

实际中的内部网络环境是非常复杂的，需要注意以下几点来避免不必要的麻烦。

2.1 保证双向通信

ND中各节点与部署管理器之间要求双向通信。因此一旦添加节点到部署管理器的时候用了IP地址来代替主机名(hostname)，就必须保证该主机的IP 地址是不变的，我们可以选择静态IP地址代替主机名。假如使用主机名，需要尽量使用短名，避免长名。当遇到访问主机名不通的问题时，如果是windows 机器，可以给所有的windows机器都设置一个wins服务器，这样就可以相互通信了。

如果是UNIX机器，可以编辑/etc/hosts文件来达到这个目的，甚至编辑/etc/netsvc.conf，加入一行：hosts = local,bind 。这样/etc/hosts就会被优先读取。windows也同样适用此种方式

2.2保证时间同步

ND中各个主机的系统时间须一致。简单介绍一下UNIX下修改时间的方式。UNIX修改时间使用date命令。例如把时间改为9月14日18点50分，可 以这样运行：

• date 09141850
• 格式：月日时分
• date 091418502006
• 格式：月日时分年

2.3保证机器性能

搭建ND环境的时候需要提前考虑到机器的性能和各节点机器的性能均衡，另外数据库的性能也不容忽视。

部署管理器单独占用一台主机比较合适，可以再运行默认的数据库。BPE数据库和SCA数据库比较耗资源，尽量选择性能好的主机。 如果需要使用消息存储器(messagestore)时，建议消息存储器的服务器不要频繁重启。如果消息存储器的服务器重启，其他服务器存取消息时会非常 耗时。

搭建ND环境要充分合理的利用硬件资源。

 

第三部分 环境的搭建

这里我们用ND-C的测试环境来举例说明如何进行ND的搭建。ND-C，下面是ND-C的结构图：

图2. ND-C的结构图

3.1 WPS的安装

WPS的安装这里是指产品的安装，不包括创建概要文件的部分。

如 果操作系统相同，使用者可以在一个机器上安装后（创建概要文件之前）将文件压缩复制到其他机器上，可以节省时间

UNIX系统也可以采取此种方式。Unix的相关命令如下。

• 压缩：
• tar cvf /home/build/wps_o0637.05.tar /usr/IBM/ProcServer
• 解压缩：
• cd /usr/IBM; tar xvf /home/build/wps_o0637.05.tar

3.2 WPS 概要文件的创建

3.2.1删除概要文件

概要文件的删除可以使用产品自带的wasprofile命令，一旦创建时出现问题可以选择删除后重建。

下面是一些常用的命令参数

• 列举所有的概要文件
• wasprofile -listProfiles
• 删除所有的概要文件
• wasprofile -deleteAll
• 删除指定的概要文件
• wasprofile -delete profileName

在删除概要文件之前，需要使用unaugment命令。总结一下删除概要文件的步骤:

• 1. wasprofile -unaugment -profileName ( profile name)
• 2. wasprofile -delete -profileName (profile name)

执行结束后可以重新创建所需的概要文件。

3.2.2创建概要文件

概要文件如果创建不成功(大部分是由于CEI初始化的原因)，可参照前一节删除后再重新创建。搭建ND环境需要创建部署管理器概要文件和自定义概要文件， 下面进行实际操作的步骤进行说明。

3.2.2.1 创建部署管理器概要文件

启动概要文件安装向导(WPS_HOME\bin\ProfileCreator_wbi\ pcatWindows.exe). 选择创建 “Development manager profile”，如图

图3. 概要文件安装向导

这里我们需要注意SOAP的端口号，接下来的步骤会用到。

图4. 设置端口

点击下一步，

图5. Windows服务定义

没有选择“Run the WebSphere Process Server process as a Windows service”，继续。

图6. SCA配置

这个步骤中，添上系统用户名和密码作为配置SCA时使用的安全模式。

图7. 数据库配置

如果提前创建了数据库，则选择第二项。

图8. 其他数据库相关配置

添加访问数据库时的用户名，密码，主机名和端口号。 其余步骤，按默认设置进行。

3.2.2.2 创建自定义 概要文件

在另外两台机器上分别创建自定义概要文件

图9. 概要文件类型选择

接下来与创建部署管理器的概要文件不同，如图

图10. 关联信息

输入部署管理器的主机名与端口号。注意这里的端口号就是创建部署管理器的概要文件时的SOAP端口号。选择“Federate this node later using the add Node command”。其余步骤按默认设置即可。

3.3 添加节点到部署管理器

在部署管理器的机器上启动部署管理器，使用命令“StartServer dmgr”。

图11. 启动部署管理器

返回到另外两台机器，分别使用命令行添加节点到部署管理器。“addNode dmgr_host [dmgr_port]” 如下所示：

图12. 添加节点到部署管理器

注意，此步需要保持三台机器的系统时间和时区相互一致，误差小于3分钟。

3.4 创建集群(Cluster)

打开部署管理器控制台的WEB页面，进入到“Servers->Clusters” ，选择NEW 新建集群。

图13. 创建集群

创建集群下的成员。

图14. 添加集群成员1

输入成员名称选择成员所在的节点。注意，这里我们需要选择使用“defaultProcessServer”模版来创建。点击Apply.

图15. 添加集群成员2

继续创建第二个成员，点击Apply。

接下的步骤按默认执行。创建完成后要 点击保存 并选择同步到节点。

至此，已经初步完成ND环境的搭建，网络拓扑已经完成，但是要运行我们的应用程序，还要根据需要进行相关的配置。

3.5 配置Service Component Architecture

3.5.1 创建SCADB数据库

手工创建SCADB数据库，方式不限。

3.5.2 配置SCA

在控制台的WEB页面打开Servers->Clusters->cluster1->service component architecture，选择“configuration a destination location”。注意：此种控制台配置的方法只能配置一次，不能更改，我们可以事先备份各节点WPS安装目录下面的profiles文件夹，以方便及 时恢复。

图16. 配置SCA

如图所示，输入需要的参数，值得注意的地方已经用红色标出。 至此，完成对ND环境的SCA配置。

重起服务器，查看控制台“Service integration ->Buses”会生成两个Bus，如图。进入后查看Messaging engines 状态应为started。如果状态不是started，那么SCA没有完全配置成功，需要重新来配置。注意一点，这里并不是只要Messaging Engines 处于started状态就一定证明配置完全成功。根据以往多数的不成功情况大多出于此，因此也不能光看支持SCA的一些应用程序安装成功就认为配置SCA 成功。

图17. SCA总线

3.6 配置Business Process Choreographer

Business Process Choreographer (简称BPC)主要是对业务流程(Business Process)和人工任务(Human Task)的应用程序提供支持。它为它们提供了相应的容器。这些容器必须在使用之前安装并配置。配置时，保持服务器启动状态。

3.6.1 创建BPEDB数据库和库表

打开“WPS_HOME\dbscripts\ProcessChoreographer\DB2\createDatabase.sql”，修改其中的 SQL语句，指定创建时的用户名和密码。

图18. BPE数据库语句

打开命令窗口，执行修改后的文件来创建数据库。

图19. BPE数据库创建

注意：此数据库与部署管理器在同一台机器，如果不在一台机器时，需要在数据库所在机器执行SQL文件。

3.6.2 使用安装向导配置业务流程容器

打开控制台，进入“Servers->Clusters->clustername->Business process container”页面。如图

图20. 进入BPC配置向导

进入“Business process container installation wizard”。

图21. BPC数据库配置

选取jdbc providers，输入访问数据库的用户名密码等。点击step2

图22. BPC其他配置

如图输入相关信息。点击step3。

图23. BPC 浏览器配置

保持默认设置，Next。创建完成后要 点击保存 并选择同步到节点。

3.6.3 使用安装向导配置人工任务容器

打开控制台，进入“Servers->Clusters->clustername->Business process container”页面。如图

图24. 选择HTC

选择“Human task container”。

图25. 进入HTC配置向导

进入installed wizard。

图26. HTC配置

输入相关信息，点击step2

图27. 其他HTC配置

保持默认，点击next。创建完成后要 点击保存 并选择同步到节点。

至此，BPC已经完成配置。

重起服务器，查看控制台“Service integration ->Buses”会生成一个Bus，如图所示。进入后查看Messaging engines 状态应为started。

3.7 配置Common Event Infrastructure

Common Event Infrastructure (简称CEI)是用来提供WPS服务器对事件的支持，例如对事件的监控等。这里在配置前请最好保持服务器启动的状态。

3.7.1 生成脚本

进入集群成员的节点所在的机器，修改“PROFILE_HOME\event\dbconfig\DB2ResponseFile.txt”文件。

• CLUSTER_NAME=SupportCluster
• SCOPE=CLUSTER
• DB_NAME=event
• JDBC_CLASSPATH="WPS_home\universalDriver_wbi\lib"
• UNIVERSAL_JDBC_CLASSPATH="wps_home\universalDriver_wbi\lib"
• JDBC_DRIVER_TYPE=4
• DB_HOST_NAME=db_hostname.rchland.ibm.com
• EXECUTE_SCRIPTS=NO

在当前目录下，命令行执行“config_event_database.bat DB2ResponseFile.txt”。产生两个目录“PROFILE_HOME\event\dbscripts\db2”和 “PROFILE_HOME\event\dsscripts\db2”。

3.7.2 创建Event数据库与库表

将生成的“PROFILE_HOME\event\dbscripts\db2”目录，拷贝到DB2数据库所在的机器上，进入该目录，执行命令 “cr_event_db2.bat server db2admin”。这里server参数是在数据库所在的机器执行，db2admin参数是访问数据库的具体用户名。

3.7.3 创建数据源

回到成员节点所在的机器上，进入“PROFILE_HOME\event\dsscripts\db2”目录，执行命令 “cr_db2_jdbc_provider.bat cluster cluster1”。这里的集群 指的是在集群范围创建数据源，cluster1是指ND环境中集群的具体名称。

注意：此时的数据源需要完整的重新启动服务器才可以生效。

3.7.4 创建CEI的应用程序

进入部署管理器节点所在的机器上，“PROFILE_HOME\event\application”目录，执行命令“..\..\bin \wsadmin.bat -f event-application.jacl -profile event-profile.jacl -action install -earfile event-application.ear -backendid DB2UDBNT_V8_1 -cluster cluster1”。

之后再执行命令“..\..\bin\wsadmin.bat -f default-event-message.jacl -profile event-profile.jacl -earfile event-message.ear -action install -cluster cluster1”，安装另一个程序。

完成后查看控制台“Applications->Enterprise Applications”下多出两个应用程序，如图

图28. CEI应用程序

重起服务器后，这两个程序处于运行状态。

至此CEI配置完成。查看控制台“Service integration ->Buses”会生成一个Bus，如图。进入后查看Messaging engines 状态应为started。

图29. CEI总线

至此已经完成了ND环境的搭建，此时可以运行一些应用程序来检测我们的WPS是否工作正常。读者可以自己进行相关的测试。

举一反三，搭建其他种类的ND环境步骤大多如此。搭建ND1是最简单的一种，仅将创建集群改成创建服务器，其他相关配置与上述步骤类似。ND5与ND-C 的步骤一致。ND7，因为应用程序和消息引擎(Message Engine)分别在不同的集群上，情况比较复杂一些，配置SCA前创建两个集群，在配置SCA时，先对消息引擎集群进行配置，然后再对应用程序集群进行 配置，选择’Remote Destination Location’为消息引擎集群。配置BPC时仅需对应用程序集群进行配置。配置CEI时也比较复杂，在对应用程序集群按上述步骤配置CEI后，因为此 时CEI总线成员默认是应用程序的集群，换句话说它的消息引擎运行在了应用程序集群上，这样并没有把消息引擎运行在消息引擎的集群上。所以需要创建一个消 息引擎集群的CEI总线成员 （包括创建支持其服务的数据源等），之后删除应用程序集群的 CEI总线成员，并且还要更新总线的目的地(destination)。