Jboss集群（四）

1 其他重要配置

1.1 三种指定连接控制器的方式

发现有三种方式指定那个连接有那个控制器来处理，区别是啥？？从下面的图中可以看到URL是怎么配置的？是JKMount还是uriworkermap

通过上面的页面可以看到配置jboss节点的状态。

而访问项目首页的地址是：http://localhost:8081/项目名称，比如我们使用 http://localhost:8081/meeting_video_s，apache会分发给某个已经配置好的jboss node，然后由jboss来处理。（8081端口是apache的监听端口号，而与某个jboss node的访问端口号没有干系）

1.1.1 通过mock_jk.conf 文件中的JkMount

D:\Program Files\Apache Software Foundation\Apache2.2\conf\mock_jk.conf 中：JkMount /jkstatus* jkstatus 说明uri中以/jkstatus开头的连接都交由jkstatus worker处理。

1.1.2 JkMount与location 结合的方式

D:\Program Files\Apache Software Foundation\Apache2.2\conf\mock_jk.conf 中

# Add jkstatus for managing runtime data

JkMount jkstatus

Order deny,allow

Deny from all

Allow from 127.0.0.1

</Location>

说明: JkMount后面的参数表示你配置的worker名称。

1.1.3 请求处理分配文件中配置

D:\Program Files\Apache Software Foundation\Apache2.2\conf\ uriworkermap.properties 中增加：

/jkstatus=jkstatus

1.2 Session问题

配置负载均衡器，两个 jboss服务器后，可以正常访问系统，但是发现有一个问题，例如，我使用用户zm登录后，主页完美呈现，过上一会，点击主页上的链接要转到其他页面的时候，session失效，系统跳到登录页面，查看了服务器日志，原来第一次登录的时候是在jboss1上登录的，后来点击链接的时候是访问的jboss2，而jboss1和jboss2 的session是独立的，即jboss1 和jboss2分别有各自的session ，所以才会造成session失效。查看session的配置方式: worker.loadbalancer.sticky_session=1

根据资料配置为1或者true时，应该为粘性sesseion，所以不应该出现上面的情况，测试了一下，原来是由于apache 安装在win7上的原因。

1.3 Apache与操作系统、IE的兼容性

Apache服务器机主	Apache服务器操作系统	测试IE	出现问题	解决方案
段清凤	Win7	IE8（段清凤、焦涛）	可以实现负载均衡，但是session粘连出现问题，基本失效、发生session错乱	将apache所在服务器IP设为信任站点，问题解决(第二天重启了系统就好了，即使不配信任站点也可以)
		IE8（珍珍）	没有问题
		IE6（唯一、蔡东余）	没有问题
珍珍	Win7	IE6、IE8	没有实现负载均稀，请求只能发给一个节点，另一个节点没有分到请求
李彪	xp	IE6、IE8	没有问题

1.4 Distributable问题

在web目录下web.xml文件中，在<web-app>节点下加入<distributable />，这一步非常重要，是为了通知tomcat服务器，当前应用需要在集群中的所有节点间实现Session共享。如果我的session 不共享，而是使用粘性session，这个属性就不需要配置了，网上很多文章即使用的粘性session也配置了这个参数，但是应该不配置也能实现粘性session.

例如，下面是一个含有distributable元素的部署描述符的例子：

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

</web-app>

如果tomcat中的所有应用都需要Session共享，也可以把conf/context.xml中的<Context>改为<Context distributable="true">，这样就不需对所有应用的web.xml再进行单独配置。

1.5 Session复制配置

不推荐，没试过.

下面要做的是基于request的cluster，也就让各个节点之间互相复制session状态。有两种复制模式，同步与异步。使用同步的方式，jboss会把session复制的操作和对request的响应放到一个应用事务(application transaction)，session复制完成后才去处理request。异步复制则发送session复制的消息后马上处理request，session复制则会稍有延迟。但是在多框架的web页面中，这样的集群方式会有问题。由于frame在同一时间发出多个request，会造成一些混乱，这也是采用基于用户的集群方式的原因之一。

JBoss 4.0.2中采用了Jboss cache来实现session复制，实际上就是一个分布式缓存，由于session id中包含了jvm route，所以能够分辨session属于哪个节点。Session的更新类似于hibernate中的乐观锁，有了更新之后就让session的版本号增加，其他节点通过对比版本号来决定是否同步session状态。

配置session replication首先需要编辑

%jboss% server\all\deploy\jbossweb-tomcat55.sar\META-INF\ jboss-service.xml，88行左右有：

<attribute name="SnapshotMode">instant</attribute>

这就是刚才提到的复制模式，instant为立即复制，如果设为interval 那么系统会在延迟一段时间再进行复制，时间长度在

<attribute name="SnapshotInterval">2000</attribute>中指定，单位是毫秒。

单独配置这一个地方还不够，在%jboss% server\all\deploy\ tc5-cluster-service.xml中有：<attribute name="CacheMode">REPL_ASYNC</attribute>这里才真正决定复制是同步的还是异步的，可以指定为REPL_ASYNC(异步)或者REPL_SYNC(同步)。在这个文件下面一点，还有一个config标签，里面指定了各个节点在进行session复制的时候如何通信，有udp和tcp两种可选，如果使用udp方式，那么应该将udp的lookback属性指定为true，因为windows上有一个叫做media sense的东西会影响udp multicast。注意如果你不了解multi address的ip规则，请不要随便修改mcast_addr的值。如果采用tcp方式的话，应该指定bind_addr的值为本机ip，并且在TCPPING标签的initial_hosts属性中列出所有节点，格式是”机器名[端口号]”，比如在我们的例子中，就应该这样配置tcp(以其中一个节点为例)：

<TCPPING initial_hosts="172.16.0.116[7810],172.16.32.88[7810]" port_range="3" timeout="3500"

num_initial_members="3" up_thread="true" down_thread="true"/>

<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />

<pbcast.NAKACK down_thread="true" up_thread="true" gc_lag="100"

retransmit_timeout="3000"/>

<pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" />

<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="false"

print_local_addr="true" down_thread="true" up_thread="true"/>

<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>

</config>

JBoss的clustering版主建议尽量使用udp。不过在Sobey内部，建议使用tcp方式，经测试可能有不明物体在影响udp通信，导致Timeout异常。

在%jboss%\ server\all\deploy\ cluster-service.xml中也有关于udp和tcp的配置信息，在4.0以前版本的jboss中，会以这个文件为主配置，4.0以后都以tc5-cluster-service.xml为主配置。

Jboss的配置完成了，最后需要在web应用中增加配置信息，控制session复制的粒度。在WEB-INF\ jboss-web.xml中增加以下内容：

<replication-config>

<replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>

<replication-granularity>SESSION</replication-granularity>

</replication-config>

其中replication-trigger是指定哪些操作引发session的版本更新，它的取值有：

SET_AND_GET

SET_AND_NON_PRIMITIVE_GET

SET

replication-granularity是复制粒度，可以取session或attribute。如果取为attribute有可能导致复制失败，这是目前版本的jboss cache的一个bug，等待修正。

部署项目，测试，如果配置没有问题，可以在%jboss%\0server\all\log\server.log中发现类似于这样的信息：

DEBUG [org.jboss.web.tomcat.tc5.session.JBossCacheManager] check to see if needs to store and replicate session with id Im9-qpuaXppMS+xXwE3M+Q**.server1

DEBUG [org.jboss.web.tomcat.tc5.session.ClusteredSession] processSessionRepl(): session is dirty. Will increment version from: 20 and replicate.

Session replication配置的成功率比较低，情况也很复杂，请仔细操作。

引用自：http://docs.huihoo.com/jboss/clustering/jboss-4.0.2.html

1.6 其他

1.6.1 负载均衡与session复制的概念

实际上，负载均衡和集群复制是两个概念。在Tomcat的集群复制中，分为DeltaManager和BackupManager两种，前者适合于小型系统，任何情况下，均进行Session复制，消耗大量资源。所以，我们应该采用BackupManager，仅在需要的时候(Tomcat挂掉的时候)进行Session复制。进行Session复制，还需要给你的web.xml配置文件中加一行<distributable/>。这样很麻烦，改变Tomcat的content.xml配置文件就可以了，修改19行为<Context distributable="true">

1.6.2 Apache绿色化

在本机安装了apache 后，需要把配置好的apache拷贝到别的电脑做测试，也就是当绿色软件使用，假设在本机的安装目录为D:\Program Files\Apache Software Foundation\Apache2.2，拷贝到另一个机器的D:\ Apache2.2目录，这时需要做两个操作：

1) 打开httpd.conf配置文件，将原来的目录“D:/Program Files/Apache Software Foundation/Apache2.2”替换为新目录“D:/ Apache2.2”。

2) 注册apche服务，在DOS窗口运行下面的代码

Cd d: D:/ Apache2.2/bin

httpd -k install -n "apache"

这样在windows的服务列表里，可以看到名称为apache的服务。启动D:\ Apache2.2\bin\ApacheMonitor.exe就可以对这个服务进行管理。

移除服务：httpd -k uninstall -n "服务名"