Get addresses of unavailable pool members?

Hi Roman,

 

 

What are you trying to get this info for?

 

 

You could do a diff between all of the members returned in members -list $pool and the members marked up from active_members -list $pool, but I am not sure it's worth the overhead.

 

 

Aaron

Hi Aaron,

 

 

Brilliant! [members -list $pool] has done the trick.

 

 

Thank you very much!

 

 

PS: We have an external app which can "remedy" a pool member (redeploy app, restart server, send alert, etc) based on the ip:port provided. What I wanted to do was upon detection there're no members left, get their addresses and pass to that external app.

 

If you can use that logic on a non-client facing virtual server it should be fine in terms of LTM resources. Else, I'd try building an iControl app to get the downed member info. Or maybe you can use SNMP traps from LTM to notify the external app that a pool member has been marked down.

 

 

Aaron

I see what you're saying, maybe I need to reconsider ... I was thinking to send HTTP sideband request with a list of offline members to that external app (it forks another thread and returns instantly back) as in the example:

 

http://devcentral.f5.com/wiki/iRules.HTTP_sideband_policy_checking.ashx

 

 

And yes, that eventually would be client-faced VIP.

 

 

Thanks, Roman

 

 

I'd try to avoid tying the pool member restart logic to the load balancing of client traffic. Doing this on the client virtual server would add unnecessary load to LTM. Ideally, you could either poll LTM from a remote host to look for newly downed pool members or set up a trap so LTM can notify the external app when a pool member gets marked down.

 

 

Aaron

Hi Aaron,

 

 

I like your idea about building remote polling app to examine LTM pool. I could use iControl for that. Hopefully, it should put less overhead on LTM, than doing it inside iRule.

 

 

Is there a way to create an event, tag, or object inside an iRule, fill it with some info, and attach it to the pool member to store on LTM? This way, when connecting with iControl, not only would I know that a pool member is down, but I would also know why. Currently, in iRule, I somewhat have access to the cause of member failure (http_status, lb_failure, momitor timeout), so the external app would get an error message and act upon that (restart webservice if http status is 500, restart server if lb_failed, etc)

 

 

I'll look into using a trap as well.

 

 

Thanks, Roman

You could use the log command to write something informative to the local filesystem when a pool member is down. Default logging will already tell you whether a monitor failed. If you're using 'Fallback on Error Codes' on the HTTP profile, I don't think that would be logged as we don't log anything by default for individual request/LB failures. In v11, you can use [event info] in LB_FAILED to check why the event was triggered. In v10, I don't think it's possible to determine why LB_FAILED was triggered. However, I'm not sure you'd want to restart services if an individual connection attempt or HTTP request failed. So maybe it only makes sense to trigger the service restart if the pool member is actually marked down.

 

 

Aaron

You're right, it prob makes more sense to mark down pool member inside an iRule, and then act on that via iControl.

 

 

I thought about interrogating logs too, but I wasn't sure how efficient that would be.

 

 

We've just upgraded to v10, so it'll be a while till we go to 11.

 

 

Thank you for all your help,

 

Roman