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分布式环境的体系结构，主要包括单元、节点、服务器、集群等基本概念，下面进行简单的介绍。
单元用来集中管理节点，每个单元里可以存在单个节点，节点下是单个服务器(server)。独立概要文件(standalone profile)就是这样。这种配置比较简单，适用于一般的开发或测试。
通常单元下面可能存在多个节点(Node)，这些节点通过部署管理器(deployment manager)来集中管理。服务器中应用程序的安装和卸载，以及环境的各种配置都通过部署管理器来更改，之后同步到各个节点。
节点主要用来管理单台物理主机上的服务器(server)。每台主机上可以存在多个节点，但每个节点只可以存在于单台主机上，并且节点由部署管理器集中管 理。
服务器由节点管理，服务器是完成具体应用的实体。
集群由单个或多个服务器作为成员组成。
集群里的服务器成员具有工作负载(workload)管理和失败补偿(failover)的能力。例如集群中有两个服务器成员，那么它们的工作负载可以平 均分配或其他比例分配。这个也就是集群的特点之一，负载均衡(load balance)。负载均衡可以避免某台服务器负载过重。集群的工作负载能力仅限于EJB相关，HTTP请求并不在其内。例如发送到服务器一的http请 求不可能被分到服务器二上。对于Http请求的分发我们推荐的是使用IBM Http 服务器，先请求IBM Http 服务器，再由IBM Http 服务器去完成负载均衡。失败补偿是指某个任务本应在服务器一上处理，但服务器一由于某种原因不处于活动状态，那么这个任务可以被转移到处于活动状态的服务 器二上面去完成。
综上所述，集群的行为与服务器类似，但它有负载均衡和失败补偿的能力。
安装完WPS后才可以创建概要文件，我们有以下三种概要文件可供选择：
部署管理器概要文件(Deployment Manager Profile)：用来创建部署管理器。
自定义概要文件(Custom Profile)：用来创建空的节点，空节点可以被添加入单元。
独立概要文件(Standalone Profile)：用来创建独立的服务器(standalone server)。独立服务器具有独有的节点和单元，通常应用于开发或测试环境，不应用于生产环境。
图中标示了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就认为用户没有登陆。这里牵涉到会话的管理，可以采用分布式会话来解决这个问题。注重安全的会话，可以选择数据库的方式；注重效率的会话，可以选内存复 制的方式。
目前ND的分类还没有统一的规定，根据日常使用，整理如下，仅供读者参考。
| 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，为了避免读者产生迷惑，这里也简单介绍一下：
| 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 |
| |
|
实际中的内部网络环境是非常复杂的，需要注意以下几点来避免不必要的麻烦。
ND中各节点与部署管理器之间要求双向通信。因此一旦添加节点到部署管理器的时候用了IP地址来代替主机名(hostname)，就必须保证该主机的IP 地址是不变的，我们可以选择静态IP地址代替主机名。假如使用主机名，需要尽量使用短名，避免长名。当遇到访问主机名不通的问题时，如果是windows 机器，可以给所有的windows机器都设置一个wins服务器，这样就可以相互通信了。
如果是UNIX机器，可以编辑/etc/hosts文件来达到这个目的，甚至编辑/etc/netsvc.conf，加入一行：hosts = local,bind 。这样/etc/hosts就会被优先读取。windows也同样适用此种方式
ND中各个主机的系统时间须一致。简单介绍一下UNIX下修改时间的方式。UNIX修改时间使用date命令。例如把时间改为9月14日18点50分，可 以这样运行：
- date 09141850
- 格式：月日时分
- date 091418502006
- 格式：月日时分年
搭建ND环境的时候需要提前考虑到机器的性能和各节点机器的性能均衡，另外数据库的性能也不容忽视。
部署管理器单独占用一台主机比较合适，可以再运行默认的数据库。BPE数据库和SCA数据库比较耗资源，尽量选择性能好的主机。 如果需要使用消息存储器(messagestore)时，建议消息存储器的服务器不要频繁重启。如果消息存储器的服务器重启，其他服务器存取消息时会非常 耗时。
搭建ND环境要充分合理的利用硬件资源。
| |
| |
这里我们用ND-C的测试环境来举例说明如何进行ND的搭建。ND-C，下面是ND-C的结构图：
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
概要文件的删除可以使用产品自带的wasprofile命令，一旦创建时出现问题可以选择删除后重建。
下面是一些常用的命令参数
- 列举所有的概要文件
- wasprofile -listProfiles
- 删除所有的概要文件
- wasprofile -deleteAll
- 删除指定的概要文件
- wasprofile -delete profileName
在删除概要文件之前，需要使用unaugment命令。总结一下删除概要文件的步骤:
- 1. wasprofile -unaugment -profileName ( profile name)
- 2. wasprofile -delete -profileName (profile name)
执行结束后可以重新创建所需的概要文件。
概要文件如果创建不成功(大部分是由于CEI初始化的原因)，可参照前一节删除后再重新创建。搭建ND环境需要创建部署管理器概要文件和自定义概要文件， 下面进行实际操作的步骤进行说明。
启动概要文件安装向导(WPS_HOME\bin\ProfileCreator_wbi\ pcatWindows.exe). 选择创建 “Development manager profile”，如图
这里我们需要注意SOAP的端口号，接下来的步骤会用到。
点击下一步，
没有选择“Run the WebSphere Process Server process as a Windows service”，继续。
这个步骤中，添上系统用户名和密码作为配置SCA时使用的安全模式。
如果提前创建了数据库，则选择第二项。
添加访问数据库时的用户名，密码，主机名和端口号。 其余步骤，按默认设置进行。
在另外两台机器上分别创建自定义概要文件
接下来与创建部署管理器的概要文件不同，如图
输入部署管理器的主机名与端口号。注意这里的端口号就是创建部署管理器的概要文件时的SOAP端口号。选择“Federate this node later using the add Node command”。其余步骤按默认设置即可。
在部署管理器的机器上启动部署管理器，使用命令“StartServer dmgr”。
返回到另外两台机器，分别使用命令行添加节点到部署管理器。“addNode dmgr_host [dmgr_port]” 如下所示：
注意，此步需要保持三台机器的系统时间和时区相互一致，误差小于3分钟。
打开部署管理器控制台的WEB页面，进入到“Servers->Clusters” ，选择NEW 新建集群。
创建集群下的成员。
输入成员名称选择成员所在的节点。注意，这里我们需要选择使用“defaultProcessServer”模版来创建。点击Apply.
继续创建第二个成员，点击Apply。
接下的步骤按默认执行。创建完成后要 点击保存 并选择同步到节点。
至此，已经初步完成ND环境的搭建，网络拓扑已经完成，但是要运行我们的应用程序，还要根据需要进行相关的配置。
3.5 配置Service Component Architecture
手工创建SCADB数据库，方式不限。
在控制台的WEB页面打开Servers->Clusters->cluster1->service component architecture，选择“configuration a destination location”。注意：此种控制台配置的方法只能配置一次，不能更改，我们可以事先备份各节点WPS安装目录下面的profiles文件夹，以方便及 时恢复。
如图所示，输入需要的参数，值得注意的地方已经用红色标出。 至此，完成对ND环境的SCA配置。
重起服务器，查看控制台“Service integration ->Buses”会生成两个Bus，如图。进入后查看Messaging engines 状态应为started。如果状态不是started，那么SCA没有完全配置成功，需要重新来配置。注意一点，这里并不是只要Messaging Engines 处于started状态就一定证明配置完全成功。根据以往多数的不成功情况大多出于此，因此也不能光看支持SCA的一些应用程序安装成功就认为配置SCA 成功。
3.6 配置Business Process Choreographer
Business Process Choreographer (简称BPC)主要是对业务流程(Business Process)和人工任务(Human Task)的应用程序提供支持。它为它们提供了相应的容器。这些容器必须在使用之前安装并配置。配置时，保持服务器启动状态。
打开“WPS_HOME\dbscripts\ProcessChoreographer\DB2\createDatabase.sql”，修改其中的 SQL语句，指定创建时的用户名和密码。
打开命令窗口，执行修改后的文件来创建数据库。
注意：此数据库与部署管理器在同一台机器，如果不在一台机器时，需要在数据库所在机器执行SQL文件。
打开控制台，进入“Servers->Clusters->clustername->Business process container”页面。如图
进入“Business process container installation wizard”。
选取jdbc providers，输入访问数据库的用户名密码等。点击step2
如图输入相关信息。点击step3。
保持默认设置，Next。创建完成后要 点击保存 并选择同步到节点。
打开控制台，进入“Servers->Clusters->clustername->Business process container”页面。如图
选择“Human task container”。
进入installed wizard。
输入相关信息，点击step2
保持默认，点击next。创建完成后要 点击保存 并选择同步到节点。
至此，BPC已经完成配置。
重起服务器，查看控制台“Service integration ->Buses”会生成一个Bus，如图所示。进入后查看Messaging engines 状态应为started。
3.7 配置Common Event Infrastructure
Common Event Infrastructure (简称CEI)是用来提供WPS服务器对事件的支持，例如对事件的监控等。这里在配置前请最好保持服务器启动的状态。
进入集群成员的节点所在的机器，修改“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”。
将生成的“PROFILE_HOME\event\dbscripts\db2”目录，拷贝到DB2数据库所在的机器上，进入该目录，执行命令 “cr_event_db2.bat server db2admin”。这里server参数是在数据库所在的机器执行，db2admin参数是访问数据库的具体用户名。
回到成员节点所在的机器上，进入“PROFILE_HOME\event\dsscripts\db2”目录，执行命令 “cr_db2_jdbc_provider.bat cluster cluster1”。这里的集群 指的是在集群范围创建数据源，cluster1是指ND环境中集群的具体名称。
注意：此时的数据源需要完整的重新启动服务器才可以生效。
进入部署管理器节点所在的机器上，“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”下多出两个应用程序，如图
重起服务器后，这两个程序处于运行状态。
至此CEI配置完成。查看控制台“Service integration ->Buses”会生成一个Bus，如图。进入后查看Messaging engines 状态应为started。
至此已经完成了ND环境的搭建，此时可以运行一些应用程序来检测我们的WPS是否工作正常。读者可以自己进行相关的测试。
举一反三，搭建其他种类的ND环境步骤大多如此。搭建ND1是最简单的一种，仅将创建集群改成创建服务器，其他相关配置与上述步骤类似。ND5与ND-C 的步骤一致。ND7，因为应用程序和消息引擎(Message Engine)分别在不同的集群上，情况比较复杂一些，配置SCA前创建两个集群，在配置SCA时，先对消息引擎集群进行配置，然后再对应用程序集群进行 配置，选择’Remote Destination Location’为消息引擎集群。配置BPC时仅需对应用程序集群进行配置。配置CEI时也比较复杂，在对应用程序集群按上述步骤配置CEI后，因为此 时CEI总线成员默认是应用程序的集群，换句话说它的消息引擎运行在了应用程序集群上，这样并没有把消息引擎运行在消息引擎的集群上。所以需要创建一个消 息引擎集群的CEI总线成员 （包括创建支持其服务的数据源等），之后删除应用程序集群的 CEI总线成员，并且还要更新总线的目的地(destination)。