Forum Discussion
Honestly the best way is to do it using pools as you are doing above (and I second Nitass point above - it is more efficient to do in CLIENT_ACCEPTED). It could be done using iRule to reselect a pool member if the wrong one is chosen but honestly - yuck.
Another way would be to add in the new pool members to the pool with a lower priority group setting, and add cookie persistence to the virtual. Then, use a browser add-on to insert the correct cookie to access the new servers.
Another way (I'm just flashing ideas about this might not suit you) to have servers move in/out of production/staging modes is to have an alternate FQDN ie staging.mysite.com, then have 2 identical pools, one that looks for "staging" in the healthcheck response, and one that looks for "normal" in the response. Then you can take x number of servers out of "normal" mode, move them into "staging" mode, then have an irule you use to access the staging pool ie.
if {[HTTP::host] starts_with "staging"} {
pool pl_staging.mysite.com
}
Then when you are finished with them in staging mode you flick them back into "normal" mode. We actually use this technique for testing new releases.
Hope some of that is useful or gives you ideas.
- Lazar_92526Aug 19, 2014NimbostratusSo an adjusted iRule that would work with the CLIENT_ACCEPTED and no ONECONNECT enabled would look like the following then? when CLIENT_ACCEPTED { if { [class match [IP::client_addr] equals test_list] }{ pool test_pool } else { pool default } }