directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <...@toolazydogs.com>
Subject Re: [replication] Master slave replication will not suffice
Date Thu, 24 Feb 2005 16:12:46 GMT


Alex Karasulu wrote:

> 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. 


Ahh, the key is that the updates can be asynchronous; including Kerberos 
threw me.  Can they really be asymchronous?  What if conflicting changes 
are sent to two different servers?


Regards,
Alan







Mime
View raw message