Hi,

Le 21/04/2010 21:05, Siddhartha Jain a écrit :

Hi,

First, kudos to OpenLDAP team for the progress they have made with 2.4. I am returning to use OpenLDAP after nearly a decade and it is heartening to see all the new features even when going from 2.3 to 2.4 (As a side rant, it is painful to see Redhat/CentOS still ship 2.3.x. RedHat might do it to push their own DS over OpenLDAP but why CentOS)?

1. From the OpenLDAP guide, I see that replication is setup to replicate

both – config and information trees.

a. With each master having a unique “ServerID”, does it mean that config replication won’t overwrite certain attributes like ServerID?

No. Replication of cn=config includes all attributes, no exceptions (unless configured otherwise, but I assume you're referring to the example in http://www.openldap.org/doc/admin24/replication.html#N-Way Multi-Master)

b. How are multiple “ServerID” values handled when the replication config is introduced?

Each serverID value should have an associated LDAP URL. Thus, each server can recognize which serverID is "it's own". For example : serverID: 1 ldap://1.2.3.4/ serverID: 2 ldap://1.2.3.5/

slapd will then compare this URL to it's listeners passed with -h option on startup, and use the corresponding serverID.

So you can put all necessary serverIDs in one config, and let it be replicated everywhere.

c. What about credentials used for rootDN of various databases? Do they get sync-ed too?

Yes.

2. What is the best way to setup a new master with empty databases?

Slapcat from an existing one and Slapdadd to the new one? Or, let replication take care of it? Network traffic issues aside, my point is how does timestamp matching work for non-existant objects (in the new master vs existing). Or, put differently, how is deletion vs new/empty database differentiated? Why wouldn’t replication consider the non-existence of databases in the new master as all databases having been deleted?

This is mostly covered by the syncrepl protocol.

I set up new servers by inserting a minimal config tree, that's only purpose is to replicate the whole config tree from an existing master. It's a simple config database with one syncrepl statement.

This pulls in all config, and then all data.

3. From 18.2.2.3 of the Guide “Arguments against Multi-Master replication”.

/4. //" If connectivity with a provider is lost because of a network partition, then "automatic failover" can just compound the problem"/

Care to expand on this, please?

I assume this is referring to the fact that if your LDAP clients are using n multi-master servers, and one goes offline or is inaccessible, and LDAP clients fallback to another server, the overall load is going to go up on the other servers, which may cause the system as a whole to be unresponsive.

/5. //" If a network is partitioned and multiple clients start writing to each of the "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider"/

How so? If all masters are sync-ed with NTP tighly, then shouldn't this issue take care of itself when a partitioned master(s) comes back online and reconnect.

Yes. But the syncrepl protocol only reconciliates by copying whole entries. So if during a network partition the same entry (let's say uid=john,o=somewhere) is modified on two servers, and two different attributes are changed, then when the two servers connect again, only the most recent modification will be kept.

Hope this helps, Jonathan