Forum Discussion
13 Replies
- eey0reCirrostratus
To disable all the pool members, you need to either execute a tmsh command or use the new iCall system if your OS is recent enough.
The tmsh command could be triggered by cron.
iCall is explained in DevCentral: https://devcentral.f5.com/icall/getting-started
A third, more complex way would be to have an external system execute iControl (SOAP).
- AnthonyNimbostratus
iCall sounds good and looks to do what we want. Unfortunately we can't run 11.4 just yet due to having under spec'd F5s.
I will look at the tmsh command from the crontab as that might be a possibility.
Thanks Ant
- nitassEmployee
another solution is to run script based on log using alertd.
Acton on Log - using the alertd deamon
- Kevin_StewartEmployee
You can get iCall-like behavior prior to 11.4 using user_alert. Take a look at this thread:
https://devcentral.f5.com/questions/clearing-machine-cache
This will allow you to react to a data plane event (ie. a syslog message) in the management plane (ie. to run a script). You wouldn't want this sort of thing to get triggered on every request as the management plane is not designed with the same capacity as the data plane. Alternatively, if you're simply looking to disable access to the VIP or specific pool members during a certain time of day, you can a data group that defines the up/down times (and other settings) and an iRule that reads this data group on each request.
- AnthonyNimbostratus
Thanks nitass another good example that might be useable. I already have the function for time based actions so this might as we use this to automate full site outages.
- Kevin_StewartEmployee
If you just wanted to disable the pool members at a specific time of day, you could simply run an external monitor script that uses tmsh to do the job. Using an external monitor script has a few advantages: 1) if you keep the script in /config/monitors, it gets saved with the config when you archive, and 2) once assigned to a "dummy" pool (a pool that doesn't get assigned to a VIP), it executes at regular intervals like a cron job. You would then check the time on each execution and disable or enable the pool members if within the defined time span. Hopefully you have a good monitor on the actual VIP pool so that it knows the pools are down and takes some action.
If all you need to do is disable access to the VIP during a certain period though, and not necessarily disable the pool members, then an iRule like the following might also do the trick:
when RULE_INIT { set static::START_OFF_TIME "05:30 AM" set static::END_OFF_TIME "06:00 AM" } when HTTP_REQUEST { set start_off_time [clock scan $static::START_OFF_TIME] set end_off_time [clock scan $static::END_OFF_TIME] set now [clock seconds] if { ( [expr $now > $start_off_time] ) and ( [expr $now < $end_off_time] ) } { HTTP::respond 200 content "Maintenance ModeMaintenance mode..." } }
This basically looks at the time of the request and compares it to a start and end time. If the current time is between these values it automatically responds with what could be arbitrary HTML content (ie. a maintenance page). If you wanted to be really crafty about it, you could also add a stream profile and inject a floating DIV banner and some JavaScript into the responses when the current time gets close to the down time - an impending maintenance event message and counter.
- AnthonyNimbostratus
Just looking at this a bit closer while I have some time.
The initial way that I'm thinking of doing it was to set an iRule using the time method above in Kevins post, and use this to output a message, then have the user_alert.conf look for this message and action a tmsh command to disable new connections to the pool memebers.
This would appear to work fine except I believe this would execute on every HTTP_REQUEST which would clearly not be ideal.
- Kevin_StewartEmployee
Try setting a table value at the beginning of the off-time, just before sending the message to user_alert. Then on subsequent requests check for the table value before sending the message. Make sure to set idle time to indefinite.
- Kevin_StewartEmployee
Sure thing, though after thinking about it I've had a slight change of heart. The code below should do what you need:
when RULE_INIT { set static::START_OFF_TIME "09:30 AM" set static::END_OFF_TIME "10:00 AM" set static::DOWN_POOL "local-pool" set static::DOWN_MEMBERS [list "10.70.0.1 80" "10.70.0.2 80"] } when CLIENT_ACCEPTED { set start_off_time [clock scan $static::START_OFF_TIME] set end_off_time [clock scan $static::END_OFF_TIME] set now [clock seconds] if { ( [expr $now > $start_off_time] ) and ( [expr $now < $end_off_time] ) } { foreach x $static::DOWN_MEMBERS { LB::down pool $static::DOWN_POOL member [lindex $x 0] [lindex $x 1] } } }
The idea is that, at the given time period, selected members of the pool are marked down in the CLIENT_ACCEPTED event. This prevents them from being selected in the LB decision. I've added two new static variables:
set static::DOWN_POOL "local-pool"
This is the name of the pool, though you could also derive this with [LB::server pool] in the CLIENT_ACCEPTED event.
set static::DOWN_MEMBERS [list "10.70.0.1 80" "10.70.0.2 80"]
This is a list (IP and port) of each pool member to take down at the given time period. The CLIENT_ACCEPTED event loops through this list, removing these members from pool selection. You could still use the USER_ALERT method, but it becomes a bit more complex as you also have to manage bringing the members back up - an event that wouldn't be triggered until someone made a request.
- AnthonyNimbostratus
Thanks Kevin, that is really appreciated. Currently looking into all possible options but this is a good one. Will have a go at implementing it to our test F5 and see how I get on.