Outils pour utilisateurs

Outils du site


replicationldap

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

replicationldap [2015/10/06 20:06] (Version actuelle)
Ligne 1: Ligne 1:
 +{{tag>​ldap systeme}}
 +
 +=====  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 //​{{:​formation:​opg:​ldif:​replication_master.ldif|replication_master.ldif}}//​
 +
 +Le //​consumer//​ implémente,​ lui, la directive syncrepl:
 +
 +voir //​{{:​formation:​opg:​ldif:​replication_slave.ldif|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 //​{{:​formation:​opg:​ldif:​replication_multimaster.ldif|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:
 +  ​
 +<​code>​
 +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
 +</​code>​
 +
 +
 +  * //​provider//:​ adresse du serveur maître
 +  * //type//: type de replication
 +  * //​updatedn//:​ correspond au compte avec lequel on va **écrire** dans la base **[[:​locale|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)