Clone pool with persistence different than server pool

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

Much thanks Deb!

 

 

Yeah - I don't post often..... but I do lurk quite a bit.

Hi 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

You 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