Forum Discussion

clazba's avatar
clazba
Icon for Nimbostratus rankNimbostratus
Nov 22, 2011

Disable (Only persistent or active connections allowed) a Pool member through a monitor in v9.x

Hi Guys,

 

 

 

I am trying to disable a pool member in V9.x (primarily for for maintenance purposes) without any admin access to the bigip (no https, no ssh, no icontrol) based on the content of an object on the target server. (i.e using HTTP Monitors)

 

 

 

The requirement is driven by a financial organization that completely locks down access to their F5 estate once the unit are in production.

 

As far as I know there is no way to do this from the GUI (hopefully i am wrong) so i can think of 2 ways to do this:

 

 

 

1. Write up an irule that on HTTP_REQUEST checks the status of a 'dummy' pool member with LB::status pool and then disables the production pool member with LB::down pool.

 

 

 

2. Write a cron job that check the status of the 'dummy' member with "b pool my_pool members all monitor" at regular intervals and, if marked down, disables the production members with "b pool my_pool member my_pool_member session disable".

 

 

 

Both methods seem quite cumbersome and not particularly elegant so i was wondering if anyone has come across a better way of doing this.

 

 

 

Thanks,

 

 

 

Claud

 

config
design
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Nov 22, 2011
    Ask them to lighten up on their requirements... :)

     

     

    How about using the "receive disable string" on an HTTP/S monitor?

     

     

    "This setting works like Receive String, except that the system marks the node or pool member disabled when its response matches Receive Disable String but not Receive String. To use this setting, you must specify both Receive Disable String and Receive String."

     

     

    You'd need to make sure the modified response which matches the receive disable string does not also match the receive string.

     

     

    Aaron
  • clazba's avatar
    clazba
    Icon for Nimbostratus rankNimbostratus
    Nov 22, 2011
    Yeah sorry i forgot to mention they are running V9.x (I knew I left something rather crucial out ;) .. afaik Receive Disable String only came about in >10.2 ? again hope i'm wrong.

     

     

    Other option of course is to create an ECV monitor but was hoping to steer away from that.
  • clazba's avatar
    clazba
    Icon for Nimbostratus rankNimbostratus
    Nov 22, 2011
    .. of course if anyone has written an ECV monitor to this purpose it would be good to take a peek ..
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Nov 22, 2011
    I think an ECV would be a lot simpler than iRule trickery for this. You could start with this template and make an iControl call from perl to disable the pool member:

     

     

    http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/TemplateForExternalLtmMonitors.html

     

     

    Aaron
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Nov 22, 2011
    What sort of financial organisation stops admin (Including trouble shooting and diags on a production system?)

     

     

    Anyway.. Use a monitor that checks the content. Then arrange the content to return something that marks the pool member down when a particular sting is (Or isn't) returned.

     

     

     

    Also set the pool action on service down to nothing (e.g. Don't reselect or reset :)

     

     

    H

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Nov 22, 2011
    I think the only difference between marking the pool member down with the pool action on down set to nothing and disabling via iControl is that you can set the node address to disabled to still allow persistent connections with iControl.

     

     

    Aaron
  • clazba's avatar
    clazba
    Icon for Nimbostratus rankNimbostratus
    Nov 23, 2011
    That's right -- we have proven in tests that if a node is marked down by the monitor it won't gracefully drain out existing session, hence the hoop jumping exercise ;)

     

     

    So Aaron, I have been playing with this all day and it appears that the questions has risen many times in the forums - there seems to be two main schools of thought in regard:

     

     

    1. ECV Monitor + perl/iControl (many ready iControl apps available)

     

     

    2. Driving the pool member status through an irule and query string as per Deb's example (http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/51/aft/26906/showtab/groupforums/Default.aspx)

     

     

    Both methods seem to work in a rough and ready lab test although with the ECV Monitor script seems the more labour intensive of the two solutions to get working properly - thinking error handling and compatibility with future releases.

     

     

    So I am tempted to go for the irule solution as it seems to offer the possibility of driving the pool member from an existing VIP directly from the target web servers - ultimately the target node would have to be manually disabled for maintenance so it makes little difference if the operator has to executes a binary that fires up an HTTP request to the VIP instead of changing the content of a file.

     

     

    Thoughts?

     

     

    Claud