Configure JBoss for mod_cluster
This topic has not yet been written. The content below is from the topic description.
Setting up JBoss for mod_cluster In the following steps, we will be making the necessary changes to a JBoss instance to make mod_cluster aware of it and vice versa. Only one server is shown, for subsequent instances, the changes are the same. First copy the mod_cluster.sar file from the earlier download to the ‘deploy’ directory of your JBoss instance. In the example below, an instance named ‘node1’ was created so we are copying mod_cluster.sar to Jboss_HOME/jboss_as/server/node1/deploy. This application is what will do the communication with Apache HTTPD. Illustration 36: Installing mod_cluster application into JBoss EAP Now that we have the application installed, we need to do some configuration. The first configuration we will do is located at mod_cluster.sar/META-INF/mod_cluster-jboss-beans.xml. In this file we will be completing the information for the location to where mod_cluster is running (the VirtualHost we set up in httpd.conf a few steps back). We will also add some domain information. Edit this file, and add the following to achieve this (changes highlighted): Illustration 37: Changes to mod_cluster-jboss-beans.xml located at mod_cluster.sar/META-INF Save your changes and close this file. The next file we need to modify is located at node1/deploy/jbossweb.sar/server.xml In this file, we need to make 2 changes. The first change is to add another listener to our web instance. This will make our mod_cluster service initialized when JBoss starts up. Your change will look like the highlighted area below: Illustration 38: Modifications to /deploy/jbossweb.sar/server.xml And the second change we need to add is a jvmRoute. This is needed for identifying the server to apache and mod_cluster for load balancing as well as for sticky sessions. Illustration 39: Adding jvmRoute to same server.xml file as in Illustration 38 Note that we are defining the jvmRoute as jboss.jvmRoute. This flags it as a dynamic property and we will be passing in during server startup. Save and close this file. The final file we need to modify is located at node1/deploy/jbossweb.sar/META-INF/jboss-beans.xml. In this file, we need to let jbossweb know that our webserver is dependent upon the HAModClusterService bean that is defined in our mod_cluster.sar (defined for us). Your changes to this file will look like the following: Illustration 40: Modifying /deploy/jbossweb.sar/META-INF/jboss-beans.xml. Save this file and close it. With that all of our changes are complete. To reiterate – while there were 3 files we needed to modify and the changes seemed maybe not the most intuitive, the best practice is to make these changes once and then just copy the JBoss instance around as a foundation for other instances. With that approach, the only time you would need to modify any fields is if the HTTPD server configuration needed to change because the JBoss instance would have a new / different HTTPD front-ending it. To add a second instance to the JBoss cluster, just copy the ‘node1’ directory recursively to a new directory, say name 2. Add more instances in the same manner. With all of our changes complete, we start up our JBoss instance: Illustration 41: Starting up our JBoss EAP instance The majority of the parameters above are covered in more detail in the TODO CLUSTERING JBOSS & CONFIGURING JBOSS whitepapers. The only items we interacted with in this example are the last 2 parameters – the domain and the jvmRoute. For sake of seeing a cluster in action, here is the same command, just starting a second JBoss instance (will come in handy when we look at mod_cluster-manager). DO NOT START UP YOUR SECOND INSTANCE JUST YET!: Illustration 42: Starting up our second JBoss EAP instance If Apache HTTPD is not up and running, be sure to start it up now. To verify that mod_cluster in Apache has discovered your JBoss instance (node1), point your browser to domain/mod_cluster-manager. You should see the following: Illustration 43: Verifying mod_cluster using mod_cluster-manager – http://127.0.0.1/mod_cluster-manager. Note only one server is visible as we haven’t started our second instance yet. Now start up your second instance of JBoss. Once it is up, you will see in mod_cluster-manager that mod_cluster has discovered your new instance: Illustration 44: Mod_cluster-manager after our second JBoss EAP instance was started. Note that no change to apache was needed At this point, we have verified that mod_cluster knows about our JBoss instances. What about the applications? We never defined them in httpd.conf...but we can see them in the mod_cluster-manager console. In your browser, now simply point to that context in your domain – in our example we are using localhost: Illustration 45: Accessing an application through Apache HTTPD setup with mod_cluster. Note that applications were never identified explicitly to Apache HTTPD like we have to do with mod_jk From this you can see that our apache web server is now sending these requests down to our application servers. As we add new applications or even new application servers to our environment, we don’t need to make any changes to our webserver – mod_cluster discovers all of this. To wrap up this section, we went through the 3 main ways of connecting Apache HTTPD to our JBoss instances – using mod_proxy, mod_jk, and mod_cluster. The recommended approach is using mod_cluster as it is the most robust solution, providing better user experiences and ease of environment management.