Back up Rational software user data for quick disaster recovery

How to configure peer-to-peer replication with Rational Directory Server (Tivoli Variant)

Currently, there is no supported way to plan for disaster recovery for IBM® Rational® software that uses Rational Directory Server. Therefore, administrators of Rational® DOORS®, Rational Change, Rational Synergy, and other Rational products that rely on the directory server always fear losing user data, such as rights, roles, preference settings, and so forth. Pranab Agarwal explains how to use peer-to-peer replication to back up that user data. This method also ensures that turnaround time to recover from a failure is very short, which helps in disaster recovery planning.

Pranab Agarwal (pranab.agarwal@in.ibm.com), Advisory Software Engineer, IBM

author photoPranab Agarwal is a senior technical staff member with the Rational Directory Server team and has been working on this product for nearly three years. He has additional wide experience in various technologies, for more than 13 years in the field.



12 March 2013

Introduction

Organizations, today, need to have some disaster recovery mechanism present for their network infrastructure. This is true for their networked resources, as well. Organizations that use IBM® Rational® DOORS®, Rational® Focal Point™, Rational Change, and Rational Synergy use the included Rational Directory Server for authentication purposes and for storing certain user-specific information required by these products.

Loosing this user-specific information could create a security problem within the organization. Therefore, they are required to back up this data in some form for retrieval in case there is some kind of disaster.

Given that the nature of business today is fast-changing, information changes rapidly. For this reason peer-to-peer replication of the Rational Directory Server is considered the best approach to disaster recovery planning for these Rational products.

There are two Rational Directory Server variants:

  • Rational Directory Server Tivoli variant
  • Rational Directory Server Apache variant

This article is about the Tivoli variant.


Replication topology

For configuring Rational Directory Server for disaster recovery, the IBM® Tivoli® Directory Server peer-to-peer replication technology is used so that two Rational Directory Servers remain in sync at all times. Although topologies other than peer-to-peer (P2P) are available, P2P is the best-suited, as explained previously.

Using this topology ensures that two Rational Directory Servers remain identical at all times. Therefore, if either fails at any time, the second is available for immediate use. The turnaround time to activate the backup server is very short.

Figure 1. Rational Directory Server in a peer-to-peer topology
applications connected to peer connected servers

Topology requirements

  • Server-class machines for setting up Rational Directory Server (Tivoli variant) – two numbers
  • IBM Tivoli Directory Server Version 6.3 or later
  • IBM Rational Directory Server Version 5.2.0.2 or later
  • IBM® DB2® Version 9.7 or later

For more details about the infrastructure requirements, see Release Notes - Rational Directory Server 5.2.0.2 (Tivoli).

Information to have ready

You need the following information before you can start the Rational Directory Server peer-to-peer replication setup:

For P2P setup, have the IP address and a fully qualified name handy to avoid any confusion. Use a text editor or similar method to save this information (substitute your specific information for anything in <angle brackets>):

Peer1: <IP Address>: <Fully qualified domain name of the machine>
Peer2: <IP Address>: <Fully qualified domain name of the machine>

Installation and configuration

Note:
As a general rule, Peer1 server is the main production server, and Peer2 is the backup server.

Installation steps

  1. Install the Tivoli Directory Server along with DB2 on both servers.
  2. Then install Rational Directory Server on both servers.

Note:
See Resources for a link to the Rational Directory Server Information Center for detailed installation steps.

Configuration steps

Note:
Restrict the use of Rational Directory Server until the configuration setup is finished.

  1. Go to Peer1.
    • For a UNIX system, open the /etc/hosts file, and enter the IP addresses of the two Rational Directory Server and their fully qualified names.
    • For a Windows system, update c:\Windows\system32\drivers\etc\hosts

      Example:
      xxx.xxx.xxx.xxx Peer1 xyz.in.ibm.com
      yyy.yyy.yyy.yyy Peer2 abc.in.ibm.com

      where
      • xxx.xxx.xxx.xxx and yyy.yyy.yyy.yyy are the IP addresses of the two Rational Directory Server servers
      • xyz.in.ibm.com and abc.in.ibm.com are the fully qualified names of the two servers, respectively
  2. Next:
    • For UNIX systems, go to <RDS_Install_Location>/Instance/idsslapd-tdsadmin/etc, and back up the ibmslapd.conf file.
    • On Windows systems, go to C:\idsslapd-tdsadmin\etc, and back up the ibmslapd.conf file
  3. Open the ibmslapd.conf file for editing and do the following:
    1. Search for the ibm-slepdServerId attribute. Delete the entry after that, and enter Peer1 for Peer1 server and Peer2 for Peer2 server, respectively.
    2. Go to the end of the file and paste in the following text:
      Ibmslapd.conf file entry dn: cn=Master server, cn=configuration cn: master server ibm-slapdMasterDN: cn=bindtoconsumer ibm-slapdMasterPW: iamsupplier ibm-slapdMasterReferral: ldap://<<Peer2 fully qualified domain name>:1389 objectclass: ibm-slapdReplication
    3. Repeat steps a and b for the Peer2 server, but use this text, instead:
      ibm-slapdMasterReferral: ldap://<<Peer1 fully qualified domain name>:1389
    4. Save the files and restart both Rational Directory Servers.
  4. Create a peer2peer.ldif file on both servers with the content provided in code Listing 1.
  5. After you have saved the file on the Peer1 server:
    • For a UNIX system, go to /opt/IBM/ldap/V6.3/bin
    • For Windows go to C:\Program Files\IBM\LDAP\V6.3\bin and run the following command:
      ./ldapmodify -h localhost -p 1389 -D uid=tdsadmin,ou=people,dc=telelogic,dc=com -w <tdsadminpassword> -i <Path for peer 2 peer file>/ peer2peer.ldif -k -l

      The Peer1 server is ready after you complete that step.
  6. Repeat steps 1 through 6 on the Peer2 server.

The peer-to-peer replication setup is then finished. You can start using Rational Directory Server. Any action on the Peer1 Rational Directory Server will be reflected on the Peer2 Rational Directory Server and vice versa.

Note:
If you are using the corporate mode of Rational Directory Server, setting up the corporate partition on the first server will automatically set it up on the second instance after replication configuration is finished.

Listing 1. Contents for the peer2peer.ldif file
dn: dc=telelogic, dc=com
changetype: modify
add: objectclass
objectclass: ibm-replicationContext

dn: ibm-replicaGroup=default,dc=telelogic,dc=com
changetype: add
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

dn: ibm-replicaServerId=Peer1,ibm-replicaGroup=default,dc=telelogic,dc=com
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer1
ibm-replicationServerIsMaster: true
cn: Peer1
description: Subentry for Peer1.

dn: ibm-replicaServerId=Peer2,ibm-replicaGroup=default,dc=telelogic,dc=com
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer2
ibm-replicationServerIsMaster: true
cn: Peer2
description: Subentry for Peer2.

dn: cn=ReplicaBindCredentials,dc=telelogic,dc=com
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on peer1 and peer2 to bind to each other.

dn: cn=Peer2, ibm-replicaServerId=Peer1,ibm-replicaGroup=default,dc=telelogic,dc=com
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Peer2
ibm-replicaConsumerId: Peer2
ibm-replicaUrl: ldap:// <Peer2 fully qualified domain name here>:1389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials,dc=telelogic,dc=com
description: Replication agreement from peer1 to peer2.

dn: cn=Peer1, ibm-replicaServerId=Peer2,ibm-replicaGroup=default,dc=telelogic,dc=com
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Peer1
ibm-replicaConsumerId: Peer1
ibm-replicaUrl: ldap://<Peer1 fully qualified domain name here>:1389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials,dc=telelogic,dc=com
description: Replication agreement from peer2 to peer1.

dn: ibm-replicaServerId=Peer1,ibm-replicaGroup=default, cn=IBMPOLICIES
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer1
ibm-replicationServerIsMaster: true
cn: Peer1
description: Subentry for Peer1.

dn: ibm-replicaServerId=Peer2,ibm-replicaGroup=default,cn=IBMPOLICIES
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer2
ibm-replicationServerIsMaster: true
cn: Peer2
description: Subentry for Peer2.

dn: cn=ReplicaBindCredentials,cn=IBMPOLICIES
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on peer1 and peer2 to bind to each other.

dn: cn=Peer2, ibm-replicaServerId=Peer1,ibm-replicaGroup=default,cn=IBMPOLICIES
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Peer2
ibm-replicaConsumerId: Peer2
ibm-replicaUrl: ldap:// <Peer2 fully qualified domain name here>:1389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials,cn=IBMPOLICIES
description: Replication agreement from peer1 to peer2.

dn: cn=Peer1, ibm-replicaServerId=Peer2,ibm-replicaGroup=default,cn=IBMPOLICIES
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Peer1
ibm-replicaConsumerId: Peer1
ibm-replicaUrl: ldap:// <Peer1 fully qualified domain name here>:1389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials,cn=IBMPOLICIES
description: Replication agreement from peer2 to peer1.

Acknowledgement

Thanks to Darshan Donni and Neelam V. Kulkami for the information in their article, Setting up Tivoli Directory Server replication by using the command line (IBM developerWorks, December 2006), which helped in writing this article.

Resources

Learn

Get products and technologies

Discuss

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 Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=860858
ArticleTitle=Back up Rational software user data for quick disaster recovery
publish-date=03122013