La réplication

Introduction

La réplication est une technique de duplication de données entre plusieurs annuaires permettant ainsi d’agir sur la performance et la redondance des informations de l’infrastructure LDAP.

Attention : ne pas confondre réplication et sauvegarde des données. En effet, la technique de réplication des données ne permet pas de restaurer des informations de dates ultérieures. Ex. restaurer les informations de l’entrée d’un utilisateur du mois dernier ou bien simplement restaurer une entrée qui vient juste d’être supprimée.

Ces copies multiples sont modifiées puis synchronisées avec un ou plusieurs serveurs d’annuaire principal appelés "provider" et ensuite propagées vers un ou plusieurs annuaires secondaires appelés "consumer".

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

Configuration du "Syncrepl" en utilisant OLC

Il n’y a pas de différence de configuration entre un mode de réplication "refreshOnly" et "refreshAndPersist" si ce n’est un paramètre (type) qui les identifie dans la configuration du consumer. Ainsi l’exemple de configuration qui va suivre peut très bien s’appliquer à ces deux modes.

1. Configuration du provider

À l’aide d’un navigateur LDAP, il faut tout d’abord se positionner dans le DIT de configuration (cn=config) du provider afin d’ajouter la fonctionnalité de réplication en créant la sous-entrée olcOverlay=syncprov dans la branche du DIT (identifiée par l’attribut olcDatabase) concernée.

Voici un exemple ci-dessous d’un fichier LDIF qui autorisera la réplication du DIT déclaré dans l’entrée olcDatabase={1}bdb,cn=config :


dn: olcOverlay=syncprov, olcDatabase={1}bdb,cn=config 
objectclass: olcSyncProvConfig 
olcOverlay: syncprov 
olcSpCheckpoint: 100 10

Lorsque l’entrée olcOverlay est créée, elle possèdera (en supposant que c’est la première fonctionnalité ou overlay qui vient d’être ajoutée) le DN suivant : olcOverlay = {0} syncprov, olcDatabase = {1} bdb, cn = config. Un {0} a été...

Les problèmes liés à la réplication LDAP Sync

La réplication LDAP Sync est un mécanisme de réplication basé sur l’objet ou autrement dit par entrée d’annuaire. Lorsque la valeur d’un attribut d’une entrée de l’annuaire à répliquer est modifiée, chaque consumer recopie entièrement l’entrée modifiée. Ce qui implique que les valeurs d’attribut inchangées sont également resynchronisées... pour rien.

Un avantage de cette méthode est que lorsque plusieurs changements multiples se produisent sur une même entrée, leur séquence précise n’a pas besoin d’être reproduite ; seul l’état final de l’entrée est suffisant pour effectuer l’opération de synchronisation. Cependant, cette approche peut avoir des inconvénients lorsque des modifications se produisent sur un très grand nombre d’entrées de l’annuaire.

Par exemple, pour un annuaire composé d’une centaine de milliers d’entrées (ex. 100000 entrées) totalisant en moyenne 1 KB d’information chacune, une opération quotidienne modifie la valeur d’un attribut (représentant 1 ou 2 Bytes) pour chacune de ces entrées, cela signifie que le consumer transférera la totalité des entrées, soit 100 MB de données, alors que les modifications n’auront totalisé qu’1 ou 2 Mb de données seulement... Tout cela sans compter les données utilisées par les protocoles LDAP et TCP/IP utilisées pour le transfert des informations. Il y a donc dans ce cas de figure un gaspillage de transmission et de traitement pour les 98 % d’informations qui n’ont pas été modifiées.

Bien que cette situation soit particulière, elle sert à démontrer une faiblesse de ce mécanisme de réplication, à prendre en considération selon l’environnement de production concerné.

Sans parler aussi de problèmes qui pourraient survenir lors de changement de valeur d’attribut d’une même entrée sur deux annuaires en réplication, dans ce cas, le changement de valeur d’un attribut serait perdu.

OpenLDAP...

Les différentes architectures de réplication

1. Architecture de réplication simple "provider/consumer"

Dans ce mode de réplication, il existe un provider, qui accepte les mises à jour (les écritures) sur son DIT et un ou plusieurs consumer qui eux n’acceptent que la lecture de leurs DIT et se synchronisent à partir du provider de manière continuelle ou bien périodique.

Figure 15-4 : Réplication simple "provider/consumer"

Ce mode permet :

D’ajouter de nouveaux consumer.
D’utiliser le mécanisme de réplication "Delta-syncrepl" qui permet de réduire le volume de données à répliquer en ne synchronisant que les attributs modifiés et non sur la réplication de l’entrée entière.

En revanche, ce mode n’offre aucun service de haute disponibilité, puisqu’en cas de panne du provider, aucun consumer ne peut prendre sa place. Une phase de reconfiguration de l’annuaire sera alors obligatoire.

2. Architecture de réplication "Peer to peer" ou "multi-Peer"

Cette topologie ou architecture de réplication peut porter différents noms : Peer-to-Peer, Maître à maître, Multimaster ou bien N-Way Multi-Master et permet donc de répliquer des données entre deux ou plusieurs annuaires provider de manière bidirectionnelle. En fait, cela n’est ni plus ni moins qu’une multitude de connexions de réplication unidirectionnelle entre les provider qui seront donc configurés pour endosser les deux rôles : provider et consumer.

Figure 15-5 : Réplication multi-Peer

Ce type de topologie nécessite que tous les annuaires soient parfaitement synchronisés en utilisant pour cela une même source de temps à l’aide d’un serveur NTP.

La figure 15-5 montre une architecture de réplication de type "Multimaster" comprenant quatre serveurs OpenLDAP. Chaque serveur est configuré en tant que provider (avec la fonctionnalité olcOverlay: syncprov) et en tant que consumer pour accéder aux trois autres annuaires (en paramétrant l’attribut olcSyncrepl). Chaque provider doit être identifié de manière unique par l’attribut olcServerID et être synchronisé à...