14 posts categorized "loadbalancing"


DevCentral: Comprehensive Article on BigIP Load-Balancing Algorithms

Everything you ever wanted to know about load-balancing algorithms on the BigIP is summed up very nicely in this article on DevCentral


New HOWTO Article on Setting Up JSessionID Persistence on a BigIP

This Howto was recently updated. Please see this post for more information.

This article serves more as a reminder for me than anything else, since I'm always forgetting the last step.  However, if it serves useful to anyone else out there...great!  

One of the first things I wanted to tackle when we got our spiffy new BigIPs in several years ago was persisting user sessions to tomcat or jboss application servers using iRules.  There are lots of examples of persisting traffic based on JSESSIONID, ASPSESSIONID, etc., but one thing that the budding application traffic manager may not necessarily realize from browsing CodeShare on F5's DevCentral site (login required) is that you don't (always) simply code an irule and attach it to your VIP.  There are a couple steps necessary and this new HOWTO article outlines those steps.

Go to HOWTO: Set Up JSESSIONID-Based Persistence on a BigIP now.


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.