Remedy Best Practices or Experiences

So we are using Remedy behind an F5 LTM. Here are some knowns:

 

1. Remedy can be configured use the rpc portmapper (tcp/111 and udp/111) to relay the open tcp/udp port used by Remedy.

 

2. Remedy is configured to listed on a specific tcp/udp prot.

 

3. Remedy uses the rpc protocol over tcp or udp.

 

4. Remedy is not a true application cluster; sessions are tracked and independant to each node. We enabled source ip session persistence and set the expiration to the period of time that Remedy expires the floating license token.

 

 

Here is my current state:

 

1. We are able to handle rpc portmapper traffic so that users can connect to the Remedy farm ip address without specifying a tcp/udp port.

 

2. We are able to handle the remedy traffic through the ltm (rpc over tcp or udp)

 

3. We have a health check set up by verifying the port that Remedy is configured to listen on is open (tcp/2020).

 

 

Here is my problem:

 

1. Remedy can be listening on the tcp/2020 but not responding to client requests. We would like a health check that actually verifies the availability of the application server. Can you point me in the right direction as to how to accomplish this?

 

 

Thanks,

 

Axton Grams

You can do this efficiently with a tcp monitor in which you provide a send string for the server for it to provide some feedback to you that you configure in a receive string. Make sure the receive string contents are only returned when you consider the site up. Click here for an example.

 

 

If you want, you can also write an external monitor that you can script to interrogate your application and provide a status back to bigIP. This page covers the format for the external monitor as well as several examples: Click here

I am not sure either option is viable, let me explain and maybe you can help to confirm or deny the validity of each option.

 

 

Option 1: TCP Monitor

 

With the RPC protocol, some binary data is required in the packet sent to the Remedy server to get a valid response. Also, multiple packets would need to be sent to complete the handshake properly to get a response that is a valid measure of the availability. Is this possible?

 

 

Option 2: External Monitor

 

The Remedy api's available are a C api and a Java api (JNI Wrapper for C native libs). Both require native libraries which are only available for the following platforms: AIX, HP-UX, Solaris, Linux, and Windows. My understanding is that the F5 devices run a BSD kernel, thus would not be capable of using the available Remedy apis.

 

 

Another option I am considering is writing a program to listen on a port seperate that of the application that can handle a request that contains a string. It would simply return a 0 or a 1 if the server is up or down. Can the tcp monitor check a port that is different than the port it handles for load balancing?

As for option 1, you can largely use binary data for the send and recv strings, but it has to be completely static (no nonces or anything). It can span multiple packets, but cannot be a back-and-forth application layer handshake; it's just "send this data and expect this other data back" and that's it. It sounds like this isn't sufficient for your needs.

 

 

As for option 2, that should be workable. As of v9 (released nearly 5 years ago), BIG-IP runs on a Linux platform, not BSD.

 

 

Your third option should also be workable. Monitors can be tied to a different port than the pool member port.

Hi,

 

 

Can someone advise if any specific configuration is needed (application side/F5) to put Arsystem Mid-tier behind F5 for load balancing?

Hi all, I'm also having issues trying to load balance between two AR serveres for remedy. I can specify each seperate server in the accounts server section and they work fine, but as soon as I use the F5, nothing. I run a tcpdump and can see some traffic hitting the vip... seems to be both udp and tcp connections and one connection using sunrpc. Trying to work out if there's any special configuration required on the f5 side or app side like RC posted above

 

 

The only traffic going to the servers in the default pool also only seems to be udp traffic:

 

 

10.20.20.250.2749 > 10.50.50.6.sunrpc: udp 56 (DF) 16:06:23.714621 10.50.50.6.sunrpc > 10.20.20.250.2749: udp 28

I'm having the same problem where I have to write a more intuitive health monitor than the simple TCP 3-way handshake check. Anyone ever figure this out? I don't see where Axton ever posted his solution....