Forum Discussion

Elliot_Schlegel's avatar
Elliot_Schlegel
Icon for Nimbostratus rankNimbostratus
Feb 19, 2015

Best practice for unavailable pool

I've been reading about sorry iRules for outage/maintenance pages by either delivering content or redirecting to an outage page [or switch to an outage pool]. This works, of course, but does seem it requires one irule per pool.

 

A colleague suggested using priority groups and have an outage node which is only activated when all other nodes are down. Has anyone done this? Is there something I'm missing avoiding irules doing it this way? It does seem to clutter up the pool display as there's always an up pool member waiting to activate in case of problems. But does unclutter the irule list.

 

All of my virtual servers are simple insofar as there is only one pool per virtual server. Is there a way to determine which pool we're dealing with in the scope of an Irule without being explicit to which pool that is?

 

2 Replies

  • The biggest issue with using priority group activation for maintenance servers, comes into play when you are using persistence. If the maintenance servers go into use, the connections will persist. The easiest method for overcoming this is using an iRule, and disabling persistence when the maintenance pool is used.

     

  • giltjr's avatar
    giltjr
    Icon for Nimbostratus rankNimbostratus

    Why do you think it requires one iRule per pool? This does assume that the correct pool has been assigned by this point in time. You could also do a check of the nubmer of active members in the LB_SELECTED event.

    when HTTP_REQUEST {
    if {[active_members [LB::server pool]] == 0} {
        set MaintenceMessage "We are out for maintenace
        HTTP::respond 200 content $MaintenaceMessage ; return
        }
    }