JBOSS集群说明与配置Word文档格式.docx

JBOSS集群说明与配置Word文档格式.docx

《JBOSS集群说明与配置Word文档格式.docx》由会员分享，可在线阅读，更多相关《JBOSS集群说明与配置Word文档格式.docx（10页珍藏版）》请在冰豆网上搜索。

负载均衡器同时负责加权静态负载均衡调度。

总之，负载均衡器的健康程度决定了集群的全局健康度，负载均衡器失败将导致集群全部失效。

这是前置机架构集群的主要潜在问题。

JBoss的负载均衡器架构集群实际是由Tomcat的HTTP集群实现的。

JBoss有自己的负载均衡器，但效果不佳，官方文档没有介绍，几乎没有人使用。

一般情况下，我们都是采用apache+mod_jk作为负载均衡器。

下文叙述的都是基于这种架构。

mod_jk是apache的一个插件，负责apache与tomcat之间的通讯，是JBoss集群配置（tomcat集群）的关键。

4.Jboss版本的选择

目前,JBoss主要有3、4、5三个版本系列。

JBoss5目前只有2个beta版，实用尚需时日。

JBoss3的最后版本是2006年3月更新的3.2.8.SP1。

随着JBoss4日益成熟和JBoss5的开发，已经停止更新1年多的Jboss3逐渐淡出历史舞台。

由于目前公司采用JBoss4.2.3GA，所以选择JBoss4.2.3GA实现JBoss集群配置。

5.Jbosscluster入门

Jboss支持如下类型的cluster：

EJB、web、JNDI、JMS，我们主要了解webcluster。

Webcluster实际上可以划分为两个话题：

负载均衡（loadbalance）和状态同步。

它们是互相独立的，单独配置。

负载均衡的概念比较简单，重要的是负载均衡的粒度。

可以选择针对每个request的均衡，或者是针对每个用户的均衡。

选择不同的粒度，需要不同的状态同步方式。

Ø

基于request的负载均衡

该种方式下，负载均衡器（loadbalancer）会根据各个node的状况，把每个httprequest进行分发。

使用这样的均衡策略，就必须在多个node之间复制用户的session，实时保持整个cluster的用户状态同步，这种操作被称为session复制（sessionreplication）。

Jboss的实现原理是使用拦截器（interceptor），根据用户的同步策略拦截request，做同步处理后再交给server产生响应。

该方法的优点是客户不会被绑定到具体的node，只要还有一个node存活，用户状态都不会丢失，cluster都能够继续工作。

缺点是node之间通信频繁，响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。

基于用户的负载均衡

该种方式下，当用户发出第一个request后，负载均衡器动态的把该用户分配到某个节点，并记录该节点的jvm路由，以后该用户的所有request都会被绑定这个jvm路由，用户只会与该server发生交互，这种策略被称为粘性session（sessionsticky）。

该方法的优点是响应速度快，多个节点之间无须通信。

缺点也很明显，某个node死掉以后，它负责的所有用户都会丢失session。

6.Jboss集群配置实例概述

该实例包含3个Jboss节点。

各节点被动接收负载均衡器转发的请求。

各节点间没有横向的联系。

6.1.环境准备

安装JDK1.5，并配置环境变量;

安装jboss4.2.3.GA，下载地址：

http:

//www.jboss.org/jbossas/downloads/;

安装apache_2.2.10，下载地址：

//httpd.apache.org/;

下载apachemod_jk，地址为：

//www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/;

6.2.负载均衡器配置

6.2.1.修改监听端口

本例中使用的监听端口是8080，请根据实际情况修改。

APACHE_HOME/conf/httpd.conf

将Listen80改为：

Listen8080

6.2.2.修改用户和用户组

将Userdaemon和Groupdaemon改为：

Userlijinchenga

GroupAdministrators

6.2.3.修改ServerName

删除ServerName前的#,将该行改为

ServerName127.0.0.1:

8888

6.2.4.apachemod_jk配置

将下载的apachemod_jk重命名为mod_jk.so，复制到APACHE_HOME/modules/中，修改APACHE_HOME/conf/httpd.conf 

，在文件末添加：

# 

Include 

mod_jk'

s 

specific 

configuration 

file 

conf/mod-jk.conf

在APACHE_HOME/conf/目录创建新文件mod-jk.conf，内容如下：

Load 

mod_jk 

module 

Specify 

the 

filename 

of 

lib 

LoadModule 

jk_module 

modules/mod_jk.so 

Where 

to 

find 

workers.properties 

JkWorkersFile 

conf/workers.properties 

put 

jk 

logs 

JkLogFile 

logs/mod_jk.log 

Set 

log 

level 

[debug/error/info] 

JkLogLevel 

info 

Select 

format 

JkLogStampFormat 

"

[%a 

%b 

%d 

%H:

%M:

%S 

%Y]"

JkOptions 

indicates 

send 

SSK 

KEY 

SIZE 

+ForwardKeySize 

+ForwardURICompat 

-ForwardDirectories 

JkRequestLogFormat 

JkRequestLogFormat 

%w 

%V 

%T"

Mount 

your 

applications 

JkMount 

/application/* 

loadbalancer 

You 

can 

use 

external 

file 

for 

mount 

points. 

It 

will 

be 

checked 

updates 

each 

60 

seconds. 

The 

format 

is:

/url=worker 

/examples/*=loadbalancer 

JkMountFile 

conf/uriworkermap.properties 

Add 

shared 

memory. 

This 

directive 

is 

present 

with 

1.2.10 

and 

later 

versions 

mod_jk, 

and 

needed 

for 

load 

balancing 

work 

properly 

JkShmFile 

logs/jk.shm 

jkstatus 

managing 

runtime 

data 

<

Location 

/jkstatus/>

status 

Order 

deny,allow 

Deny 

from 

all 

Allow 

127.0.0.1 

/Location>

在在APACHE_HOME/conf/目录创建新文件uriworkermap.properties，置为空，这个文件主要是做url路由的，基本格式为/url=worker_name;

在在APACHE_HOME/conf/目录创建新文件workers.properties,内容如下：

Define 

list 

workers 

that 

used 

mapping 

requests 

worker.list=loadbalancer,status 

Node1 

modify 

host 

as 

IP 

or 

DNS 

name. 

worker.node1.port=8009 

worker.node1.host= 

worker.node1.type=ajp13 

worker.node1.lbfactor=1 

worker.node1.cachesize=10 

Node2 

name 

worker.node2.port=8009 

worker.node2.host= 

worker.node2.type=ajp13 

worker.node2.lbfactor=1 

worker.node2.cachesize=10 

Load-balancing 

behaviour 

worker.loadbalancer.type=lb 

worker.loadbalancer.balance_workers=node1,node2 

worker.loadbalancer.sticky_session=1 

#worker.list=loadbalancer 

Status 

worker 

balancer 

worker.status.type=status 

说明:

●worker.node1.host、worker.node2.host和worker.node3.host要改成jboss集群各机器的实际IP.如果有更多的节点,顺序定义更多的node段,并在worker.loadbalancer.balance_workers后全部列出.

●lbfactor是负载分配权重,值越大分配的负载越多.

●worker.loadbalancer.sticky_session设置是否启用“粘着的”Session，stickysession是指来自同一IP的请求将被发送到同一个Jboss节点，stickysession设为0的话同一session的不同请求会被负载均衡分发到不同的jboss节点上。

6.3.Jboss集群节点配置

修改JBOSS_HOME/server/all/deploy/jboss-web.deployer/server

.xml文件，将Engine修改如下：

Engine 

name="

jboss.web"

defaultHost="

localhost"

jvmRoute="

node1"

>

... 

/Engine>

node1和node2分别对应相应ip的jboss；

修改JBOSS_HOME/server/all/deploy/jboss-web.deployer/META-INF/jboss-service.xml，找到<

attributename="

UseJK"

改为：

attribute 

true<

/attribute>

6.4.启动Jboss集群

先启动负载均衡器apache,然后启动各jboss节点。

各jboss节点的启动顺序没有要求。

6.4.1.启动负载均衡器apache

用netstat检查8080监听端口存在,apache启动成功.

6.4.2.启动Jboss节点

在集群各机器的/usr/local/jboss/bin,分别执行run.bat-call,default配置是不支持集群的。

用netstat检查8888端口监听存在.

用浏览器访问各节点的8888端口,能够看到jboss的状态.

Jboss启动成功.

6.4.3.集群的生命期

apache能够自动发现新启动的Jboss节点。

当第一个Jboss节点启动后，自动创建Jboss集群。

然后依次将其他节点加入到集群中。

现在访问http:

//192.168.8.246:

8888，能够看到jboss的状态.说明请求已经被转发到Jboss节点。

集群启动成功。

apache能够监视集群中各节点的状况，自动从集群中去掉无法访问的节点，从而保证每个请求都被响应。

当集群的全部节点都停止工作，集群消亡。

6.5.Jboss集群的session复制

6.5.1.集群的缺陷和粘着session

截止到现在,Jboss集群工作得很完美，除了session。

目前配置的Jboss集群中，各节点是被动的、相互独立的，相当于增加了节点状态检测的DNS轮询，所以session也是相互独立的。

当同一用户的2个请求被转发到不同的Jboss节点上时，会出现session信息假”丢失”的现象。

为此，Jboss提出粘着session（stickysession）概念。

使用粘着session后，来自同一IP的请求将被发送到同一个Jboss节点，从而保证session使用的连续性。

如果应用中没有使用session，则可以使用非粘着session的jboss集群。

这样，负载分布更为合理。

设置方法是编辑负载均衡器的/usr/local/apache2/conf/workers.properties的worker.loadbalancer.sticky_session。

设置为1使用粘着session，设置为0不使用粘着session。

使用粘着session还存在一种隐患，当某个节点发生故障时，该节点的session将全部丢失。

要彻底解决这个问题，就要用到jbosssession复制。

6.5.2.Jbosssession复制原理

jbosssession复制是jbosssession同步的一种实现。

原理是在各Jboss节点间建立横向联系，每个节点都将本节点的session变化同步到其他所有节点上。

jboss的session复制与HTTP集群是相互配合、相互独立的两个系统。

session复制是节点间的横向联系，HTTP集群是负载均衡器与节点的纵向联系。

6.5.3.配置Jboss节点

JBOSS_HOME/server/all/deploy/jbossweb-cluster.sar/META-INF/jboss-service.xml，找到<

ClusterConfig"

，有udp和tcp两种方式，任选一种即可，将bind_addr改为本机ip，<

tcppinginitial_hosts值设为:

node1IP[7810],node2IP[7810]；

vi/usr/local/jboss/server/all/deploy/tc5-cluster.sar/META-INF/jboss-service.xml

找到<

config>

udp,将>

到<

/config>

全部注释掉.

jbosssession复制有UDP和TCP两种方式.UDP采用多播方式,但问题比较多,所以jijian91采用TCP方式。

<

tcp,将>

生效.并对该部分进行以下修改：

∙将全部down_thread和up_thread的false都改为true.

∙在<

tcpbind_addr=”后填入本机的IP，比如<

TCPbind_addr=”>

tcppinginitial_hosts=”后填入本机和集群其他全部Jboss节点的IP[7810],比如<

tcppinginitial_hosts=”192.168.130.95[7810],192.168.130.99[7810],192.168.130.112[7810]”>

/tcpping>

其他参数还包括:

ClusterName是集群名称,比如partition1.

在同一局域网内,可以存在多个jboss集群,根据集群名称区分它们.所以,集群中各节点配置的集群名称必须一致,而机器IP则没有特殊要求,只要它们能相互连通.理论上,可以在一台机器上安装多个Jboss实例,分属于不同的集群.但这会极大地增加复杂度,是不好的配置方式.jijian91严重不建议给自己找麻烦。

IsolationLevel是隔离等级.

可选值包括：

SERIALIZABLE,REPEATABLE_READ,READ_COMMITTED,READ_UNCOMMITTED,和NONE。

这里的隔离级别和数据库的隔离级别有同样的含义，对于大多数WEB应用程序来讲通常设置为REPEATABLE_READ。

CacheMode是缓存模式。

由于session复制是通过缓存实现的,所以实际上是复制模式.可选值包括：

REPL_SYNC和REPL_ASYNC，确定改变是应该同步还是异步复制。

缺省值是REPL_ASYNC.使用同步复制，确保在请求完成之前传播改变，session同步没有滞后,但效率低。

6.5.4.配置应用程序

在应用程序的web.xml的<

web-app>

段中增加<

distributable/>

，如下所示：

?

xml 

version="

1.0"

encoding="

UTF-8"

web-app 

2.4"

xmlns="

xmlns:

xsi="

//www.w3.org/2001/XMLSchema-instance"

xsi:

schemaLocation="

distributable 

/>

...

/web-app>

在web-inf中添加jboss-web.xml文件，内容如下：

!

DOCTYPE 

jboss-web 

PUBLIC 

-//JBoss//DTD 

Web 

Application 

4.2//EN"

//www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd"

jboss-web>

replication-config>

replication-trigger>

SET_AND_NON_PRIMITIVE_GET<

/replication-trigger>

replication-granularity>

SESSION<

/replication-granularity>

replication-field-batch-mode>

/replication-field-batch-mode>

/replication-config>

context-root>

/<

/context-root>

/jboss-web>