Parallel Migrate a Complete CA Directory Implementation to a New Set of Servers

Products

• CA Directory

Issue/Introduction

As an enterprise continues to embrace the virtualization technology, there comes the point when it may decide to move its existing on-prem CA Directory implementation to the cloud or at least partially to the cloud.

To make the materials more consumable, this article is a summary of three other sub-topics:

• Planning
• Directory Server Migration
• Management UI Migration

As of this writing the SCIM Services feature of the Directory Manager is not yet addressed.

Environment

Release: 14.1
Component: CA Directory

Cause

There may come a time under the following scenarios when a parallel migration of a complete CA Directory implementation is needed:

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

Resolution

This article is to summarize the three-part approach we have tested to do a parallel migration of a complete CA Directory implementation: 

• Part 1: Planning on In-Place Upgrading a CA Directory Linux Implementation
  For a parallel migration, the usual approach is simply to prepare a new set of servers and to start the installation of the same version of the software. This part 1 starts as an in-place upgrade since a parallel migration tends to be a tradeoff of an in-place upgrade. An in-place upgrade planning guide allows the administrators to not overlook some of the details of the existing implementation that need changes for the new implementation. This part 1 also helps the administrator to clearly identify the two different CA Directory installation packages: Directory Package and Directory Management UI Packages and also all the Directory servers that are in service in case the administrators are inheriting a CA Directory implementation without the complete picture of the existing implementation.  
  If all possible, the administrators are encouraged to do an in-place upgrade for the existing CA Directory implementation so that once the whole parallel migration is done, we know that we can easily port the data running in the existing implementation to the new one.
  
  
• Part 2: Migrate a CA Directory Linux Implementation to a New Set of Servers
  Partly because CA Directory Management UI is an optional component, we can start migrating all the Directory servers first without the Management UI servers. This may seem to be counter intuitive, however, from what we have tested, we actually found out that it was easier to first migrate the Directory servers without the Management UI servers as the attempt to migrate the existing Management UI repository in a parallel migration scenario requires a lot of tedious changes to the data in the repository.
  Important!! It is worthwhile to point out that even if the DSAs of a CA Directory implementation have been deployed/managed using the CA Directory Management UI, the Driectory services of all the DSAs can actually function while the Management UI is offline.
  
  
• Part 3: Management UI Server Migration to New Set of Servers as Part of A CA Directory Implementation Migration
  Even though there may be good reasons why an existig CA Directory implementation elected not to implement the Management UI component, while you are doing the migration, it is actually a good time to re-exam the more recent features the Management UI has to offer:
  • Remote and Centralized Management - to avoid having to login to the CA Directory servers all the time
  • Less Error-Prone Configuration Changes of DSAs - the management UI helps relate DSAs information across multiple DSAs and avoid many of the common mistatkes 
  • Configuration Using a Graphical Web-Based User Interface - a modern Graphical Web UI has the advantage of revealing a large quantity of knowledge to the administrators so that one does not get blind-sided.
  • RestAPIs - to allow administrators to build automation scripts