< draft-ietf-ldup-usage-profile-05.txt   draft-ietf-ldup-usage-profile-06.txt >
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003
Internet-Draft Richard V. Huber Internet-Draft Richard V. Huber
LDAP Duplication/Replication/Update Gerald F. Maziarski LDAP Duplication/Replication/Update Gerald F. Maziarski
Protocols WG AT&T Laboratories Protocols WG AT&T Laboratories
Intended Category: Informational Ryan D. Moats Intended Category: Informational Ryan D. Moats
Expires: December 2003 Lemur Networks Expires: March 2004 Lemur Networks
June 2003 September 2003
General Usage Profile for LDAPv3 Replication General Usage Profile for LDAPv3 Replication
draft-ietf-ldup-usage-profile-05.txt draft-ietf-ldup-usage-profile-06.txt
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 45
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
Support for replication in LDAP directory systems is often one of the Support for replication in LDAP directory systems is often one of the
key factors in the decision to deploy them. But replication brings key factors in the decision to deploy them. But replication brings
design constraints along with its benefits. design constraints along with its benefits.
We discuss some of the factors that should be taken into consideration We discuss some of the factors that should be taken into consideration
when designing a replicated directory system. Both programming and when designing a replicated directory system. Both programming and
architectural/operational concerns are addressed. architectural/operational concerns are addressed and both single- and
multi-master directories are considered.
Table of Contents Table of Contents
1 Introduction........................................................2 1 Introduction........................................................3
2 Meta-data Considerations............................................3 2 Meta-data Considerations............................................3
2.1 Schema Considerations...........................................3 2.1 Schema Considerations............................................3
2.2 Replication Agreements..........................................4 2.2 Replication Agreements...........................................5
2.3 Access Control..................................................5 2.3 Access Control...................................................5
2.4 Change Logs.....................................................6 2.4 Change Logs......................................................6
3 Naming Considerations...............................................6 3 Naming Considerations...............................................6
4 Conflict Resolution Considerations..................................7 4 Conflict Resolution Considerations..................................7
4.1 Consistent Access after Changes.................................7 4.1 Consistent Access after Changes..................................7
4.2 Conflict Resolution in Single-Master Systems....................8 4.2 Conflict Resolution in Single-Master Systems.....................8
4.3 Problem Cases...................................................9 4.3 Problem Cases....................................................8
4.3.1 Atomicity....................................................9 4.3.1 Atomicity.....................................................8
4.3.1.1 Locking..................................................9 4.3.1.1 Locking...................................................8
4.3.1.2 Partitioning............................................10 4.3.1.2 Partitioning..............................................9
4.4 General Principles.............................................10 4.4 General Principles...............................................9
5 Failover Considerations............................................10 5 Failover Considerations............................................10
5.1 Common Issues..................................................11 5.1 Common Issues...................................................10
5.2 Single Master Issues...........................................11 5.2 Single Master Issues............................................11
5.3 Multi-Master Issues............................................13 5.3 Multi-Master Issues.............................................12
6 Other Issues.......................................................13 6 Other Issues.......................................................12
6.1 Locking........................................................13 6.1 Locking.........................................................12
6.2 Backup and Restore.............................................14 6.2 Backup and Restore..............................................13
7 Impact of Non-LDAP Changes/Constraints.............................14 7 Impact of Non-LDAP Changes/Constraints.............................13
7.1 Changes Outside of LDAP........................................14 7.1 Changes Outside of LDAP.........................................13
7.2 Application Triggers...........................................15 7.2 Application Triggers............................................14
7.3 Policy Conflicts Across Servers................................15 7.3 Policy Conflicts Across Servers.................................14
8 Security Considerations............................................16 8 Security Considerations............................................15
9 Acknowledgements...................................................16 9 Acknowledgements...................................................15
10 References........................................................16 10 References........................................................15
Authors' Addresses...................................................17 Authors' Addresses...................................................16
Full Copyright Statement.............................................18 Full Copyright Statement.............................................16
1 Introduction 1 Introduction
As LDAP directories become part of the critical infrastructure for As applications come to rely on LDAP directories as part of their
applications maintaining high reliability and availability is mission-critical infrastructure, the need for highly reliable and
significant. highly available LDAP systems will increase.
Distributed, replicated directories can reduce reliability and Distributed, replicated directories can increase reliability and
capacity problems. However, applications that work well with a reduce capacity problems. Nevertheless, applications which work well
single, standalone directory can develop problems in a distributed with a single, standalone directory may develop problems in a
environment unless both the applications and the environment are distributed environment unless both the applications and the
carefully designed. environment are designed with data distribution as one of the
criteria.
While particular areas of concern depend partly on whether the While the detailed design criteria will depend partly on whether the
distributed directory is a single-master or multi-master system most distributed directory is a single-master or multi-master system many
concerns that are common to both. This document flags some issues as concerns are common to both. This document flags some issues as being
being specific to either single-master or multi-master directories. specific to either single-master or multi-master directories;
Unflagged issues pertain to both. unflagged issues pertain to both.
The current replication framework provides no easily separable subset Any given class of directory applications (e.g. white pages, policy,
of functions for single-master and multi-master replication, therefor authentication and authorization) is not inherently single- or multi-
this addresses general issues regarding the deployment of single- master. This choice will depend on the requirements
master and multi-master directory systems. There may be additional (reliability/availability, update procedures, performance, etc.) of a
drafts in the future that address specific applications. specific instance of the application. Therefore, this document
addresses general issues regarding the deployment of single- and
multi-master directory systems. There may be future documents that
address specific applications.
2 Meta-data Considerations 2 Meta-data Considerations
Any LDAP directory contains meta-data as well as the user data in the Any LDAP directory contains meta-data as well as the user data in the
directory. Examples of this meta-data include descriptions of the directory. A non-exhaustive list of meta-data includes descriptions
data in the directory (e.g. schema), policies for use of the data of the data in the directory (e.g. schema), policies for use of the
(e.g. access controls), and configuration/status information (e.g. data (e.g. access controls), and configuration/status information
replication agreements); this is not an exhaustive list. (e.g. replication agreements).
This meta-data is stored in the directory itself, frequently This meta-data is stored in the directory itself, accessible as
accessible as regular data or as operational attributes. Issues arise regular data or as operational attributes. Issues may arise when
when meta-data stored in the directory is replicated. However, not meta-data stored in the directory is replicated. However, not
replicating meta-data also causes issues to arise. replicating meta-data may also be problematic.
This section examines some of the potential problems.
2.1 Schema Considerations 2.1 Schema Considerations
If the schema of one or more of the copies of a replica differs from If the schema of one or more of the copies of a replica differs from
the schema of the other replicas, then there is a possibility of the schema of the other replicas, then there is a possibility of
schema mismatch when data is exchanged between them. The schema schema mismatch when data is exchanged between them. The schema
extensibility feature of LDAP nearly guarantees that replica groups extensibility feature of LDAP nearly guarantees that replica groups
comprised of a heterogeneous mix of systems will not contain comprised of a heterogeneous mix of systems will not contain
homogeneous schema because of directory vendors' built-in extensions. homogeneous schema because of directory vendors' built-in extensions.
A given directory may not utilize all of the elements of its schema, A given directory may not use all of the elements of its schema, so
so schema differences do not always lead to schema mismatches during schema differences do not always lead to schema mismatches during
replication. replication.
Schema mismatch issues are further complicated by the possibility of Schema mismatch issues are further complicated by the possibility of
replicating the "subschemaSubentry" itself. Some directories replicating the "subschemaSubentry" itself. Some directories use this
distribute schema changes through that mechanism. Currently there is technique to distribute schema changes. Currently there is no
no standard for LDAP schema representation within the standard for LDAP schema representation within the subschemaSubentry.
subschemaSubentry. In the absence of such a standard, full schema In the absence of such a standard, full schema interoperability is not
interoperability is not possible in the IETF sense. Directory possible in the IETF sense. Directory designers should establish
designers should establish common schema on all servers holding a common schema on all servers holding a common replica, and should
replica. avoid use of vendor-specific attributes.
The following is a partial list of possible schema mismatches: The following is a partial list of possible schema mismatches:
1. Object class not defined 1. Object class not defined
2. Structure Rule of an object class 2. Structure Rule of an object class
3. Structural vs. Auxiliary in an object class 3. Structural vs. Auxiliary in an object class
4. Optional vs. Mandatory attribute in an object class 4. Optional vs. Mandatory attribute in an object class
5. Object identifiers differ on an attribute type or on an object 5. Object identifiers differ on an attribute type or on an object
class class
6. Type and number of attributes defined in a class 6. Type and number of attributes defined in a class
skipping to change at page 4, line 27 skipping to change at page 4, line 38
8. Base syntax of an attribute type 8. Base syntax of an attribute type
9. Multi-valued vs. single-valued attribute types 9. Multi-valued vs. single-valued attribute types
10. Matching rule of an attribute type 10. Matching rule of an attribute type
11. Naming collisions of attribute type names 11. Naming collisions of attribute type names
12. Attribute name aliasing ("street" vs. "streetAddress" vs. 12. Attribute name aliasing ("street" vs. "streetAddress" vs.
"Strasse") "Strasse")
13. ACL format (and consequently, ACL calculus) 13. ACL format (and consequently, ACL calculus)
Schema mismatches that cause data corruption in one or more of the Schema mismatches that cause data corruption in one or more of the
replicas must result in meta-data (e.g. log entries) in order to replicas must result in meta-data (e.g. log entries) in order to
comply with Requirement P7 of [RFC3384]. However, not all schema comply with Requirement P7 of [RFC3384]. Note that schema differences
differences produce corruption in all circumstances. Some schema do not produce corruption in all circumstances. Some schema
differences may have little or no impact on the proper storage of differences may have little or no impact on the proper storage of
replicated data. However, any time data is added to the directory, replicated data. However, any time data is added to the directory,
replication may result in data corruption due to a schema mismatch. replication between heterogeneous schemas may result in data
corruption due to a schema mismatch.
Here are some options for dealing with such potential mismatches: Options for dealing with such potential mismatches include:
- Use fractional replication to replicate only those attributes - Use fractional replication to replicate only those attributes
that do not have differences that do not have differences
- Removal of all schema mismatches. - Remove all schema mismatches
- Use the same schema on all systems - Use the same schema on all systems
The tool described by requirement AM8 of [RFC3384] would help The tool described by requirement AM8 of [RFC3384] would help
designers detect schema conflicts as early as possible. designers detect schema conflicts as early as possible.
2.2 Replication Agreements 2.1.1.1 Replication Agreements
Replication Agreements are central to replication, as they allow Replication Agreements are central to replication, as they allow
configuration of most of the aspects of the replication process, configuration of most of the aspects of the replication process,
including the triggers for replica cycles (from Requirement M1 in including the triggers for replica cycles (from Requirement M1 in
[RFC3384]), critical OID information (from Requirement M6 in [RFC3384]), critical OID information (from Requirement M6 in
[RFC3384]), and replication process parameters (Requirement M7 in [RFC3384]), and replication process parameters (Requirement M7 in
[RFC3384]). Through the use of a standard replication agreement [RFC3384]). Through the use of a standard replication agreement
schema (Requirement SC2 of [RFC3384], [InfoMod]) it is possible to schema (Requirement SC2 of [RFC3384], [InfoMod]) it is possible to
replicate the replication agreement. replicate the replication agreement.
If a replication agreement includes replication credentials, the If a replication agreement includes replication credentials, the
agreement should be read protected in the directory and transport of agreement should be read and write protected in the directory, and
the replication agreement should be encrypted. transport of the replication agreement should be encrypted.
When replication agreements are themselves distributed via When replication agreements are themselves distributed via
replication, they are subject to same "loose consistency" problems replication, they are subject to same "loose consistency" issues (due
(due to replication delay and deferred conflict resolution) as other to replication delay and deferred conflict resolution) as other data.
data. Even a temporary inconsistency among replication agreements may Even a temporary inconsistency among replication agreements may cause
cause unbalanced replication and further inconsistency. As "multi- unbalanced replication and further inconsistency. As "multi-
mastering" complicates "loose consistency" issues, avoidance of these mastering" complicates "loose consistency" issues, avoidance of these
issues by making all replication agreement changes through the same issues by making all replication agreement changes through the same
master (see Sections 4 and 5) is strongly advised. master (see Sections 4 and 5) is strongly advised.
2.3 Access Control 2.2 Access Control
The following considerations complicate replication of Access Control The following considerations complicate replication of Access Control
Information: Information:
- Access Control Information (ACI) is treated as though it were - Access Control Information (ACI) is treated as though it were
stored as attributes in the directory [RFC2820] stored as attributes in the directory [RFC2820]
- LDAP [RFC2251] declares that changes resulting from a single LDAP - LDAP [RFC2251] declares that changes resulting from a single LDAP
MODIFY are atomic (but see caveats for multi-master replication MODIFY are atomic (but see caveats for multi-master replication
in Sections 3 and 4) in Sections 3 and 4)
- The ACI affecting a given entry may not be part of that entry (it - The ACI affecting a given entry may not be part of that entry (it
could be part of a group entry or part of an ancestor of the could be part of a group entry or part of an ancestor of the
entry in question) entry in question)
- The ACI cannot always be changed atomically with associated data - The ACI cannot always be changed atomically with associated data
changes changes
- The interaction of replication and partitioning is still unclear - The interaction of replication and partitioning is still unclear
(i.e. what happens when access control policy is inherited from (i.e. what happens when access control policy is inherited from
an area of replication that is not held locally). an area of replication that is not held locally)
- Thus, if you aren't careful, you can leave windows where data is
unprotected Do not leave windows where data is unprotected.
To reduce risk: To reduce risk:
- In all environments, access control changes should be made before - In all environments, access control changes should be made before
adds and after deletes adds and after deletes
- In multi-master environments, access control changes and the - In multi-master environments, access control changes and the
associated data changes should be made on same system. associated data changes should be made on same system.
Even when ACI is faithfully replicated (with the same transfer format) Even when ACI is faithfully replicated (with the same transfer format)
among heterogeneous members of a replica group, there is no guarantee among heterogeneous members of a replica group, there is no guarantee
that an ACI change is expressed similarly everywhere in the group. that an ACI change is expressed similarly everywhere in the group.
This caveat is partly due to the open issues with respect to This caveat is partly due to the open issues with respect to
partitioning mentioned above, and partly due to vendor differences partitioning mentioned above, and partly due to vendor differences
with regard to the expression of security policy. with regard to the expression of security policy.
2.4 Change Logs 2.3 Change Logs
Requirement G4 of [RFC3384] states that meta-data must not grow Requirement G4 of [RFC3384] states that meta-data must not grow
without bound. Since it is unrealistic to assume that meta-data won't without bound. Since it is unrealistic to assume that meta-data won't
be needed during replication, designers must consider how and when be needed during replication, designers must consider how and when
meta-data can be purged. meta-data can be purged.
Replicas that use connections with intermittent quality should use Replicas that use connections with intermittent quality should use
explicit replica cycle scheduling. Since the systems know when explicit replica cycle scheduling. Since the systems know when
replication should have occurred, delayed replication can be detected replication should have occurred, delayed replication can be detected
and manual intervention initiated before the meta-data grows without and manual intervention initiated before the meta-data grows without
skipping to change at page 6, line 36 skipping to change at page 6, line 36
In a multi-master system, it is possible for a consumer to receive In a multi-master system, it is possible for a consumer to receive
changes that cannot be applied. For example, a modify request for an changes that cannot be applied. For example, a modify request for an
entry may arrive before the add request that creates that entry. The entry may arrive before the add request that creates that entry. The
replication system will typically queue this change and wait for replication system will typically queue this change and wait for
additional changes (see Section 3.3). additional changes (see Section 3.3).
3 Naming Considerations 3 Naming Considerations
A number of naming models have been proposed for directories A number of naming models have been proposed for directories
([RFC1255], [RFC2377], [CIMNames]), and many others have been ([RFC1255], [RFC2377]), and many others have been implemented on an ad
implemented on an ad hoc basis. Each of these models specifies the hoc basis. Each of these models specifies the naming attributes to be
naming attributes to be used and provides rules for using them which used and provides rules for using them which may also include
may also include containment rules. containment rules.
The naming plan applies to the directory as a whole, not the The naming plan applies to the directory as a whole, not the
individual servers holding replicas. Therefore, in a heterogeneous individual servers holding replicas. Therefore, in a heterogeneous
replicated environment, all of the replicating servers must be capable replicated environment, all of the replicating servers must be capable
of supporting all of the rules for the naming plan in use for that of supporting all of the rules for the naming plan in use for that
directory. directory.
Some directory implementations have naming constraints (e.g. Some directory implementations have naming constraints (e.g.
containment rules, restrictions on attributes that can be used for containment rules, restrictions on attributes that can be used for
naming). If such an implementation is part of a replicated directory, naming). If such an implementation is part of a replicated directory,
those constraints will have to be observed by all participating those constraints will have to be observed by all participating
directories. If the environment contains implementations with directories. If the environment contains implementations with
incompatible constraints there is a major problem. This should be incompatible constraints there is a major problem. This should be
checked as early in the design phase as possible. checked as early in the design phase as possible.
Applications often have their own requirements on naming; in this case Applications often have their own requirements on naming; if a
the directory will have to support multiple naming schemes. Thus, if directory supports multiple applications it may have to support
two independent applications start sharing previously separate multiple naming schemes. Thus, if two independent applications start
directory information, care should be taken that the naming is sharing previously separate directory information, care should be
consistent across the applications. A difference in name form may be taken that the naming is consistent across the applications. A
accepted through LDUP without constraint violation, but nevertheless difference in name form may be accepted through LDUP without
result in unexpected behavior from a cross-application perspective. constraint violation, but nevertheless result in unexpected behavior
Consistent naming is not only important to the directory, but to the from a cross-application perspective. Consistent naming is not only
applications that consume directory information as well. important to the directory, but to the applications that consume
directory information as well.
4 Conflict Resolution Considerations 4 Conflict Resolution Considerations
4.1 Consistent Access after Changes 4.1 Consistent Access after Changes
Many operations on a directory are done as a set of steps. For Many operations on a directory are done as a set of steps. For
example, a new object may be created by one operation, and its values example, a new object may be created by one operation, and its values
may be filled in as part of a separate LDAP operation. An may be filled in as part of a separate LDAP operation. An
administrator may add a user to a directory, and that user may then administrator may add a user to a directory, and that user may then
try to log in using the new entry. try to log in using the new entry.
skipping to change at page 7, line 49 skipping to change at page 7, line 46
it should be standard practice to ask the user to wait a while before it should be standard practice to ask the user to wait a while before
trying to use the entry. In the case where the new object must be trying to use the entry. In the case where the new object must be
filled in, the application should make appropriate use of LDAP filled in, the application should make appropriate use of LDAP
sessions to make sure that the same server is reached for both sessions to make sure that the same server is reached for both
operations. operations.
As a general rule, an LDAP application should bind once and not unbind As a general rule, an LDAP application should bind once and not unbind
until a complete set of related operations have been performed. To until a complete set of related operations have been performed. To
achieve load balancing of write operations in a multi-master achieve load balancing of write operations in a multi-master
environment, balancing the write-enabled connections is recommended environment, balancing the write-enabled connections is recommended
over balancing LDAP write operations. over balancing the individual LDAP write operations.
In the single-master case, all write requests go to one server. If a In the single-master case, all write requests go to one server. If a
set of related reads and writes are done, they should all be done on set of related reads and writes are done, they should all be done on
the master if possible. Ideally, only sets of related operations that the master if possible.
cannot include a write should go to one of the slave servers. But
load balancing concerns may make this impractical.
In some cases, related requests will deal with data in different In some cases, related requests will deal with data in different
partitions that are not all available on a single server. In this partitions that are not all available on a single server. In this
case, it is safer to keep sessions open to all servers rather than case, it is safer to keep sessions open to all servers rather than
closing the session with one server and opening one with another closing the session with one server and opening one with another
server. server.
It may not always be obvious to clients that they are using different It may not always be obvious to clients that they are using different
servers. If a load distribution system is used between the client and servers. If a load distribution system is used between the client and
the server, the client may find that a change request and a subsequent the server, the client may find that a change request and a subsequent
skipping to change at page 8, line 38 skipping to change at page 8, line 28
4.2 Conflict Resolution in Single-Master Systems 4.2 Conflict Resolution in Single-Master Systems
It is possible that resolution conflicts could occur in a single It is possible that resolution conflicts could occur in a single
master replication system. Because requirement SM2 of [RFC3384] is a master replication system. Because requirement SM2 of [RFC3384] is a
"SHOULD" and not a "MUST", it is possible for implementers to reorder "SHOULD" and not a "MUST", it is possible for implementers to reorder
changes. If changes are reordered, it is quite possible for a changes. If changes are reordered, it is quite possible for a
conflict to occur. Consider a case where schema changes are declared conflict to occur. Consider a case where schema changes are declared
critical and must be moved to the front of the replication queue. critical and must be moved to the front of the replication queue.
Then the consumer servers might have to delete an attribute that still Then the consumer servers might have to delete an attribute that still
has values, and later process requests to delete the values of that has values, and later process requests to delete the values of that
attribute. now undefined attribute.
However, directory administrators may have scenarios where re-ordering However, directory administrators may have scenarios where re-ordering
of replication information is desirable. On a case-by-case basis, the of replication information is desirable. On a case-by-case basis, the
directory administrator should make such decisions. directory administrator should make such decisions.
Many vendors may not implement conflict resolution for single-master Many vendors may not implement conflict resolution for single-master
replication. If such a system receives out-of-order changes from a replication. If such a system receives out-of-order changes from a
system that does support them, replication errors will almost system that does support them, replication errors will almost
certainly occur. Designers should be aware that mismatches in the certainly occur. Designers should be aware that mismatches in the
capabilities of replicating single-master directories could cause capabilities of replicating single-master directories could cause
skipping to change at page 10, line 4 skipping to change at page 9, line 34
the value of X should be 0 and the value of Y should be "USER1" But the value of X should be 0 and the value of Y should be "USER1" But
what is the value of Z at the end of the replication cycle? If it is what is the value of Z at the end of the replication cycle? If it is
42, then the atomicity constraint on the change from B has been 42, then the atomicity constraint on the change from B has been
violated. But for it to revert to its previous value, grouping violated. But for it to revert to its previous value, grouping
information must be retained. Therefore, it is not clear when such information must be retained. Therefore, it is not clear when such
information may be safely discarded. Thus, requirement G6 in information may be safely discarded. Thus, requirement G6 in
[RFC3384] may be violated. [RFC3384] may be violated.
The utility of locking mechanisms cannot be guaranteed with multi- The utility of locking mechanisms cannot be guaranteed with multi-
master replication, and therefore results are likely to be misleading. master replication, and therefore results are likely to be misleading.
As discussed further in section 6.1 below, its use in multi-master As discussed further in section 6.1 below, its use in multi-master
environments should be deprecated. environments should be deprecated.
4.3.1.2 Partitioning 4.3.1.2 Partitioning
Partitioning (design of replica groups) also adds complexity. For Partitioning (design of replica groups) also adds complexity. For
example, suppose two servers, A and B, are members of a replica-group example, suppose two servers, A and B, are members of a replica-group
for area of replication X while servers B and C are members of for area of replication X while servers B and C are members of
replica-group for area Y. It is possible to issue a ModifyRDN replica-group for area Y. It is possible to issue a ModifyRDN
operation on server B that moves an entry from area X to area Y. operation on server B that moves an entry from area X to area Y.
Replication in area X would delete the entry on server A while Replication in area X would delete the entry on server A while
replication in area Y would add the entry to server C. However, if replication in area Y would add the entry to server C. However, if
another change on server C prevented the add operation from working another change on server C prevented the add operation from working
(e.g. an entry with the same RDN but a different GUID exists there (e.g. an entry with the same RDN but a different GUID exists there
already), then the change on server A is inconsistent and will need to already), then the change on server A is inconsistent and will need to
be reversed. Other examples of cases of this class include group be reversed. Other examples of cases of this class include group
membership modification and access control scoping. membership modification and access control scope.
4.4 General Principles 4.4 General Principles
The examples above discuss some of the most difficult problems that The examples above discuss some of the most difficult problems that
can arise in multi-master replication. Dealing with them is difficult can arise in multi-master replication. Dealing with them is difficult
and can lead to situations that are quite confusing to the application and can lead to situations that are quite confusing to the application
and to users. and to users.
The common characteristics of the examples are: The common characteristics of the examples [RFC3384] are:
1. Several directory users/applications are changing the same data 1. Several directory users/applications are changing the same data
2. They are changing the data at the same time 2. They are changing the data at the same time
3. They are using different directory servers to make these changes 3. They are using different directory servers to make these changes
4. They are changing data that are parts of a distinguished name or 4. They are changing data that are parts of a distinguished name or
they are using ModifyRequest to both read and write a given they are using ModifyRequest to both read and write a given
attribute value in a single atomic request attribute value in a single atomic request.
If any one of these conditions is reversed, the types of problems If any one of these conditions is reversed, the types of problems
described above will not occur. There are many useful applications of described above will not occur. There are many useful applications of
multi-master directories where at least one of the above conditions multi-master directories where at least one of the above conditions
does not occur or where careful design can reverse one of the does not occur or where careful design can reverse one of the
conditions. If, for example, all atomic read/modify requests for a conditions. If, for example, all atomic read/modify requests for a
given object can be directed to the same server, condition 3 will not given object can be directed to the same server, condition 3 will not
occur. For cases where all four conditions do occur, application occur. For cases where all four conditions do occur, application
designers should be aware of the possible consequences. designers should be aware of the possible consequences.
skipping to change at page 11, line 28 skipping to change at page 10, line 53
applications. Designers should consider how clients are notified that applications. Designers should consider how clients are notified that
the server is again available. the server is again available.
When the failed server comes back up, it is brought back into When the failed server comes back up, it is brought back into
synchronization with the other servers and is ready to take requests. synchronization with the other servers and is ready to take requests.
It is always possible that the failed server, if it was acting as a It is always possible that the failed server, if it was acting as a
supplier, was unable to completely distribute its pending changes supplier, was unable to completely distribute its pending changes
before removal from service, leaving its consumers in an inconsistent before removal from service, leaving its consumers in an inconsistent
state. During the period between its removal from service and its state. During the period between its removal from service and its
eventual return, the inconsistency may have been compounded by further eventual return, the inconsistency may have been compounded by further
application activity. As there is no current automatic mechanism to application activity. At the time of publication there is no standard
rectify the problem, the administrator should use whatever mechanism automatic mechanism to rectify the problem, so the administrator must
is available to compare the replicas for consistency as soon after the use whatever mechanism is available to compare the replicas for
event as is reasonable. consistency as soon after the event as is reasonable.
Note that the process used to bring a failed server back into Note that the process used to bring a failed server back into
replication can also be used to add a server to a set of replicating replication can also be used to add a server to a set of replicating
servers. In this case, the new server might be initialized from a servers. In this case, the new server might be initialized from a
backed-up copy of the directory or it may acquire the entire DIB via backed-up copy of the directory or it may acquire the entire DIB via
replication. The former method is usually preferable when the replication. The former method is usually preferable when the
directory is large. directory is large.
5.2 Single Master Issues 5.2 Single Master Issues
In a single-master system, the master is a single point of failure, as In a single-master system, the master is a single point of failure, as
all modification has to originate at the master server. When high all modification has to originate at the master server. When high
availability is a requirement, a quick, automated failover process for availability is a requirement, a quick, automated failover process for
converting a slave replica to a new master is desirable, as the converting a slave replica to a new master is desirable, as the
failover time becomes a major factor in determining system failover time becomes a major factor in determining system
availability. The considerations in section 5.1 apply here; clients availability. The considerations in section 5.1 apply here; clients
must know how to find the new master or a new slave in case of must know how to find the new master or a new slave in case of
failure. failure.
To aid in promotion of a slave replica, the master could replicate To aid in promotion of a slave replica, the master could replicate
control information and meta-data (including replication credentials) control information and meta-data (including replication credentials)
so that this information is available during failover promotion. This so that this information is available during failover promotion. This
data may either be replicated on a single "failover designate" slave data may either be replicated on a single "failover designate" slave
(which would become the master in during failover) or it could be (which would become the master during failover) or it could be
replicated to all slaves. The first possibility has the advantage of replicated to all slaves. The first possibility has the advantage of
minimizing the amount of extra replication while the second more minimizing the amount of extra replication while the second more
robustly handles multiple failovers (i.e. failover of the newly robustly handles multiple failovers (i.e. failover of the newly
promoted master to another slave before the original master has been promoted master to another slave before the original master has been
restored). If this method is followed, data privacy mechanisms should restored). If this method is followed, data privacy mechanisms should
be used to protect the replication session. be used to protect the replication session.
If data privacy mechanisms (e.g. encryption) are used to protect the If data privacy mechanisms (e.g. encryption) are used to protect the
replication session, the new master must have the necessary key replication session, the new master must have the necessary key
information. Further this key information should be independent of information. Further this key information should be independent of
skipping to change at page 13, line 13 skipping to change at page 12, line 26
master if that is how the restored master rejoins the replica group. master if that is how the restored master rejoins the replica group.
5.3 Multi-Master Issues 5.3 Multi-Master Issues
Typically, a multi-master configuration is used when high availability Typically, a multi-master configuration is used when high availability
is required for writes as well as reads in the directory. Because is required for writes as well as reads in the directory. Because
there are multiple active servers prepared to take write requests, there are multiple active servers prepared to take write requests,
there is no "switchover" time in this case. But clients still need to there is no "switchover" time in this case. But clients still need to
be able to find an alternate server, so the considerations of Section be able to find an alternate server, so the considerations of Section
5.1 apply here. 5.1 apply here.
6 Other Issues 6 Other Issues
6.1 Locking 6.1 Locking
Section 4.3.1.1 discussed the problems that can arise when the Section 4.3.1.1 discussed the problems that can arise when the
"modify" command in LDAP is used for locking in a multi-master "modify" command in LDAP is used for locking in a multi-master
environment. There are more general principles at work there. LDAP environment. There are more general principles at work there. LDAP
is a distributed and replicated directory service that is typically is a distributed and replicated directory service that is typically
described as "loosely consistent". described as "loosely consistent".
In loose consistency, the data should eventually converge among the In loose consistency, the data should eventually converge among the
replicas, but at any given instant, replicas may be in disagreement. replicas, but at any given instant, replicas may be in disagreement.
This stipulation is the general result of: This stipulation is the general result of:
1. The delay due to replication or extended replication intervals 1. Delay due to replication intervals
2. The out of natural time order arrival of data at a replica 2. Out of natural time order arrival of data at a replica
3. The temporary isolation of distributed systems from one another 3. Temporary isolation of distributed systems from one another
4. Failure to accept a change due to conflict resolution failure on 4. Failure to accept a change due to conflict resolution failure on
a replica a replica
Because of loose consistency, data preconditions to an LDAP operation Because of loose consistency, data encountered by an LDAP operation
may differ among replicas. Multi-mastering may exacerbate this may differ among replicas. Multi-mastering may exacerbate loose
situation, but single-mastering will not totally eliminate it if out- consistency, but single-mastering will not totally eliminate it if
of-order replication is allowed (see Section 4.2). One must carefully out-of-order replication is allowed (see Section 4.2). One must
assess the effect of loose consistency when evaluating operations that carefully assess the effect of loose consistency when considering the
place specific preconditions on data to work correctly. Applications use of distributed LDAP servers as a data store. Applications which
which depend on such operations may be better suited for transactional depend on synchronous consistency may be better suited for
models and/or non-distributed data. transactional models and/or non-distributed data.
Distributed locking is one operation that depends on strict data
preconditions. When data preconditions cannot be guaranteed, the lock
is moot. The same principles hold for "atomic operations", defined
here as any mix of allowable operations contained within the same LDAP
PDU. RFC2251 requires that they either all fail or are applied as a
unit. If strict data preconditions cannot be guaranteed, then the
atomic operation may itself result in a further inconsistency
requiring human intervention at one of the consumers.
6.2 Backup and Restore 6.2 Backup and Restore
Backup of a directory server should have the following goals: Backup of a directory server should have the following goals:
1. It can be unambiguously and faithfully restored. 1. The directory (or the replica) can be unambiguously and
2. It is an internally consistent snapshot of an entire replica faithfully restored from the backup.
during the time interval it took to make it. This can only be 2. The backup is an internally consistent snapshot of an entire
achieved if the server is quiescent. replica during the time interval it took to make it.
3. Replication can resume on a machine restored from that backup 3. Replication can resume on a machine restored from that backup
without information loss. without information loss.
Backup and restore of a single, operating directory server (rather Backup and restore of a single, operating directory server (rather
than the entire directory system) presents its own challenges. "Loose than the entire directory system) presents its own challenges. "Loose
consistency" works against the probability of achieving a loss-free consistency" works against the probability of achieving a loss-free
copy of all the data in the directory, except under ideal conditions. copy of all the data in the directory, except under ideal conditions.
Backup and restore of distributed directories is a decidedly easier Backup and restore of distributed directories is a decidedly easier
task when the constraint of continuous availability is removed. In task when the constraint of continuous availability is removed. In
most cases, the removal of entire directory systems from write service most cases, the removal of entire directory systems from write service
is impossible, even for small periods of time. It is more practical is impossible, even for small periods of time. It is more practical
to remove a single directory server from service to achieve a to remove a single replica from service to achieve a condition of
condition of quiescence. Once all write load is removed, including quiescence. Once all write load is removed, including write load due
write load due to replication, an internally consistent copy of the to replication, an internally consistent copy of the data may be
data may be obtained. obtained.
Replicas that have suffered catastrophic data loss may be restored Replicas that have suffered catastrophic data loss may be restored
from backups of working servers temporarily removed from service from backups of working ones temporarily removed from service
specifically to make a copy. This scenario illustrates the benefit of specifically to make a copy. This scenario illustrates the benefit of
having three or more replicas in the system: no single point of write having three or more master replicas in the system: no single point of
failure in the event that one of the replicas must be restored from a write failure in the event that one of the replicas must be restored
copy of another. from a copy of another.
The M11 requirement from [RFC3384] allows an empty replica to be The M11 requirement from [RFC3384] allows an empty replica to be
brought up to date through replication. This feature duplicates, but brought up to date through replication. This feature duplicates, but
does not make entirely unnecessary, backup procedures on directory does not make entirely unnecessary, backup procedures on directory
servers. Backups are still needed to recover data that has been lost servers. Backups are still needed to recover data that has been lost
to all replicas, either through normal LDAP updates or through some to all replicas, either through normal LDAP updates or through some
catastrophic event. catastrophic event.
7 Impact of Non-LDAP Changes/Constraints 7 Impact of Non-LDAP Changes/Constraints
skipping to change at page 15, line 41 skipping to change at page 14, line 37
server might interpret a request to replace the current value of the server might interpret a request to replace the current value of the
userPassword attribute with some new value as a request to compute one userPassword attribute with some new value as a request to compute one
or more secure hashes of the new value and store these hashes in one or more secure hashes of the new value and store these hashes in one
or more attributes, storing no value in the userPassword attribute. or more attributes, storing no value in the userPassword attribute.
Using this trigger the directory server avoids the security exposure Using this trigger the directory server avoids the security exposure
of storing the plaintext password. of storing the plaintext password.
Replication between directory servers with different application Replication between directory servers with different application
triggers will compromise directory integrity. triggers will compromise directory integrity.
Similarly, one cannot extend the directory with stored procedures that
execute on access - such as scripts, programs or controls which change
the data - because the expression of such mechanisms may not be
guaranteed to be consistent among heterogeneous servers.
7.3 Policy Conflicts Across Servers 7.3 Policy Conflicts Across Servers
In addition to the discussions of ACI in Section 2.3 and triggering in In addition to the discussions of ACI in Section 2.3 and triggering in
section 7.2, LDUP replication can not (by its definition) handle section 7.2, LDUP replication can not (by its definition) handle
replication of information that makes use of policy not expressible in replication of information that makes use of policy not expressible in
the LDAP protocol. A prime example of this is security encoding of the LDAP protocol. A prime example of this is security encoding of
attributes (e.g. userPassword). This encoding is typically attributes (e.g. userPassword). This encoding is typically
implementation specific and is not easily expressible via the LDAP implementation specific and is not easily expressible via the LDAP
protocol. Therefore replication of userPassword attributes between protocol. Therefore replication of userPassword attributes between
directory servers that use different encoding schemes will impede directory servers that use different encoding schemes will impede
skipping to change at page 16, line 33 skipping to change at page 15, line 29
9 Acknowledgements 9 Acknowledgements
This document owes a lot to discussions on the LDUP mailing list. In This document owes a lot to discussions on the LDUP mailing list. In
particular, the authors would like to thank Ed Reed, whose email to particular, the authors would like to thank Ed Reed, whose email to
the mailing list drove much of section 6.1, and Mark Brown for the mailing list drove much of section 6.1, and Mark Brown for
identifying and generating text on the issues discussed in section 7. identifying and generating text on the issues discussed in section 7.
10 References 10 References
[CIMNames] Desktop Management Task Force, "Guidelines for CIM-to-LDAP
Directory Mappings", DMTF Specification DSP0100, May 2000 (available
online at http://www.dmtf.org/spec/DEN/DSP0100.htm).
[FindingLDAP] R. Moats, R. Hedberg, "A Taxonomy of Methods for LDAP [FindingLDAP] R. Moats, R. Hedberg, "A Taxonomy of Methods for LDAP
Clients Finding Servers", Internet Draft, draft-ietf-ldapext-ldap- Clients Finding Servers", Internet Draft, draft-ietf-ldapext-ldap-
taxonomy-05.txt, July 2001. taxonomy-05.txt, July 2001.
[InfoMod] R. Moats, R. Huber, J. McMeeking, "LDUP Replication [InfoMod] R. Moats, R. Huber, J. McMeeking, "LDUP Replication
Information Model", Internet Draft, draft-ietf-ldup-infomod-07.txt, Information Model", Internet Draft, draft-ietf-ldup-infomod-07.txt,
June 2003. June 2003.
[LDAPinDNS] M. Armijo, L. Esibov, P. Leach, R. L. Morgan, [LDAPinDNS] M. Armijo, L. Esibov, P. Leach, R. L. Morgan,
"Discovering LDAP Services with DNS", Internet Draft, draft-ietf- "Discovering LDAP Services with DNS", Internet Draft, draft-ietf-
ldapext-locate-05.txt, March 2001. ldapext-locate-05.txt, March 2001.
[RFC3384] E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3
Replication Requirements", RFC 3384, October 2002.
[RFC1255] The North American Directory Forum, "A Naming Scheme for [RFC1255] The North American Directory Forum, "A Naming Scheme for
c=US", RFC 1255, September 1991. c=US", RFC 1255, September 1991.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol", RFC 2251, December 1997. Protocol", RFC 2251, December 1997.
[RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behara, ôAccess Control
Requirements for LDAPö, RFC2820. May 2000.
[RFC2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, "Naming Plan [RFC2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, "Naming Plan
for Internet Directory-Enabled Applications", RFC 2377, September for Internet Directory-Enabled Applications", RFC 2377, September
1998. 1998.
[RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behara, ôAccess Control
Requirements for LDAPö, RFC2820. May 2000.
[RFC3384] E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3
Replication Requirements", RFC 3384, October 2002.
Authors' Addresses Authors' Addresses
Richard V. Huber Richard V. Huber
Room C3-3B30 Room C3-3B30
AT&T Laboratories AT&T Laboratories
200 Laurel Avenue South 200 Laurel Avenue South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
E-Mail: rvh@att.com E-Mail: rvh@att.com
Telephone: +1 732 420 2632 Telephone: +1 732 420 2632
 End of changes. 52 change blocks. 
158 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/