鸿 网 互 联 www.68idc.cn

当前位置 : 服务器租用 > 手机系统开发 > WP7 > >

WPS Network Deployment 经验分享

来源:互联网 作者:佚名 时间:2015-09-25 05:14
当前,越来越多的企业用户基于 WebSphere 应用服务器和 DB2 数据库环境搭建业务系统。随着业务量的增大,企业对系统的负载量和高可用性提出了更多的要求。Network Deployment(简称 ND)环境允许您从部署管理器(Deployment Manager)集中管理一组服务器。部
当前,越来越多的企业用户基于 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)。

网友评论
<