Health Monitor Profile

Overview

Avi Vantage must validate whether servers are working correctly and are able to accommodate additional workloads before load balancing a client to a particular server. Health monitors perform this function by either actively sending a synthetic transaction to a server or by passively monitoring client experience with the server. Avi Vantage sends active health monitors on a periodic basis that originate from the Service Engines assigned to the application’s virtual service.

The health monitors are attached to the pool for the virtual service. When scaling out a virtual service across multiple Service Engines, servers will receive active health queries from each Service Engine.

A pool that is not attached to a virtual service is considered to be in an unused state and will therefore not send health monitors to its servers. A pool may have both multiple actively concurrent health monitors (such as Ping, TCP, and HTTP), as well as a passive monitor. All active health monitors must be successful for the server to be marked up.

Only active health monitors may be edited. The passive monitor has no settings.

  • Health Monitors Tab
  • Create/Edit a Health Monitor
  • Passive Health Monitor

Health Monitor Settings

Select Templates > Profiles > Health Monitor to open the Health Monitor tab. This tab includes the following functions:

  • Search — Search across the list of objects.
  • Create — Opens the New Health Monitor Profile popup.
  • Edit — Opens the Edit Health Monitor Profile popup.
  • Delete — A profile may only be deleted if it is not currently assigned to a virtual service. An error message will indicate the VS referencing the profile. The default system profiles can be edited, but not deleted.

The table on this tab provides the following information for each health monitor profile:

  • Health Monitor — Name of the health monitor.
  • Type — Type of Health Monitor, which can be one of the following:
    • DNS — Validate the health of responses from DNS servers.
    • External — Use a custom script to validate the health of a diverse array of applications.
    • HTTP — Validate the health of HTTP web servers.
    • HTTPS — Validate the health of HTTPS web servers when the connection between Avi Vantage and the server is SSL/TLS encrypted.
    • Ping — An ICMP ping can be used to monitor any server that responds to pings. This is a lightweight monitor, but it does not validate application health.
    • TCP — Validate TCP applications via simple TCP request/response data.
    • UDP — Validate UDP applications via simple UDP request/response data.
    • SIP — Validate SIP applications via SIP request code and response.
  • Send Interval — Frequency at which the Health Monitor initiates a server check, in seconds.
  • Receive Timeout — Maximum amount of time before the server must return a valid response to the Health Monitor, in seconds.
  • Successful Checks — Number of consecutive health checks that must succeed before Avi Vantage marks a down server as being back up.
  • Failed Checks — Number of consecutive health checks that must fail before Avi Vantage marks an up server as being down.

Active Health Monitor

Active health monitors send proactive queries to servers, synthetically mimicking a client. Send and receive timeout intervals may be defined, which statically determine the server response as successful or failed. Active health monitors originate from the Service Engines upon which the application’s virtual service has been placed. Each SE must be able to send monitors to the servers, which ensures there are no routing or intermediate networking issues that might prevent access to a server from all active Service Engines.

The health monitors are attached to the pool for the virtual service. A pool that is not attached to a virtual service will not send health monitors.

The following are configurable active health monitors:

SIP Monitor

For SIP applications, the server health is monitored using the SIP request code and response. Currently only SIP options are supported for the request code. The monitor greps for the configured response string in the response payload. If a valid response is not received from the server within the configured timeout, then the server status is marked down.

sip-settings

Parameters specific to a SIP monitor:

  • SIP Request Code: Specify the SIP request to be sent to the server for health monitoring. By default, SIP OPTIONS request will be sent.
  • SIP Response: Specify the match for a keyword in the first 2KB of the server header and body response. By default, it is configured for SIP/2.0.
  • SIP Monitor Transport: Specify the transport protocol TCP or UDP, to be used for SIP health monitor. The default transport is UDP.

Passive Health Monitor

While active health monitors provide a binary good/bad analysis of server health, passive health monitors provide a more subtle check by attempting to understand and react to the client-to-server interaction. An active health monitor sends a periodic check to the servers that mimics an end user transaction with a synthetic request, then statically validates the response against an expected string. Passive health monitors do not send a check to the servers. Instead, Avi Vantage monitors end-user interaction with the servers. If a server is quickly responding with valid responses (such as HTTP 200), then all is well; however, if the server is sending back errors (such as TCP resets or HTTP 5xx errors), the server is assumed to have errors. Errors are defined by the analytics profile attached to the virtual service. The analytics profile also defines the threshold for response time before a server is considered responding slowly.

With active health monitors, Avi Vantage will mark a server down after the specified number of consecutive failures and will no longer send new connections or requests until that server is able to correctly pass the periodic active health checks.

With passive health monitors, server failures will not cause Avi Vantage to mark that server as down. Rather, the passive health monitor will reduce the number of connections or requests sent to the server relative to the other servers in the pool by about 75%. Further failures may increase this percentage. After a server is satisfactorily handling the reduced load, it will once again be sent normal volumes of traffic.

Note: Best practice is to enable both a passive and an active health monitor to each pool.

RADIUS Health Monitor (RADIUS HM)

For Remote Authentication Dial-In User Service (RADIUS) applications, server health can be monitored using the RADIUS request and response. RADIUS requests can be now generated, given the password, username, and secret. The server status will be marked Up only if the RADIUS response is Access Accept or Access Challenge. Otherwise the server will be marked Down.

Username, password, and auth secret are the mandatory parameters.

Configuring RADIUS Health Monitor

Configure the username, password, and the secret as shown below.


[admin:ctrl]:configure healthmonitor radius-hm
[admin:ctrl]: healthmonitor> radius_monitor
password        Radius monitor will query Radius server with this password.
shared_secret   Radius monitor will query Radius server with this shared secret.
username        Radius monitor will query Radius server with this username.
[admin:ctrl]: healthmonitor> radius_monitor