raito load balancing not working

When a connection comes to a virtual server where persistence has been enabled, the connection is first evaluated to determine if the LTM has a valid persistence record for that connection. If the LTM does not, then the connection is load-balanced according to the method chosen for the pool.

 

 

Thus, even though your pool members have a ratio of 2:1, assuming that some of your clients return within the persistence timeout, you will see that your actual ratio of connections is not 2:1. A couple of examples:

 

 

Example 1: three clients, two pool members, ratio of connections is 2:1 in favor of 1st pool member, no persistence enabled.

 

 

1st client makes connection, is load-balanced to 1st pool member.

 

2nd client makes connection, is load-balanced to 2nd pool member.

 

3rd client makes connection, is load-balanced to 1st pool member. (because of ratio)

 

 

You get a clear 2:1 ratio out of that and a repeating load-balancing pattern of 1-2-1.

 

 

Example 2: three clients (each of which is in a different /24 network), two pool members, ratio of connections is 2:1 in favor of 1st pool member, source address persistence and a /24 mask are configured.

 

 

1st client makes connection, is load-balanced to 1st pool member.

 

2nd client makes connection, is load-balanced to 2nd pool member.

 

3rd client makes connection, is load-balanced to 1st pool member. (because of ratio)

 

1st client makes connection, returns to 1st pool member (because of persistence)

 

3rd client makes connection, returns to 1st pool member (because of persistence)

 

 

Now the ratio looks more like 5:1, and this is caused by persistence behavior as expected.

 

 

I'm not sure it's worth it to try and prove this, but you could collect all of your web server logs, parse them to remove connections from clients that are returning to the same server within the persistence timeout period, then compare the count of remaining sessions. You would probably see something much closer to the ratio you configured on the pool.

 

hi Rob,

 

 

I can agree with the example above.

 

 

Anyway I was thinking that for long period of time (month) I can count client requests and amount of traffic that they produce an average value. And I was expecting to see that each server received a ratioed portion of this traffic. It is not possible that a new client hits persistent record of the previous client who used that IP.

 

 

Currently the observed from me behaviour is more like the first servers from the pool receive all "heavy" connections and next servers with different ratio receive all who are just checking a mail - "light" connections.

 

That's why I've rased this case.

 

 

Regards,

 

Todor

Posted By Trosho on 03/11/2011 10:23 AM

 

The order is not of big importance.

 

 

How the above can happen if we have persistent on source IP and time of IP address reassign is much grater than persist timeout

 

 

T

 

Chris is correct, that's how it works.. In your example you stated 3 different client IPs

 

 

 

Posted by Trosho on 03/10/2011 04:01 PM

 

 

3 different clients IPs.

 

1st client makes connection (TCP session) - 1st node. 1st. client makes second TCP session - again 1st node because of the persistence.

 

2nd client makes connection (TCP session) - 1st node (because of the ratio)

 

3th client opens TCP session - 2nd node

 

 

 

If that's the case, source address persistence doesn't come into play.. So yes the order does kinda matter in understanding ratios. Like Chris said, it's basically round robin until ever pool member has a connection, then it's starts it's ratio algorithm.