1. Enterprise Deployment Guide for Oracle Identity and Access Management
  2. Configuring the Enterprise Deployment
  3. Configuring Multi-Data Center

18 Configuring Multi-Data Center

Multi-Data Centers (MDC) help you distribute load as well as address disaster recovery. This chapter provides detailed instructions to help you configure multi- data centers for your enterprise deployment.

Topics

Parent topic: Configuring the Enterprise Deployment

Variables Used When Configuring Multi-Data Center

This topic lists the variables used while configuring the Multi-Data Center.

  • IAD_ORACLE_HOME

  • IGD_ASERVER_HOME

  • IAD_ASERVER_HOME

Parent topic: Configuring Multi-Data Center

Roadmap for Configuring Multi-Data Center Deployment

The roadmap in this section includes the high-level steps for configuring a multi-data center deployment.

The steps described in this chapter, to configure multi-data center enterprise deployment, assumes that you have copies of the binaries on both site-1 and site-2. The binaries should be at the same patch level version. Some of the methods of doing this are:

  • Manually installing the products on site–1 and site–2

  • Remote mirror from site-1 to site-2

  • T2P copy and paste method

Creating the binaries is outside of the scope of this chapter. Manual installation steps are described in the earlier chapters of this guide. Remote mirroring is achieved using the mechanisms available within your storage hardware. T2P can be used by following the Oracle T2P documentation.

Table 18-1 Roadmap for Configuring a Multi-Data Center Enterprise Deployment

Task Sub-Tasks Description

Configure Site-1 by completing the sub-tasks on Site-1.

For each of the sub-tasks, follow the instructions described under Site-1 title, in the respective sections provided in the Description column.

Procure the necessary resources. See Procuring Resources for a Multi-Data Center Deployment.

NA

 Preparing the load balancer. See Preparing the Load Balancer for a Multi-Data Center Deployment.

NA

 Prepare the file system. See Preparing the File System for a Multi-Data Center Deployment.

NA

 Prepare the host computers. See Preparing the Host Computers for a Multi-Data Center Enterprise Deployment.

NA

 Prepare the database. See Preparing the Host Computers for a Multi-Data Center Enterprise Deployment.

NA

 Configure Oracle LDAP. See Configuring Oracle LDAP for a Multi-Data Center Deployment.

NA

 Configure Oracle HTTP Server. See Configuring the Web Tier for a Multi-Data Center Deployment.

NA

 Create the Infrastructure for Oracle Access Management. See Creating the Oracle Access Management Infrastructure for a Multi-Data Center Deployment.

NA

 Configure Oracle Access Management. See Configuring Oracle Access Management for a Multi-Data Center Deployment.

NA

 Create the Infrastructure for Oracle Identity Governance. See Creating the Oracle Identity Governance Infrastructure for a Multi-Data Center Deployment.

NA

 Configure Oracle Identity Governance. See Configuring Oracle Identity Governance for a Multi-Data Center Deployment.

Configure Site-2 by completing the sub-tasks on Site-2.

For each of the sub-tasks, follow the instructions described under Site-2 title, in the respective sections provided in the Description column.

Procure the necessary resources. See Procuring Resources for a Multi-Data Center Deployment.

NA

 Preparing the load balancer. See Preparing the Load Balancer for a Multi-Data Center Deployment.

NA

 Prepare the file system. See Preparing the File System for a Multi-Data Center Deployment.

NA

 Prepare the host computers. See Preparing the Host Computers for a Multi-Data Center Enterprise Deployment.

NA

 Prepare the database. See Preparing the Host Computers for a Multi-Data Center Enterprise Deployment.

NA

 Extend the existing Oracle LDAP directory to Site-2. See Configuring Oracle LDAP for a Multi-Data Center Deployment.

NA

 Configure Oracle HTTP Server. See Configuring the Web Tier for a Multi-Data Center Deployment.

NA

 Create the Infrastructure for Oracle Access Management. See Creating the Oracle Access Management Infrastructure for a Multi-Data Center Deployment.

NA

 Configure Oracle Access Management. See Configuring Oracle Access Management for a Multi-Data Center Deployment.

NA

 Create the Infrastructure for Oracle Identity Governance. See Creating the Oracle Identity Governance Infrastructure for a Multi-Data Center Deployment.

NA

 Extend the Oracle Identity Governance installation to encompass Site-2. See Configuring Oracle Identity Governance for a Multi-Data Center Deployment.
Enable Oracle Policy Replication between Site-1 and Site-2.

NA

 See Enabling Multi-Data Center.

Parent topic: Configuring Multi-Data Center

Procuring Resources for a Multi-Data Center Deployment

You must procure the resources for a multi-data center enterprise deployment.

The procedure for procuring the resources for a multi-data center enterprise deployment is same as the one described in Procuring Resources for an Enterprise Deployment, but with the following additional considerations.

Site–1

When allocating virtual IP addresses, you must ensure that:

  • You will need a virtual IP address for the Oracle Access Management Domain on Site 1.

  • The virtual IP address you use for the Oracle Identity Manager Domain must be movable to Site 2, if Site–1 becomes unavailable. This allows the Administration server to be started on Site–2, if necessary.

Site–2

When allocating virtual IP addresses, you must ensure that:

  • You will need a virtual IP address for the Oracle Access Management Domain on Site 2.

  • The virtual IP Address you use for the Oracle Identity Manager Domain must be movable from Site–1, if Site–2 becomes available. This allows the Administration server to be started on Site–1, if necessary.

Parent topic: Configuring Multi-Data Center

Preparing the Load Balancer for a Multi-Data Center Deployment

A local load balancer configuration for a Multi-Data Center Enterprise Deployment needs to be configured for Site–1 and Site–2.

The procedure for preparing the load balancer for a multi-data center enterprise deployment is same as the one described in Preparing the Load Balancer and Firewalls for an Enterprise Deployment, but with the following additional considerations.

Site–1

The differential parameters for local load balancer configuration of Site–1 in a Multi-Data Center Enterprise Deployment are:

  • The load balancer virtual servers configured within the site will not use the main entry points, that is, idstore.example.com, igdinternal.example.com, prov.example.com, and login.example.com, instead, they will use local variants. The names of these entries are not used outside of the load balancer configuration, for example, they can be login1.example.com and prov2.example.com

  • Iadamin.example.com will be unique to the deployment, for example: iadadmin1.example.com.

  • A new load balancer entry point called oam1.example.com will be defined, which will contain the Oracle Access Management (OAM) Managed servers in Site–1.

  • A global Load balancer virtual host, called oam.example.com will be created, which will pass on requests to the local load balancer virtual host oam1.example.com.

  • The main application entry points, that is, idstore.example.com , login.example.com, prov.example.com and igdinternal.example.com will be configured as part of a global load balancer. These entry points will in turn pass on requests to the local load balancer virtual host. For example prov.example.com will direct requests to prov1.example.com.

Site–2

The differential parameters for local load balancer configuration of Site–2 in a Multi-Data Center Enterprise Deployment are:

  • The load balancer virtual servers configured within the site will not use the main entry points, that is, prov.example.com and login.example.com, instead, they will use local variants. The names of these entries are not used outside of the load balancer configuration, for example, they can be login2.example.com and prov2.example.com

  • Iadamin.example.com will be unique to the deployment, for example: iadadmin2.example.com.

  • A new load balancer entry point called oam2.example.com will be defined, which will contain the Oracle Access Management (OAM) Managed servers in Site-2.

  • The local load balancer virtual host oam2.example.com will be added to the global load balancer definition for oam.example.com. Geographic rules will be set up to ensure that invocations originating in Site–1 are sent to oam1.example.com and invocations originating in Site–2 are sent to oam2.example.com. If the target for the invocations is unavailable, they can be directed to any site which is available..

  • The local load balancer virtual hosts for iidstore2.example.com, igdinternal2.example.com, prov2.example.com, and login2.example.com will be added to the corresponding global load balancer definition, and geographic rules set up to ensure:

    • Internal traffic originating from a given site is sent to back to that site, if it is available. If the site is not available, internal traffic is directed to another site.

    • Public traffic is directed to the local load balancer that is nearest to their geographical location.

Parent topic: Configuring Multi-Data Center

Preparing the File System for a Multi-Data Center Deployment

You must configure the file system for a multi-data center enterprise deployment.

The procedure for preparing the file system for a multi-data center enterprise deployment is same as the one described in Preparing the File System for an Enterprise Deployment, but with the following additional considerations.

Site–1

The differential parameters for file system configuration of Site–1 in a Multi-Data Center Enterprise Deployment are:

  • The binaries can optionally be mirrored to Site–2 to prevent the need to keep both sites at the exact same software versions. If doing so, it is important that at least two versions of the binaries are used, as described in the main chapter.

  • IAD_ASERVER_HOME will be configured locally to Site–1.

  • IAD_ASERVER_HOME will be mirrored to Site–2 to allow the Governance Administration server to be started on Site–2, if necessary.

  • If you are using the file system for whole server migration, then this will need mirroring to Site 2.

Site–2

The differential parameters for file system configuration of Site–2 in a Multi-Data Center Enterprise Deployment are:

  • The binaries can optionally be mirrored to Site 1 to prevent the need to keep both sites at the exact same software versions. If doing so, it is important that at least two versions of the binaries are used, as described in the main chapter.

  • IGD_ASERVER_HOME will be configured locally to Site–2.

  • IGD_ASERVER_HOME will be mirrored to Site 1 to allow the Governance Admin server to be started on Site–2, if necessary.

  • If you are using the file system for whole server migration, then this will need mirroring to Site–1.

Parent topic: Configuring Multi-Data Center

Preparing the Host Computers for a Multi-Data Center Enterprise Deployment

The procedure for preparing the host computers for a multi-data center enterprise deployment is same as the one described in Preparing the Host Computers for an Enterprise Deployment.

Parent topic: Configuring Multi-Data Center

Preparing the Database for a Multi-Data Center Deployment

You must configure the database for a multi-data center enterprise deployment.

The procedure for preparing the database for a multi-data center enterprise deployment is same as the one described in Preparing the Database for an Enterprise Deployment, but with the following additional considerations.

Site–1

The observations to be made when setting up a database for a multi-data center enterprise deployment for Site–1 are:

  • A dedicated database will be used for Oracle Access Management (OAM) for Site–1.

  • A dedicated database will be used for Oracle Identity Governance (OIG) for Site–1.

  • Role-based database services must be used for OIG.

Site–2

The observations to be made when setting up a database for a multi-data center enterprise deployment for Site–2 are:

  • A dedicated database will be used for Oracle Access Management (OAM) for Site–2.

  • Data guard will be used to replicate the Oracle Identity Governance (OIG) database to Site–2

  • Role-based database services must be used for OIG and configured on both Site–1 and Site–2.

Parent topic: Configuring Multi-Data Center

Configuring Oracle LDAP for a Multi-Data Center Deployment

You must configure Oracle LDAP for a Multi-Data Center Enterprise Deployment.

The Oracle LDAP configuration for a Multi-Data Center Enterprise Deployment for Site–1 and Site–2 is described in the following sections.

Site–1

Configure LDAP on Site–1 as described in Configuring Oracle LDAP for an Enterprise Deployment.

Site–2

LDAP is configured on Site–2 as an extension of Site–1. Therefore, you should configure LDAP on Site–2 as follows:

Parent topic: Configuring Multi-Data Center

Configuring the Web Tier for a Multi-Data Center Deployment

You must configure the web tier for a multi-data center enterprise deployment.

Configure Oracle HTTP Server (as described in Configuring Oracle HTTP Server for an Enterprise Deployment), but with the following additional considerations:

Site-1

The observations to be made when configuring the web tier for a Multi-Data Center Enterprise Deployment for Site 1 are:

  • When creating the virtual hosts (either Oracle HTTP Server or Oracle Internet Directory), ensure that the main entry points are used, that is, prov.example.com , login.example.com, and igdinternal.example.comrather than the local variations.

  • Iadadmin1.example.com should still be used for the iadadmin.example.comentry point. Iadadmin1.example.com will always be used to manage the Oracle Access Management (OAM) domain on Site–1.

  • Optionally, include the Weblogic cluster members from Site–2 in the virtual host definitions. If the managed servers in Site 1 are down, but the web tier in Site–1 is functioning, then Site 1 can direct requests to managed servers on Site–2. While this is a legitimate use case, it is more often not desirable to direct requests to managed servers to prevent traffic from bouncing between the sites. If you do not wish traffic bouncing between the sites, then you need to add the Oracle HTTP Server directive DynamicServerList OFF.

# OIM Self Service

<Location/Identity>

SetHandler webLogic-handler

WebLogicCluster PMHOST1.example.com:14000, OIMHOST2.example.com:14000

DynamicServerList OFF

</Location

Site–2

The observations to be made when configuring the web tier for a Multi-Data Center Enterprise Deployment for Site–2 are:

  • When creating the virtual hosts (either Oracle HTTP Server or Oracle Internet Directory), ensure that the main entry points are used, that is, prov.example.com , login.example.com, and igdinternal.example.com rather than the local variations.

  • Iadadmin2.example.com should still be used for the iadadmin.example.com entry point. Iadadmin2.example.com will always be used to manage the Oracle Access Management (OAM) domain on Site–2.

  • Optionally, include the Weblogic cluster members from Site–2 in the virtual host definitions. If the managed servers in Site–1 are down, but the Web Tier in Site–1 is functioning, then Site–1 can direct requests to managed servers on Site–2. While this is a legitimate use case, it is more often not desirable to direct requests to managed servers to prevent traffic from bouncing between the sites. If you do not wish traffic bouncing between the sites, then you need to add the Oracle HTTP Server directive DynamicServerList OFF.

# OIM Self Service

<Location/Identity>

SetHandler webLogic-handler

WebLogicCluster OIMHOST3.example.com:14000, OIMHOST2.example.com:14000

DynamicServerList OFF

</Location

Be aware that if you are using dynamic clusters with OIM, the port numbers will be an increment of those on Site–1. For example: Site 1 (14000, 14001) and Site–2 (14002, 14003).

Parent topic: Configuring Multi-Data Center

Creating the Oracle Access Management Infrastructure for a Multi-Data Center Deployment

The creation of the Oracle Access Management Infrastructure for a multi-data center enterprise deployment for Site–1 and Site –2 is the same as the standard EDG process described in Creating Infrastructure for Oracle Access Management.

Parent topic: Configuring Multi-Data Center

Configuring Oracle Access Management for a Multi-Data Center Deployment

You must configure Oracle Access Management for a multi-data center enterprise deployment.

The procedure for configuring Oracle Access Management for a multi-data center enterprise deployment is same as the one described in Configuring Oracle Access Management, but with the following additional considerations.

Site–1

After configuring OAM, complete the following tasks:

  1. Create a Server Instance for Load Balancer

    When OAM is initially configured, a number of OAM server instances would have been created for each managed server. These server instances are used to determine where to send OAM NAP calls. In a Multi-Data Center deployment, you need to create an additional server instance for the load balancer entry point, oam.example.com. For more information on how to create a server instance, refer Creating an Additional Server Instance for the Load Balancer.

  2. Update Webgate Agents to Use load Balancer

    Update the Webgate Agents to use the load balancer entry oam.example.com rather than the named server names. For more information on how to To update the Webgate Agents, refer Updating the Webgate Agents to Use Load Balancer

Site–2

The configuration of OAM for Site–2 is similar to that described in the configuration for Site–1. The updating of webgate agents to use the load balancer entry point is taken care of with policy synchronisation.

Parent topic: Configuring Multi-Data Center

Creating an Additional Server Instance for the Load Balancer

You must create an additional server instance for the load balancer entry point in a Multi-Data Center Enterprise Deployment.

To create an additional server instance, perform the following steps:
  1. Log in to the OAM console using the URL as oamadmin user that you have created in the EDG.
    http://iadadmin.example.com/oamconsole
  2. Click the Configuration tab.
  3. Click Server Instances.
  4. On the Search OAM Servers page, click Search.
    The server instances that are already defined is displayed.
  5. Click Create
  6. Enter the server name as oamLBR
  7. Enter the loadbalancer virtual host name. For example: oam.example.com
  8. Enter the port that you have configured on the loadbalancer virtual host to listen on. For example: 5575
  9. Enter the proxy server ID that you have used in the existing server entries. For example: AccessServerConfigProxy
  10. Select the OAM security model that you are using. For example: Simple
  11. Click Apply.

Parent topic: Configuring Oracle Access Management for a Multi-Data Center Deployment

Updating the Webgate Agents to Use Load Balancer

You must update the Webgate Agents for the load balancer entry point in a Multi-Data Center Enterprise Deployment.

To update the Webgate Agents, do the following:
  1. Click an agent name.
  2. In the Primary Server box, click the Add button to create a new agent, and select oamLBR as the access server.
  3. Delete each of the other entries in the Primary Server List.
  4. Click Apply
  5. Repeat these steps for each of the agents.

Parent topic: Configuring Oracle Access Management for a Multi-Data Center Deployment

Creating the Oracle Identity Governance Infrastructure for a Multi-Data Center Deployment

The procedure for configuring Oracle Identity Governance (OIG) Infrastructure for a multi-data center enterprise deployment for Site–1 and Site— 2 is largely the same as the standard EDG process described in Creating Infrastructure for Oracle Identity Governance. There are however a few exceptions which are described below.

Parent topic: Configuring Multi-Data Center

Configuring Oracle Identity Governance for a Multi-Data Center Deployment

You must configure Oracle Identity Governance for a multi-data center enterprise deployment.

The configuration of Oracle Identity Governance (OIG) for a multi-data center enterprise deployment is the same as the standard EDG process described in Configuring Oracle Identity Governance. In addition to this, perform the additional tasks for Site-1 and Site-2.

Site–1

After you configure Oracle Identity Governance on Site-1, perform the following tasks on Site-1:

  1. Configuration Wizard changes for Oracle Identity Manager

  2. Post-configuration Changes for Oracle Identity Manager

Site–2

After you configure Oracle Identity Governance on Site-2, disable the OIM job scheduler for Site–2 as described in Disabling the Oracle Identity Manager Job Scheduler for Configuring the Oracle Identity Manager.

Parent topic: Configuring Multi-Data Center

Configuration Wizard changes for Oracle Identity Manager

The following additions should be made in the configuration wizard when configuring Oracle Identity Manager this will create a cluster which spans the two sites:

  • Oracle Identity Manager (OIM) Cluster Configuration

    In the configuration wizard, while creating the IAMGovernanceDomain, you must include ALL servers (Site 1 and Site 2), when specifying the OIM and SOA clusters. For example, OIMHOST1.example.com:14000, OIMHOST2.example.com:14000, OIMHOST3.example.com:14000, OIMHOST4.example.com:14000

    For dynamic clusters, you must include only the machines for Site 1 and Site 2.

    If you have an existing deployment, you can use the standard scale up/out procedures to include the extra cluster members.

  • JMS

    Configure JMS to use the database by creating JMS stores for All the OIM/SOA managed servers.

  • Data sources

    When creating the JMS data sources, you must specify the OIM service name and not the database service name; this will be a role-based database service.

Parent topic: Configuring Oracle Identity Governance for a Multi-Data Center Deployment

Post-configuration Changes for Oracle Identity Manager

The following post-configuration changes should be made when configuring Oracle Identity Manager (OIM):

  • Update OIM data source

    When the OIM domain was created, a number of datasources would have been created that use the oim.example.com database service. All these services will be pointing at the primary OIM database. In order to facilitate a seamless failover, the standby database needs to be added in to the data source configurations. A typical database connection which includes both a primary and standby database looks like: 

    jdbc:oracle:thin:@ (DESCRIPTION_LIST=(LOAD_BALANCE=OFF)(FAILOVER=ON)(DESCRIPTION=(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=iagdb-scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=oim.example.com)))(DESCRIPTION=(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=iagdbdg-scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=oim.example.com))))

These data sources needs to be changed. For more information on how to change the data sources, refer Changing the Oracle Identity Manager Data Sources for Configuring Oracle Identity Manager

  • Update Java Virtual Machine Process Status Tool (JPS) security files

    In addition to updating the weblogic data sources, you must also update the data source information in the files, jps-config.xml and jps-config-jse.xml, which are located in the directory IGD_ASERVER_HOME/config/fmwconfig.

    Note:

    You must take a back up of these files before editing them.

Parent topic: Configuring Oracle Identity Governance for a Multi-Data Center Deployment

Changing the Oracle Identity Manager Data Sources for Configuring Oracle Identity Manager
You must change the Oracle Identity Manager data sources when performing the post-configuration changes for configuring Oracle Identity Manager (OIM). To change the OIM data sources, do the following:
  1. Login to the WebLogic Console.
  2. Click Lock and Edit.
  3. In the Domain Tree, expand Services – Data Sources.
  4. On the Summary of JDBC Data sources page, click the name of a data source. For example, click ApplicationDB.
  5. Click the Connection Pool tab.
  6. Update the URL to reflect the above database connection example.
  7. Click Save.
  8. Validate the data source by clicking the Monitoring tab and the Testing sub tab.
  9. Select one of the servers and click Test Data Source.
    You make sure the test is successful before continuing.
  10. Click the ONS tab.
  11. Add the standby database to the ONS Nodes field by separating each host/port with a comma. For example: primaryDB-scan:6200,standbyDB-scan:6200.
  12. Click Save.
  13. Repeat for each data source.
  14. Click Activate Changes.

Disabling the Oracle Identity Manager Job Scheduler for Configuring the Oracle Identity Manager

You must the disable the Oracle Identity Manager job scheduler on Site 2 for configuring the Oracle Identity Manager.

The OIM job scheduler uses the database intensively. In order to keep inter-site traffic to a minimum, the job scheduler should be disabled on the site, where the database is not primary. This step is not necessary, if you plan to shutdown the OIM Managed servers on Site 2.

The jobscheduler is disabled by adding the following parameter to the server startup arguments:

-Dscheduler.disabled=true

For more information on how to disable the job scheduler, refer Adding the Parameter to Disable Job Scheduler for Configuring Oracle Identity Manager

Parent topic: Configuring Oracle Identity Governance for a Multi-Data Center Deployment

Adding the Parameter to Disable Job Scheduler for Configuring Oracle Identity Manager
To add the parameter, Disabling th, to disable the job scheduler, do the following:
  1. Log in to the WebLogic Administrative Console.
  2. In left pane, click Environment, Servers.
  3. Click Lock and Edit in the left tab.
  4. Click Configuration, Server start tab in the right pane.
  5. In the Argument text box, add -Dscheduler.disabled=true, and save.
  6. Click Activate Change in the left pane.
    After switching over the database, this parameter should be removed from these servers and added into the server definitions of the now standby site.

Updating TAP Endpoint

The procedure for updating TAP endpoint is explained in this section.

If you have configured the OAM MDC prior to starting the configuration of Oracle Identity Governance then this step is not required. If you are converting an existing OAM to a multi-datacenter, then you may need to update the TAP endpoint in OIM to reflect the new OAM Entry point:

  1. Log in to the IdentityAccessDomain in the Oracle Enterprise Manager using the user weblogic_idm.
    http://iadadmin.example.com/em
  2. Click weblogic_domain > System Mbean Browser.
  3. In the search box, enter oamWLST, and click Search. The mbean is displayed.
  4. Select the Operations tab.
  5. Click displayTAPURL, make a note of the return value. Check the example mentioned below.
    https://login.example.com:443/oam/server/dap/cred_submit
  6. Log in to the IdentityGovernanceDomain of Oracle Enterprise Manager using the user weblogic_idm.
    http://igdadmin.example.com/em
  7. Click weblogic_domain > System Mbean Browser.
  8. In the search box, enter SSOIntegrationMXBean, and click Search. The mbean is displayed.
  9. Set the value of TapEndpointUrl attribute to the value noted from oamWLST bean.
  10. Click Apply.

Parent topic: Configuring Multi-Data Center

Enabling Multi-Data Center

You must enable the Multi-Data Center after building a Multi-Data Center Deployment.

You can enable the Multi-Data Center by performing the following steps. These steps are explained in the following sections.

Parent topic: Configuring Multi-Data Center

Setting up a Primary Data Center

To set up a Primary Data Center, you must configure a Primary Data Center using MDC ADMIN REST APIs.

Run the following command with appropriate values to configure the Primary Data Center.

curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://MasterServerURL/oam/services/rest/mdc/master' -d '{"mdcTopologyType":"value", "masterMDCAgentID":"value","cloneMDCAgentID":"value", "accessClientPassword":"value","artifactPassword":"value","cloneServerURL":"value","agentKeyPassword":"value","certModeKeystorePassword":"value","masterServerURL":"value", "cloneAdminUserNamePassword":"value","trustStorePath":"value", "keyStorePath":"value", "artifactsZipLocation":"value"}'

The following table describes the values for the Curl command.

Table 18-2 Configuring the Primary Data Center

Value Description
-u The user name and password of the OAM Administrative user. For example: iamadmin
MasterServerURL The URL of the OAM domain you are designating as primary. For example: http://iadadmin1.example.com/oam/services/rest/mdc/master
mdcTopologyType The two topology types available for MDC configuration, ACTIVE_ACTIVE or DISASTER_RECOVERY. In this case, choose ACTIVE_ACTIVE.
masterMDCAgentID The MDC NAP Agent Name for the Primary Data Center. For, enter Site1
cloneMDCAgentID The MDC NAP Agent Name for the Clone data center. For example, enter Site2
accessClientPassword The password required to be used by the MDC NAP agents in Primary and Clone data centers
artifactPassword The password that is used to protect cloning artifacts
cloneServerURL The URL of the Primary Admin server or the URL of the reverse proxy front ending the Primary Admin Server. For example, enter http://iamadmin1.example.com/
masterServerURL The URL of the Primary Admin server or the URL of the reverse proxy front ending the Primary Admin Server. For example, enter http://iamadmin1.example.com/
cloneAdminUserNamePassword The user credentials of the Clone data center’s IAM Administrator if the user name and password of the Administrator for Primary and Clone data centers are different. For example, enter iamadmin
trustStorePath The path to oamclient-truststore.jks file. For example IAD_ASERVER_HOME/output/webgate-ssl-SHA-256/
keyStorePath The path to oamclient-keystore.jks file file For example IAD_ASERVER_HOME/output/webgate-ssl-SHA-256/
artifactsZipLocation The location where cloning artifacts are to be stored; specify only if cloning artifacts need to be stored in any location other than /tmp. For example SHARED_CONFIG_DIR/mdc

Note:

Before running the Curl command, make sure that the location specified in artifactsZipLocation already exists.

A sample Curl command for configuring a Primary Data Center is as follows:

curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://iadadmin1.example.com/oam/services/rest/mdc/master' -d '{"mdcTopologyType":"ACTIVE_ACTIVE", "masterMDCAgentID":"site1Agent","cloneMDCAgentID":"site2Agent", "accessClientPassword":"password","artifactPassword":"password","cloneServerURL":"http://iadadmin2.example.com","agentKeyPassword":"password","certModeKeystorePassword":"password","masterServerURL":"http://iadadmin1.example.com", "cloneAdminUserNamePassword":"password","trustStorePath":"/u01/oracle/config/domains/IAMAccessDomain/output/webgate-ssl-SHA-256", "keyStorePath":"":"/u01/oracle/config/domains/IAMAccessDomain/output/webgate-ssl-SHA-256", "artifactsZipLocation":"/u01/oracle/config/mdc"}'

After this command is executed, two new agents are created in the OAM Console called, site1Agent and site2Agent. Verify that these agents reference the load balancer entry for OAM by following the steps in Updating the Webgate Agents to Use Load Balancer section.

Parent topic: Enabling Multi-Data Center

Setting up a Clone Data Center

To set up a Clone Data Center, you must configure a Clone Data Center for Multi-Data Center (MDC) environment using MDC ADMIN REST APIs as follows:

Run the following command with appropriate values to configure the Clone Data Center.

curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://CloneServerURL/oam/services/rest/mdc/clone' -d '{"masterServerURL":"value","artifactPassword":"value","masterAdminUserNamePassword":"value", "artifactsZipLocation":"value", "masterArtifactsZipLocation":"value"}'

The following table describes the values for the Curl command.

Table 18-3 Clone Data Center Properties

Value Description
-u The user name and password of the OAM Administrative user. For example: iamadmin
CloneServerURL The URL of the OAM domain you are designating as a clone. For example: http://iadadmin2.example.com/oam/services/rest/mdc/clone
masterServerURL The URL of the Primary Admin server or the URL of the reverse proxy front ending the Primary Admin Server. For example, enter http://iamadmin.example.com/
artifactPassword The same password that protects cloning artifacts and is used while setting up the Primary data centers
masterAdminUserNamePassword The user credentials of the Primary data center’s IAM Administrator
artifactsZipLocation The location where cloning artifacts are to be stored; specify only if cloning artifacts need to be stored in any location other than /tmp. For example SHARED_CONFIG_DIR/mdc

Note:

Before running the Curl command, make sure that the location specified in artifactsZipLocation already exists on the clone admin server machine.

A sample Curl command for configuring a Clone Data Center is as follows:

curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://iadadmin2.example.com/oam/services/rest/mdc/clone/configuration'

In a Multi-Data Center deployment, only one site is responsible for the creation of policies; the site that been designated as primary site, as explained in the section Setting up a Primary Data Center. To prevent inadvertent writes to the Clone site, you must place the Clone site into read-only mode.

To place the clone site into read-only mode on the clone site, do the following:

IAD_ORACLE_HOME/oracle_common/common/bin/wlst.sh 
connect('weblogic','password','t3://iadadmminvhn2.example.com:7001') 
domainRuntime() 
setMultiDataCenterWrite(WriteEnabledFlag="true") 
exit()

After setting up the Clone Data Center, you must restart the domain and validate the configuration, for Site 1 and Site 2.

For more information, refer the following topics:

Parent topic: Enabling Multi-Data Center

Restarting the Domains

After setting up the Clone Data Center, you must restart the domains for Site 1 and Site 2.

To restart the domains on Site 1 and Site 2, do the following:

  1. Shutdown the Admin Server and Managed Servers on Site 1.

  2. Shutdown the Admin Server and Managed Servers on Site 2.

  3. Startup the Admin Server and Managed Servers on Site 1.

  4. Startup the Admin Server and Managed Servers on Site 2.

Validating the Configuration of Clone Data Center

After setting up the Clone Data Center, you must validate the configuration of Clone Data Center for Site 1 and Site 2.

To validate the configuration, execute the following command:

curl -k -u oamadmin:XXXX 'http://SiteURL/oam/services/rest/mdc/configuration'

For Site 1, the command is:

curl -k -u oamadmin:password “http://iadadmin1.example.com/oam/services/rest/mdc/configuration”

For Site 1, the command is:

curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST “http://iadadmin2.example.com/oam/services/rest/mdc/configuration”

Enabling Replication

After the configuration has been placed into Multi-Data Center mode you have to set up data synchronization. This set-up ensures that any information added to the Primary site is propagated to the Clone sites.

The set-up is a two-stage process, which are:

  • To perform a bulk data unload from the Primary site to the Clone site

  • To create a replication agreement so that subsequent changes are propagated automatically

For more information, refer the following topics:

Parent topic: Enabling Multi-Data Center

Performing a Bulk Data Unload from the Primary Site to the Clone Site

To perform a bulk data unload from the Primary site to the Clone site, you must refresh the Clone with the Primary site's Data, which is achieved by exporting the Access Store from the Primary and importing it into the clone.

To refresh the Clone with the Primary site's Data, issue the following command on the Primary Node:

IAD_ORACLE_HOME/oracle_common/common/bin/wlst.sh
connect('weblogic','password','t3://iadadmin1vhn.example.com:7001')
exportAccessStore(toFile=”filelocation/oamaccess.zip",namePath="/")‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬
exit()‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬

Note:

A file location must exist for the command to be executed.

Copy the generated file to the Clone admin server host.

To refresh the Clone with the Primary site's Data, issue the following command on the Clone Node:

IAD_ORACLE_HOME/oracle_common/common/bin/wlst.sh
connect('weblogic','password','t3://iadadmin1vhn.example.com:7001')
importAccessStore(toFile=”filelocation/oamaccess.zip",namePath="/")‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬
exit()‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬

Parent topic: Enabling Replication

Creating a Replication Agreement

The final step in the process is to set up a replication agreement between the Primary and the Clone Sites. But, before creating a replication agreement, it is good practice to perform the processes listed below. These processes are explained in the following sections.

To set up a replication agreement between the Primary and the Clone Sites, execute the following command:

curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://masterSiteURL/oam/services/rest/_replication/setup' -d '{"name":”agreementName”,"source":”masterClusterName”,"target":”cloneClusterName”,"documentType":"ENTITY","config": {"entry":{"key":"authorization","value":”Basic encodedUser” }}}' 

The following table describes the values for the Curl command.

Table 18-4 Values for the Curl Command

Value Description
-u The user name and password of the OAM Administrative user. For example: iamadmin
masterSiteURL The URL of the OAM domain you are designating as primary, for example: http://iadadmin1.example.com/ oam/services/rest/_replication/setup
agreementName A name of the agreement of your choice. For example: Site1toSite2
masterClusterName The name of the primary sites cluster obtained from Obtain MDC Cluster Names
clonerClusterName The name of the cluster sites cluster obtained from Obtain MDC Cluster Names
encodedUser The iamadmin encoded user string as obtained in Encode the iammadmin User

A sample Curl command for creating a replication agreement is as follows

curl -k -u iamadmin:password -H 'Content-Type: application/json' -X POST 'http://iadadmin1.example.com/oam/services/rest/_replication/setup' -d '{"name":"Site1toSite2","source":"0c04b-OAMHOST1.u","target":"0c04b-OAMHOST2.u","documentType":"ENTITY","config": {"entry":{"key":"authorization","value":"Basic aWFtYWRtaW46UGFzc3dvcmQxr" }}}' 

If the replication is successful, the output is similar to as shown below:

{"enabled":true,"identifier":"201709071449437364","lastSequenceNumber":878,"ok":true,"pollInterval":900,"startingSequenceNumber":878,"state":"READY"}

Note:

The POLLINTERVAL is 900 sec (15 min). Hence the changes made in Primary DC takes 15 minutes to get propagated to Clone DC. If the poll interval is too long, you can modify the poll interval in Clone DC.

To modify the poll interval in Clone DC, do the following:

  1. Obtain the replication Identifier (replId) by sending a query to the existing replication agreements using the following command:

    curl -k -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/_replication/agreements' 

      If there are multiple agreements, you must select the identifier for which APS has to be disabled by executing the same command on the corresponding Clone Data Center.

  2. Execute the following command to modify poll interval in Clone DC:

    curl -u weblogic:password -H 'Content-Type: application/json' -X PUT 'http://iamadmin1.example.com/oam/services/rest/_replication/replicationAgreement' -d '{"pollInterval":PollInterval,"replicaType":"CONSUMER"}'
    Where

    • replicationAgreement is the value obtained in step 1

    • Pollinterval is the new polling interval in seconds

Validating the Replication End Points

Before creating a replication agreement, it is good practice to ensure that REST endpoints, which facilitate replication, are working on both the primary and clone sites. If these end points are not working, you will not be able to create a replication agreement.

To validate the replication end points, you must issue the following command:

curl -u oamadmin:password 'http://SiteURL/oam/services/rest/_replication/hello'

A sample Curl command for validating replication end points is as follows:

For Site 1:
curl -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/_replication/hello'
For Site 2:
curl -u oamadmin:password 'http:// iadadmin2.example.com /oam/services/rest/_replication/hello'
Obtaining the Multi-Data Center Cluster Names

Each site in the Multi-Data Center deployment has a unique cluster name, which is required when creating a replication agreement.

Query the existing configurations using the following command to determine the cluster name of each site:

curl -k -u oamadmin:password 'http://siteURL/oam/services/rest/mdc/dc/configuration

A sample Curl command for Obtaining the Multi-Data Center Cluster Names is as follows:

For Site 1:
curl -k -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/mdc/dc/configuration
For Site 2:
curl -k -u oamadmin:password 'http://iadadmin2.example.com/oam/services/rest/mdc/dc/configuration
The output is similar to as shown below with the cluster name highlighted:
{"ok":true,"status":"Success","clusterName":"0c04b-OAMHOST1.u" ,"primaryServers":["OAMHOST1.example.com:5575","OAMHOST2.example.com:5575","oamLBR.example.com:5575"],"restEndPoint":"http://IADADMINVHN1.example.com:7001","oamServerModes":{"wls_oam2":"simple","oamLBR":"simple","wls_oam1":"simple"}}

Make a note of the cluster names.

Encoding the oamadmin User

When you setup the replication agreement, you need to use the oamadmin account, which resides in your LDAP directory.

Setting up the replication agreement is achieved using curl commands. As part of the curl command, you need to supply the oamadmin user and password. This password must be encoded using base64. There are many utilities on the web that allow you to encode the password, one example is http://www.motobit.com/util/base64-decoder-encoder.asp

Note:

When encoding the value you must encode both the username and the password. For example; when using the above utility the value to be encoded should be in the form username:password (For example; oamadmin:<password>).