Health Monitoring

ACOS devices can regularly check the health of real servers and service ports. Health checks ensure that client requests go only to available servers.

Servers or ports that respond appropriately to health checks remain eligible to serve client requests. A server or port that does not respond appropriately to a health check is temporarily removed from service, until the server or port is healthy again.

You can configure health methods on the ACOS device by configuring settings for the type of service you are monitoring. You also can configure health monitors externally using scripts and import the monitors for use by the ACOS device.

For information about health monitoring of the ACOS device’s nexthop gateways, see the “Gateway Health Monitoring” chapter in the System Configuration and Administration Guide.

Health Check Overview

This section contains the following topics:

     Default Health Checks

     Health-Check Guidelines

     Health Method Timers

     Health Check Operation

Default Health Checks

ACOS performs the following types of health checks by default:

     Layer 3 ping – Every 5 seconds, the ACOS device sends an ICMP echo request (ping) addressed to the real server’s IP address. The server passes the health check if it sends an echo reply to the ACOS device. If the server does not reply after the fourth attempt (the first attempt followed by 3 retries), the ACOS device sets the server state to DOWN.

     Layer 4 TCP – Every 5 seconds, the ACOS device sends a connection request (TCP SYN) to the specified TCP port on the server. The port passes the health check if it replies to the ACOS device by sending a TCP SYN ACK. If the port does not reply after the fourth attempt, the ACOS device sets the port state to DOWN.

     Layer 4 UDP – Every 5 seconds, the ACOS device sends a packet with a valid UDP header and a garbage payload to the UDP port. The port passes the health check if it either does not reply, or replies with any type of packet except an ICMP Error message. If the port replies with an ICMP Error message, the ACOS device sets the port state to DOWN.

The default ICMP, TCP, or UDP monitor is not used if you disable it on the server or port, or you apply a different monitor to the server or port.

NOTE:                               In the GUI, on the server configuration page, the default health monitors appear as “(default)” in the Health Monitor drop-down lists for the server itself and for the individ­ual TCP or UDP ports.

For the server itself, “(default)” means the Layer 3 ping described above. For TCP ports, “(default)” means the Layer 4 TCP health monitor described above. Likewise, for UDP ports, “(default)” means the Layer 4 UDP health monitor described above.

On a new ACOS device, the Health Monitor list contains one health monitor, “ping”. This health monitor is the same as the “default” server health monitor. The list does not con­tain the default TCP or UDP health monitors.

Health-Check Guidelines

By default, Layer 3 health checking of real server IP addresses is enabled. Likewise, Layer 4 (TCP and UDP) health checking of server ports is enabled by default.

Layer 3 health checking can be CPU-intensive. To help reduce unnecessary processing overhead, if you are using Layer 4 or Layer 7 health checking of a real server’s ports, it is recommended to disable Layer 3 health checking of that server’s IP address.

For very large deployments (1000 or more servers), A10 Networks recommends disabling the default Layer 3 health check, and using only Layer 4-7 health checks. (See Globally Disabling Layer 3 Health Checks.)

Health Method Timers

Health methods operate based on the following timers:

     Interval – Number of seconds between health check attempts.

Determination of the server or port’s health is not made within the interval. Instead, determination of health is made after the server or port passes or fails one of the attempts (intervals), or the number of retries is exhausted.

The default interval is 5 seconds. If you need to fine-tune this interval, you can change it to a value from 1-180 seconds.

     Timeout – Number of seconds the ACOS device waits for a reply to a health check. If the ACOS device does not receive the expected reply by the end of the timeout, the ACOS device either sends the health check again (if there are retries left) or marks the server or service down. You can specify 1-180 seconds. The default is 5 seconds.

The type of reply expected by the ACOS device depends on the monitor type. (See Health Method Types.)

     Retries – maximum number of times the ACOS device will send the same health check to an unresponsive server or service before marking that server or service as down. You can specify 1-5. The default is 3.

     Up-Retry – Number of consecutive times the device must pass the same periodic health check, in order to be marked Up. You can specify 1-10. The default is 1. (See Consecutive Health Checks Within a Health Check Period.)

NOTE:                               The default interval and timeout can be adjusted automatically by health-check rate limiting. (See Health-Check Rate Limiting.)

NOTE:                               The timeout does not apply to externally configured health monitors.

Health Check Operation

The figures in this section show how health checking operates:

     Example When Server or Port Is Unresponsive

     Example When Server or Port Is Responsive

Example When Server or Port Is Unresponsive

Figure 148 shows how health checking operates when the server or port is unresponsive.

After each interval, ACOS immediately begins the next health check, because the next interval begins immediately after the previous attempt times out. In the figures, “R” indicates a retry.

FIGURE 148      Health Checks Using Default Settings – Server or Port Is Unresponsive

health_check_defaults.jpg

 

Example When Server or Port Is Responsive

Figure 149 shows how health checking operates when the server or port is responsive. ACOS begins the next health check when the next interval begins. Using the default interval value, the next interval begins within 5 seconds.

FIGURE 149      Health Checks Using Default Settings – Server or Port Responds

health_check_defaults_response.jpg

 

Health Method Types

TABLE 16    lists the internal health method types supported by the ACOS device. The health methods use the well-known port numbers for each application by default. You can change the port numbers and other options when you define the health methods.

Multiple health method instances can be defined using the same method type and different parameters. Likewise, multiple health monitors can use the same health method to check different servers.

When a health monitor is in use by a server, the monitor cannot be removed.

NOTE:                               To configure a health monitor for Direct Server Return (DSR), see Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments.

TABLE 16    Internal Health Method Types

Type

Description

Successful If...

Configuration Required on Target Server

Database

ACOS device sends a query to the database. The database can be one of the following types:

  Oracle

  MSSQL

  MySQL

  PostgreSQL

Server sends a reply with the expected query results.

For replies that consist of multiple results, the results are in a table. You can specify the row and column loca­tion within the results table to use as the receive string.

(For more information, see Database Health Monitors.)

Database must contain the queried data.

Requested user name and password must be valid on the server.

DNS

ACOS device sends a lookup request for the specified domain name or server IP address.

By default, recursion is allowed. The tested DNS server is allowed to send the health check’s request to another DNS server if the tested server can not fulfill the request using its own data­base. Optionally, you can disable recursion.

Server sends a reply with the expected status code (0 by default) and record type (A by default).

You can configure the response code(s) and record type required for a successful health check.

You can require the server to reply with specific status codes within the range 0-15.

For health checks sent to a domain name, you can require the server to reply with one of the following record types:

  A – IPv4 address record (the default)

  CNAME – Canonical name record for a DNS alias

  SOA – Start of authority record

  PTR – Pointer record for a domain name

  MX – Mail Exchanger record

  TXT – Text string

  AAAA – IPv6 address record

(For more information, see Customizing DNS Health Monitors.)

Domain name in the lookup request must be in the server’s database.

FTP

ACOS device sends an FTP login request to the specified port.

If anonymous login is not used, the username also must be spec­ified in the health check configu­ration.

Server replies with FTP OK message or Password message.

If the server sends the Password mes­sage, the ACOS device sends the pass­word specified in the health check configuration. In this case, the ACOS device expects the server to reply with another OK message.

Requested user name and password must be valid on the server.

HTTP / HTTPS

ACOS device sends an HTTP GET, HEAD, or POST request to the specified TCP port and URL.

  GET requests the entire page.

  HEAD requests only the meta-information in the header.

  POST attempts to write infor­mation to the server. For POST requests, you must specify the target field names and the val­ues to post. (For more informa­tion, see Configuring POST Requests in HTTP/HTTPS Health Monitors.)

If a user name and password are required to access the page, they also must be specified in the health check configuration.

By default, the real server’s IP address is placed in the request header’s Host: field. You can con­figure a different value if needed.

The following types of authenti­cation are supported: basic, digest and NT LAN Manager (NTLM) authentication. If you specify a username and pass­word, the health monitor will try to use basic authentication first. If this try succeeds, the authenti­cation process is complete. Oth­erwise, the health monitor will negotiate with the server to select another authentication method, and retry the health check using that authentication method.

For HTTPS health checks, the ACOS device encapsulates SSLv3, TLSv1, TLSv1.1, or TLSv1.2 hello messages within the SSLv2 hello messages by default. You can disable this encapsulation.

Server replies with OK message (200), by default. You can configure the response code(s) and record type required for a successful health check.

For GET requests, the server also must reply with the requested content or meta-information in the page header. The response must include the string specified in the Expect field on the ACOS device.

For HEAD requests, the ACOS device ignores the Expect field and only checks for the server reply message.

For POST operations, the data must be posted without error.

Requested page (URL) must be present on the server.

For GET requests, the string specified as the expected reply must be present.

For POST operations, the field names specified in the health check must be present on the requested page.

For HTTPS health checks, SSL support must be enabled on the server.

A certificate does not need to be installed on the ACOS device. ACOS always accepts the server certificate pre­sented by the server.

ICMP

ACOS device sends an ICMP echo request (ping) to the server.

The transparent option is appli­cable for testing the path from the ACOS device to a target device through an intermediate device.

Note: This is a Layer 3 health check only. Use the other method types to check the health of a specific application.

Server replies with an ICMP echo reply message.

Server must be configured to reply to ICMP echo requests.

IMAP

ACOS device sends an IMAP user login request with the specified user parameter.

Server replies with an OK message.

The ACOS device then sends the pass­word specified in the health check configuration. The ACOS device expects the server to reply with another OK message.

Requested user name and password must be valid on the server.

Kerberos

Depending on the method options used, a Kerberos health monitor can check accessibility to each of the following:

  Key Distribution Center (KDC) Ticket Granting Ticket (TGT) service – Tests ability to access the Kerberos server as a new client requesting a TGT.

  Kerberos administrative sys­tem – Tests ability to access the Kerberos server as a user account administrator.

  Kerberos password change system – Tests ability to access the Kerberos server as a user attempting to change their password.

Kerberos server responds and allows access.

Valid administrator and end-user accounts.

LDAP

ACOS sends an LDAP request to the LDAP port.

Optionally, the request can be directed to a specific Distin­guished Name.

SSL can be enabled for the health check.

The ACOS also must send a valid password, if one is required by the server.

Server sends a reply containing result code 0.

If a Distinguished Name and password are sent in the health check, they must match these values on the LDAP server.

A certificate does not need to be installed on the ACOS device. The ACOS device always accepts the server cer­tificate presented by the server.

NTP

ACOS device sends an NTP cli­ent message to UDP port 123.

Server sends a standard NTP 48-byte reply packet.

NTP service must be running.

POP3

ACOS device sends a POP3 user login request with the specified user parameter.

Server replies with an OK message.

The ACOS device then sends the pass­word specified in the health check configuration. The ACOS device expects the server to reply with another OK message.

Requested user name and password must be valid on the server.

RADIUS

ACOS device sends a Password Authentication Protocol (PAP) request to authenticate the user name and password specified in the health check configuration.

Server sends Access-Accepted mes­sage (reply code 2).

Note: You can specify the response code(s) that ACOS can accept as valid responses. For example you can con­figure a health monitor to accept an Access-Reject response (code 3) as a valid response from a healthy RADIUS server.

Requested user name and password must be configured in the server’s user database.

Likewise, the shared secret sent in the health check must be valid on the server.

RTSP

ACOS device sends a request for information about the file speci­fied in the health check configu­ration.

Server replies with information about the specified file.

The file must be present on the RTSP server.

SIP

ACOS device sends a SIP OPTION request or REGISTER request.

Server replies with 200 - OK.

None.

SMTP

ACOS device sends an SMTP Hello message.

Server sends an OK message (reply code 250).

Server recognizes and accepts the domain of sender. If SMTP service is running and can reply to Hello messages, the server can pass the health check.

SNMP

ACOS device sends an SNMP Get or Get Next request to the speci­fied OID, from the specified com­munity.

Server replies with the value of the OID.

Requested OID and the SNMP community must both be valid on the server.

TCP

ACOS device sends a connec­tion request (TCP SYN) to the specified TCP port on the server.

Server replies with a TCP SYN ACK.

By default, the ACOS device completes the TCP handshake with the server:

 

ACOS -> Server

 

SYN ->

<- SYN-ACK

ACK ->

FIN ->

<- FIN-ACK

ACK ->

 

To configure the ACOS device to send a RST (Reset) instead of sending the first ACK, enable the Halfopen option. In this case, the health check is per­formed as follows:

 

SYN ->

<- SYN-ACK

RST ->

Destination TCP port of the health check must be valid on the server.

UDP

ACOS device sends a packet with a valid UDP header and a gar­bage payload to the specified UDP port on the server.

Server does either of the following:

  Replies from the specified UDP port with any type of packet.

  Does not reply at all.

The server fails the health check only if the server replies with an ICMP Error message.

Destination UDP port of the health check must be valid on the server.

 

Protocol Port Numbers Tested by Health Checks

If you specify the protocol port number to test in a health monitor, the protocol port number configured in the health mon­itor is used if you send an on-demand health check to a server without specifying the protocol port. (See On-Demand Health Checks.)

After you bind the health monitor to a real server port, health checks using the monitor are addressed to the real server port number instead of the port number specified in the health monitor’s configuration. In this case, you can override the IP address or port using the override options described in Overriding the Target IP Address or Protocol Port Number.

Configuring and Applying a Health Method

1.     Create a new health monitor and configure its settings for the type of service you are monitoring and the ciphers you want the monitor to use. If you created the monitor externally with a script, import the script.

NOTE: The GUI does not support selecting the SSL ciphers ACOS uses. To select SSL ciphers for the health monitor fea­ture, use the CLI.

2.     Apply the monitor to the real server (for Layer 3 checks) or service port.

You can apply a health monitor to a server or port in either of the following ways:

     Apply the health monitor to a server or port template, then bind the template to the server or port.

     Apply the health monitor directly to the individual server or port.

Configuring and Applying a Health Method Using the GUI

Configure an Internal Monitor

This example creates TCP a health monitor called “hm1:”

1.     Select ADC > Health Monitors.

2.     Click Create.

3.     In the Name field under the General Fields section, enter hm1.

4.     Click the Method type drop-down menu, and select TCP.

The rest of the configuration fields change depending on which type of health monitor you select. (See Health Method Types.)

5.     Click Create Monitor. The new monitor appears in the Health Monitor table.

Import an Externally Configured Monitor

This example imports an external monitor called “ext-hm:”

1.     Create a script for the monitor. (For an example, see Using External Health Methods.)

2.     In the GUI, select ADC > Health Monitors.

3.     From the menu bar, select the External Programs tab.

4.     Click Create.

5.     In the Name and Description fields, enter a name and description for the external health method.

6.     Copy and paste the script into the Definition field.

7.     Click Create. The method appears in the External Program Name table.

Apply a Layer 3 Health Monitor to a Real Server Template

This example shows how to apply the health monitor “hm1” to a new real server template named “rs-template.”

1.     Select ADC > Templates.

2.     Select the SLB tab from the menu bar, if not already selected.

3.     Create a real server template, and apply the health monitor to the template:

a.     Click Create to create the template, and select Server from the drop-down list.

b.     In the Name field, enter rs-template.

c.     In the Health Monitor field, select hm1 from the drop-down list or available health monitors.

d.     Click OK.

Apply a Layer 3 Health Monitor to a Real Service Port Template

This example shows how to apply the health monitor “hm1” to a new real service port template named “rsp-template.”

1.     Select ADC > Templates.

2.     Select the SLB tab from the menu bar, if not already selected.

3.     Create a real server port template, and apply the health monitor to the template:

a.     Click Create to create the template, and select Port from the drop-down list.

b.     In the Name field, enter rsp-template.

c.     In the Health Monitor field, select hm1 from the drop-down list or available health monitors.

d.     Click OK.

Apply a Layer 3 Health Monitor to an Individual Real Server or Service Port

NOTE:                               Layer 3 health checking can be CPU-intensive. To help reduce unnecessary processing overhead, if you are using Layer 4 or Layer 7 health checking of a real server’s ports, it is recommended to disable Layer 3 health checking of that server’s IP address.

1.     Select ADC > SLB.

2.     From the menu bar, select the Servers tab.

3.     Select the server or click Create to create a new one.

4.     To apply a Layer 3 health monitor to the server, select the health monitor from the Health Monitor drop-down list.

5.     To apply a health monitor to a service port:

a.     In the Port section, click Create.

b.     In the Port Number field, enter the port number.

c.     Click the Protocol drop-down menu and select TCP or UDP.

d.     Next to the Health Check, select the desired radio button from these choices:
Default, Disable, Monitor, or Follow Port 

e.     If you select the Monitor radio button, the Health Monitor drop-down menu appears. Click the menu and select the desired health monitor from the list.

6.     Enter or change other settings if needed, such as Connection Limit or No Logging.

7.     Click Create.

To apply a Layer 3 health monitor to a service group

1.     Select ADC > SLB.

2.     On the menu bar, select the Service Groups tab.

3.     Select one of the existing service groups that appear, or click Create to add a new one.

4.     Click the Health Monitor drop-down list and select the desired health monitor.

5.     Enter or change other settings if needed.

6.     Click Create or Update.

(For more information about how health monitors are used when applied to service groups, see Service Group Health Checks.)

Configuring and Applying a Health Method Using the CLI

Configure an Internal Monitor

The following example configures an internal TCP health monitor named “hm1:”

ACOS(config)# health monitor hm1

ACOS(config-health:monitor)# method tcp port 80

 

The method-name can be one of the types listed in Health Method Types. Also see that section for additional options you can specify. For syntax information, see the “Config Commands: SLB Health Monitors” chapter in the Command Line Interface Reference.

Import an Externally Configured Monitor

Create an external Tcl script for the monitor. (For an example, see Using External Health Methods.)

The following example shows how to import the external health monitor named “ext-hm” using ftp:

ACOS(config)# import health-external ext-hm ftp://examplehost/script/ext-hm

 

After the external monitor script is imported, create a new health monitor named “hm2” to use the script:

ACOS(config)# health monitor hm2

ACOS(config-health:monitor)# method external program ext-hm

 

Apply the Health Monitor to a Real Server Template or Real Service Port Template

The following example applies the health monitor “hm1” to real server template “svr-template:”

ACOS(config)# slb template server svr-template

ACOS(config-rserver)# health-check hm1

 

Apply the Monitor to an Individual Real Server or Service Port

The following example applies the health monitor “hm1” to a service port on real server “rs1:”

ACOS(config)# slb server rs1

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# health-check hm1

 

Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments

Layer 3 and Layer 4-7 health checks are supported in DSR configurations.

The target of the Layer 3 health checks can be the real IP addresses of the servers, or the virtual IP address, depending on your preference.

     To send the Layer 3 health checks to the real server IP addresses, you can use the default Layer 3 health method (ICMP).

     To send the Layer 3 health checks to the virtual IP address instead:

     Configure an ICMP health method with the transparent option enabled, and with the alias address set to the virtual IP address.

     Globally enable DSR health checking.

Layer 4-7 health checks are sent to the same IP address as the Layer 3 health checks, and then addressed to the specific pro­tocol port. You can use the default TCP and UDP health monitors or configure new health monitors. This example uses the default TCP health monitor.

NOTE:                               The following sections show how to configure Layer 3 health checking of virtual IP addresses and how to globally enable DSR health checking of virtual IP addresses. A complete DSR deployment requires additional configuration. See the examples in Direct Server Return (DSR) SLB Deployment.

NOTE:                               External health monitoring is not currently supported for DSR deployments.

Using the GUI

To configure a Layer 3 health method targeted to a virtual IP address:

1.     Select ADC > Health Monitors.

2.     Click Create. The Create Health Monitors page appears.

3.     In the Name field, enter a name for the monitor.

4.     Click the Method Type drop-down list and select ICMP. The ICMP section appears in the pane in the right.

a.     Select the Transparent checkbox in the ICMP section below.

b.     Select the desired address type, IPv4 or IPv6, and enter the loopback address.

5.     Click Create Monitor.

To globally enable DSR health checking of virtual IP addresses:

1.     Select ADC > SLB.

2.     From the menu bar, select the Global tab.

3.     Select the DSR Health Check Enable checkbox.

4.     Click Update.

Using the CLI

To configure a Layer 3 health method targeted to a virtual IP address:

Use the following commands to configure a health method target to VIP 192.168.4.4:

ACOS(config)# health monitor hm1

ACOS(config-health:monitor)# method icmp transparent 192.168.4.4

 

To globally enable DSR health checking of virtual IP addresses:

Use the following commands:

ACOS(config)# slb common

ACOS(config-common)# dsr-health-check-enable

 

(Enter the slb common command from the global configuration level to access the configuration level for system-wide SLB parameters.)

Using Send and Receive Strings in TCP Health Checks

ACOS supports use of send and receive text strings in TCP health checks. Send and receive string allow you to add additional intelligence to TCP health monitors. ACOS sends the specified send string to the target TCP port, and watches for the speci­fied reply.

For example, you can configure a send string that is an HTTP GET request, and specify the response string the server must send in reply to the GET request. (See the CLI example below.)

TCP health monitors that include send and receive strings work as follows:

1.     ACOS performs the TCP three-way handshake with the TCP port on the server:

ACOS                Server
SYN ->
                    <- SYN-ACK
ACK ->

2.     If the three-way handshake is successful, ACOS sends the entire send string to the TCP port.

ACOS                Server
ACK ->

3.     If the port’s reply contains the specified receive string anywhere within the reply, the port passes the health check.

ACOS                Server
                    <- ACK

4.     ACOS and server complete the handshake.

ACOS                Server
FIN ->
                    <- FIN-ACK
ACK ->

Using the GUI

The following example configures a TCP health monitor named “tcp-with-http-get” that sends an HTTP GET request to TCP port 80, and expects the string “200” to be present in the reply:

1.     Select ADC > Health Monitors.

2.     Click Create. The Create Health Monitors page appears.

3.     In the Name field, enter tcp-with-http-get.

4.     Click the Method Type drop-down list and select TCP. The TCP section appears.

a.     In the Send field, enter the following:

GET / HTTP/1.1\r\nHost: 22.1.2.2\r\nUser-Agent: a10\r\nAccept: */*\r\n\r\n

b.     In the Response Contains field, enter 200.

5.     Click Create Monitor.

gui_health_monitor_TCP_HTTP.png

 

 

Using the CLI

The following example configures a TCP health monitor named “tcp-with-http-get” that sends an HTTP GET request to TCP port 80, and expects the string “200” to be present in the reply:

ACOS(config)# health monitor tcp-with-http-get

ACOS(config-health:monitor)# method tcp port 80 send "GET / HTTP/1.1\r\nHost: 22.1.2.2\r\nUser-Agent: a10\r\nAccept: */*\r\n\r\n" response contains 200

 

This health monitor sends an HTTP GET request to TCP port 80 on the target server. This particular request uses the following header fields:

     Host – Specifies the host (server) to which the request is being sent.

     User-Agent – Identifies the entity (user agent) that is sending the request. In this example, the sending entity is “a10”.

     Accept – Specifies the types of media that are allowed in the response. This example uses wildcards (*/*) to indicate that any valid media type and range are acceptable.

If the string “200” is present anywhere in the reply from the port, the port passes the health check.

Certificate and Key Support in HTTPS Health Monitors

You can add an SSL certificate and key to an HTTPS health monitor. When you use this option, the ACOS device uses the cer­tificate and key during the SSL handshake with the HTTPS port on the server.

The certificate you plan to use with the health monitor must be present on the ACOS device before you configure the health monitor.

Using the GUI

1.     Select ADC > Health Monitors.

2.     Click Create. The Create Health Monitors page appears.

3.     In the Name field, enter the health monitor name.

4.     Click the Method Type drop-down list and select HTTPS. The HTTPS section appears.

a.     In the Client certificate field, select the certificate from the drop-down list.

b.     In the Client Private Key field, select the key from the drop-down list.

c.     If applicable, enter the pass phrase in the Key Password Phrase field.

5.     Click Create Monitor.

Using the CLI

To add a certificate and key to an HTTPS health monitor, use the cert and key options with the method https command.

The following commands configure an HTTPS health monitor that uses a certificate:

ACOS(config)# health monitor https-with-key

ACOS(config-health:monitor)# method https cert cert-for-health-checks key key1

 

Configuring POST Requests in HTTP/HTTPS Health Monitors

You can specify a POST operation in an HTTP or HTTPS health monitor. A POST operation attempts to post data into fields on the requested page.

Using the GUI

The following example configures an HTTP health method names “http1” that uses a POST operation to post first­name=abc and lastname=xyz to /postdata.asp on the tested server.

1.     Select ADC > Health Monitors.

2.     Click Create. The Create Health Monitors page appears.

3.     In the Name field, enter http1.

4.     In the Method Type section, select HTTP from the drop-down list. Configuration fields for HTTP health monitoring options appear.

5.     Configure an HTTP POST operation:

a.     Select the checkbox in the URL Type field.

b.     In the URL Type field, select POST from the drop-down list.

c.     In the Post Path field, enter /postdata.asp.

d.     In the Post Type field, select POST Data.

e.     In the Post Data field, enter firstname=fname&lastname=lname.

Use “=” between a field name and the value you are posting to it. If you post to multiple fields, use “&” between the fields. The string can be up to 255 bytes long.

6.     Click Create Monitor.

gui_health_monitor_HTTP_POST.png

 

Using the CLI

The following commands configure an HTTP health method names “http1” that uses a POST operation to post first­name=abc and lastname=xyz to /postdata.asp on the tested server.

ACOS(config)# health monitor http1

ACOS(config-health:monitor)# method http url POST /postdata.asp postdata first­name=fname&lastname=lname

 

In the postdata string, use “=” between a field name and the value you are posting to it. If you post to multiple fields, use “&” between the fields. For example: postdata fieldname1=value&fieldname2=value. The string can be up to 255 bytes long.

To use POST data longer than 255 bytes, you must import a POST data file and use the POST / postfile filename option. To import POST data file up to 2 Kbytes long, use the following command at the global configuration level of the CLI:

The following commands import a file containing a large HTTP POST data payload (up to 2 Kbytes), and add the payload to an HTTP health monitor:

 

ACOS(config)# import health-postfile long-post scp://exampleuser@192.168.1.1/scripts/

...

ACOS(config)# health monitor http1

ACOS(config-health:monitor)# method http url post / postfile long-post expect def

 

In this example, health checks that use this health monitor will send a POST request containing the data in “postfile”, and expect the string “def” in response.

Automatic Interval Adjust Based on HTTP Status Code

Passive health monitoring optimizes health monitoring by increasing the health-check interval when the servers are Up.

Passive health monitoring checks the HTTP status code in the initial server reply to a client request. If the server sends enough replies that contain a status code indicating normal operational status, ACOS increases the health-check interval for that server. By increasing the health-check interval, ACOS reduces network overhead.

If a server’s healthy response codes fall below a configured threshold, the health monitor’s configured interval is used again, to more frequently check server health.

Passive Health-monitoring Parameters

Passive health monitoring is activated and deactivated based on the following parameters. You can configure these parame­ters in individual HTTP health monitors.

This feature has the following configurable parameters:

     Healthy status code numbers – The set of status codes that indicate the HTTP service is healthy. You can specify one of the following:

     Any 2xx status code

     Any status code other than a 5xx code

You must specify the set of status codes to use when you configure the monitor. There is no default.

     Passive interval – The health-monitor interval that is used when passive health monitoring is activated. For proper operation of the feature, the passive interval should be longer than the health monitor’s interval. You can specify 1-180 seconds. The default is 10 seconds.

     Sample threshold – Minimum number of server replies that must contain one of the specified status codes, within a given one-second interval, before passive health monitoring is enabled. The sample threshold helps prevent passive health monitoring from taking effect after only a small total number of samples are taken. You can specify 1-10000 samples per second. The default is 50.

     Threshold – Minimum percentage of server replies that must contain a healthy status code, within a given one-sec­ond interval, before passive health monitoring is activated. You can specify 0-100 percent. The default is 75 percent. If you specify 0, this parameter is disabled, in which case there is no minimum threshold.

Passive Health-monitoring Activation

Once per second, these parameters are used to evaluate the server responses to initial client requests. Within that one-sec­ond interval:

     If, after the sample threshold is exceeded, the threshold also is exceeded, the passive interval becomes active.

     If the sample threshold and threshold are not exceeded, the health monitor’s interval setting remains in effect.

The response statistics are reevaluated each second. Generally, once a server is up and healthy, the passive interval remains in effect for that server. Overall, the health-check traffic overhead for the server is reduced by half.

Figure 150 shows an example of how passive health monitoring is activated.

FIGURE 150      Activation for passive health monitoring

health_check_activate_passive.jpg

 

In this example, the health monitor interval and each of the passive health-monitoring parameters described above are left at their default values.

When the server first comes up, the health-check interval is set to 5 seconds, which is the interval setting on the health mon­itor. The server's responses quickly exceed the sample threshold and threshold, so passive health-monitoring mode is acti­vated. this results in the health-check interval being reset t 10 seconds.

The longer interval remains in effect as long as the server responses exceed the thresholds.

Notes

     This feature applies only to TCP virtual ports, and only to the ICMP and HTTP health methods.

     Only the first packet in the reverse direction of a TCP session flow is inspected.

     If connection-reuse is enabled on the virtual port, only the response packet for the initial session is examined.

Using the GUI

1.     Navigate to ADC > Health Monitors.

2.     Click Create or click the Edit link next to the name of a configured ICMP or HTTP health monitor.

3.     If configuring a new monitor, enter a name and select the Method Type, ICMP or HTTP.

4.     Select the Passive checkbox.

5.     Customize any other settings as desired.

For information about the options, see Passive Health-monitoring Parameters.

6.     If configuring an HTTP health monitor, configure HTTP settings as applicable to your deployment.

7.     Click Create Monitor or Update Monitor.

Using the CLI

To configure inband health monitoring based on HTTP status code, use the passive command at the configuration level for the HTTP health monitor. For more information, see Passive Health-monitoring Parameters.

The following commands create a new health monitor, and enable passive health-monitoring mode:

ACOS(config)# health monitor http-passive

ACOS(config-health:monitor)# passive status-code-2xx

 

The following command sets the method to HTTP:

ACOS(config-health:monitor)# method http

 

The following commands configure a real server, service group, and virtual server. The HTTP health monitor configured above is applied to the TCP port on the real server.

ACOS(config)# slb server ser1 172.168.1.107

ACOS(config-real server)# health-check-disable

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# health-check http-passive

ACOS(config-real server-node port)# exit

ACOS(config-real server)# exit

ACOS(config)# slb service-group sg1 tcp

ACOS(config-slb svc group)# member ser1 80

ACOS(config-slb svc group-member:80)# exit

ACOS(config-slb svc group)# exit

ACOS(config)# slb virtual-server vs1 172.168.6.100

ACOS(config-slb vserver)# port 80 tcp

ACOS(config-slb vserver-vport)# service-group sg1

ACOS(config-slb vserver-vport)#

 

Customizing DNS Health Monitors

ACOS provides the following configurable options for DNS health monitors

     Expected response codes – You can specify a list of response codes, in the range 0-15, that are valid responses to a health check. If the tested DNS server responds with any of the expected response codes, the server passes the health check. By default, the expect list is empty, in which case the ACOS device expects status code 0 (No error condition).

     Recursion setting (enabled or disabled) – Recursion specifies whether the tested DNS server is allowed to send the health check’s request to another DNS server if the tested server can not fulfill the request using its own database. Recursion is enabled by default.

     Record type expected from the server – You can specify one of the following record types:

     A – IPv4 address record

     CNAME – Canonical name record for a DNS alias

     SOA – Start of authority record

     PTR – Pointer record for a domain name

     MX – Mail Exchanger record

     TXT – Text string

     AAAA – IPv6 address record

By default, the ACOS device expects the DNS server to respond to the health check with an A record.

Using the GUI

1.     Select ADC > Health Monitors.

2.     Click Create.

3.     In the General Fields section, enter a name for the monitor in the Name field.

4.     In the Method Type section, select DNS from the drop-down list. Configuration fields for DNS health monitoring options appear.

5.     If the DNS server to be tested does not listen for DNS traffic on the default DNS port (53), edit the port number in the Override Port field.

6.     To test a specific server, enter the address in the IPv4 Address field. Otherwise, to test based on a domain name sent in the health check, select Domain and enter the domain name in the Domain field.

7.     If you select Domain, select the record type the server is expected to send in reply to health checks. Select the record type from the Domain Type drop-down list.

8.     If you do not want to allows recursion, select Disabled in the IPv4 Recurse drop-down menu.

9.     To specify the response codes that are valid for passing a health check, enter the codes in the Domain Response Code field. To specify a range, use a dash. Separate the codes (and code ranges) with commas.

10.  Click Create Monitor.

gui_health_monitor_DNS.png

 

Using the CLI

To configure a DNS health monitor, use the health monitor and method dns commands.

The following commands configure a DNS health monitor that sends a query for www.example.com, and expects an Address record and any of the following response codes in reply: 0, 1, 2, 3, or 5:

ACOS(config)# health monitor dnshm1

ACOS(config-health:monitor)# method dns domain www.example.com expect response-code 0-3,5

 

DNS Health Monitoring over TCP

ACOS also supports use of DNS health monitoring over TCP.

Using the GUI

On the configuration page for the DNS health monitor, select the IPv4, IPv6, or Domain TCP option, depending on which DNS type you select.

gui_health_monitor_DNS00001.png

 

Using the CLI

To enable use of TCP instead of UDP for a DNS health monitor, use the tcp option with the method dns command.

The following example configures a health monitor for DNS over TCP:

 

ACOS(config)# health monitor dns-tcp

ACOS(config-health:monitor)# method dns domain www.example.com tcp

 

Overriding the Target IP Address or Protocol Port Number

ACOS provides options to override the real server IP address or protocol port number to which health checks are addressed.

By default, the ACOS device sends a Layer 3 health check to the IP address used in the real server configuration. Likewise, the ACOS device sends Layer 4-7 health checks to the real port number in the real server’s configuration. For GSLB service IPs, the ACOS device sends the health check to the service IP address. For example, if the configuration has a Layer 3 health monitor used by service IPs 192.168.100.100-102, the ACOS device addresses the health checks those IP addresses.

You can specify an override IP address or protocol port number in the health monitor. In this case, the ACOS device always addresses the health check to the override address or port. This option is particularly useful for testing the health of a remote link, as in the following example.

FIGURE 151      Example of Health-check Address Override

health_check_override.jpg

 

In this example, the real servers managed by the site ACOS are configured as service IPs 192.168.100.100-102 on the GSLB ACOS. The health-check metric is enabled in the GSLB policy, so health checks are needed to verify that the service IPs are healthy. One way to do so is to check the health of the ISP link connected to the site ACOS device.

Because the GSLB ACOS device is deployed in route mode instead of transparent mode, the transparent option for ICMP health monitors can not be used to check the remote end of the path. In this case, the health monitor can be configured with an override IP address, 192.168.1.1, to check the health of the ISP link to the site where the servers are located. When the ACOS device in this example uses the health monitor to check the health of a service IP, the device addresses the health check to 192.168.1.1, the override address, instead of addressing the health check to the service IP addresses.

Override Parameters

You can independently configure any of the following override parameters for a health monitor:

     Target IPv4 address

     Target IPv6 address

     Target Layer 4 protocol port number

The override is used only if applicable to the method (health check type) and the target. An IP address override is applicable only if the target has the same address type (IPv4 or IPv6) as the override address.

A protocol port override is applicable to all health methods except ICMP. If the protocol port number is explicitly configured for the method, the override port number is still used instead.

Using The GUI

1.     Select ADC > Health Monitors.

2.     Click edit next to the health monitor name or click Create to create a new one.

3.     For an ICMP health monitor:

a.     Leave ICMP selected in the Method Type drop-down list.

b.     Enter the target IP address of the health monitor, in the Override IPv4 or Override IPv6 field.

4.     For other health methods, select the type, then enter the target protocol port number in the Override Port field.

5.     Click Create Monitor or Update Monitor. The health monitor list re-appears.

Using The CLI

Use the override-ipv4, override-ipv6, or override-port commands at the configuration level for the health moni­tor.

The following example configures a health monitor for the service IPs shown in FIGURE 151   , and apply the mon­itor to the service IPs.

ACOS(config)# health monitor site1-hm

ACOS(config-health:monitor)# method icmp

ACOS(config-health:monitor)# override-ipv4 192.168.1.1

ACOS(config-health:monitor)# exit

ACOS(config)# gslb service-ip gslb-srvc1 192.168.100.100

ACOS(config-service-ip:gslb-srvc1)# health-check site1-hm

ACOS(config-service-ip:gslb-svrc1)# exit

ACOS(config)# gslb service-ip gslb-srvc2 192.168.100.101

ACOS(config-service-ip:gslb-srvc2)# health-check site1-hm

ACOS(config-service-ip:gslb-srvc2)# exit

ACOS(config)# gslb service-ip gslb-srvc3 192.168.100.102

ACOS(config-service-ip:gslb-srvc3)# health-check site1-hm

Basing a Port’s Health Status on Another Port’s Health Status

You can configure the ACOS device to base a real port’s health status on the health status of another port number.

Both the real port and the port to use for the real port’s health status must be the same type, TCP or UDP.

Using the GUI

1.     Navigate to the configuration page for the real server (ADC >> SLB >> Servers > server_name >> Port >> Create).

2.     Select Follow Port in the Health Check field.

a.     Select TCP or UDP from the drop-down list in the Follow Port Protocol field.

b.     In the Follow Port field, enter the port number upon which you want to base the health of the real port.

gui_health_DNS_follow_port.PNG

3.     Click Create.

Using the CLI

Use the health-check-follow-port command at the configuration level for the real port.

The following example configures the real port to follow TCP port 8081:

ACOS(config)# slb server rs1

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# health-check-follow-port 8081 tcp

 

Service Group Health Checks

You can assign a health monitor to a service group. This feature is useful in cases where the same server provides content for multiple, independent sites. When you use this feature, if a site is unavailable (for example, is taken down for maintenance), the server will fail the health check for that site, and clients will not be sent to the site. However, other sites on the same server will pass their health checks, and clients of those sites will be sent to the server.

Figure 152 shows an example.

FIGURE 152      Service Group Health Checks

health_check_service_group.jpg

 

In this example, a single server provides content for the following sites:

     www.media-rts.com

     www.media-tuv.com

     www.media-wxyz.com

All sites can be reached on HTTP port 80 on the server. The health check configured on the port in the real server configura­tion results in the same health status for all three sites. All of them either are up or are down.

In this case, if one of the sites is taken down for maintenance, the health status of that site will still be up, since the real port still responds to the health check configured on the port.

You can configure the ACOS device to separately test the health of each site, by assigning each site to a separate service group, and assigning a separate Layer 7 health monitor to each of the service groups. In this case, if a site is taken down for maintenance, that site fails its health check while the other sites still pass their health checks, on the same real port.

In this example, a separate HTTP health method is configured for each of the services. The health monitors test the health of a site by sending an HTTP request to a URL specific to the site. In this way, even though the server’s HTTP port is up, a site will fail its health check if the URL requested by its health check is unavailable.

Priority of Health Checks

Service group health status applies only within the context of the service group. For example, a health check of the same port from another service group can result in a different health status, depending on the resource requested by the health check.

Health checks can be applied to the same resource (real server or port) at the following levels:

     In a service group that contains the server and port as a member

     In a server or server port configuration template that is bound to the server or port

     Directly on the individual server or port

In cases where health checks are applied at multiple levels, they have the following priority:

1.     Health check on real server

2.     Health check on real server’s port

3.     Health check on service group

If a health check at the real server level (1) fails, the corresponding real server, real server port, and service group members are marked Down. However, if a health check on the service group level (3) fails, only that service group member in that ser­vice group is marked Down.

To assign a health monitor to a service group, use either of the following methods.

Using the GUI

In the Service Group configuration page (ADC >> SLB >> Service Groups >> Update), select the monitor from the drop-down list in the Health Monitor field.

Using the CLI

The commands in this section implement the configuration shown in Figure 152.

The following commands configure the health monitors for each site on the server:

ACOS(config)# health monitor qrs

ACOS(config-health:monitor)# method http url GET /media-qrs/index.html

ACOS(config-health:monitor)# exit

ACOS(config)# health monitor tuv

ACOS(config-health:monitor)# method http url GET /media-tuv/index.html

ACOS(config-health:monitor)# exit

ACOS(config)# health monitor wxyz

ACOS(config-health:monitor)# method http url GET /media-wxyz/index.html

ACOS(config-health:monitor)# exit

 

The following commands configure the real server:

ACOS(config)# slb server media-rs 10.10.10.88

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# exit

ACOS(config-real server)# exit

 

The following commands configure the service groups:

ACOS(config)# slb service-group qrs tcp

ACOS(config-slb svc group)# health-check grs

ACOS(config-slb svc group)# member media-rs 80

ACOS(config-slb svc group-member:80)# exit

ACOS(config-slb svc group)# exit

ACOS(config)# slb service-group tuv tcp

ACOS(config-slb svc group)# health-check tuv

ACOS(config-slb svc group)# member media-rs 80

ACOS(config-slb svc group-member:80)# exit

ACOS(config-slb svc group)# exit

ACOS(config)# slb service-group wxyz tcp

ACOS(config-slb svc group)# health-check wxyz

ACOS(config-slb svc group)# member media-rs 80

ACOS(config-slb svc group-member:80)# exit

ACOS(config-slb svc group)# exit

 

The following commands configure the virtual servers:

ACOS(config)# slb virtual-server media-qrs 192.168.1.10

ACOS(config-slb vserver)# port 80 http

ACOS(config-slb vserver-vport)# service-group qrs

ACOS(config-slb vserver-vport)# exit

ACOS(config-slb vserver)# exit

ACOS(config)# slb virtual-server media-tuv 192.168.1.11

ACOS(config-slb vserver)# port 80 http

ACOS(config-slb vserver-vport)# service-group tuv

ACOS(config-slb vserver-vport)# exit

ACOS(config-slb vserver)# exit

ACOS(config)# slb virtual-server media-wxyz 192.168.1.12

ACOS(config-slb vserver)# port 80 http

ACOS(config-slb vserver-vport)# service-group wxyz

ACOS(config-slb vserver-vport)# exit

ACOS(config-slb vserver) #exit

 

Disable Following Failed Health Check

You can configure the ACOS device to disable a server, port, or service group if the server, port, or service group fails a health check.

This option applies to all servers, ports, or service groups that use the health monitor. When a server, port, or service group is disabled based on this command, the server, port, or service group’s state is changed to disable in the running-config. If you save the configuration while the server, port, or service group is disabled, the state change is written to the startup-con­fig.

ACOS also generates a log message to indicate that the server, port, or service group is disabled.

The server, port, or service group remains disabled until you explicitly enable it.

This option is disabled by default. (A server, port, or service group that uses the health monitor is not disabled if it fails a health check.)

Using The CLI

Use the following commands:

ACOS(config)# health monitor hm1

ACOS(config-helath:monitor)# disable-after-down

 

In-Band Health Monitoring

In-band health checks are an optional supplement to the standard Layer 4 health checks. In-band health checks assess ser­vice port health based on client-server traffic, and can very quickly send a client’s traffic to another server and port if neces­sary. An in-band health check can also mark a port down.

In-band health monitoring is supported for the following service types:

     TCP

     HTTP

     HTTPS

Relationship To Standard Layer 4 Health Monitoring

The in-band health check works independently of and supplements the standard Layer 4 health check. For example, for TCP, the standard health check works as follows by default:

Every 30 seconds, the ACOS device sends a connection request (TCP SYN) to the specified TCP port on the server. The port passes the health check if the server replies to the ACOS device by sending a TCP SYN ACK.

This is the same Layer 4 health check available in previous releases and has the same defaults.

In-band health monitoring works as described below.

NOTE:                               It is recommended that you continue to use standard Layer 4 health monitoring even if you enable in-band health monitoring. Without standard health monitoring, a server port marked down by an in-band health check remains down.

How In-Band Layer 4 Health Monitoring Works

In-band health monitoring for services on TCP watches client-server SYN handshake traffic, and increments the following counters if the server does not send a SYN ACK in reply to a SYN:

     Retry counter – Each client-server session has its own retry counter. the ACOS device increments a session’s retry counter each time a SYN ACK is late. If the retry counter exceeds the configured maximum number of retries allowed, the ACOS device sends the next SYN for the session to a different server. ACOS also resets the retry counter to 0.

You can set the retry counter to 0-7 retries. The default is 2 retries.

     Reassign counter – Each real port has its own reassign counter. Each time the retry counter for any session is exceeded, the ACOS device increments the reassign counter for the server port. If the reassign counter exceeds the configured maximum number of reassignments allowed, the ACOS device marks the port DOWN.

In this case, the port remains DOWN until the next time the port successfully passes a standard health check. Once the port passes a standard health check, the ACOS device starts using the port again and resets the reassign counter to 0.

You can set the reassign counter to 0-255 reassignments. The default is 25 reassignments.

In-band health monitoring is disabled by default.

Logging and Traps

When the ACOS device marks a server port down, the device generates a log message and an SNMP trap, if logging or SNMP traps are enabled. The message and trap are the same as those generated when a server port fails a standard health check. However, you can discern whether the port was marked down due to a failed in-band health check or standard health check, based on the process name listed in the message.

     A10lb – The port was marked down by an in-band health check.

     A10hm – The port was marked down by a standard health check.

Here is an example of a log message generated from each process:

Sep 08 2014 17:15:04 Info    A10LB SLB server s-3-2-1 (10.3.2.1) port 80 is down.

Sep 08 2014 17:15:04 Info    A10HM SLB server s-3-2-1 (10.3.2.1) port 80 is down.

In-band health monitoring does not mark ports up. Only standard health monitoring marks ports up. So messages and traps for server ports coming up are generated only by the A10hm process.

Configuring In-Band Health Monitoring

To configure in-band health monitoring:

1.     Enable the feature in a server port template.

2.     Bind the port template to real server ports, either directly or in a service group.

Using The GUI

To configure in-band health monitoring in server port template:

1.     Select ADC > Template.

2.     Click the Edit link in the Actions column for an existing tempalte, or click Create and select Port from the drop-down list to create a new port template.

3.     Select the checkbox in the Inband Health Check field.

4.     Enter other parameters as needed (for example, the template name, if you are creating a new template).

5.     Click OK or Update.

To bind the template to a server port, see Binding a Server Port Template to a Real Server Port.

Using The CLI

To configure in-band health monitoring, use the inband-health-check command at the configuration level for the server port template:

The following example enables in-band health monitoring in a server port template called rp-tmplt2 and binds this template to real ports 80 on server rs1, and real port 80 on server rs2:

ACOS(config)# slb template port rp-tmplt2

ACOS(config-rport)# inband-health-check

ACOS(config-rport)# exit

ACOS(config)# slb server rs1 10.1.1.99

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# template port rp-tmplt2

ACOS(config-real server-node port)# exit

ACOS(config-real server)# exit

ACOS(config)# slb server rs2 10.1.1.100

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# template port rp-tmplt2

ACOS(config-real server-node port)# exit

ACOS(config-real server)# exit

 

Consecutive Health Checks Within a Health Check Period

You can configure the number of times the target device must consecutively reply to the same periodic health check in order to pass the health check.

By default, a server or port needs to successfully reply to a given health check only one time in order to pass the health check. The server or port is then considered to be up until the next periodic health check. You can set the required number of consecutive passes to 1-10.

You can configure this parameter on an individual health monitor basis. The setting applies to all health checks that are per­formed using the health monitor.

Using the GUI

1.     Select ADC > Health Monitors.

2.     Click on the Edit button next to the monitor name or click Create to add a new one.

3.     If new, in the General Fields section, enter a name for the monitor.

4.     If new, in the Method Type section, select the monitor type from the drop-down list, and enter or select settings for the monitor.

5.     Select the checkbox in the Passive field.

6.     In the Passive Interval field, enter the number of consecutive times the target must pass the same periodic health check.

7.     Click Create Monitor or Update Monitor.

Using the CLI

To configure consecutive health checks using the CLI, use the up-retry command. For example:

ACOS(config)# health monitor hm1

ACOS(config-health:monitor)# up-retry 3

 

Maintenance Health Status for Servers in Persistence Configurations

You can use the response to an HTTP or HTTPS health check to set a server’s health status to “Maintenance”. When a server’s health status is Maintenance, the server will accept new requests on existing cookie-persistent or source-IP persistent con­nections, but will not accept any other requests.

To place a server into maintenance mode, configure an HTTP or HTTPS health method that includes a maintenance code. If the server replies to a health check with the code, the ACOS device changes the server’s health status to Maintenance.

To leave maintenance mode, the server must do one of the following:

     Successfully reply to a health check, but without including the maintenance code. In this case, the server’s health sta­tus changes to Up.

     Fail a health check. In this case, the server’s status changes to Down.

The Maintenance health status applies to server ports and service-group members. When a port’s status changes to Mainte­nance, this change applies to all service-group members that use the port.

NOTE:                               This feature applies only to servers in cookie-persistence or source-IP persistence config­urations, and can be used only for HTTP and HTTPS ports.

Using the CLI

Use the maintenance-code code-list option with one of the following commands at the configuration level for a health method:

http options

https options

CLI Example

The following commands configure a health monitor that places a server into maintenance mode if the server replies to a health check with code 503:

ACOS(config)# health monitor hm2

ACOS(config-health:monitor)# method http maintenance-code 503

 

In this example, if the server replies with status 503, the server goes into maintenance mode and stays there until server replies with status code 200 (UP).

In this example, if the server replies with code 503, the server goes into maintenance mode, and stays there until the server either fails a health check (Down) or replies with code 200 (Up).

On-Demand Health Checks

You can easily test the health of a server or individual service at any time, using the default Layer 3 health monitor (ICMP ping) or a configured health monitor.

Using the CLI

To test the health of a server, use the health-test command at the EXEC, Privileged EXEC, or global configuration level of the CLI:

NOTE:                               If an override IP address and protocol port are set in the health monitor configuration, the ACOS device will use the override address and port, even if you specify an address and port when you send the on-demand health check.

CLI Example

The following command tests port 80 on server 192.168.1.66, using configured health monitor hm80:

ACOS# health-test 192.168.1.66 monitorname hm80

node status UP.

Enabling Strict Retries

Some types of health monitors do not use the retry parameter by default. For these health monitors, the ACOS device marks the server or port Down after the first failed health check attempt, even if the retries option for the health monitor is set to higher than 0.

For example, this is true for HTTP health monitors that expect a string in the server reply. If the server’s HTTP port does not reply to the first health check attempt with the expected string, the ACOS device immediately marks the port Down.

To force the ACOS device to wait until all retries are unsuccessful before marking a server or port down, enable strict retries. You can enable strict retries on an individual health monitor basis.

Using the CLI

The following example configures an HTTP health monitor that checks for the presence of “testpage.html”, and enable strict retries for the monitor.

ACOS(config)# health monitor http-exhaust

ACOS(config-health:monitor)# method http url GET /testpage.html

ACOS(config-health:monitor)# strict-retry-on-server-err-resp

 

Globally Changing Health Monitor Parameters

You can globally adjust health monitor parameters, including the following:

     Interval – Number of seconds between health check attempts.

     Timeout – Number of seconds the ACOS device waits for a reply to a health check.

     Retries – maximum number of times the ACOS device will send the same health check to an unresponsive server or service before marking that server or service as down.

     Up-Retry – Number of consecutive times the device must pass the same periodic health check, in order to be marked Up.

Globally changing a health monitor parameter changes the default for that parameter. For example, if you globally change the interval from 5 seconds to 10 seconds, the default interval becomes 10 seconds.

If a parameter is explicitly set on a health monitor, globally changing the parameter does not affect the health monitor. For example, if the interval on health monitor hm1 is explicitly set to 20 seconds, the interval remains 20 seconds on hm1 regard­less of the global setting.

NOTE:                               Global health monitor parameter changes automatically apply to all new health moni­tors configured after the change. To apply a global health monitor parameter change to health monitors that were configured before the change, you must reboot the ACOS device.

NOTE:                               When the auto-adjust mode for health-check rate limiting is enabled, and the global interval or timeout setting differs from the setting on an individual health monitor, the actual interval and timeout values that are used depend on the number of health checks performed by the ACOS device. (See Health-Check Rate Limiting.)

To globally change health monitor parameters, use the following commands:

health global

Enter this command at the global configuration level. Then, for a list of commands, enter ?

CLI Example

The following commands globally changes the default number of retries to 5:

ACOS(config)# health global

ACOS(config-health:global)# retry 5

 

The following commands globally changes the timeout to 10 seconds and default number of retries to 4:

ACOS(config)# health global

ACOS(config-health:global)# timeout 10 retry 4

 

Globally Disabling Layer 3 Health Checks

Layer 3 health checks (ICMP pings) are enabled by default. For very large deployments (1000 or more servers), A10 Networks recommends disabling the default Layer 3 health check, and using only Layer 4-7 health checks.

To globally disable Layer 3 health checks, disable health monitoring in the server templates used to configure the servers. If you did not configure a customized server template, the default server template is used.

NOTE:                               If a custom Layer 3 health monitor is enabled on an individual server, the health monitor is still used.

Using the CLI

Use the health-check-disable command to disable Layer 3 health monitoring in the template:

ACOS(config)# slb template server default

ACOS(config-rserver)# health-check-disable

 

Health-Check Rate Limiting

Health-check rate limiting helps ensure that health checks in large SLB deployments can be processed successfully. In previ­ous releases, without health-check rate limiting, it is possible for a server or port to fail its health check because the ACOS device is unable to complete processing of the health check before it times out.

NOTE:                               Health-check rate limiting is enabled by default. Generally, you do not need to configure it. However, you still may want to see the following section: Health-Check Guidelines.

Health-check rate limiting uses a threshold to limit the number of health-check packets the ACOS device will send within a given 500-millisecond (ms) period. If additional health-check packets need to be sent, the ACOS device waits until the next 500-ms period. Within any 500-ms period, the ACOS device never sends more health-check packets than are allowed by the threshold.

Health-check rate limiting has an auto-adjust mode, which is enabled by default. When necessary, the auto-adjust mode dynamically increases the default interval and timeout for health checks. By increasing these timers, health-check rate limit­ing provides more time for health-check processing.

Health-check rate limiting is always enabled, and its auto-adjust mode is enabled by default.

Health-check Threshold

When auto-adjust mode is enabled, the health-check threshold is one of the following:

     ACOS models with 64-bit ACOS – 1600 health-check packets per 500-ms period

     ACOS models with 32-bit ACOS – 800 health-check packets per 500-ms period

When auto-adjust mode is enabled, you can not manually change the threshold. To change the threshold, you first must dis­able auto-adjust mode. Then you can set the threshold to a value within one of the following ranges:

     ACOS models with 64-bit ACOS – 1-5000 health-check packets per 500-ms period

     ACOS models with 32-bit ACOS – 1-2000 health-check packets per 500-ms period

When you disable auto-adjust mode, the default threshold is changed to one of the following:

     ACOS models with 64-bit ACOS – 1000 health-check packets per 500-ms period

     ACOS models with 32-bit ACOS – 400 health-check packets per 500-ms period

NOTE:                               It is recommended not to set the threshold to a very high value. Doing so may result in health-check timeouts due to resource constraints.

Health-Check Interval and Timeout

When the auto-adjust mode for health-check rate limiting is enabled, and the global interval or timeout setting differs from the setting on an individual health monitor, the actual interval and timeout values that are used depend on the number of health checks performed by the ACOS device:

     More than 1000 health checks (64-bit models) or more than 400 health checks (32-bit models) – Setting with the lon­ger value is used. For example, if the global interval is 10 seconds but the interval configured on an individual health monitor is 5 seconds, 10 seconds is used.

     Fewer than 1000 health checks (64-bit models) or fewer than 400 health checks (32-bit models) – Setting on the indi­vidual health monitor is used.

Using the CLI

To display the current settings for health-check rate limiting, use the show health stat command. Here is an example:

ACOS(config)# show health stat

Health monitor statistics

Total run time:                       : 21 hours 31 minutes 31 seconds

Number of burst:                      : 0

...

Configured health-check rate (/500ms) : Auto configured

Current health-check rate (/500ms):   : 5

...

The Configured health-check rate field and Current health-check rate show the health-check rate limiting settings.

     If auto-adjust is enabled:

     Configured health-check rate – Shows “Auto configured”

     Current health-check rate – Shows the total number of health monitors divided by the global health-check timeout:
total-monitors / global-timeout

     If auto-adjust is disabled:

     Configured health-check rate – Shows the manually configured threshold

     Current health-check rate – Shows the manually configured threshold

Changing the Threshold

To change the health-check rate limiting threshold:

ACOS(config)# health global

ACOS(config-health:global)# disable-auto-adjust

ACOS(config-health:global)# check-rate 2000

 

Multi-CPU Support for Health Monitoring

ACOS includes a scalability feature that enables use of multiple CPUs for health-monitor processing.

NOTE:                               Ensure that the health-monitor process number does not exceed the current number of control CPUs.

The maximum value for the health check-rate is 50000000.

Use the GUI to Configure Multi-CPU Support

To configure multi-CPU support from the GUI:

1.     Navigate to ADC >> Health Monitors >> Global.

2.     Select the number of CPUs from the drop-down list in the Multi Process field.

3.     Click Update.

Use the CLI to Configure Multi-CPU Support

Use the following commands to specify 2 processes to start health monitoring.

ACOS(config)# health global

ACOS(config-health:global)# multi-process 2

 

You can monitor up to 20 processes, with the default value being 1.

It is recommend that you use this feature with multiple control CPUs. ACOS should be configured to run multiple control CPUs before issuing the health multi-process command. For example:

ACOS(config)# multi-ctrl-cpu 2

This will modify your boot profile for multiple control CPUs.

It will take effect after the next reboot.

Please confirm: You want to configure multiple control CPUs (N/Y)?: y

Database Health Monitors

You can configure database health monitors using the CLI or GUI, without the need to configure and import scripts. Previous releases support database health monitors only with imported scripts.

Simplified database health monitor configuration applies to the following database types:

     Oracle

     MSSQL

     MySQL

     PostgreSQL

Database Health Monitor Parameters

To configure a database health monitor, specify the following parameters.

Required Parameters

     Database type – Oracle, MSSQL, MySQL, or PostgreSQL

     Database name – Name of the database to query

     Username and password – Account information required for access to the database

Optional Parameters

     Send string – SQL query to send to the database.

     Receive string – Query result expected from the database in order to pass the health check.

     Receive row and column – For replies that consist of multiple results, the results are in a table. You can specify the row and column location within the results table to use as the receive string. If you do not specify the row and column, row 1 and column 1 are queried by default.

NOTE:                               To use the receive string option, you also must use the send string option. If you do not use the send option, the ACOS device does not send a query.

Using the GUI

To create a new database health monitor:

1.     Hover over ADC in the menu bar, then select Health Monitors.

2.     Select Create.

3.     In the Name field, specify a name for your health monitor.

4.     In the Method type field, select Database from the drop-down list.

5.     Configure the desired values in the General Fields pane.

6.     In the Database pane, select the database type from the Database Type field, then complete the other parameters.

7.     Click Create Monitor.

Using the CLI

The example in this section shows how to create an Oracle database health monitor:

ACOS(config)# health monitor dbhm1

ACOS(config-health:monitor)# method database oracle db-name orcl1 username admin password welcome1

 

For additional information, see Database Health Monitor Parameters.

Kerberos Health Monitors

ACOS provides health monitoring for Kerberos AAA servers. A Kerberos health monitor can contain separate methods for checking accessibility to each of the following:

     Key Distribution Center (KDC) Ticket Granting Ticket (TGT) service – Tests ability to access the Kerberos server as a new client requesting a TGT.

     Kerberos administrative system – Tests ability to access the Kerberos server as a user account administrator.

     Kerberos password change system – Tests ability to access the Kerberos server as a user attempting to change their password.

These services can be on the same server (hostname or IP address) or different servers.

You can use these health checks in AAA SLB deployments and in Authentication Proxy deployments.

NOTE:                               Health checks for access to the Kerberos administrative system are not supported with Windows Server Domain Controllers (DCs).

Using the GUI

1.     Navigate to ADC >> Health Monitors.

2.     Click Create.

3.     Specify kerb-hm1 in the Name field.

4.     Select “Kerberos KDC” from the drop-down list in the Method type field.

5.     Complete the necessary fields in the Kerberos KDC field

FIGURE 153      ADC >> Health Monitors >> Create >> Kerberos KDC

gui_health_monitor_kerberos.PNG

6.     .Click Create Monitor.

 

Using the CLI

To configure a Kerberos health monitor, use the commands described in this section.

The following commands create a Kerberos health check method to check accessibility of the KDC for obtaining a TGT (“acos-1” is the name of the ACOS device:

ACOS(config)# health monitor kerb-hm1

ACOS(config-health:monitor)# method kerberos-kdc kinit acos-1 examplepassword examplekd­chost

 

The following command configures a Kerberos health check method to check accessibility of the Kerberos server for user account administration (“acos-1” is the name of the ACOS device):

ACOS(config-health:monitor)# method kerberos-kdc kadmin examplerealm acos-1 examplepass­word examplekdchost exampleadminhost

 

The following example configures a Kerberos health method to check accessibility of the Kerberos server for user password changes (“acos-1” is the name of the ACOS device):

ACOS(config-health:monitor)# method kerberos-kdc lpasswd acos-1 examplepassword examplekd­chost examplepwdhost

 

Compound Health Monitors

Compound health monitors enable you to combine the status of multiple health checks into a single result. ACOS uses the combined results of individual health checks to determine the health of the real server, port, or service group to which the compound health monitor is applied.

NOTE:                               The compound server health status may report as Down due to incorrect timeout or interval parameters. (See Considerations.)

NOTE:                               Compound health monitoring increases the workload of the health monitoring subsys­tem. For example, using a compound monitor with many sub monitors against a service group with many members can affect system performance. This increased workload could significantly delay the response time for compound health checks.

Compound Health Monitor syntax

A compound health monitor consists of a set of health monitors joined in a Boolean expression (AND / OR / NOT).

The CLI Boolean expression syntax is based on Reverse Polish Notation (also called Postfix Notation), a notation method that places an operator (AND, OR, NOT) after all of its operands (in this case, health monitors).

After listing the health monitors, add the Boolean operator(s). The following operators are supported:

     AND – Both the ANDed health checks must be successful for the health status to be Up. If either of the health checks is unsuccessful, the health status is Down.

     OR – Either of the ORed health checks must be successful for the result to be Up. Even if one of the health checks is unsuccessful, the health status is still Up if the other health check is successful. If both of the health checks are unsuc­cessful, the health status is Down.

     NOT – The health status is the opposite of the health check result. For example, if a health check is unsuccessful, the resulting health status is Up. Likewise, if the health check is successful, the resulting health status is Down. You can use NOT with a single health method, or with multiple health methods for more complex expressions. (See below.)

For example, to construct a health monitor that ANDs two health monitors, use the following syntax:

method compound sub hm1 sub hm2 AND

This is logically equivalent to the following expression: hm1 & hm2

NOTE:                               In the CLI, you must enter method compound at the beginning, and sub in front of each health-monitor name. In the GUI, do not enter method compound. The GUI auto­matically enters sub in front of each health monitor name when you select it.

NOTE:                               The equivalent expressions are shown for clarity but are not valid syntax on the ACOS device.

Similarly, to construct a health monitor that ORs two health monitors, use the following syntax:

method compound sub hm1 sub hm2 OR

This is logically equivalent to the following expression: hm1 | hm2

To construct a health monitor that results in an Up health status if the health check is unsuccessful, use the following syntax:

method compound sub hm1 NOT

This is logically equivalent to the following expression: ! hm1

To construct more complex expressions, you can enter multiple sets of health monitors and operators. Here is a quite com­plex expression:

(! (hm1 | (hm2 & (hm3 | (! hm4))))) | hm5

To configure this expression, use the following syntax:

method compound sub hm1 sub hm2 sub hm3 sub hm4 NOT OR AND OR NOT sub hm5 OR

Considerations

     A maximum of 8 sub monitors are supported in a compound monitor. To use more sub monitors, you can nest com­pound monitors. (See below.)

     The total number of sub monitors plus the number of Boolean operators supported in a compound monitor is 16.

     You can nest compound monitors. To nest compound monitors, configure a compound monitor, then use that com­pound monitor as a sub monitor in another compound monitor. The maximum nesting depth is 8.

Nesting loops are not allowed.

     The timeout and interval parameters of a compound monitor must be set to values that allow each of the sub moni­tors to complete their health checks. If any of the sub monitors is unable to complete its health check, the compound monitor’s result is always Down.

For example, if monitor1 gives a result after 2 seconds, but a compound monitor that uses monitor1 times out in 1 sec­ond, the resulting health status will always be Down, regardless of the Boolean expression. (See Timeout Configuration.)

NOTE:                               If you encounter this problem, A10 Networks recommends you increase the timeout parameter for the compound monitor to ensure the health check can cycle through all sub monitors. (See Configuring and Applying a Health Method.) You alter­natively can decrease the number of retry attempts for sub monitor health checks to 1. (See Consecutive Health Checks Within a Health Check Period”.)

Using the GUI

1.     Configure the sub monitors first.

2.     Click Create on the health monitor list to begin configuration of a new monitor.

3.     In the Method Type section, select Compound from the drop-down list. The Compound configuration controls appear.

4.     Construct the Boolean expression:

NOTE:                               Make sure to use Reverse Polish Notation. (See Compound Health Monitor syntax.) Otherwise, the GUI will display an error message when you click OK to com­plete the health monitor configuration.

5.     Click Create Monitor to complete the configuration of the compound monitor.

FIGURE 154      Compound Health Monitor Configuration

gui_health_monitor_compound.png

 

Using the CLI

To configure a compound health monitor, use the method compound command to add a Boolean expression at the config­uration level for the monitor:

NOTE:                               Make sure to use Reverse Polish Notation. (See Compound Health Monitor syntax.)

The following commands configure a compound health monitor in which both health checks must be successful in order for the resulting health status to be Up:

ACOS(config)# health monitor hm-compoundAND

ACOS(config-health:monitor)# method compound sub hm1 sub hm2 AND

 

The following commands apply the health monitor to a service group:

ACOS(config)# slb service-group sg1 tcp

ACOS(config-slb svc group)# health-check hm-compoundAND

 

The following commands configure a compound health monitor in which the resulting health status is Up if any one ore more of the health checks is successful:

ACOS(config)# health monitor hm-compoundOR

ACOS(config-health:monitor)# method compound sub hm1 sub hm2 sub hm3 OR

 

The following commands apply the health monitor to a service group:

ACOS(config)# slb service-group sg2 tcp

ACOS(config-slb svc group)# health-check hm-compoundOR

 

NOT Operator

The following commands configure a compound health monitor that results in an Up status only if the server fails the ICMP health check:

ACOS(config)# health monitor icmp

ACOS(config-health:monitor)# retry 1

ACOS(config-health:monitor)# exit

ACOS(config)# health monitor not-ping

ACOS(config-health:monitor)# interval 11 timeout 11

ACOS(config-health:monitor)# method compound sub icmp not

 

Timeout Configuration

For a compound health check configured as follows:

ACOS(config)# health monitor monitor1 interval 3 retry 2 timeout 3

ACOS(config-health:monitor)# interval 3 timeout 3

ACOS(config-health:monitor)# retry 2

ACOS(config-health:monitor)# method tcp port 80

ACOS(config-health:monitor)# exit

ACOS(config)# health monitor monitor2

ACOS(config-health:monitor)# interval 5 timeout 5

ACOS(config-health:monitor)# retry 1

ACOS(config-health:monitor)# method tcp port 8080

ACOS(config-health:monitor)# exit

ACOS(config)# health monitor compound-monitor

ACOS(config-health:monitor)# interval 6 timeout 6

ACOS(config-health:monitor)# retry 3

ACOS(config-health-monitor)# method compound sub monitor1 sub monitor2 and

 

The amount of time allowed to perform health checks for monitor1 and monitor2 is calculated by the retry and timeout val­ues.

For this example, a compound health check requires a minimum of 10 seconds. If the timeout value for the compound health check is set to 6, then the result is always Down. In order to ensure a complete compound health check, set the com­pound health check timeout to 10 seconds or greater.

Configurable Response Codes for RADIUS Health Monitors

By default, ACOS requires a RADIUS server to reply to RADIUS health checks with an Access-Accept message (response code 2, by default).

In previous releases, code 2 was the only code the server is allowed to respond with, in order to be marked UP, but beginning in ACOS 2.7.2, you can specify the response code(s) that ACOS can accept as valid responses. So, for example, you can config­ure a health monitor to accept an Access-Reject response (code 3) as a valid response from a healthy RADIUS server.

To specify the response code(s) a RADIUS server is allowed to send back in response to a RADIUS health check, use the expect response-code option with the method command.

The following commands configure a RADIUS health monitor that accepts response code 2 or 3 as passing (healthy) responses from a server:

ACOS(config)# health monitor rad1

ACOS(config-health:monitor)# method radius port 1812 expect response-code 2,3 secret a10rad username admin1 password examplepassword

 

Displaying Health Status

ACOS begins sending health checks to a real server’s IP address and service ports as soon as you finish configuring the server. You can display health status for virtual servers and service ports, and for the real servers and service ports used by the virtual server.

To display health status, use the following methods.

Use The GUI to View Health Status

This section contains the following:

     Use the GUI to View the Health of Virtual Servers and Service Ports

     Use the GUI to View the Health of Real Servers and Service Ports

Use the GUI to View the Health of Virtual Servers and Service Ports

To do this:

1.     Select ADC > SLB.

The virtual servers are listed at the top of the page. An icon appears next to each virtual server to indicate the health status.

2.     To display more specific health information for a virtual server’s service ports, click on the virtual server name.

Use the GUI to View the Health of Real Servers and Service Ports

To do this:

1.     Select ADC > SLB.

2.     On the menu bar, select the Servers tab.

An icon appears next to each real server to indicate the health status.

3.     To display more specific health status information for a real server’s service ports, click on the server name.

For information about the real server health state icons, see the online help or GUI Reference.

Use the CLI to View Health Status

This section contains the following:

     Use the CLI to View the Health of Virtual Servers and Service Ports

     Use the CLI to View the Health of Real Servers and Service Ports

     Use the CLI to View Health Monitoring Statistics

Use the CLI to View the Health of Virtual Servers and Service Ports

Use the show slb virtual-server command to view the health of virtual servers and service ports. The health status is shown in the State field; for additional information about this command and the fields in the output, see the CLI Reference.

ACOS# show slb virtual-server "vs 1"

Virtual server: vs 1(A)                  State: Down             IP: 1.1.1.201  

Port                          Curr-conn  Total-conn Rev-Pkt    Fwd-Pkt   Peak-conn

-------------------------------------------------------------------------------------

 

Virtual Port:80 / service:svcgrp 1 / state:Down

  port 80  tcp

1         server 1:80/Down    0          0          0          0         0

 

Virtual Port:1 / service: / state:Unkn

  port 1  tcp

         Persist Source IP:tmpl persist srcip 1

 

Virtual Port:2 / service: / state:Unkn

  port 2  tcp

         Persist SSL session ID:tmpl persist sslid 1

 

Virtual Port:3 / service: / state:Unkn

  port 3  tcp

         Template tcp tmpl tcp 1

...

Use the CLI to View the Health of Real Servers and Service Ports

Use the show slb server command to view the health of real servers and service ports. The health status is shown in the State column; for additional information about this command and the fields in the output, see the Command Line Interface Reference.

ACOS# show slb server

Total Number of Services configured: 5

                  Current = Current Connections, Total = Total Connections

                   Fwd-pkt = Forward packets, Rev-pkt = Reverse packets

Service                   Current    Total      Fwd-pkt    Rev-pkt    Peak-conn    State

---------------------------------------------------------------------------------------

s1:80/tcp                 0          0          0          0          0            Down

s1:53/udp                 0          0          0          0          0            Down

s1:85/udp                 0          0          0          0          0            Down

s1: Total                 0          0          0          0          0            Down

...

Use the CLI to View Health Monitoring Statistics

Use the show health stat command to view health monitoring statistics. For additional information about this com­mand and the fields in the output, see the Command Line Interface Reference:

ACOS# show health stat

Health monitor statistics

Total run time:                        : 2 hours 1345 seconds

Number of burst:                       : 0

max scan jiffie:                       : 326

min scan jiffie:                       : 1

average scan jiffie:                   : 1

Opened socket:                         : 1140

Open socket failed:                    : 0

Close socket:                          : 1136

Send packet:                           : 0

Send packet failed:                    : 259379

Receive packet:                        : 0

Receive packet failed                  : 0

Retry times:                           : 4270

Timeout:                               : 0

Unexpected error:                      : 0

Conn Immediate Success:                : 0

Socket closed before l7:               : 0

Socket closed without fd notify:       : 0

Get retry send:                        : 0

Get retry recv:                        : 0

Configured health-check rate (/500ms)  : Auto configured

Current health-check rate (/500ms):    : 1600

External health-check max rate(/200ms) : 2

Total number:                          : 8009

Status UP:                             : 8009

Status DOWN:                           : 0

Status UNKN:                           : 0

Status OTHER:                          : 0

 

IP address           Port  Health monitor  Status Cause(Up/Down) Retry PIN

--------------------------------------------------------------------------------

10.0.0.11            80    http            UP     11 /0  @0      0     0  /0  0

10.0.0.12            80    http            UP     10 /0  @0      0     0  /0  0

Using External Health Methods

Besides internal health checks, which use a predefined health check method, you can use external health checks with scripts. The following types of scripts are supported:

     Perl

     Shell

     Tcl

     Python

Utility commands such as ping, ping6, wget, dig, and so on are supported.

ACOS supports the Perl IO::Socket module and the Tcl UDP extension.

NOTE:                               External health methods are not supported in Direct Server Return (DSR) deployments.

Configuration

To use an external health method:

1.     Configure a health monitor script.

2.     Import the script onto the ACOS device.

3.     Configure a health monitor that uses external as the method.

4.     In the server configuration, set the health check to use the method.

NOTE:                               The filename of the imported script should be less than 32 characters in length, includ­ing the extension.

Using the GUI

To import an external health-check script onto the ACOS device:

1.     Select ADC > Health Monitors.

2.     On the menu bar, select External Programs.

3.     Click Create.

4.     Enter a name and description for the script.

5.     Copy-and-paste the script into the Definition field.

6.     Click Create.

To configure an external health monitor:

1.     Select ADC > Health Monitors.

2.     Click Create.

3.     In the Name field, enter a name for the monitor.

4.     In the Method Type section, select External from the drop-down menu.

5.     Click the Program drop-down menu and select the desired script.

6.     In the Port field, enter the protocol port number.

7.     Enter any arguments in the Arguments field.

8.     Click Create Monitor.

To configure a server to use the external health method:

1.     Select ADC > SLB.

2.     On the menu bar, select the Servers tab.

3.     Click on the server name or click Create to create a new one.

4.     If configuring a new server, enter the name and IP address, and other general parameters as applicable.

5.     In the Port section:

a.     If adding a new port, enter the port number in the Port field.

b.     Select the external health monitor from the Health Monitor field.

6.     Click Create or Update.

Using the CLI

Use the import health-external command at the global configuration level to import an external health-check script onto your ACOS device. The following example imports a script called example-health.py

ACOS(config)# import health-external example-health.py ftp://examplehost/scripts/hc

 

The following example shows how to configure the external health monitor:

ACOS(config)# health monitor hm1

ACOS(config-health:monitor)# method external program example-health.py

 

After the health monitor is configured, you can configure a server to use the external health method:

ACOS(config)# slb server rs1

ACOS(config-real server)# health-check hm1

 

Script Examples

This section contains the following script examples:

     TCL Script Example

     Perl Script Example

     Shell Script Example

     Python Script Example

TCL Script Example

For Tcl scripts, the health check parameters are transmitted to the script through the predefined TCL array ACOS_env. The array variable ax_env(ServerHost) is the server IP address and ax_env(ServerPort) is the server port number. Set ax_env(Result) 0 as pass and set the others as fail. TCL script filenames must use the “.tcl” extension.

To use the external method, you must import the program onto the ACOS device device. The script execution result indi­cates the server status, which must be stored in ax_env(Result).

The following commands import external program “ext.tcl” from FTP server 192.168.0.1, and configure external health method “hm3” to use the imported program to check the health of port 80 on the real server:

ACOS(config)#health external import "checking HTTP server" ftp://192.168.0.1/ext.tcl

ACOS(config)#health monitor hm3

ACOS(config-health:monitor)#method external port 80 program ext.tcl

Here is the ext.tcl file:

set sock -1

set ax_connected -1

set ax_result -1

set ax_server $ax_env(ServerHost)

set ax_port $ax_env(ServerPort)

 

proc recv_response { args } {

  global sock ax_result ax_server ax_port

  puts "recv_response"

  set line [read $sock]

  puts $line

if { [ regexp "HTTP/1.. (\[0-9\]+) " $line match status] } {

     puts "server $ax_server:$ax_port response: $status"

     # Check the status code

     if { $status == 200 } {

        # Set server to be "UP"

        set ax_result 0

     } else {

        set ax_result 1

     }

  } else {

     puts "not match"

     set ax_result 1

  }

  # clear the read event

  fileevent $sock readable {}

}

 

proc send_request { args } {

  global sock ax_result ax_connected

  puts "send_request"

puts $sock "GET / HTTP/1.0\r\n"

puts $sock "User-Agent: A10 HMON\r\n\r\n"

  set ax_connected 1

  # clear the write event

  fileevent $sock writable {}

}       

 

# setup timer, 1000ms       

after 1000 {       

   set ax_connected 0   

  set ax_result 1

   puts "timeout"   

}       

 

if {[catch {socket -async $ax_server $ax_port} sock]} {    

   puts "$ax_server: $sock"       

} else {       

   fconfigure $sock -buffering none -blocking 0 -eofchar {}   

 

   fileevent $sock writable { send_request 0 }

   puts "waiting"  

  vwait ax_connected

   if {1 == $ax_connected} {

     fileevent $sock readable { recv_response 0 }

     vwait ax_result

   }     

   set ax_env(Result) $ax_result       

  close $sock

}

Perl Script Example

For other external scripts (non-Tcl), environment variables are used to pass the server IP address (HM_SRV_IPADDR) and the port number (HM_SRV_PORT). The script returns 0 as pass and returns others as fail. For Perl scripts, use #! /usr/bin/perl at the beginning of the script.

Here is an example using the Perl scripting language:

#!/usr/bin/perl -w

# Sample script for checking Web server

 

my $host = $ENV{'HM_SRV_IPADDR'};

my $port = 80;

if (defined($ENV{'HM_SRV_PORT'})) {

  $port = $ENV{'HM_SRV_PORT'};

}

 

# Use wget, exit code is zero if wget was successful.

my @args = qw(-O /dev/null -o /dev/null);

exec "wget", "http://$host:$port", @args;

 

# vim: tw=78:sw=3:tabstop=3:autoindent:expandtab

Shell Script Example

For Shell scripts, use #! /bin/bash at the beginning of the script.

Here is an example using the Shell scripting language:

#! /bin/bash  

if test "$HM_SRV_IPADDR" == "" ; then  

  echo "Please check ENV Var 'HM_SRV_IPADDR'"

  exit 1  

fi  

  

echo -n "Test $HM_SRV_IPADDR ...."  

wget $HM_SRV_IPADDR --delete-after --timeout=2 --tries=1  > /dev/null 2>&1

ret=$?  

if test $ret == 0 ; then  

  echo "OK"

exit 0

else  

 echo "Fail"

exit 1  

fi

Python Script Example

See Database Health Monitoring Using a Script.

Database Health Monitoring Using a Script

ACOS supports Open Database Connectivity (ODBC). With this support, you can use a Python script to perform Layer 7 health checking based on information in a database on the server.

The following types of databases are supported:

     Microsoft SQL (see Example Script—Microsoft SQL)

     MySQL (see Example Script—MySQL)

     PostgreSQL (see Example Script—PostgreSQL)

     Oracle (see Example Script—Oracle)

NOTE:                               ACOS also provides a database heath method. See Database Health Monitors.

To configure database health monitoring:

1.     Configure a Python script to check the database. (See the examples below.)

2.     Import the script onto the ACOS device.

3.     Configure an external health monitor that uses the script.

4.     Bind the external health monitor to the target (real server, real port, or service group).

The steps performed on the ACOS device are the same as those for any other type of external health monitor.

Example Script—Microsoft SQL

#!/usr/bin/python

import sys

import os

import pyodb

 

# MsSQL connection string format:

#Driver=FreeTDSDriver;Server=<ip>;Port=<port>;TDS_version=7.0;Database=<data­base>;UID=<username>;PWD=<password>

 

# by a10hm convention get host and/or port from environment

host = os.environ['HM_SRV_IPADDR']

if os.environ.has_key('HM_SRV_PORT'):

  port = int(os.environ['HM_SRV_PORT'])

if 0 >= port or 65536 <= port:

  port = 0

else:

  port = 0

 

if 0 != port:

  conn_str = ("Driver=FreeTDSDriver;Server=%s;Port=%d;TDS_version=7.0;Database=Data­base;UID=User;PWD=Password" % (host, port))

else:

  conn_str = ("Driver=FreeTDSDriver;Server=%s;TDS_version=7.0;Database=Data­base;UID=User;PWD=Password" % (host))

 

sql_stmt = "select * from Table"

try:

  rv = 0

  print "Connecting %s" % (conn_str)

  conn = pyodb.Connect(conn = conn_str)

   print "Doing SQL query '%s'" % (sql_stmt)

  conn.execute(sql_stmt)

  print "Fetching query results"

  rows = conn.fetch()

  print "Verifying results are OK"

  if (0 == len(rows)):

     rv = -1;

  print "Cleaning up the database connection"

  conn.disconnect()

  del(conn)

except:

  print "Something went wrong"

  # by a10hm convention must exit with something other than 0

  rv = -1

 

sys.exit(rv)

Example Script—MySQL

#!/usr/bin/python

import sys

import os

import pyodb

 

# MySQL connection string format:

#Driver=MySQLDriver;Server=<ip>;Port=<port>;Database=<database>;UID=<username>;PWD=<pass­word>

 

# by a10hm convention get host and/or port from environment

host = os.environ['HM_SRV_IPADDR']

if os.environ.has_key('HM_SRV_PORT'):

  port = int(os.environ['HM_SRV_PORT'])

if 0 >= port or 65536 <= port:

  port = 0

else:

  port = 0

 

if 0 != port:

  conn_str = ("Driver=MySQLDriver;Server=%s;Port=%d;Database=Database;UID=User;PWD=Pass­word" % (host, port))

else:

   conn_str = ("Driver=MySQLDriver;Server=%s;Database=Database;UID=User;PWD=Password" % (host))

 

sql_stmt = "select * from Table"

try:

  rv = 0

  print "Connecting %s" % (conn_str)

  conn = pyodb.Connect(conn = conn_str)

   print "Doing SQL query '%s'" % (sql_stmt)

  conn.execute(sql_stmt)

  print "Fetching query results"

  rows = conn.fetch()

  print "Verifying results are OK"

  if (0 == len(rows)):

     rv = -1;

  conn.disconnect()

  del(conn)

except:

  print "Something went wrong"

  # by a10hm convention must exit with something other than 0

  rv = -1

 

sys.exit(rv)

Example Script—PostgreSQL

#!/usr/bin/python

import sys

import os

import pyodb

 

# PostgreSQL connection string format:

# Driver=PostgreSQLDriver;Server=<ip>;Port=<port>;Database=<database>;UID=<user­name>;PWD=<password>

 

# by a10hm convention get host and/or port from environment

host = os.environ['HM_SRV_IPADDR']

if os.environ.has_key('HM_SRV_PORT'):

  port = int(os.environ['HM_SRV_PORT'])

if 0 >= port or 65536 <= port:

  port = 0

else:

  port = 0

 

if 0 != port:

  conn_str = ("Driver=PostgreSQLDriver;Server=%s;Port=%d;Database=Data­base;UID=User;PWD=Password" % (host, port))

else:

   conn_str = ("Driver=PostgreSQLDriver;Server=%s;Database=Database;UID=User;PWD=Password" % (host))

 

sql_stmt = "select * from Table"

try:

  rv = 0

  print "Connecting %s" % (conn_str)

  conn = pyodb.Connect(conn = conn_str)

   print "Doing SQL query '%s'" % (sql_stmt)

  conn.execute(sql_stmt)

  print "Fetching query results"

  rows = conn.fetch()

  print "Verifying results are OK"

  if ( 0 == len(rows)):

     rv = -1;

  print "Cleaning up the database connection"

  conn.disconnect()

  del(conn)

except:

  print "Something went wrong"

  # by a10hm convention must exit with something other than 0

  rv = -1

 

sys.exit(rv)

Example Script—Oracle

#!/usr/bin/python

import sys

import os

import pyodb

 

# Oracle connection string format:

#Driver=OracleODBCDriver;DBQ=<Oracle-DBQ>;UID=<username>;PWD=<password>

 

# by a10hm convention get host and/or port from environment

host = os.environ['HM_SRV_IPADDR']

  if os.environ.has_key('HM_SRV_PORT'):

port = int(os.environ['HM_SRV_PORT'])

if 0 >= port or 65536 <= port:

  port = 0

else:

  port = 0

 

if 0 != port:

   conn_str = ("Driver=OracleODBCDriver;DBQ=//%s:%d/XE;UID=User;PWD=Password" % (host, port))

else:

  conn_str = ("Driver=OracleODBCDriver;DBQ=//%s/XE;UID=User;PWD=Password" % (host))

 

sql_stmt = "select * from Table"

try:

  rv = 0

  print "Connecting %s" % (conn_str)

  conn = pyodb.Connect(conn = conn_str)

   print "Doing SQL query '%s'" % (sql_stmt)

  conn.execute(sql_stmt)

  print "Fetching query results"

  rows = conn.fetch()

  print "Verifying results are OK"

  if ( 0 == len(rows)):

     rv = -1;

  print "Cleaning up the database connection"

  conn.disconnect()

  del(conn)

except:

  print "Something went wrong"

  # by a10hm convention must exit with something other than 0

  rv = -1

 

# by a10hm convention must exit with 0

sys.exit(rv)

 

Table of Contents

Index

Glossary

-Search-

Back