Exit Print View

Sun OpenDS Standard Edition 2.2 Architectural Reference

Get PDF Book Print View
 

Document Information

1.  Introduction

2.  The Directory Server Access Control Model

3.  Understanding the Directory Server Schema

4.  Directory Server Index Databases

5.  Understanding Directory Server Plug-Ins

6.  Directory Server Replication

Overview of the Directory Server Replication Architecture

Basic Replication Architecture

Replication Servers

Replication Change Numbers

Replication Server State

Operation Dependencies

How Replication Works

Directory Server Change Processing

Change Replay

Auto Repair

Directory Server Crashes

Replication Server Crashes

Historical Information and Conflict Resolution

What is a Replication Conflict?

Resolving Modify Conflicts

Resolving Naming Conflicts

Purging Historical Information

Schema Replication

Schema Replication Architecture

Replication Status

Replication Status Definitions

Degraded Status

Full Update Status and Bad Generation ID Status

Replication Groups

Replication Server Selection

Assured Replication

Assured Replication Modes

Safe Data Mode

Safe Read Mode

Safe Read Mode and Replication Groups

Assured Replication Connection Algorithm

Assured Replication and Replication Status

Assured Replication Monitoring

Fractional Replication

Fractional Data Set Identification

Fractional Replication Filtering

Fractional Replication and Local Operations

External Change Log

How the External Change Log Works

Porting Applications that Rely on Other Change Logs

Differences Between the ECL and the LDAP Change Log Draft

Index Differences

DIT and Schema Differences

Additional Differences Between the ECL and the Sun DSEE Retro Change Log

API for Compatibility With the LDAP Change Log Draft and the Sun DSEE Retro Change Log

Limitations of the Compability API

7.  Directory Server Root Users and the Privilege Subsystem

8.  Supported Controls and Operations

Safe Read Mode and Replication Groups

Replication groups support multi-data center replication and high availability. For more information about replication groups, see Replication Groups. In the context of assured replication, replication groups enable a set of directory servers to work together in safe read mode. All directory servers that work together in a synchronized manner require the same group ID. This group ID should also be assigned to all the replication servers working in the synchronized topology. Assured replication does not cross group boundaries.

When a change occurs on a directory server with certain group ID (N), the LDAP call is not returned before every other directory server with group ID N has returned an acknowledgment of the change.

The use of replication groups provides more flexibility in a replicated topology that uses safe read mode.

Example 6-4
Safe Read Mode in a Single Data Center With One Group

The following illustration shows a deployment in which all nodes are in the same data center and are part of the same replication group. Each directory server and replication server has the same group ID. Any modification must be replayed on every directory server in the topology before an LDAP client call returns. Any subsequent LDAP read operation on any directory server in the topology is assured of reading the modification.

Such a scenario might be convenient, for example, if there is an LDAP load balancer in front of the replicated directory server pool. Because it is impossible to determine the directory server to which the load balancer will redirect an LDAP modification, a subsequent read operation is not necessarily routed to the directory server on which the modification was made. In this case, it is imperative that the change is made on all servers in the topology before the LDAP client call is returned.

Figure shows a single data center with all directory servers in safe read mode.
Example 6-5
Safe Read Mode in a Single Data Center With More Than One Group

The following illustration shows a deployment in which all nodes are in the same data center but in which assured replication is configured on only a subset of the directory servers. This subset of servers constitutes a replication group, and each server is assigned the same group ID (1). When a change is made on one of the directory servers in the replication group, an acknowledgment must be received from all the directory servers in the group before the initial LDAP call is returned to the client. The remaining directory servers in the topology will still replay the change, but their acknowledgment is not required before the LDAP call is returned. If a change made on one of the servers outside of the group, no acknowledgment from other directory servers is required before the LDAP call is returned to the client.

In this example, the replication server that is connected to directory servers outside of the replication group is still assigned a group ID of 1. This configuration ensures failover in the case of another replication server being offline. In this case, if a directory server within the replication group connects to this particular replication server, assured replication must still work. For the purpose of failover, any replication server must be assigned the same group ID if there is a chance that a directory server within the group might connect to it at some stage.

Figure shows a single data center with a subset of directory servers in safe read mode.
Example 6-6
Safe Read Mode in a Multi-Data Center Deployment

The following illustration shows a deployment with two data centers (in different geographical locations). Each data center has safe read mode configured locally within the data center. All of the directory servers and the replication servers within the same data center are assigned the same group ID (1 for the first data center and 2 for the second data center). The directory servers within the same data center operate in a more tightly consistent synchronized manner. Any change made on a directory server must be replayed and acknowledged from all directory servers within that data center before the LDAP client call returns.

In this example, data is synchronized between the two data centers, but any change made on a specific directory server is immediately visible on all other directory servers within the same data center. This scenario is convenient if there is an LDAP load balancer in front of the directory servers of a data center. The performance impact in terms of writes is not too great because no acknowledgments are requested from the servers of the remote data center.

Figure shows safe read mode configured across two data centers

The group ID of the replication server is important in this scenario. If a change arrives from a directory server with group ID N, the replication server compares N with its own group ID and takes the following action: