The LDAP health check component provides information about the availability of LDAP external servers. The health check result includes a server state, which can be one of the following:
  • Available. Completely accessible for use.
  • Degraded. The server may be used if necessary, but has a condition which may make it less desirable than other servers (for example, it is slow to respond or has fallen behind in replication).
  • Unavailable. Completely unsuitable for use (for example, the server is offline or is missing critical data).

Health check results also include a numeric score, which has a value between 1 and 10, that can help rank servers with the same state. For example, if two servers are available and one has a score of 8 and the other a score of 7, the Directory Proxy Server can be configured to prefer the server with the higher score.

The Directory Proxy Server periodically invokes health checks to monitor each LDAP external server, and may also initiate health checks in response to failed operations. It checks the health of the LDAP external servers at intervals configured in the LDAP server’s health-check-frequency property. However, the Directory Proxy Server has safeguards in place 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.

The results of health checks performed by the Directory Proxy Server are made available to the load-balancing algorithms so that they may be taken into account when determining where to send requests. The Directory Proxy Server will attempt to use servers with a state of available before trying servers with a state of degraded. It will never attempt to use servers with a state of unavailable. Some load-balancing algorithms may also take the health check score into account, such as the health-weighted load-balancing algorithm, which prefers servers with higher scores over those with lower scores. You configure the algorithms that work best for you environment.

In some cases, an LDAP health check may define different sets of criteria for promoting and demoting the state of a server. So, a degraded server may need to meet more stringent require- ments to be reclassified as available than it originally took to be considered degraded. For example, if response time is used in the process of determining the health of a server, then the Directory Proxy Server may have a faster response time threshold for transitioning a server from degraded back to available than the threshold used to consider it degraded in the first place. This threshold difference can help 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 to be marked degraded when the search response time is greater than 1 second. You can then configure that the response time must be less than 500 ms before the server is made available again, so that the Directory Proxy Server does not flip back and forth between available and degraded.

PingDirectoryProxy Server provides the following health checks:
  • Measure the response time for searches and examine the entry contents. For example, 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 classified as degraded or unavailable if 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, for example an index that must be rebuilt, then it will flag itself as degraded or unavailable. When the Directory Proxy Server detects this, it will stop 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=alerts branch 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=monitor entry of the Directory Server. If this entry has a value for the unavailable-alert-type attribute, then the Directory Proxy Server will consider it unavailable. If this entry has a value for the degraded-alert-type attribute, then the Directory Proxy Server will consider 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 degraded or unavailable.

  • Monitor the busyness of the server. If a server becomes too busy, then it may be marked degraded or unavailable so that less heavily-loaded servers may be preferred.

For information about configuring health checks, see Configuring Server Health Checks. To associate a health check with an LDAP external server and set the health check frequency, you must configure the health-check and health-check-frequency properties of the LDAP external server. See “To Configure an External Server Using dsconfig” for information about configuring the properties of the external server.