19 mars 2024

Tuto Openldap, partie VII : Keepalived

Septième partie de la série de tuto sur OpenLDAP dans la continuité de la partie précédente sur la réplication, nous allons mettre en place le logiciel Keepalived afin que nos services LDAP soient accessibles via une IP unique.

Ceci ne sera pas un tutoriel complet sur Keepalived, mais juste une rapide présentation et mise en place. J’en parlerais plus longuement dans un futur article sur la haute disponibilité, etc…

 

I – Maintenez les en vie !

A – Présentation

Keepalived permet de faire deux choses distinctes :

  • Mise en place d’une IP virtuelle qui pourra changer de serveur en fonction de leur état (un peu à la manière de Hearbeat)
  • Mise en place de Loadbalancing (ceci dit, pas aussi complet qu’Haproxy, mais pour du LDAP, c’est largement suffisant.)

Comme je l’expliquais au préalable, nous allons rapidement l’installer et le configurer sans trop rentrer dans les détails, non pas que ça ne soit pas intéressant, mais ce n’est pas le sujet qui nous intéresse aujourd’hui. Pour le moment, on veut juste avoir nos serveurs Ldap accessible.

B- Installation

Sur nos deux serveurs, nous installons Keepalived :

ldapx# apt-get install keepalived

Sa configuration se trouvera dans /etc/keepalived qui, pour le moment est vide.

 

II – Configuration simple : une IP virtuelle

Nous allons commencer par la configuration la plus simple, la création d’une IP virtuelle qui se « baladera » entre nos deux serveurs LDAP en fonction de leur état.

Pour cela, créez sur les deux serveurs un fichier /etc/keepalived/keepalived.conf et remplissez le ainsi :

vrrp_script check_server_health {
    script "/etc/keepalived/test_ldap.sh aaa.aaa.aaa.aaa" (mettre l'ip réel de votre serveur)
    interval 2
    fall 2
    rise 2
}
vrrp_instance VI_LDAP {
    state BACKUP
    interface eth1
    virtual_router_id 50
    priority xxx (mettre 100 sur le serveur 1 et 10 par ex, sur le serveur 2)
    advert_int 1
    lvs_sync_daemon_interface eth1

    authentication {
        auth_type PASS
        auth_pass MON_MOT_DE_PASSE_SECRET
    }

    track_script {
        check_server_health
    }

    virtual_ipaddress {
        XXX.XXX.XXX.XXX (mettre l'ip virtuelle de votre choix)
    }
}

La valeur priority doit être adaptée. Elle doit être plus élevée sur votre serveur principal et plus faible sur le serveur secondaire.

Bien sur, vous remplacerez aaa.aaa.aaa.aaa par l’ip de votre serveur Ldap sur lequel vous êtes actuellement et xxx.xxx.xxx.xxx par l’ip virtuelle que vous aurez choisi.

Renseignez également la bonne interface dans les options interface et lvs_sync_daemon_interface en fonction de votre configuration (chez moi, eth1, pour le réseau inter-machines, l’eth0 étant pour les communications avec la gateway)

Il faut également créer le fichier qui va tester la santé de vos serveurs Ldap.
Créez donc un fichier (toujours sur les deux serveurs bien évidement) /etc/keepalived/test_ldap.sh et mettez ceci dedans :

#!/bin/bash

ldapsearch -x -H ldap://$1 -D cn=viewer,ou=system,dc=debugo,dc=fr -w motdepasse-b dc=debugo,dc=fr -l 3 > /dev/null 2>&1
ldapresponse=$?

if [ "$ldapresponse" -gt 0 ]; then
    echo "down"
    exit 1
else
    echo "up"
fi

exit 0

Vous mettrez bien sur les valeurs adaptées à votre configuration. Keepalived attend une valeur à 0 si tout va bien et 1 si il y a une erreur.

Pensez à le rendre exécutable :

ldapx# chmod /etc/keepalived/test_ldap.sh +x

Ensuite, vous n’avez plus qu’à lancer sur les deux serveurs :

ldapx# service keepalived start

On peut vérifier l’état avec :

ldapx# service keepalived status

Sur le serveur principal, on fait un:

ldap1# ifconfig eth1

et …. rien !

En effet, keepalived passe par iproute2 et certaines données ne seront donc pas affichées avec la vieille commande ifconfig. Pour voir cette nouvelle IP, il faut donc faire :

ldap1#  ip addr show dev eth1

Maintenant, testez… Si vous coupez le serveur 1, l’ip bascule sur le 2 et si le serveur 1 revient, l’IP revient dessus.

 

III – Et avec du loadbalancing ?

Dans notre configuration actuelle, tout le trafic arrivant sur notre ip virtuelle est relayé vers un seul serveur.

Que faire si nous voulons ajouter du loadbalancing et faire en sorte que nos deux serveurs soient ainsi sollicités ?

Rien de compliqué, ajoutez ce qui suit au fichier /etc/keepalived/keepalived.conf  à la suite de ce que nous avons déjà mis :

[...]
virtual_server xxx.xxx.xxx.xxx 389 {
    delay_loop 5
    lb_algo wrr
    lb_kind DR
    persistence_timeout 0
    protocol TCP

    real_server aaa.aaa.aaa.aaa 389 {
        weight 1
        inhibit_on_failure
        MISC_CHECK {
            misc_path "/etc/keepalived/test.sh aaa.aaa.aaa.aaa"
        }
        connect_timeout 1
        nb_get_retry 1
        delay_before_retry 1
    }

    real_server bbb.bbb.bbb.bbb 389 {
        weight 1
        inhibit_on_failure
        MISC_CHECK {
            misc_path "/etc/keepalived/test.sh bbb.bbb.bbb.bbb"
        }
        connect_timeout 1
        nb_get_retry 1
        delay_before_retry 1
    }
}

La, le complément du fichier sera le même sur les deux serveurs.

Modifiez simplement les adresses aaa.aaa.aaa.aaa et bbb.bbb.bbb.bbb par les adresses de vos serveurs Ldap et xxx.xxx.xxx.xxx par votre ip virtuelle.

On relance sur les deux serveurs :

ldapx# service keepalived restart

On va tester depuis une autre machine en installant ldap-utils :

test# apt-get ldap-utils

Puis, effectuez plusieurs fois :

test# ldapsearch -x -LLL -H ldap://ipvrituelle -D cn=admin,dc=debugo,dc=fr -w motdepasse-b cn=config "objectClass=olcGlobal" olcServerID

Tiens, curieux, une fois sur deux ça ne marche pas…

Mmm… Pourquoi donc…

Vous le savez, pour déboguer du réseau, tcpdump, c’est le bien. Du coup, on l’installe sur notre serveur qui ne répond pas (normalement, ce doit être le secondaire, vérifiez la réponse olcServerID) :

ldap2# apt-get install tcpdump

Et on va écouter un peu ce qui se passe :

ldap2# tcpdump -i eth1 port 389 -n

Puis relancer la commande sur la machine test. Entre les traces des paquets échangées entre les instances de Keepalived et le serveur Ldap, on doit voir des paquets émanant de votre machine de test et adressé à votre serveur sur l’IP Virtuelle….

Ha ! Il est la le problème !

Le serveur secondaire n’a pas cette IP (vu que pour le moment, elle est attribuée au serveur principal).

Donc, il nous suffit de rajouter un alias. Dans le fichier /etc/network/interfaces, ajoutez ceci :

auto lo:0
iface lo:0 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.255

Pour l’activer de suite :

ldap2# if up lo:0

Cette manipulation est à faire également sur le serveur principal, au cas ou il perde l’IP virtuelle (ce ne devrait se produire que si Openldap tombe et du coup, n’étant plus loadbalancé par Keepalived, il ne devrait pas recevoir de requêtes, donc, manipulation en théorie inutile, mais je suis du genre prudent…)

On reste depuis notre machine de test :

test# ldapsearch -x -LLL -H ldap://ipvrituelle -D cn=admin,dc=debugo,dc=fr -w motdepasse-b cn=config "objectClass=olcGlobal" olcServerID

Et la, selon le serveur qui répond, la réponse olcServerID sera différente. Sur le reste par contre, ce sera transparent pour les clients.

Bingo !

 

Concernant Keepalived, on pourrait encore dire beaucoup de chose, mais comme promis, ce sera dans un article dédié à ces techniques (Haute Disponibilité, Load Balancing, etc…)

 

4 réflexions sur « Tuto Openldap, partie VII : Keepalived »

  1. Petite précision : Sous débian j’ai été obligé pour la partie ip virtuelle d’activer mon eth1 comme ceci dans /etc/networl/interfaces :
    auto eth1
    iface eth1 inet manual
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down

    eth1 est une carte réseau additionnelle.

    Sinon marche du feu quand j’étais ldap1 il passe sur mon deux (vérif avec la commande pour afficher l’ip de eth1)

  2. Petite précision concernant le keepalived :

    Même si c’est la priorité la plus haute qui prend le status Master, il est nécessaire de mettre state MASTER sur le maitre principal et laisser backup sur le 2e.

    1. Bonjour,
      Merci pour la précision.
      Cependant quand j’avais fait ainsi à l’époque, de mémoire, j’avais eu des soucis.
      Mais tu as raison, la logique voudrait que l’on fasse comme tu le dis.
      Tu es en quelle version de Keepalived ?

  3. Grandiose !
    Mais j’ai quand même des ratés sur la série de tests de olcServerID depuis un serveur de test. J’ai essayé de placer le state MASTER sur le maître mais ça ne change rien. De temps en temps j’ai un :
    ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

    En traçant avec tcpdump j’ai ces lignes alors :
    17:01:25.332288 IP (IP_TEST).60756 > (IP_VIRTUELLE).389: Flags [S], seq 3066819340, win 64240, options [mss 1460,sackOK,TS val 1166418908 ecr 0,nop,wscale 7], length 0

    C’est tout ce que je vois dans le flot de lignes

    Y a t’il une explication ?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *