Kemp GEO LoadMaster Health Checks
This article explains the health checking options for the GEO LoadMaster and the GSLB.
None:
No check occurs.
Layer 3 - ICMP:
The LoadMaster sends ICMP echo requests (pings) to the IP indicated in the checker. If no IP is indicated, the ping is sent to the IP entered in the FQDN.
An IP address end-point fails this check when it does not respond with an ICMP echo response in the configured response time for the configured number of retries.
Layer 4 – TCP:
The LoadMaster attempts to open a TCP connection to the IP address end-point on the configured service port. The server passes the check if it responds with a TCP SYN/ACK in the response time interval. In this case, the LoadMaster closes the connection by sending a TCP RESET. If the server fails to respond within the configured response time for the configured number of times, it is assumed to be dead.
Layer 7 - Cluster Checks:
A health check is performed on the IP address of the cluster. Different types of clusters can be defined. The health checks differ for each type:
Default Cluster Type: An ICMP Ping or TCP Connect health check (depending on what is selected in the Manage Cluster options) is performed.
Remote LM Cluster Type: An SSH connection is attempted. The native LoadMaster statistics are obtained and matched against the FQDN IP If a matching Virtual Service IP is not found, the list of Real Servers cluster is marked as down. Permission to connect using SSH must be granted on the LoadMaster.
Local LM: This method is required if a LoadMaster is co-located with the GSLB Feature Pack for health checks to function correctly.
- Note that this option is removed if GEO partners are used.
If the checker type is set to Cluster Checks and the cluster Type (in Global Balancing > Manage Clusters > Modify) is set to Remote LM, you must also select the associated Virtual Service from the Mapping Menu drop-down list.
If Virtual Services are not displayed in the drop-down list, ensure that both LoadMasters are able to access each other and that the Virtual Services are passing the health checks. The remote GEO partner must be configured in Certificates & Security > Remote Access.
The Mapping Menu drop-down list displays a list of Virtual Service names (where available) and Virtual Service IP addresses from that LoadMaster. It lists each Virtual Service IP address with no port, as well as all of the Virtual IP address and port combinations. Select the Virtual IP address that is associated with this mapping.
If a Virtual Service with no port is selected, the health check checks all Virtual Services with the same IP address as the one selected. If one of them is in an "Up" status, the FQDN shows as "Up". The port does not come into consideration.
If a Virtual Service with a port is selected, the health check only checks against the health of that specific Virtual Service when updating the health of the FQDN.
Common Log Messages
<Date> <LM hostname> geocheck: Mapping <FQDN> -> <Endpoint IP> failed
Example
Feb 1 07:51:44 GEO1 geocheck: Mapping mail.kemptest.com. -> 192.168.10.10 failed
Explanation
The endpoint has failed the health check.
<Date> <LM hostname> geocheck: Mapping <FQDN> -> <Endpoint IP> back in service
Example
Feb 1 07:57:05 GEO1 geocheck: Mapping mail.kemptest.com. -> 192.168.10.10 back in service
Explanation
The endpoint has passed the health check.
<Date> <LM hostname> geocheck: cluster <Cluster name> -> <Cluster IP> failed
Example
Feb 1 07:55:20 GEO1 geocheck: cluster Cluster Site 1 - Limerick (192.168.10.5) failed
Explanation
The cluster has failed the health check.
<Date> <LM hostname> geocheck: cluster <Cluster name> -> <Cluster IP> back in service
Example
Feb 1 07:55:20 GEO1 geocheck: cluster Cluster Site 1 - Limerick (192.168.10.5) back in service
Explanation
The cluster has passed the health check.