Original heavyweight: JBoss 4.0.2 cluster Guide

JBoss 4.0.2 cluster Guide

Bromon originality, please respect copyright

This article mainly describes the basic knowledge of JBoss cluster and simple configuration methods, and involves some supplementary knowledge of JBoss.

I. Material preparation:

1. JBoss 4.0.2

JBoss versions vary greatly. Even if the same version is JBoss 4.x, the internal component versions are inconsistent. Therefore, use the server of the same version whenever possible. It has been proved that the cluster versions can be configured mostly JBoss 3.2.6 and JBoss 4.0.2.

2. Apache 2.0.54

3. Apache mod_jk-1-2-13-apache-2-0-54

Ii. installation:

1. Install jboss4.0.2 and Apache 2.0.54 on your own. Assume that the installation directory of JBoss is % JBoss %, and that of Apache is % Apache %.

2. Install mod_jk.

Get the file mod_jk-1-2-13-apache-2-0-54.so from apache.org and copy it to % Apache %/modules.

3. Getting started with JBoss Cluster

JBoss supports the following types of clusters: EJB, web, JNDI, and JMS. We mainly know about Web Cluster.
The web cluster can be divided into two topics: load balancing and State synchronization. They are independent from each other and configured separately.

The concept of Server Load balancer is simple. What is important is the granularity of Server Load balancer. You can select a balance for each request or for each user. Select different granularities and different state synchronization modes are required.

1. Request-Based Load Balancing

In this way, the Load balancer distributes each HTTP request according to the status of each node. When using this balancing policy, you must copy the user's session between multiple nodes to synchronize the user status of the entire cluster in real time. This operation is called session replication ). The implementation principle of JBoss is to use Interceptor to intercept requests based on the user's synchronization policy, and then send the requests to the server for a response.

The advantage of this method is that the customer will not be bound to all specific nodes. As long as another node is alive, the user status will not be lost, and the cluster can continue to work. The disadvantage is that the nodes communicate frequently and the response speed is affected. When multiple concurrent and high-frequency operations are performed, the performance is greatly reduced.

2. User-Based Load Balancing

In this way, when the user sends the first request, the Server Load balancer dynamically allocates the user to a node and records the JVM route of the node, in the future, all requests of this user will be bound to this JVM route, and the user will only interact with this server. This policy is called sticky session ).

The advantage of this method is that the response speed is fast and there is no need to communicate between multiple nodes. The disadvantage is that when a node dies, all the users it is responsible for will lose the session.

Iv. Practice

1. Server Load balancer

Currently, JBoss has two load balancing solutions: Apache mod_jk and JBoss Load Balancing module. The two configurations are described below.

Mod_jk Configuration

1. Make sure that the mod_jk-1-2-13-apache-2-0-54.so file is already in % Apache %/modules.
2. Modify % Apache %/CONF/httpd. conf and add include CONF/mod_jk2.conf at the end of the file.
3. Create the file mod_jk2.conf in % Apache %/conf as follows:

# Load mod_jk module. Specify the filename
# Of the mod_jk lib you 've downloaded and
# Installed in the previous section
Loadmodule jk_module modules/mod_jk-1-2-13-apache-2-0-54.so
# Where to find workers. Properties
Jkworkersfile CONF/workers2.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 indicate to send SSL key size,
Jkoptions + forwardkeysize + forwarduricompat-forwarddirectories
# Jkrequestlogformat set the request format
Jkrequestlogformat "% w % v % t"
Jkmount/* loadbalancer

Jkmount/* loadbalancer indicates that all requests are sent to loadbalancer for processing. You can modify the URL to control the sending of certain requests.
4. Create the workers2.properties file under % Apache %/CONF. The content is as follows:

Worker. List = loadbalancer, server1, server2

# Define the first node...
Worker. server1.port = 8009
Worker. server1.host = 172.16.0.116
Worker. server1.type = ajp13
Worker. server1.lbfactor = 1
Worker. server1.local _ worker = 1
Worker. server1.cachesize = 10

# Define the first node...
Worker. server2.port = 8009
Worker. server2.host = 172.16.32.88
Worker. server2.type = ajp13
Worker. server2.lbfactor = 1
Worker. server2.local _ worker = 1
Worker. server2.cachesize = 10

# Now we define the load-balancing behaviour
Worker. loadbalancer. type = LB
Worker. loadbalancer. balanced_workers = server1, server2
Worker. loadbalancer. sticky_session = 1

The node naming rule is worker. node name. xxxx. Therefore, the preceding file defines two nodes: server1 and server2. Port 8009 is the default AJP port of JBoss. In addition, the parameter worker. server2.lbfactor is used as the node load weight. The larger the value, the larger the chance to obtain the load. It can be adjusted based on the hardware performance of the node. The worker. loadbalancer. sticky_session parameter specifies whether to use sticky sessions.

All nodes that require Server Load balancer must be listed in the parameter worker. loadbalancer. balanced_workers.

Remember the names of all nodes and their corresponding machines, which will be used in subsequent configuration.

Start Apache: % Apache/bin/apache.exe. Normally, there is no prompt. If you use JK 2.0, the configuration file is written differently. Since mod_jk2 has stopped development, Apache has not provided any explanation, there is no guidance for writing configuration files.

Configuration of JBoss built-in balancer

Folder % JBoss %/docs/examples/Varia/loadbalancer. SAR copies to % JBoss %/Server/All/deploy and modifies loadbalancer. SAR/loadbalancer. SAR/META-INF/jboss-service.xml, class out all nodes in the

The disadvantage of this balancer is that the load capacity is relatively low and there are too few configuration parameters. For example, the load weighting of different nodes cannot be specified, so the following uses mod_jk as an example, I will not explain the content of the Load balancer that comes with JBoss.
 

After configuring the Server Load balancer, start JBoss. All nodes in defaultpatition are listed during the process:
Run. Bat-C all

The shutdown and startup of any node will be broadcast in the cluster. For example, after a new node is added, the following prompt will be displayed for other nodes:

2. Session sticky Configuration

Apache should distribute requests in the form of sticky sessions. Deploy an application and test it. You will find that the sticky session does not work. Since JBoss has not been configured with jvmroute, Apache cannot know which sessions belong to which node. Let's continue:

Modify JBoss profile on server1 machine: % JBoss %/Server/All/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml

In row 110, <attribute name = "usejk"> false </attribute> is set to true. It is worth noting that there is a comment on this line of tag, which requires you to include:
Engine name = "JBoss. Web" jmvroute = "node1" defaulthost = "localhost"

Please note that there is a small bug that is not worth the candle. The official JBoss document has written jvmroute as jmvroute, which means that the reversal of the letters V and M has made me feel depressed for three days, I rummaged through jboss.com and theserverside.com. It was a direct copy error. Vomiting Blood and vomiting dehydration.

Below you need to modify % JBoss %/Server/All/deploy/jbossweb-tomcat55.sar/server. xml on server1, there are around 32 lines:

<Engine name = "JBoss. Web" defaulthost = "localhost">

Add a jvmroute attribute to it:

<Engine jvmroute = "server1" name = "JBoss. Web" defaulthost = "localhost">

Note that the value of jvmroute must correspond to the node name in mod_jk. Otherwise, the route cannot be correctly routed. All nodes in the cluster should be configured accordingly.

After JBoss is configured, modify the configuration file in your web application to support the cluster.

Add properties to WEB-INF/Web. xml: <distributable/>

OK. The cluster is based on the user. Each user is bound to a node for interaction. How is this binding completed? After Apache distributes the customer to a node, the node adds the route name of the node to the user's session ID:

Efdfxxd98daja87daj76da2dka **, server1

With this identifier, you can identify the node to which the session belongs.

3. session replication Configuration

The following is a request-based cluster that allows each node to copy the session status to each other. There are two replication modes: synchronous and asynchronous. In synchronous mode, JBoss puts the session replication operation and response to the request into an application transaction. After the session replication is complete, the request is processed. Asynchronous replication processes the request immediately after sending the message of the session replication, and the session replication will be slightly delayed. However, in the web pages with multiple frameworks, this cluster method may be faulty. Frame sends multiple requests at the same time, which may cause some confusion. This is also one of the reasons for using the user-based cluster method.

JBoss cache is used in JBoss 4.0.2 to implement session replication. In fact, it is a distributed cache. Because the session ID contains JVM route, you can determine which node the session belongs. The update of the session is similar to the optimistic lock in hibernate. After the update, the version number of the session is increased. Other nodes determine whether to synchronize the session status by comparing the version number.

Edit session replication first
% JBoss % server/All/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml, 88 rows left and right are:
<Attribute name = "snapshotmode"> instant </attribute>
This is the replication mode just mentioned. The instant is instant replication. If it is set to interval, the system will perform replication after a delay of some time, the length is specified in <attribute name = "snapshotinterval"> 2000 </attribute>, in milliseconds.

It is not enough to configure this place separately, in % JBoss % server/All/deploy/tc5-cluster-service.xml there are:

<Attribute name = "cachemode"> repl_async </attribute>

It is determined whether the replication is synchronous or asynchronous. You can specify it as repl_async (asynchronous) or repl_sync (synchronous ).

Under this file, there is also a Config tag that specifies how each node communicates during session replication. There are two Optional options: UDP and TCP. If UDP is used, set the lookback attribute of UDP to true, because there is something called media sense on Windows that affects UDP multicast. Note: If you do not know the IP address rules of Multi address, do not modify the value of mcast_addr. If the TCP mode is used, specify the bind_addr value as the local IP address and list all nodes in the initial_hosts attribute of the tcpping label. The format is "machine name [port number]". for example, in our example, we should configure TCP as follows (take one of the nodes as an example ):

<Config>
<TCP bind_addr = "172.16.0.116" start_port = "7810" loopback = "true"/>
<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"/>
<Merge2 min_interval = "5000" max_interval = "10000"/>
<FD shun = "true" timeout = "2500" max_tries = "5" 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>

We recommend that you use UDP whenever possible for the clustering Moderator of JBoss. However, in sobey, TCP is recommended. Some unknown objects may affect UDP communication, resulting in a timeout exception.

UDP and TCP configuration information is also available in % JBoss %/Server/All/deploy/cluster-service.xml. in JBoss versions earlier than 4.0, this file is the main configuration, 4.0 after the tc5-cluster-service.xml as the main configuration.

After JBoss is configured, add configuration information to the Web application to control the session replication granularity. Add the following to the WEB-INF/jboss-web.xml:

<Replication-config>
<Replication-trigger> set_and_non_primitive_get </replication-trigger>
<Replication-granularity> session </replication-granularity>
</Replication-config>

Among them, replication-trigger specifies which operations will trigger session version updates. Its values include:

Set_and_get
Set_and_non_primitive_get
Set

Replication-granularity is the replication granularity and can be set to session or attribute. If attribute is set, the replication may fail. This is a bug in the current JBoss cache and is waiting for correction.

Deploy the project and test it. If the configuration is correct, you can find information similar to this in % JBoss %/0 server/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.

The success rate of session replication configuration is relatively low, and the situation is complicated. Please perform the operation carefully.

5. distributed hot deployment)

In a cluster with many nodes, it would be too stupid to copy the program file to every machine when deploying the application, fortunately, JBoss started with all automatically supports distributed hot deployment. Put the application supporting cluster (usually packaged as a war file) under % JBoss %/Server/All/farm, other nodes in the same cluster will be automatically downloaded and deployed, JBoss calls this farm deploy. For example:

End 2005-7-11 released by bromon