中国开发网: 论坛: 程序员情感CBD: 贴子 175223
疯子张
偶们的集群方案——图贴不上来。
一、建立应用服务器集群可行性分析

1、为什么要建立应用服务器集群

应用服务器集群的好处是给系统带来了可扩展的性能。当用户建立自己最初的系统时,无法精确预计未来的系统规模。如果一开始设计的系统规模很小,那么就无法适应可能出现的未来大规模发展。如果已开始设计的规模很大,那么很有可能会造成投资的浪费。在这种情况下,用户的最佳选择是可以先建立一个小规模的系统,而在系统规模扩大时,可以方便地进行扩充,不需要进行应用的重新开发和调整等高风险性的操作。应用服务器体系结构就可以满足用户的这种要求。所有的应用服务器系统,都具有负载均衡的能力,即将用户发来的请求,恰当地分配给各个应用服务器,使大家可以分别负担系统的负载。通过使用负载均衡,用户在扩大系统时,可以仅仅增加几台新的服务器,安装应用服务器软件,进行恰当的配置即可,无需对应用进行任何修改,这样就满足了可扩展性能的要求

在 WebSphere Application Server 中,应用程序服务器是运行应用程序 Servlet、JSP 或 EJB 的进程。它提供了 Servlet 运行期组件和 EJB 运行期容器。当一个单独的 WebSphere Application Server 不能具备足够的能力和可用性时,可以将几个 WebSphere Application Server 组建为一个集群,以提供负载均衡和故障切换的支持。集群中的每个应用程序服务器运行相同集合的应用程序,由一个 Deployment Manager(或称为单元管理器)来管理整个集群。对用户来说,这个服务器集群表现为一个单独的应用程序服务器。


2、xxxxxxx系统负载量很高

目前,有10个分行上线使用xxxxxxx系统,平均在线使用人数超过120人,峰值并发访问达到130个,系统的负载量非常高。由于PA-RISC32平台的JVM有2GB内存限制,导致很高并发负载的时候执行复杂统计查询内存消耗过大,应用服务器宕机。

接下来,还有28个分行上线使用,最终全国38个分行上线使用,根据当前使用状况预测,全行上线之后,平均在线使用人数将超过500人,峰值并发访问达到400-500,JVM的2GB内存肯定无法满足要求。

此外,单个WebSphere运行实例所能够处理的并发请求只能达到300,无法响应高达400-500的并发请求,因此使用应用服务器集群来提供负载均衡,是扩展系统性能,解决内存瓶颈的必经之路。


3、系统运行平台的限制

运行平台描述
硬件 HP-9000 PA-RISC32,8GB 内存
操作系统 HP-UX 11i
应用服务器 IBM Websphere V5.1.1
虚拟机 Sun Hotspot JVM1.4.1_03
内存限制 JVM可以管理的物理内存只有2GB,一旦有大量执行时间超长的统计查询,JVM内存就不够用了


4、使用集群进行负载均衡
应用服务器集群组成原理如下图所示:

在两台服务器上面运行6个WebSphere实例的集群

配置WebSphere应用服务器集群,既可以在单台物理服务器上面启动多个WebSphere实例组成一个集群逻辑组,也可以将集群部署到多台物理服务器上面组成分布式集群。如上图所示,使用两台物理服务器,每台物理服务器启动3个WebSphere集群实例,总共6个WebSphere实例组成应用集群,进行负载均衡。其中的一个WebSphere实例作为Deployment Manager(或称为单元管理器),因此可以被用来处理业务的WebSphere实例总共有5个。

客户登录xxxxxxx系统的每次访问请求都将根据相应的权重,被分配到某个WebShpere实例去处理。也就是说,原来是由单个WebSphere实例来进行业务处理,现在则被分配到5个WebSphere实例去处理。由于每个WebSphere实例只能够使用2GB物理内存,同时使用5个实例,使得整个xxxxxxx系统的可用物理内存大大扩展。

目前,单个WebSphere实例可以稳定的支撑6-8个分行上线交易,但是达到10个分行的时候,在每天下班前执行历史交易查询业务处理的时候,内存耗用明显吃力,甚至宕机,因此目前交易系统的瓶颈在于2GB的内存限制。使用5个实例的集群,则可以将大量的交易查询分担到5个实例各自执行,有效的降低了单个实例的内存耗用量。

5、集群具备了高可用性

目前,单个WebShpere实例运行交易系统,一旦交易量过大,导致JVM的2GB内存耗尽,WebSphere实例宕机,则无法对外提供交易服务,对于银行业务损失极大。当使用上述的集群方案的时候,一方面有效的进行了负载均衡,另一方面提高了系统的可用性。这是因为,一旦某个WebSphere实例因为某种原因宕机,其他WebSphere实例仍然可以正常运行,可以响应客户端的请求,完成交易操作,不会导致交易服务中断的情况出现。

此外,系统管理员还可以将宕机的WebSphere实例重新启动,再次加入当前的应用服务器集群中去。如果未来的业务系统交易量进一步增大,当前的集群无法满足需要的话,还可以再添置服务器,增加WebSphere实例到当前运行的集群中去,让业务系统获得近似无限的可扩展性和很高的可用性。


二、负载均衡集群的实施方案

1、规划负载均衡集群的实例

目前,单个WebSphere实例可以稳定的提供6个分行上线使用,当10个分行上线使用的时候,WebSphere在处理历史交易查询的时候,可能会出现内存不足的现象。一方面,可以优化统计查询的SQL,以加快查询执行时间,避免长期占用过多内存;另一方面,需要使用负载均衡集群来突破2GB内存的限制。

根据单个WebSphere实例可以稳定提供6个分行上线使用的经验来估算,两台物理服务器可以运行总计5个WebSphere实例,每个WebSphere实例使用2GB内存,整个集群可以稳定支撑30-40个分行上线,即可以满足全部38个分行上线使用的要求。



集群规划部署图

如图所示,在物理服务器TP1和物理服务器TP2上面都需要安装WebSphere Application Server,此外我们把TP1作为主服务器,在上面还需要安装IBM HTTP Server和Deployment Manager(用来部署和管理集群)。
其中TP1上面运行Deployment Manager和两个WebSphere实例,TP2上面运行三个WebSphere实例,实例部署拓扑图如下:


实例部署拓扑图

2、安装和部署WebSphere集群

假设:
TP1的IP地址为:10.10.10.75
TP2的IP地址为:10.10.10.76

1)分别在TP1和TP2上面安装WebSphere Application Server,并且启动两个Application Server,启动TP1上面的IBM HTTP Server。

2)安装Deployment Manager
Deployment Manager需要单独进行安装,由于TP1上面已经安装WebSphere ApplicationServer,因此在安装Deployment Manager的过程中,需要选择“Reconfigure the product to coexist with other versions of itself”,安装程序将建议为 Deployment Manager 设置新端口和地址。记录下新的 Admin Console Port 和 Soap Connector Address 以备后用。

3)创建Deployment Manager单元
安装完成之后,配置如下:
Node TP1:
* 安装了基本的 WebSphere Application Server
* 安装了 WebSphere Application Server Deployment Manager
* 安装了 IBM HTTP Server
Node TP2:
*安装了基本的 WebSphere Application Server

两个 WebSphere 节点必须添加到 Deployment Manager 的单元。使用 addNode 命令来完成这一任务,这个命令可以在每个节点(TP1 和 TP2)上的 WebSphere Application Server 安装的 bin 目录下找到。

首先在计算机 TP1 上执行 addNode ,等待命令结束,然后再在计算机 TP2 上执行。这个命令需要运行着 Deployment Manager 进程的计算机名称作为参数。此外,由于配置为 Deployment Manager 与 Application Server 共存于同一计算机上,所以必须为 Deployment Manager 的 SOAP Connector Address 指定另一个参数。例如主机名是 TP1,SOAP Connector Address 是 8880。

在 TP2 上执行相同的 addNode 命令,以将 TP2 加入到单元中。现在,在 TP1 上运行着一个 Deployment Manager 和一个 Node Agent,在 TP2 上运行着一个 Node Agent。

4)创建集群
使用 WebSphere Administrative Console 来创建应用程序服务器群集。

在浏览器中访问:http://tp1:9091/admin以打开 Deployment Manager Administrative Console,由于 Deployment Manager 与 Application Server 配置在同一主机上,所以您指定的端口是 9091 而不是 9090。输入用户 ID admin(或者您所选择的任何管理员 ID),并单击 OK。

在 Administrative Console 中,单击 +展开 Servers,然后选择 Clusters (Servers > Clusters)。在 Server Cluster 中,单击 New来创建一个新群集。

现在将进行下面的步骤:
* 创建一个群集
* 创建实例 1
* 创建实例 2
* 创建实例 3
* 创建实例 4
* 创建实例 5
* 安装一个企业应用程序

在步骤 1 中,输入 cluster1作为群集的名称。不要选中“prefer local”。选中 Create Replication Domain for this cluster。单击 Next 到步骤 2。

在步骤 2 中,在节点 TP2上创建一个名为 clone1的克隆。选择 Generate Unique Http Ports和 Create Replication Entry in this Server。使用默认的应用程序服务器模板并单击 Apply。

重复步骤 2,在节点 TP2上创建一个名为 clone2和clone3的克隆。选择 Generate Unique Http Ports和 Create Replication Entry in this Server。使用默认的应用程序服务器模板并单击 Apply。

再次重复步骤 2,在节点 TP1上创建一个名为clone4和clone5的克隆。选择 Generate Unique Http Ports和 Create Replication Entry in this Server。使用默认的应用程序服务器模板并单击 Next。

在群集的创建过程中,已经为这个群集创建了一个复制域(Replication Domain),可以用它来在克隆之间复制 http 会话以支持故障切换。为此,需要配置应用程序服务器 clone1到clone5去使用这一服务。在 Administrative Console 中,选择 Application Servers > clone1 > Web Container > Session Management > Distributed Environment Settings。然后选择 Memory to Memory Replication单选按钮。重复此过程设置 clone2到clone5。

5)部署应用
使用Deployment Manager将bdb.ear部署到cluster1上面。

至此,集群部署完毕,可以使用Deployment Manager 的 Administrative Console 来启动或停止群集。


三、集群方案实施计划

1、集群的运行环境

1)硬件要求
应用服务器集群不要求运行集群的硬件服务器配置一样,但是尽量应该保持一致。采用本集群方案,要求两台HP9000小型机,具备8GB内存,4路PA-RISC32的CPU。因此需要硬件添置一台和生产机器配置一样的HP9000小型机,和当前的生产机器组成集群的硬件环境。

2)软件要求
带有集群功能的WebSphere Application Server Enterprise Version,足够的License授权。


2、集群对应用程序的要求

xxxxxxx系统采用的是Struts + SLSB + DAO 的技术架构,在这样的架构下,部署集群,HTTP Session需要在每个WebSphere实例之间进行内存复制,因此要求保存在HTTP Session中的Java对象必须实现可序列化接口。


3、集群方案是否可以满足全行上线性能要求

本集群方案使用了5个WebSphere实例,每个WebSphere实例使用2GB物理内存,根据当前单个WebSphere实例可以稳定支撑6个分行上线的经验来推断,集群方案可以稳定支撑30个以上的分行上线使用。
几年前,技术抛弃了我;现在,我抛弃了技术。


相关信息:


欢迎光临本社区,您还没有登录,不能发贴子。请在 这里登录