A directory is a collection of information about objects arranged in a hierarchical structure. It is a specialized database, that enables users or applications to find resources that have the characteristics needed for a particular task. The IBM Directory implements the Internet Engineering Task Force (IETF) LDAP V3 specifications. It also includes enhancements added by IBM in functional and performance areas. IBM Directory Server 5.1 uses the IBM DB2 as the backing store to provide per LDAP operation transaction integrity, high performance operations, and on-line backup and restore capability.
Before you begin using this tutorial, you will have to install IDS 5.1 on 2 different machines. One machine acts a Master Server and other as Replica Server. This tutorial assumes you have IDS 5.1 installed on two different machines. Before you begin working with this article, you need to have a suffix called o=ibm, c=us.
Subtree : This is a branch of the Directory Information Tree (DIT). For example o=ibm,c=us.
Replicated subtree: A replicated subtree is a portion of the DIT that is replicated from one server to another.
Replication agreement: A replication agreement is information contained in the directory that defines the "connection" or "replication path" between two servers. One server is called the supplier (the one that sends the changes) and the other is the consumer (the one that receives the changes).
Consumer server: Server, which receives changes through replication from another (supplier) server.
Supplier server: Server, which sends changes to another (consumer) server.
Replication : Replication is a technique used by directory servers to improve performance and reliability. The replication process keeps the data in multiple directories synchronized.
The rational for replica is to offload the lookup requests from the master LDAP for performance. Master LDAP server is the only LDAP server that can make updates .Another and most important reason to use a replica is to allow the capability of bringing down an LDAP server in order to perform a backup of the database. Without the replica authentication would stop while the backup is in progress.
Server replication improves the availability of a directory service. The combination of a master and multiple replicated servers ensure that directory data is always available when needed. If any server fails, the directory server continues to be available from another replicated server.
Replication involves two types of directories: master and replica. LDAP refers to the master as master server and to the replica as replica server. For a particular directory structure, there can only be one master server. All updates are made on the server, and these updates are subsequently propagated to the replica server. Each replica server contains an exact copy of the master server's directory data.
Changes to the directory can be made only to the master server, which is always used for write operations to the directory. Either the master or the replicas can be used for read operations. When the original master server is out of service for an extended period of time, a replica server can be promoted to master server to allow write operations to the directory.
- Replica LDAP servers handle the same directory context as the LDAP master server.
- Because LDAP replica servers have the same directory context, they must have the same suffix as the master server.
- Schema definitions must also be the same on each replica and master server.
To define a replication topology, you must
- Create replicated subtree on a master server and define what it contains. Select the subtree (in our example , it is o=ibm, c=us) that you want to be replicated and specify the server as the master.
- Create credentials to be used by the supplier.
- Create a replica server.
- Export data to the replica.
Step 1: Creating a replicated subtree on a master server
To create a replicated subtree, you must designate the subtree that you want the server to replicate.
- Start the Directory Server .
- Open a browser, and type http://localhost:9080/IDSWebApp/IDSjsp/Login.jsp
- At the IBM Directory Server Web Administration login page select the
LDAP host name
for your machine from the drop-down menu. - Enter the
bind DN
and the password
for that server (for this tutorial, I have used cn=root and password = Tivoli). Click Login.
Once you login to the IDS Web Administration Tool - Expand the
Replication management
category in the navigation area and click Manage topology. - Click
Add subtree
Figure 1. Adding a replica subtree
- Enter the DN of the subtree i.e. o=ibm,c=us that you want to replicate or click Browse to expand the entries to select the entry that is to be the root of the subtree.
- Enter the master server referral URL. This must be in the form of an LDAP URL, for example: ldap://tivoli9:389
- Click OK.
The new server is displayed on the Manage topology panel under the heading Replicated subtrees.
Figure 3. Replicated subtree
Expand the Replication management category in the navigation area of the Web Administration Tool and click
Manage credentials
Figure 4. Manage Credentials
- Select the location that you want to use to store the credentials from the list of subtrees. The Web Administration Tool allows you to define credentials in two places:
a) cn=replication,cn=localhost, which keeps the credentials only on the current server.
b) Within the replicated subtree
Credentials placed in the replicated subtree are created beneath the ibm-replicagroup=default entry for that subtree.
Note: Here I am using cn=replication, cn=localhost - Click Add
- Enter the name for the credentials you are creating. In this example, I am using mycreds.
Figure 5. Add Credential
- Select the type of authentication method you want to use and click Next.
- Here I have selected
Simple bind
authentication:
a. Enter the DN that the server uses to bind to the replica, for example, cn=John
b. Enter the password uses when it binds to the replica, for example, secret.
c. Enter the password again to confirm that there are no typographical errors.
d. If you want, enter a brief description of the credentials.
e. Click Finish
Figure 6. Provide Bind DN and Password values
- Note: You might want to note the credential's bind DN and password for future reference. You will need this password when you create the replica agreement.
- Start Directory server (if it is stopped)
- Expand the Replication management category in the navigation area and click Manage topology.
- Select the subtree that you want to replicate and click Show topology.
Figure 7. Select subtree
- Click the arrow next to the Replication topology selection to expand the list of supplier servers.
- Select the supplier server and click Add replica.
On the Server tab of the Add replica window:
Enter the host name and port number for the replica you are creating. The default port is 389 for non-SSL and 636 for SSL. These are required fields.
Select whether to enable SSL communications.
Enter the replica name or leave this field blank to use the host name.
Enter the replica ID. If the server on which you are creating the replica is running,
click Get replica ID to automatically fill this field.
Enter a description of the replica server.
Figure 8. Server information
On the Additional tab:
- Specify the credentials that the replica uses to communicate with the master.
a. Click Select.
b. Select the location for the credentials you want to use. Preferably this is cn=replication, cn=localhost.
c. Click Show credentials.
d. Expand the list of credentials and select the one you want to use.
e. Click OK.
Figure 9. Supplier and Replica Server information
- Specify a replication schedule from the drop-down list or click Add to create one
Figure 10. Show credential object
- From the list of supplier capabilities, de-select any capabilities that do not need replication.
- Click OK to create the replica.
Figure 11. Replication topology
Step 4: Copying data to the replica
After creating the replica, you must now export the topology from the master to the replica.
This is a manual procedure. On the master server create an LDIF file for the data. To copy all the data
contained on the master server, issue the command: db2ldif -o <masterfile.ldif>
If you want to copy just the data from a single subtree the command is:
db2ldif -o <masterfile.ldif>-s<subtreeDN>
Figure 12. Copying data to the replica
On the machine (Server 2) where you are creating the replica:
- Ensure that the suffixes used by the master are defined in the ibmslapd.conf file.
- Stop the replica server.
- Copy the <masterfile.ldif> to the replica server (Server2) and issue the command:
ldif2db -r no -i <masterfile.ldif>
The replication agreements, schedules, credentials (if stored in the replicated subtree) and entry data are loaded on the replica.
- Start the server.
On Replica Server (Server 2) machine
Adding the supplier information to the replica
On the machine where you are creating the replica(i.e.Server2):
- Click Manage replication properties in the navigation area.
- Click Add.
Figure 13. Manage replication properties
Figure 13. Manage replication properties
- Select a supplier from the Replicated subtree drop-down menu or enter the name of the replicated
subtree for which you want to configure supplier credentials. If you are editing supplier credentials, this field is not editable.
- Enter the replication bindDN. In this example, cn=John
Figure 14. Replication bind DN
- Depending on the type of credential, enter and confirm the credential password. (You previously recorded this for future use.)
- Click OK.
- You must restart the replica for the changes to take effect.
On the Master Server(Server1)
The replica is in a suspended state and no replication is occurring. After you have finished setting up your replication topology, you must click Manage queues,
select the replica and click suspend/resume to start replication. The replica now receives updates from the master.
Conclusion
This tutorial explained how to setup replication between two LDAP servers on Windows 2000.
- LDAP Implementation Cookbook
- IBM Directory Server Version 5.1 Administration Guide Directory Server 5.1 Administration Guide.
Nagesh Mogi is a software engineer at the Developer Relations Technical Support Center in Dallas, Texas, which is part of IBM's Developer Relations Technical Support structure. He has provided technical support for various products including VisualAge for Java, WebSphere Application Server, WSAD and WebSphere Business Components. He currently provides technical and development assistance to IBM Business Partners on IBM Directory Server and Tivoli Security products.




