Configuring server migration allows SOA 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 Fusion Middleware SOA Exalogic enterprise deployment.
This chapter contains the following steps:
Section 13.1, "Overview of Server Migration for an Exalogic Enterprise Deployment"
Section 13.2, "Setting Up a User and Tablespace for the Server Migration Leasing Table"
Section 13.5, "Setting Environment and Superuser Privileges for the wlsifconfig.sh Script"
Section 13.8, "Backing Up the Server Migration Configuration"
Configure server migration for the WLS_OSB1, WLS_SOA1, WLS_OSB2, and WLS_SOA2 Managed Servers. The WLS_OSB1 and WLS_SOA1 Managed Server are configured to restart on SOAHOST2 should a failure occur. The WLS_OSB2 and WLS_SOA2 Managed Servers are configured to restart on SOAHOST1 should a failure occur. The WLS_OSB1, WLS_SOA1, WLS_OSB2 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_OSB1, WLS_SOA1, WLS_OSB2, and WLS_SOA2 Managed Servers.
In this section, you set up a user and tablespace for the server migration leasing table:
Note:
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.
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;
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;
Create the leasing table using the leasing.ddl script:
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
Connect to the database as the leasing user.
Run the leasing.ddl script in SQL*Plus:
@Copy_Location/leasing.ddl;
After the tool completes, enter the following at the SQL*Plus prompt:
commit;
Use Appendix D, "Creating a GridLink Data Source." to create a GridLink data source for the Leasing table using the Oracle WebLogic Administration Console.
For the Leasing table data source, use the following names:
Datasource Name: leasing
JNDI Name: jdbc/leasing
Database User Name: Leasing
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, SOAHOST1 and SOAHOST2.
The nodemanager.properties file is located in the following directory:
WL_HOME/common/nodemanager
As interface, enter the EoIB and IPoIB interfaces that the SOA and OSB servers use for sever migration. Then enter the pertaining IP address ranges that will be controlled by server migration. Notice that this entry does not allow using hostnames but only IP addresses. Follow the IP addresses by the pertaining netmasks. For example:
bond0=soahost1-priv-v1-ip, soahost1-priv-v2-ip,NetMask=255.255.248.0
bond1=soahost1vhn1vip, soahost1vhn2vip,NetMask=255.255.248.0
Note:
Do not specify the sub-interface, such as bond0:1 or bond0: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 bond0, bond1, bond2, bond3, bondn, depending on the number of interfaces configured.
NetMask:
NetMask=255.255.248.0
This property specifies the net mask for the interface for the floating IP. The net mask should be the same as the net mask on the interface.
UseMACBroadcast:
UseMACBroadcast=true
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:
StateCheckInterval=500 bond0=*,NetMask=255.255.248.0 UseMACBroadcast=true
Note:
The following steps are not required if the server properties (start properties) have been properly set and Node Manager can start the servers remotely.
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.
Start Node Manager on SOAHOST1 and SOAHOST2 by running the startNodeManager.sh script, which is located in the following directory:
/u02/private/oracle/config/nodemanager
Set environment and superuser privileges for the wlsifconfig.sh script:
Ensure that your PATH environment variable includes the files listed inTable 13-1.
Table 13-1 Files Required for the PATH Environment Variable
| File | Located in this directory |
|---|---|
|
wlsifconfig.sh |
|
|
wlscontrol.sh |
|
|
nodemanager.domains |
|
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.
Note:
Ask the system administrator for the appropriate sudo and system rights to perform this step.
Grant sudo privilege to the WebLogic user oracle with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.
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
In this section, you configure server migration targets for soa_cluster and osb_cluster. Configuring Cluster Migration sets the DataSourceForAutomaticMigration property to true.
To configure migration in a cluster:
Log in to the Oracle WebLogic Server Administration Console at the URL listed in Section 8.18.2, "Validating Access through Oracle Traffic Director."
In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page is displayed.
Click the cluster name for which you want to configure migration in the Name column of the table.
Click the Migration tab.
Click Lock and Edit.
In the Available field, select the machines to which to allow migration, SOAHOST1 and SOAHOST2, and click the right arrow.
Select the data source to be used for automatic migration. In this case, select the leasing data source.
Click Save.
Click Activate Changes.
In the Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.
Select the server for which you want to configure migration.
Click the Migration tab.
Select Automatic Server Migration Enabled and click Save.
Click Activate Changes.
In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select SOAHOST1 and SOAHOST2.
Restart the managed servers for which server migration has been configured as described in Section 8.5.3, "Starting the Administration Server on SOAHOST1."
Note:
If migration is only going to be allowed to specific machines, do not specify candidates for the cluster, but rather specify candidates only on a server per server basis.
In this section, you test the server migration. For example, to test migration for OSB servers:
Stop the WLS_OSB1 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_OSB1
Watch the Node Manager console. You should see a message indicating that WLS_OSB1's floating IP has been disabled.
Wait for Node Manager to try a second restart of WLS_OSB1. It waits for a fence period of 30 seconds before trying this restart.
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.
Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_OSB1 on SOAHOST1, Node Manager on SOAHOST2 should prompt that the floating IP for WLS_OSB1 is being brought up and that the server is being restarted in this node.
Access the OSB Console using the Virtual Host Name, for example:
soahost1vhn1.mycompany.com/soa-infra/
Follow the previous steps to test server migration for the WLS_OSB2, WLS_SOA1, and WLS_SOA2 Managed Servers.
Table 13-2 shows the Managed Servers and the hosts they migrate to in case of a failure.
Table 13-2 Managed Server Migration
| Managed Server | Migrated From | Migrated To |
|---|---|---|
|
WLS_OSB1 |
SOAHOST1 |
SOAHOST2 |
|
WLS_OSB2 |
SOAHOST2 |
SOAHOST1 |
|
WLS_SOA1 |
SOAHOST1 |
SOAHOST2 |
|
WLS_SOA2 |
SOAHOST2 |
SOAHOST1 |
Verification From the Administration Console
Migration can also be verified in the Administration Console:
Log in to the Administration Console.
Click Domain on the left console.
Click the Monitoring tab and then the Migration sub tab.
The Migration Status table provides information on the status of the migration.
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.
Back up the server migration configuration. For more information, see Section 14.8, "Backing Up the Oracle SOA Enterprise Deployment."