Directory Server (LDAP) - Replication overview

Replication overview

Replication provides two main benefits:

Redundancy of information - replicas back up the content of their supplier servers.
Faster searches - search requests can be spread among several different servers, all having the same content, instead of a single server. This improves the response time for the request completion.

Specific entries in the directory are identified as the roots of replicated subtrees, by adding the ibm-replicationContext objectclass to them. Each subtree is replicated independently. The subtree continues down through the directory information tree (DIT) until reaching the leaf entries or other replicated subtrees. Entries are added below the root of the replicated subtree to contain the replication topology information. These entries are one or more replica group entries, under which are created replica subentries. Associated with each replica subentry are replication agreements that identify the servers that are supplied (replicated to) by each server, as well as defining the credentials and schedule information.

Through replication, a change made to one directory is propagated to one or more additional directories. In effect, a change to one directory shows up on multiple different directories. The IBM Directory supports an expanded master-subordinate replication model. Replication topologies are expanded to include:

Replication of subtrees of the Directory Information Tree (DIT) to specific servers
A multi-tier topology referred to as cascading replication
Assignment of server role (master or replica) by subtree.
Multiple master servers, referred to as peer to peer replication.
Gateway replication across networks.

The advantage of replicating by subtrees is that a replica does not need to replicate the entire directory. It can be a replica of a part, or subtree, of the directory.

The expanded model changes the concept of master and replica. These terms no longer apply to servers, but rather to the roles that a server has regarding a particular replicated subtree. A server can act as a master for some subtrees and as a replica for others. The term, master, is used for a server that accepts client updates for a replicated subtree. The term, replica, is used for a server that only accepts updates from other servers designated as a supplier for the replicated subtree.

The types of servers as defined by function are master/peer, cascading, gateway, and replica.

Table 1. Server roles
Directory	Description
Master/peer	The master/peer server contains the master directory information from where updates are propagated to the replicas. All changes are made and occur on the master server, and the master is responsible for propagating these changes to the replicas. There can be several servers acting as masters for directory information, with each master responsible for updating other master servers and replica servers. This is referred to as peer replication. Peer replication can improve performance and reliability. Performance is improved by providing a local server to handle updates in a widely distributed network. Reliability is improved by providing a backup master server ready to take over immediately if the primary master fails. Notes: Master servers replicate all client updates, but do not replicate updates received from other masters. Updates to the same entry made by multiple servers might cause inconsistencies in directory data because there is no conflict resolution.
Cascading (forwarding)	A cascading server is a replica server that replicates all changes sent to it. This contrasts to a master/peer server in that a master/peer server only replicates changes that are made by clients connected to that server. A cascading server can relieve the replication workload from the master servers in a network that contains many widely dispersed replicas.
Gateway	Gateway replication uses gateway servers to collect and distribute replication information effectively across a replicating network. The primary benefit of gateway replication is the reduction of network traffic.
Replica (read-only)	A replica is an additional server that contains a copy of directory information. The replicas are copies of the master (or the subtree that it is a replica of). The replica provides a backup of the replicated subtree.

If the replication fails, it is repeated even if the master is restarted. The Manage Queues window in the Web administration tool can be used to check for failing replication.

You can request updates on a replica server, but the update is actually forwarded to the master server by returning a referral to the client. If the update is successful, the master server then sends the update to the replicas. Until the master has completed replication of the update, the change is not reflected on the replica server where it was originally requested. Changes are replicated in the order in which they are made on the master.

If you are no longer using a replica, you must remove the replication agreement from the supplier. Leaving the definition causes the server to queue up all updates and use unnecessary directory space. Also, the supplier continues trying to contact the missing consumer to retry sending the data.

Start of change Gateway replication End of change

Start of change Gateway replication uses gateway servers to collect and distribute replication information effectively across a replicating network. The primary benefit of gateway replication is the reduction of network traffic. Gateway servers must be masters (writable). End of change

Start of change The following figure illustrates how gateway replication works:

Figure 2. A replicating network with gateway servers

The graphic shows three gateway servers that interconnect with each other. Each gateway server in turn interconnects with the peer and replica servers within its own replication site.

The replicating network in the preceding figure contains three replication sites, each containing a gateway server. The gateway server collects replication updates from the peer/master servers in the replication site where it resides and sends the updates to all the other gateway servers within the replicating network. It also collects replication updates from other gateway servers in the replication network and sends those updates to the peers/masters and replicas in the replication site where it resides. End of change

Start of change Gateway servers use server IDs and consumer IDs to determine which updates are sent to other gateway servers in the replicating network and which updates are sent to local servers within the replication site. End of change

Start of change To set up gateway replication, you must create at least two gateway servers. The creation of a gateway server establishes a replication site. You must then create replication agreements between the gateway and any masters/peers and replicas you want to include in that gateway's replication site. End of change

Start of change Gateway servers must be masters (writable). If you attempt to add the gateway object class, ibm-replicaGateway, to a subentry that is not a master, an error message is returned. End of change

Start of change There are two methods for creating a gateway server. You can:

Create a new gateway server
Convert an existing peer server to a gateway server

Note:

It is very important that you assign only one gateway server per replication site.