La réplication sous OpenLDAP

La réplication d’annuaire consiste à concerver en parfaite synchronisation plusieurs annuaires répartis sur le réseaux.

Depuis les versions 2.3.X ldap supporte différents modes de réplication d’annuaires.

Tout d’abord implémenté avec “slurpd”, les versions 2.4.X d’OpenLDAP utilisent l’overlay (le module) “syncprov” pour la réplication (protocole de réplication défini dans la RFC 4533).

Deux modes de réplication sont disponibles :

  • le mode maître esclave (dans le protocole le maître est nommé “provider” et l’esclave “consumer”),
  • le mode multi-master.

Réplication maître esclave

La réplication maître esclave ce décline sous deux modes :

  • le mode “refreshOnly” ou l’esclave initie une connexion à intervalle régulier avec le provider. Toutes les modifications survenues depuis la dernières connexions sont répliqués sur le serveur secondaire (“consumer”).
  • le mode “refeshAndPersist” ou l’esclave initie une connexion avec le maître pour la première synchronisation, puis garde la connexion ouverte de sorte que toute modification intervenant sur le provider soit immédiatement répliquée sur le consumer.

Réplication multi-master

Le mode de fonctionnement multi-maître est proche du fonctionnement de la réplication maître esclave avec la particularité que chaque consumer et aussi provider.

Mise en place

La version d’OpenLDAP utilisée pour les exemples ci dessous est la v2.4.17-1.

Dans toute la suite, nos annuaires Open LDAP communiquerons sur le port 389 (TCP) correspondant au port par défaut d’OpenLDAP. Dans un environnement de production dit “normal”, il vas de soit qu’utiliser la couche SSL semble être un minimum en ce qui concerne la sécurité (port 636 (TCP)). Pensez à ouvrir les ports de vos firewalls en conséquence.

Création d’un annuaire de test

Sur les deux machines, installation des paquets “slapd”.

Le fichier de configuration de l’annuaire est “slapd.conf”. En fonction des distributions, il est localisé dans “/etc/openldap”, “/etc/ldap” ou encore “/usr/local/etc/openldap” lors d’une compilation depuis les sources.

Les schémas à inclure dans le fichier de configuration d’OpenLDAP sont traditionnellement dans un répertoire “schema” dans le même répertoire que “slapd.conf”.

Configuration d’un annuaire simple :

# GLOBAL DIRECTIVES :
 
# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
 
# PID file (change this value with server stoped) :
pidfile         /var/run/slapd/slapd.pid
 
# Where the dynamically loaded modules are stored
modulepath      /usr/lib/ldap
moduleload      back_hdb
backend         hdb
 
# DATABASES DEFINITION
# Database info
database        hdb
suffix          "o=rez0.lan"
rootdn          "cn=admin,o=rez0.lan"
rootpw          {SSHA}QQR0gZclxDJ4Ry50bhw2pCTd1DF18Kdh
directory       "/var/lib/ldap/rez0.lan"

Note : Le mot de passe encrypté ligne 22 est obtenu par la commande “slappasswd”.

… puis création des répertoires, attribution des droits et test du démarrage des serveurs :

debian:~# mkdir -p /var/lib/ldap/rez0.lan
debian:~# chown -R openldap.openldap /var/lib/ldap
debian:~# chmod -R 2750 /var/lib/ldap
debian:~# /etc/init.d/slapd start
Starting OpenLDAP: slapd.
debian:~# ps -u openldap
  PID TTY          TIME CMD
 1777 ?        00:00:00 slapd

La configuration initiale est volontairement très simple et ne présente aucune sécurité ou restriction d’accès (ACL, connexion sécurisé par certificats, etc…).

Peupler l’annuaire

Création d’un fichier ldif simple pour la réalisation des tests :

# RACINE (DIT)
dn: o=rez0.lan
o: rez0.lan
objectClass: top
objectClass: organization
 
# UNITE ORGANISATIONNELLES
# Les groupes :
dn: ou=groups,o=rez0.lan
ou: groups
objectclass: top
objectclass: organizationalUnit
 
# Les utilisateurs :
dn: ou=users,o=rez0.lan
ou: users
objectclass: top
objectclass: organizationalUnit

Importation du fichier de test dans l’annuaire du maître :

debian:~# ldapadd -x -c -D "cn=admin,o=rez0.lan" -h localhost -p 389 -W -f exemple.ldif
Enter LDAP Password:
adding new entry "o=rez0.lan"
 
adding new entry "ou=groups,o=rez0.lan"
 
adding new entry "ou=users,o=rez0.lan"

qui donne la structure suivante :

Arbre LDAP de test

Arbre LDAP de test

Répliquation : mode refreshOnly
Côté “provider” (le maître)

Ce mode de réplication exige très peut de modification coté serveur. Il convient pour sa mise en application de charger le module “syncprov” et de déclarer son utilisation dans le fichier “slapd.conf” du serveur à la fin de la section définissant la base de donnée à répliquer.

En reprenant le fichier “slapd.conf” ci dessus qui ne définit qu’un arbre, nous intercalons le chargement du module lignes 14 :

modulepath      /usr/lib/ldap
moduleload      syncprov
moduleload      back_hdb

et en fin de déclaration de base ajoutons son appel :

# Add syncprov usage to provider.
overlay syncprov
# Checkpoint after 100 updates or evry 10 min
syncprov-checkpoint 100 10

Les données sont enregistrées dans la bases après 100 changements ou toutes les 10 minutes.

Côté consumer (l’esclave)

Côté client (consumer ou esclave), la mise en application de ce mode de réplication s’effectue par l’appel de la directive “syncrepl” dans la définition de la base de donnée et par sa configuration. Toujours en ce basant sur le fichier d’exemple donné plus haut la réplication en mode “refresh only” ce traduit par l’ajout des lignes suivantes en fin de déclaration de la base “rez0.lan” :

# Parameters of provider to replacate :
syncrepl rid=000
  provider=ldap://192.168.1.2
  type=refreshOnly
  interval=00:00:05:00
  retry="5 10 300 +"
  searchbase="o=rez0.lan"
  attrs="*,+"
  bindmethod=simple
  binddn="cn=admin,o=rez0.lan"
  credentials=Mot de passe en clair
  • Ligne 26, appel de la directive “syncrepl” et définition du “rid” (l’identifiant unique du serveur esclave dans la chaine de réplication).
  • Ligne 27, localisation du “provider” (le serveur à répliquer). Il peut être définit par son IP, son nom ou son fqdn (son nom complet) et suivit par le numéro de port d’écoute du serveur maître (“ldap://master.rez0.lan:389″).
  • Ligne 28, définition du type de réplication. Comme annoncé, “refreshOnly”.
  • Ligne 29, définition de l’interval de réplication au format “jj:hh:mm:ss”. Ici, l’annuaire sera répliqué toutes les 5 minutes.
  • Ligne 30, définition du comportement à adopter en cas d’erreur de synchronisation. Ici, l’esclave tentera de ce reconnecter au maitre toutes les 5 secondes les 10 premières tentatives, ensuite il ré essayera toutes les 5 minutes (300 secondes) indéfiniment (“+”). En remplacent le “+” par une valeur “N”, le consumer effectuera “N” tentative espacées de 300 secondes.
  • Ligne 31, définition de la branche à répliquer. Dans notre cas, tous l’annuaire est répliqué.
  • Ligne 32, définition des attributs à répliquer. Ici, tout est répliqué (valeur par défaut).
  • Ligne 33, type d’authentification (simple ou sasl). Dans cette exemple utilisation de la méthode simple.
  • Ligne 34 35, définition de l’utilisateur effectuant la réplication. Dans cette exemple, il s’agit du super administrateur.

NOTE I : L’exemple décrit ici est simplifié au maximum au mépris de toutes bases de sécurité. Dans le cas d’un annuaire en production, il est fortement conseillé de définir un utilisateur destiné à la réplication ayant les droits en lecture seule sur la branche à répliquer. Le mot de passe transite dans cet exemple en clair sur le réseau et est enregistré en clair dans “slapd.conf”. Pensez au minimum, à restreindre les droits sur ce fichier.
NOTE II : Toujours en raison de la simplicité de l’exemple, aucune valeur n’est indexée dans l’annuaire d’exemple. Pour obtenir de meilleurs performances de réplication, il est fortement conseillé d’ajouter l’indexation des identifiant universels unique des entrées (entryUUID) et le Change Sequence Number (entryCSN) en ajoutant les lignes suivante en fin de déclaration de base à répliquer :

index entryCSN,entryUUID eq

NOTE III : ATTENTION : Aucun commentaire n’est toléré par slapd dans la section “syncrepl”. Ce point est couramment oublié mais ne permet pas le démarrage de l’annuaire !

Répliquation : mode refreshAndPersist

Ce mode de fonctionnement plus dynamique (toute modification de l’annuaire du maître est immédiatement répercutée sur l’esclave) ne provoque pas de changement majeur dans la configuration de “slapd.conf”.

Côté “provider” (le maître)

La configuration du maître reste la même que pour le mode “refreshOnly”.

Côté consumer (l’esclave)

La configuration de l’esclave reste également la même que pour “refreshOnly” à la différence du type de réplication qui passe, ligne 28, de “refreshOnly” à “refreshAndPersist” et à la suppression de l’intervalle de réplication (ligne 29 “interval=00:00:05:00″).

# Parameters of provider to replacate :
syncrepl rid=000
  provider=ldap://192.168.1.2
  type=refreshAndPersist
  retry="5 10 300 +"
  searchbase="o=rez0.lan"
  attrs="*,+"
  bindmethod=simple
  binddn="cn=admin,o=rez0.lan"
  credentials=Mot de passe en clair

Les définitions et notes relatives au mode “refreshOnly” restent les mêmes.

Répliquation : mode Multi-Master

Jusqu’à maintenant, les modes de réplication vu ne permettaient la modification des données que depuis le serveur maître.

Le type de fonctionnement décrit maintenant permet la modification des données sur n’importe quel nœud. Comme dans le mode “refreshAndPersist”, les modifications sont appliquées immédiatement à l’autre nœud ou aux autres nœuds.

Chaque serveur ce verra attribué, dans la section globale de “slapd.conf”, un identifiant UNIQUE, le “ServerID”, dans la chaine de réplication (dans l’ensemble des serveurs répliquant l’annuaire).

Dans la définition de la base à répliquer, le mode miroir (“mirrormode”) sera activé après la déclaration et la configuration de “syncrepl”.

Enfin, le module “syncprov” devra être chargé sur chaque nœud.

Le reste de la configuration reste très proche de celle du mode “refreshAndPersist”.

# GLOBAL DIRECTIVES :
 
# Schema and objectClass definitions
...
 
# PID file (change this value with server stoped) :
pidfile         /var/run/slapd/slapd.pid
 
# Where the dynamically loaded modules are stored
modulepath      /usr/lib/ldap
moduleload      syncprov
moduleload      back_hdb
backend         hdb
 
# Server Identifiant
ServerID 001
 
# DATABASES DEFINITION
# Database info
database        hdb
suffix          "o=rez0.lan"
rootdn          "cn=admin,o=rez0.lan"
rootpw          {SSHA}0a7APSXizEujUVh4vR2Qq+P5dyd5590t
directory       "/var/lib/ldap/rez0.lan"
 
index entryCSN,entryUUID eq
 
syncrepl rid=000
  provider=ldap://192.168.1.31
  type=refreshAndPersist
  retry="5 5 300 +"
  searchbase="o=rez0.lan"
  attrs="*,+"
  bindmethod=simple
  binddn="cn=admin,o=rez0.lan"
  credentials=toto
 
mirrormode true
 
# Add syncprov usage to provider.
overlay syncprov
# Checkpoint after 100 updates or evry 10 min
syncprov-checkpoint 100 10

Le fichier de configuration “slapd.conf” sera le même sur toutes les machines de “réplicantes” à l’exception de la valeur “ServerID”, qui devrat nécessairement être différente sur chaque machine, et du “provider” dont le chemin pointera vers les différents serveurs de la chaîne de réplication.

La valeur rid ne change pas nécessairement car elle désigne l’identifiant unique d’un serveur “du point de vue du serveur qui le définit”.

Dans le cas de l’ajout d’un troisième serveur en mode multi master, les lignes 28 à 37 du fichier de configuration seront recopiée. le “rid” devra être incrémenté et le “provider” de cette nouvelle section adapté :

Bien entendu, les identifiants des utilisateurs effectuant la réplication peuvent changer.

Extrait d’un fichier “slapd.conf” de l’hypothétique “company.com” répliquant son annuaire entre Paris, Madrid et Berlin. Sur le serveur de Paris, nous trouverions :

...
syncrepl rid=000
  provider=ldap://master-madrid.company.com:389
  type=refreshAndPersist
  retry="60 10 300 +"
  searchbase="o=company.com"
  attrs="*,+"
  bindmethod=simple
  binddn="uid=replicador,l=Madrid,ou=users,o=company.com"
  credentials=Contrasena
 
syncrepl rid=001
  provider=ldap://master-berlin.company.com:389
  type=refreshAndPersist
  retry="60 10 300 +"
  searchbase="o=company.com"
  attrs="*,+"
  bindmethod=simple
  binddn="uid=replikator,l=Berlin,ou=users,o=company.com"
  credentials=Passwort
...

Optimiser la réplication

Sur de gros annuaire, la quantité de donnée échangée entre les serveurs peut devenir problématique. En mode “refeshOnly” le problème est accentué par le temps de rafraichissement qui peut considérablement varier en fonction des besoins. Afin de minimiser le temps de re synchronisation, OpenLDAP implémente deux méthode destinées à minimiser ces échanges :

  • session log : maintiens un fichier de log des entrées de l’annuaire modifiées ;
  • access log (ou delta-synchronization) : conserve une trace de toutes les modifications effectuées sur l’annuaire dans un annuaire (“accesslog”) séparé ;

Méthode “session log”

Cette méthode est directement implémentée dans l’overlay “syncprov”. Le principe est de conserver un état des entrées modifiées jusqu’au moment de la re synchronisation. Si aucune modification n’est consignée dans le journal aucun transfert n’est effectué. Sinon, les entrées modifiées sont répliqué. Dans le cas ou les modifications dépassent la taille du journal, l’annuaire est intégralement re synchroniser. Bien que plus directement destinée à la réplication “refreshOnly”, cette méthode est applicable à tous les modes de réplication.

Sa mise en application ce résume à l’ajout de la directive “syncprov-sessionlog [taille du journal]” dans la configuration de l’overlay “syncprov”. En reprenant les exemples précédents, nous obtiendrions :

# Add syncprov usage to provider.
overlay syncprov
# Checkpoint after 100 updates or evry 10 min
syncprov-checkpoint 100 10
syncprov-sessionlog 250

ou nous choisissons de conserver dans le journal la modification de 250 entrées.

Méthode “Access log” ou “delta-sync”

Cette méthode, implémentée dans l’overlay “accesslog” maintien un arbre des modification effectuées sur l’annuaire. Cet arbre est donc significativement plus petit que l’annuaire répliqué et donc beaucoup plus rapide et léger à synchroniser.

La mise en place du delta sync, ce fait en deux parties, coté provider ou serveur maître nous ajoutons au fichier de configuration de base (slapd.conf) les lignes nécessaires à l’overlay “accesslog” et à sa configuration :

# GLOBAL DIRECTIVES :
 
# Schema and objectClass definitions
...
# DATABASES DEFINITION
# Database info
database        hdb
suffix          "o=rez0.lan"
...
 
index entryCSN,entryUUID eq
 
...
# Acceslog configuration to this directory :
# - on common name "delta-sync", (logdb "cn=delta-sync")
# - only succefull add, delete, modify and modrdn are logged,
# (logops writes et logsuccess TRUE),
# - tree is clean evry day for entres older than 3 days (logpurge 3+00:00 1+00:00)
#
overlay accesslog
logdb "cn=delta-sync"
logops writes
logsuccess TRUE
logpurge 3+00:00 1+00:00
 
# Add syncprov usage to provider.
overlay syncprov
# Checkpoint after 100 updates or evry 10 min
syncprov-checkpoint 100 10
 
# Database delta-sync :
database hdb
suffix "cn=delta-sync"
...
# Some options to optimize acceslog :
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart 
 
# See http://linux.die.net/man/5/slapo-syncprov for détail off options below :
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE

Côté serveur esclave, configuration de la réplication de l’annuaire :

# GLOBAL DIRECTIVES :
 
# Schema and objectClass definitions
...
# DATABASES DEFINITION
# Database info
database        hdb
suffix          "o=rez0.lan"
...
# syncrepl with accesslog directive to delta synchronisation
syncrepl rid=000
  provider=ldap://192.168.1.31
  type=refreshAndPersist
  retry="5 5 300 +"
  searchbase="o=rez0.lan"
  attrs="*,+"
  bindmethod=simple
  binddn="cn=admin,o=rez0.lan"
  credentials=toto
  logbase="cn=delta-sync"
  logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
  syncdata=accesslog
...

En bref le fichier de configuration de l’esclave n’est modifié que pour les lignes 20, 21 et 22.
Ligne 20, on précise à syncrepl la racine de la base de réplication accesslog à utiliser.
Ligne 21, on précise que l’on ne prend en compte QUE les ajouts, modifications et suppressions ayant réussis (reqResult=0). Ceci est redondant avec le ” logsuccess TRUE” définit côté serveur maître, mais mieux vaut assurer la stabilité de l’ensemble.
Ligne 22, syncrepl devra utiliser l’overlay accesslog.

Références

slapo-syncprov(5) – Linux man page : http://linux.die.net/man/5/slapo-syncprov
LDAP for Rocket Scientists : http://www.zytrax.com/books/ldap/ (Tous viens de là)
Le site d’OpenLDAP : http://www.openldap.org/