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é à une source de temps fiable. Chaque consumer doit contenir toutes les informations nécessaires (nom ou adresse IP des provider, le DIT ou la partie du DIT à répliquer, les accréditations à utiliser et le type de réplication à utiliser parmi "refreshAndPersist" et "refreshOnly") pour se connecter aux provider. La configuration sera donc la même sur chacun des serveurs : une entrée syncprov et trois entrées SyncRepl.
Ainsi, dans cette configuration, en supposant qu’un type de synchronisation "refreshAndPersist" soit utilisé, une écriture (ajout, suppression ou modification d’une entrée) sur n’importe quel maître sera immédiatement propagée à tous les autres maîtres agissant dans leur rôle de consumer.
¬
Cette architecture de réplication ne supporte pas le mécanisme de réplication "Delta-syncrepl".
a. Exemple de configuration
La configuration de l’architecture de réplication de la figure 15-5 pourra être effectuée en utilisant la configuration "OLC" ci-dessous.
Configuration du provider
La fonctionnalité "syncprov" doit être ajoutée comme sous-entrée de la définition du DIT à répliquer par l’attribut olcDatabase (ex. olcDatabase = {1} bdb, cn = config) avec l’attribut olcCheckpoint pour assurer des points de contrôle en cas d’interruption de la connexion de synchronisation.
Le fichier LDIF suivant devra être exécuté sur chacun des serveurs.
dn: olcOverlay=syncprov, olcDatabase={1}bdb,cn=config 
objectclass: olcSyncProvConfig 
olcOverlay: syncprov 
olcSpCheckpoint: 100 10
Configuration du consumer
Le fichier LDIF suivant (avec quelques ajustements précédés par ##) devra être exécuté sur chacun des serveurs.
dn: cn=config 
changetype: modify 
add: olcServerId 
olcServerId: 1         ## Doit être unique par serveur 
 
dn: olcDatabase={1}bdb,cn=config 
changetype: modify 
add: olcSyncrepl 
olcsyncrepl: {0}rid=000  
  provider=ldap://ldap2.example.com   ## A adapter par serveur 
  type=refreshAndPersist 
  retry="5 5 300 +"  
  searchbase="dc=example,dc=com" 
  attrs="*,+" 
  bindmethod=simple 
  binddn="cn=admin,ou=people,dc=example,dc=com" 
  credentials=dirtysecret 
olcsyncrepl: {1}rid=001 
  provider=ldap://ldap3.example.com   ## A adapter par serveur 
  type=refreshAndPersist 
  retry="5 5 300 +"  
  searchbase="dc=example,dc=com" 
  attrs="*,+" 
  bindmethod=simple 
  binddn="cn=admin,ou=people,dc=example,dc=com" 
  credentials=dirtysecret 
olcsyncrepl: {1}rid=002 
  provider=ldap://ldap4.example.com   ## A adapter par serveur 
  type=refreshAndPersist 
  retry="5 5 300 +"  
  searchbase="dc=example,dc=com" 
  attrs="*,+" 
  bindmethod=simple 
  binddn="cn=admin,ou=people,dc=example,dc=com" 
  credentials=dirtysecret 
- 
add: olcAccess 
olcAccess: {x}to * 
  by dn.base="cn=admin,ou=people,dc=example,dc=com" read 
  by * break 
- 
add: olcDbIndex 
olcDbIndex: entryUUID eq 
olcDbIndex: entryCSN eq 
- 
replace: olcMirrorMode 
olcMirrorMode: TRUE
Avec :
1.	L’attribut OlcServerID doit être unique et attribué par serveur. Il est toujours défini dans l’entrée cn=config (c’est un attribut de l’objet classe olcGlobal).	
2.	L’attribut olcDbIndex qui est optionnel, mais peut aider à accélérer le traitement des requêtes de lecture.	
3.	L’attribut olcAccess est nécessaire sur chacun des provider afin d’autoriser l’utilisateur de liaison (BindUser) à lire le DIT ou une partie de celui-ci. Il doit être configuré avec un numéro de séquence {x} afin de le positionner dans une série d’autorisations définissant une politique de sécurité. Si c’est le premier ou le seul attribut olcAccess, alors il faudra utiliser la valeur {0} ou l’omettre entièrement, auquel cas la valeur {0} sera attribuée lorsqu’il sera ajouté.	
4.	Les paramètres binddn et credentials (mot de passe est en clair, pas très sécurisant) sont donc utilisés par les consumer pour lire le DIT à répliquer des provider. Dans notre exemple, il est le même et ceci est parfaitement permis. Cependant, s’il est découvert sur un seul serveur alors il pourra être utilisé sur tous les autres. Une stratégie plus sûre serait d’utiliser un paramètre binddn unique pour chaque provider.	
5.	Le paramètre rid de l’attribut olcSyncrepl doit être incrémenté dans la configuration locale du serveur, mais sa valeur n’est pas propagée à l’ensemble des autres annuaires. Il n’y a d’ailleurs aucune relation entre les valeurs du paramètre rid et celles de l’attribut olcServerId.	
6.	L’attribut olcMirrormode: TRUE est obligatoire dans les architectures de réplication multimaître. Si cet attribut est absent ou a la valeur FALSE, alors toutes les mises à jour échoueront.	
L’état de chaque DIT n’est pas important lorsque des serveurs d’annuaire sont configurés pour prendre part à une configuration "Multimaster". En effet, un ou plusieurs des serveurs de cet exemple pourraient disposer de DIT vides. La synchronisation initiale se chargera de mettre à niveau le DIT de chaque serveur en fonction de l’horodatage des entrées via le cookie de contrôle (l’attribut contextCSN).
Rappel important : Ce type d’architecture de réplication nécessite une synchronisation d’horloge entre tous les serveurs. Chaque serveur doit donc être client NTP d’une source identique d’horloge. Il ne suffit pas d’utiliser une commande ntpdate à chaque redémarrage du serveur ou bien au travers d’un script, car la dérive de l’horloge peut considérablement s’emballer en fonction de l’architecture physique du serveur (exemple d’une VM).
3. Architecture de réplication "miroir"
Une architecture de réplication en mode "miroir" est en fait une configuration hybride qui fournit toutes les garanties de cohérence des informations répliquées de la réplication "provider/consumer", tout en fournissant un service de haute disponibilité grâce à la réplication "multi-peer". En effet, dans ce type d’architecture, seuls deux fournisseurs sont configurés pour se répliquer l’un à l’autre, mais un équipement externe placé au-devant des clients LDAP est utilisé pour diriger toutes les écritures vers un seul des deux serveurs. Ainsi, le deuxième fournisseur ne sera utilisé en écriture qu’en cas de panne du premier. Cette architecture peut donc s’apparenter à un cluster "Actif/Passif". Par ailleurs, si un des fournisseurs a crashé et est totalement réinstallé, alors il se mettra à jour au cours de la synchronisation initiale de réplication grâce au "syncrepl".
Pour résumer :
	•	Si un nœud est en panne, à son retour, il se met automatiquement à jour.
	•	Si le DIT d’un des nœuds est totalement ou partiellement détruit, alors quand il redémarrera, il se synchronisera complètement à l’autre nœud.
	•	Il est possible de connecter des consumer aux fournisseurs.
	•	L’intégralité des données du DIT répliqué est garantie, car seul un des deux nœuds reçoit les mises à jour (les écritures).
En revanche, ce mode nécessite :
	•	D’installer un proxy LDAP ou un équipement externe de type "load-balancer" afin de diriger les requêtes d’écriture sur un seul des deux serveurs LDAP.
¬
Figure 15-6 : Réplication miroir
La configuration d’une architecture en mode "miroir" est en fait la même que celle d’une architecture "multi-peer". En effet, cette architecture n’est ni plus ni moins qu’une topologie "multi-peer" à seulement deux nœuds. L’autre différence se situant par l’intégration d’un équipement de type "load-balancer" qui dirigera les opérations LDAP sur un seul des deux annuaires.
4. Architecture avec un proxy de réplication
Le protocole "LDAP Sync" réalise la réplication entre un provider et un ou plusieurs consumer à l’aide de deux modes "pull" et "push". Dans le premier de ces modes (pull), le consumer va chercher auprès du provider les entrées à mettre à jour, alors que dans le second mode (push) c’est le provider qui va transmettre les entrées modifiées au consumer. Malgré un sens de communication inverse entre ces deux modes, techniquement parlant, c’est toujours le consumer qui va initier la connexion. Et ce comportement peut être problématique dans des environnements de production ultra-sécurisés où des pare-feu interdisent les flux entrants.
Il existe ainsi une alternative possible en utilisant un proxy de réplication appelé "Sync_repl proxy" qui permettrait ainsi de centraliser toutes les connexions des consumer vers le provider et ainsi de n’appliquer qu’une seule règle au niveau des pare-feu : celle d’une connexion depuis le proxy vers le provider (cf. figure 15-7). Il faudra utiliser le backend "slapd-ldap" afin de configurer cette fonctionnalité.
¬
Figure 15-7 : Utilisation d’un proxy LDAP
5. Configuration du NTP
Il faut bien comprendre qu’à partir du moment où l’on souhaite construire une architecture répliquée (mais aussi lors de la configuration d’une infrastructure en haute disponibilité), il faudra faire en sorte que tous les serveurs composant cette architecture synchronisent leur horloge entre eux. Et dans ce cas, la meilleure façon de le réaliser est de se synchroniser avec des serveurs NTP.
Voici un exemple de configuration du service "ntpd" sur un serveur Linux :
[root@ldap01 ~]# cat /etc/ntp.conf 
tinker panic 0 
# Permit all access over the loopback interface.  This could 
# be tightened as well, but to do so would effect some of 
# the administrative functions. 
restrict 127.0.0.1 
 
# NTP servers to connect to 
server tick.exemple.com 
server tock.exemple.com 
#server 0.europe.pool.ntp.org 
#server 1.europe.pool.ntp.org 
#server 2.europe.pool.ntp.org 
#server 3.europe.pool.ntp.org 
 
# It is important not to use the local clock as a time source,  
often referred to 
# as the Undisciplined Local Clock. NTP has a tendency to fall  
back to this in 
# preference to the remote servers when there is a large amount  
of time drift. 
#server 127.127.1.0     # local clock 
#fudge  127.127.1.0 stratum 10 
driftfile /var/lib/ntp/drift
Cette configuration montre que le serveur consultera deux serveurs NTP : "tick.exemple.com" et "tock.exemple.com", qu’il ne tiendra pas compte de son horloge locale (#server 127.127.1.0) et qu’il ne permet pas que d’autres serveurs se connectent à lui pour se synchroniser (restrict 127.0.0.1).
6. Réaliser la première synchronisation
Comme cela a été présenté lors de ce chapitre, quel que soit le mode de réplication utilisé "syncrepl’’ ou "Delta-syncrepl", la synchronisation initiale est capable de renseigner un DIT vide. Cependant, en fonction de l’architecture informatique rencontrée, il y aura deux stratégies à adopter :
1.	Ne rien faire et partir ainsi d’un DIT vide. Cependant, si le DIT à répliquer est trop important, le processus de réplication peut prendre énormément de temps et impacter le réseau de production de l’entreprise.	
2.	Ou bien charger une copie récente du DIT à répliquer (un fichier LDIF) sur le consumer en utilisant la commande d’administration LDAP slapadd. Ainsi, lors du démarrage de la réplication, la synchronisation initiale sera faible, voire inexistante.	
Voici dans le cas de la seconde stratégie, les différentes étapes à suivre :
	•	Enregistrer (exporter) une copie au format LDIF du DIT hébergé par un provider en utilisant un navigateur LDAP ou avec la commande slapcat. Il n’est pas nécessaire dans ce cas d’arrêter le service LDAP du provider puisque tous les changements intervenus pendant et après le processus d’enregistrement seront appliqués lors de la synchronisation initiale.
	•	Arrêter le service LDAP du consumer.
	•	Charger sur le consumer le fichier LDIF en ligne de commande en utilisant la commande slapadd ci-dessous :
slapadd -l /path/to/provider/copy/ldif -w
¬
L’option -w permet de créer le "SyncCookie" le plus à jour possible.
	•	Démarrer le service LDAP du consumer.
	•	Exécuter une transaction de test sur le provider et vérifier qu’elle s’est bien propagée sur le consumer.