Forum Discussion
10 Replies
- IheartF5_45022Nacreous
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_92526NimbostratusSo 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 } }
- nitass_89166Noctilucent
Will this following irule send traffic to a pool based of of client ip addresses defined in a group destination list?
yes
If the IP is not defined, we want it to go to the default pool defined for the VIP.
yes
- nitass_89166Noctilucentone more thing, you may move irule to CLIENT_ACCEPTED because you do not use any information from application (http) layer.
- nitassEmployee
Will this following irule send traffic to a pool based of of client ip addresses defined in a group destination list?
yes
If the IP is not defined, we want it to go to the default pool defined for the VIP.
yes
- nitassEmployeeone more thing, you may move irule to CLIENT_ACCEPTED because you do not use any information from application (http) layer.
- IheartF5_45022Nacreous
You don't actually need the explicit default pool chosen if you have oneconnect enabled, if you don't then [LB::server pool] is best way to refer to default pool;-
when HTTP_REQUEST { if { [class match [IP::client_addr] equals test_list] }{ pool test_pool } else { You can drop this clause if you have oneconnect enabled as default pool will always be chosen pool [LB::server pool] } }
- Lazar_92526Nimbostratus
Thanks - so what I'm trying to accomplish with this is to add new members (and new IP addresses) to a pool as a part of an upgrade so we can use the same VIP, but we only want traffic to go to these members from specific IP addresses.
Additionally, I'm trying to elimiate creating additional pools for these new systems if possible. When the exising members are retired, we then want traffic to go to the new members. Trying to determine an irule that may be able to accomplish this.
Any ideas are appreciated.
- nitassEmployee
so what I'm trying to accomplish with this is to add new members (and new IP addresses) to a pool as a part of an upgrade so we can use the same VIP, but we only want traffic to go to these members from specific IP addresses.
you may check client ip using IP::addr or class match command. If matches, send it to specific server using node command.
node
IP::addr
- Lazar_92526Nimbostratus
Taking IheartF5's thoughts in consideration:
I'm thinking of doing the following.
Put in an iRule to look for the client IP and see if it matches one identified in the test_list for testing purposes. If it does, go to a defined pool.
On the default pool, set priority group activation for the default pool = less then 1, then when the old servers are disabled, the new servers will take over.
Thoughts on the following:
Default pool = the following IP addresses and priorities:
IP1(original server) (Priority group 3)
IP2(original server) (Priority group 3)
IP3(new server) (Priority group 1)
IP4(new server) (Priority group 1)
IP addresses IP3 and IP4 are also in the test_pool. The new servers should not get any traffic sent to them as long as none of the original systems are up. Once both the original systems are down, traffic will go to the new systems.