[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on ldup-replica-req-00.txt
Uppili Srinivasan wrote:
> John: Why will each server maintain "its own" increasing counter for each
> attribute.
This is the model I believe that the Bayou project uses. Each write is assigned
a number from a server specific counter. Each server then keeps track of
the latest update it has received from every server in the set of master servers.
This is done to avoid writes being replayed to servers which don't need them.
The salability problem is that each server needs to know about every other
server. I'd hope there was a solution which did away with this.
The below is not actually what I meant. I guess I must have stumbled on
an overloaded term. It is interesting though, as I believe this is the conflict
resolution policy used by Exchange, and was proposed by Chris Weiser &
John Strassner in their multi-master draft. I think this mechanism is opposed
be those who believe 'most-written-wins' isn't a desirable policy.
John
> If you mean the attribute version numbers, then there ought to
> be a systemwide version number for each attribute. The job of the conflict
> resolution policy should be to ensure systemwide convergence towards the
> same image of all items (attributes). A potential picture is:
> - When an entry is created all attributes start with version 1
> - If the same entry (DN being the same) is created in multiple places, only
> one of the entries (in its entirety) would win based on the enterprise CR
> policy (could be time stamp). So all attributes will start with version 1
> on all servers
> - If two servers update the same attribute from version n to version n+1
> then again CR policy would have to ensure that only one of the updates win
> (again possibly based on timestamps). So the system would converge to
> version n+1 for this attribute to value associated with the winner above.
>
> can you explain the scalability problem here?
>
> -Uppili Srinivasan
> ____________________________________________________________________________
> Oracle Corporation |
> Box 659510 |Phone: (650)506-3039 Internet: usriniva@xxxxxxxxxxxxx
>
> 500 Oracle Pkwy |Fax: (650)506-7122
> Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; s=usriniva
>
> CA 94065 |
> ___________________|________________________________________________________
>
>
>
>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Subject: Re: Comments on ldup-replica-req-00.txt
> Date: 21 Apr 98 11:56:00
> From: "John Merrells" <merrells@xxxxxxxxxxxx>
> Organization: Netscape Communications
> To: Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>
> CC: ietf-ldup@xxxxxxx
> References: <>
>
> Alan Lloyd wrote:
>
> > Of course - its just that these servers just become "normal"
> > users of the directory that must be authenticated and if one changes the
> > credentials of a server in one server - how does that get into the
> > second - unless servers need to use their old credentials depending if
> > they have replicated them or not... is this chicken and egg stuff.
>
> That hasn't been raised as a requirement either. An administrator's
> intention may indeed be to permanently or temporarily deny access to
> some other server. In any case, the administrators should sort it out.
>
> > > > Does this mean changes to the LDAP RFC?
> > >
> > > Probably, in the form of new controls, and possibly extended
> > > operations.
> > >
> > > > You see replication needs to be initated by either server
> > > and
> > > > replicas transferred in either direction so its either a
> > > bi-directional
> > > > LDAP server to server with transaction control and server based
> > > > management and a lot of Gods help (this is not a religious statement
> > > > ;-))
> > >
> > > It could be a session in each direction.
> > With God in most cases it seems to be simplex - but I realise it
> > is bothways with LDAP :-) see above.
>
> Alan, you've lost me with the God acronym.
>
> An LDAP Replication session could be implemented as one bi-directional
> session, or two uni-directional sessions.
>
> > Protocol fields are easy to
> > write down . eg ip6 address is just 16 bytes - now try and deploy it and
> > make it work as a global network.
>
> Um, LDAP Replication might require some extra controls to definethe start
> and end of a replcation session.
>
> > Want to ask Oracle, Ingres or Sybase about transaction locking
> > systems and deadlock issues?
>
> No, I've got a book all about it.
>
> An LDAP Replication protocol specifiction could mandate the use of
> transactions, but it's probably not essential that it does.
>
> > If they stay like DISP there is a chance of success - : -) ..
> > existance proof is good.
>
> Is that documented in X.525?
>
> Are there any documents that address using DISP for multi-master
> directory topologies?
>
> > > So far, no one's suggested this as a requirement.
> > >
> > May I suggest a feature which.........................
>
> Are you suggesting identifying an entry as a master/shadow as arequirement
> then?
>
> > > I'd wonder though... that if your application has real-time
> > > constraints then
> > > you probably don't want to store your data in some loosly consistent
> > > store.
> > X.500 permits inconsistencies - but leaves the ops people to
> > sort that out- but X.500 provides the services to always get the master
> > entry just in case the ops people dont make it.
>
> Who are ops people?
>
> 'One of the master copies', seems no better than 'One of the replica copies'.
>
> > > Also... if an entry is mastered by many servers... then you won't know
> > > which server holds the 'correct' value anyway. So it doesn't sound
> > > like
> > > this buys you much.
> > >
> > In X.500 one does via the information being tagged as copies
> > (internally in the DSA because it arrived via DISP) - and with the
> > knowledge information in the replication agreements the replica DSA
> > knows of the master - and the via DSP (distribution again - an LDAP
> > deficiency) I can request of the replica I am connected to to go to the
> > master via DSP to get it by specifying Dont Use Copy - all seamlessly to
> > the user - you see replication and distribution in X.500 work together.
> > In LDAP land all the parts arn't there yet. So replication on its own is
> > very limited....
>
> I think you're missing my point. Which of the master copies is the onetrue
> correct copy? You'll just never know.
>
> > through replication agreements and using op attrs.
> >
> > The replication scaling problem is reduced with distributed
> > directories in the first place.
>
> Reduced, but not elliminated. Say you have a set of N masters for an
> entry.Each server maintains an increasing counter which is
> used to tag attribute
> values as they're updated. These tags are then used to determine which
> values are communicated to each of its peers. The question is: 'How do
> you avoid each server having to know the highest tag value sent from
> each other server?' This seems to be the big scalability problem for
> multi-master directories. How does X.500 solve this?
>
> John
>
> --
> John Merrells
> Netscape Communications
> Directory Server
> Software Engineer
>
> http://people.netscape.com/merrells
--
John Merrells
Netscape Communications
Directory Server
Software Engineer
http://people.netscape.com/merrells