Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1) Part Number E12036-08 |
|
|
PDF · Mobi · ePub |
This chapter describes the procedures for extending the domain to include Oracle Business Activity Monitoring (BAM).
This chapter contains the following sections:
Section 12.4, "Running the Configuration Wizard to Extend the Domain"
Section 12.5, "Configuring a Default Persistence Store for Transaction Recovery"
Section 12.6, "Untargeting the BAM Server System from WLS_BAM2"
Section 12.7, "Propagating the Domain Changes to the Managed Server Domain Directory"
Section 12.8, "Disabling Host Name Verification for the WLS_BAMn Managed Servers"
Section 12.9, "Starting Node Manager on BAMHOST1 and BAMHOST2"
Section 12.11, "Configuring the BAM Web Applications to Use the BAM Server in BAMHOST1"
Section 12.12, "Configuring Oracle HTTP Server for the WLS_BAMn Managed Servers"
Section 12.13, "Validating Access Through Oracle HTTP Server"
Section 12.14, "Configuring Server Migration for the WLS_BAM1 Server"
Section 12.15, "Applying Configuration Changes BAM components in a BAM Cluster"
The BAM system is installed using the WL_HOME and ORACLE_HOME created in Chapter 8, "Creating a Domain for an Enterprise Deployment" on a shared storage. BAMHOST1 and BAMHOST2 mount MW_HOME
and reuse the existing WLS and SOA installations. The pack
and unpack
utilities are used to bootstrap the domain configuration for the WLS_BAM1 and WLS_BAM2 servers in these two new nodes. As a result, you do not need to install any software in these two nodes. For the BAM system to work properly, BAMHOST1 and BAMHOST2 must maintain the same system configuration that was required for installing Oracle FMW in SOAHOST1 and SOAHOST2. Otherwise, unpredictable behavior in the execution of binaries may occur.
Before performing the steps in this section review the following prerequisites:
Back up the existing installation
If you have not yet backed up the existing Fusion Middleware Home and domain, back it up now.
To back up the existing Fusion Middleware Home and domain:
tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name
These commands create a backup of the installation files for both Oracle WebLogic Server and Oracle Fusion Middleware, as well as the domain configuration.
Attach the existing Oracle Homes to the Inventory in the BAMHOSTS
On the new node, mount the existing FMW Home, which should include the SOA installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach an ORACLE_HOME in shared storage to the local Oracle Inventory, use the following command on the BAMHOST:
cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_version
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the $HOME/bea/beahomelist
file and add MW_HOME to it.
The BAM System uses a virtual hostname as the listen addresses for the managed server hosting the BAM Server component. This virtual host name and corresponding virtual IP is required to enable server migration for the BAM Server component. Enable a VIP (VIP4) mapping BAMHOST1VHN1 on BAMHOST1 and correctly resolve the BAMHOST1VHN1 hostname in the network system used by the topology (either by DNS Server, hosts resolution).
To enable the virtual IP on Linux:
Run the ifconfig
command as root:
/sbin/ifconfig <interface:index> IPAddress netmask netmask /sbin/arping -q -U -c 3 -I interface IPAddress
For example:
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
Enable your network to register the new location of the virtual IP, for example:
/sbin/arping -q -U -c 3 -I ethX 100.200.140.206
Validate that the address is available by pinging it from another node, for example:
/bin/ping 100.200.140.206
In this example 'ethX' is the ethernet interface (eth0 or eth1) and Y is the index (0, 1, 2,).
About Accessing an Oracle BAM Server Using the BAM Adapter
When accessing an Oracle BAM Server using the BAM Adapter (rmi), use the Virtual Hostname of the BAM Server (BAMHOST1VNH1) for the connection. SOAP requests come through HTTP, therefore, use the load balancer addresses when using the adapter.
In this step, you extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment" to contain BAM. The instructions in this section assume that the BAM deployment uses the same database service (soaedg.mycompany.com
) as the SOA deployment. However, you may choose to use a different database service specifically for BAM.
Change directory to the location of the Configuration Wizard. This is within the SOA home directory.
cd ORACLE_COMMON_HOME/common/bin
Start the Configuration Wizard:
./config.sh
In the Welcome screen, select Extend an existing WebLogic domain, and click Next.
In the WebLogic Domain Directory screen, select the following WebLogic domain directory:
ORACLE_BASE/admin/domain_name/aserver/domain_name
Click Next.
In the Select Extension Source screen, do the following:
Select Extend my domain automatically to support the following added products.
Select the following products:
Oracle Business Activity Monitoring 11.1.1.0
Click Next.
In the Configure JDBC Component Schema screen (Figure 12-1), do the following:
Select BAM Schema.
Select Configure selected component schemas as RAC multi data source schemas in the next panel.
Click Next.
Figure 12-1 Configure JDBC Component Schema Screen
In the Configure RAC Multi Data Sources Component Schema screen (Figure 12-2), do the following:
Select BAM Schema. Leave the other data sources as they are.
Enter values for the following fields, specifying the connect information for the Oracle RAC database that was seeded with RCU.
Driver: Select Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11.
Service Name: Enter the service name of the database; for example, soaedg.mycompany.com
.
Username: Enter the complete user name (including prefix) for the schemas. The user names shown in Figure 12-2 assume that soedg
was used as prefix for schema creation from RCU.
Password: Enter the password to use to access the schemas.
Click Add and enter the details for the first Oracle RAC instance.
Repeat for each Oracle RAC instance.
Note:
Leave the SOA Infrastructure, User Messaging Service, OWSM MDS, and SOA MDS Schema information as it is.
Click Next.
Figure 12-2 Configure Multi Data Source Component Schema Screen
In the Test JDBC Data Sources screen, the connections should be tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.
Click Next when all the connections are successful.
In the Select Optional Configuration screen, select the following:
Managed Servers, Clusters, and Machines
Deployments and Services
JMS File Store
Click Next.
In the Select JMS Distributed Destination Type screen, select UDD from the drop-down list for all Fusion Middleware Components' JMS Modules.
Note:
Oracle does not support using WDDs for Fusion Middleware components.
In the Configure Managed Servers screen, add the required managed servers.
A server called bam_server1 is created automatically. Rename this to WLS_BAM1 and add a new server called WLS_BAM2. Give these servers the attributes listed in Table 12-1. Do not modify the other servers that appear in this screen; leave them as they are.
Table 12-1 Managed Servers
Name | Listen Address | Listen Port | SSL Listen Port | SSL Enabled |
---|---|---|---|---|
WLS_BAM1 |
BAMHOST1VHN1 |
9001 |
n/a |
No |
WLS_BAM2 |
BAMHOST2 |
9001 |
n/a |
No |
Click Next.
In the Configure Clusters screen, add the following clusters listed in Table 12-2. Do not modify the other clusters that display in this screen; leave them as they are.
Table 12-2 Clusters
Name | Cluster Messaging Mode | Multicast Address | Multicast Port | Cluster Address |
---|---|---|---|---|
BAM_Cluster |
unicast |
n/a |
n/a |
Leave it empty. |
Click Next.
In the Assign Servers to Clusters screen, add the following. Do not modify the other assignments that display in this screen; leave them as they are.
BAM_Cluster
WLS_BAM1
WLS_BAM2
Click Next.
In the Configure Machines screen, do the following:
Delete the LocalMachine that appears by default.
Click the Unix Machine tab. You should add the BAMHOST1 and BAMHOST2 machines and have the following entries:
Leave all other fields to their default values.
Click Next.
In the Assign Servers to Machines screen, do the following:
Assign WLS_BAM1 to BAMHOST1
Assign WLS_BAM2 to BAMHOST2.
Click Next.
In the Target Deployments to Clusters or Servers screen, ensure the following targets:
usermessagingserver and usermessagingdriver-email should be targeted only to SOA_Cluster and BAM_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)
WSM-PM should be targeted only to WSM-PM_Cluster.
The DMS Application should be targeted to BAM_Cluster, SOA_Cluster, WSM-PM_Cluster and Admin Server.
Target the oracle.sdp.* library only to SOA_Cluster and BAM_Cluster. Target the oracle.soa.* library only to SOA_Cluster.
Target the oracle.rules.* library to SOA_Cluster, BAM_Cluster and Admin Server.
The oracle.wsm.seedpolicies library should be targeted only to the WSM-PM_Cluster.
Target this library to the SOA_Cluster or BAM_Cluster also, only if you are planning to deploy WebLogic WebServices to them.
oracle.bam* is targeted only to BAM_Cluster.
Click Next.
In the Target Services to Clusters or Servers screen, ensure the following targets:
mds-owsm, mds-owsm-rac0, and mds-owsm-rac1 should be targeted to both WSM-PM_Cluster and AdminServer.
mds-soa, mds-soa-rac0, and mds-soa-rac1 should be targeted to both SOA_Cluster and AdminServer.
OraSDPMDatasource, OraSDPMDatasource-rac0, and OraSDPMDatasource-rac1 should be targeted to both SOA_Cluster and BAM_Cluster.
Click Next.
In the Configuration Summary screen, click Extend.
In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores as recommended in Section 4.3, "About Recommended Locations for the Different Directories." For example:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
Click OK in the warning dialog about conflicts in ports for the domain.
In the Creating Domain screen, click Done.
Restart the Administration Server using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."
Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to the server.
Note:
The recommended location is a dual-ported SCSI disk or on a Storage Area Network (SAN)
To set the location for the default persistence store for WLS_BAM1:
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page appears.
Click WLS_BAM1 (represented as a hyperlink) in the Name column of the table. The settings page for the WLS_BAM1 server appears and defaults to the Configuration tab.
Click the Services sub-tab.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:
ORACLE_BASE/admin/domain_name/bam_cluster_name/tlogs
Click Save.
Note:
To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both BAMHOST1 and BAMHOST2 must be able to access this directory. This directory must also exist before you restart the server.
Because the BAM server component in BAM is a singleton, you must untarget it from one of the WLS_BAM servers before you configure it for server migration.
In this step, you remove the BAM server runtime from WLS_BAM2.
To untarget the BAM server artifacts from WLS_BAM2:
Log into the Oracle WebLogic Administration Console at http://ADMINVHN:7001/console
.
In the Domain Structure window, choose Environment and then Servers. The Summary of Servers page appears.
Select WLS_BAM2 in Name column of the table. The Settings page for WLS_BAM2 appears.
Click the Deployments tab.
Select the oracle-bam application from the Name column of the table. The Settings page for the oracle-bam application appears.
Click the Targets tab.
Click Lock & Edit.
Change the targets for the modules as described in Table 12-4. You must change all of these components, as incorrect targeting can prevent the BAM system from starting.
Table 12-4 oracle-bam Component Target Types
Component | Type | Target |
---|---|---|
oracle-bam(11.1.1) |
Enterprise Application |
BAM_Cluster |
/oracle/bam |
WEBAPP |
WLS_BAM1 |
oracle-bam-adc-ejb.jar |
EJB |
WLS_BAM1 |
oracle-bam-ems-ejb.jar |
EJB |
WLS_BAM1 |
oracle-bam-eventengine-ejb.jar |
EJB |
WLS_BAM1 |
oracle-bam-reportcache-ejb.jar |
EJB |
WLS_BAM1 |
OracleBAM |
WEBAPP |
BAM_Cluster |
OracleBAMWS |
WEBAPP |
BAM_Cluster |
oracle-bam-statuslistener-ejb.jar |
EJB |
WLS_BAM1 |
sdpmessagingclient-ejb.jar |
EJB |
WLS_BAM1 |
Click Save and Activate Changes.
Propagate the domain configuration to BAMHOST1 and BAMHOST2 using the pack/unpack utility.
To propagate the new domain configuration:
Make sure that a similar directory and shared storage configuration as SOAHOST2 is present in BAMHOST1 (described in Chapter 3, "Preparing the Network for an Enterprise Deployment"). BAMHOST1 and BAMHOST2 should have mounted the MW_HOME
directory as created in Chapter 8, "Creating a Domain for an Enterprise Deployment."
Run the pack
command on SOAHOST1 to create a template pack:
Run the following command:
cd ORACLE_COMMON_HOME/common/bin
Note:
Notice that this directory is available as mount point to the MW_HOME created in Chapter 8, "Creating a Domain for an Enterprise Deployment."
Run the pack command:
./pack.sh -managed=true -domain=ORACLE_BASE/admin/ domain_name/aserver/domain_name -template=soadomaintemplateExtBPM.jar -template_name=soa_domain_templateExtBPM
Run the following command on SOAHOST1 to copy the template file created in the previous step to BAMHOST1.
scp soadomaintemplateBAM.jar
oracle@BAMHOST1:/ORACLE_COMMON_HOME/common/bin
Run the unpack
command on BAMHOST1 to unpack the template in the managed server domain directory as follows:
BAMHOST1> cd ORACLE_COMMON_HOME/common/bin BAMHOST1> ./unpack.sh -domain= ORACLE_BASE/admin/ domain_name/mserver/domain_name -template=soadomaintemplateBAM.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Run the copy and unpack commands for BAMHOST2.
Note:
The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.
For the enterprise deployment described in this guide, you set up the appropriate certificates to authenticate the different nodes with the Administration Server after you have completed the procedures to extend the domain for Oracle BPM. Therefore, you must disable the host name verification for the WLS_SOAn managed server to avoid errors when managing the different WebLogic Servers. You enable host name verification again once the Enterprise Deployment topology configuration is complete. See Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1" for more information.
To disable host name verification:
Log in to Oracle WebLogic Server Administration Console.
In the Administration Console, select WLS_BAM1, then SSL, and then Advanced.
Set Hostname Verification to None.
In the Administration Console, select WLS_BAM2, then SSL, and then Advanced.
Save and activate the changes.
Start Node manager using the setNMProps.sh
script.
To start Node Manager on BAMHOST1 and BAMHOST2:
On each server, run the setNMProps.sh
script, which is located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled
property to 'true' before starting Node Manager:
BAMHOSTn> cd ORACLE_COMMON_HOME/common/bin
BAMHOSTn> ./setNMProps.sh
Note:
Use the StartScriptEnabled
property to avoid class loading failures and other problems. For more information about StartScriptEnabled
, see Section 16.13.5, "Incomplete Policy Migration After Failed Restart of SOA Server."
Note:
If the BAM server is sharing the MW_HOME in a local or shared storage with SOA, as suggested in the shared storage configuration described in Chapter 3, "Preparing the Network for an Enterprise Deployment," it is not required to run setNMProps.sh
again. In this case, Node Manager has already been configured to use a startscript.
Run the following commands to start Node Manager on BAMHOST1:
BAMHOST1> cd WL_HOME/server/bin
BAMHOST1> ./startNodeManager.sh
Run the following commands to start Node Manager on BAMHOST2:
BAMHOST2> cd WL_HOME/server/bin
BAMHOST2> ./startNodeManager.sh
Start the WLS_BAM1 managed server using the Oracle WebLogic Server Administration Console.
These instructions are based on the assumption that the host name verification displayed previously for the WS-M or SOA managed servers in SOAHOST2 and that the Node Manager is already running on SOAHOST2.
To start the WLS_BAM1 managed server on BAMHOST1:
Start the WLS_BAM1 managed servers:
Log into the Oracle WebLogic Server Administration Console at http://ADMINVHN:7001/console
.
In the Domain Structure window, expand the Environment node and then select Servers. The Summary of Servers page appears.
Click the Control tab.
Select WLS_BAM1 from the Servers column of the table.
Click Start.
Access http://BAMHOST1VHN1:9001/OracleBAM
to verify status of WLS_BAM1.
If the managed server fails to start with the following message:
Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was <db_connect_string>
Verify that the PROCESSES
initialization parameter for the database is set to a high enough value. See Section 5.2.3, "About Initialization Parameters" for details. This error often occurs when you start servers that are subsequent the first server.
Start the WLS_BAM2 managed servers:
Log into the Oracle WebLogic Administration Console at http://ADMINVHN:7001/console
.
In the Domain Structure window, expand the Environment node and then select Servers. The Summary of Servers page appears.
Click the Control tab.
Select WLS_BAM2 from the Servers column of the table.
Click Start.
Access http://BAMHOST2:9001/OracleBAM
to verify status of WLS_BAM2.
To configure the OracleBamWeb(WLS_BAM1) and OracleBamWeb(WLS_BAM2) applications to use the BAM server in BAMHOST1:
Access Oracle Enterprise Manager Fusion Middleware Control through http://ADMINVHN:7001/em
.
Expand BAM in the navigation tree.
Right-click OracleBamWeb(WLS_BAM1).
Choose BAM Web Properties from the context menu. The BAM Web Properties page appears.
Define the following properties:
Enter https://soa.mycompany.com:443 for the application URL.
Enter BAMHOST1VHN1 for the server name. See also Table 3-1 in Section 3.4, "About IPs and Virtual IPs."
Modify the listening port of the server using the Mbean browser:
Log into the Oracle Enterprise Manager Fusion Middleware Control.
Expand the domain name in the left navigation tree.
Expand the BAM item in the left navigation tree.
In the BAM drop-down menu on the top-right, select Mbean Browser.
Navigate to the oracle.bam.web, Server, Application, Config, and then BAMWebConfig, on the right.
In the ServerPort field, replace the "DEFAULT" value with 9001.
Click Apply.
Select OracleBamWeb(WLS_BAM2) from the navigation tree and repeat steps 3 through 5.
To enable Oracle HTTP Server to route to BAM_Cluster, which contains the WLS_BAMn managed servers, you must set the WebLogicCluster
parameter to the list of nodes in the cluster as follows:
The servers specified in the WebLogicCluster
parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. The listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.
Sample scenarios:
Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered on the fly at runtime.
Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.
If you list all members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started.
For more information on configuring the WebLogic Server plug-in, see the Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server guide.
To enable Oracle HTTP Server to route to the SOA_Cluster:
Add the following lines to the ORACLE_BASE/admin/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.conf
file:
# BAM Web Application <Location /OracleBAM > SetHandler weblogic-handler WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /OracleBAMWS > SetHandler weblogic-handler WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001 WLProxySSL ON WLProxySSLPassThrough ON </Location>
Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2 as follows:
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
Verify URLs to ensure that appropriate routing and failover is working from the HTTP Server to the BAM_Cluster.
To verify the URLs:
While WLS_BAM2 is running, stop WLS_BAM1 using the Oracle WebLogic Server Administration Console.
Access WebHost1:7777/OracleBAM
to verify the appropriate functionality. You can not retrieve reports or data at this point since the BAM server is down.
Start WLS_BAM1 from the Oracle WebLogic Server Administration Console.
Stop WLS_BAM2 from the Oracle WebLogic Server Administration Console.
Access WebHost1:7777/OracleBAM
to verify the appropriate functionality.
The high-availability architecture for BAM uses server migration to protect the BAM server singleton service against failures. The WLS_BAM1 managed server is configured so that it can be restarted on BAMHOST2 if it fails. For this configuration, WLS_BAM1 listens on a specific, floating IP address that is failed over by WebLogic Server migration. To configure server migration for the WLS_BAM1 managed servers, complete the following tasks:
Step 1: Setting Up the User and Tablespace for the Server Migration Leasing Table
Step 2: Creating a Multi-Data Source Using the WebLogic Server Administration Console
Step 4: Setting Environment and Superuser Privileges for the wlsifconfig.sh Script
Step 5: Enabling Host Name Verification for Node Manager in the BAMHOSTn Nodes and the Administration Server
Step 7: Testing Server Migration
Note:
If server migration was configured previously for SOA, the BAM stem can use the same data sources and database schemas. In that case, steps 1 through 4 are not required, but you must target the corresponding server-migration/leasing datasources to the BAM Cluster.
To create the 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 it to the leasing tablespace as follows:
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;
Create the leasing table using the leasing.dll
script as follows:
Copy the leasing.ddl file located in the WL_HOME/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 as follows:
SQL> @copy_location/leasing.ddl;
Use the Oracle WebLogic Server Administration Console to create a multi-data source for the leasing table. 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 for the global leasing multi-data source. When you create this data source:
Ensure that it 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
Data sources do not require support for global transactions. Therefore, do not use any type of distributed transaction emulation/participation algorithm for the data source (do not choose the Supports Global Transactions option, or the Logging Last Resource, Emulate Two-Phase Commit, or One-Phase Commit options of the Supports Global Transactions option), and specify a service name for your database.
Target these data sources to the BAM Cluster.
Make sure the datasources' connection pool initial capacity is set to 0. To do this, select Services, JDBC, and then Datasources. In the Datasources screen, click the Datasource Name, then click the Connection Pool tab, and enter 0 in the Initial capacity field.
For information on using Oracle WebLogic Server Administration to create a multi-data source, see Section 14.3, "Creating a Multi-Data Source Using the Oracle WebLogic Server Administration Console."
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:
Interface
Interface=eth0
This property specifies the interface name for the floating IP (eth0
, for example).
Note:
Do not specify the sub interface, such as eth0:1
or eth0:2
. This interface is to be used without the :0
, or :1
. The 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
, or, eth2
, eth3
, eth
n, depending on the number of interfaces configured.
NetMask
NetMask=255.255.255.0
This property specifies the net mask for the interface for the floating IP.
UseMACBroadcast
UseMACBroadcast=true
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 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.
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 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.
Set the environment and superuser privileges for the wlsifconfig.sh
script.
Ensure that the PATH environment variable includes the files listed in Table 12-5.
Table 12-5 Required Files for the PATH Environment
File | Directory Location |
---|---|
|
ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration |
|
WL_HOME/common/bin
|
|
WL_HOME/common/nodemanager
|
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, to set the environment and superuser privileges for the wlsifconfig.sh
script.
Note:
Ask the system administrator for the sudo and system rights as appropriate to 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:
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
Enable host name verification certificates between Node Manager in the BAMHOSTn nodes and the Administration Server. To enable host name verification certificates, see Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1."
To configure cluster migration targets, set the DataSourceForAutomaticMigration
property to true.
To configure migration targets in a cluster:
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page appears.
Click the cluster for which you want to configure migration (BAM_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 BAMHOST1 and BAMHOST2.
Select the data source to be used for automatic migration. In this case select the leasing data source.
Click Save.
Click Activate Changes.
Set the candidate machines for server migration for WLS_BAM1 only. WLS_BAM2 does not use server migration:
In 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.
In the Available field, located in the Migration Configuration section, select the machines to which to allow migration and click the right arrow. Select BAMHOST2 for WLS_BAM1.
Select Automatic Server Migration Enabled and click Save.
This enables the Node Manager to start a failed server on the target node automatically.
Click Activate Changes.
Restart the Administration Server and the WLS_BAM1 server.
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 is different from the configuration if the server is migrated automatically.
To verify that Server Migration is working properly:
To test from Node 1:
Kill the WLS_BAM1 managed server.
BAMHOST1> 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:
BAMHOST1> ps -ef | grep WLS_BAM1
Watch the Node Manager console: you should see a message indicating that WLS_BAM1's floating IP has been disabled.
Wait for the Node Manager to try a second restart of WLS_BAM1. Node Manager waits for a fence period of 30 seconds before trying this restart.
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:
Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_BAM1on Node 1, Node Manager on Node 2 should prompt that the floating IP for WLS_BAM1 is being brought up and that the server is being restarted in this node.
Access the Oracle BAM console using BAMHOST1VHN1 and soa.mycompany.com/OracleBAM.
To validate migration from the Administration Console:
Log into the Administration Console.
Click on Domain on the left console.
Click the Monitoring tab and then on the Migration tab.
The Migration Status table provides information on the status of the migration.
If you are using Oracle BAM in a clustered environment, you must make the changes you made in Oracle Enterprise Manager on one node to all nodes. In addition, consider the following when making configuration changes to BAM Server in a BAM Enterprise Deployment Topology:
Since you are using server migration, the BAM Server is moved to a different node's domain directory. You must pre-create the BAM Server configuration in the failover node. The BAM Server configuration files are located in the following directory:
DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config
In order to create the files in preparation for possible failovers, you can force a server migration and copy the files from the source node. For example, for BAM:
Configure the driver for WLS_BAM1 in BAMHOST1.
Force a failover of WLS_BAM1 to BAMHOST2. Verify the directory structure for the BAM Server in the failover node:
DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config
After you have verified that the extended domain is working, back up the domain configuration. This is a quick backup for the express purpose of immediate restore in case of failures in future procedures. Back up the configuration to the local disk. This backup can be discarded once you have completed the enterprise deployment. Once you have completed the enterprise deployment, you can initiate the regular deployment-specific backup and recovery process.
For information about backing up the environment, see "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide. For information about recovering your information, see "Recovering Your Environment" in the Oracle Fusion Middleware Administrator's Guide.
To back up the domain configuration:
Back up the Web tier:
Shut down the instance using opmnctl
.
ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
Back up the Middleware Home on the web tier using the following command (as root):
tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
Back up the Instance Home on the web tier using the following command (as root):
tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE
Start the instance using opmnctl
:
ORACLE_BASE/admin/instance_name/bin/opmnctl startall
Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or OS tools such as tar
for cold backups if possible.
Back up the Administration Server domain directory to save your domain configuration. The configuration files are located in the following directory:
ORACLE_BASE/ admin/domain_name
To back up the Administration Server:
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name