You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2005/02/24 02:15:46 UTC
[replication] Master slave replication will not suffice
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.
-Alex
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
>> Have any recommendations? Advice? How would you proceed to
>> introduce MMR into ApacheDS?
>
>
> Hmm...I can only speak in generalities: some of the
> techniques with which I'm most familar are patented...
:(
> For replication, you always need to store extra state
> pertaining to the entries : change sequence numbers ,
Yep I figured that some kind of sequence number similar to the version
in a svn repo would need to be maintained. Almost like a txn-id.
> or similar. Try to be careful about how this is stored,
> otherwise you can end up with two databases that
> you must maintain consistency (e.g. with 2-phase commit)
> across. Ideally keep it all in the same database.
Ideally we would like to keep all data about an entry in the entry so
it's replicated with it rather than putting this info into another area
which also must be replicated.
> Be concerned about re-entrancy issues: an update
> to the local server may originate with a client, or
> with another replica, replaying its updates. Be sure
Hmmm trying to understand this. I think you're referring to
differentiating between client driven change verses changes induced by
replication in which case I would use a special replication user to
apply updates. This way the special user can bypass the replication
mechanism.
> to distinguish between the two properly to avoid re-propagating the
> updates.
> Some updates will be due to conflict resolution,
> not a direct replayed update. Much of the trickness
> is to ensure that the conflict resolution mechanism
> converges.
Hmm have not even thought about conflict resolution strategies yet. We
really need a champion to drive this process who knows what the heck
they're doing. I'm not feeling very confident myself.
> I have studied the Apache DS code, but right now
> I'm not sure I can think of specific code-related
> advice.
np
> You need to pay very special attention to testing.
Oh yeah this goes without saying in general especially for tough
problems like MMR.
Do you have an LDAP background? Just curious where your experience with
MMR is coming from :).
Thanks for the advice. I'll look this over a few more times.
-Alex
Re: [replication] Master slave replication will not suffice
Posted by David Boreham <da...@bozemanpass.com>.
> Have any recommendations? Advice? How would you proceed to introduce
> MMR into ApacheDS?
Hmm...I can only speak in generalities: some of the
techniques with which I'm most familar are patented...
For replication, you always need to store extra state
pertaining to the entries : change sequence numbers ,
or similar. Try to be careful about how this is stored,
otherwise you can end up with two databases that
you must maintain consistency (e.g. with 2-phase commit)
across. Ideally keep it all in the same database.
Be concerned about re-entrancy issues: an update
to the local server may originate with a client, or
with another replica, replaying its updates. Be sure
to distinguish between the two properly to avoid
re-propagating the updates.
Some updates will be due to conflict resolution,
not a direct replayed update. Much of the trickness
is to ensure that the conflict resolution mechanism
converges.
I have studied the Apache DS code, but right now
I'm not sure I can think of specific code-related
advice.
You need to pay very special attention to testing.
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
>> So what we need is multimaster replication.
>
>
> Probably. Having a single point of failure for writes tends to upset
> folk, even though in reality
> for most purposes it's ok (e.g .almost all
> RDBMS have this property too, but that doesn't
> tend to cause concern).
Yep I agree best to keep system going if masster is down.
>
>> This is an order of magnitude more complex than master slave
>> replication.
>
>
> More complex, but I'm not sure about order of magnitude.
> I've worked on code for both kinds. I do believe that
Have any recommendations? Advice? How would you proceed to introduce
MMR into ApacheDS?
-Alex
Re: [replication] Master slave replication will not suffice
Posted by David Boreham <da...@bozemanpass.com>.
> So what we need is multimaster replication.
Probably. Having a single point of failure for
writes tends to upset folk, even though in reality
for most purposes it's ok (e.g .almost all
RDBMS have this property too, but that doesn't
tend to cause concern).
> This is an order of
> magnitude more complex than master slave replication.
More complex, but I'm not sure about order of magnitude.
I've worked on code for both kinds. I do believe that
multimaster requires more clarity of thought in the
design, and it's much easier to do if it's in mind from
the beginning (vs. retrofit to an existing single master
design).
I believe that some of the techniques used for
MMR are patented by various usual suspects.
BTW, I think you are correct that a JMS
implementation can be used, but that only
solves part of the problem: reliable transport
of replication updates to replicas. It turns out
that this isn't a particularly large or particularly
hard pard of the overall multimaster solution,
but it's surely better to re-use than re-invent.
Re: [replication] Master slave replication will not suffice
Posted by Emmanuel Lecharny <el...@iktek.com>.
Le jeudi 24 février 2005 à 08:40 -0800, David Boreham a écrit :
> > Cool, this sounds interesting. Let's say that server A gets an update
> > to change foo=dog and and the same time server B gets an update to
> > change foo=cat. Replication takes a while and 15 minutes later, A gets
> > the update to change foo=cat from B and B gets the update to change
> > foo=dog. How does that get resolved?
>
> One of them wins. There are various possible choices,
> however you might find it useful to think of a 'principle
> of least surprise' here. e.g. if the change made later
> in time wins, that might be less of a surprise than if
> an earlier change wins.
You may also have a hierarchical strategy. A modification that occured
on a server A is less significant than the one made on the server B if
server B is a kind of "virtual master" of the server A.
Both strategy (timestamped modification & hierarchical level) may be
used.
Re: [replication] Master slave replication will not suffice
Posted by Emmanuel Lecharny <el...@iktek.com>.
> How do we synchronize their clocks?
NTP server?
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
>
>> How do we synchronize their clocks?
>
>
> I believe that clock sync is a well understood (and mostly solved)
> problem ;)
+1 nothing to worry about.
Alex
Re: [replication] Master slave replication will not suffice
Posted by David Boreham <da...@bozemanpass.com>.
> How do we synchronize their clocks?
I believe that clock sync is a well understood
(and mostly solved) problem ;)
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alan D. Cabrera wrote:
>
>
> David Boreham wrote:
>
>>> Cool, this sounds interesting. Let's say that server A gets an
>>> update to change foo=dog and and the same time server B gets an
>>> update to change foo=cat. Replication takes a while and 15 minutes
>>> later, A gets the update to change foo=cat from B and B gets the
>>> update to change foo=dog. How does that get resolved?
>>
>>
>>
>> One of them wins. There are various possible choices,
>> however you might find it useful to think of a 'principle
>> of least surprise' here. e.g. if the change made later
>> in time wins, that might be less of a surprise than if
>> an earlier change wins.
>>
> How do we synchronize their clocks?
>
Ahha! :D - that's why we got an NTP service in this diagram an in SVN:
http://incubator.apache.org/directory/images/50k-ft-architecture.png
Also as image map on the front page here:
http://incubator.apache.org/directory/
(Oh btw Enrique looks like the move of some protocol stuff broke image
map links to the repo)
http://svn.apache.org/viewcvs.cgi/incubator/directory/protocols/ntp/trunk/
-Alex
Re: [replication] Master slave replication will not suffice
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
David Boreham wrote:
>> Cool, this sounds interesting. Let's say that server A gets an
>> update to change foo=dog and and the same time server B gets an
>> update to change foo=cat. Replication takes a while and 15 minutes
>> later, A gets the update to change foo=cat from B and B gets the
>> update to change foo=dog. How does that get resolved?
>
>
> One of them wins. There are various possible choices,
> however you might find it useful to think of a 'principle
> of least surprise' here. e.g. if the change made later
> in time wins, that might be less of a surprise than if
> an earlier change wins.
>
How do we synchronize their clocks?
Regards,
Alan
Re: [replication] Master slave replication will not suffice
Posted by David Boreham <da...@bozemanpass.com>.
> Cool, this sounds interesting. Let's say that server A gets an update
> to change foo=dog and and the same time server B gets an update to
> change foo=cat. Replication takes a while and 15 minutes later, A gets
> the update to change foo=cat from B and B gets the update to change
> foo=dog. How does that get resolved?
One of them wins. There are various possible choices,
however you might find it useful to think of a 'principle
of least surprise' here. e.g. if the change made later
in time wins, that might be less of a surprise than if
an earlier change wins.
Re: [replication] Master slave replication will not suffice
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
David Boreham wrote:
>
>> 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?
>
>
> You need conflict resolution. However, the LDAP/X.500 information
> model is sufficiently simple that it's possible to perform automatic
> conflict resolution.
Cool, this sounds interesting. Let's say that server A gets an update
to change foo=dog and and the same time server B gets an update to
change foo=cat. Replication takes a while and 15 minutes later, A gets
the update to change foo=cat from B and B gets the update to change
foo=dog. How does that get resolved?
Regards,
Alan
Re: [replication] Master slave replication will not suffice
Posted by David Boreham <da...@bozemanpass.com>.
> 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?
You need conflict resolution. However, the LDAP/X.500 information
model is sufficiently simple that it's possible to perform automatic
conflict resolution.
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
Alan D. Cabrera wrote:
>
>
> Alex Karasulu wrote:
>
>> Alan D. Cabrera wrote:
>>
>>>
>>>
>>> Alex Karasulu wrote:
>>
>>
<snip/>
>> 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?
I just don't know enough to confirm - just speculating. Your guess is
as good if not better than mine.
-Alex
Re: [replication] Master slave replication will not suffice
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
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
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
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.
-Alex
Re: [replication] Master slave replication will not suffice
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
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.
The embedded server is great but keep it a single server; at least use a
logger to make changes durable. I think it would be great if the ADS
servers supported *both* embedded servers and clustered resilient servers.
Regards,
Alan
Re: [replication] Master slave replication will not suffice
Posted by David Boreham <da...@bozemanpass.com>.
> backing store. I would add that in addition to the "single unified
> mechanism" for distributing data, we will also unify the management
> interfaces.
Yes, but be careful here : it unifies the mechanism to access
the data, but not the schema nor the semantics. For example
you still need special code to, say, create a new DNS host
(because it needs to know to create the forward and reverse
record); or special code to generate an NIS automount record.
But the benefits to having a single mechanism to
read and write the data are certainly significant.
Re: [replication] Master slave replication will not suffice
Posted by Enrique Rodriguez <er...@apache.org>.
David Boreham wrote:
> Therefore to achieve distribution of service you also need
> to distribute the underlying data. There is some benefit to
> using a single unified mechanism for this (e.g. replicated
> LDAP) : no need to wrangle with N different things ---
> NIS pushes, DNS slaves, Kerberos secondaries, and so on.
>
> Therefore your idea to have an LDAP-based MMR
> mechanism, with local gateway services (NIS, DNS, KRB)
> that use the local copy of the LDAP data, makes perfect sense to me.
Yup, dead on. The approach with the current services has been to make
them "as dumb as possible"; they exist to service requests, maintain
little state, and as infrequently as possible make changes to the
backing store. I would add that in addition to the "single unified
mechanism" for distributing data, we will also unify the management
interfaces.
-enrique
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
>>> Once you have replication what's the point in embedding?
>>
>>
<snip/>
>> 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.
>
>
<snip/>
>
> Therefore your idea to have an LDAP-based MMR
> mechanism, with local gateway services (NIS, DNS, KRB)
> that use the local copy of the LDAP data, makes perfect sense to me.
Thanks for the validation!
Alex
Re: [replication] Master slave replication will not suffice
Posted by David Boreham <da...@bozemanpass.com>.
>> 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.
I think you're on the right track. What you're describing
is a 'distribution of service' approach : take a set of key
services and ensure that they're available reliably and
efficiently everywhere they're needed. An obvious approach
to ensure this is to simply run an instance of a server
for each service on every machine (or at least every
server class machine). Then, if the machine is up,
then most likely the services are available, which is a good thing.
However, having done so you now have a distrubution
of data problem. If the underlying data is not available
locally, then the benefits of distribution of service are not
achieved because the problem has simply moved from
the initial service endpoint to the data service (LDAP or
RDBMS or whatever).
Therefore to achieve distribution of service you also need
to distribute the underlying data. There is some benefit to
using a single unified mechanism for this (e.g. replicated
LDAP) : no need to wrangle with N different things ---
NIS pushes, DNS slaves, Kerberos secondaries, and so on.
Therefore your idea to have an LDAP-based MMR
mechanism, with local gateway services (NIS, DNS, KRB)
that use the local copy of the LDAP data, makes perfect
sense to me.
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
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.
-Alex
Re: [replication] Master slave replication will not suffice
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
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?
Regards,
Alan
Re: [replication] Master slave replication will not suffice
Posted by David Boreham <da...@bozemanpass.com>.
>Instead of trying to do P2P replication, conflict resolution and so forth,
>I
>would investigate a "negotiated Master" approach instead.
Floating single master sounds attractive, but it tends to
flounder on the rock of decding who is master, coping
with network partition, pending operations when an election
occurs, and so on. Getting these right
bloats the complexity back up to almost the same level
as multi master.
Re: [replication] Master slave replication will not suffice
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 24 February 2005 09:15, Alex Karasulu wrote:
> So what we need is multimaster replication. This is an order of
> magnitude more complex than master slave replication.
I don't have the formal MMR academia under my belt, and I make a general
disclaimer of having any clue of how this should be solved. However, since I
have implemented system fault tolerant systems in process control networks, I
would like to share an approach that I *think* may work rather well here as
well. (perhaps someone have suggested this already, and I have missed it,
then sorry for the noise)
Instead of trying to do P2P replication, conflict resolution and so forth, I
would investigate a "negotiated Master" approach instead.
I.e. all peers in the cluster negotiates who is the master, and forwards all
CUD requests there, and the replication flows downstream.
Also, all peers monitors the master, and if any peer have communication
problems with the master, it initiates the 'negotiation process'.
I think this limits the problem domain quite a bit, but there are still some
of the MMR issues around;
* What happens to Peer-to-Master-CUD and Master-to-Peer-replication
operations in progress when the Master dies?
* What happens to Master-to-Peer-replication operations in progress when a
Peer no longer can be reached by the Master, but the Peer itself is
operational and will initiate 'negotiation' (probably a very rare condition,
but completely possible)?
And possibly others. Note that these are still present in full MMR situations
as well (together with heaps of other failure situations).
Cheers
Niclas
Re: [replication] Master slave replication will not suffice
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
>On Wed, 23 Feb 2005 20:15:46 -0500, Alex Karasulu <ao...@bellsouth.net> 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.
>>
>>
>
>Doesn't Kerberos service use JNDI to access ApacheDS backend storage?
>So, how about modifying JNDI provider to request the alteration to the
>master behind the scene?
>
>
>
What's the point of embedding Kerberos with LDAP if communication has to
be made to another LDAP server besides the one that is embedded?
>>So what we need is multimaster replication. This is an order of
>>magnitude more complex than master slave replication.
>>
>> -Alex
>>
>>
>>
>
>- Trustin
>
>
Re: [replication] Master slave replication will not suffice
Posted by Trustin Lee <tr...@gmail.com>.
On Wed, 23 Feb 2005 20:15:46 -0500, Alex Karasulu <ao...@bellsouth.net> 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.
Doesn't Kerberos service use JNDI to access ApacheDS backend storage?
So, how about modifying JNDI provider to request the alteration to the
master behind the scene?
> So what we need is multimaster replication. This is an order of
> magnitude more complex than master slave replication.
>
> -Alex
>
- Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/