Présentation de OpenLDAP

OpenLDAP est un logiciel libre dérivé du premier serveur LDAP indépendant de l’université de Michigan (1996). Beaucoup d’améliorations ont été par la suite apportées.  On distingue facilement ses atouts techniques d’OpenLDAP :

• De nombreux backends.
• Des options de sécurité avancées.
• De nombreuses extensions implémentées.
• Supporté sur de nombreuses plates formes.
• autorise le changement à la volée des options de configuration de slapd.

La version 2.4.31 est à ce jour la dernière version stable d’OpenLDAP

Mécanisme de réplication OpenLDAP

Pour assurer la répartition de charge entre plusieurs serveurs et/ou la tolérance aux pannes, il est nécessaire de disposer de plusieurs LDAP avec des annuaires identiques.

Nous allons dans cet article décrire les différents mécanismes de réplication proposés par l’annuaire open source OpenLDAP.

Les versions antérieures d’OpenLdap utilisaient un mécanisme appelé slurpd (standalone LDAP Update Replication Daemon). slurpd a été remplacé par syncrepl depuis la version 2.4 d’OpenLDAP (LDAP Sync Replication engine).

Syncrepl est plus robuste et permet de mettre en place des architectures beaucoup plus complexes. Il est également normalisé par l’IETF (Internet Engineering Task Force) par la RFC 4533.

L’annuaire OpenLdap propose plusieurs types d’architectures.

• Une réplication « Maître – Esclaves (langage OpenLDAP : Provider – Consumers).
• Une réplication multi-maître.
• Une réplication en mode miroir (2 nœuds qui se synchronisent l’un sur l’autre).

Replication Provider – Consumers

Dans ce mode, il y a un maître (le provider), sur lequel sont réalisées les écritures, et des esclaves (les consumers) qui vont se synchroniser sur le maître (de manière continue ou périodique). Les esclaves sont en lecture seule uniquement.

Avantages :

• Possibilité d’ajouter facilement des nouveaux consumers.
• Possibilité de réaliser de la delta-syncrepl : réplication par attribut et non par l’entrée complète (non supporté par la réplication multi-maître).

Inconvénients :

•  Si le maître est hors service, aucun esclave ne peut facilement prendre sa place : il faut passer par une phase de reconfiguration de l’annuaire.

Réplication multi maitre

Dans ce modèle, plusieurs maîtres cohabitent ensemble sur le réseau. Des modifications peuvent être réalisées sur tous les annuaires du réseau, et les mises à jour sont donc bidirectionnelles. Ce type de réplication est supporté depuis la version 2.4 d’OpenLDAP.

Avantages:

• Utile pour la haute disponibilité.

Inconvénients :

• Ne propose pas du delta : les entrées sont répliquées entièrement : si un attribut a changé, l’entrée complète est répliquée.
• Si deux changements sont réalisés en « peu de temps » (avant que la réplication ait pu se faire), un changement sera perdu.

Mode Miroir

Un miroir est composé uniquement de deux nœuds. Ces deux nœuds sont configurés à la fois en maître et en esclave. Dans ce mode, les deux nœuds sont identiques à tout instant. Ils sont accessibles en écriture et il est donc possible de mettre à jour indifféremment l’un ou l’autre.

Avantages :

• Si un nœud est hors service, lors de son retour, il se met à jour automatiquement ;
• Si les fichiers de données d’un nœud sont détruits, lors de son redémarrage, il se synchronisera entièrement depuis l’autre nœud ;
• Un nœud étant configuré comme un maître. Il est possible d’y connecter des consumers.

Inconvénients :

•  Les traitements de masse de mise à jour d’un nœud sont plus longs qu’en mode provider/consumers, car les 2 nœuds se mettent à jour simultanément et en mode full.

Ci-dessous un exemple d’architecture mixte en prenant les avantages des différents modes de synchronisation :

La configuration est la suivante :

• 2 nœuds en mode miroir pour les écritures : un serveur actif et un serveur passif.
• Un « consumer » en lecture seule qui sera synchronisé (en temps réel ou périodiquement suivant la configuration choisie) à partir du nœud actif. Les deux nœuds en mode miroir sont à positionner sur deux sites distincts.

Une solution de load balancing et fail over (de type F5) peut être implantée pour réaliser les actions suivantes :

• Supporter le Fail over pour les écritures.
• Supporter le Fail over et le load balancing sur le consumer et le nœud passif pour les lectures.

Dans un prochain article, nous réaliserons un focus sur le load balancing et le fail over avec OpenLDAP.

In this article we will describe the different replication mechanisms provided by a directory, and especially by the open source OpenLDAP.

OpenLDAP presentation

OpenLDAP is an open source derivative of the first independent LDAP server, created by the University of Michigan (1996). Many improvements were made. OpenLDAP strengths are :

• Many backends.
• Advanced security options.
• Many extensions implemented.
• Supported on many platforms.

Version 2.4.31 is now the latest stable version of OpenLDAP.

Replication mechanism OpenLDAP

To ensure load balancing among multiple servers and / or fault tolerance, it is necessary to have multiple identical LDAP directories .

In this article we will describe the different replication mechanisms offered by the open source OpenLDAP directory.

Earlier versions of OpenLdap used a mechanism called slurpd (Standalone LDAP Update Replication Daemon). slurpd was replaced by syncrepl from version 2.4 of openLDAP (LDAP Sync Replication engine).

Syncrepl is more robust and can implement much more complex architectures. It is also standardized by the IETF (Internet Engineering Task Force) by RFC 4533.

The directory OpenLdap offers various types of architectures.

• Replication Master – Slave (OpenLDAP language : Provider – Consumers).
• A multi-master replication.
• Replication in mirror mode (two nodes that are synchronized to each other).

Replication Provider – Consumers

In this mode, there is a a master (the provider), on which the entries are written, and the slaves (consumers) that will synchronize from the master (continuously or periodically). The slaves are read-only basis.

Advantages:

• Ability to add new consumers.
• Possibility of realizing the delta-syncrepl: attribute replication, instead of entire entry replication (not supported by the multi-master replication).

Disadvantages:

• If the master is down, no slave can easily take its place: you must go through a reconfiguration phase of the directory.

Multi master replication

In this model, several masters have been living together on the network. Changes may be made on all network directories, and updates are bidirectional. This type of replication is supported since version 2.4 of OpenLDAP.

Advantages:

• Useful for high availability.

Disadvantages:

• Delta sync not available: the inputs are fully replicated: if an attribute has changed, the entire entry is replicated.
• If two changes are made “shortly” one after an other (before replication could take place), a change will be lost.

Mirror mode

A mirror is composed of only two nodes. Both nodes are configured in both master and slave. In this mode, both nodes are identical at all times. They are writable and it is possible to update either one or the other.

Advantages:

• If a node is down, on his return, it automatically updates;
• If the data files of a node is destroyed, when it restarts, it will synchronize completely from the other node;
• A node is configured as a master. It is possible to connect consumers.

Disadvantages:

• Mass treatment of update of a node are longer in fashion provider / consumers, because the two nodes are updated simultaneously and in full mode.

Below is an example of mixed architecture by taking advantages of different modes of synchronization:

The configuration is as follows:

• Two nodes in mirror mode for writes: an active server and a passive server.
• A “consumer” read-only to be synchronous (real time or periodically depending on the configuration chosen) with the active node. Both nodes are in mirror mode to be positioned on two separate sites.

A solution of load balancing and fail over (type F5) can be implemented to achieve the following:

• Fail over to support the entries.
• Support the Fail over and load balancing on the consumer and the passive node for reads.

In a future article, we will take a focus on load balancing and fail over with OpenLDAP.