Fonctionnement du protocole de réplication "LDAP Sync"
La réplication d’un annuaire OpenLDAP est gérée par le moteur de réplication "LDAP Sync" nommé syncrepl. Il se met en œuvre du côté du consumer et se connecte par l’intermédiaire d’un thread du processus "slapd" à l’annuaire LDAP du provider. Il permet de maintenir une copie exacte de l’annuaire entier ou bien d’un fragment de celui-ci, de manière sporadique ou programmée.
syncrepl utilise le protocole LDAP Content Synchronization appelé "LDAP Sync" qui supporte deux modes de fonctionnement :
	•	Pull-based (appelé "refreshOnly") : dans ce mode, le moteur syncrepl va sonder régulièrement le "provider" et répliquer tout changement survenu depuis sa dernière connexion.
	•	Push-based (appelé "refreshAndPersist") : dans ce mode, le moteur va réceptionner les mises à jour envoyées par le fournisseur en temps réel. Cela se traduit par une connexion permanente au provider et tout changement intervenu est répliqué instantanément sur le consumer.
C’est à partir de la version 2.3 qu’OpenLDAP a introduit son nouveau protocole de synchronisation nommé "LDAP sync" devenu à partir de la version 2.4 le seul mécanisme de réplication. La fonctionnalité Syncrepl offre à la fois la réplication maître/esclave classique introduite par le service "slurpd", et la version 2.4 permet une réplication multimaître. Le protocole utilise le terme provider (plutôt que maître) pour définir la source des mises à jour de réplication et le terme consumer (plutôt qu’esclave) pour définir une destination pour les mises à jour.
Dans ce mode de réplication, le consumer déclenche toujours le processus de mise à jour. Le consumer peut être configuré pour extraire périodiquement les mises à jour du provider (refreshOnly) ou il peut demander à ce dernier d’afficher les mises à jour (refreshAndPersist). Dans tous les cas de réplication, afin de se référer sans ambiguïté à une entrée, le serveur doit conserver un numéro universellement unique (entryUUID) pour chaque entrée dans un DIT. Le processus de synchronisation est illustré à la figure 15-1 (rafraîchir uniquement) et 15-2 (refreshAndPersist).
1. Réplication en mode "refreshOnly" ou "Pull-based"
¬
Figure 15-1 : Syncrepl en mode "refreshOnly"
En mode "refreshOnly", le consumer établit une connexion avec le provider (1) et effectue une synchronisation des DIT (2 à 4), puis le consumer met fin à la connexion (5). Le consumer, en fonction de sa configuration, va reproduire ce processus périodiquement. Ce mode de synchronisation peut être considéré comme fonctionnant en mode rafale, et la durée entre chaque cycle de réplication est le temps entre les reconnexions.
¬
Le provider n’a pas de restriction sur le nombre de consumer qui peuvent le solliciter et ne possède également aucune information sur ses consumer. Tant qu’un consumer satisfait aux exigences de sécurité du provider, ses demandes de synchronisation seront exécutées.
La requête de synchronisation est essentiellement une opération de recherche LDAP étendue qui définit la base de réplication, la portée de réplication et les paramètres de recherche. Ainsi, la réplication est très flexible, pouvant donc couvrir la totalité ou partie du DIT et aussi l’intégralité ou un certain nombre d’attributs en fonction des critères de recherche.
Le provider ne conserve d’ailleurs aucune information sur le contenu des échanges qu’il a entretenu avec ses consumer. Alors, afin que le consumer sache ce qu’il doit mettre à jour lors de chacune de ses demandes de réplication/synchronisation, il se base sur un cookie de synchronisation (SyncCookie) envoyé par le provider à la fin de chaque connexion. Ce cookie contient un numéro de séquence de modification (contextCSN) - essentiellement un horodatage indiquant le dernier changement envoyé à ce consumer et qui peut être vu comme un point de contrôle de changement ou de synchronisation. Lorsque le consumer lance une session, il envoie le dernier cookie qu’il a reçu du provider pour lui indiquer son niveau de mise à jour. Si le consumer n’a pas de "SyncCookie" alors l’ensemble de l’arbre à répliquer sera synchronisé. Ce fonctionnement permet à un consumer de démarrer avec un DIT vide.
Le provider lors de la phase de synchronisation accomplira deux actions :
	•	La première action appelée "present phase" concerne les entrées qui sont encore dans le DIT (ou le fragment du DIT). Le provider transmettra l’entrée complète (le DN, l’entry UUID et l’ensemble des attributs) au consumer pour chaque entrée ayant été modifiée depuis la dernière synchronisation. En revanche, il communiquera seulement le DN et l’uuid des entrées qui n’ont pas été modifiées. Le consumer pourra mettre à jour de manière fiable ses entrées à partir des informations reçues du provider.
	•	La seconde action appelée "delete phase" concerne les entrées qui ont été supprimées du DIT depuis la dernière synchronisation. Le provider transmettra le DN et l’uuid des entrées ayant été supprimées et le consumer pourra ainsi les effacer de son propre DIT.
À la fin de la phase de synchronisation, le provider met à jour le "SyncCookie" (l’attribut contectCSN) et le diffuse au consumer, puis il met fin à la session. Le consumer l’enregistre et l’utilisera lors de l’ouverture d’une nouvelle session de synchronisation (défini par le paramètre interval de l’attribut olcSyncrepl), comme repère temporel afin d’identifier les entrées ajoutées, modifiées ou bien supprimées depuis la dernière connexion.
2. Réplication en mode "refreshAndPersist" ou "Push-based"
¬
Figure 15-2 : Syncrepl en mode "refreshAndPersist"
Ce mode de réplication fonctionne en fait de la même manière que le précédent. La différence réside sur le fait que la connexion entre le provider et le consumer ne s’interrompt jamais et est donc permanente.
Ainsi, si on reprend le schéma fonctionnel du mode précédent, à la fin de la phase de synchronisation, le provider transmet également un "SyncCookie", mais au lieu de mettre fin à la session, il la garde active. Chaque mise à jour (ajout, suppression ou modifications d’entrées) effectuée sur le DIT du provider est ainsi immédiatement communiquée au consumer qui effectuera ces modifications sur son propre DIT. Dans ce mode de réplication, il n’y a donc pas de cycle de réplication, mais une synchronisation permanente, restaurée immédiatement en cas de perte de connexion entre le provider et le consumer.