directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [replication] Master slave replication will not suffice
Date Thu, 24 Feb 2005 07:10:46 GMT
Alan D. Cabrera wrote:

> Alex Karasulu wrote:
>> Alan D. Cabrera wrote:
>>> Alex Karasulu wrote:
>>>> I was thinking about replication earlier today.  I was hoping we 
>>>> can quickly implement master slave replication by piggy backing on 
>>>> a JMS implementation like ActiveMQ.  It quickly occured to me 
>>>> however that there is no way we can utilize a master slave rep. 
>>>> configuration without loosing all the benefits of having embedded 
>>>> services like Kerberos, DNS, DHCP etc.
>>>> The reasoning behind this has to do with the way master-slave rep. 
>>>> works.  Basically there is one master and all other servers are 
>>>> slaves a.k.a. replicas.  A request to modify a replica returns an 
>>>> error indicating the replica is not writable along with a referral 
>>>> to the master.  I forget the exact LDAP result code returned.  The 
>>>> client would then contact the master for the alteration what ever 
>>>> it may be.  The master makes the change and propagates it to the 
>>>> replicas usually using a special replication user that bypasses 
>>>> certain checks.
>>>> Here's the problem: with a master slave setup an embedded inet 
>>>> service like Kerberos will have to contact the master of the system 
>>>> to make alterations on all replicas for any alterations to the 
>>>> DIT!  This defeats the entire purpose of embedding the service in 
>>>> the first place and limits the HA yeild from replication.
>>>> So what we need is multimaster replication.  This is an order of 
>>>> magnitude more complex than master slave replication. 
>>> Once you have replication what's the point in embedding?
>> No network latency between say,
>> DNS and LDAP or
>> Kerberos and LDAP or
>> DHCP and LDAP ...
>> Also the there is less entropy to the system.  It also means that 
>> there are not as many exposed points for attack from a security 
>> standpoint.  Intra process communication is more secure and faster 
>> than two separate inter process servers talking to each other.
>> Does this make sense or am I missing something here?  I'm begining to 
>> doubt myself because you're like the 3rd person to think there was a 
>> flaw with this reasoning.
> Your motivation is admirable but, you cannot eat your cake and have it 
> too.  :)  You propose to have intra-process servers that share state 
> w/ external processes, processes that are hopefully on different boxes 
> and, for many deployments, in separate buildings most likely in 
> different regions.

Having trouble parsing this :).  What external processes do the intra 
process servers talk to?  You lost me here.

My understanding is ...

In an ApacheDS instance (same JVM) you have say a DNS service and an 
LDAP service.  By having DNS and LDAP in the same process, DNS can just 
use the server side JNDI provider to access or modify the DIT.  The DNS 
service is not talking to something else outside of the JVM.

When replication comes into the picture thats when things get 
complicated.  If  master slave rep. (MSR) is in effect then DNS services 
in ApacheDS replicas must update records at the master ApacheDS instance 
for say Dynamic DNS operations.   The whole point is: this defeats the 
value of having DNS and LDAP in the same process at least for record 
updates.  MMR ameliorates this (I hope) because the DNS service can now 
issue the update to the local JNDI store and not have to go over the 
wire.  Replication of the change can be asynchronous.  The operation 
would still be fast without the overhead of network latency as far as 
the client is concerned.


View raw message