JBoss 集群配置指南.doc

JBoss 4.0.2集群配置指南JBoss 4.0.2集群配置指南本文主要讲解JBosscluster的基本知识以及简单的配置方法，其间涉及了一些jboss的补充知识。一、材料准备： 1、JBoss4.0.2JBoss各个版本之间差异比较大，即使同为jboss4.x的版本，内部组件的版本也不一致，所以请尽量使用同一版本的server。目前已经证明可以配置cluster的版本多为jboss3.2.6和jboss4.0.2。2、Apache2.0.543、Apachemod_jk-1-2-13-apache-2-0-54二、安装：1、jboss4.0.2与apache2.0.54的安装请自行搞定。假设jboss的安装目录为%jboss%，apache安装目录为%apache%。2、mod_jk的安装。从获得文件mod_jk-1-2-13-apache-2-0-54.so，将该文件拷贝到%apache%modules。三、jbosscluster入门Jboss支持如下类型的cluster：EJB、web、JNDI、JMS，我们主要了解webcluster。Webcluster实际上可以划分为两个话题：负载均衡(loadbalance)和状态同步。它们是互相独立的，单独配置。负载均衡的概念比较简单，重要的是负载均衡的粒度。可以选择针对每个request的均衡，或者是针对每个用户的均衡。选择不同的粒度，需要不同的状态同步方式。1、基于request的负载均衡该种方式下，负载均衡器(loadbalancer)会根据各个node的状况，把每个httprequest进行分发。使用这样的均衡策略，就必须在多个node之间复制用户的session，实时保持整个cluster的用户状态同步，这种操作被称为session复制(sessionreplication)。Jboss的实现原理是使用拦截器(interceptor)，根据用户的同步策略拦截request，做同步处理后再交给server产生响应。该方法的优点是客户不会被绑定都具体的node，只要还有一个node存活，用户状态都不会丢失，cluster都能够继续工作。缺点是node之间通信频繁，响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。2、基于用户的负载均衡该种方式下，当用户发出第一个request后，负载均衡器动态的把该用户分配到某个节点，并记录该节点的jvm路由，以后该用户的所有request都会被绑定这个jvm路由，用户只会与该server发生交互，这种策略被称为粘性session(sessionsticky)。该方法的优点是响应速度快，多个节点之间无须通信。缺点也很明显，某个node死掉以后，它负责的所有用户都会丢失session。四、实战1、负载均衡Jboss的负载均衡目前有两种方案，一是使用apache的mod_jk，二是使用jboss自带的负载均衡模块。下面分别讲解这两种配置。mod_jk的配置1、请确认%apache%modules下已经有mod_jk-1-2-13-apache-2-0-54.so文件。2、修改%apache%confhttpd.conf在文件末尾添加:Includeconf/mod_jk2.conf3、在%apache%conf下新建文件mod_jk2.conf文件内容如下：#Loadmod_jkmodule.Specifythefilename#ofthemod_jklibyouvedownloadedand#installedintheprevioussectionLoadModulejk_modulemodules/mod_jk-1-2-13-apache-2-0-54.so#WpertiesJkWorkersFileconf/perties#WheretoputjklogsJkLogFilelogs/mod_jk.log#Setthejklogleveldebug/error/infoJkLogLevelinfo#SelectthelogformatJkLogStampFormat%a%b%d%H:%M:%S%Y#JkOptionsindicatetosendSSLKEYSIZE,JkOptions+ForwardKeySize+ForwardURICompat-ForwardDirectories#JkRequestLogFormatsettherequestformatJkRequestLogFormat%w%V%TJkMount/*loadbalancer其中JkMount/*loadbalancer的意思是，把所有的请求都发给loadbalancer处理。可以通过修改url来控制发送某些request。4、在%apache%conf下新建文件perties其内容为：worker.list=loadbalancer,server1,server2#Definethefirstnode.worker.server1.port=8009worker.server1.host=16worker.server1.type=ajp13worker.server1.lbfactor=1worker.server1.local_worker=1worker.server1.cachesize=10#Definethefirstnode.worker.server2.port=8009worker.server2.host=8worker.server2.type=ajp13worker.server2.lbfactor=1worker.server2.local_worker=1worker.server2.cachesize=10#Nowwedefinetheload-balancingbehaviourworker.loadbalancer.type=lbworker.loadbalancer.balanced_workers=server1,server2worker.loadbalancer.sticky_session=1其中对于node的命名规则是worker.节点名.xxxx。所以上述文件定义了两个节点：server1和server2。8009端口是jboss默认的ajp端口，另外需要注意的是worker.server2.lbfactor参数，它是节点的负载加权，它的值越大，获得负载的机会就越大。可以根据node的硬件性能进行调整。worker.loadbalancer.sticky_session参数是指定是否使用粘性session。所有需要负载均衡的节点，都必须在worker.loadbalancer.balanced_workers参数中列举出来。请记住所有node的名称和它对应着哪台机器，后面的配置中会使用。尝试启动apache：%apachebinapache.exe，正常情况下没有任何提示。如果你使用的jk是2.0的，那么配置文件的写法完全不同，由于mod_jk2已经停止开发，所以apache并没有提供任何讲解，对于配置文件的编写也没有任何指导。Jboss自带均衡器的配置将文件夹%jboss%docsexamplesvarialoadbalancerloadbalancer.sar拷贝到%jboss%serveralldeploy下，并且修改loadbalancer.sarloadbalancer.sarMETA-INFjboss-service.xml，在标签中类出所有节点，在标签中指定是否使用粘性session。配置完成。该均衡器的缺点是负载能力相对不高，配置参数太少，比如无法指定不同节点的负载加权，所以后面都以mod_jk为例，不再讲解jboss自带的负载均衡器的内容。负载均衡的配置基本完成，启动jboss，其中过程中会列出DefaultPatition中所有的节点：run.bat-call任何节点的关闭与启动都会在cluster中广播，比如加如一个新节点后，其他节点会得到以下提示：2、sessionsticky配置apache应该会以粘性session的方式分发请求。部署一个应用测试一下，你会发现粘性session没有起作用。因为我们还没有给jboss配置jvm路由(jvmRoute)，apache就无法知道究竟哪些session是属于哪个节点的。我们继续往下：修改server1机器上的jboss的配置文件：%jboss%serveralldeployjbossweb-tomcat55.sarMETA-INFjboss-service.xml在110行有：false，将它改为true。值得注意的是在这行标签上面有一段注释，要求你在server.xml中必须有：Enginename=jboss.webjmvRoute=Node1defaultHost=localhost请注意这里有一个气死人不偿命的小bug，jboss的官方文档把jvmRoute写成了jmvRoute，就是v和m两个字母的颠倒让我郁闷了三天，翻遍了和。都是直接拷贝的错，吐血吐到脱水啊。下面需要修改server1上的%jboss%serveralldeployjbossweb-tomcat55.sarserver.xml，在32行左右有：给它增加一个jvmRoute属性：请注意，jvmRoute的值必须和mod_jk中的节点名字正确对应，否则无法正确路由。Cluster中的所有节点都应该做相应的配置。Jboss的配置完成了，下面需要在你的web应用中修改配置文件，让它支持集群。在WEB-INFweb.xml中加入属性：Ok，基于用户的cluster完成了，每个用户会绑定都某个节点上进行交互。这种绑定是如何完成的呢？原来apache把客户分发到节点后，该节点会在用户的sessionid后面加上此节点的路由名称，变成这个样子：Efdfxxd98daja87daj76da2dka*,server1有了这个标志，就能分辨该session属于哪个节点。3、sessionreplication配置下面要做的是基于request的cluster，也就让各个节点之间互相复制session状态。有两种复制模式，同步与异步。使用同步的方式，jboss会把session复制的操作和对request的响应放到一个应用事务(applicationtransaction)，session复制完成后才去处理request。异步复制则发送session复制的消息后马上处理request，session复制则会稍有延迟。但是在多框架的web页面中，这样的集群方式会有问题。由于frame在同一时间发出多个request，会造成一些混乱，这也是采用基于用户的集群方式的原因之一。JBoss4.0.2中采用了Jbosscache来实现session复制，实际上就是一个分布式缓存，由于sessionid中包含了jvmroute，所以能够分辨session属于哪个节点。Session的更新类似于hibernate中的乐观锁，有了更新之后就让session的版本号增加，其他节点通过对比版本号来决定是否同步session状态。配置sessionreplication首先需要编辑%jboss%serveralldeployjbossweb-tomcat55.sarMETA-INFjboss-service.xml，88行左右有：instant这就是刚才提到的复制模式，instant为立即复制，如果设为interval那么系统会在延迟一段时间再进行复制，时间长度在2000中指定，单位是毫秒。单独配置这一个地方还不够，在%jboss%serveralldeploytc5-cluster-service.xml中有：REPL_ASYNC这里才真正决定复制是同步的还是异步的，可以指定为REPL_ASYNC(异步)或者REPL_SYNC(同步)。在这个文件下面一点，还有一个config标签，里面指定了各个节点在进行session复制的时候如何通信，有udp和tcp两种可选，如果使用udp方式，那么应该将udp的lookback属性指定为true，因为windows上有一个叫做mediasense的东西会影响udpmulticast。注意如果你不了解multiaddress的ip规则，请不要随便修改mcast_addr的值。如果采用tcp方式的话，应该指定bind_addr的值为本机ip，并且在TCPPING标签的initial_hosts属性中列出所有节点，格式是”机器名端口号”，比如在我们的例子中，就应该这样配置tcp(以其中一个节点为例)：JBoss的clustering版主建议尽量使用udp。不过在Sobey内部，建议使用tcp方式，经测试可能有不明物体在影响udp通信，导致Timeout异常。在%jboss%serveralldeploycluster-service.xml中也有关于udp和tcp的配置信息，在4.0以前版本的jboss中，会以这个文件为主配置，4.0以后都以tc5-cluster-service.xml为主配置。Jboss的配置完成了，最后需要在web应用中增加配置信息，控制session复制的粒度。在WEB-INFjboss-web.xml中增加以下内容：SET_AND_NON_PRIMITIVE_GETSESSION其中replication-trigger是指定哪些操作引发session的版本更新，它的取值有：SET_AND_GETSET_AND_NON_PRIMITIVE_GETSETreplication-granularity是复制粒度，可以取session或attribute。如果取为attribute有可能导致复制失败，这是目前版本的jbosscache的一个bug，等待修正。部署项目，测试，如果配置没有问题，可以在%jboss%0serveralllogserver.log中发现类似于这样的信息：DEBUGorg.jboss.web.tomcat.tc5.session.JBossCacheManagerchecktoseeifneedstostoreandreplicatesessionwithidIm9-qpuaXppMS+xXwE3M+Q*.server1DEBUGorg.jboss.web.tomcat.tc5.session.ClusteredSessionprocessSessionRepl():sessionisdirty.Willincrementversionfrom:20andreplicate.Sessionreplication配置的成功率比较低，情况也很复杂，请仔细操作。五、分布式热部署(distributablehotdeploy)在一个节点很多的cluster中，如果部署应用的时候必须把程序文件拷贝到每个机器上的话，那实在太愚蠢了，幸好通过all启动的jboss自动支持分布式热部署。把支持cluster的应用（通常需要打包成war文件），放到%jboss%serverallfarm下，那么处于同一cluster中的其他节点会自动下载并且部署，jboss把这个称为Farmdeploy。如下图：jboss-4.0.2 Quick Startjboss-4.0.2 Quick Start一、基础1、下载jboss-4.0.22、安装将jboss-4.0.2.zip解压缩到一个目录下即可，配置操作的JAVA_HOME环境变量。3、启动启动命令：在%JBOSS_HOME%bin下，运行 run.bat -c default|minimal|all,默认使用default.JBoss架构是由JMX MBean服务器、微内核组成的。 JBoss有三种服务器配置： 1)Minimal：最小配置，仅仅包括日志，JNDI服务和URL部署扫描器，你可能会在一个不需要J2EE的应用中使用这种配置，或者以该配置为基础自定义配置。2)Default：缺省配置，包括除了RMI/IIOP和集群的所有J2EE服务。3)All：这种配置包括所有的JBoss服务。启动默认配置：运行jboss-4.0.2binrun.bat或者：jboss-4.0.2binrun.bat -c default4、关闭一般关闭很简单，直接Ctrl+C就可以关闭了，当然也可以从命令行关闭，这个选项较多： jboss-4.0.2binshutdown.bat usage: shutdown options options: -h, -helpShow this help message (default) -D=Set a system property -Stop processing options -s, -server=Specify the JNDI URL of the remote server -n, -serverName=Specify the JMX name of the ServerImpl -a, -adapter=Specify JNDI name of the MBeanServerConnection to use -u, -user= Specify the username for authentication -p, -password= Specify the password for authentication operations: -S, -shutdownShutdown the server -e, -exit= Force the VM to exit with a status code -H, -halt= Force the VM to halt with a status code 5、部署应用部署的目录：jboss-4.0.2serveralldeploy你可以把下列文件拷贝到此目录下：* 任何jar库（其中的类将被自动添加到JBoss的classpath中）* EJB JAR* WAR (Web Appliction aRrchive) 注意默认情况下context为war名称.* EAR (Enterprise Application aRchive)* 包含JBoss MBean定义的XML文件* 一个包含EJB JAR、WAR或者EAR的解压缩内容，并以.jar、.war或者.ear结尾的目录。 6、jboss-4.0.2的目录结构将二进制发布版解压到 jboss-4.0.2 目录。该目录包含如下 5个子目录： bin：含有启动、停止以及其他系统相关脚本。在前面，本书已经讨论过启动 JBoss应用服务器的 run 脚本。 client：存储供 Java 客户应用或者外部 Web 容器使用的配置文件和 JAR 文件。用户可以使用所需要的具体存档，或者仅仅使用 jbossall-client.jar。 docs：含有 JBoss 引用的XML DTD文件（当然，还包括 JBoss 具体配置文件） 。同时，还存在 JCA（Java Connetor Architecture，Java连接器架构）实例配置文件，供设置不同数据库的数据源使用（比如 MySQL、Oracle、Postgres）。 lib：包含运行 JBoss 微内核所需的 JAR 文件。请注意，不要往该目录添加用户自身的任何 JAR 文件。 server：包含的各个子目录都是不同的服务器配置。通过往run脚本后添加-c 参数便能够指定不同的配置。 server 目录下存在 3 个服务器实例配置：all、default 以及 minimal，它们各自提供了不同的服务集合。很显然，如果启动 JBoss服务器时没有指定其他配置，则将使用 default配置。各个配置的具体内容如下： serverminimal：这是启动 JBoss服务器所要求的最低配置。 minimal 配置将启动日志服务、JNDI 服务器以及 URL 部署扫描器，以找到待部署的（新）应用。对于那些不需要使用任何其他 J2EE 技术，而只是使用自义服务的场合而言，则这种 JMX/JBoss配置最适合。它仅仅是服务器，而不包含 Web容器、不提供 EJB 和 JMS 支持。serverdefault：默认配置，它含有大部分 J2EE应用所需的标准服务。但是，它不含有 JAXR服务、IIOP 服务、或者其他任何群集服务。 serverall：提供了所有可用的服务。它包含 RMI/IIOP和群集服务，default 配置中没有提供群集服务。 对于默认的配置目录文件夹，其作用如下：serverdefaultconf：含有指定 JBoss 核心服务的 jboss-service.xml 文件。同时，还包括核心服务的其他配置文件。 serverdefaultdata：这一目录存储持久化数据，即使服务器发生重启其中的数据也不会丢失。许多 JBoss 服务将数据存储在这里，比如 Hypersonic 数据库实例。 serverdefaultdeploy：用户将应用代码（JARWAREAR 文件）部署在此处。同时，deploy目录也用于热部署服务（即，那些能够从运行服务器动态添加或删除的服务）和部署JCA 资源适配器。因此，用户能够在 deploy 目录看到大量的配置文件。尤其是，用户能够看到 JMX 控制台应用（未打包的 WAR 文件），本书前面讨论过。JBoss服务器将定期扫描该目录，从而查找是否有组件更新或修改，从而自动完成组件的重新部署。本书后续章节将详细阐述部署细节。 serverdefaultlib：服务器配置所需的 JAR 文件。用户可以添加自身的库文件，比如 JDBC 驱动，等等。 serverdefaultlog：日志信息将存储到该目录。 JBoss 使用 Jakarta Log4j 包作为其日志功能。同时，用户可以在应用中直接使用 Log4j日志记录功能。 serverdefaulttmp：供部署器临时存储未打包应用使用，也可以作为其他用途。 serverdefaultwork：供 Tomcat 编译 JSP 使用。JBoss配置Mysql连接池对于jsp的web程序来说，配置连接池是必不可少的。JBoss配置MySql的连接池，可以查看官方文档，地址为：url/jbossas/getting_started/v4/html/db.html/url。我这里的配置分为以下几步：第一步：从jboss-4.0.2docsexamplesjca目录下的mysql-ds.xml复制文件到D:jboss-4.0.2serverdefaultdeploy目录下并编辑如下： MySqlDS jdbc:mysql:/localhost:3306/test com.mysql.jdbc.Driver root root org.jboss.resource