Forum Discussion

jrok_47156's avatar
jrok_47156
Icon for Nimbostratus rankNimbostratus
Dec 27, 2012

pool assignment persistence

I have a vip with a pool that has members. The members are application servers. When all the members of my vip pool are down I currently have the F5 doing a redirect with the URI to /maintenance and then follow that up with a HTTP::respond 200 with the maintenance page content as everyone is familiar with. This method works fine for the client browser but I wanted more control over information about the downtime so I could react quicker than getting a phone call from our hosting provider.

 

So I created another seperate application server to act only as a downtime server. I did not create a vip for it. I created only another pool and pointed it at the downtime server. So in this new scenario while someone is browsing along and the members all go down I re-assign the pool on the next request from the real vip application pool to the downtime server pool. The downtime server, which has programming power the F5 does not, then sends me an SMS message on my phone and emails all the usual supects that might have broken my application. It also presents the client a similar downtime page with a meta-refresh to keep checking if the application pool comes back up.

 

So far this all works fine. However, when someone gets kicked to the downtime page and the vip application pool members then come back online, the client browser just keeps on showing the downtime page and refreshing back to itself. It seems like the pool re-assignment has become permanent with that particular client and I cannot seem to re-assign it back to the proper application pool. If I open another browser it works fine, but the client that got sent to the downtime page never recovers.

 

 

when HTTP_REQUEST {

 

if { $static::wwwqadebug }

 

{

 

log local0. "act:[active_members $static::wwwqapool]"

 

}

 

if { [active_members $static::wwwqapool] > 0 }

 

{

 

pool $static::wwwqapool

 

}

 

else

 

{

 

HTTP::respond 302 noserver "Location" "$static::wwwqaprot$static::wwwqahost$static::wwwqafail"

 

pool downtimeservice

 

event disable

 

}

 

}

 

1 Reply

  • I think simply removing the 'event disable' statement should fix this. I'd also suggest that rather than this iRule and the second pool you use Priority Group Activation, OneConnect and a simpler iRule to switch back instead. Alternatively, configuring a sorry server in a HTTP Profile might be preferable.