Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite
11g Release 1 (11.1.1)

Part Number E12036-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

7 Extending the Domain to Include BAM

This chapter is for users who want to use Oracle Business Activity Monitoring (BAM) in their enterprise. It covers the following topics:

7.1 Overview 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.

Performing Backups

Before using the Configuration Wizard, you must back up the domain as described in in Oracle Fusion Middleware Administrator's Guide.

This section describes how to add BAM to the domain that you created in Chapter 4, "Creating a Domain" through the following steps.

Note:

You might have already added SOA components to the domain as described in Chapter 5, "Extending the Domain for SOA Components."

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

To enable VIP4, follow the steps described in Section 4.3, "Enabling VIP1 in SOAHOST1."

7.3 Extending 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.

Note:

Before performing these steps, back up the domain as described in Oracle Fusion Middleware Administrator's Guide.
  1. Change directory to the location of the Configuration Wizard. This is within the SOA home directory.

    SOAHOST1> cd ORACLE_HOME/common/bin
    
  2. Start the Configuration Wizard:

    SOAHOST1> ./config.sh
    
  3. In the Welcome screen, select Extend an existing WebLogic domain, and click Next.

  4. In the WebLogic Domain Directory screen, select the WebLogic domain directory (ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>), and click Next.

  5. 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.1

    Click Next.

  6. In the Configure JDBC Component Schema screen (Figure 7-1), do the following:

    1. Select BAM Schema.

    2. Select Configure selected component schemas as RAC multi data source schemas in the next panel.

    3. Click Next.

    Figure 7-1 Configure JDBC Component Schema Screen

    Description of Figure 7-1 follows
    Description of "Figure 7-1 Configure JDBC Component Schema Screen"

  7. In the Configure RAC Multi Data Sources Component Schema screen (Figure 7-2), do the following:

    1. Select BAM Schema. Leave the other data sources as they are.

    2. 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 7-2 assume that soedg was used as prefix for schema creation from RCU.

      • Password: Enter the password to use to access the schemas.

    3. Click Add and enter the details for the first Oracle RAC instance.

    4. Repeat for each Oracle RAC instance.

      Note:

      Leave the SOA Infrastructure, User Messaging Service, OWSM MDS, and SOA MDS Schema information as it is.
    5. Click Next.

    Figure 7-2 Configure Multi Data Source Component Schema Screen

    Description of Figure 7-2 follows
    Description of "Figure 7-2 Configure Multi Data Source Component Schema Screen"

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

  9. In the Optional Configuration screen, select the following:

    • JMS Distributed Destinations

    • Managed Servers, Clusters, and Machines

    • Deployments and Services

  10. 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.
  11. 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 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.

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

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

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

  15. In the Assign Servers to Machines screen, do the following:

    • Assign WLS_BAM1 to BAMHOST1

    • Assign WLS_BAM2 to BAMHOST2.

    Click Next.

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

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

    • Target JOC Startup Class and JOC Shutdown Class only to WSM-PM_Cluster.

  18. Click Next.

  19. In the Configuration Summary screen, click Extend.

    Note:

    Because you are extending a domain, do not change the values that appear in the Configuration Summary screen.
  20. Click OK in the warning dialog about conflicts in ports for the domain.

  21. In the Creating Domain screen, click Done.

  22. Restart the Administration Server to enable these changes to take effect.

7.3.1 Restarting the Administration Server

Restart the Administration Server using the procedure in Section 4.7, "Starting the Administration Server on SOAHOST1."

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:

  1. Log into the Oracle WebLogic Server Administration Console.

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

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

  4. 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
    
  5. Click Save and Activate.

  6. Repeat the steps for UMSJMSFileStore_auto_4

7.5 Configuring 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:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page appears.

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

  4. Click the Services tab.

  5. 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
    
  6. 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.6 Untargeting 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:

  1. Log into the Oracle WebLogic Administration Console at http://ADMINVHN:7001/console.

  2. In the Domain Structure window, choose Environment and then Servers. The Summary of Servers page appears.

  3. Select WLS_BAM2 in Name column of the table. The Settings page for WLS_BAM2 appears.

  4. Click the Deployments tab.

  5. Select the oracle-bam application from the Name column of the table. The Settings page for the oracle-bam application appears.

  6. Click the Targets tab.

  7. Click Lock and Edit.

  8. Change the targets for the modules as described in Table 7-4.

    Note:

    You must target all of these components as described in Table 7-4, as incorrect targeting can prevent the BAM system from starting.

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


7.7 Propagating the Domain Configuration to BAMHOST1 and BAMHOST2 Using the pack/unpack Utility

To propagate the new domain configuration, complete these steps:

  1. Make sure that a similar directory and shared storage configuration as SOAHOST2 is present in BAMHOST1 (described in Chapter 2, "Database and Environment Preconfiguration"). BAMHOST1 and BAMHOST2 should have mounted the MW_HOME directory as created in Chapter 4, "Creating a Domain."

  2. Run the pack command on SOAHOST1 to create a template pack as follows:

    1. Run the following command:

      SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
      

      Note:

      Notice that this directory is available as mount point to the MW_HOME created in Chapter 4, "Creating a Domain."
    2. Run the pack command:

      SOAHOST1> ./pack.sh -managed=true
         -domain=ORACLE_BASE/admin/domain_name/aserver/v
         -template=soadomaintemplateBAM.jar
         -template_name=soa_domain_templateBAM
      
  3. Run the following command on SOAHOST1 to copy the template file created in the previous step to BAMHOST1.

    SOAHOST1> scp soadomaintemplateBAM.jar
       oracle@BAMHOST1:/ORACLE_COMMON_HOME/common/bin
    
  4. 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
    
  5. Run the copy and unpack commands for BAMHOST2.

7.8 Disabling 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:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. In the Administration Console, select WLS_BAM1, then SSL, and then Advanced.

  3. Set Hostname Verification to None.

  4. In the Administration Console, select WLS_BAM2, then SSL, and then Advanced.

  5. Save and activate the changes.

7.9 Starting Node Manager on BAMHOST1 and BAMHOST2

Perform these steps to start Node Manager on BAMHOST1 and BAMHOST2:

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

    You must use the StartScriptEnabled property to avoid class loading failures and other problems. See also Section 10.7.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 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.
  2. 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.10 Starting the BAM System

Perform these steps to start the WLS_BAM1 managed server on BAMHOST1:

  1. Start the WLS_BAM1 managed servers:

    1. Log into the Oracle WebLogic Server Administration Console at http://ADMINVHN:7001/console.

    2. In the Domain Structure window, expand the Environment node and then select Servers. The Summary of Servers page appears.

    3. Click the Control tab.

    4. Select WLS_BAM1 from the Servers column of the table.

    5. Click Start.

  2. 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 2.1.1.3, "Initialization Parameters" for details. This error often occurs when you start servers that are subsequent the first server.

  1. Start the WLS_BAM2 managed servers:

    1. Log into the Oracle WebLogic Administration Console at http://ADMINVHN:7001/console.

    2. In the Domain Structure window, expand the Environment node and then select Servers. The Summary of Servers page appears.

    3. Click the Control tab.

    4. Select WLS_BAM2 from the Servers column of the table.

    5. Click Start.

  2. 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.11 Configuring 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:

  1. Access Oracle Enterprise Manager Fusion Middleware Control through http://ADMINVHN:7001/em.

  2. Expand BAM in the navigation tree.

  3. Right-click OracleBamWeb(WLS_BAM1).

  4. Choose BAM Web Properties from the context menu. The BAM Web Properties page appears.

  5. Define the following properties:

    • Enter https://soa.mycompany.com:443 for the application URL.

    • Enter BAMHOST1VHN1 for the server name. See also Table 2-2 in Section 2.2.3, "IPs and Virtual IPs."

    • Modify the listening port of the server using the Mbean browser. To do this follow these steps:

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

  6. Select OracleBamWeb(WLS_BAM2) from the navigation tree and repeat these steps.

7.12 Configuring Oracle HTTP Server for the WLS_BAMn Managed Servers

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:

  1. 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>
    
  2. 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
    

7.13 Validating Access Through Oracle HTTP Server

Verify URLS to ensure that appropriate routing and failover is working from the HTTP Server to the BAM_Cluster. Perform these steps to verify URLs:

  1. While WLS_BAM2 is running, stop WLS_BAM1 using the Oracle WebLogic Server Administration Console.

  2. Access WebHost1:7777/OracleBAM to verify the appropriate functionality. (Please note that you will not be able to retrieve reports or data since the BAM server is down.)

  3. Start WLS_BAM1 from the Oracle WebLogic Server Administration Console.

  4. Stop WLS_BAM2 from the Oracle WebLogic Server Administration Console.

  5. Access WebHost1:7777/OracleBAM to verify the appropriate functionality.

7.14 Configuring 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:

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

  1. 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;
    
  2. 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;
    
  3. Create the leasing table using the leasing.dll script as follows:

    1. Copy the leasing.ddl file located in the WL_HOME/server/db/oracle/920 directory to your database node.

    2. Connect to the database as the leasing user.

    3. Run the leasing.ddl script in SQL*Plus as follows:

      SQL> @copy_location/leasing.ddl;
      

7.14.2 Creating a Multi-Data Source from the WebLogic Server Administration Console

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 9.2, "Creating a Multi-Data Source Using the Oracle WebLogic Server Administration Console."

7.14.3 Editing 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.
  1. 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.

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

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

    Table 7-5 Required Files for the PATH Environment

    File Directory Location

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

      1. Grant sudo privilege to the WebLogic 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 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

See Section 8.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1."

7.14.6 Configure Server Migration Targets

Configuring Cluster Migration sets the DataSourceForAutomaticMigration property to true. Perform these steps to configure cluster migration in a cluster:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page appears.

  3. Click the cluster for which you want to configure migration (BAM_Cluster) in the Name column of the table.

  4. Click the Migration tab.

  5. In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select BAMHOST1 and BAMHOST2.

  6. Select the data source to be used for automatic migration. In this case select the leasing data source.

  7. Click Save.

  8. Set the candidate machines for server migration:

    Note:

    You must perform this task for WLS_BAM1 only, as WLS_BAM2 does not use server migration.
    1. In Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.

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

    3. Click 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. Select BAMHOST2 for WLS_BAM1.

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

    6. Click Save.

    7. Restart the Administration Server and the WLS_BAM1 server.

      To restart the Administration Server, use the procedure in Section 4.7, "Starting the Administration Server on SOAHOST1.".

7.14.7 Test Server Migration

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

From Node 1:

  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
    
  2. Watch the Node Manager console: you should see a message indicating that WLS_BAM1's floating IP has been disabled.

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

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

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

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

  1. Log into the Administration Console.

  2. Click on Domain on the left console.

  3. Click the Monitoring tab and then on the Migration tab.

    The Migration Status table provides information on the status of the migration.

7.15 Configuration Changes Applied to BAM components in an EDG Topology

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:

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:

  1. Configure the driver for WLS_BAM1 in BAMHOST1.

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

7.16 Configuration Changes Applied to BAM components in an EDG Topology

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:

  1. Back up the web tier:

    1. Shut down the instance using opmnctl.

      ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall
      
    2. Back up the Middleware Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
      
    3. Back up the Instance Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
      
    4. Start the instance using opmnctl:

      ORACLE_BASE/admin/<instance_name>/bin/opmnctl startall
      
  2. 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.

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