LDAP health checks provide information about the status and availability of LDAP external servers. Configure the Directory Proxy Server health checks that work best for your environment.
PingDirectoryProxy provides the following health checks:
- Measure the response time for searches and examine the entry contents
- The health check might retrieve a monitoring entry from a server and base the health check result on whether the entry was returned, how long it took to be returned, and whether the value of the returned entry matches what was expected.
- Monitor the replication backlog
- If a server falls too far behind in replication, then the Directory Proxy Server can stop sending requests to it. A server is
unavailableif the threshold is reached for the number of missing changes, the age of the oldest missing change, or both.
- Consume Directory Server administrative alerts
- If the Directory Server indicates there is a problem, such as an index that must be
rebuilt, then it flags itself as
unavailable. When the Directory Proxy Server detects this, it stops sending requests to the server. The Directory Proxy Server detects administrative alerts as soon as they are issued by maintaining an LDAP persistent search for changes within the
cn=alertsbranch of the Directory Server.
When the Directory Proxy Server is notified by the Directory Server of a new alert, it immediately retrieves the base
cn=monitorentry of the Directory Server. If this entry has a value for the
unavailable-alert-typeattribute, then the Directory Proxy Server considers it unavailable. If this entry has a value for the
degraded-alert-typeattribute, then the Directory Proxy Server considers it
degraded. Clients of the Directory Proxy Server can use a similar mechanism to detect and react when a Directory Proxy Server flags itself as
- Monitor the busyness of the server
- If a server becomes too busy, you can mark it as
unavailableso that less heavily-loaded servers are preferred.
The health check results contain the following server states:
- Completely accessible for use.
- The server can be used if necessary but has a condition which can make it less desirable than other servers. For example, it is slow to respond or has fallen behind in replication.
- Completely unsuitable for use. For example, the server is offline or is missing critical data.
Health check results include a numeric score that has a value between 1 and 10. This score helps rank servers with the same state. For example, two servers are available and one has a score of 8 and the other a score of 7, you can configure the Directory Proxy Server to prefer the server with the higher score.
The results of health checks are made available to the load-balancing algorithms to help
determine where to send requests. The Directory Server attempts to use
servers with a state of
available before trying servers with a state of
degraded. It never attempts to use servers with a state of
Some load-balancing algorithms also take the health check score into account, such as the health-weighted load-balancing algorithm that prefers servers with higher scores over those with lower scores. You should configure the algorithms that work best for you environment.
The Directory Server periodically invokes health checks to monitor each
LDAP external server and initiates health checks in response to failed operations. It
checks the health of the LDAP external servers at intervals configured in the LDAP
health-check-frequency property. The Directory Proxy Server contains safeguards to ensure that only one health
check is in progress at any time against a backend server to avoid affecting its ability
to process other requests.
To associate a health check with an LDAP external server and set the health check
frequency, you must configure the
health-check-frequency properties of the LDAP external server.
For more information about configuring the properties of the external server, see Configuring an external server using dsconfig.
Server states and search response times
In some cases, an LDAP health check defines different sets of criteria for promoting and
demoting the state of a server. A
degraded server might need to meet
more stringent requirements to be reclassified as
originally for it to be considered
If response time is used in the process of determining the health of a server, then the
Directory Server might have a faster response time threshold for
transitioning a server from
degraded back to
than the threshold used to consider it
degraded in the first place.
This threshold difference helps avoid cases in which a server repeatedly transitions
between the two states because it is operating near the threshold.
For example, the health check used to measure search response time is configured to mark
any server as
degraded when the search response time is greater than 1
second. You can configure that the response time must be less than 500 ms before the
server is made available again so that the Directory Server does not flip
back and forth between
For more information about configuring health checks, see Configuring Server Health Checks.