LDAP health checks provide information about the health and availability of the LDAP directory servers, which has a direct effect on services, such as the PingAuthorize Server System for Cross-domain Identity Management (SCIM) 2 service and the SCIM Token Resource Lookup method.
- Completely accessible for use.
- The server is ready for use if necessary, but it has a condition that might 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 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, you can configure PingAuthorize Server to prefer the server with the higher score.
PingAuthorize Server periodically invokes health checks to monitor each LDAP external server. It might 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.
The results of health checks performed by PingAuthorize Server are made available to the load-balancing algorithms to take into account when determining where to send requests. PingAuthorize 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 UNAVAILABLE. Some load-balancing algorithms might 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 must configure the algorithms that work best for your environment.
In some cases, an LDAP health check might define different sets of criteria for promoting and demoting the state of a server. A DEGRADED server might need to meet more stringent requirements to meet the criteria for AVAILABLE than it originally took to meet the criteria for DEGRADED. For example, if response time is used to determine the health of a server, then PingAuthorize Server might 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.
The default Consume Admin Alerts and Get Root DSE LDAP health checks apply to
all LDAP external servers, even if you did not explicitly configure and add
them to an LDAP external server's
use-for-all-serversproperty for each LDAP health check. For example:
dsconfig set-ldap-health-check-prop \ --check-name 'Consume Admin Alerts' \ --reset use-for-all-servers
Available 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 a PingAuthorize 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 PingAuthorize Server administrative alerts||If a PingDirectory Server indicates there is a problem, it flags itself as DEGRADED
or UNAVAILABLE. When a PingAuthorize Server detects this,
it stops sending requests to the server.
You can configure a
PingAuthorize Server to detect administrative alerts as
soon as they are issued by maintaining an LDAP persistent
search for changes within the
|Monitor the busyness of the server||If a server becomes too busy, the health check might mark it as DEGRADED or UNAVAILABLE so that less heavily loaded servers are preferred.|