Vip target VIP

Posted By deb on 07/22/2008 12:07 PM

 

This may be simpler & more efficient approach, esp if the default pool idea is working well and you'd like to support it still:

 

If you use 2 cookies - one for pod choice and one for LTM persistence, you can let LTM built in persistence options do the heavy lifting re:persistence mgmt, and use your existing rule logic to set the pod cookie. To enforce persistence across multiple pools, apply a persistence profile with a custom cookie name. That way the system will look for or insert the same cookie name in the default pool and the pod-specific pool...

 

That way you'd avoid the overhead of having to parse both values from the same cookie, and of building & managing the persistence cookie.

 

HTH

 

/deb

 

 

So we actually don't want member persistence, but rather pod/pool persistence. All pool members in a pod are session aware, and we would like to make sure we load balance across these servers as equally as possible. We are not using any persistence profile on the VIP, all persistence is in the iRule above via the "pod" cookie. With that said, do you see any pitfalls or trouble with that design? Thanks, again, in advance...

 

 

--brice