This topic has not yet been written. The content below is from the topic description.
Setting up mod_jk We will be doing the same example as we did with mod_proxy, except this time using mod_jk. mod_jk is only dependent on the mod_jk module to be loaded. However, the configuration requires more directives and files. The section below covers the changes needed to send requests to a clustered JBoss EAP instance with a weighted load balancer, leveraging sticky sessions (same as with mod_proxy exercise). Modifications to httpd.conf EWS ships with the mod_jk module but not explicitly included in the httpd.conf file. The first thing we will need to do is add the mod_jk module to be loaded. We do this by adding the following line at the end of the LoadModule block: LoadModule jk_module /var/local/httpd/modules/mod_jk.so Next, we need to define the location where our workers (application server instances that will respond to requests) are defined at. The common practice for this is to define this information in a file called workers.properties. We add this directive with the following: JkWorkersFile /var/local/httpd/conf/workers.properties Next we define the location of a shared memory file. This is used by the load balancer internal to mod_jk for knowing where requests are at and where to direct traffic. JkShmFile /var/local/httpd/mod_jk.shm Now we define where our logs for mod_jk should go be written at, what logging level we want (error, debug, info), and the format of the logs. JkLogFile /var/local/httpd/logs/mod_jk.log JkLogLevel info JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " Finally, similar to what we did with mod_proxy, we need to define which URLs are mapped over. We do this by defining the location for a URI mapping file (we look at the values of this file next). Since we only want this to affect one domain, we apply the following change inside our VirtualHost. JkMountFile /var/local/httpd/conf/uriworkermap.properties If we were to restart apache now, it would fail as the workers.properties file has not been created yet. Try it out, you should see something similar in the httpd log Before we fix this error, lets address our uriworkermap.properties file and then we will create our workers.properties file. The uriworkermap.properties file does not exist and you will need to create this file at the location you identified in the last step above. This file is very straightforward. We simply mount the servlet context that we want to be added as defined by a group (which we identify in workers.properties). Note that the servlet context will match the URL Apache HTTPD forwards over to JBoss. Here is the content of our uriworkermap.properties file: # Mount the Servlet context to the ajp13 worker /admin-console=examplebalancer /admin-console/*=examplebalancer Finally, we identify our application servers in our workers.properties file. Just like our uriworkermap.properties file, the workers.properties file does not exist and will need to be created at the location you defined in httpd.conf. The following exercise walks through creating a load balanced connection to 2 JBoss servers. The first item to create in our workers.properties file is the listing of workers that will be available. We do this by using the workers.list directive like the following (notice how it matches our uriworkermap.properties definition): worker.list=examplebalancer With our worker list defined, we now go about identifying the servers that will make up our load balanced group. For the rest of the configuration, you will notice that the pattern is ‘worker.’ + workerName + property where workerName is how we are identifying the worker. There are quite a few configurable values here. This example will walk through the most critical values to set. These include the hostname where the JBoss instance resides, the type of worker this is, what the communication port should be, the load balancer weight, and finally how mod_jk should check to ensure that the identified application server is up and responding (CPing). Lets look at the configuration: # Define Node1 # modify the host as your host IP or DNS name. worker.node1.port=8009 worker.node1.host=localhost worker.node1.type=ajp13 worker.node1.ping_mode=A worker.node1.lbfactor=1 In the example above, we are connecting to a JBoss instance on our local machine. We will be communicating using the ajp1.3 protocol, and JBoss is handling AJP on port 8009. We set a load balance factor of 1 (which makes more sense once we add our second node). Final, we set our ping_mode to A. This means that we want mod_jk to check all routes to verify that JBoss is up. This includes: Check once after the initial connection to JBoss Before each request is sent to JBoss At a regular interval (heartbeat) We set our second node (using the same parameters but updated for our second instance): # Define Node2 # modify the host as your host IP or DNS name. worker.node2.port=8109 worker.node2.host=localhost worker.node2.type=ajp13 worker.node2.ping_mode=A worker.node2.lbfactor=3 With our JBoss servers identified and configured, we wrap up the configuration by defining the loadbalancer aspects for the group and bind it to ‘examplebalancer’ which is what is defined in our uriworkermap.properties. In the following example, we define the type of this worker as a loadbalancer(remember, named example balancer), what workers make up this load balancer, and we enable sticky sessions. # Load-balancing behaviour worker.examplebalancer.type=lb worker.examplebalancer.balance_workers=node1,node2 worker.examplebalancer.sticky_session=1 Now that we have our uriworkermap.properties and worker.properties files defined, we restart Apache HTTPD and test it out. First thing we check after the restart is our mod_jk.log. The following shows us that the mappings have all lined up and the backend servers are found and available: Illustration 33: Verifying mod_jk is installed and configured through the mod_jk.log Any errors in here would tell us that a backend server isn’t available or that we possibly have a type in our configurations. And finally we verify that we can connect to our JBoss application server through Apache by testing through a browser over port 80: Illustration 34: Accessing JBoss through Apache HTTPD using mod_jk