After the configuration succeeds on OIMHOST1, you can propagate it to OIMHOST2 by packing the domain on OIMHOST1 and unpacking it on OIMHOST2.

To pack the domain on OIMHOST1 and unpack it on OIMHOST2:

Validate the Oracle Identity Manager (OIM) instances on OIMHOST2.

Open the OIM Console with this URL:

http://identityvhn2.example.com:14000/identity

Log in using the xelsysadm password.

Each Managed Server has a transaction log that stores information about in-flight transactions that the Managed Server coordinates that may not complete. WebLogic Server uses the transaction log to recover from system/network failures. To leverage the Transaction Recovery Service migration capability, store the transaction log in a location that all Managed Servers in a cluster can access. Without shared storage, other servers in the cluster can't run transaction recovery in the event of a server failure, so the operation may need to be retried.

To set the location for default persistence stores for the OIM and SOA Servers:

Install Oracle HTTP Server on WEBHOST1 and WEBHOST2.

To validate that Oracle HTTP Server is configured properly, follow these steps:

You can scale out or scale up the OIG high availability topology. When you scale up the topology, you add new Managed Servers to nodes that are already running one or more Managed Servers. When you scale out the topology, you add new Managed Servers to new nodes. See Scaling Out Oracle Identity Governance to scale out.

In this case, you have a node that runs a Managed Server configured with SOA. The node contains:

• A Middleware home

• An Oracle HOME (SOA)

• A domain directory for existing Managed Servers

You can use the existing installations (Middleware home and domain directories) to create new WLS_OIM and WLS_SOA Managed Servers. You do not need to install OIM and SOA binaries in a new location or run pack and unpack.

This procedure describes how to clone OIM and SOA Managed Servers. You may clone one or two of these component types, as long as one of them is OIM.

Note the following:

• This procedure refers to WLS_OIM and WLS_SOA. However, you may not be scaling up both the components. For each step, choose the component(s) that you are scaling up in your environment. Also, some steps do not apply to all components

• The persistent store's shared storage directory for JMS Servers must exist before you start the Managed Server or the start operation fails.

• Each time you specify the persistent store's path, it must be a directory on shared storage

To scale up the topology:

1. In the Administration Console, clone WLS_OIM1/WLS_SOA1. The Managed Server that you clone should be one that already exists on the node where you want to run the new Managed Server.

   1. Select Environment -> Servers from the Administration Console.

   2. Select the Managed Server(s) that you want to clone.

   3. Select Clone.

   4. Name the new Managed Server WLS_OIMn/WLS_SOAn, where n is a number to identity the new Managed Server.

   The rest of the steps assume that you are adding a new Managed Server to OIMHOST1, which is already running WLS_OIM1 and WLS_SOA1.

2. For the listen address, assign the hostname or IP for the new Managed Server(s). If you plan to use server migration, use the VIP (floating IP) to enable Managed Server(s) to move to another node. Use a VIP different from the VIP that the existing Managed Server uses.

3. Create JMS Servers for OIM/SOA, BPM, UMS, JRFWSAsync, and SOAJMServer on the new Managed Server.

   1. In the Administration Console, create a new persistent store for the OIM JMS Server(s) and name it. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

   2. Create a new JMS Server for OIM. Use JMSFileStore_n for JMSServer. Target JMSServer_n to the new Managed Server(s).

   3. Create a persistence store for the new UMSJMSServer(s), for example, UMSJMSFileStore_n. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
      

   4. Create a new JMS Server for UMS, for example, UMSJMSServer_n. Target it to the new Managed Server (WLS_SOAn).

   5. Create a persistence store for the new BPMJMSServer(s), for example, BPMJMSFileStore_n. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n
      

   6. Create a new JMS Server for BPM, for example, BPMJMSServer_n. Target it to the new Managed Server (WLS_SOAn).

   7. Create a new persistence store for the new JRFWSAsyncJMSServer, for example, JRFWSAsyncJMSFileStore_n. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n
      

   8. Create a JMS Server for JRFWSAsync, for example, JRFWSAsyncJMSServer_n. Use JRFWSAsyncJMSFileStore_n for this JMSServer. Target JRFWSAsyncJMSServer_n to the new Managed Server (WLS_OIMn).

      Note:

      You can also assign SOAJMSFileStore_n as store for the new JRFWSAsync JMS Servers. For clarity and isolation, individual persistent stores are used in the following steps.

   9. Create a persistence store for the new SOAJMSServer, for example, SOAJMSFileStore_auto_n. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_auto_n
      

   10. Create a JMS Server for SOA, for example, SOAJMSServer_auto_n. Use SOAJMSFileStore_auto_n for this JMSServer. Target SOAJMSServer_auto_n to the new Managed Server (WLS_SOAn).

       Note:

       You can also assign SOAJMSFileStore_n as store for the new PS6 JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   11. Update SubDeployment targets for SOA JMS Module to include the new SOA JMS Server. Expand the Services node, then expand the Messaging node. Choose JMS Modules from the Domain Structure window. Click SOAJMSModule (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. In the subdeployment module, click the SOAJMSServerXXXXXX subdeployment and add SOAJMSServer_n to it Click Save.

       Note:

       A subdeployment module name is a random name in the form COMPONENTJMSServerXXXXXX. It comes from the Configuration Wizard JMS configuration for the first two Managed Servers, WLS_COMPONENT1 and WLS_COMPONENT2).

   12. Update SubDeployment targets for UMSJMSSystemResource to include the new UMS JMS Server. Expand the Services node, then expand the Messaging node. Choose JMS Modules from the Domain Structure window. Click UMSJMSSystemResource (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. In the subdeployment module, click the UMSJMSServerXXXXXX subdeployment and add UMSJMSServer_n to it. Click Save.

   13. Update SubDeployment targets for OIMJMSModule to include the new OIM JMS Server. Expand the Services node, then expand Messaging node. Choose JMS Modules from the Domain Structure window. Click OIMJMSModule (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. In the subdeployment module, click OIMJMSServerXXXXXX and OIMJMSServer_n to it. Click Save.

   14. Update SubDeployment targets for the JRFWSAsyncJmsModule to include the new JRFWSAsync JMS Server. Expand the Services node then expand the Messaging node. Choose JMS Modules from the Domain Structure window. Click JRFWSAsyncJmsModule (hyperlink in the Names column of the table). In the Settings page, click the SubDeployments tab. Click the JRFWSAsyncJMSServerXXXXXX subdeployment and add JRFWSAsyncJMSServer_n to this subdeployment. Click Save

   15. Update SubDeployment targets for BPM JMS Module to include the new BPM JMS Server. Expand the Services node, then expand the Messaging node. Choose JMS Modules from the Domain Structure window. Click BPMJMSModule (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. In the subdeployment module, click the BPMJMSServerXXXXXX subdeployment and add BPMJMSServer_n to it. Click Save.

4. Configure the transaction persistent store for the new server in a shared storage location visible from other nodes.

   From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the default persistent store.

5. Disable hostname verification for the new Managed Server (required before starting/verifying a WLS_SOAn Managed Server) You can re-enable it after you configure server certificates for Administration Server / Node Manager communication in SOAHOSTn. If the source server (from which you cloned the new Managed Server) had disabled hostname verification, these steps are not required; hostname verification settings propagate to a cloned server.

   To disable hostname verification:

   1. In the Administration Console, expand the Environment node in the Domain Structure window.

   2. Click Servers. Select WLS_SOAn in the Names column of the table.

   3. Click the SSL tab. Click Advanced.

   4. Set Hostname Verification to None. Click Save.

6. Start and test the new Managed Server from the Administration Console.

   1. Shut down the existing Managed Servers in the cluster.

   2. Ensure that the newly created Managed Server is up.

   3. Access the application on the newly created Managed Server to verify that it works. A login page opens for OIM. For SOA, a HTTP basic authorization opens.

   Table 6-3 Managed Server Test URLs

   Component	Managed Server Test URL
   SOA	http://vip:port/soa-infra
   OIM	http://vip:port/identity

7. In the Administration Console, select Services then Foreign JNDI provider. Confirm that ForeignJNDIProvider-SOA targets cluster:t3://soa_cluster, not a Managed Server(s). You target the cluster so that new Managed Servers don't require configuration. If ForeignJNDIProvider-SOA does not target the cluster, target it to the cluster.

8. Configure Server Migration for the new Managed Server.

   Note:

   For scale up, the node must have a Node Manager, an environment configured for server migration, and the floating IP for the new Managed Server(s).

   To configure server migration:

   1. Log into the Administration Console.

   2. In the left pane, expand Environment and select Servers.

   3. Select the server (hyperlink) that you want to configure migration for.

   4. Click the Migration tab.

   5. In the Available field, in the Migration Configuration section, select machines to enable migration for and click the right arrow. Select the same migration targets as for the servers that already exist on the node.

      For example:

      For new Managed Servers on SOAHOST1, which is already running WLS_SOA1, select SOAHOST2.

      For new Managed Servers on SOAHOST2, which is already running WLS_SOA2, select SOAHOST1.

      Verify that the appropriate resources are available to run Managed Servers concurrently during migration.

   6. Select the Automatic Server Migration Enabled option to enable Node Manager to start a failed server on the target node automatically.

   7. Click Save.

   8. Restart the Administration Server, Managed Servers, and Node Manager.

   9. Repeat these steps to configure server migration for the newly created WLS_OIMn Managed Server.

9. To test server migration for this new server, follow these steps from the node where you added the new server:

   1. Stop the Managed Server.

      Run kill -9 pid on the PID of the Managed Server. To identify the PID of the node, enter, for example, ps -ef | grep WLS_SOAn.

   2. Watch Node Manager Console for a message indicating that the Managed Server floating IP is disabled.

   3. Wait for Node Manager to try a second restart of the Managed Server. Node Manager waits for 30 seconds before trying this restart.

   4. After Node Manager restarts the server, stop it again. Node Manager logs a message indicating that the server will not restart again locally.

10. Edit the OHS configuration file to add the new managed server(s). See Configuring Oracle HTTP Server to Recognize New Managed Servers.

When you scale out the topology, you add new Managed Servers configured with software to new nodes.

Before you scale out, check that you meet these requirements:

• Existing nodes running Managed Servers configured with OIM and SOA in the topology.

• The new node can access existing home directories for WebLogic Server, SOA, and OIM. (Use existing installations in shared storage to create new Managed Server. You do not need to install WebLogic Server or component binaries in a new location, but must run pack and unpack to bootstrap the domain configuration in the new node.)

  Note:

  If there is no existing installation in shared storage, you must install WebLogic Server, SOA, and OIM in the new nodes.

  Note:

  When multiple servers in different nodes share ORACLE_HOME or WL_HOME, Oracle recommends keeping the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh.

To scale out the topology:

1. On the new node, mount the existing Middleware home, which contains the SOA and OIG installations, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.

2. Attach ORACLE_HOME in shared storage to the local Oracle Inventory. For example:

   cd /u01/app/oracle/soa/
   ./attachHome.sh -jreLoc u01/app/JRE-JDK_version>
   

   To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the ORACLE_HOME/bea/beahomelist file and add u01/app/oracle to it.

3. Log in to the Administration Console.

4. Create a new machine for the new node. Add the machine to the domain.

5. Update the machine's Node Manager's address to map the IP of the node that is being used for scale out.

6. Clone WLS_OIM1/WLS_SOA1.

   To clone OIM and SOA:

   1. Select Environment -> Servers from the Administration Console.

   2. Select the Managed Server(s) that you want to clone.

   3. Select Clone.

   4. Name the new Managed Server WLS_OIMn/WLS_SOAn, where n is a number to identity the new Managed Server.

   Note:

   These steps assume that you are adding a new server to node n, where no Managed Server was running previously.

7. Assign the hostname or IP to use for the new Managed Server for the listen address of the Managed Server. In addition, update the value of the Machine parameter with the new machine created in step 4.

   If you plan to use server migration for this server (which Oracle recommends), this should be the server VIP (floating IP). This VIP should be different from the one used for the existing Managed Server.

8. Create JMS servers for OIM (if applicable), UMS, BPM, JRFWSAsync, and SOA on the new Managed Server.

   1. In the Administration Console, create a new persistent store for the OIM JMS Server and rename it. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

   2. Create a new JMS Server for OIM. Use JMSFileStore_n for JMSServer. Target JMSServer_n to the new Managed Server(s).

   3. Create a persistence store for the new UMSJMSServer(s), for example, UMSJMSFileStore_n. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
      

   4. Create a new JMS Server for UMS, for example, UMSJMSServer_n. Target it to the new Managed Server, which is WLS_SOAn (migratable).

   5. Create a persistence store for the new BPMJMSServer(s), for example, BPMJMSFileStore_n. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n
      

   6. Create a new JMS Server for BPM, for example, BPMJMSServer_n. Target it to the new Managed Server, which is WLS_SOAn (migratable).

   7. Create a new persistence store for the new JRFWSAsyncJMSServer, for example, JRFWSAsyncJMSFileStore_n. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n
      

   8. Create a JMS Server for JRFWSAsync, for example, JRFWSAsyncJMSServer_n. Use JRFWSAsyncJMSFileStore_n for this JMSServer. Target JRFWSAsyncJMSServer_n to the new Managed Server, which is WLS_OIMn (migratable).

      Note:

      You can also assign SOAJMSFileStore_n as store for the new JRFWSAsync JMS Servers. For clarity and isolation, the following steps use individual persistent stores.

   9. Create a persistence store for the new SOAJMSServer, for example, SOAJMSFileStore_auto_n. Specify the store's path, a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_auto_n
      

   10. Create a JMS Server for SOA, for example, SOAJMSServer_auto_n. Use SOAJMSFileStore_auto_n for this JMSServer. Target SOAJMSServer_auto_n to the new Managed Server, which is WLS_SOAn (migratable).

       Note:

       You can also assign SOAJMSFileStore_n as store for the new PS6 JMS Servers. For clarity and isolation, the following steps use individual persistent stores.

   11. Update SubDeployment targets for SOA JMS Module to include the new SOA JMS Server. Expand the Services node, then expand the Messaging node. Choose JMS Modules from the Domain Structure window. Click SOAJMSModule (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. In the subdeployment module, click the SOAJMSServerXXXXXX subdeployment and add SOAJMSServer_n to it Click Save.

       Note:

       A subdeployment module name is a random name in the form COMPONENTJMSServerXXXXXX. It comes from the Configuration Wizard JMS configuration for the first two Managed Servers, WLS_COMPONENT1 and WLS_COMPONENT2).

   12. Update SubDeployment targets for UMSJMSSystemResource to include the new UMS JMS Server. Expand the Services node, then expand the Messaging node. Choose JMS Modules from the Domain Structure window. Click UMSJMSSystemResource (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. In the subdeployment module, click the UMSJMSServerXXXXXX subdeployment and add UMSJMSServer_n to it. Click Save.

   13. Update SubDeployment targets for OIMJMSModule to include the new OIM JMS Server. Expand the Services node, then expand Messaging node. Choose JMS Modules from the Domain Structure window. Click OIMJMSModule (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. In the subdeployment module, click OIMJMSServerXXXXXX and OIMJMSServer_n to it. Click Save.

   14. Update SubDeployment targets for the JRFWSAsyncJmsModule to include the new JRFWSAsync JMS Server. Expand the Services node then expand the Messaging node. Choose JMS Modules from the Domain Structure window. Click JRFWSAsyncJmsModule (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. Click the JRFWSAsyncJMSServerXXXXXX subdeployment and add JRFWSAsyncJMSServer_n to this subdeployment. Click Save

   15. Update SubDeployment targets for BPM JMS Module to include the new BPM JMS Server. Expand the Services node, then expand the Messaging node. Choose JMS Modules from the Domain Structure window. Click BPMJMSModule (hyperlink in the Names column). In the Settings page, click the SubDeployments tab. In the subdeployment module, click the BPMJMSServerXXXXXX subdeployment and add BPMJMSServer_n to it. Click Save.

9. Run the pack command on SOAHOST1 to create a template pack. For example:

   cd ORACLE_HOME/oracle_common/common/bin
   ./pack.sh -managed=true/
   -domain=ORACLE_HOME/user_projects/domains/soadomain/
   -template=soadomaintemplateScale.jar -template_name='soa_domain_templateScale'
   

   Run the following command on HOST1 to copy the template file created to HOSTn:

   scp soadomaintemplateScale.jar oracle@SOAHOSTN:/
   ORACLE_BASE/product/fmw/soa/common/bin
   

   Run the unpack command on HOSTn to unpack the template in the Managed Server domain directory. For example, for SOA:

   ORACLE_HOME/oracle_common/common/bin
   /unpack.sh /
   -domain=ORACLE_HOME/user_projects/domains/soadomain/
   -template=soadomaintemplateScale.jar
   

10. Configure the transaction persistent store for the new server. This should be a shared storage location visible from other nodes.

    From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.

11. Disable hostname verification for the new Managed Server; you must do this before starting/verifying the Managed Server. You can re-enable it after you configure server certificates for the communication between the Administration Server and Node Manager. If the source Managed Server (server you cloned the new one from) had already disabled hostname verification, these steps are not required. Hostname verification settings propagate to cloned servers.

    To disable hostname verification:

    1. Open the Administration Console.

    2. Expand the Environment node in the Domain Structure window.

    3. Click Servers.

    4. Select WLS_SOAn in the Names column of the table. The Settings page for the server appears.

    5. Click the SSL tab.

    6. Click Advanced.

    7. Set Hostname Verification to None.

    8. Click Save.

12. Start Node Manager on the new node, as shown:

    ORACLE_HOME/user_projects/domains/soadomain/bin/startNodeManager.sh
    

13. Start and test the new Managed Server from the Administration Console.

    1. Shut down the existing Managed Server in the cluster.

    2. Ensure that the newly created Managed Server is up.

    3. Access the application on the newly created Managed Server to verify that it works. A login page appears for OIM. For SOA, a HTTP basic authorization opens.

    Table 6-4 Managed Server Test URLs

    Component	Managed Server Test URL
    SOA	http://vip:port/soa-infra
    OIM	http://vip:port/identity

14. Configure Server Migration for the new Managed Server.

    Note:

    Because this new node is using an existing shared storage installation, it is already using a Node Manager and environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges. The floating IP for the new Managed Server is already in the new node.

    To configure server migration:

    1. Log into the Administration Console.

    2. In the left pane, expand Environment and select Servers.

    3. Select the server (represented as a hyperlink) for which you want to configure migration. The Settings page for that server appears.

    4. Click the Migration tab.

    5. In the Available field, in the Migration Configuration section, select machines to which to enable migration and click the right arrow.

       Note:

       Specify the least-loaded machine as the new server's migration target. Required capacity planning must be completed so that this node has the available resources to sustain an additional Managed Server.

    6. Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.

    7. Click Save.

    8. Restart the Administration Server, Managed Servers, and Node Manager.

15. Test server migration for this new server from the node where you added it:

    1. Stop the Managed Server.

       Run kill -9 pid on the PID of the Managed Server. Identify the PID of the node using, for example, ps -ef | grep WLS_SOAn.

    2. Watch the Node Manager Console for a message indicating that the floating IP has been disabled.

    3. Wait for the Node Manager to try a second restart of the new Managed Server. Node Manager waits for a fence period of 30 seconds before restarting.

    4. After Node Manager restarts the server, stop it again. Node Manager should log a message that the server will not restart again locally.

16. Edit the OHS configuration file to add the new managed server(s). See Configuring Oracle HTTP Server to Recognize New Managed Servers.