need help on the keepalived with Ldap High availability misc check script

Question

I need help on the keepalived with Ldap High availability misc check script.

We had an LDAP problem suddenly users were not able to login to the system over the applications and su – ldapuser, it was happened for twice.

During that time in primary LDAP servers connections are 600 and secondary LDAP servers connections are 1000.

All the application servers will be contacted over the keepalived (load balancer) servers, currently, we have 2 lb nodes and 2 LDAP nodes.

LDAP design is Active and Active, if primary down then requests go to secondary.

So finding the root cause is very hard we tried a lot to find so we are thing like to implement in LB level if there are connections are high like 600 or more than that switch to the secondary server

I am reaching out here for suggestions on how to implement in misc check whether a number of connections checking is the fine or any other parameter to be used to check LDAP related content to switch to the secondary server.even I don’t want to do ssh from lb to check ldap content , I need direct logic to check and switch

Currently, we have like below for misc check script:

LB monitoring script :

virtual_server 10.X.X.X 389 {
    protocol TCP
    !service_name ldap
    persistence_timeout 0
    sorry_server 10.X.X.X 389
    lb_kind DR
    real_server 10.X.X.X 389 {
        MISC_CHECK {
            misc_path "/monitor.sh 389 10.X.X.X"
            misc_timeout 6
        }
        weight 1
    }
    lb_algo rr
    delay_loop 15

Cat monitor.sh

#!/bin/bash
port=$1
ip=$2
timeout 1s /bin/bash -c "2>/dev/null >/dev/tcp/$ip/$port"
if [ $? -eq 0 ]
then
  echo "OK"
  RETURN_CODE=0
else
  echo "NOK"
  RETURN_CODE=1
fi

exit $RETURN_CODE

Thanks, Subhash Kumar.D

Answer 1

Checking for port open it one thing to do but doing a LDAP bind will allow you to check if the service is "really" responding to the LDAP request.

Depending on your LDAP server Implementation, a ldapsearch for something in the rootDSE and checking for a reasonable response works well.

I assume, although you do not reveal, that this is some "linux" LDAP setup which generate logs. Usually these LDAP logs on the Linux side will provide a lot of answers.

Usually what we see in these type of scenarios is the improper setup of reasonable caching on the Linux client side. Often every command performed on Linux requires a check for some authorization and therefore a LDAP call. Even "cd .."