Best Way to do Cookie Persistence here?

Posted By hoolio on 04/28/2010 09:52 AM

 

I haven't read through and fully understood the example you provided, but I can see at least one issue with the overall scenario. I don't think you'll be able to use LTM's least connections load balancing algorithm, as it sounds like you want to logically combine the connection counts for clusters of three servers.

 

 

You could try to manually track the connections to each "cluster" of three servers yourself. If you did that, you could track which of the clusters had the lowest connection count and select that cluster to handle the request. Once a cluster had been selected you could select the server with the lowest connection count. For persistence, you could track which cluster was selected and set a cookie based on that. You'd want to skip the cluster/server selection in subsequent requests if the client presented a valid persistence cookie.

 

 

If that seems doable, could you confirm which LTM version you're running? Also, is there any simple way you can think of to correlate the servers in a "cluster"? Can you come up with a IP addressing scheme that would make it simple to identify the servers in cluster 1 versus cluster 2, etc? If so and you're running 10.x, you could add all of the servers to a single pool and then use the members or active_members command to get a list of the pool members.

 

 

You could then use an array or list of lists to store the connection count info for each cluster and cluster members. If you use lists, you could use lsort -integer -index X to get the cluster and cluster member with the lowest connection count.

 

 

If you can't use a correlation between the IP addresses and cluster members, you'd probably need to use a difficult to maintain configuration using datagroups with the cluster memberships and update that each time the cluster members change.

 

 

Aaron

 

 

Hoolio - I'm currently using IP schemes to identify servers in each. For instance, 1.1.1.1-1.1.1.3 would be pool 1, 1.1.1.4-1.1.1.6 would be pool 2, etc...I'm doing that with data groups today. Good point on Least Connections...am running 10.1. I'm not too concerned with which node in the pool/cluster has the most connections since all 3 share the same backend resources. I'm very interested in sending to the "pool" with least connections. So, yes, I'd want to track the connections to the 3 nodes in each cluster and make my initial selection based on that.