Setting up Replication in IBM Directory Server 5.1

This article provides step by step instructions on how to set up replication for IBM Directory Server 5.1. After setup, server replication improves the availability of the directory service. The combination of a master and multiple replicated servers ensures that directory data is always available when needed. If any server fails, the directory server continues to be available from another replicated server.

Nagesh Mogi, Software Engineer, IBM

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.



03 September 2004

Introduction

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.


Pre-requisites

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.


Basic Definitions

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.


Benefits of Replication

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 Requirements

  • 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.

Replication topology

To define a replication topology, you must

  1. 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.
  2. Create credentials to be used by the supplier.
  3. Create a replica server.
  4. 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.

  1. Start the Directory Server .
  2. Open a browser, and type http://localhost:9080/IDSWebApp/IDSjsp/Login.jsp
  3. At the IBM Directory Server Web Administration login page select the LDAP host name
    for your machine from the drop-down menu.
  4. 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
  5. Expand the Replication management
    category in the navigation area and click Manage topology.
  6. Click
    Add subtree
Figure 1. Adding a replica subtree
Figure 1. Adding a replica subtree
  1. 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.
  2. Enter the master server referral URL. This must be in the form of an LDAP URL, for example: ldap://tivoli9:389

Figure 2. Replica subtree
Figure 2. Replica subtree

  1. Click OK.

The new server is displayed on the Manage topology panel under the heading Replicated subtrees.

Figure 3. Replicated subtree
Figure 3. Replicated subtree

Step 2: Creating credentials

Expand the Replication management category in the navigation area of the Web Administration Tool and click

Manage credentials

Figure 4. Manage Credentials
Figure 4. Manage Credentials
  1. 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
  2. Click Add
  3. Enter the name for the credentials you are creating. In this example, I am using mycreds.
Figure 5. Add Credential
Figure 5. Add Credential
  1. Select the type of authentication method you want to use and click Next.
  2. 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
Figure 6. Provide Bind DN and Password values

  1. 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.

Step 3: Creating a replica

  1. Start Directory server (if it is stopped)
  2. Expand the Replication management category in the navigation area and click Manage topology.
  3. Select the subtree that you want to replicate and click Show topology.
Figure 7. Select subtree
Figure 7. Select subtree
  1. Click the arrow next to the Replication topology selection to expand the list of supplier servers.
  2. 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
Figure 8. Server information

On the Additional tab:

  1. 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
Figure 9. Supplier and Replica Server information
  1. Specify a replication schedule from the drop-down list or click Add to create one
Figure 10. Show credential object
Figure 10. Show credential object
  1. From the list of supplier capabilities, de-select any capabilities that do not need replication.
  2. Click OK to create the replica.
Figure 11. Replication topology
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
Figure 12. Copying data to the replica

On the machine (Server 2) where you are creating the replica:

  1. Ensure that the suffixes used by the master are defined in the ibmslapd.conf file.
  2. Stop the replica server.
  3. 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.
  4. 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):

  1. Click Manage replication properties in the navigation area.
  2. Click Add.
Figure 13. Manage replication properties
Figure 13. Manage replication properties

Figure 13. Manage replication properties

  1. 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.
  2. Enter the replication bindDN. In this example, cn=John
Figure 14. Replication bind DN
Figure 14. Replication bind DN
  1. Depending on the type of credential, enter and confirm the credential password. (You previously recorded this for future use.)
  2. Click OK.
  3. 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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Tivoli (service management) on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Tivoli (service management), Tivoli, Security
ArticleID=23505
ArticleTitle=Setting up Replication in IBM Directory Server 5.1
publish-date=09032004