14 Configuring Server Migration for an Enterprise Deployment

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

This chapter contains the following sections:

• Section 14.1, "Overview of Server Migration for an Enterprise Deployment"

• Section 14.2, "Setting Up a User and Tablespace for the Server Migration leasing Table"

• Section 14.3, "Creating a GridLink Data Source for leasing Using the Administration Console"

• Section 14.4, "Editing Node Manager's Properties File"

• Section 14.5, "Setting Environment and Superuser Privileges for the wlsifconfig.sh Script"

• Section 14.6, "Configuring Server Migration Targets"

• Section 14.7, "Testing the Server Migration"

14.1 Overview of Server Migration for an Enterprise Deployment

You can configure server migration for Oracle WebLogic Server Managed Servers. With server migration configured, should failure occur, each Managed Server can restart on a different host machine. The Managed Servers listen on specific floating IPs that are failed over by WebLogic Server.

Note:

Refer to each component's chapter for details on whether it uses or requires server migration or not.

The procedures described in this chapter must be performed for various components of the enterprise deployment topology outlined in Section 2.1.1, "Reference Topology Documented in the Guide." Variables are used in this chapter to distinguish between component-specific items:

• WLS_SERVER1 and WLS_SERVER2 refer to the WebLogic Server Managed Servers for the enterprise deployment component.

• HOST1 and HOST2 refer to the host machines for the enterprise deployment component.

• CLUSTER refers to the cluster associated with the enterprise deployment component.

The values to be used for these variables are provided in the component-specific chapters in this EDG.

In this enterprise topology, you must configure server migration for the WLS_SERVER1 and WLS_SERVER2 Managed Servers. The WLS_SERVER1 Managed Server is configured to restart on HOST2 should a failure occur. The WLS_SERVER2 Managed Server is configured to restart on HOST1 should a failure occur. For this configuration, the WLS_SERVER1 and WLS_SERVER2 servers listen on specific floating IP addresses that are failed over by WebLogic Server migration.

Table 14-1 describes the steps for configuring server migration for the WebLogic Server Managed Servers.

Table 14-1 Steps for Configuring Server Migration

Step	Description	More Information
Set up a user, tablespace, and migration table	Create a leasing tablespace, user, and table for server migration.	Section 14.2, "Setting Up a User and Tablespace for the Server Migration leasing Table"
Create GridLink data sources for the leasing table	Create a data source for each of the Oracle RAC database instances and the global leasing GridLink data source in the Administration Console.	Section 14.3, "Creating a GridLink Data Source for leasing Using the Administration Console"
Specify Node Manager properties values for migration	Edit the property values in the nodemanager.properties file for each host, and verify the values.	Section 14.4, "Editing Node Manager's Properties File"
Set the environment and specify superuser privileges for the oracle user	Add files to the PATH environment variable, and grant the sudo privilege for the wlsifconfig.sh script.	Section 14.5, "Setting Environment and Superuser Privileges for the wlsifconfig.sh Script"
Configure cluster migration	Assign available nodes as migration targets, and specify candidate machines for each server.	Section 14.6, "Configuring Server Migration Targets"
Test server migration	Verify server migration between hosts from Node Manager or the Administration Console.	Section 14.7, "Testing the Server Migration"

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.

Note:

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

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

1. Create a tablespace called leasing. For example, log in 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;
   

   Note:

   The database file location will vary depending on the type of storage and data file location used for the database.

2. Create a user named leasing, and assign to it the leasing tablespace:

   SQL> create user leasing identified by password;
   
   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 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 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, select GridLink Data Source, and do 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, clear 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:

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

     SQL>show parameter remote_listener;
     
     NAME                 TYPE        VALUE
      
     --------------------------------------------------
      
     remote_listener     string      db-scan.mycompany.com
     

     Note:

     For Oracle Database 11g Release 1 (11.1), use the virtual IP and port of each database instance listener; for example:

     custdbhost1-vip.mycompany.com (port 1521) 
     

     and

     custdbhost2-vip.mycompany.com (1521)
     

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

   • Port - The port on which the database server listens for connection requests.

   • Database User Name: leasing

   • Password: Enter the password for the leasing user.

   • 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=wccedg.mycompany.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 follows) and click ADD:

     [orcl@db-scan1 ~]$ srvctl config nodeapps -s
      
     ONS exists: Local port 6100, remote port 6200, EM port 2016
     

   • Click Next.

   Note:

   For Oracle Database 11g Release 1 (11.1), use the host name and port 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 the targets for which you are doing server migration, IMG_Cluster and SOA_Cluster, and All Servers in the cluster.

12. Click Finish.

13. Click Activate Changes.

14.4 Editing Node Manager's Properties File

The third step is to edit Node Manager's properties file. This needs to be done for the Node Managers in both nodes where server migration is being configured:

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

• 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; 255.255.255.0 is used as an example in this document.

• UseMACBroadcast: This property specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not 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:

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

Note:

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

• Set the following property in the nodemanager.properties file:

  StartScriptEnabled: Set this property to true. This is required for Node Manager to start the Managed Servers using start scripts.

Note:

When you run 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

Start Node Manager after the variable has been set in the shell.

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

The fourth step is to set environment and superuser privileges for the wlsifconfig.sh script (for the oracle user):

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

   Table 14-2 Files Required for the PATH Environment Variable

   File	Located in This Directory
   wlsifconfig.sh	ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration/
   wlscontrol.sh	WL_HOME/common/bin/
   nodemanager.domains	WL_HOME/common/nodemanager/

   
   

2. Grant the sudo privilege 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, perform these steps to set the environment and superuser privileges for the wlsifconfig.sh script:

     1. Grant the sudo privilege to the WebLogic Server 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 Server user (oracle). The following is an example of an entry inside /etc/sudoers granting the sudo execution privilege for oracle and also over ifconfig and arping:

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

   Note:

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

3. Start Node Manager on HOST1 and HOST2 by running the startNodeManager.sh script, which is located in the WL_HOME/server/bin/ directory.

14.6 Configuring Server Migration Targets

The fifth step is to configure server migration targets. You first assign all the available nodes for the cluster's members and then specify candidate machines (in order of preference) for each server that is configured with server migration. Follow these steps to configure cluster migration in a migration in a cluster:

1. Log in to the WebLogic Server Administration Console (http://Host:Admin_Port/console). Typically, Admin_Port is 7001 by default.

2. In the Domain Structure tree on the left, expand Environment and select Clusters.

3. On the Summary of Clusters page, click the cluster for which you want to configure migration (CLUSTER) in the Name column of the table.

   Note:

   For the procedures in this document, configure server migration for the Oracle SOA Suite and Imaging clusters.

4. Open 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 HOST1 and HOST2.

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. Click Lock & Edit.

11. Set the candidate machines for server migration. You must perform this task for all of the Managed Servers as follows:

    1. In the Domain Structure tree on the left of the WebLogic Server Administration Console, expand Environment and select Servers.

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

       Note:

       For the procedures in this document, configure server migration for the Oracle SOA Suite and Imaging servers.

    3. Open 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_SERVER1, select HOST2. For WLS_SERVER2, select HOST1.

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

    6. Click Save.

    7. Click Activate Changes.

    8. Restart the Administration Server, node managers, and the servers for which server migration has been configured.

14.7 Testing the Server Migration

The sixth and final step is to test the server migration. To verify that server migration is working properly:

From HOST1:

1. Stop the WLS_SERVER1 Managed Server. To do this, run this command on HOST1:

   kill -9 pid
   

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

   ps -ef | grep WLS_SERVER1
   

2. Watch the Node Manager console. You should see a message indicating that WLS_SERVER1's floating IP has been disabled.

3. Wait for Node Manager to try a second restart of WLS_SERVER1. 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.

From HOST2:

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

2. Access your server's console in the same IP.

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.

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

   Figure 14-1 Migration Status Screen in the Administration Console

   
   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 or machine, stop the Managed Server from the WebLogic Server Administration Console and then start it again. The appropriate Node Manager will start the Managed Server on the machine to which it was originally assigned.