Forum Discussion
AltostratusPersistence
OK, I'm not new here, but I've a few newbie questions unfortunately!
I've just been taking a very close look at all the persistence methods available for the first time really. I've nearly always used source or Cookie in the real world. What I'm confused about are the 'destination' methods, not Destination Address itself but others like; Universal, Hash and anything related to CARP.
So, source related methods like Cookie ensure multiple requests from the same client go to the same Pool Member. 1) With destination methods, the idea is to ensure the same request from multiple clients goes to the same Pool Member? 2) Presumably if that's the case then these methods are not suitable for applications that require session state?
3) Moving onto the Universal method, assuming I'm correct regarding 1) and 2) this uses the iRule specified data to create the persistence (record) and any client information is ignored (unless it's part of that iRule specified data)? Any requests from other clients that hold the same data go to the same Pool Member, if there's no existing persistent record, normal LB'ing occurs.
4) Moving onto Hash, it look similar but it's a hash value, not the actual data? 5) Are persistence records created? 6) If so, I assume normal LB'ing occurs once and the record is created? This is where I get really stuck. 7) Things like CARP seem to be selecting a Pool Member so does 'normal' load balancing never occur?
Thanks in advance.
6 Replies
- nitass
Employee
1) With destination methods, the idea is to ensure the same request from multiple clients goes to the same Pool Member? 2) Presumably if that's the case then these methods are not suitable for applications that require session state?i think it is considered "destination" method. i understand it is just another persistence method which uses any arbitrary data. 
What_Lies_Bene1Cirrostratus
Thanks as ever Nitass. Anyone else have any answers to my other queries?
natheCirrocumulus
3) Moving onto the Universal method, assuming I'm correct regarding 1) and 2) this uses the iRule specified data to create the persistence (record) and any client information is ignored (unless it's part of that iRule specified data)? Any requests from other clients that hold the same data go to the same Pool Member, if there's no existing persistent record, normal LB'ing occurs.
Hi Steve, like yourself I've only ever used Src and Cookies. Re Universal persistence, I have come across that once but it didn't eventually fit our purpose. However, that's exactly as I understand it. Examples where I've seen it is to persist based on a string in a URI or a header. All clients with the same bit of data queried for will go to the same pool member.
N- What_Lies_Bene1Thanks Nathan, glad it's not just me!
- natheSteve,
4) Moving onto Hash, it look similar but it's a hash value, not the actual data? 5) Are persistence records created? 6) If so, I assume normal LB'ing occurs once and the record is created?
You've got me interested in Hash Persistence (as I've never used it). If the difference between Universal Persistence and Hash Persistence is that Hash Persistence is the hash of the data, rather than the data itself, then why use it? Presumably it puts more processing pressure on the LTM? There must be other differences that are key I imagine. Must delve deeper on this....
Anyway, I've tested in my lab and it does create a persistence record and I presume no.6 is true.
N - What_Lies_Bene1It seems CARP is a stateless Hash hence I thought perhaps Hash didn't create records, thanks for testing that. Minimising memory usage (by persistence records) seems to be the main driver of hash but it seems it's flexible enough to do more with some math. See here: https://devcentral.f5.com/tech-tips/articles/hash-load-balancing-and-persistence-on-big-ip-ltm/. It's still not clear to me how it works though, when using Election or CARP.
