Forum Discussion
IheartF5_45022
Nacreous
OK I think I have it. You'll need 4 pools;-
- pl_server_v1 - contains all servers with http monitor that checks for "v1" returned from check
- pl_server_v2 - contains all servers with http monitor that checks for "v2" returned from check
- pl_server_v3 - contains all servers with http monitor that checks for "v3" returned from check
- pl_server_all - contains all servers with http monitor that checks for "v" returned from check
The virtual server will have pl_server_all as default pool, http and oneconnect profiles assigned, and the following iRule;
when HTTP_REQUEST {
Check AV cookie
if {[HTTP::cookie exists "AV"]} {
Assign pool based on AV cookie value
pool "pl_server_[string tolower [HTTP::cookie value "AV"]"
}
}
Remember to use a receive disable string in all the monitors which you can use to drain connections from the server. Let me know if it's not clear how to use this from reading the doco and I can explain.
Werner_Strydom_
Mar 05, 2014Nimbostratus
Thanks. I used v1, v2, v3 as placeholders for versions. In reality the versions change with every deployment (almost daily) and so does the cookie value. Once we deploy a new version, we'd like to migrate users to that version, without any errors. Since the applications isn't compatible, it can only happen when the session expires or when the user logs off. Its unclear how you'd route that request to a newer server.
The iRule you posted may be subject to a DoS attack. All I have to do is send you a lot of bogus requests with cookie "AV" with a value that doesn't exist. What would you do in that case. Or worse, flood the server with requests without a cookie (more likely) which overloads servers in pl_server_all. If there is no attack, I still have to ensure pl_server_all has enough servers to handle potential load.