Image of an arrow

Utilisation de Keepalived pour la haute-disponibilité LDAP et HTTP

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.

ka-header

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-logo

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

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.


Articles similaires

Image of an arrow

La LDAPCon est une conférence internationale autour de la technologie LDAP et des enjeux de gestion des identités, d’authentification et d’habilitation. L’événement qui se déroulera cette année à Bruxelles du 19 au 20 octobre, se tient tous les deux ans dans un pays différent : 2007 à Cologne en Allemagne 2009 à Portland aux États-Unis […]

Savez-vous comment automatiser l’installation ainsi que la configuration de Nexus Repository Manager version 3.x avec Ansible ? Pas encore ? On vous donne un coup de pouce ici ! Pour rappel, Ansible est un outil de déploiement qui permet à des playbooks d’automatiser les déploiements d’applications et d’infrastructure. L’avantage clé d’Ansible est sa flexibilité puisqu’il […]

         Nous sommes heureux de vous annoncer la sortie d’une vidéo promotionnelle produite par Microsoft eux-même ! Fruit d’une collaboration autour de la plateforme Azure, cette vidéo souligne la pertinence et l’essor des technologies open source dans l’environnement infonuagique Azure de Microsoft ainsi que notre capacité d’innovation en combinant technologies open source […]

Thumbnail image

L’authentification unique (en anglais Single Sign On ou SSO) est aujourd’hui bien implantée dans les systèmes d’information, grâce à une large offre de produits et surtout de nombreux standards comme CAS, SAML ou OpenID Connect, pour ne citer que les plus importants. Cependant, ce domaine reste difficile d’accès car chaque nouvelle norme demande un temps […]

Thumbnail image

La Ville de Villeurbanne mise sur l’Open Source et choisit LemonLDAP::NG pour contrôler les droits d’accès de ses utilisateurs. La Ville de Villeurbanne possédait plusieurs applications Web dont l’authentification était déjà déléguée à un serveur central CAS (Central Authentification Services), modifié pour les besoins de Villeurbanne pour donner accès à la fois aux utilisateurs internes […]