Matt_Breedlove_
Jun 24, 2009Nimbostratus
single VS distributing new connections across multiple pools with persistence
We have a single VS in standard mode with 2 pools of servers. Each pool contains different servers.
VS has cookie insert persistence with named cookie and a 17min timeout.
Goal is to have 1 out of every X number of NEW connections only go to the second pool. Once a client has been sent to the second pool, the subsequent requests from that user should also follow into the the second pool if during same session.
We have a single global variable that increments each time HTTP_REQUEST occurs, but we want to modify this so that it only increments on new connections
Current rule:
when RULE_INIT {
set ::cnt 0
}
when HTTP_REQUEST {
incr $cnt
if { $cnt = 4000 } {
set ::cnt 0
pool pool2
} else {
pool $pool1
}
}
Pool 2 is about 20% of the capacity of Pool 1 and using different class of server hardware.
One thing that I was thinking of was to look for the named persistence cookie, and if it does not already exist then increment the global var
The assumption is that new/initial HTTP connections can be identified in the VS's iRule by looking for the presence of the named inserted cookie via the persistence profile.
We have the megaproxy issue so we are dependent on cookie inserted persistence
Possible changed rule
when RULE_INIT {
set ::cnt 0
}
when HTTP_REQUEST {
if { ([HTTP::cookie] exists "namedcookie_from_persistence_profile") } {
send connection to existing persisted server in whichever pool its in
Can 'persist' just be used or does the member and pool need to be looked up and then
manually pooled there?
} else {
Assumption is only brand new initial connections with no persistence yet defined are
being dealt with at this point
incr $cnt
if { $cnt = 4000 } {
set ::cnt 0
pool pool2 New persistence record is formed after this 'pool'
} else {
pool $pool1
}
}
}
Is this the right strategy?
Can 'persist' be used in place of 'pool' to make sure the specific member in the respective pool is reused for the rest of that sessions http requests? Or is 'pool' required to actually farm the connection out
What we are trying to avoid is having User Bob come in and hit homepage on global var cont 3998, go to a server in pool a, then click on 2 links and the second link sets the global var to 4000, which causes Bob to have his second click "pooled" to the second pool. Rather we would not want User Bob's subsequent http requests to be capable of incrementing that global var, so that when User Joe comes in on new connection and he trips the counter to 4000, then his requests and subsequent requests in same connection/session go to that same node in the second pool
Once the persistence cookie expires then the user can be sent to either of the pools.
If the node in the pool is marked down by a monitor, we would expect that to wipe out the named persistence cookie causing them to be free to be subject to new pool and new subsequent persistence record being created
Thanks for the help