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…)
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)
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.
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 ?
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 ?