20 Configuring Multi-Data Center
Topics
- Variables Used When Configuring Multi-Data Center
This topic lists the variables used while configuring the 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. - Procuring Resources for a Multi-Data Center Deployment
You must procure the resources for a multi-data center enterprise deployment. - 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. - Preparing the File System for a Multi-Data Center Deployment
You must configure the file system for a multi-data center enterprise deployment. - Preparing the Host Computers for a Multi-Data Center Enterprise Deployment
- Preparing the Database for a Multi-Data Center Deployment
You must configure the database for a multi-data center enterprise deployment. - Configuring Oracle LDAP for a Multi-Data Center Deployment
You must configure Oracle LDAP for a Multi-Data Center Enterprise Deployment. - Configuring the Web Tier for a Multi-Data Center Deployment
You must configure the web tier for a multi-data center enterprise deployment. - Creating the Oracle Access Management Infrastructure for a Multi-Data Center Deployment
- Configuring Oracle Access Management for a Multi-Data Center Deployment
You must configure Oracle Access Management for a multi-data center enterprise deployment. - Creating the Oracle Identity Governance Infrastructure for a Multi-Data Center Deployment
- Configuring Oracle Identity Governance for a Multi-Data Center Deployment
You must configure Oracle Identity Governance for a multi-data center enterprise deployment. - Updating TAP Endpoint
The procedure for updating TAP endpoint is explained in this section. - Enabling Multi-Data Center
You must enable the Multi-Data Center after building a Multi-Data Center Deployment.
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 20-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 either Oracle HTTP Server or Oracle Traffic Director. | 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 either Oracle HTTP Server or Oracle Traffic Director. | 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 available. 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
, andlogin.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 belogin1.example.com
andprov2.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 hostoam1.example.com
.
-
The main application entry points, that is,
idstore.example.com
,login.example.com
,prov.example.com
andigdinternal.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 exampleprov.example.com
will direct requests toprov1.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
andlogin.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 belogin2.example.com
andprov2.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 foroam.example.com
. Geographic rules will be set up to ensure that invocations originating in Site–1 are sent tooam1.example.com
and invocations originating in Site–2 are sent tooam2.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 i
idstore2.example.com
,igdinternal2.example.com
,prov2.example.com
, andlogin2.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.
-
IGD_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.
-
IAD_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
-
For Oracle Unified Directory (OUD), complete the following tasks:
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 either Oracle HTTP Server (as described in Configuring Oracle HTTP Server for an Enterprise Deployment) or Oracle Traffic Director (as described in Configuring Oracle Traffic Director 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
, andigdinternal.example.com
rather than the local variations.
-
Iadadmin1.example.com
should still be used for theiadadmin.example.com
entry 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
Note:
Whilst advised, it is not mandatory to use the same web tier type OHS or Oracle Traffic Directory on both sites.
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
, andigdinternal.example.com
rather than the local variations.
-
Iadadmin2.example.com
should still be used for theiadadmin.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
Note:
Whilst advised, it is not mandatory to use the same web tier type OHS or Oracle Traffic Directory on both sites.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:
-
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. -
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.
- 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. - 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.
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.
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.
- Click an agent name.
- In the Primary Server box, click the Add button to create a new agent, and select oamLBR as the access server.
- Delete each of the other entries in the Primary Server List.
- Click Apply
- Repeat these steps for each of the agents.
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:
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.
- Configuration Wizard changes for Oracle Identity Manager
- Post-configuration Changes for Oracle Identity Manager
- 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
:14000For 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.
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.
Changing the Oracle Identity Manager Data Sources for Configuring Oracle Identity Manager
Parent topic: Post-configuration Changes for Oracle Identity Manager
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
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:
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 Master Data Center
To set up a Master Data Center, you must configure a Master Data Center using MDC ADMIN REST APIs.
Run the following command with appropriate values to configure the Master 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 20-2 Configuring the Master 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 a master. 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 Master 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 Master and Clone data centers |
artifactPassword | The password that is used to protect cloning artifacts |
cloneServerURL | The URL of the Master Admin server or the URL of the reverse proxy front ending the Master Admin Server. For example, enter http://iamadmin1.example.com/ |
masterServerURL | The URL of the Master Admin server or the URL of the reverse proxy front ending the Master 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 Master 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 Master 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 20-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 Master Admin server or the URL of the reverse proxy front ending the Master Admin Server. For example, enter http://iamadmin.example.com/ |
artifactPassword | The same password that protects cloning artifacts and is used while setting up the Master data centers |
masterAdminUserNamePassword | The user credentials of the Master 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 master site, as explained in the section Setting up a Master 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:
-
Shutdown the Admin Server and Managed Servers on Site 1.
-
Shutdown the Admin Server and Managed Servers on Site 2.
-
Startup the Admin Server and Managed Servers on Site 1.
-
Startup the Admin Server and Managed Servers on Site 2.
Parent topic: Setting up a Clone Data Center
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”
Parent topic: Setting up a Clone Data Center
Enabling Replication
After the configuration has been placed into Multi-Data Center mode you have to set up data synchronisation. This set-up ensures that any information added to the Master 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 Master to the Clone
-
To create a replication agreement so that subsequent changes are propagated automatically
Fore more information, refer the following topics:
Parent topic: Enabling Multi-Data Center
Performing a Bulk Data Unload from the Master to the Clone
To perform a bulk data unload from the Master to the Clone, you must refresh the Clone with the Masters Data, which is achieved by exporting the Access Store from the Master and importing it into the clone.
To refresh the Clone with the Masters Data, issue the following command on the Master 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 Masters 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 Master 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 Master 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 20-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 a master, 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 master 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 Master 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:
-
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.
-
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
- Obtaining the Multi-Data Center Cluster Names
- Encoding the oamadmin User
Parent topic: Enabling Replication
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 master 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:
curl -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/_replication/hello'
curl -u oamadmin:password 'http:// iadadmin2.example.com /oam/services/rest/_replication/hello'
Parent topic: Creating a Replication Agreement
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:
curl -k -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/mdc/dc/configuration
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.us.oracle.com:7001","oamServerModes":{"wls_oam2":"simple","oamLBR":"simple","wls_oam1":"simple"}}
Make a note of the cluster names.
Parent topic: Creating a Replication Agreement
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>).Parent topic: Creating a Replication Agreement