7.1Overview of Adding BAM to a Domain

The BAM system is installed using the WL_HOME and ORACLE_HOME created in Chapter 4, "Creating a Domain" 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.

7.2 Enabling VIP4 in BAMHOST1

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. You must enable a VIP (VIP4) mapping BAMHOST1VHN1 on BAMHOST1 and must correctly resolve the BAMHOST1VHN1 hostname in the network system used by the topology (either by DNS Server, hosts resolution).

7.3Extending the Domain to Include BAM

In this step, you extend the domain created in Chapter 4, "Creating a Domain" 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, a deployment may choose to use a different database service specifically for BAM.

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.

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 7-1. Do not modify the other servers that appear in this screen; leave them as they are.

Table 7-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 7-2. Do not modify the other clusters that display in this screen; leave them as they are.

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

Table 7-3 Machines

Name

Node Manager Listen Address

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

BAMHOST1

BAMHOST1

BAMHOST2

BAMHOST2

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.

The oracle.sdp.* deployment should be targeted only to SOA_Cluster and BAM_Cluster. The oracle.soa.* deployments should be targeted only to SOA_Cluster.

The oracle.rules.* library should be targeted only to Admin Server and SOA_Cluster.

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.

7.3.1Restarting the Administration Server

7.4 Configuring a JMS Persistence Store for BAM UMS

Configure the location for all of the persistence stores as a directory that is visible from both nodes. For more information, see Section 4.1, "Installing Oracle Fusion Middleware Home." You must then change all of the persistent stores to use this shared base directory as follows:

Log into the Oracle WebLogic Server Administration Console.

In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page appears.

Select the UMSJMSFileStore_auto_3 persistence store (represented as a hyperlink) from the Name column of the table. The Settings page for the persistence store appear.

In the Configuration tab, enter the location on a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster in the Directory field. Specifying this location enables pending JMS messages to be sent. The location should follow the following directory structure:

ORACLE_BASE/admin/<domain_name>/<bam_cluster_name>/jms

Click Save and Activate.

Repeat the steps for UMSJMSFileStore_auto_4

7.5Configuring a Default Persistence Store for Transaction Recovery

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:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence store, complete these steps 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 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.

7.6Untargeting the BAM Server System from WLS_BAM2

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. Perform these steps 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.

7.8Disabling Host Name Verification for the WLS_BAMn Managed Servers

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 8, "Setting Up Node Manager"). If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the EDG topology configuration is complete as described in Chapter 8, "Setting Up Node Manager."

Perform these steps 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.

7.9Starting Node Manager on BAMHOST1 and BAMHOST2

Perform these steps 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:

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 2, "Database and Environment Preconfiguration," 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

7.10Starting the BAM System

Perform these steps 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.

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

Note:

These instructions assume 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.

7.11Configuring the BAM Web Applications to Use the BAM Server in BAMHOST1

Perform these steps to configure the OracleBamWeb(WLS_BAM1) and OracleBamWeb(WLS_BAM2) applications to use the BAM server in BAMHOST1:

7.14Configuring Server Migration for the WLS_BAM1 Server

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:

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 may not be required, but you must also target the corresponding server-migration/leasing datasources to the BAM Cluster.

7.14.1 Setting Up the User and Tablespace for the Server Migration Leasing Table

Perform these steps 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:

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.

7.14.3Editing the Node Manager's Properties File

The nodemanager.properties file is located in the WL_HOME/common/nodemanager directory.

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

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

Interface

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, ethn, depending on the number of interfaces configured.

NetMask

This property specifies the net mask for the interface for the floating IP.

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.

Perform this configuration in the two nodes where the servers are running. 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 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 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.

7.14.4 Set Environment and Superuser Privileges for the wlsifconfig.sh Script

Perform these steps to set the environment and superuser privileges for the wlsifconfig.sh script:

Ensure that the PATH environment variable includes the files listed in Table 7-5.

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, complete these steps:

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.

7.14.5 Enabling Host Name Verification Certificates Between Node Manager in the BAMHOSTn Nodes and the Administration Server

7.14.7 Test Server Migration

Perform these steps to verify that Server Migration is working properly:

From Node 1:

Kill the WLS_BAM1 managed server.

To do this, run this command:

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.

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.

Verification From the Administration Console

Migration can also be verified in 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, any configuration property changes you make in Oracle Enterprise Manager on one node must be made on all nodes (i.e. configuration changes applied to one server are no applied automatically to all servers in the BAM cluster. In addition, consider the following when making configuration changes to BAM Server in a BAM EDG Topology:

Since server migration is used, the BAM Server is moved to a different node's domain directory. It is necessary to pre-create the BAM Server configuration in the failover node. The BAM Server configuration files are located in the following directory:

When accessing a Oracle BAM Server using the BAM Adapter (rmi), the Virtual Hostname of the BAM Server (BAMHOST1VNH1) should be used for the connection. SOAP requests come through HTTP, therefore, you must use the load balancer addresses when using the adapter in this case.

7.17 Backing Up the Installation

After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded once the enterprise deployment setup is complete. At this point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in this guide. For information on how to recover components, see "Recovery of Components" and "Recovery After Loss of Component" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" in the guide. Also refer to the Oracle Database Backup and Recovery Guide for information on database backup.

Perform these steps to back up the installation a this point:

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 AdminServer domain directory. Perform a backup to save your domain configuration. The configuration files all exist under the ORACLE_BASE/admin/<domain_name> directory.

SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>

Scripting on this page enhances content navigation, but does not change the content in any way.