Forum Discussion
Chris_Phillips
Feb 07, 2011Nimbostratus
Thanks for these, not sure how I didn't see that first link. I'm a bit confused about that link though, as it does not use any formal persistence. Whilst I can see that the existence of the cookie is still there, and I guess is just more "visible" than a more muted "persist cookie" and letting it do it under the covers, I don't think I'd want to have to be going through iRules once a connection is under way. I'm looking to use this in a number of scenarios, at one end 5 identical pools which our test analysts would always need to pick a pool manually somehow, and at the other a production service where we'd want very close control over which source IP's (maybe..) can specify a pool so the great unwashed couldn't exploit it.
I think a query string makes more sense than a uri change, as then I don't need to change the uri at all, and I can certainly see a combination of those two and some basic tests I've already written, but I'd really appreciate some clarity about how much meddling there would be once we are being load balanced. The less the better. I guess I can just use the cookie. In your example their Matt, you say to use an insert cookie persist on the VS, yet there's a persist in the rule. Do these work together, or override one another? I can certainly see how simple your example is there to get the hell out of the way and let normal persistence do it's thing when the uri is "normal" though, that's certainly good to see.
I'm also somehow going to need a solution, maybe this one, to deal with appliances (games consoles and set top boxes) as well as web users. Hopefully I can use a uri / query modification as their starting point, but we'll see. Might need to do something on the back end instead using data groups... Anyone know if an xbox 360 posts consistently unique additional http headers per device? No? Ho hum...
Thanks