Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Portal
11g Release 1 (11.1.1.6.0)

Part Number E12037-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

14 Configuring Server Migration for an Enterprise Deployment

This chapter describes the procedures for configuring server migration for the enterprise deployment.

This chapter contains the following sections:

14.1 Overview of Server Migration for an Enterprise Deployment

Configure server migration for the WLS_SOA1 and WLS_SOA2 managed servers. With server migration configured, should failure occur, the WLS_SOA1 managed server restarts on SOAHOST2, and the WLS_SOA2 managed server restarts on SOAHOST1. The WLS_SOA1 and WLS_SOA2 servers listen on specific floating IPs that are failed over by Oracle WebLogic Server.

Perform the steps in the following sections to configure server migration for the managed servers.

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

Set up a user and tablespace for the server migration leasing table using the create tablespace leasing command.

To set up a user and tablespace for the server migration leasing table:

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

    SQL> 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.

    SQL> create user leasing identified by welcome1;
    
    SQL> grant create table to leasing;
    
    SQL> grant create session to leasing;
    
    SQL> alter user leasing default tablespace leasing;
    
    SQL> 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:

      WL_HOME/server/db/oracle/817
      WL_HOME/server/db/oracle/920
      
    2. Connect to the database as the leasing user.

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

      SQL> @copy_location/leasing.ddl;
      

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

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.

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

  3. In the Domain 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:

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

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

    • 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:

      wcpedg.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:

      NAME                 TYPE        VALUE
       
      --------------------------------------------------
       
      remote_listener     string db-scan.mycompany.com:1521
      

      Note:

      For Oracle Database 11g R1 use the VIPs and ports of each database's instance listener, for example:

      custdbhost1-vip.mycompany.com (port 1521)
      

      and

      custdbhost2-vip.mycompany.com (1521)
      
    • Port - The port on which the database server listens for connection requests.

    • 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=wcpedg.us.oracle.com))) succeeded.
    

    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:

      [orcl@db-scan ~]$ srvctl config nodeapps -s
       
      ONS exists: Local port 6100, remote port 6200, EM port 2016
      
    • Click Next.

    Note:

    For Oracle Database 11g R1 use the hostnames and ports of each database's ONS service, for example:

    custdbhost1.mycompany.com (port 6200)
    

    and

    custdbhost2.mycompany.com (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 SOA_Cluster as the target, and All Servers in the cluster.

  12. Click Finish.

  13. Click Activate Changes.

14.4 Enabling Host Name Verification Certificates between SOAHOST1 and SOAHOST2 and the Administration Server

Create the appropriate certificates for host name verification between the Node Manager and the Administration Server. This procedure is described in Section 11.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1 and WCPHOST1" and Section 11.5, "Enabling Host Name Verification Certificates for the Node Manager in SOAHOST2 and WCPHOST2."

14.5 Editing the Node Manager's Properties File

Edit the Node Manager properties file on the two nodes where the servers are running. The nodemanager.properties file is located in the following directory:

WL_HOME/common/nodemanager 

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

Verify in the output of Node Manager (the shell where the Node Manager is started) that these properties are in use. Otherwise, problems may occur during migration. The output should be similar to the following:

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

Note:

The following steps are not required if the server properties (start properties) have been 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 Node 1 and Node 2 by running the startNodeManager.sh script, which is located in the WL_HOME/server/bin/ directory.

    Note:

    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 SOAHOSTn, use the Interface environment variable as follows: SOAHOSTn export JAVA_OPTIONS=-DInterface=eth3 and start Node Manager after the variable has been set in the shell.

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

Set the environment and superuser privileges for the wlsifconfig.sh script:

  1. Ensure that the PATH environment variable includes the files listed in Table 14-1:

    Table 14-1 Required Files for the PATH Environment Variable

    File Directory Location

    wlsifconfig.sh

    ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration
    

    wlscontrol.sh

    WL_HOME/common/bin
    

    nodemanager.domain

    WL_HOME/common/nodemanager
    

  2. Grant sudo configuration for the wlsifconfig.sh script.

    • Configure sudo to work without a password prompt.

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

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

      2. 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 ifconfig and arping:

        oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
        

    Note:

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

14.7 Configuring Server Migration Targets

Configure server migration targets. Configuring Cluster Migration sets the DataSourceForAutomaticMigration property to true.

To configure migration in a cluster:

  1. Log into the Oracle WebLogic Server Administration Console:.

    http://host:adminPort/console
    

    Typically, adminPort is 7001 by default.

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

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

  4. Click the Migration tab.

  5. Click Lock & Edit.

  6. In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select SOAHOST1 and SOAHOST2.

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

  8. Click Save.

  9. Click Activate Changes.

  10. Set the Candidate Machines for Server Migration. You must perform this task for all of the managed servers as follows:

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

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

    3. Click the Migration tab.

    4. In the Available field, located in the Migration Configuration section, select the machines to which to allow migration and click the right arrow. For WLS_SOA1, select SOAHOST2. For WLS_SOA2, select SOAHOST1.

    5. Select Automatic Server Migration Enabled and click Save.

      This enables the Node Manager to start a failed server on the target node automatically.

    6. Click Activate Changes.

    7. Restart the Administration Server and the servers for which server migration has been configured

      To restart the Administration Server, use the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

    Tip:

    Click Customize this table in the Summary of Servers page, move Current Machine from the Available Window to the Chosen window to view the machine on which the server is running. This will be different from the configuration if the server gets migrated automatically.

14.8 Testing Server Migration

To verify that Server Migration is working properly:

To test from Node 1:

  1. Stop the WLS_SOA1 managed server.

    kill -9 pid
    

    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_SOA1
    
  2. Watch the Node Manager console: you should see a message indicating that WLS_SOA1's floating IP has been disabled.

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

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

To test from Node 2:

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

  2. Access the soa-infra console in the same IP.

Verification From the Administration Console

You can also verify migration using the Administration Console:

  1. Log into the Administration Console.

  2. Click on Domain on the left console.

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

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

    Figure 14-1 Migration Status Screen in the Administration Console

    Description of Figure 14-1 follows
    Description of "Figure 14-1 Migration Status Screen in the Administration Console"

Note:

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.