{"id":443,"date":"2012-06-22T12:38:27","date_gmt":"2012-06-22T04:38:27","guid":{"rendered":"http:\/\/rmohan.com\/?p=443"},"modified":"2012-06-22T12:45:18","modified_gmt":"2012-06-22T04:45:18","slug":"setting-up-clustering-on-apachejboss-using-jakarta-mod_jk","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=443","title":{"rendered":"Setting up Clustering on Apache\/Jboss\/Tomcat using Jakarta mod_jk"},"content":{"rendered":"
\n

Clustering Jboss for two reasons\u00a0 load balancing and failover.<\/p>\n<\/div>\n

Fail-over<\/h3>\n
\n

Fail-over is probably the most important issue for web applications. If the front end load balancer detects that one of the nodes has gone down it will redirect all the traffic to the second instance and your clients, apart from any on the failed node, won\u2019t even notice. Well that\u2019s the theory \u2013 if the site is under high load you may find that the surviving Tomcat cannot cope with the increased load and fails in short order. You need to size and correctly configure your hardware and software.<\/p>\n

You can also manually fail-over a system to upgrade the hardware, JVM or other application without end users being aware. If your management doesn\u2019t tolerate any downtime this is an extremely important feature. Your JVM\u2019s can be installed on separate or the same physical host. The latter leaves you exposed to hardware problems.<\/p>\n<\/div>\n

Load-balancing<\/h2>\n
\n

There are two easy ways to increase application performance without tuning the application software itself. Buy faster hardware or add more hardware. If you add a second server running Jboss you can use load balancing to distribute the work between the two servers. Requests come in to the Apache front end, static content is served directly by Apache and any dynamic requests forwarded to the Tomcats based on some algorithm. The Apache Jakarta mod_jk<\/em> connector is the most popular way of doing this.<\/p>\n

In this exercise we will configure two physical computers each running one Apache web server and two tomcats for both failover and load balancing. The example ignores any back-end data storage considerations but will discuss load balancing between the two computers.<\/p>\n<\/div>\n

<\/a>Front End Load Balancing<\/h2>\n
<\/div>\n

DNS Round Robin<\/h3>\n
\n

The simplest technique for load balancing between the two Apache front end servers is the DNS Round Robin<\/a> strategy. This performs load balancing by returning a different server IP address each time a (DNS<\/acronym>) name server is queried by a client. It is usually found as front-end service on large clusters of servers to provide a server address that is geographically close to the client. Normally an intelligent name server such as lbnamed<\/em> is used. This will poll the web servers in the list to check if they are online and not overloaded.<\/p>\n

DNS<\/acronym> Load balancing has some significant drawbacks. Addresses may be cached by clients and local DNS<\/acronym> resolvers and it can be hard to accurately manage load. The system simply shuffles the order of the address records each time the name server is queried. No account is taken of real server load or network congestion.<\/p>\n<\/div>\n

<\/a>Load Balanced<\/h3>\n
\n

The advantage of using a load balancer compared to using round robin DNS<\/acronym> is that it takes care of the load on the web server nodes and will direct requests to the node with the least load. It can also remove failed nodes from the list. Some round robin DNS<\/acronym> software can do this, the problem is they have little control about how client\u2019s cache IP addresses.<\/p>\n

Many web applications (e.g. forum software, shopping carts, etc.) make use of sessions. If you are in a session on Apache node 1, you would lose that session if suddenly node 2 served your requests. This assumes that the web servers don\u2019t share their session data, say via a database.<\/p>\n

For DNS<\/acronym> load balancing this is not a problem, the IP address will resolve to a single server. However a front end load balancer must be aware of sessions and always redirect requests from the same user to the same backend server.<\/p>\n

There are a number of packages to support front end load balancing. For example RedHat Piranha<\/em> or Ultramonkey<\/em>. There are also hardware\/firmware solutions from companies such as Cisco.<\/strong><\/p>\n

 <\/p>\n

Apache httpd<\/h2>\n
<\/div>\n

MaxClients<\/h2>\n
\n

MaxClients limits the maximum simultaneous connections that Apache can serve. This value should be tuned carefully based on the amount of memory available on the system.<\/p>\n

MaxClients ? (RAM - size_all_other_processes)\/(size_apache_process(es))<\/pre>\n
If Apache is using the PreFork MPM<\/strong> a separate Apache process will be created for each connection, so the total number of processes will be MaxClients + 1. Each process will have a single connection the mod_jk pool to talk to a Jboss instance. The Worker MPM<\/strong> module uses the thread model to handle client requests and should be slightly more efficient.<\/p>\n
As a guide Apache MaxClients<\/strong> and the number of available jboss threads configured in server.xml<\/em> should be equal. Mod_jk maintains persistent connections between Apache and jboss. If the Apache front end accepts more users than jboss can handle you will see connection errors. In a clustered environment we have to take account of errors the load balancer makes when it tracks the number of concurrent threads to the Tomcat back-ends so the following formula is a starting point:<\/p>\n
Apache.MaxClients = 0.8 * (Tomcat-1.maxThreads + \u2026 Tomcat-n.maxThreads)<\/pre>\n
i.e.<\/p>\n
400 = 0.8 * (250 + 250)<\/pre>\n
Use:<\/p>\n