ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzahy_5.4.0.1/rzahyp2p.htm

88 lines
5.5 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) - Create a complex topology with peer replication</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="rzahyp2p"></a>
<h3 id="rzahyp2p">Create a complex topology with peer replication</h3>
<p>Peer replication is a replication topology in which multiple servers are
masters. However, unlike a multi-master environment, no conflict resolution
is done among peer servers. LDAP servers accept the updates provided by
peer servers, and update their own copies of the data. No consideration is
given for the order the updates are received, or whether multiple updates
conflict.</p>
<p>To add additional masters (peers), you first add the server as a read-only
replica of the existing masters (see <a href="rzahycreaterep.htm#rzahycreaterep">Create a replica server</a>), initialize
the directory data, and then promote the server to be a master (see <a href="rzahypromote.htm#rzahypromote">Move or promote a server</a>).</p>
<p>Initially, the <span class="bold">ibm-replicagroup</span> object
created by this process inherits the ACL of the root entry for the replicated
subtree. These ACLs might be inappropriate for controlling access to the
replication information in the directory.</p>
<p>For the Add subtree operation to be successful, the entry DN which you
are adding must have correct ACLs, if it is not a suffix in the server.</p>
<dl>
<dt class="bold">For Non-filtered ACLs :</dt>
<dd>
<ul>
<li>ownersource : &lt;<span class="italic">the entry DN</span>></li>
<li>ownerpropagate : TRUE</li>
<li>aclsource : &lt;<span class="italic">the entry DN</span>></li>
<li>aclpropagate: TRUE</li></ul>
</dd>
<dt class="bold">Filtered ACLs :</dt>
<dd>
<ul>
<li>ownersource : &lt;<span class="italic">the entry DN</span>></li>
<li>ownerpropagate : TRUE</li>
<li>ibm-filteraclinherit : FALSE</li>
<li>ibm-filteraclentry : &lt;<span class="italic">any value</span>></li></ul>
</dd>
</dl>
<p>Use the <span class="bold">Edit ACLs</span> function of the Web administration
tool to set ACLs for the replication information associated with the newly
created replicated subtree (see <a href="rzahyrepacl.htm#rzahyrepacl">Edit access control lists</a>).</p>
<p>The replica is in a suspended state and no replication is occurring. After
you have finished setting up your replication topology, you must click <span class="bold">Manage queues</span>, select the replica and click <span class="bold">Suspend/resume</span> to start replication. See <a href="rzahyqueues.htm#rzahyqueues">Manage queues</a> for more detailed information. The replica now receives
updates from the master.</p>
<p>Use peer replication only in environments where the pattern of directory
updates is well known. Updates to particular objects within the directory
must be done only by one peer server. This is intended to prevent the scenario
of one server deleting an object, followed by another server modifying the
object. This scenario creates the possibility of a peer server receiving
a delete command followed by a modify command; which creates a conflict.</p>
<p>To define a peer-forwarder-replica topology, consisting of two peer-master
servers, two forwarding servers, and four replicas you must: </p>
<ol type="1">
<li>Created a master server and a replica server. See <a href="rzahymasterrep.htm#rzahymasterrep">Create a master-replica topology</a>.</li>
<li>Create two additional replica servers for the master server. See <a href="rzahycreaterep.htm#rzahycreaterep">Create a replica server</a>.</li>
<li>Create two replicas under each of the two newly created replica servers.</li>
<li>Promote the original replica to a master. See <a href="rzahypromoteserver.htm#rzahypromoteserver">Promote a server to be a peer</a>.
<a name="wq248"></a>
<div class="notetitle" id="wq248">Note:</div>
<div class="notebody">The server that you want to promote to a master must be a leaf replica
with no subordinate replicas.</div></li>
<li>Copy the data from the master to the new master and replicas. See <a href="rzahyexportdata.htm#rzahyexportdata">Copy data to the replica</a>.</li></ol>
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
</body>
</html>