Health Monitor Profile
Avi Vantage validates if the servers are functioning efficiently. Avi Vantage also tests if they can accommodate additional workloads before load balancing a client to a server. This topic details out the functions of a health monitor, provides the steps to create/edit a health monitor in Avi Vantage, and defines the different types of health monitors available.
Avi Vantage sends active health monitors on a periodic basis. They originate from the Service Engines(SE) 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 SEs, servers will receive active health queries from each Service Engine.
A pool that is not attached to a virtual service is in an unused state and will therefore not send health monitors to its servers. A pool may have 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.
Note: Starting with release 18.1.2, this feature is supported for IPv6 in Avi Vantage.
Active Health Monitors
Active health monitors send proactive queries to servers, synthetically mimicking a client. Send and receive timeout intervals are defined to determine the server response as success or failure. Active health monitors originate from the SE assigned to the application’s virtual service. 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 SEs. The health monitors are attached to the pool for virtual service. A pool that is not attached to a virtual service will not send health monitors.
To view health monitors in Avi Vantage, navigate to Templates > Profiles > Health Monitors.
The health monitors are displayed as below.
The following functions can be executed on this screen.
- Search: Click on the search icon and type the name of a health monitor to find it from the list of health monitors.
- Create: Click on the Create button to view the New Health Monitor screen. Enter the details of the new monitor and click on Save.
- Edit: Click on the edit icon against a health monitor to view the Edit Health Monitor: screen. Modify the fields as required and click on Save.
Note: The default system profiles can be edited but not deleted. A profile can be deleted only if it is not assigned to a virtual service.
Creating/Editing a Health Monitor
The New Health Monitor and the Edit Health Monitor windows have the same fields. For illustration, let us view the New Health Monitor screen.
- Click on Create. The New Health Monitor appears as shown below.
- Enter a unique Name for the monitor.
- Enter a Description.
- Select the Type of Health Monitor you want to create from the dropdown list.
- Enter the following details:
- Send Interval,(in seconds):This value determines how frequently the health monitor initiates an active check of a server. The minimum frequency is 2 seconds, and the maximum is 3600.
- Receive Timeout,(in seconds): The server must return a valid response to the Health Monitor within the specified time limit. The minimum value is 1 second, and the maximum is the shorter of either 300 seconds or the Send Interval value minus 1 second.
Note: If the status of a server continually flips between up and down, this may indicate that the Receive Timeout is too aggressive for the server.
- Successive Checks: This is the number of consecutive health checks that must succeed before Avi Vantage marks a down server as up. The minimum is 1, and the maximum is 50.
- Failed Checks: This is the number of consecutive health checks that on failing, Avi Vantage marks a server as down. The minimum is 1, and the maximum is 50.
- Click on the option Is Federated? to replicate the object across the federation. When this option is not selected, the object is visible within the Controller-cluster and its associated SEs.
is_federatedis set to True only when GSLB is turned on. A federated health monitor is used for GSLB purposes while it is not applicable for a regular health-monitor. This implies that a GSLB service cannot be associated with a regular health monitor, because GSLB service is a federated object, while the health monitor is not. Conversely, A pool cannot be associated with a federated health monitor because the pool is not a federated object.
Note: Scroll down to view the configurations specific to the monitor selected.
Types of Monitors
- DNS Monitor: A DNS monitor queries name servers for an A record and matches the resolved response against an expected IP address. To know more, refer to DNS Health Monitor.
- External Monitor: Use the external monitor to write scripts that provide highly customized and granular health checks. The scripts may be Linux shell, Python, or Perl, which can be used to execute wget, netcat, curl, snmpget, or dig. To know more, refer to External Health Monitor.
- HTTP Monitor: This Monitor type sends a request to a web server and validates either the HTTP response code or the HTML response data. To know more refer to HTTP Health Monitor
- HTTPS Monitor: This Monitor type can be used to validate the health of HTTPS encrypted web servers. Use this monitor when Avi Vantage is either passing SSL encrypted traffic directly from clients to servers, or Avi Vantage is providing SSL encryption between itself and the servers. This monitor is the same as the HTTP Monitor.
- Ping Monitor: Avi Vantage will send an ICMP ping to the server. This Monitor type is generally very fast and lightweight for both Avi Vantage and the server. To know more, refer to Ping Health Monitor.
- TCP Monitor: For any TCP application, this Monitor will wait for the TCP connection establishment, send the request string, and then wait for the server to respond with the expected content. If no client request and server response are configured, the health check will pass once a TCP connection is successfully established. To know more, refer to TCP Health Monitor
- UDP Monitor: Sends the request data to the server, then matches the server’s response against the expected response data. To know more, refer to UDP Health Monitor
- 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 Request Code: Enter the request to be sent to the SIP server for health monitoring.
SIP Response: Enter the string to be matched in the response payload. By default, it is configured for SIP/2.0.
Passive Health Monitors
While active health monitors show us if the server health is good or bad, passive health monitors provide a subtle check by attempting to understand and react to the client-to-server interaction. Unlike the active health monitors, 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 monitors.
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: It is recommended to enable a passive and an active health monitor to each pool.