GSXZGLJ系统WAS集群架构设计说明

 

 

一、系统容错及可靠性设计

 

现有的架构设计存在以下问题：

1. 前端负载分发基于硬件F5以NAT地址转发路由机制在分发Web请求，的确可以很好的降低Web负载，但由于系统未采用IHS作为独立的Web容器，以致WAS同时处理Web容器、J2EE容器、Servlet容器、缓存服务器等多种角色于一身，虽然便于管理，但WAS的容错性和可靠性却很差，但某一容器出现J2EE常见的GC垃圾回收失败时，会导致内存溢出，产生宕机风险。而面对这样的宕机产生，管理员除了重启服务无法保证业务连续性。

2. 虽然多台WAS看似以集群形式存在，但实际上并不能起到水平扩展的作用，这是一个似是而非的集群，并非IBM推荐的系统集成架构，这是一个危险且浪费资源的设计。

3. 会话无法被复制，不能支持页面会话级故障转移，这是大集中式的业务系统所不允许的。

4. 系统容错和可靠性设计对于应用程序的部署也有对应的讲究，否则无法达到高可靠性的要求。

 

我的设计主要表现在可靠性设计和系统容错上，设计的目的就是解决以上这4个问题。最终达到如下效果：

1. 水平垂直集群设计，解决横向扩展负载均衡和纵向故障转移的设计要求，达到会话级别的故障转移。

2. 基于session DB设计，让会话和web请求具备可追溯的映射关联关系，这是一切安全性可审计的前提。

3. 独立设计的Web容器集群、缓存集群、JSP/servlet集群、EJB集群，缩小了故障产生的影响面，可以有把握有效的解决问题。

 

二、设计说明

 

IBM WebSphere应用服务器具有容错和错误恢复能力的保障，主要是通过以下途径来实现容错和故障恢复。

1． 多层的集群技术

2． 内置HA管理器

3． Nanny(保姆)守护服务 

4． 支持Session级故障恢复

5． 备份和恢复应用服务器的功能，以支持人为操作错误的容错能力

 

下面从这几个方面做详细说明

1、多层的集群技术

IBM WebSphere Application Server完全提供端到端的多层的集群。包括Web服务器层、应用服务器（Web容器层和EJB容器层）的群集功能，在每个层次上实现不同组件的群集服务。

1.1 Web服务器层的集群

IBM WebSphere Application Server内置Edge Component组件，其中所含部件Network Dispatcher能够支持不同操作系统下的WEB服务器级的负载平衡，如下图所示。

Web服务器级的负载平衡

1.2 应用服务器层的集群

为了实现应用的扩展能力和保证应用的高可用性，WebSphere应用服务器采用多服务器群集的方式来提供应用的分布式部署、负载均衡、组件级的失效即时恢复（Fail Over）。在N层应用架构下，应用服务器群集可以为每一层逻辑的应用提供良好的扩展性和可用性，可提供高效率的负载均衡算法，提供一个可伸缩的负载平衡方案。在应用服务器层面，支持群集的部署，并且要具有很好的灵活性。可以为Servlet会话（Session）为用户提供透明的状态备份机制和快速的失效切换，同时服务器群集的管理简单方便，使关键应用具有高性能和高可用性。

WebSphere应用完全提供了独立于硬件系统的集群功能。在WebSphere应用服务器中，提供了两种方式的Cluster：垂直的方式和水平的方式。它们分别是为了适应不同的应用环境而设置的，垂直的Cluster允许在一台机器上实现动态负载均衡；而水平的Cluster允许在多台机器上实现动态的负载均衡。二者可以有机的协调工作，为复杂环境的应用实现负载均衡提供了强有力的保证。

单机环境下的应用级动态的负载平衡：

 

 

多机环境下的应用级动态的负载平衡：

水平集群和垂直集群的综合负载均衡解决方案：

 

IBM WebSphere Application Server支持当硬件平台或操作系统不是同一产品时的异构Cluster技术。在WebSphere中提供了简单的菜单设置方法来实现异构的Cluster技术。从用户来的角度来看，他根本不用关心怎样在一个平台上实现Cluster技术，只需要通过简单的菜单，按照App Server-Server Group-Cloning的简单流程就可以复制出自己想要的异构集群环境，轻松实现应用的扩展。

2、内置HA管理器

内置的HA管理器，对关键服务进行监控，如负载路由（WLM）, JMS消息，事务管理器等，自动侦测出现的问题。为关键业务的JAVA应用提供24×7 的运行保障。使DM不再成为一个单点故障。

基于HA管理器的统一集群框架提高了应用服务器的高可靠性。自动安装应用模式，保证了快速、简单的管理复杂动态的IT环境。

3、Nanny(保姆)守护服务

IBM WebSphere Application Server完全保证用户的程序在一个高可靠的环境内运行。WebSphere使用的是一种Nanny –服务的体系结构，使用该结构，所有的Application Server (应用服务器) 将由一个Administration Server(管理服务器)来监视管理，一旦由于一个特殊的原因（例如进程被杀掉）导致应用服务器停止，管理服务器将自动重新启动该应用服务器；同样，Administration Server (管理服务器) 由一个"Nanny(保姆)守护服务，该"保姆"服务一旦检测到管理服务器停止也将自动重新启动它。这样WebSphere从体系结构上就最大限度地保证服务器程序的可靠稳定运行。另外，就象我们在前面多次提到多的，WebSphere支持两种方式的复制技术：水平克隆和垂直克隆，它们都能保证应用系统的可靠性。

4、支持Session级故障恢复

IBM WebSphere Application Server会话管理负责管理 HTTP 会话，提供会话数据的存储器，分配会话标识，并通过使用 cookie 或 URL 重写技巧来跟踪与每个客户机请求相关的会话标识。会话管理可以以多种方法存储会话相关的信息：

l 应用程序服务器内存（缺省值）。此信息无法与其它应用程序服务器共享。 

l 在数据库中。此存储选项称为数据库持久会话。 

l 在另一个 WebSphere Application Server 实例中。此存储选项称为内存到内存会话复制。 

IBM WebSphere 应用服务器采用内存到内存复制和数据库持久的方式作为分布式会话引用。当应用程序服务器接收与当前内存中不存在的会话标识相关联的请求时，它可以通过访问外部存储（数据库或内存到内存）获取必需的会话状态，从而支持Session级故障恢复。

5、备份和恢复应用服务器的功能

WebSpher应用服务器提供备份和恢复应用服务器的功能(备份和恢复命令)。人为操作错误后，可使用已经备份的文件来恢复应用服务器的环境。

另外，集成到WebSphere 应用服务器管理控制台中的TPV可以动态监控各种性能参数，并用图表的方式显示，能快速发现和定位性能问题。

6、总结

IBM WebSphere Application Server可以通过透明的集群技术为所有的服务器（包括异构的平台）实现智能的工作负载均衡，保证整个应用系统在即使某台服务器出现故障的情况下仍然能够保证事务处理能够顺利地进行下去；内置HA管理器对关键性服务进行监控，保证了管理集群的组件DM的高可用性；备份集群的技术保证了用户的关键业务的不间断运行；会话故障恢复机制，保证了故障转移时用户会话数据的恢复；应用服务器提供的备份恢复功能，加强了人为操作错误的容错，保证了关键业务24x7x365的高可用性。

三、完成设计后的应用程序部署及维护说明

环境说明

单机环境（Base/stand alone environment）：只有1个应用程序服务器进程的环境，安装的产品是WAS Base。

网络部署环境（Network Deployment environment）：多个WAS进程、多结点的环境，由Deployment Manager统一管理，组成了一个Cell（类似于Windows中Domain的概念），安装的产品是WAS ND。也称为ND环境、Cell环境、集群环境等等。下面为了叙述和理解方便，简称为集群环境，注意，更严谨的叫法应该称为ND环境或者Cell环境。

以前为单机环境，现在扩展为集群环境。

当前环境举例为Linux系统，M1机器上安装了WAS5 ND, M2机器上安装了WAS5 Base，并已配置成cell环境。edge1和edge2机器上安装并配置了edge server。

集群系统拓扑图 vs.单机系统拓扑图

单机环境和集群环境在系统拓扑、管理方式上都有变化。下面的系统架构图是指客户发出请求访问系统时，涉及到的系统组件。WAS进程拓扑图则是针对不同系统架构中的WAS进程，给出的详细的WAS进程描述图。

单机系统

 

集群系统

 

 

上图虚线分割开的两部分是两台真实的物理机器。其中，M1机器上有进程Node agent、server1、Myc1。M2机器上有进程Depolyment Manager（以后简称dmgr）、Node agent、server1、Myc2。Myc1和Myc2组成了一个集群Mycluster。

从功能上，可以把这些WAS进程分为3类：

l DMGR：管理整个cell环境，对cell中每个WAS进程配置的修改都需要通过dmgr进行，每个cell环境只有1个。

l node agent：可以理解为中间通讯/监控代理，每个结点有一个。

l 应用程序服务器进程：我们把server1/ Myc*这样的进程称为应用程序服务器进程，应用是运行在这些应用程序服务器进程上的。在客户访问请求时，这些进程中必须至少有1个是active的。

启动/停止系统的变化

单机系统

在M1上:

cd /opt/WebSphere/AppServer/bin

启动：>./startServer.sh server1

停止：>./stopServer.sh server1

集群系统

一般来说，如果启动/停止整个系统，需要启动/停止dmgr、node agent、应用程序服务器进程（即server1、Myc1、Myc2）。在我们的配置中，如果修改了应用的配置或某个应用程序服务器进程的配置，一般只需要启动/停止集群，或者启停相应的的应用程序服务器进程，server1进程一般都是停止的（因为我们没有在server1上面部署应用，应用都部署在集群上了）。

请注意下面的命令都分别是在哪台机器上发出的。

集群系统的启动停止分为几种类型，它们一般都可以通过管理控制台或者命令行的方式来完成：

l 启动/停止Dmgr：

在M2上:

cd /opt/WebSphere/DeploymentManager/bin

启动：>./startManager.sh

停止：>./stopManager.sh

 

l 启动/停止node agent：

如果需要停止哪台服务器上的node agent，就到哪台服务器上去发命令：

cd /opt/WebSphere/AppServer/bin

启动：>./startNode.sh

停止：>./stopNode.sh

 

l 启动/停止集群：

有3种方法：

第一种方法：到管理控制台（后面会讲到怎么进集群系统的控制台），找到集群,如图5

 

 

 

第二种方法：到管理控制台（后面会讲到怎么进集群系统的控制台），通过管理控制台直接控制启停集群成员。如图6

 

 

 

第三种方法：到集群成员（如Myc1，或者Myc2）所在机器上，stopServer.sh 集群成员名字。以启停M1上的Myc1为例：

cd /opt/WebSphere/AppServer/bin

启动：>./startServer.sh Myc1

停止：>./stopServer.sh Myc1

 

l 启动/停止单个应用程序服务器进程：

方法与前面启停集群成员相同，有两种方法：

第一种方法：到管理控制台（后面会讲到怎么进集群系统的控制台），通过管理控制台直接控制启停。如图6。

 

第二种方法：到应用程序服务器进程（如server1、Myc1，或者Myc2）所在机器上，startServer.sh 应用程序服务器进程。以启停M1上的Myc1为例：

cd /opt/WebSphere/AppServer/bin

启动：>./startServer.sh Myc1

停止：>./stopServer.sh Myc1

 

集群系统中web server和edge server的启停

1. 启停Web服务器

到M1或者M2机器上，

cd /opt/IBMHttpServer/bin

./apachectl start

./apchectl stop

 

2. 启停edge server

到edge1或者edge2机器上，

dsserver

lbadmin  //启动图形配置界面，需要查看edge server运行状况或者更改edge server配置时用

不过，在安装了新应用、修改了应用服务器配置时，大多数情况下不需要重启web服务器或者edge server。

 

管理系统的变化

单机系统

http://M1:9090/admin

集群系统

http://M2:9091/admin

 

配置JDBC资源的变化

单机系统

资源配置只局限于单个WAS进程（server1）内

集群系统

需要考虑资源的scope。资源的scope分为3级：Cell, Node, Server。如果不同scope的资源有重名，运行时取local的资源。因此，如果有同名的资源，则Server级别的资源会覆盖Node级别的，Node的会覆盖cell的。一般在集群下，为简便，可把资源的scope配置成cell级别（可以理解为全局的）。如图7：

 

 

部署应用的变化

单机系统

到管理控制台，安装应用 -> next -> next

集群系统

分为如下几步进行：

1. 到管理控制台，安装应用-> next －> … －>目标映射到服务器->

“映射模块到目标服务器”切记选择应用部署到“Mycluster”，而不是server1。最后应该看到应用右面的”服务器”栏中只出现了Mycluster，如图8，图9:

 

 

 

 

 

 

2.保存时，记得选择“与结点同步更改”，如图10:

 

 

 

3.选择“环境 ->更新Web服务器插件”，如图11：

 

 

 

4.把M2机器上的

/opt/WebSphere/DeploymentManager/config/cells/plugin-cfg.xml拷贝到M1的/opt目录下

在M1机器上，发出以下命令：

scp M2: /opt/WebSphere/DeploymentManager/config/cells/plugin-cfg.xml /opt

 

5.以前在单机环境下启动server1之前，某些应用需要执行一段脚本，对应集群环境下，在启动单个的应用服务器进程（如Myc1，Myc2）之前，也执行该段脚本即可。例如

cd /opt/WebSphere/AppServer/bin

source /home/oracle/.bash_profile_back

./startServer.sh Myc1

 

系统日志位置的变化

单机系统

M1下，

/opt/WebSphere/AppServer/logs/server1目录

集群系统

希望看到进程在哪台机器，就到哪台机器下去看。

如果是Myc1，到M1机器的

/opt/WebSphere/AppServer/logs/Myc1目录；

如果是Myc2, 到M2机器的

/opt/WebSphere/AppServer/logs/Myc2目录；

如果是dmgr，到M2机器的

/opt/WebSphere/DeploymentManager/logs/dmgr目录

 

正常运行时，通常情况下组件的状态

l active:

edge1和edge2机器上的edge server。

M1和M2机器上的web server。

M1和M2机器上的Myc*进程。

 

l 可以active也可以不active的

node agent,

dmgr

但是在部署应用、修改WAS进程的配置时，node agent和dmgr必须active

 

l 不active的

M1和M2机器上的server1进程。因为我们没把应用部署在server1进程上，所以如果开着server1是白白浪费资源。

 

l 查看各个进程的状态

web server：ps –ef |grep httpd

WAS进程：./serverStatus.sh可以看状态