JBoss_负载均衡

1.JBoss集群配置概念

JBoss集群(Cluster)是一组计算机节点的集合，它们作为一个整体向用户提供一组网络资源。一个理想的集群对用户是透明的。用户由单一入口访问集群的资源，从来不会意识到集群中的节点。在他们看来，集群是一个系统，而非多个计算机系统。集群还应该支持随意增加和减少集群系统的节点，而这同样不会影响到用户的访问。

2.JBoss集群分类

习惯上，JBoss集群配置的关键是把集群分为高可用(High Availability，简称HA)集群和高性能计算(High PerfermanceComputing，简称HPC)集群两类。HA集群的目标是提高系统的可使用性(availability),即可靠性(reliability)和可维护性(maintainability)。请不要将集群中的可使用性(availability)与UE和交互设计中的可用性(Usability)混淆。HA集群的核心是防止单点失效，这一般是通过失败转移来实现的，即在一个节点失效后由另一个节点接替服务。不丢失用户状态。HA集群的其他主要特性还包括负载均衡、session同步等。我们使用的SQL Server数据库的双机热备和Oracle的RAC都属于HA集群。HPC集群采用并行计算技术提供超大规模计算和存储能力，多数超级计算机都是HPC集群。这不是我们关注的集群。

3.JBoss集群架构

JBoss集群是HA集群。JBoss集群有2种架构。一是客户端拦截器(Client-side interceptor)架构，一是负载均衡器(Load balancer)架构。客户端拦截器架构适于用C/S结构，负载均衡器架构适用于B/S结构。本文只叙述负载均衡器架构的JBoss集群。

负载均衡器架构由负载均衡器和n个集群节点组成。每个节点是一个JBoss服务器实例。负载均衡器是全局唯一的前置机，全部用户请求都发到负载均衡器，由其转发到各节点。当负载均衡器发现一个节点失效后，会将请求转发到另一个节点上，从而保证服务得以延续。负载均衡器同时负责加权静态负载均衡调度。总之，负载均衡器的健康程度决定了集群的全局健康度，负载均衡器失败将导致集群全部失效。这是前置机架构集群的主要潜在问题。

JBoss的负载均衡器架构集群实际是由Tomcat的HTTP集群实现的。JBoss有自己的负载均衡器，但效果不佳，官方文档没有介绍，几乎没有人使用。一般情况下，我们都是采用apache+mod_jk作为负载均衡器。下文叙述的都是基于这种架构。mod_jk是apache的一个插件，负责apache与tomcat之间的通讯，是JBoss集群配置(tomcat集群)的关键。

 

5.Jboss cluster入门

Jboss 支持如下类型的cluster：EJB、web、JNDI、JMS，我们主要了解web cluster。

Web cluster实际上可以划分为两个话题：负载均衡 (load balance) 和状态同步。它们是互相独立的，单独配置。

负载均衡的概念比较简单，重要的是负载均衡的粒度。可以选择针对每个request的均衡，或者是针对每个用户的均衡。选择不同的粒度，需要不同的状态同步方式。

基于request的负载均衡

该种方式下，负载均衡器 (load balancer)会根据各个node的状况，把每个http request进行分发。使用这样的均衡策略，就必须在多个node之间复制用户的session，实时保持整个cluster的用户状态同步，这种操作被称为session复制(session replication)。Jboss的实现原理是使用拦截器(interceptor)，根据用户的同步策略拦截request，做同步处理后再交给server产生响应。

该方法的优点是客户不会被绑定到具体的node，只要还有一个node存活，用户状态都不会丢失，cluster都能够继续工作。缺点是node之间通信频繁，响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。

基于用户的负载均衡

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

该方法的优点是响应速度快，多个节点之间无须通信。缺点也很明显，某个node死掉以后，它负责的所有用户都会丢失session。

 

6.Jboss集群配置实例概述

该实例包含3个Jboss节点。各节点被动接收负载均衡器转发的请求。各节点间没有横向的联系。

6.2. 负载均衡器配置

6.2.1. 修改监听端口

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

APACHE_HOME/conf/httpd.conf

将Listen 80改为：Listen 8080

6.2.2. 修改用户和用户组

将User daemon和Group daemon改为：

User lijinchenga

Group Administrators

6.2.3. 修改ServerName

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

ServerName 127.0.0.1:8888

6.2.4. apache mod_jk配置

 将下载的apache mod_jk重命名为mod_jk.so，复制到APACHE_HOME/modules/中，修改 APACHE_HOME/conf/httpd.conf  ，在文件末添加：

# Include mod_jk's specific configuration file

Include conf/mod-jk.conf

 

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

# Load mod_jk module

# Specify the filename of the mod_jk lib

LoadModule jk_module modules/mod_jk.so

# Where to find workers.properties

JkWorkersFile conf/workers.properties

# Where to put jk logs

JkLogFile logs/mod_jk.log

# Set the jk log level [debug/error/info]

JkLogLevel info

# Select the log format

JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"

# JkOptions indicates to send SSK KEY SIZE

JkOptions +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 for updates each 60 seconds.

# The format of the file is: /url=worker

# /examples/*=loadbalancer

JkMountFile conf/uriworkermap.properties

# Add shared memory.

# This directive is present with 1.2.10 and

# later versions of mod_jk, and is needed for

# for load balancing to work properly

JkShmFile logs/jk.shm

# Add jkstatus for managing runtime data

<Location /jkstatus/>

JkMount status

Order deny,allow

Deny from all

Allow from 127.0.0.1

</Location>

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

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

# Define list of workers that will be used

# for mapping requests

worker.list=loadbalancer,status

# Define Node1

# modify the host as your host IP or DNS name.

worker.node1.port=8009

worker.node1.host=node1.mydomain.com

worker.node1.type=ajp13

worker.node1.lbfactor=1

worker.node1.cachesize=10

# Define Node2

# modify the host as your host IP or DNS name

worker.node2.port=8009

worker.node2.host= node2.mydomain.com

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 for managing load 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，sticky session是指来自同一IP的请求将被发送到同一个Jboss节点，sticky session设为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，找到<attribute name="UseJK">改为：

<attribute name="UseJK">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 -c all ,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(sticky session)概念。使用粘着session后，来自同一IP的请求将被发送到同一个Jboss节点，从而保证session使用的连续性。如果应用中没有使用session，则可以使用非粘着session的jboss集群。这样，负载分布更为合理。

设置方法是编辑负载均衡器的/usr/local/apache2/conf/workers.properties的worker.loadbalancer.sticky_session。设置为1使用粘着session，设置为0不使用粘着session。

使用粘着session还存在一种隐患，当某个节点发生故障时，该节点的session将全部丢失。要彻底解决这个问题，就要用到jboss session复制。

6.5.2. Jboss session复制原理

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

jboss的session复制与HTTP集群是相互配合、相互独立的两个系统。session复制是节点间的横向联系，HTTP集群是负载均衡器与节点的纵向联系。

6.5.3. 配置Jboss节点

JBOSS_HOME/server/all/deploy/jbossweb-cluster.sar/META-INF/jboss-service.xml，找到<attribute name="ClusterConfig">，有udp和tcp两种方式，任选一种即可，将bind_addr改为本机ip，<tcpping initial_hosts 值设为:node1 IP[7810],node2 IP[7810] ；

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

找到<config><udp,将><config>到</config>全部注释掉.

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

找到<config> <tcp,将><config>到</config>生效.并对该部分进行以下修改：

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

• 在<tcp bind_addr=”后填入本机的IP，比如<TCP bind_addr=”>

• 在<tcpping initial_hosts=”后填入本机和集群其他全部Jboss节点的IP[7810],比如<tcpping initial_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 version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"      xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee     http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd ">

<distributable />

 ...

</web-app>

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

<!DOCTYPE jboss-web PUBLIC

    "-//JBoss//DTD Web Application 4.2//EN"

    "http://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>true</replication-field-batch-mode>

    </replication-config>

    <context-root>/</context-root>

</jboss-web>