Nous déployons régulièrement des infrastructures LDAP et WebSSO chez nos clients, et se pose toujours la question de la haute-disponibilité : la plate-forme d’authentification devenant centrale, il est indispensable de se prémunir d’un arrêt de service, que ce soit de l’annuaire LDAP ou du portail d’authentification Web. Nous allons voir comment le logiciel Keepalived peut nous aider à répondre à ce besoin.
Des logiciels d’infrastructure adaptés
Avant d’envisager la mise en place d’outils de haute-disponibilité, il faut s’assurer que les logiciels principaux de l’infrastructure sauront fonctionner dans ce mode, c’est-à-dire qu’ils peuvent être installés sur plusieurs nœuds (serveurs physiques, virtuels ou conteneurs) et opérer de la même façon quelque soit le nœud actif.
Dans notre cas, nous utiliserons les logiciels suivants :
- OpenLDAP : serveur d’annuaire compatible LDAPv3
- LemonLDAP::NG : produit de WebSSO compatible CAS, SAML et OpenID Connect
OpenLDAP sait fonctionner en mode multi-maîtres depuis plusieurs années, via le protocole SyncRepl. Le mode « miroir » (mirror mode) est particulièrement pertinent dans une architecture à deux nœuds où un seul d’entre eux sera contacté par les clients (l’important ici est d’éviter que des opérations d’écriture soient faites simultanément sur les deux nœuds). La configuration de ce mode est détaillée dans le guide d’administration d’OpenLDAP.
LemonLDAP::NG pour sa part a été conçu dès le départ pour pouvoir utiliser des bases externes pour la gestion de ses données (configuration et sessions). Ainsi il est possible de déployer autant de nœuds que nécessaire en partageant les données entre les nœuds. Pour ma part, j’utilise régulièrement l’annuaire OpenLDAP comme stockage de la configuration et des sessions : l’annuaire étant déjà redondé, pas besoin de travail supplémentaire pour le WebSSO. Mais vous pouvez également utiliser des bases de données SQL (MySQL, PostGreSQL) ou NoSQL (MongoDB, Redis, Cassandra) pour assurer ce service.
Utilisation d’une adresse virtuelle
Une fois les deux nœuds installés, chacun possède son adresse IP propre et il faut trouver un moyen d’indiquer aux applications clientes quel nœud utiliser.
Une première solution est le Round-Robin DNS : au nom DNS ldap.example.com ou auth.example.com on associe les deux adresses IP, et charge aux clients de se débrouiller avec ça. Dans le cas de HTTP, la plupart des clients sauront rejouer les requêtes sur la seconde IP si la première ne fonctionne pas, mais ce n’est pas aussi évident pour les clients LDAP.
L’autre solution est d’utiliser une adresse IP virtuelle qui sera associée au nœud principal. Le nœud secondaire est opérationnel mais ne sera pas associé à l’adresse IP virtuelle, jusqu’à ce que celle-ci bascule en cas de problème du nœud principal. Dans cette situation, la haute-disponibilité est bien gérée du côté des serveurs, et non du côté des clients qui ne contacte qu’une seule adresse, l’adresse IP virtuelle.
Utilisation de Keepalived
Le logiciel Keepalived permet de gérer une IP virtuelle qui sera associée au nœud principal tant que celui-ci est opérationnel. Le protocole VRRP est utilisé entre les nœuds pour gérer cette adresse IP virtuelle.
Sa configuration est assez simple :
vrrp_instance VI_SFL {
state MASTER
priority 150
nopreempt
interface eth0
virtual_router_id 69
advert_int 5
authentication {
auth_type PASS
auth_pass KEEPALIVED_PASSWORD
}
virtual_ipaddress {
10.10.0.10/22 brd 10.10.0.255 dev eth0 scope global
}
}
Il est intéressant de paramétrer la partie « authentication » pour éviter que les ordres VRRP soient pris en compte par d’autres routeurs non associés à la grappe de serveurs. Seuls les serveurs disposant du même mot de passe consommeront les requêtes.
Le paramètre « priority » permet d’indiquer le nœud principal. Le ou les nœuds secondaires auront une priorité plus faible (par exemple 100).
Script de surveillance
Cette configuration initiale n’est pas suffisante pour palier à des problèmes applicatifs : l’adresse IP virtuelle basculera si le nœud principal ne répond plus au protocole VRRP, mais rien n’est fait pour surveiller l’annuaire LDAP ou le serveur HTTP.
Keepalived permet d’utiliser un « track_script » dans lequel nous sommes libres de lancer les commandes que nous souhaitons. Si ce script s’exécute sans erreurs, alors le nœud est considéré comme opérationnel, sinon il est mis en quarantaine.
L’appel au script se configure simplement :
vrrp_script check_server_health {
script "/usr/local/bin/check_server_health.sh"
interval 2
fall 2
rise 2
}
vrrp_instance VI_SFL {
...
track_script {
check_server_health
}
}
Voici un exemple de script :
#!/bin/bash
# Script that do several checks to verify LDAP/SSO service is up
#
# Returns 0 if all is fine
#
# Copyright (c) 2016 Clement Oudot @ Savoir-faire Linux
# Disks
rootuse=$(df -H / | grep -v 'Filesystem' | awk '{ print $5 }' | cut -d'%' -f1)
if [ $rootuse -ge 95 ]; then
echo "Partition / is full ($rootuse%)"
exit 1
else
echo "Partition / is OK ($rootuse%)"
fi
# Process
openldapprocess=$(/bin/pidof slapd)
apacheprocess=$(/bin/pidof apache2)
/usr/local/openldap/bin/ldapsearch -x -H ldap://localhost -b '' -s base -l 3 > /dev/null 2>&1
ldapresponse=$?
if [ -z "$openldapprocess" ]; then
echo "OpenLDAP is not running"
exit 1
else
echo "OpenLDAP is running (PID $openldapprocess)"
fi
if [ "$ldapresponse" -gt 0 ]; then
echo "OpenLDAP is not anwering on RootDSE"
exit 1
else
echo "OpenLDAP is answering on RootDSE"
fi
if [ -z "$apacheprocess" ]; then
echo "Apache is not running"
exit 1
else
echo "Apache is running (PID $apacheprocess)"
fi
# Exit without problem
exit 0
J’utilise plusieurs type de vérifications dans ce script :
- Contrôle de l’espace disque
- Contrôle des démons lancés
- Réponse à une requête LDAP
Bien entendu, charge à vous d’y mettre les vérifications qui vous semblent pertinentes.