The Suretec Blog

You already know that replicated directories are a fundamental requirement for delivering a resilient enterprise deployment, but which one to choose?

You'll probably be thinking in terms of a master server and some number of slave servers. Stop, this is old terminology now and in 2.4 they are now called provider and consumer. Let me explain.

In older releases of OpenLDAP (2.3) a master accepted directory updates from other clients, and a slave only accepted updates from a (single) master. The replication structure was rigidly defined and any particular database could only fulfill a single role, either master or slave:

As OpenLDAP now supports a wide variety of replication topologies, these terms have been deprecated in favor of provider and consumer: A provider replicates directory updates to consumers; consumers receive replication updates from providers. Unlike the rigidly defined master/slave relationships, provider/consumer roles are quite fluid: replication updates received in a consumer can be further propagated by that consumer to other servers, so a consumer can also act simultaneously as a provider. Also, a consumer need not be an actual LDAP^[?] server; it may be just an LDAP client.

The 5 main options are:

1. Syncrepl replication


2. Delta-syncrepl replication


3. N-Way Multi-Master replication


4. MirrorMode replication


5. Syncrepl Proxy Mode

1. Syncrepl is covered exhaustively in the Admin Guide, but briefly it always starts from the consumer, i.e. pull-based. Depending on how it's been configured, the consumer will check for updates at certain intervals or it will remain active and process the persistent messages from the provider, i.e. push based. It will always start from the consumer though, so bear this in mind for firewall issues. This is best used for directory replication where bandwidth isn't an issue due the fact that each consumer fetches and processes the complete changed object, including both the changed and unchanged attribute values:

For example, suppose you have a database consisting of 100,000 objects of 1 KB each. Further, suppose you routinely run a batch job to change the value of a single two-byte attribute value that appears in each of the 100,000 objects on the master. Not counting LDAP and TCP/IP protocol overhead, each time you run this job each consumer will transfer and process 1 GB of data to process 200KB of changes!

2. Delta-syncrepl came into existence due to the above fact. This isn't all bad though:

One advantage of this approach is that when multiple changes occur to a single object, the precise sequence of those changes need not be preserved; only the final state of the entry is significant. But this approach may have drawbacks when the usage pattern involves single changes to multiple objects.

Delta-syncrepl uses a changelog and the consumer checks this log for any updates. If these updates are too out of sync, the consumer will fall back to syncrepl to catch up and switch back to delta when ready.

3. N-Way Multi-Master replication is new in 2.4 and will keep quiet all the people that complained about it not being there when comparing OpenLDAP to other proprietry directory servers. Why not to use it and when to use it is discussed in full in the guide. Basically you would use it because:

- If any provider fails, other providers will continue to accept updates
- Avoids a single point of failure
- Providers can be located in several physical sites i.e. distributed across the network/globe.
- Good for Automatic failover/High Availability

4. MirrorMode replication is for Active-Active Hot-Standby and is often the best solution versus N-Way multimaster:

In MirrorMode two providers are set up to replicate from each other (as a multi-master configuration), but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync.

5. Syncrepl Proxy Mode is used for push-based replication and can be used to replace slurpd whereby the provider pushes out changes. This is useful when a provider is behind a firewall which doesn't allow incoming connections and your slaves are outside the main network.

Hopefully above helps you pick which replication to technique to use, but to quickly decide, ask yourself:

1. Is bandwidth an issue?
2. Where do I want my directories located?
3. What firewalling do I have?
4. What is most important to me; the ability to accept writes? an available directory? Distributed directories? Easy backups (mirrormode and N-way need careful planning)?

There are more questions to ask and answer, but I'm sure you'll get there with the help of the docs and the OpenLDAP Project support facilities. If not, speak to us.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.