173 lines
11 KiB
HTML
173 lines
11 KiB
HTML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<meta name="dc.date" scheme="iso8601" content="2005-09-06" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow"/>
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<title>Directory Server (LDAP) - Replication overview</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
||
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
|
||
|
|
|
||
|
|
<a name="rzahyrepoverview"></a>
|
||
|
|
<h3 id="rzahyrepoverview">Replication overview</h3>
|
||
|
|
<p>Replication provides two main benefits:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Redundancy of information - replicas back up the content of their supplier
|
||
|
|
servers.</li>
|
||
|
|
<li>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.</li></ul>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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: </p>
|
||
|
|
<ul>
|
||
|
|
<li>Replication of subtrees of the Directory Information Tree (DIT) to specific
|
||
|
|
servers</li>
|
||
|
|
<li>A multi-tier topology referred to as cascading replication</li>
|
||
|
|
<li>Assignment of server role (master or replica) by subtree.</li>
|
||
|
|
<li>Multiple master servers, referred to as peer to peer replication.</li>
|
||
|
|
<li><img src="delta.gif" alt="Start of change" />Gateway replication across networks.<img src="deltaend.gif" alt="End of change" /></li></ul><p class="indatacontent">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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>The types of servers as defined by function are <span class="italic">master/peer</span>, <span class="italic">cascading</span>, <span class="italic">gateway</span>, and <span class="italic">replica</span>. </p><img src="delta.gif" alt="Start of change" />
|
||
|
|
<a name="wq32"></a>
|
||
|
|
<table id="wq32" width="100%" summary="" border="1" frame="border" rules="all" class="singleborder">
|
||
|
|
<caption>Table 1. Server roles</caption>
|
||
|
|
<thead valign="bottom">
|
||
|
|
<tr class="tablemainheaderbar">
|
||
|
|
<th id="wq33" width="18%" align="center" valign="top">Directory</th>
|
||
|
|
<th id="wq34" width="81%" align="center" valign="top">Description</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody valign="top">
|
||
|
|
<tr>
|
||
|
|
<td headers="wq33">Master/peer</td>
|
||
|
|
<td headers="wq34">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.
|
||
|
|
<p>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.</p>
|
||
|
|
<a name="wq35"></a>
|
||
|
|
<div class="notelisttitle" id="wq35">Notes:</div>
|
||
|
|
<ol type="1">
|
||
|
|
<li>Master servers replicate all client updates, but do not replicate updates
|
||
|
|
received from other masters.</li>
|
||
|
|
<li>Updates to the same entry made by multiple servers might cause inconsistencies
|
||
|
|
in directory data because there is no conflict resolution.</li>
|
||
|
|
</ol></td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td headers="wq33">Cascading (forwarding)</td>
|
||
|
|
<td headers="wq34">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.</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td headers="wq33">Gateway</td>
|
||
|
|
<td headers="wq34">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.</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td headers="wq33">Replica (read-only)</td>
|
||
|
|
<td headers="wq34">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.</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table><img src="deltaend.gif" alt="End of change" />
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p><img src="delta.gif" alt="Start of change" /><span class="bold">Gateway replication</span><img src="deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="delta.gif" alt="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).<img src="deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="delta.gif" alt="Start of change" /> The following figure illustrates how gateway replication works:</p>
|
||
|
|
<a name="wq37"></a>
|
||
|
|
<div class="fignone" id="wq37"><span class="figcap">Figure 2. A replicating network with gateway servers</span>
|
||
|
|
<div class="mmobj">
|
||
|
|
<img src="rzahy503.gif" alt="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." /></div></div><p class="indatacontent">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.<img src="deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="delta.gif" alt="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.<img src="deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="delta.gif" alt="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.<img src="deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="delta.gif" alt="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.<img src="deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="delta.gif" alt="Start of change" />There are two methods for creating a gateway server. You can:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Create a new gateway server</li>
|
||
|
|
<li>Convert an existing peer server to a gateway server</li></ul><p class="indatacontent"> </p>
|
||
|
|
<a name="wq38"></a>
|
||
|
|
<div class="notetitle" id="wq38">Note:</div>
|
||
|
|
<div class="notebody">It is very important that you assign only one gateway
|
||
|
|
server per replication site.</div><img src="deltaend.gif" alt="End of change" />
|
||
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
|
</body>
|
||
|
|
</html>
|