Expected behavior of sticky connections and server failure.

[jason.nadeau]

I am using an ACE module in front of 4 Apache servers. We load balance the new clients requests round robin between those 4 servers. New client requests that are handled by one of the servers are assigned a JSESSION cookie which the ACE tracks to keep that user going to the same server, this establishes user session affinity. The cookie is good for 8 hours and the ACE is configured to keep affinity for 8 hours.

My question is if the user affinity stored in the ACE is discarded if a server is removed from the server pool because it failed probes.

My current guess it either: The ACE drops all user affinity records for a server if it fails the probes and is removed from the server pool, or the ACE will drop user affinity records for a failed server only if that client makes a request while the server is down. If the server returns to the server pool before a user makes another request the user affinity is kept.

Can anyone shed any light on the expected behavior?

[Christopher Miles · Accepted solution]

Hi Jason,

The default behaviour of the ACE is to "take a failed real server out of load-balancing rotation for new connections and to allow existing connections to complete".. If you wish to effect this default behaviour you can configure the failaction in the server farm..

see

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A2/configuration/slb/guide/rsfarms.html#wp999994

cheers,

Chris

[jason.nadeau]

Thanks Chris,

Just to be clear the ACE module by default will let existing connections finish. A connection is finished based upon the TCP FIN or RST flags being exchanged at the end of the current TCP session, not the expiration of the sticky table entry?

[Christopher Miles]

Jason,

Connections will be cleaned up if they hit the timeout value that has been configured unless the TCP session is torn down by way of a RST or a FIN first. If no fail action is configured then the connections would not be cleaned up until the timeout was hit, so basically a fail action will neatly clean any sessions up immediately. Any client that is then sending a SYN is effectively setting up a new connection that would be classified by whatever configuration rules you have assigned to that vserver and would be load balanced to another server in rotation if the failed server is been deemed unreachable.

[jason.nadeau]

Thanks again Chris. Invaluable explaination!