directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Question about Replication of Config Partition and Schema Partition
Date Sat, 14 Jul 2012 23:03:17 GMT
Le 7/14/12 9:13 PM, Göktürk Gezer a écrit :
> Hi Devs,
> Here i share my findings on LDAP replication in terms of OSGI layer.
>     - First of all i found nothing related to replicating configuration of
>     LDAP Server on any RFC related to replication. So replicating configuration
>     is only ApacheDS's concern because it keeps its configuration as DIT data.
Absolutely. RFC 4533 says nothing about how to implement replication nor 
how to manage the replication configuration.
>     I don't know OpenLDAP yet but don't think its the same, right?
It's clearly different, but not that much.

> And i
>     believe we shouldn't let administrators to initiate replication under
>     ou=config base. It is not standart and it is not wise.
The ida we had was to manage configuration using an Administrative Area. 
This is not yet implemented though, so we ended up with managing 
replication under ou=config atm.

> Simply replicating
>     configuration will first break the replication aggreement between servers
>     anyway ! You should set some filters on config partition entries to whether
>     replicate them, but this would be improper in terms of design IMO.
Whe you setup replication, you tell the local server with which remote 
server you want to replicate. Obviously, you don't want to replicate 
such localized information. Now, you can still consider that we share a 
global configuration between all the servers, in which you just name 
each server, with the assoictaed informations (IP, port, etc), and now 
you can setup a replication mechanism in which you express each 
configration using thoses names. For instance, if you have 3 servers A, 
B and C, you may have the shared configuration where A -r> B, B-r> C, 
B-r>A. This configuration can be replicated as is on , B and C, because 
each server will now which replication is of interest to itself.
>     - But i'm not against on replicating configuration completely. Some one
>     would want to simply clone the server in its entirety. ( This is not
>     touched by RFC as i see ) Because our OSGI distribution is Karaf based, we
>     can use Karaf Cellar here. Cellar is used to keep multiple Karaf instances
>     synched in terms of Bundles,Features, and Configuration.(We can't use its
>     configuration aspects because we're keeping our component configurations in
>     ApacheDS itself). I quickly looked through its functionality and code. It's
>     incomplete but promising. Most importantly it provides API to initiate
>     Karaf Instance replication.(Again not complete). So when replication system
>     is revisited we can make use of Cellar.
>     - I looked at Apache ZooKeeeper a bit, and we should definetely leverage
>     it in our LDAP replication system. It is simply a distributed data and
>     notification system for clusters. It has strength in node management in
>     clusters and good for implementing infrastructure related parts of
>     replication system.
> So i see no threat to OSGI from LDAP Replication. However i believe
> ou=config should be excluded from replication in any scenario.
Not sure.
>   I believe if
> we're gonna provide some way to replicate some ApacheDS instance's runtime
> layout, we should not do it by LDAP Replication. Because :
>     - It is not just config partition manages the server anymore.
>     - We just can't be sure that 2 server having the same configuration will
>     have same runtime behavior, because they might have different composition
>     of bundles.
>     - Replicating ou=config is hell of a job because of site specific
>     configuration parameters.
Unless the server can detect which configuration applies to itself.

Bottom line, there are a very litte set of information a server needs to 
keep local :
- its IP address
- its port
- its name

The name will be used to identify the configuration that applies to the 
local server.

Emmanuel Lécharny

View raw message