Forum Discussion
Bruce_Hampton_1
Nimbostratus
NimbostratusClone pool with persistence different than server pool
I have situation where I need to change the persistence on a clone pool. The server pool has no persistence, however; I would like to use SSL persistence on the clone pool.
So - I have written this rule.
when CLIENT_ACCEPTED {
pool MY_APPPOOL
persist ssl
clone pool MY_CLONEPOOL
}
The question of course is will this apply SSL persistence to the clone pool only?
Thank for any help!
Bruce
- Hi Bruce -
(Long time no see!)
With that configuration, persistence will only apply to the clone pool.
Persistence by default is not shared between different pools or virtuals: Persistence table entries are keyed on the virtual & poolname unless otherwise specified by the "Persist across services" or "Perist across virtuals" option in the persistence profile.
HTH
/deb 
Bruce_Hampton_1Much thanks Deb!
Yeah - I don't post often..... but I do lurk quite a bit.- Bruce_Hampton_1Hi Deb,
When I applied the above rule - I got the following error.
BIGpipe: rule modification error:
01070372:3: Persistence mode (SSL) called out in rule (clone_test_persist) requires a corresponding persistence profile for virtual server (clone_test2).
The VIP does not have persisitance on it - by design. I only want to persist the clone pool side.
I could add persistance on the VIP but then delete it in the I-RUle? How to do a PERSIST::disable ?
Bruce - Oh, my apologies, it looks like I mis-read your original post.
I just checked with one of our developers, and there currently no way to apply persistence to the clone pool regardless of persistence settings on the server pool.
Apparently you could implement persistence by directly selecting the clone pool member, but I'm still waiting for details about how to pull out the clone pool info & force the selection. Will post back when I know more.
Sorry for the confusion.
/deb - OK, a CR is in the works to get profile-based clone pool persistence added, but in the meantime I finally got the scoop & wrote an article covering the basic idea of rolling your own clone pool persistence with an iRule:
Click here
http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=134
I'd be interested to hear if you run into any anomalies implementing this approach.
HTH,
/deb - Bruce_Hampton_1You Rock Deb! We'll give it a look over and see if it works out for us....
In the mean time - we fell to this model..
when CLIENT_ACCEPTED {
if { [expr {[crc32 [getfield [IP::client_addr] "." 4]] % 2} ] eq "1" } {
clone pool member 192.168.43.161
} else {
clone pool member 192.168.43.162
}
} - No problem.
It's always cool when you can add much-needed functionality with a few lines of code, especially when it has such potentially broad utility. Thanks for the post.
Your simple crc hash will work to split the traffic, but doesn't offer much in the way of fallback if a clone pool member goes down. I'd recommend going for a higher level of high-availability such as that my code provides via the LB::status & active_members commands to always send traffic to a known good server.
Apparently there are more applications than I realized for the roll-your-own/hash approach, though, so next week's tech tip will take the topic to another level that I'm sure you will find useful. I'll post back then with comments as to how you could use that same idea here.
/deb
