Answers

HTTP monitor and target web server down

I have a reverse HTTP monitor that is assigned to two pool members. The HTTP server for this monitor is hosted on a third server, which is not a member of the pool. When this third server is up and serving requests, I can correctly execute the monitor for the pool members. However, when the HTTP server is down, my reverse monitors fail and the pool members get disabled. Is there a way to configure a reverse monitor to survive an outage on an alias address/port?

Can you post the config for your monitor (sanitized if you need)? Just to help clarify how your monitor is working? Should be able to get it from the command line "tmsh list ltm monitor <MONITOR NAME>".

Hi Michael,
Sure - in this example, server1 is one of the two pool members. Server3 (which is running the HTTP server) is at 10.1.1.1. My question is, when server3 is down (reboot/patch/etc.), how can I ensure that the monitor doesn't fail so that server1 and server2 remain enabled in the pool?
ltm monitor http Ultra_rev_server1 {
defaults-from http
destination 10.1.1.1:http
interval 5
recv DOWN
reverse enabled
send "GET /down/server1.html\\r\\n"
time-until-up 0
timeout 16
}
Thanks,
Jen

0

Answers to this Question

Hi dubdub,
I´m not aware of a build-in solution for your requirement and I guess F5´s intention was to map the reverse monitor to the pool members directly. In case the monitoring condition is met or the pool member does not respond at all it will be marked as down until a following monitoring sequence is successful.
Before this feature was build in I used a so called external monitor (based on a shell script) to poll a status page on a dedicated server. Based on the result the monitor modified the pool member state via tmsh.
That´s the only approach coming close to what you have currently tried to implement.
But how about using the API to control poolmember state?
Thanks, Stephan

Hi Stephan,
It's funny you should mention that, as I am currently rolling out a script for monitoring some TCP application servers based on a separate web service's JSON result set (which includes whether the pool member should be enabled or not, and how to adjust the dynamic ratio setting for it based on current load, and some other tidbits). That script is already tested to sustain an outage to the web service and not adversely affect the pool member status if it's not available. The trickiest thing with the script was to figure out whether the current unit was the active unit or not, as otherwise the sync state got completely hosed up with each unit doing its own enabling/disabling of nodes.
I was hoping there might be some survivability (not a real word, I know!) built into the reverse monitor, but I can pull together a script for this situation as well. Figured it was worth finding out for sure.
I appreciate the responses!
Thanks,
Jen