Load balancing example cases

An application is deployed on 3 application servers with identical performance parameters: B1, B2, B3. In order to achieve an equal distribution of all sessions over those three servers, the weight fields of all three servers must contain identical values:

Weight B1: 100 (33%)
Weight B2: 100 (33%)
Weight B3: 100 (33%)

New sessions going to this back-end group will be randomly assigned to one of these three back-end hosts, which results in equal distribution in the long run.

An application runs on two servers: B1, a very powerful, high-end machine, and B2, a legacy system with limited performance, only about 1/3 of B1's. Usage demands exceed what B1 alone could handle, but are within what B1 and B2 combined can deal with. The sessions should therefore be distributed over both B1 and B2, but with fewer sessions going to B2:

Weight B1: 300 (75%)
Weight B2: 100 (25%)

New sessions going to this back-end group will be randomly assigned to either B1 or B2, but three times more likely to B1 than to B2. In the long run, this results in a distribution of 3:1 between B1 and B2.

An application runs on two servers, B1 and B2. B1 is fully capable of dealing with all the expected traffic. B2 is used as a failover system, to take over in case of B1 experiencing any kind of problems. In order to achieve this, use the following settings:

B1: Spare = no, Weight = 100 (100%)
B2: Spare = yes

All incoming traffic is now sent to B1. Health Checks monitor B1. Assume that at one point, B1 is set to "Bad" due to too many requests failing. Airlock Gateway now looks for any back-end hosts in the same back-end group which are marked as "spare". The first one found, in our case B2, is now assigned B1's weight (100). Since B1 is set to "Bad", it does not receive any traffic any more. Instead, all traffic goes now to B2.

Once B1 comes back online, new sessions will once again go to B1, but all existing sessions will remain on B2, minimizing the impact on the application users.

An application is deployed on 5 application servers with identical performance parameters: B1 through B5. In general, three of them are sufficient to deal with the expected traffic, the remain two should be used as back-up systems in case one or more systems fail:

B1: Spare = no, Weight = 100 (33%)
B2: Spare = no, Weight = 100 (33%)
B3: Spare = no, Weight = 100 (33%)
B4: Spare = yes
B5: Spare = yes

New sessions going to this back-end group will be randomly assigned to either B1, B2 or B3, resulting in equal distribution over these three systems in the long run. Now assume that at one point, B2 fails several Health Checks and is therefore set to "Bad": It will not receive any further traffic. Airlock Gateway now looks for any back-end hosts in the same back-end group which are marked as "Spare". The first one found, in our case B4, is now assigned B2's weight (100), and receives 1/3 of the new sessions. Again, in the long run, traffic will be equally distributed over B1, B3 and B4.

Now, assume that at a later point, B4 also has problems, fails several Health Checks, and is set to "Bad": The next spare server to be found is B5, which now receives the weight 100, and therefore 1/3 of the new sessions.

Later still, B2 comes back on line. It still carries its weight (100). B5's weight will be set to 0, it still serves its existing sessions, but does not receive any new ones. Again, 1/3 of all new sessions go to B2, which eventually will carry once again 1/3 of the overall traffic load.

Once the problems on B4 are fixed, and it is back on line, it will once again serve as a spare, to be activated the next time one of the three productive systems (B1, B2 or B3) fails.