| Oracle® Fusion Applications Enterprise Deployment Guide for Financials 11g Release 6 (11.1.6) Part Number E27364-09 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Enterprise Deployment Guide for Financials 11g Release 6 (11.1.6) Part Number E27364-09 |
|
|
PDF · Mobi · ePub |
This chapter describes how to configure server migration according to enterprise deployment recommendations.
This chapter includes the following topic:
Before migrating Oracle Fusion Applications domains, ensure you have completed the steps in Section 16.1, "Enabling Virtual IPs on FINHOST1 and FINHOST2," Section 16.2, "Setting the Listen Address for soa_server1," and Section 16.3, "Setting the Listen Address for soa_server2" for all Managed Servers needing to be migrated.
Note:
This prerequisite does not apply to the Oracle Business Intelligence domain.
The procedures in this section apply to these domains and applications:
Oracle SOA Suite in the Oracle Fusion Financials domain
Oracle SOA Suite and Oracle WebCenter Content: Imaging in the Oracle Fusion Common domain
Oracle SOA Suite in the Oracle Business Intelligence domain
Oracle SOA Suite in the Oracle Fusion Human Capital Management domain
Oracle SOA Suite in the Oracle Fusion Supply Chain Management domain
Oracle SOA Suite in the Oracle Fusion Projects domain
Oracle SOA Suite in the Oracle Fusion Procurement domain
The procedures described in this chapter must be performed for various components of the enterprise deployment topology outlined in Variables are used in this chapter to distinguish between component-specific items:
The procedures described in this chapter must be performed for various components of the enterprise deployment topology outlined in Section 2.1, "Overview of Reference Enterprise Deployment Topologies." Variables are used in this chapter to distinguish between component-specific items:
WLS_SERVER1 and WLS_SERVER2 refer to the managed WebLogic servers for the enterprise deployment component
FINHOST1 and FINHOST2 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 to these variables are provided in the component-specific chapters in this guide.
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 FINHOST2 should a failure occur. The WLS_SERVER2 Managed Server is configured to restart on FINHOST1 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. Configuring server migration for the WLS Managed Servers consists of the following steps:
The first step is to 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 will have to be retargeted to the cluster being configured with server migration.
To set up a user and tablespace:
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;
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;
Create the leasing table using the leasing.ddl script:
Copy the leasing.ddl file located in either the ORACLE_BASE/products/fusionapps/wlserver_10.3/server/db/oracle/817 or the ORACLE_BASE/products/fusionapps/wlserver_10.3/server/db/oracle/920 directory to your database node.
Connect to the database as the leasing user.
Run the leasing.ddl script in SQL*Plus:
SQL> @Copy_Location/leasing.ddl;
The second step is to create a multi-data source for the leasing table from the Oracle WebLogic Server Administration Console. You create a data source to each of the Oracle RAC database instances during the process of setting up the multi-data source, both for these data sources and the global leasing multi-data source.
Please note the following considerations when creating a data source:
Make sure that this is a non-XA data source.
The names of the multi-data sources are in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.
Use Supports Global Transactions, One-Phase Commit, and specify a service name for your database.
Target these data sources to the cluster assigned to the enterprise deployment component (CLUSTER; see the component-specific chapters in this guide).
Creating a Multi-Data Source
To create a multi-data source:
In the Domain Structure window in the Oracle WebLogic Server Administration Console, click the Data Sources link.
Click Lock & Edit.
Select Multi Data Source from the New dropdown menu.
The Create a New JDBC Multi Data Source page is displayed.
Enter leasing as the name.
Enter jdbc/leasing as the JNDI name.
Select Failover as algorithm (default).
Click Next.
Select the cluster that must be migrated. In this case, SOA cluster.
Click Next.
Select non-XA driver (the default).
Click Next.
Click Create a New Data Source.
Enter leasing-rac0 as the name. Enter jdbc/leasing-rac0 as the JNDI name. Enter oracle as the database type. For the driver type, select Oracle Driver (Thin) for Oracle RAC Service-Instance connections, Versions 10 and later.
Note:
When creating the multi-data sources for the leasing table, enter names in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Click Next.
Deselect Supports Global Transactions.
Click Next.
Enter the following for your leasing schema:
Service Name: The service name of the database.
Database Name: The Instance Name for the first instance of the Oracle RAC database.
Host Name: The name of the node that is running the database. For the Oracle RAC database, specify the first instance's VIP name or the node name as the host name.
Port: The port number for the database (1521).
Database User Name: Enter leasing.
Password: The leasing password.
Click Next.
Click Test Configuration and verify that the connection works.
Click Next.
Target the data source to the cluster assigned to the enterprise deployment component (CLUSTER).
Click Finish.
Click Create a New Data Source for the second instance of your Oracle RAC database, target it to the cluster assigned to the enterprise deployment component (CLUSTER), repeating the steps for the second instance of your Oracle RAC database.
Add leasing -rac0 and leasing -rac1 to your multi-data source.
Make sure the initial connection pool capacity of the data sources is set to 0 (zero). In the Datasources screen do the following:
Select Services, then select Datasources.
Click Datasource Name, then click the Connection Pool tab.
Enter 0 (zero) in the Initial Capacity field.
Click Save, then click Activate Changes.
The third step is to edit Node Manager's properties file, which is located at:
ORACLE_BASE/config/nodemanager/FINHOST1 ORACLE_BASE/config/nodemanager/FINHOST2
This must be done for the node managers in both nodes where server migration is being configured. For example:
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 steps below are 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.
Restart Node Manager on FINHOST1 and FINHOST2 by running the startNodeManagerWrapper.sh script, which is located in the ORACLE_BASE/config/nodemanager/FINHOST1 and ORACLE_BASE/config/nodemanager/FINHOST2 directories.
The fourth step is to set environment and superuser privileges for the wlsifconfig.sh script:
Ensure that your PATH is set with the environment variables in the terminal from where Node Manager is started, and that it includes these files:
Table 18-1 Files Required for the PATH Environment Variable
| File | Located in this directory |
|---|---|
|
wlsifconfig.sh |
|
|
wlscontrol.sh |
|
|
nodemanager.domains |
|
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, perform these steps to set the environment and superuser privileges for the wlsifconfig.sh script:
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:
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
Note:
Ask the system administrator for the sudo and system rights as appropriate to this step.
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.
Enterprise deployment recommends using cluster-based migration. Perform the following steps, including a step to enable automatic server migration (Step 10), to configure cluster-based migration for all Managed Servers in a cluster:
Log in to the Oracle WebLogic Server Administration Console. For example, http://fininternal.mycompany.com:7777/console
In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page is displayed.
Click the cluster for which you want to configure migration (CLUSTER) in the Name column of the table.
Click the Migration tab.
Click Lock & Edit.
In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select FINHOST1 and FINHOST2.
Note:
When there are three (3) hosts, for example FINHOST1, FINHOST2, and FINHOST3, select all three hosts.
Select the data source to be used for automatic migration. In this case, select the leasing data source.
Click Save.
Click Activate Changes.
Enable automatic server migration for all Managed Servers in the cluster. (You must perform this task for all of the Managed Servers.)
Note:
Although you are using cluster-based migration for the Managed Servers, you must perform this step (from the Migration tab) to enable automatic server migration for all the Managed Servers in the selected cluster.
In the Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.
Tip:
Click Customize this table in the Summary of Servers page and 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.
Select the server for which you want to configure cluster-based migration.
Click the Migration tab, and then click Lock & Edit.
Select Automatic Server Migration Enabled. This enables Node Manager to start a failed server on the target node automatically.
Click Save.
Click Activate Changes.
Restart the administration server, node managers, and the servers for which server migration has been configured.
The sixth and final step is to test the server migration. Perform these steps to verify that server migration is working properly:
From FINHOST1:
Stop the WLS_SERVER1 Managed Server. To do this, run this command:
FINHOST1> 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:
FINHOST1> ps -ef | grep WLS_SERVER1 | grep DomainName_SOACluster
Watch the Node Manager console. You should see a message indicating that WLS_SERVER1's floating IP has been disabled.
Wait for Node Manager to try a second restart of WLS_SERVER1. It waits for a fence period of 10 seconds before trying this restart.
After Node Manager restarts the server, stop it few times. Node Manager should now log a message indicating that the server will not be restarted again locally.
From FINHOST2:
Watch the local Node Manager console. Ten (10) seconds after the last try to restart WLS_SERVER1 on FINHOST1>, Node Manager on FINHOST2> should prompt that the floating IP for WLS_SERVER1 is being brought up and that the server is being restarted in this node.
As an example, for Oracle SOA Suite Managed Servers, access the soa-infra console in the same IP.
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 subtab.
The Migration Status table, shown in Figure 18-1, provides information on the status of the migration.
Note:
To complete server migration in a cluster, perform the same steps on the second, third, and so on, managed servers.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
