Inter Cluster Management

It is recommended that you designate one data center as the primary. Therefore, you should setup your cluster/primary data center based on the recommended architectures described in the RadiantOne Deployment and Tuning Guide. Then, all configurations made at the primary data center are migrated to all other data centers.

Each naming context depends on one or more resources to function properly. A resource is defined as any data source, virtual view (.dvx file), or schema file (.orx file), or Global Identity Builder project files associated with a naming context. The vdsconfig utility includes three commands that can discover, export and import the resources for a naming context.

• Resource-traverse discovers and displays the resources that a naming context depends on to function. Because some of these resources may exist behind the scenes, it is recommended that you run resource-traverse before exporting dependencies.
• Resource-export exports the dependencies to a zip file. This file can then be imported into a target server to synchronize the configuration changes.
• Resource-import imports the dependencies from a zip file onto a target server.

The tool used for traversing, exporting and importing configuration is named vdsconfig.bat (Windows) or vdsconfig.sh (Linux) and is located in <RLI_HOME>/bin.

It is recommended that configuration migration is performed during non-peak/off hours.

1. On a node in the primary cluster, open a command prompt and navigate to <RLI_HOME>\bin.
2. Run vdsconfig passing the resource-traverse -name <name of resource> -instance vds_server. The result is a hierarchy depicting the dependencies associated with the resource. Therefore, if you were to migrate the resource to another environment, all the needed dependencies must be considered as well. For example, if a new naming context named dc=ad needed to be migrated to an existing production environment the following command would traverse the resource and display the dependencies:

<RLI_HOME>/bin/vdsconfig.bat resource-traverse -name dc=ad -instance vds_server

2015 - 12 - 30 16:31:54 INFO c.r.t.c.ResourceCLI:134 - Dependency tree:
dc=ad [NAMING] OK
dc_ad.dvx [DVX] OK
ad203 [DATASOURCE] OK
dc_ad.orx [ORX] OK
ad203 [DATASOURCE] OK
2015 - 12 - 30 16:31:54 INFO c.r.t.c.ResourceCLI:135 - Resource paths:
zk:dvx/dc_ad.dvx
zk:lod/dc_ad.orx
zk:namings/a721f1f5-853e- 4983 - b5d7-c64105082ee3_dc=ad
ds:ad203

3. Using the resource-export command, export the resource and its dependencies. This exports the resource along with its dependencies into the file indicated in the command. If there are dependencies you want to omit from the export file, there are two command arguments that allow you to skip them. The -skip argument specifies the name of the resource to be skipped. The -skipregex argument allows you to indicate which resource(s) to skip using a regular expression. This makes -skipregex especially useful in situations where you want to omit a range of resources. The -skip and -skipregex arguments can be used together in the same command. The format for -skipregex is as follows.

Resourcetype:regex

Supported -skipregex resource types are naming, ds, orx, dvx, file, custom, and all. The following table provides examples of the argument’s usage and syntax.

If a location is not indicated with the -path command argument, the default is <RLI_HOME>/work.

In the following example, a naming context, dc=ad, and its dependencies, except for .DVX files, are exported.

<RLI_HOME>/bin/vdsconfig.bat resource-export -name dc=ad -instance vds_server -skipregex dvx:.*

2015 - 12 - 30 16:37:02 INFO c.r.t.m.ResourceDependencyService:102 - Export of dc=ad to C:\radiantone\vds\work\dc_ad.zip has completed successfully.

4. Copy the export file to the server where you want to migrate the changes.

5. On the target cluster/server, export the current configuration to save as a backup.

6. Run the command to import the resource and dependencies. By default, resource-import displays the actions that are going to be taken on the target without performing the import. This allows you to review the changes that will be applied to your target system. Take note of any items you do not want overwritten in the target so you can skip them when running the import command with the -apply flag. <RLI_HOME>/bin/vdsconfig.bat resource-import -path C:\radiantone\vds\work\dc_ad.zip

7. Run the resource-import command with the -apply flag to import the configuration changes on the target. Remember to skip any resources (using the -skip and/or -skipregex flags as described in step 3 above) you do not want updated on the target.

o_aggregateview [NAMING] OK
o_aggregateview.dvx [DVX] OK
seradiantad [DATASOURCE] OK
o_aggregateview.orx [ORX] OK
seradiantad [DATASOURCE] OK
mergetree_-1154533092_ou_cfs_users_o_aggregateview [NAMING] OK
vds_ou_cfs_users_o_aggregateview_ou_accounting_o_companydirectory.dvx [DVX] OK
vds [DATASOURCE] OK
vds_ou_cfs_users_o_aggregateview_ou_accounting_o_companydirectory.orx [ORX]OK
vds [DATASOURCE] OK
o=companydirectory [NAMING] OK

8. Perform any manual migration tasks applicable to your environment. Please see the Items Requiring Manual Migration section below for more details.

Items Requiring Manual Migration

After importing the configuration onto the production server, the following items should be reviewed to see if they are applicable to the configuration, as they must be addressed manually.

• Update Global Settings
• Configure and Initialize Persistent Cache
• Managing Server Certificate
• Installing Services
• Managing Interception Scripts and Custom Object Scripts

Update Global Settings

If you modified any RadiantOne global settings from the Main Control Panel > Settings tab, you must manually make those same changes to the target servers. These settings can be updated using the command line API instead of the Main Control Panel if needed. Please see the Radiantone Command Line Configuration Guide for details.

Configure and Initialize Persistent Cache

Virtual views configured as persistent cache should be manually configured as persistent cache and initialized in the target environment(s).

Managing Server Certificate

If you are using a CA-signed server certificate for RadiantOne, the Migration Tool cannot generate new ones for the target machine. New certificates must be configured manually if you do not want the server to use the certificate defined during the install. For steps on configuring and installing SSL certificates, please see the RadiantOne System Administration Guide.

Installing Servers to Run as Services

For steps on configuring and installing RadiantOne to start as a service, please see the RadiantOne Deployment and Tuning Guide.

Managing Interception Scripts and Custom Object Scripts

Interception scripts are deployed as jar files (<RLI_HOME>/vds_server/custom/lib/intercept.jar and/or customobjects.jar). These files should be copied from the source environment to the corresponding location on the target machine. The target RadiantOne service must be restarted for the new script to take effect.

If RadiantOne is deployed in a cluster architecture, the copied jar files are automatically synchronized to all nodes. However, the RadiantOne service on each node must be restarted for the new script logic to take effect. Therefore, restart each node one at a time so the other RadiantOne node(s) can handle the client load.

The resync utility allows you to analyze and reconcile RadiantOne Universal Directory (HDAP) stores in two different clusters. This can be useful when, for example, a network outage has prevented the clusters from communicating changes between them, resulting in a period of time in which they become out of sync. The utility compares the current image of a store in two different clusters. This analysis results in two LDIF-formatted files containing the changes applicable to each store required to bring the two stores in-sync. The source names are part of the LDIF file names so you know which file is applicable to which cluster. Two other LDIF-formatted files are also generated for sorting the entries. If no changes are required, the LDIF file dedicated for that data source is empty. The LDIF files containing the changes are located at <RLI_HOME>\vds_server\ldif\export and have the following syntax: <HDAP_Store_Suffix>_<data source name>.ldif

The basis for determining what is out-of-sync is determined in one of two ways:

• The first data source passed to the utility in the -d property is the one considered as the base, up-to-date image with which the image from the second data source is compared against.

• The timestamp passed in the -x property determines which new or deleted entries should apply to each store.

Both stores must be accessible and defined in the base DN of the LDAP data sources when the command is executed. You need one LDAP data source per cluster. Resync-util.bat (resync-util.sh on Linux) is located at <RLI_HOME>/bin/advanced.

Usage

resync-util.bat [-d <datasource1,datasource2>] [-b <base_dn>] [-x <disconnectionTimestamp>] [-i <ignoredAttributes>] [-c <true/false>] [-a <true/false>] [-m <true/false>]

In the following example, the store o=hdap1, in two different clusters identified as data sources named localvds and localvds2, are automatically re-synchronized.

c:\radiantone\vds\bin\advanced>resync-util.bat resync -d localvds,localvds2 -b o=hdap1 -a true

Command Arguments

- d <datasource1,datasource2>
[required] This parameter specifies the names of the data sources. The data sources must exist in RadiantOne prior to using the utility and you need one LDAP data source per cluster. Data sources are passed in the command as comma-separated values (e.g. cluster1,cluster2). If the - x argument is not specified, the first data source indicated in the -d argument is considered the definitive source for discrepant entries. - b <base_dn>
[required] The base DN of the stores to be examined.

- x <disconnectionTimestamp>
[optional] This value is the date and time used to determine which entries should be added and deleted in each store to bring the images in-sync. This timestamp would generally be the time the network connectivity between the clusters and the replication journal failed. If this value is specified, new entries and entry deletions that occur after the specified disconnectionTimestamp are noted in the LDIF files associated with the data source where the changes should be applied. If this value is not specified, the first data source indicated in the -d argument is considered the definitive source for discrepant entry additions and deletions. In addition, if the disconnectionTimestamp is equivalent to the time an entry was created or deleted, the first data source indicated in the -d argument is considered the definitive source.

[-i <ignoreAttributes>]
[optional] This argument specifies the attribute(s) to be ignored by the utility when comparing stores. If not specified, the utility examines all attributes in the specified stores. Attributes are comma-separated (e.g. cn,description,mail).

[-c <true/false>]
[optional] The default behavior is to save the LDIF files that sort and describe the entries that are discrepant between the two stores. If you do not want the LDIF files stored on the file system, pass -c false. If generated, these LDIF files are stored at <RLI_HOME>vds_server\ldif\export.

[-a <true/false>]
[optional] To perform an analysis of the stores without applying changes, pass the -a false argument, or omit this argument from the command. After analysis, you can copy the relevant LDIF file to the corresponding cluster and manually import it to update the store. If you prefer to automatically apply the changes required to bring the stores back in sync, pass the -a true argument and the re-sync occurs.

[-m <ignoreCase>]
[optional] To ignore case when detecting changes, pass the -m true argument, or omit this argument from the command. To detect case differences, pass the -m false argument.