Migrate a CA Directory Linux Implementation to a New Set of Servers
search cancel

Migrate a CA Directory Linux Implementation to a New Set of Servers

book

Article ID: 390415

calendar_today

Updated On:

Products

CA Directory

Issue/Introduction

There are times when we are facing the need to migrate an existing CA Directory Linux Implementation to a new set of servers. The real-world scenarios for this type of need include:

  • Migrating an on-prem implementation to the Cloud and vice versa
  • Retiring the existing Linux Servers to be replaced by a new set of servers for various reasons.

 

Environment

Release 14.1
Component: CA Directory
Operating System: Linux

Resolution

Within this article, we assume that you know exactly the set of Linux CA Directory servers that needs to be migrated. If not, you can use the exploration parts of the following article to identify them:

Planning on In-Place Upgrading a CA Directory Linux Implementation

We have also decided to separate the migration of a Directory Management UI server into its own topic so that we can simplify the structure of this document and concentrate on the more urgent matter of migrating the Directory servers.

Install the Same Release of CA Directory on the New Servers

The aforementioned article also re-empasizes the importance of distinguishing the two types of CA Directory installation packages:

  • Directory Package, and
  • Directory Management UI Package

The first set of tasks to do is to use the correct package to install the same release of the CA Directory on each of the new servers. To do that, you will need to follow the production documentation starting the following link:

Installing

to first prepare your servers to fulfill the system requirements, all the pre-requisites, and then to actually install the correct package of the CA Directory software on each of the servers.

Within this article, we focus on only the migration of the Directory servers, that is the set of servers installed using the Directory Package. This should work out as it is recommended not to deploy any production DSAs on the Management UI servers.

Migrate the Existing CA Directory Services to the New Set of Servers

This article is scoped to discuss migrating an existing CA Directory Implementation to a new set of servers. The nature of being a migration allows us to break the migration tasks into two phases and allows the existing services to continue to function. This approach is in general similar to the Parallel upgrade section in the product documentation:

Upgrading

There may exist certain upgrade scenarios where we may not have the luxury to assume that we can simply migrate services within the same CA Directory releases. Yet, even if the new servers is actually an upgrade when we are required to install newer release of the software, the approach using ldif data files to move the data from existing servers to the new servers will most likely not cause any issues at all. 

The first phase is focusing on migrating the services to the new servers without concerning the data synchronization between the two sets of servers and allow both systems to function independently.

The second phase is to pause the existing production services, quickly move the production data to this new set of servers, switch the production client applications to connect to the new servers, and finally stop the original services and then retire the original services.

Phase 1: Migrate the Existing Directory Servers to the New Servers

In general, it is recommended not to create extra DSAs on a production Management UI server. Please see:

Recommendations

As such, we focus on 

Setup New Directory Servers

The migration of the existing Directory Servers is then assumed to include only the servers that is installed using the Directory Package. Under this assumption, for each of the existing Directory Server, we need to

  1. Identify the corresponding new server where an existing service is migrating to.
  2. Fulfill the system requirements, pre-requisites, and then install the same release of the Directory Package on the identified new server.
  3. Use the democorp/unspsc/routers included in the samples subdirectories or similar to quickly verify the software is installed and functioning correctly.
  4. Remove the configuration/data created to by the verification samples
  5. Rename the DXHOME/config subdirectory to a different name.
  6. Adjust the file systems to accommodate any of the possible custom directory structure where you may be holding your configuration and/or data files. A common example for this is the subdirectories used to hold database backup files.
  7. Copy the config subdirectory and other possible custom directory structure from the corresponding existing server to this new server.
  8. Adjust the configuration files so that the new servers will honor the new machine names and/or IP addresses in the new environment.
  9. Load the ldif data to the new server through ldif files obtained using the dxdumpdb on existing servers and dxnewdb/dxloaddb on the new servers.

Of the steps outlined above, other than "Adjust the configuration files" step, the rest of steps are relatively straight forward.

Adjust the Configuration Files to Honor the New Machine Names and/or IP Address

The following Linux command is a simple way to help locate those files that have either machine names and/or IP address we need to adjust to allow the new servers to offer the same services. Its output is not quite as clean but relatively easy to use:

cd $DXHOME/config
find . -type f -exec grep address {} +

The following is a sample output to give you some ideas to further sort out which files need to adjust:

./DSAConfig.xsd:                <xs:annotation><xs:documentation>If a port is specified, then that port is used with all interfaces specified for the host. If an address list is specified, then each component interface must exist on the host and a port can optionally be given against each one. If no port is given, then it is inherited in the usual way.</xs:documentation><xs:appinfo>
./access/access.help:    attrs = telephoneNumber, commonName, surname, title, mhsORaddress, dcEmail
./knowledge/knowledge.help:address             = tcp Eagle port 1901,
...
./knowledge/unspsc.dxc:     address       = tcp "XXXXXXXX" port 19489
...
./knowledge/democorp2.dxc:#     address       = ipv4 "999.999.999.999" port 22389
./schema/mhs.dxc:    ldap-names = mhs-or-addresses
./schema/cosine.dxc:        name   = cosineTextEncodedORaddress
./schema/cosine.dxc:    ldap-names = textEncodedORaddress

Usually, these address lines are usually in the files under the knowledge subdirectory, but they could be anywhere else especially the config/servers subdirectory.

With the files located, it can be tedious to go through each of them and change either the machine name or the IP address to ones the new set of servers use. 

Testing the New Servers and Adjusting Client Applications Configurations in Production

Once all ldif data loaded into the new servers, then

  1. Run "dxserver start all on all servers"
  2. Verify the data replications if any on the new set of servers
  3. Adjust and document production network needs for any of the name to IP resolutions, NAT addresses, firewall rules, load balancers and other third-party integrations to allow client applications that operates in production network to actually connect and work.
  4. Adjust client application configurations in production so that there should be no client-side configuration changes during the production switching to reduce the amount of time required.
  5. Verify the client applications if operate in production network can connect to this new set of servers and function correctly

Phase 2: Switch the Directory Services in Production to the New Servers

The steps for the second phase can be outlined as follows:

  1. Confirm the "Testing the New Servers" during phase 1 has properly prepared what the client applications in production network need to interact with the new set of servers
  2. Confirm the client applications do not require any configuration changes after switching to the new set of servers.
  3. Shutdown all DSAs on the new set of servers
  4. Pause the exiting production servers, allow the replication to finish, take the new data snapshots in ldif using dxdumpdb for all Data DSAs.
  5. Load the ldif data files to the net set of servers
  6. Adjust the production network configurations so that all the relevant existing client applications in production network will connect to the new set of servers and work
  7. Start all DSAs on the new set of servers

Next Steps

For an implementation that actually uses the Management UI to manage the DSAs deployment. The migration of the Management UI servers is a subject of its own and will be discussed in a separate article.

 

Powered by Wolken Software