Outils pour utilisateurs

Outils du site


replicationldap

Réplication et distribution ldap

Résumé:

Mise en place d'une réplication d'un serveur ldap en utilisant le mécanisme de syncrepl, qui remplace le vénérable slurpd.

Distribution

biblio: http://www.zytrax.com/books/ldap/ch8/#ol-syncrepl-mm

un referral consiste à déléguer la gestion d'une partie du DIT à un serveur particulier (par exemple basé sur un découpage géographique)

Le suivi de referral peut se faire de manière automatique par le serveur (chaining) ou pas. Dans ce cas il fournit au client la référence au serveur “suivant”. C'est à la charge du client de “suivre” ou pas cette référence.

Exemple: http://www.zytrax.com/books/ldap/ch7/referral-multi.png

Réplication

Type de réplication:

  • master (RW) - slave (RO) == provider / consummer

Problème de cette archi: les clients devant réaliser des opérations d'écriture doivent pouvoir accéder au serveur maître, et rediriger les requêtes de lectures vers le serveur esclave.

Le serveur maître est un SPOF

* multi-master - les écritures peuvent se faire sur chaque acteur de la réplication. Attention, il y a des risques de contention.

Illustration: http://www.zytrax.com/books/ldap/ch2/ldap-replication.png

Réplication basée sur syncrepl :

  • refresh ( consumer pull ). Asynchrone, la synchronisation est à l'initiative du client, à des intervalles prédéfinies. L'état de la synchronisation est connu via un “cookie” de synchronisation contenant le timestamp de la dernière modification (contextCSN)
  • refresh & persist (provider push). Lors de la 1ère connexion, on procède à la synchronisation, puis la connexion est maintenue ouverte et tout changement est immédiatement propagé vers le consumer.

L'état de la synchronisation est connu au moyen d'un cookie de synchronisation contenant le contextCSN de la dernière modification enregistré par le consommateur.

Chaque entrée de l'arbre ldap est identifiée par un identifiant unique (entryUUID)

Dans tous les cas, le provider doit implémenter l'overlay syncprov - voir replication_master.ldif

Le consumer implémente, lui, la directive syncrepl:

voir replication_slave.ldif

Réplication syncrepl multi-master

synchronize your clocks first

Dans cette architecture, chaque serveur implémente à la fois les directives du provider (syncprov) et les directives du consumer (syncrepl).

Chaque serveur dispose également d'un attribut olcserverid unique.

Chaque serveur doit avoir les même schéma.

voir replication_multimaster.ldif

Prérequis:

Un serveur ldap en fonctionnement

Configuration du serveur esclave:

Elle doit être identique à celle du serveur maître, avec les directives suivantes en plus:

syncrepl rid=123
provider=ldap://servermaitre:389
type=refreshOnly
interval=01:00:00:00
searchbase="dc=example,dc=com"
filter="(objectClass=organizationalPerson)"
scope=sub
attrs="cn,sn,ou,telephoneNumber,title,l"
schemachecking=off
updatedn="cn=replica,dc=example,dc=com"
bindmethod=simple
binddn="cn=syncuser,dc=example,dc=com"
credentials=secret
  • provider: adresse du serveur maître
  • type: type de replication
  • updatedn: correspond au compte avec lequel on va écrire dans la base locale.
  • binddn: correspond au compte avec lequel on va se connecter sur le serveur maître.
  • credentials: mot de passe associé au compte “binddn”. Apparemment ce n'est pas possible de le spécifier en crypté.

Configuration du serveur:

Créer un compte dédié à la réplication, différent du rootdn, et s'assurer que les acls et les index sont correctement configurés.

On peut également rajouter les directives suivantes:

  • syncprov-checkpoint / olcSpCheckPoint ops sec force l'enregistrement sur disque de la valeur du contextCSN
  • syncprov-sessionlog size - nombre d'opération d'écriture qui seront enregistrées dans un journal pour améliorer les opérations de synchronisation.
  • index eq sur contextcsn et entryuuid

Vérification de la réplication

On peut imaginer un cron qui modifie un objet marqueur, et un script de vérification qui vérifie la bonne synchronisation de cette modification.

On peut également vérifier que la valeur de l'attribut global ContextCSN soit identique des 2 cotés. # vim: set filetype=dokuwiki:

replicationldap.txt · Dernière modification: 2015/10/06 20:06 (modification externe)