Blogging Techstacks

Updated Howto: Setting up BigIP for JSESSIONID-Based Persistence

I updated the HOWTO: Set Up JSessionID-Based Persistence on a BigIP article recently to reflect some additional changes/discoveries made while running this in a production environment for a while.  The howto covers migrating off of apache/mod_jk to apache/mod_proxy and moving persistence based on jsessionid to a bigip ltm.  

If you are a developer reading this and wondering why in the world anyone would want to move away from mod_jk, the rationale behind the migration is pretty straightforward:  When you have more than a couple web servers front-ending your tomcat, glassfish, or jboss application servers, or even if you only have a couple of web servers but a lot of workers defined within your workers.properties files, disabling servers using the jk-status handler page can be a real hassle.  Training 1st or 2nd level support personnel within your network operations center on disabling servers in a bigip is much easier than showing them how to disable workers within a jk-status page. 

In addition, the BigIP enables the DevOp or Application Delivery Engineer to create more sophisticated health checks to assess app server health over mod_jk's cping/cpong.  A well written health monitor on the bigip is much better able to assess if an app server is hung than mod_jk's health checks at present.  A BigIP health check can assess almost instantly when a java application server is hung where requests using the traditional mod_jk approach must wait until the ajp backlog threshold has been reached, which could result in a lot of request hitting a hung application server unnecessarily.

Changes to the document include information on why oneconnect is necessary as well as mod_proxy-specific environment variables that should be set in order to avoid 502-Proxy Errors showing up in your apache error log during periods of low site activity.

load-balancing with mod_jk or mod_proxy: lbfactor

10 years ago, when Cisco Local Directors were all the rage, a node could be assigned a 'weight', which meant that if you had one node that was faster then another node, you could assign the faster node more traffic.

"server weights" became subjective and it would not be unusual to see some pretty interesting values. For example, some node pairs had weights of 1 and 2, some pairs had weights of 50 and 100, Server weights essentially means how much traffic one server should get in relation to other servers within a particular load-balanced cluster, pool, VIP, whatever vernacular your load-balanced vendor uses to describe a set of load-balanced servers. Network administrators would often set weights as if they were percentages, for example, setting a weight of 25 to one node and 75 to another node thinking that it always needed to total 100 and they would scratch their heads trying to calculate what the new percentages should be set to in the event a third server was added so that everything always equaled 100. Although the math often adds up correctly, this is not the correct way to think about setting weights. Weights are relative to the node in the cluster with the lowest value, so if you have three equally weighted servers, their weights should be 1, 1, and 1 each. Their weights could be set to 900, 900, and 900 each--it doesn't really matter because all values are equal and will normalize to 1, 1, and 1. If you have two servers and you want twice as much traffic to go to one server, you could set a weight of 1 and 2. If you then add an even more powerful server that is twice as fast as the second server, you could set a weight of 1, 2, and 4. If you then replace the first server with a new box that is the same type as the third box you added, you would then need to adjust your weights again to 4, 2, and 4 (or 2, 1, and 2--they mean the same thing).

In the mod_proxy and mod_jk world, server weights are set by a configuration directive called 'lbfactor' but the idea is the same. In an example cluster, if you have three servers and one of them is twice as fast as the other two, then you could assign an lbfactor of 2 to the faster box while setting the lbfactor to 1 on the other two servers. The behavior of this could lead to unexpected results based upon the lbmethod that has been chosen however and it is important to let your developers know that just because you have one server that has an lbfactor of 1 and another that has an lbfactor of 2, you won't necessarily see twice as much memory, cpu, or disk utilization on the server with the lbfactor set to 2.

If your lbmethod is "byrequests" and you have two servers and one has an lbfactor of 1 and the other has an lbfactor of 2, then your second server, on average, will receive twice as many network packets as your first server. If your lbmethod is "bytraffic" then your second server will receive twice as many bytes as your first server. This does not mean that your second server will receive twice the load--only twice the amount of network I/O. If your lbmethod is "bysessions", then you should expect to see twice as many user sessions on the one server, again--on average, then you will on the other. This last method should really be tested further by me to verify that that is in fact the behavior.

The other important thing to keep in mind is that mod_jk on one web server (or mod_proxy) is not really cognizant of a mod_jk implementation on another web server. Weights are only calculated for that cluster for that particular web server so if you aren't careful in setting your configurations up, you could have one web server's mod_jk sending traffic using equal lbfactors while another web server sends traffic using weighted lbfactors.

Apache-like Updates on the way for IIS

IIS 7 finally on par with apache 1.3! Okay, this sounds a bit facetious but two add-on features that Microsoft is introducing provide mod_proxy-style support and mod_rewrite support within IIS. The Microsoft URL Rewrite Module for IIS 7, which is in Community Technology Preview status provides mod_rewrite functionality in IIS. The Microsoft Application Request Routing for IIS 7 module provides mod_proxy-like functionality to IIS. Add this to the FastCGI support that was released back in March and it looks like Microsoft is finally trying to compete with Apache head-on. Heck, the URL Rewrite module even has an importer for mod_rewrite rules.

One thing that the Application Request Router provides, which appeals to the sysadmin/ops guy in me, that mod_proxy does not do is that you can configure health checks to monitor your back-end servers. This is one of the things presently lacking in mod_jk and mod_proxy. They certainly perform ping tests to make sure that the back-end system is up and running but they can't really tell if a back-end jvm is hung or if there is some other problem preventing the app server from serving up content correctly. Obviously, since I haven't played with it, I'm just reading a feature in a bulleted list of features so this could very well not work as I envision.  I'll have to play with it a little to see but it certainly could serve as a replacement for the IIS JK Redirector that the ASF provides for IIS.


Microsoft IIS 7 Implementation and Administration (Mastering)