14 Configuring Server Migration for an Enterprise Deployment

Configuring server migration allows SOA-managed and OIM-managed servers to be migrated from one host to another, so that if a node hosting one of the servers fails, the service can continue on another node. This chapter describes how to configure server migration for an Identity Management enterprise deployment.

This chapter contains the following steps:

14.1 Overview of Server Migration for an Enterprise Deployment

Configure server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 Managed Servers. The WLS_OIM1 and WLS_SOA1 Managed Server are configured to restart on IDMHOST2 should a failure occur. The WLS_OIM2 and WLS_SOA2 Managed Servers are configured to restart on IDMHOST1 should a failure occur. The WLS_OIM1, WLS_SOA1, WLS_OIM2 and WLS_SOA2 servers listen on specific floating IPs that are failed over by WebLogic Server Migration.

Perform the steps in the following sections configure server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 Managed Servers.

14.2 Setting Up a User and Tablespace for the Server Migration Leasing Table

In this section, you set up a user and tablespace for the server migration leasing table:


If other servers in the same domain have already been configured with server migration, the same tablespace and data sources can be used. In that case, the data sources and multi data source for database leasing do not need to be re-created, but they must be retargeted to the clusters being configured with server migration.

  1. Create a tablespace called leasing. For example, log on to SQL*Plus as the sysdba user and run the following command:

    create tablespace leasing 
    logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' 
    size 32m autoextend on next 32m maxsize 2048m extent management local;
  2. Create a user named leasing and assign to it the leasing tablespace:

    create user leasing identified by password;
    grant create table to leasing;
    grant create session to leasing;
    alter user leasing default tablespace leasing;
    alter user leasing quota unlimited on leasing;
  3. Create the leasing table using the leasing.ddl script:

    1. Copy the leasing.ddl file located in either of the following directories to your database node:

    2. Connect to the database as the leasing user.

    3. Run the leasing.ddl script in SQL*Plus:

    4. Currently, the script does not commit the change. Enter the following, at the SQL*Plus prompt, after the tool completes:


14.3 Creating a GridLink Data Source for Leasing Using the Oracle WebLogic Administration Console

In this section, you create a GridLink data source for the leasing table from the Oracle WebLogic Server Administration Console.

To create a GridLink data source:

  1. Log in to the Oracle WebLogic Server Administration Console at the URL listed in Section 17.2, "About Identity Management Console URLs."

  2. If you have not already done so, in the Change Center, click Lock & Edit.

  3. In the IDMDomain Structure tree, expand Services, then select Data Sources.

  4. On the Summary of Data Sources page, click New and select GridLink Data Source, and enter the following:

    • Name: Enter a logical name for the data source. For example, leasing.

    • JNDI: Enter a name for JNDI. For example, jdbc/leasing.

    • Database Driver: Select For the Database Driver, select Oracle's Driver (Thin) for GridLink Connections Versions: 11 and later.

    • Click Next.

  5. In the Transaction Options page, de-select Supports Global Transactions, and click Next.

  6. In the GridLink Data Source Connection Properties Options screen, select Enter individual listener information and click Next.

  7. Enter the following connection properties:

    • Service Name: Enter the service name of the database with lowercase characters. For a GridLink data source, you must enter the Oracle RAC service name. For example: OIMEDG.mycompany.com

    • Host Name and Port: Enter the SCAN address and port for the RAC database being used. You can identify this address by querying the appropriate parameter in the database using the TCP Protocol:

      show parameter remote_listener;
      NAME                 TYPE        VALUE
      remote_listener     string      DB-SCAN.mycompany.com:1521


      For Oracle Database 11g Release 1 (11.1), use the virtual IP and port of each database instance listener, for example: DBHOST1-VIP.mycompany.com (port 1521) and DBHOST2-VIP.mycompany.com (port 1521), where 1521 is DB_LSNR_PORT

      For Oracle Database 10g, use multi data sources to connect to an Oracle RAC database. For information about configuring multi data sources see Appendix A, "Using Multi Data Sources with Oracle RAC."

    • Database User Name: leasing

    • Password: For example: welcome1

    • Confirm Password: Enter the password again and click Next.

  8. On the Test GridLink Database Connection page, review the connection parameters and click Test All Listeners. Here is an example of a successful connection notification:

    Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=DB-SCAN.mycompany.com)
    (PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=OIMEDG.mycompany.com))) succeeded.

    where port 1521 is DB_LSNR_PORT.

    Click Next.

  9. In the ONS Client Configuration page, do the following:

    • Select FAN Enabled to subscribe to and process Oracle FAN events.

    • Enter here also the SCAN address for the RAC database and the ONS remote port as reported by the database (example below) and click ADD:

      srvctl config nodeapps -s
      ONS exists: Local port 6100, remote port 6200, EM port 2016
    • Click Next.


    For Oracle Database 11g Release 1 (11.1), use the hostname and port of each database's ONS service, for example:

    DBHOST1.mycompany.com (port 6200)


    DBHOST2.mycompany.com (port 6200)
  10. On the Test ONS Client Configuration page, review the connection parameters and click Test All ONS Nodes.

    Here is an example of a successful connection notification:

    Connection test for DB-SCAN.mycompany.com:6200 succeeded.

    Click Next.

  11. In the Select Targets page, select oim_cluster and soa_cluster as the targets, and All Servers in the cluster.

  12. Click Finish.

  13. Click Activate Changes.

14.4 Editing Node Manager's Properties File

In this section, you edit Node Manager's properties file. This must be done for the Node Managers on the nodes where the servers are running, IDMHOST1 and IDMHOST2.

The nodemanager.properties file is located in the following directory:


Add the following properties to enable server migration to work properly:

  • Interface:


    This property specifies the interface name for the floating IP (for example, eth0).


    Do not specify the sub-interface, such as eth0:1 or eth0:2. This interface is to be used without :0 or :1. Node Manager's scripts traverse the different :X-enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0, eth1, eth2, eth3, ethn, depending on the number of interfaces configured.

  • NetMask:


    This property specifies the net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface.

  • UseMACBroadcast:


    This property specifies whether to use a node's MAC address when sending ARP packets, that is, whether to use the -b flag in the arping command.

Verify in Node Manager's output (shell where Node Manager is started) that these properties are being used, or problems may arise during migration. You should see something like this in Node Manager's output:



The following steps are not required if the server properties (start properties) have been properly set and Node Manager can start the servers remotely.

  1. If not done already, set the StartScriptEnabled property in the nodemanager.properties file to true. This is required to enable Node Manager to start the managed servers.

  2. Start Node Manager on IDMHOST1 and IDMHOST2 by running the startNodeManager.sh script, which is located in the WL_HOME/server/bin directory.


When running Node Manager from a shared storage installation, multiple nodes are started using the same nodemanager.properties file. However, each node may require different NetMask or Interface properties. In this case, specify individual parameters on a per-node basis using environment variables. For example, to use a different interface (eth3) in HOSTn, use the Interface environment variable as follows:

export JAVA_OPTIONS=-DInterface=eth3

and start Node Manager after the variable has been set in the shell.

14.5 Setting Environment and Superuser Privileges for the wlsifconfig.sh Script

On Linux, you set environment and superuser privileges for the wlsifconfig.sh script:

Ensure that your PATH environment variable includes the files listed inTable 14-1.

Table 14-1 Files Required for the PATH Environment Variable

File Located in this directory







Grant sudo privilege to the WebLogic user oracle with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.

For security reasons, sudo should be restricted to the subset of commands required to run the wlsifconfig.sh script. For example, perform the following steps to set the environment and superuser privileges for the wlsifconfig.sh script.


Ask the system administrator for the appropriate sudo and system rights to perform this step.

Make sure the script is executable by the WebLogic user ('oracle'). The following is an example of an entry inside /etc/sudoers granting sudo execution privilege for oracle and also over ifconfig and arping.

To grant sudo privilege to the WebLogic user ('oracle') with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries:

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

14.6 Configuring Server Migration Targets

In this section, you configure server migration targets. Configuring Cluster Migration sets the DataSourceForAutomaticMigration property to true.

To configure migration in a cluster:

  1. Log in to the Oracle WebLogic Server Administration Console at the URL listed in Section 17.2, "About Identity Management Console URLs."

  2. In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page is displayed.

  3. Click the cluster for which you want to configure migration (oim_cluster) in the Name column of the table.

  4. Click the Migration tab.

  5. Click Lock and Edit.

  6. In the Available field, select the machines to which to allow migration, IDMHOST1 and IDMHOST2, and click the right arrow.

  7. Select the data source to be used for automatic migration. In this case, select the leasing data source.

  8. Click Save.

  9. In the Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.

  10. Select the server for which you want to configure migration.

  11. Click the Migration tab.

  12. Select Automatic Server Migration Enabled and click Save.

  13. Click Activate Changes.

  14. Repeat steps 2 through 13 for the SOA cluster.

  15. Restart WebLogic Administration Server, Node Managers, and the servers for which server migration has been configured, as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components.".

14.7 Testing the Server Migration

In this section, you test the server migration. Perform these steps to verify that server migration is working properly:

To test from IDMHOST1:

  1. Stop the WLS_OIM1 Managed Server. To do this, run this command:

    kill -9 pid

    where pid specifies the process ID of the Managed Server. You can identify the pid in the node by running this command:

    ps -ef | grep WLS_OIM1
  2. Watch the Node Manager console. You should see a message indicating that WLS_OIM1's floating IP has been disabled.

  3. Wait for Node Manager to try a second restart of WLS_OIM1. It waits for a fence period of 30 seconds before trying this restart.

  4. Once Node Manager restarts the server, stop it again. Node Manager should now log a message indicating that the server will not be restarted again locally.

To test from IDMHOST2:

  1. Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_OIM1 on IDMHOST1, Node Manager on IDMHOST2 should prompt that the floating IP for WLS_OIM1 is being brought up and that the server is being restarted in this node.

  2. Access the OIM Console using the Virtual Host Name, for example: http://OIMHOST1VHN.mycompany.com:14000/identity.

Follow the previous steps to test server migration for the WLS_OIM2, WLS_SOA1, and WLS_SOA2 Managed Servers.

Table 14-2 shows the Managed Servers and the hosts they migrate to in case of a failure.

Table 14-2 Managed Server Migration

Managed Server Migrated From Migrated To













Verification From the Administration Console

Migration can also be verified in the Administration Console:

  1. Log in to the Administration Console.

  2. Click Domain on the left pane.

  3. Click the Monitoring tab and then the Migration sub tab.

    The Migration Status table provides information on the status of the migration.


After a server is migrated, to fail it back to its original node/machine, stop the Managed Server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager starts the Managed Server on the machine to which it was originally assigned.

14.8 Backing Up the Server Migration Configuration

Back up the database and the WebLogic domain, as described in Section 17.6.3, "Performing Backups During Installation and Configuration."