[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: naming contexts
Yeah - there are those that believe they can manage the replication toplogy
information without resorting to using the Primary as the single-master for
replica topology information - I'm not one of them. The draft verbage
invites those who think they can to actively participate in the management
operations draft work that Ryan and others are working on...
So, I'm trying not to impose the limits of my understanding on others...and
to leave the door open to other approaches...I simply don't have a clue as
to how to make those other approaches work.
The one I understand how to do is to designate one of the replicas as the
Primary replica, and to REQUIRE all replica topology information changes to
be made AT THE PRIMARY and to then allow the Primary to shadow that
replica toplogy information to those servers that have a replicaSubentry.
This approach admittedly presumes that the primary replica OWNS the
replica toplogy information, and in turn might be considered to be the
owner of all the data in the replication area of the DIT. That later is
subject to much more discussion, but it's a useful simplification.
That notion of ownership returns the X.500 notion of Master as Owner
of data to the multi-master model (and is why I've always used the
term "updateable" where others insist on using "master"). If there is
a "master" in the X.500 sense of the word...owning the data...that
would be the "primary" replica. Other updateable replicas hold copies
that may be changed by users, but the data owner could still be viewed
as the primary replica.
What's nice about this approach is that it explicitly identifies who gets
to decide whether a new replica will be allowed to be added to the topology -
the primary replica does. I think that ability to constrain who may
begin replicating an area is an important defense against trawling for
data, and from denial of service attacks that create replicas and then
destroy them willy-nilly (attack: while (true) {add replica; replicate
knowledge of the new replica to everyone else so they add the replica
to their update vector and purge vector arrays; take the replica off line
without removing its information from the replica toplogy on all the other
servers so they can never purge themselves};)
This is an architypical case where even with a multi-master system, there
are still appropriate places where individual applications can and should
be able to choose to cooperate by using the multimaster directory in
a single-master fashion for their own data - in this case, the application is
LDUP, and the data are the replica toplogy information. Other applications
may similarly choose to do so, and the primary replica, used by LDUP
in this instance to designate the "chosen" replica that is to be used to
coordinate (strictly serialize) updates to its data, may be similarly used
by those other applications, though they could also use some other
mechanism to select their application-specific "single master".
Ed
=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note: Area code is 585
>>> "Timothy Hahn" <hahnt@xxxxxxxxxx> 12/06/01 10:58AM >>>
Ed,
Yes, but the explanation in the DRAFT for this attribute is MUCH LESS
restrictive than what you have been implying.
There are indications that NO Primary replica need exist, it need NOT be
the same for different replication contexts, and even that MULTIPLE
primary replicas might exist. Thus, I have not interpreted the meaning of
replicaType=Primary to be as "strong" as was implied in earlier postings
on this thread.
Regards,
Tim Hahn
Internet: hahnt@xxxxxxxxxx
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388 tie-line: 8/852.6388
fax: 607.752.3681
"Ed Reed" <eer@xxxxxxxxxxxxx>
12/06/2001 12:15 PM
To: <ietf-ldup@xxxxxxx>, Timothy Hahn/Endicott/IBM@IBMUS
cc:
Subject: RE: naming contexts
Tim - from the currently posted draft...
8.2.8. replicaType
(2.16.840.1.113719.1.142.4.4 NAME 'replicaType'
DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable,
3-ReadOnly, all others reserved'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
EQUALITY integerMatch
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE dSAOperation )
ReplicaType is a simple enumeration, used to identify what kind of
replica is being described in a Replica object entry.
It is replicaType 1-Primary that I'm speaking of.
Ed
=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note: Area code is 585
>>> "Timothy Hahn" <hahnt@xxxxxxxxxx> 12/06/01 09:42AM >>>
Ed,
In its current state, the information model does not yet contain
indicators of "primary master". I believe we are, currently, requiring
that IF replicaSubentry information is entered at different server
instances, that it WILL be entered consistently with respect to what was
entered on the other server instances. If not, then results are
indeterminant. If so, then the two servers will "synchronize".
Either that or we were thinking that the "initial set of replicaSubEntry"
information would be entered on ONE OF the servers" and then replicated to
(and so be consistent) with the OTHER servers that were referenced. The
idea being that no SINGLE server is noted as "primary master" - just that
ONE server is used to enter the "initial settings".
This is what I recall anyway,
Tim Hahn
Internet: hahnt@xxxxxxxxxx
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388 tie-line: 8/852.6388
fax: 607.752.3681
"Ed Reed" <eer@xxxxxxxxxxxxx>
Sent by: owner-ietf-ldup@xxxxxxxxxxxx
12/06/2001 10:35 AM
To: <steven.legg@xxxxxxxxxxxxx>, <ietf-ldup@xxxxxxx>,
<Kurt@xxxxxxxxxxxx>
cc:
Subject: RE: naming contexts
1) I'm pleased to see Kurt referring to a "Primary Master", as I think
such a concept is needed to represent the single-master of replica
topology information about a replication context. However,
2) I agree with Steven that what becomes interesting in a multi-master
environment is the replication context, not the naming context, held by a
server. Frankly, in the mostly-distributed directories I've worked with,
replication contexts were all that were available, since they're more
informative about what is actually held, allow clients to piece together a
minimal set of servers needed to fully traverse a distinguished name when
searching for a named entry, etc.
But here the interesting point - there IS a place for a "Primary Master"
when you ABSOLUTELY NEED some data in the DIT to be single-mastered, even
if the rest of the data can be multi-mastered. In my example 1 above,
those data are the operational attributes and subentries associated with
the definition, description and management of a replication area.
Thus, the Model (Architecture) document and, I think, the Information
Model, still retain the Primary master replica type, even if the
requirements document has dropped it.
One fine point, though - I don't know how to represent nor manage a
scenario where DIFFERENT DATA are "owned" by different PRIMARY MASTER
replicas in the same replication area...I know how to deal and manage
having a single replica designated as the primary of all the masters, but
not how to tag ownership of specific schema elements.
So, the information model places the replica type designation on the
replicaSubentry, and only one replica of the replication area is deemed to
be the "primary master" of the replication context.
Ed
=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note: Area code is 585
>>> "Steven Legg" <steven.legg@xxxxxxxxxxxxx> 12/06/01 02:35AM >>>
Kurt,
> It seems to me that the definition of a "naming context"
> in LDAP/X.500 makes little sense in the face of multi-master
> replication. A LDAP/X.500 naming context is subtree of
> entries held in a single master DSA.
>
> Consider three DSAs A, B, C where
> A masters subtree X
> B masters subtree Y
> C masters subtrees X and Y, and
> Subtrees X and Y are adjacent.
>From what follows, I assume that Y is subordinate to X.
> If A and B are masters and C is a shadow of each,
> LDAP/X.500 says that
> A holds context X, B holds context Y, and
> C holds contexts X and Y.
C holds a shadow copy of contexts X and Y.
> If C masters X and Y and A and B are shadows,
> LDAP/X.500 says that:
> A, B, C holds context X
C holds context X, which is now the union of the subtrees X and Y,
i.e. there is no longer a context Y. A holds a shadow copy of a
portion (subtree X) of context X. B holds a shadow copy of a different
portion (subtree Y) of context X.
>
> If A, B, and C master the subtrees they hold, which
> contexts does LDUP say they hold?
Having an entry mastered by more that one master DSA doesn't invalidate
the definition of naming context as far as I can see, but we do need
to be a bit more careful how we phrase things.
A holds a naming context with the context prefix being the root of the
subtree X. B holds a naming context with the context prefix being the
root of the subtree Y. C holds a naming context with the context prefix
being the root of subtree X, the same root as A but with a superset of the
entries. Off the top of my head I can't think of anything that is broken
because A and C have the same context prefix but unequal sets of entries
in their naming contexts.
For LDUP we're okay if we say we are replicating "replication contexts"
rather than "naming contexts". C can be said to hold two adjacent
replication
contexts (for subtree X and subtree Y).
>
> I can only find one reasonable way to answer this question,
> it requires each entry to have held by one and only one
> "primary" master DSA and defining the LDUP naming context
> as a subtree of entries held in a single "primary" master
> DSA. I believe this same solution can be used to define
> other terms and to detail directory models for multi-master
> replication which maps reasonable well onto the X.500 models.a
I don't think we need impose this restriction for
what is only a definitional problem.
>
> I recommend the WG consider defining the LDUP multi-master
> replication directory models such that, for any particular
> entry, there is only one "primary" master DSA and zero or
> more "secondary" master DSAs. Otherwise, defining the
> models consistent with the LDAP/X.500 models will be
> extremely difficult.
Regards,
Steven