iRule to check if pool member is unavailable.

Forums Technical Forums
, ,
1

I would like to create an iRule that checks if all pool members. If these are unavailable or all down it should send a response that the page is currently unavailable.

Following irule works perfectly when the pool members are DOWN:

when HTTP_REQUEST {

if { [active_members [LB::server pool]] == 0 } {

HTTP::respond 503 content “Service Temporarily Unavailable”

}}

But the response is not send when pool members are marked as unavailable, for example by a https monitor where the disable string has been received.

Is there a way how you can check if pool members are unavailable?

2

Hi

This is because of this - myF5

Take a look at https://devcentral.f5.com/s/articles/irules-recipe-4-static-maintenance-page-23131 and Vernons’ comments

3

As far as I can tell, that article only applies when you have manually disabled pool members that would otherwise be online. (Pool member status shows a black circle and mouseover text “Available (Disabled) - Pool member is available, user disabled”)

This then also results in the virtual server status with a gray circle “Available (Disabled Parent) - The children pool member(s) might be disabled”

In any scenario where a health check automatically marks all pool members down, the pool members go into status offline, the vserver status also switches to offline and the above iRule works perfectly fine. At least for me, with version 14.

Which by the way also opens up a simple, if not very elegant, workaround: Instead of manually disabling the entire pool, just attach a monitor with an impossible condition to mark all members offline.

If there are any scenarios where what I wrote is not correct, I’d really like to know, because that could certainly come to bite me in my backside.

4

You can also reference K6510: BIG-IP system fallback host behavior when a host is down for information on using Fallback Host in the associated HTTP profile. It provides an alternative that does not include iRules, which is more efficient, but comes with some caveats. It also shows an iRule that triggers on LB_FAILED rather than HTTP_REQUEST, which is far more efficient since HTTP_REQUEST is triggered for every request, while LB_FAILED is only triggered if there is a problem with establishing the server-side connection, such as no available pool members. Here’s the iRule code from that article that redirects the request to an apology server. (Instead of HTTP::fallback, you could do your HTTP::respond 503.):

when LB_FAILED {
     if { [active_members [LB::server pool]] < 1 } {
          # The redirect will be sent only if LB_FAILED
          # was because the pool had no available members.
          HTTP::fallback "http://example.com/redirect.html"
     }
}

5

Thanks for all your input. we discovered we are hitting following bug:

Upgrade to 15.1..0 fixed the issue