Cookie persistence: URL or Domain: which is optimized for LB management?

default cookie.

any other views?

Okay, I'll take a stab at this. First, doing persistence with a custom domain cookie iRule is definitely a good way to go, and probably the simplest approach I think.

Alternatively, you could do a URL rewrite thing so that all access to these other apps is forced through the single app VIP. I'd say the code to do this would only be slightly more complex than the custom domain cookie iRule, but then you wouldn't have to worry about persistence.

would a domain cookie irule disturb the load balancing method?

Yes it would. The first request will come in without a persistence token and will get one in that first response. The second and subsequent requests will all send back that persistence cookie and no new load balancing will occur. In fact, the load balancing method you choose is completely independent of the persistence method.

is this really critical? does this mean trading off the load balancing functionnality for consistent user experience? Of course forcing a user to stay on the same server does not mean that all new users will ne forced to come to this server. load balancing still applies for new users. I'm just trying to see it this will not go critical at some point of use especially in high usage scenarios.

I think it basically boils down to this: if you need all of the requests from a single user to go to the same server that is hosting multiple applications, then you need a persistence mechanism that can provide that, and the load balancing algorithm only comes into play on the FIRST request.

That said, if one application on one of the servers fails, but doesn't affect the other applications? Is that a problem? Do you really need to stick the user to the same node for all applications?

if one application fails the user interface is impacted in that only one portion of the application is available. that's why sticking the user to the same server makes sense. If the server is not working as expected the whole application will be down and this can be explained and managed better than half of the app is working because the app is split on three servers and you need to know which one is not working worrectly.

Yes, but if you separate the applications into different pools with different monitors, so that if one application fails on a server, it doesn't necessarily affect the services provided by the others, you may get better scale. If you take an entire node out of production because one of the three services has failed, that seems less efficient. The only caveat is whether or not one application is dependent on another application ON THE SAME server (ie. local tokens, memory space, etc.).