Forum Discussion
NimbostratusQuestion about persistence with different pools
Looking for confirmation regarding a scenario with persistence along with an irule that directs traffic to different pools behind a single VS.
Here's the setup -
-
One VS with two pools (each pool is made up of different servers running different versions of app)
- pool A - default pool
- pool B - special pool
- VS has OneConnect and cookie persistence profile applied with default cookie name and http profile encrypting cookie
- VS has irule that checks for a specific http cookie which determines which of the two pools user goes to
Scenario -
-
User accesses app at login page (traffic goes to default pool A)
- at this point the encrypted persistence cookie is inserted tying the user to a server in pool A
- user logs in to app and based on user attributes app inserts cookie
-
user now has app cookie as well as the persistence cookie (pool A)
- next request - iRule in place looks for app cookie and if exists sends requests to pool B
- from fiddler captures I can see that the F5 now inserts a second persistence cookie for pool B
My question is what happens now? I believe the iRule is processed first so the user will go to pool B based on the app cookie matching the iRule but what about the persistence? Does the F5 know to use the right cookie depending upon which pool the traffic gets sent to?
Also what if the we used a custom cookie name for the persistence cookie? Would that impact the persitence when switching pools?
Thanks!
2 Replies
- Kevin_Stewart
Employee
I believe the iRule is processed first so the user will go to pool B based on the app cookie matching the iRule but what about the persistence? Does the F5 know to use the right cookie depending upon which pool the traffic gets sent to?
The iRule is indeed processed first, or at least negates (with the help of OneConnect) the existing persistence if a different pool is selected. The interesting thing about the built-in cookie persistence is that it magically includes the pool name in its name, so each pool will get its own persistence cookie and load balancing affinity will happen according to the defined pool. If you create a cookie persistence profile with a different name, you won't get the ability to create different cookies for different pools.
33boston_223Thanks Kevin! That's what I was looking for, so basically in order for persistence to function when going to different pools we would need to use the persistence cookies default naming convention.
