Forum Discussion

RADITC_237625's avatar
RADITC_237625
Icon for Nimbostratus rankNimbostratus
Dec 08, 2015

BigIP LTM Monitor RPC and HTTP

Up until recently every monitor I have configured has been relatively simple. However, I've hit a bit of blocker with this one though I have read the forums I don't truly understand how this will work.

 

So I have a set of IIS servers which are active passive across DC's that have a replicated LTM with GTM on the edge. These servers are only used for RPC calls from a thick client or from true web servers that are sat behind the LTM. All traffic is RPC.

 

I need to be able to associated a VS / VIP with these RPC servers and LB this between the 2 on each site and over the WAN using the replicated LTM's. Now I could do a RPC monitor and leave it be. But this leads to the problem of removing single servers from active service for the guys who actually manage the web kit. It's been suggested a website created that the monitor queries but this doesn't give a true service availability report as the HTTP call is only there for the LTM not live service.

 

I've read you can add multiple monitors to a pool (never done that and news until today!) - Is it possible to create a monitor that would allow the HTTP call to complete, if this completes then run the RPC monitor, if both complete service is up. If one fails service is down?

 

Anyone give a good example of this being done?

 

Rich

 

1 Reply

  • You can certainly add more than one monitor, and specify whether 'all' monitors must be successful or a minimum number of successful monitors for a pool member to be active. (use the 'Advanced' screen if GUI; in TMSH will be 'min of { monitor list }' - use the ? after the monitor keyword for examples).

     

    I don't believe you can 'sequence' monitors using only the basic capability of GUI/TMSH. If you needed to do this you could probably craft a custom external monitor that would check functions in sequence. If running both the HTTP and RPC monitor will work in your scenario it may be the cleanest (from config management and resource utilization) route.

     

    I hope this helps at least somewhat.