Skip Headers
Oracle® Fusion Middleware High Availability Guide
11g Release 1 (11.1.1.8.0)

Part Number E10106-22
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

12 Active-Passive Topologies for Oracle Fusion Middleware High Availability

This chapter describes how to configure and manage active-passive topologies. It contains the following sections:

12.1 Oracle Fusion Middleware Cold Failover Cluster Topology Concepts

Oracle Fusion Middleware provides an active-passive model for all its components using Oracle Fusion Middleware Cold Failover Cluster (Cold Failover Cluster). In a Cold Failover Cluster configuration, two or more managed server instances are configured to serve the same application workload but only one is active at any particular time.

You can use a two-node Cold Failover Cluster to achieve active-passive availability for middle-tier components. In a Cold Failover Cluster, one node is active while the other is passive, on standby. If the active node fails, the standby node activates and the middle-tier components continue servicing clients from that node. All middle-tier components fail over to the new active node. No middle-tier components run on the failed node after the failover.

The most common properties of a Cold Failover Cluster configuration include:

In active-passive deployments, services are typically down for a short period of time. This is the time taken to either restart the instance on the same node, or to fail over the instance to the passive node.

Active-Passive Topologies: Advantages

Active-Passive Topologies: Disadvantages

12.2 Configuring Oracle Fusion Middleware for Active-Passive Deployments

Oracle Fusion Middleware components come in a variety of Java EE container-deployed components and non-Java EE components. Oracle Internet Directory, Oracle Virtual Directory, and Oracle Reports are system components. Oracle SOA Suite and Oracle WebCenter Portal are Java EE components that are deployed to Oracle WebLogic Server.

Administration Console and Oracle Enterprise Manager Fusion Middleware Control also deploy to the WebLogic container. You can deploy both Java EE and system components to Cold Failover Cluster environments; they can co-exist on the same system or on different systems. When on the same system, you can configure them to failover as a unit, sharing the same virtual IP, or failover independently using separate virtual IPs. In most Oracle Fusion Middleware deployments, a database is used either for the component metadata created using Repository Creation Utility (RCU), or for application data. In many cases, a Cold Failover Cluster middle tier deployment uses a Cold Failover Cluster database, both deployed to the same cluster. The typical deployment has the two components configured as separate failover units using different VIPs and different shared disks on the same hardware cluster.

To create an active-passive topology for Oracle Fusion Middleware:

  1. Install the component as a single instance configuration. If you plan to transform this instance to a Cold Failover Cluster deployment, install it using a shared disk. That is, the Middleware home, the Instance home (for system components) and the domain directory (for a WebLogic deployment on a shared disk). Everything that fails over as a unit should be on a shared disk.

  2. After the installation, transform the deployment into a Cold Failover Cluster deployment and configure it to listen on a Virtual IP. The Virtual IP is configured on the current active node. It fails over, along with the Oracle Fusion Middleware deployment, to the passive node when failure occurs.

This general procedure applies to the Cold Failover Cluster Oracle database. For example, the Oracle database instance is installed as a single instance deployment and subsequently transformed for Cold Failover Cluster. A Cold Failover Cluster Oracle Fusion Middleware deployment can also use an Oracle Real Application Clusters (Oracle RAC) database.

The following sections describe the procedures for post-installation configuration to transform a single instance deployment to a Cold Failover Cluster deployment.

The rest of this chapter describes how to transform Cold Failover Cluster for each individual component in the Oracle Fusion Middleware suite. The first section details the procedure for the basic infrastructure components, and the subsequent section does so for the individual Oracle Fusion Middleware component. Any given deployment, for example an Oracle instance or domain, has more than one of these in a machine. To transform the entire instance or domain:

This section includes the following topics:

12.2.1 Cold Failover Cluster Requirements

A Cold Failover Cluster deployment has at least two nodes. You install on one of these nodes; the other node is the passive node. Requirements for both nodes are as follows:

  • The nodes should be same in all respects at the operating system level. For example, they should be the same operating system, version, and patch level.

  • The nodes should have similar hardware characteristics. This ensures predictable performance during normal operations and on failover. Oracle suggests designing each node for capacity to handle both its normal role and the additional load required to handle a failover scenario. This is not required only if the SLA agreement indicates that, during outage scenarios, reduced performance is acceptable.

  • The nodes should have the same mount point free so that mounting shared storage can occur to the same node during normal operations and failover conditions.

  • The user ID and group ID on the two nodes are similar, and the user ID and group ID of the user owning the instance is the same on both nodes.

  • The oraInventory location is the same on both nodes and has similar accessibility of the instance or domain owner. The location of the oraInst.loc file, as well as the beahomelist file should be the same.

  • Since a given instance uses the same listen ports irrespective of the machine on which it is currently active, ensure that the ports that the Cold Failover Cluster instance uses are free on both the nodes.

Note:

Before you start the transformation, back up the entire domain. Oracle also recommends that you create a local backup file before editing the source files. For more information, see the Oracle Fusion Middleware Administrator's Guide. Oracle recommends backing up:

  • All domain directories

  • All Instance homes

  • The database repository (optional)

  • Middleware homes (optional)

12.2.2 Directories and Environment Variables Terminology

The following list describes the directories and variables used in this chapter:

  • ORACLE_BASE: This environment variable and related directory path refers to the base directory under which Oracle products are installed.

  • MW_HOME: This environment variable and related directory path refers to the location where Fusion Middleware (FMW) resides.

  • WL_HOME: This environment variable and related directory path contains installed files necessary to host a WebLogic Server.

  • ORACLE_HOME: This environment variable and related directory path refers to the location where a specific Oracle FMW Suite, such as SOA, is installed.

  • ORACLE_COMMON_HOME: The Oracle home that contains the binary and library files that are common to all the Oracle Fusion Middleware software suites. In particular, the Oracle Common home includes the files required for Oracle Enterprise Manager Fusion Middleware Control (which is used to manage the Fusion Middleware) and the Oracle Java Required Files (JRF).

  • DOMAIN_HOME: This directory path refers to the location where the Oracle WebLogic Domain information (configuration artifacts) is stored.

  • ORACLE_INSTANCE: An Oracle instance contains one or more system components, such as Oracle Web Cache, Oracle HTTP Server, or Oracle Internet Directory. An Oracle instance directory contains updatable files, such as configuration files, log files, and temporary files.

  • /localdisk: The root of the directory tree when the FMW install (either MW_HOME or DOMAIN_HOME) is on a local disk. It is used to represent the MW_HOME on local disk.

  • /shareddisk: Root of the directory tree when the FMW install (either MW_HOME or DOMAIN_HOME) is on a shared storage system that is mounted by any one node of a CFC configuration. It is used to represent the MW_HOME on shared disk.

The example values this guide uses and that Oracle recommends for consistency are:

  • ORACLE_BASE: /u01/app/oracle

  • MW_HOME (Apptier): ORACLE_BASE/product/fmw

  • ORACLE_COMMON_HOME: MW_HOME/oracle_common

  • WL_HOME: MW_HOME/wlserver_10.3

The following table includes examples of Oracle home, domain home, and domain directory values used for some of the Oracle Fusion Middleware components:

Component ORACLE_HOME DOMAIN_HOME Domain Directory

Identity Management

MW_HOME/idm

IDMDomain

MW_HOME/user_projects/domains/IDMDomain

Oracle SOA

MW_HOME/soa

SOADomain

MW_HOME/user_projects/domains/SOADomain

WebCenter

MW_HOME/wc

WCDomain

MW_HOME/user_projects/domains/WCDomain

WebCenter Content

MW_HOME/wcc

WCCDomain

MW_HOME/user_projects/domains/WCCDomain

Oracle Portal

MW_HOME/portal

PortalDomain

MW_HOME/user_projects/domains/PortalDomain

Oracle Forms

MW_HOME/forms

FormsDomain

MW_HOME/user_projects/domains/FormsDomain

Oracle Reports

MW_HOME/reports

ReportsDomain

MW_HOME/user_projects/domains/ReportsDomain

Oracle Discoverer

MW_HOME/disco

DiscoDomain

MW_HOME/user_projects/domains/DiscoDomain

Web Tier

MW_HOME/web

Not applicable

Not applicable

Directory Tier

MW_HOME/idm

Not applicable

Not applicable


Example location for Applications Directory: ORACLE_BASE/admin/domain_name/apps

Example location for Oracle Instance: ORACLE_BASE/admin/instance_name

Oracle recommends ORACLE_BASE as the shared storage mount point. In most cases, this location helps to ensure that all the persistent bits of a failover unit are on the same shared storage. When more than one Cold Failover Cluster exists on a node, and each one fails over independently, different mount points will exist for each failover unit.

12.2.3 Transforming Oracle Fusion Middleware Infrastructure Components

An Oracle Fusion Middleware deployment comprises basic infrastructure components that are common across all the product sets. This section describes Cold Failover Cluster transformation steps for these components.

There are two Administration Server topologies supported for Cold Failover Cluster configuration. The following sections describe these two topologies and provide installation and configuration steps to prepare the Administration Server for Cold Failover Cluster transformation.

This section includes the following topics:

12.2.3.1 Administration Server Topology 1

Figure 12-1 shows the first supported topology for Oracle Cold Failover Cluster.

Figure 12-1 Administration Server Cold Failover Cluster Topology 1

Description of Figure 12-1 follows
Description of "Figure 12-1 Administration Server Cold Failover Cluster Topology 1"

In Figure 12-1, the Administration Server runs on a two-node hardware cluster: Node 1 and Node 2. The Administration Server listens on the Virtual IP or hostname. The Middleware Home and the domain directory are on a shared disk that is mounted on either Node 1 or Node 2 at any given point. Both the Middleware home and the domain directory should be on the same shared disk or shared disks that can fail over together. If an enterprise has multiple Fusion Middleware domains for multiple applications or environments, this topology is well suited for Administration Server high availability. You can deploy a single hardware cluster to host these multiple Administration Servers. Each Administration Server can use its own virtual IP and set of shared disks to provide high availability of domain services.

12.2.3.2 Topology 1 Installation Procedure

To install and configure Cold Failover Cluster for the managed server in this topology:

Install the Middleware Home

This installation includes the Oracle home, WebLogic home, and the Domain home on a shared disk. This disk should be mountable by all the nodes that act as the failover destination for the Administration Server. Depending on the storage sub-system used, the shared disk may be mountable only on one node at a time. This is the preferred configuration, even when the storage sub system enables simultaneous mounts on more than one node. This is done as a regular single-instance installation. See the component chapters to install the Administration Server (and Enterprise Manager) alone. The overall procedure for each suite is as follows:

For Administration Server only:

  1. Install the WebLogic Server software.

    See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

  2. Invoke the Configuration Wizard and create a domain with just the Administration Server.

    In the Select Domain Source screen, select the following:

    • Generate a domain configured automatically to support the following products.

    • Select Enterprise Manager and Oracle JRF.

For Oracle SOA, Oracle WebCenter Portal or Oracle WebCenter Content:

  1. Install the WebLogic Server software.

    See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

  2. Install the Oracle Home for Oracle SOA, Oracle WebCenter Portal or Oracle WebCenter Content.

    See the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite, the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal, or the Oracle WebCenter Content Installation Guide.

For Oracle Identity Management:

  1. Install the WebLogic Server software.

    See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

  2. Using Oracle Identity Management 11g Installer, install and configure the IDM Domain using the create domain option. In the Configure Components Screen, de-select everything except Enterprise Manager (selected by default)

    See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

For Oracle Portal, Forms, Reports and Discoverer:

  1. Install the WebLogic Server software.

    See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

  2. Using Oracle Fusion Middleware 11g Portal, Forms, Reports, and Discoverer Installer, install and configure the Classic Domain using the create domain option. In the Configure Components Screen, ensure that Enterprise Manager is selected.

Note:

In this case, at least one more Managed Server for the product components is also installed in this process; you cannot install the Administration Server on its own. You must transform this Managed Server to CFC using the specific procedure for the component. It is part of the same failover unit as the Administration Server.

For Oracle Business Intelligence:

  1. Install the WebLogic Server software.

    See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

  2. Using Oracle Fusion Middleware 11g Business Intelligence Installer, install and configure the Business Intelligence domain using the create new BI system option.

Note:

In this case, at least one more Managed Server for the product components is also installed in this process; you cannot install the Administration Server on its own. You must transform this Managed Server to CFC using the specific procedure for the component. It is part of the same failover unit as the Administration Server.

Configuring the Administration Server for Cold Failover Cluster

To configure the Administration Server for Cold Failover Cluster:

  1. Provision the Virtual IP using the following commands as root user:

    For Linux

    /sbin/ifconfig interface:index IP_Address netmask netmask
    /sbin/arping -q -U -c 3 -I interface IP_Address
    

    Where IP_Address is the virtual IP_address and the netmask is the associated netmask. In the following example, the IP_address is being enabled on the interface eth0.

    /sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
    /sbin/arping -q -U -c 3 -I eth0 130.35.46.17
    

    For Windows:

    netsh interface ip add address interface IP_Address netmask
    

    Where IP_Address is the virtual IP_Address and the netmask is the associated netmask. In the example below, the IP_Address is being enabled on the interface Local Area Connection.

    netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0
    
  2. Transform the Administration Server instance to Cold Failover Cluster following the procedure in section Section 12.2.3.5, "Transforming the Administration Server for Cold Failover Cluster."

  3. Validate the Administration Server transformation by accessing the consoles on the virtual IP.This virtual IP address is the new IP address; Oracle recommends that you use only this virtual IP address.

    http://cfcvip.example.com:7001/console

    http://cfcvip.example.com:7001/em

  4. Failover the Administration Server manually to the second node using the following procedure:

    Note:

    If the Administration Server is managed by a Node Manager, you must enable the Node Manager for Cold Failover Cluster.

    1. Stop the Administration Server process (and any other process running out of a given Middleware Home)

    2. Unmount the shared storage from Node1 where the Middleware Home and domain directory exists.

    3. Mount the shared storage on Node2, follow storage specific commands.

    4. Disable the Virtual IP on Node1 using the following command as root user:

      For Linux:

      /sbin/ifconfig interface:index down 
      

      In the example below, the virtual IP_Address is being disabled on the interface eth0.

      /sbin/ifconfig eth0:1 down
      

      On Windows:

      netsh interface ip delete address interface IP_Address
      

      Where IP_Address is the virtual IP_Address and the netmask is the associated netmask. In the example below, the IP_Address is being enabled on the interface Local Area Connection.

      netsh interface ip delete address "Local Area connection" 130.35.46.17
      
    5. Enable the virtual IP on Node2 using the same commands as in Step 1.

    6. Start the Administration Server process.

      DOMAIN_HOME/bin/startWebLogic.sh
      

      Where DOMAIN_HOME is the location of your domain directory.

    7. Validate access to both the Administration Server and Enterprise Manager console.

12.2.3.3 Administration Server Topology 2

Figure 12-2 shows the second supported Administration Server topology for Oracle Cold Failover Cluster.

Figure 12-2 Administration Server Cold Failover Cluster Topology 2

Administration Server Cold Failover Cluster Topology 2
Description of "Figure 12-2 Administration Server Cold Failover Cluster Topology 2"

In Figure 12-2, the Administration Server runs on a two-node hardware cluster: Node 1 and Node 2. The Administration Server is listening on the Virtual IP or hostname. The domain directory used by the Administration Server is on a shared disk. This is mandatory. This shared disk is mounted on Node 1 or Node 2 at any given point. The Middleware Homes, which contain the software, (WebLogic Home and the Oracle Home) are not necessarily on a shared disk. They can be on the local disk as well. The Administration Server uses the Middleware Home on Node1 for the software when it runs on Node1 and it uses the Middleware Home on Node2 when it runs on Node2. You must maintain the two Middleware Homes to be identical in terms of deployed products, Oracle Homes, and patches. In both cases, it uses the configuration available in the shared Domain Directory/Domain Home. Since this is shared, it ensures that the same configuration is used before and after failover.

This shared domain directory may also have other Managed Servers running. It may also be used exclusively for the Administration Server. If the domain directory is shared with other managed servers, appropriate consideration must be made for their failover when the Administration Server fails over. Some of these considerations are:

  1. If the shared storage can be mounted as read/write on multiple nodes simultaneously, the Administration Server domain directory can be shared with other managed servers. In addition, it can fail over independently of the Managed Server. The Administration Server can failover and Managed Servers can continue to run independently on their designated nodes. This is possible because the Administration Server in this case requires only failover of the VIP, and does not require failover of the shared disk. The domain directory/domain home continues to remain available by the Managed Servers. Example of such storage include a NAS or a SAN/Direct attached storage with Cluster file system.

  2. If only one node can mount the shared storage a time, sharing the Administration Server domain directory with a Managed Server implies that when the Administration Server fails over, the Managed Server that runs off the same domain directory must be shut down.

In this topology, you can use a hardware cluster to help automate failover (when used with properly configured clusterware). However, it is not required. A single hardware cluster can be deployed to host these multiple Administration Servers. Each Administration Server can use its own virtual IP and set of shared disks to provide domain services high availability.

This topology is supported for Oracle SOA Suite and Oracle WebCenter Portal Suite only.

Note:

For the Oracle Identity Management, an alternate topology is also supported for Cold Failover Cluster. See the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management for more details.

12.2.3.4 Topology 2 Installation Procedure

To install and configure Cold Failover Cluster for the Administration Server in this topology:

Install the Middleware Home

Install the Middleware Home including the Oracle Home and WebLogic Home separately on the two nodes of the domain. The Administration Server domain directory is created on a shared disk. This disk should be mountable by all the nodes that act as the failover destination for the Administration Server. Depending on the storage sub-system used, the shared disk may be mountable only on one node at a time. This is a regular single-instance installation. Refer to the product suite for details on installing the Administration Server, and Enterprise Manager alone.

To install the Middleware Home for Oracle SOA Suite, Oracle WebCenter Portal, or Oracle WebCenter Content:

  1. Install the Oracle WebLogic Server software on Node 1.

  2. Install the Oracle Home for SOA or WebCenter on Node 1.

  3. Repeat steps 1 and 2 on Node 2.

  4. Start the Configuration Wizard on Node 1 and create a domain with just the Administration Server.

    In the Select Domain Source screen, select the following:

    • Generate a domain configured automatically to support the following products.

    • Select Enterprise Manager and Oracle JRF.

  5. In the Specify Domain Name and Location screen, enter the domain name, and be sure the domain directory matches the directory and shared storage mount point.

Configuring the Middleware Home for Cold Failover Cluster

To configure the Middleware Home for Cold Failover Cluster:

  1. Provision the Virtual IP. For example:

    For Linux:

    /sbin/ifconfig eth0:1 IP_Address netmask netmask
    /sbin/arping -q -U -c 3 -I eth0 IP_Address
    

    Where IP_Address is the virtual IP_Address and the netmask is the associated netmask. In the following example, the IP_Address is being enabled on the interface eth0.

    /sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
    /sbin/arping -q -U -c 3 -I eth0 130.35.46.17
    

    For Windows:

    netsh interface ip add address interface IP_Adress netmask
    

    Where IP_Address is the virtual IP_Address and the netmask is the associated netmask. In the example below, the IP_Address is being enabled on the interface Local Area Connection.

    netsh interface ip add address "Local Area connection" IP_Adress netmask
    
  2. Transform the Administration Server instance to Cold Failover Cluster using the procedure in Section 12.2.3.5, "Transforming the Administration Server for Cold Failover Cluster."

  3. Validate the Administration Server by accessing the consoles on the virtual IP.

    http://cfcvip.example.com:7001/console

    http://cfcvip.example.com:7001/em

  4. Failover the Administration Server manually to the second node:

    1. Stop the Administration Server process and any other process running out of a given Middleware Home.

    2. Unmount the shared storage from Node1 where the Middleware Home or domain directory exists.

    3. Mount the shared storage on Node2, following storage specific commands.

    4. Disable the virtual IP on Node1:

      For Linux:

      /sbin/ifconfig interface:index down 
      

      In the following example, the IP_Address is being disabled on the interface eth0.

      /sbin/ifconfig eth0:1 down
      

      For Windows:

      netsh interface ip delete address interface addr=IP_Address
      

      Where IP_Address is the virtual IP_Address. In the following example, the IP_Address is enabled on the interface Local Area Connection.

      netsh interface ip delete address "Local Area connection" addr=130.35.46.17
      
    5. Enable the virtual IP on Node 2.

    6. Start the Administration Server process using the following command:

      DOMAIN_HOME/bin/startWebLogic.sh
      

      Where DOMAIN_HOME is the location of your domain directory.

    7. Validate access to both Administration Server and Enterprise Manager console.

12.2.3.5 Transforming the Administration Server for Cold Failover Cluster

To transform the Administration Server installed on a shared disk from Node 1, follow the steps in this section. These steps transform the container, therefore, both the Administration Console and Oracle Enterprise Manager Fusion Middleware Control, are transformed for Cold Failover Cluster. This results in other components such as OWSM-PM, deployed to this container, to become Cold Failover Cluster ready as well. The address for all of these services transforms cfcvip.example.com. After installation, to transform a non Cold Failover Cluster instance, to a Cold Failover Cluster:

  1. Log into the Administration Console.

  2. Create a machine for the virtual host

    1. Select Environment, and then Machines.

    2. In the Change Center, click Lock & Edit then New.

    3. In the Name field, enter cfcvip.example.com

    4. For the Machine OS field, select the appropriate operating system.

    5. Click Next then Finish.

      Note:

      Keep the Listen Address field set to localhost; the CFC solution relies on this setting. Do not change it to the virtual IP_Address or any other value.

    6. On the Summary of Machines tab, click the machine name just created.

    7. Click the Servers tab then click Add.

    8. In the select server drop down list ensure AdminServer is selected.

    9. Click Finish.

    10. Click Activate Changes.

  3. Configure the Administration Server to Listen on cfcvip.example.com.

    1. Select Environment, and then Servers from the Domain Structure menu.

    2. In the Change Center, click Lock & Edit.

    3. Click on the Administration Server (AdminServer)

    4. Change the Listen Address to cfcvip.example.com

    5. Click Save.

    6. Click Activate Changes.

    7. Restart the Administration Server.

      Note:

      Typically Administration Server transformation to Cold Failover Cluster takes place at domain creation time No other changes to other parts of the domain are expected. If this change happens after domain creation and other components are installed in the domain, follow the steps in the following Administration Server transformation section.

Changing Client Side Configuration for Administration Server

Any existing entities in the domain must communicate with the Administration Server using the new address. For example, when starting the Managed Servers manually, the Administration Server address should be specified as cfcvip.example.com.

In the instance.properties file, located in the ORACLE_INSTANCE/config/OPMN/opmn directory, make the following change:

adminHost=cfcvip.example.com

If the Oracle Instance is to be registered or reregistered with a Cold Failover Cluster Administration Server using the OPMN registration commands, the AdminHost location in the opmnctl command should reference the new location of the Administration Server (cfcvip.example.com).

Changing Client Side Configuration for Oracle Enterprise Manager

Since the Enterprise Manager is part of the same container where the Administration Server runs, transforming the Administration Server to Cold Failover Cluster also transforms the Enterprise Manager. If there are existing Enterprise Manager Agents configured to be part of the domain, these agent configurations must use the new location for the Enterprise Manager. To configure the new location for Enterprise Manager, use the following steps for each agent:

  1. Set the directory to ORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/config.

  2. In the emd.properties file, change node1.example.com to cfcvip.example.com in the following attributes:

    • REPOSITORY_URL

    • emdWalletSrcUrl

  3. Stop and restart the agent using the following commands:

    cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin 
    ./emctl stop agent 
    ./emctl start agent 
    ./emctl status agent 
    

    This shows the Repository URL and it should now point to the new host.

12.2.3.6 Transforming Oracle WebLogic Managed Servers

All Oracle Fusion Middleware components are deployed to a Managed Server. An important step to convert an application or component that is deployed to Oracle WebLogic Server to Cold Failover Cluster is to change its listen address to the virtual IP being used. This change is done for the specific Managed Server to which the component has been deployed. You can make this change using the Administration Console or using WLST commands.

The following example describes the generic steps for Cold Failover Cluster transformation of a Managed Server named WLS_EXMPL. These steps apply to any Managed Server in the Fusion Middleware components.

This section includes the following topics:

12.2.3.6.1 Transforming an Oracle WebLogic Managed Server using the Fusion Middleware Administration Console

In the following procedure, cfcvip.example.com is the virtual IP used for the Cold Failover Cluster and WLS_EXMPL is the managed server to be transformed.

  1. Log into the Administration Console.

  2. Create a machine for the virtual host:

    1. Select Environment > Machines.

    2. In the Change Center, click Lock & Edit then click New.

      Note:

      Create a new machine only if you used a different VIP to transform managed servers. If so, go to step g.

    3. For the Name field, enter cfcvip.example.com

    4. For the Machine OS field, select the appropriate operating system.

    5. Click Next and then click Finish.

      If you are transforming the Node Manager, you must complete the following steps:

    6. Click the newly created machine.

    7. Click Node Manager tab.

    8. Update Listen Address: cfcvip.example.com.

    9. Click Save.

    10. Click Activate Changes.

    11. Complete the steps in Section 12.2.3.7, "Transforming Node Manager."

  3. Stop the WLS_EXMPL Managed server:

    1. Choose Environment > Servers.

    2. Click Control.

    3. Select WLS_EXMPL.

    4. Select Force Shutdown Now in the Shutdown drop-down menu.

  4. Associate the WLS_EXMPL Managed Server with the VirtualHost Machine:

    1. Choose Environment > Servers.

    2. In the Change Center, click Lock & Edit.

    3. Click Configuration.

    4. Select WLS_EXMPL.

    5. For Machine, assign the newly created Machine by assigning it from the pull down menu.

    6. For Listen Address, enter cfcvip.example.com.

    7. Click Save.

    8. Click Activate Changes.

  5. Start the WLS_EXMPL Managed Server.

Note:

You can use several ways to start and stop a server instance. Use a method you have used previously to start and stop the server instances.

12.2.3.6.2 Transforming an Oracle WebLogic Managed Server using the WLST Command Line

You can transform an Oracle WebLogic managed server using WLST commands as well.

Oracle recommends shutting down the managed server you are transforming before performing these steps.

To transform a Managed Server using the WLST command line in online mode (with the WebLogic Server Administration Server up):

  1. In the command line, enter:

    WL_HOME/server/bin/setWLSEnv.sh
    WL_HOME/common/bin/wlst.sh
    
  2. In WLST, enter the following commands:

    wls:/offline>connect(<username>,<password>,<AdminServer location>)
    

    For example:

    wls:/offline>connect('WebLogic', 'welcome1', 't3://cfcvip.example.com:7001')
    
    wls:/DomainName/serverConfig> edit()
    wls:/DomainName/edit> startEdit()
    wls:/DomainName/edit !> create('cfcvip.example.com','Machine')
    wls:/DomainName/edit !> cd('Machines/cfcvip.example.com/NodeManager/cfcvip.example.com')
    wls:/DomainName/edit !> set('ListenAddress', 'cfcvip.example.com')
    wls:/DomainName/edit !>cd ('Servers')
    wls:/DomainName/edit/Servers !>cd ('WLS_EXMPL')
    wls:/DomainName/edit/Servers/WLS_EXMPL !>set('Machine',' cfcvip.example.com ')
    wls:/DomainName/edit/Servers/WLS_EXMPL !>set('ListenAddress',' cfcvip.example.com ')
    wls:/DomainName/edit/Servers/WLS_EXMPL !> save()
    wls:/DomainName/edit/Servers/WLS_EXMPL !> activate()
    wls:/DomainName/edit/Servers/WLS_EXMPL> exit()
    
  3. Stop (if not already down) and start the Managed server.

After the Managed server transformation completes, verify that all references to it use the new Listen Address cfcvip.example.com. If Oracle HTTP Server serves as a front end to this Managed server, change any mod_wls_ohs configuration with mount points referring to applications in this Managed server to route to the new listening end point.

Note:

When transforming Oracle FMW SOA server with existing or deployed composites, there are a few locations where possible appearances of the old server's listen address may occur. When the server is front ended by OHS or an LBR, the references remain the same as they do not reflect the server's listen address.

  • Deployed Composites may include specific endpoint references. For example, they can use callbackServerURL specified as a binding property for the specific reference.These references must be updated to the new server's VIP.

  • Composites relay on the SOA properties specified for the soa-infra application in Enterprise Manager: ServerURL and CAllBackURL must be updated if they were modified from the default null values.

  • The system uses the front end address set at server level. So it must be updated to reflect the new VIP.

12.2.3.7 Transforming Node Manager

Node Manager can be used in a Cold Failover Cluster environment. The possible configurations are:

  • A Node Manager that listens on the virtual IP as well and fails over with the rest of the Cold Failover Cluster stack. With ASCRS based deployments, the Node Manager must be part of the same Middleware Home as where the Cold Failover Cluster Fusion Middleware instance is running. This Node Manager is assumed to be dedicated for this Fusion Middleware instance. In this case, Oracle recommends having additional Network Channels listening on the localhost configured. Other Node Managers may co-exist on the box listening on other ports. For more details, see Chapter 13, "Using Oracle Cluster Ready Services."

  • A Node Manager that does not failover with the rest of the Cold Failover Cluster stack. In this case, Node Manager is not configured for Cold Failover Cluster and listens on all IPs on the machine, and not specifically on the virtual IP for Cold Failover Cluster. The failover nodes also have a similarly configured Node Manager already available and configured. The Node associated with the WebLogic instance communicates with the Node Manager on the localhost. For more details, see the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.

For Cold Failover Cluster in general, port usage should be planned so that there are no port conflicts when failover occurs.

To convert the Node Manager to Cold Failover Cluster:

  1. If Node Manager is running, stop it.

    The nodemanager.properties file is created only after the first start of Node Manager.

    Restart the Node Manager if necessary.

  2. In the nodemanager.properties file located in the WL_HOME/common/nodemanager/ directory, set the ListenAddress to the virtual IP.

    For example:

    ListenAddress=cfcvip.example.com
    
  3. Restart the Node Manager using the startNodeManager.sh file, located in the WL_HOME/server/bin directory. For ASCRS based deployment, the Node Manager is started using WL_HOME/server/bin/cfcStartNodemanager.sh.

    See Chapter 13, "Using Oracle Cluster Ready Services." for more details.

    Note:

    If needed, start the Node Manager only using the cfcStartNodemanager.sh script instead of the startNodeManager.sh script.

    Note:

    For WebLogic Managed Servers and Administration Servers, hostname verification may be enabled or disabled in a given installation. For CFC installation where hostname verification is enabled and Node Manager is managing these instances, the hostname verification step should use certificates for the virtual IP cfcvip.example.com as part of these steps.

12.2.3.8 Transforming Oracle Process Management and Notification Server

Oracle Process Management and Notification Server (OPMN) is used for Process Management of system components and is part of the managed server instance.

Oracle recommends keeping the default OPMN configuration in a Cold Failover Cluster environment. No further steps are necessary for Cold Failover Cluster transformation of the OPMN process itself.

If you are transforming an Oracle Instance for Cold Failover Cluster and it is registered with an Administration Server, make the following changes in these files:

  1. In the topology.xml file in the DOMAIN_HOME/opmn directory of the Administration Server domain, change hostname entries for this specific Oracle instance (being transformed to Cold Failover Cluster) to cfcvip.example.com.

    For example, for an Oracle HTTP Server instance transformed to Cold Failover Cluster, set the following in the topology.xml file

    <property name="HTTPMachine" value="cfcvip.example.com"/>
    

    For the instance itself:

    <ias-instance id="asinst " instance-home="/11gas3/MW/asinst" host="cfcvip.example.com" port="6701">
    
  2. In the instance.properties file in the ORACLE_INSTANCE/config/OPMN/opmn directory, change adminHost=<physical hostname> to adminHost=<cfcvip.example.com>.

  3. Restart all OPMN components.

12.2.3.9 Transforming Oracle Enterprise Manager for an Oracle Instance

When an Oracle instance transforms to Cold Failover Cluster, you must also transform the Enterprise Manager agent that is part of this Oracle instance to Cold Failover Cluster. This topic describes how to transform the agent and the server.

To transform the Enterprise Manager agent:

  1. Stop the Enterprise Manager agent using the following command:

    cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin 
    ./emctl stop agent 
    
  2. Set the directory to ORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/config.

  3. Replace the physical host name with the virtual host name using the mbean and setting the operation on it, for example: emoms.props:Location=AdminServer,name=emoms.properties,type=Properties,Application=em

  4. In the emd.properties file, change node1.example.com to cfcvip.example.com for the EMD_URL attribute.

  5. Change the targets.xml file on the agent side:

    cd ORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/emd
    cp targets.xml targets.xml.org
    

    Modify targets.xml so that it has only targets related to the host and oracle_emd. Remove all other entries. For example:

    <Targets AGENT_TOKEN="ad4e5899e7341bfe8c36ac4459a4d569ddbf03bc"> 
           <Target TYPE="oracle_emd" NAME="cfcvip.example.com:port"/> 
           <Target TYPE="host" NAME="cfcvip.example.com"  DISPLAY_NAME="cfcvip.example.com/>" 
    </Targets>           
    
  6. Restart the agent

    cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin 
    ./emctl start agent
    

To transform the Enterprise Manager server, make the following changes in the Administration Server domain directory:

Stop the Administration Server before making any changes.

  1. Set your directory to MW_HOME/user_projects/domains/domain_name/sysman/state.

  2. In the targets.xml file, located in MW_HOME/user_projects/domains/domain_name/sysman/state directory, modify the hostname from node1.example.com to cfcvip.example.com.

  3. Restart the Administration Server.

12.2.3.10 Transforming Web Tier Components and Clients

The Web tier is made up of two primary components, Oracle HTTP Server and Oracle Web Cache. The next two sections describe how to transform Oracle HTTP Server and Oracle Web Cache for Cold Failover Cluster.

12.2.3.10.1 Transforming Oracle HTTP Server

To transform Oracle HTTP Server for Cold Failover Cluster:

  1. In ORACLE_INSTANCE/config/OHS/component_name/httpd.conf, change the following attributes:

    Listen cfcvip.example.com:port #OHS_LISTEN_PORT
    Listen cfcvip.example.com:port #OHS_PROXY_PORT
    ServerName cfcvip.example.com
    
  2. In ORACLE_INSTANCE/config/OHS/component_name/admin.conf, change the following attributes:

    Listen cfcvip.example.com:port #OHS_LISTEN_PORT
    Listen cfcvip.example.com:port #OHS_ADMINISTRATOR_PORT
    ServerName cfcvip.example.com
    
  3. Restart Oracle HTTP Server:

    .cd ORACLE_INSTANCE/bin
    ./opmnctl restartproc process-type=OHS
    

Also, perform a single sign-on registration, as described in Section 12.2.4.15, "Single Sign-On Reregistration (If required)."

Clients of Oracle HTTP Server

If an Oracle Web Cache instance is routing to Oracle HTTP Server that has been transformed to Cold Failover Cluster, in ORACLE_INSTANCE/config/WebCache/component_name/webcache.xml, change the following attributes:

Change node1.example.com to cfcvip.example.com, where node1.example.com is the previous address of the Oracle HTTP server before transformation.

<HOST ID="h1" NAME="cfcvip.example.com" PORT="8888" LOADLIMIT="100"
 OSSTATE="ON"/>
<HOST ID="h2" NAME="cfcvip.example.com" PORT="8890" LOADLIMIT="100" OSSTATE="ON"
 SSLENABLED="SSL"/>
12.2.3.10.2 Transforming Oracle Web Cache

To transform an Oracle Web Cache for Cold Failover Cluster:

  1. Set up an alias to the physical hostname on both nodes of the cluster in /etc/hosts.

    This is an alias to the IP_Address of the node. Set this in /etc/hosts for Linux and Windows location for Windows. The alias name is wcprfx.example.com. For example, on node Node1, the /etc/hosts file (on UNIX), the entry would be n.n.n.n node1 node1.example.com wcprfx wcprfx.example.com

    On the failover node Node2, the /etc/hosts file (on UNIX), the entry would be n.n.n.m node2 node2.example.com wcprfx wcprfx.example.com.

    On Windows, make this change on all nodes in the file located at C:\SystemRoot\system32\drivers\etc\hosts. SystemRoot is Winnt or Windows.

  2. In ORACLE_INSTANCE/config/WebCache/component_name/webcache.xml:

    • Change node1.example.com to cfcvip.example.com node1.example.com is where Oracle Web Cache was installed, and the host address it is listening on before transformation.

      SITE NAME="cfcvip.example.com"
      
    • Change the Virtual Host Name entries to be cfcvip.example.com for the SSL and non-SSL ports. For example:

      <HOST SSLENABLED="NONE" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
      PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8888"
      NAME="cfcvip.example.com" ID="h0"/>
      <HOST SSLENABLED="SSL" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
      PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8890"
      NAME="cfcvip.example.com" ID="h3"/>
      <VIRTUALHOSTMAP PORT="8094" NAME="cfcvip.example.com">
         <HOSTREF HOSTID="h3"/>
      </VIRTUALHOSTMAP>
      <VIRTUALHOSTMAP PORT="8090" NAME="cfcvip.example.com">
         <HOSTREF HOSTID="h0"/>
      </VIRTUALHOSTMAP> 
      
    • Change cache name entries to be based of wcprfx.example.com where wcprfx.example.com is an alias created in /etc/hosts on all nodes of the cluster. For example:

      <CACHE WCDEBUGON="NO" CAPACITY="30" VOTES="1" INSTANCENAME="asinst_1"
      COMPONENTNAME="wc1" ORACLEINSTANCE="ORACLE_INSTANCE"
      HOSTNAME="wcprfx.example.com" ORACLEHOME="ORACLE_HOME"
      NAME="wcprfx.example.com-WebCache">
      
    • In the MULTIPORT section, change IPADDR from ANY to cfcvip.example.com for the following:

      PORTTYPE="NORM"
      SSLENABLED="SSL" PORTTYPE="NORM"
      PORTTYPE="ADMINISTRATION"
      PORTTYPE="INVALIDATION"
      PORTTYPE="STATISTICS"
      

      For example:

      <MULTIPORT>
         <LISTEN PORTTYPE="NORM" PORT="8090"
      IPADDR="cfcvip.example.com"/>
         <LISTEN SSLENABLED="SSL" PORTTYPE="NORM" PORT="8094"
      IPADDR="cfcvip.example.com">
             <WALLET>ORACLE_INSTANCE/config/WebCache/wc1/keystores/
      default</WALLET>
         </LISTEN>
         <LISTEN PORTTYPE="ADMINISTRATION" PORT="8091"
      IPADDR="cfcvip.example.com"/>
         <LISTEN PORTTYPE="INVALIDATION" PORT="8093" IPADDR="
      cfcvip.example.com"/>
         <LISTEN PORTTYPE="STATISTICS" PORT="8092"
      IPADDR="cfcvip.example.com"/>
      </MULTIPORT>
      
  3. Restart Oracle Web Cache:

    cd ORACLE_INSTANCE/bin
    ./opmnctl restartproc process-type=WebCache
    

12.2.4 Transforming Oracle Fusion Middleware Components

This section describes the following Fusion Middleware components:

For detailed explanation on the product components, see the appropriate component chapter in this guide.

12.2.4.1 Transforming Oracle Internet Directory and Its Clients

This section describes how to transform Oracle Internet Directory and its clients.

12.2.4.1.1 Transforming Oracle Internet Directory

To transform an Oracle Internet Directory server from PS1:

  1. In a text editor, create a file named oidcfc.ldif that sets up the virtual IP cfcvip.example.com for the Oracle Internet Directory server:

    dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry 
    changetype: modify 
    replace: orclhostname 
    orclhostname: cfcvip.example.com
    
  2. Run the following command:

    ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin –w
    <adminPasswd> -f oidcfc.ldif
    

    OID must be up at the time of running this command. oidHost is the physical hostname listening end point installed with OID.

  3. Stop and restart the Oracle Internet Directory server using opmnctl:

    For example:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
    ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1
    
  4. Reregister OID with the Administration Server.

    For example:

    ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost
    myAdminHost -adminPort 7001 -adminUsername weblogic -componentType OID
    -componentName oid1 -Host cfcvip.example.com
    -Port 3060
    -Sport 3131
    

To upgrade Oracle Internet Directory from PS1, run the following:

ORACLE_HOME/opmn/bin/upgradenonj2eeapp.sh -oracleInstance ORACLE_INSTANCE

12.2.4.1.2 Transforming Oracle Internet Directory Clients

To transform an Oracle Internet Directory client:

  1. All clients of the Oracle Internet Directory server should use the virtual IP cfcvip.example.com to access that Oracle Internet Directory server.

  2. Oracle Directory Integration Platform installation that uses the Oracle Internet Directory server must access the Oracle Internet Directory server using the virtual IP. To do this:

    1. In a text editor, open the dip-config.xml file located in the DOMAIN_HOME/config/fmwconfig/servers/wls_ods1/applications/DIP_<version_number>/configuration directory.

      For example:

      MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/
      wls_ods1/applications/DIP_11.1.1.2.0/configuration
      
    2. Enter the following value to set the LDAP address to the virtual IP:

      <OID_NODE_HOST>cfcvip.example.com</OID_NODE_HOST>
      
  3. An Oracle Directory Services Manager instance managing the Oracle Internet Directory server in Section 12.2.3.10.1, "Transforming Oracle HTTP Server" must use the virtual IP to connect to the Oracle Internet Directory server.

    For example, from the Oracle Directory Services Manager screen, verify that you can connect to Oracle Internet Directory using the virtual server by following these steps:

    1. Select the Connect to a directory --> Create A New Connection link in the upper right hand corner.

    2. In the New Connection screen, fill in the connection information below and click Connect:

      • Directory Type: OID

      • Name: OIDHA

      • Server: cfcvip.example.com

      • Port: 389

      • SSL Enabled: Leave blank

      • User Name: cn=orcladmin

      • Password: ********

      • Start Page: Home (default)

12.2.4.2 Transforming Oracle Virtual Directory and Its Clients

This section describes how to transform Oracle Virtual Directory and its clients. It includes the following topics:

12.2.4.2.1 Transforming Oracle Virtual Directory

To transform an Oracle Virtual Directory server:

  1. In a text editor, open the listeners.os_xml file in the ORACLE_INSTANCE/config/OVD/componentname directory.

  2. Enter the following value to set the LDAP address to the virtual IP:

    <host>cfcvip.example.com</host>
    
  3. Restart the Oracle Virtual Directory server using opmnctl.

    For example:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
    ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1
    
12.2.4.2.2 Generating a New Key for the Keystore

Admin should generate a new key pair with the virtual hostname (self-signed or signed by CA) and associate this certificate in OVD listener configuration. This certificate should also be trusted by EMAgent for which it should be imported as a trusted cert in EMAgent's cwallet.sso.

For more information, see Section 8.3.5.2, "Generating a New Key for the Keystore Using WLST".

If you select a different keystore or change the certificate in the keystore for the Admin Gateway Listener or the LDAP SSL Endpoint Listener, you must import the certificate into the Oracle Enterprise Manager Fusion Middleware Control Agent's wallet. If you do not import the certificate, Oracle Enterprise Manager Fusion Middleware Control cannot connect to Oracle Virtual Directory to retrieve performance metrics.

To import the certificate into the Oracle Enterprise Manager Fusion Middleware Control Agent's wallet:

  1. Export the Oracle Virtual Directory server certificate by executing the following command:

    ORACLE_HOME/jdk/jre/bin/keytool -exportcert \
    -keystore OVD_KEYSTORE_FILE -storepass PASSWORD \
    -alias OVD_SERVER_CERT_ALIAS -rfc \
    -file OVD_SERVER_CERT_FILE
    
  2. Add the Oracle Virtual Directory server certificate to the Oracle Enterprise Manager Fusion Middleware Control Agent's Wallet by executing the following command:

    ORACLE_COMMON_HOME/bin/orapki wallet add -wallet \
    $ORACLE_INSTANCE/EMAGENT/EMAGENT/sysman/config/monwallet \
    -trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD
    
12.2.4.2.3 Transforming Oracle Virtual Directory Clients

All clients of Oracle Virtual Directory must use the virtual IP cfcvip.example.com to access Oracle Virtual Directory. For example, when using Oracle Directory Services Manager to administer a Cold Failover Cluster Oracle Virtual Directory instance, create a connection using cfcvip.example.com as the location of the Oracle Virtual Directory instance.

12.2.4.3 Transforming Oracle Directory Integration Platform and Oracle Directory Services Manager and Their Clients

This section describes how to transform Oracle Directory Integration Platform, Oracle Directory Services Manager, and their clients.

12.2.4.3.1 Transforming Oracle Directory Integration Platform and Oracle Directory Services Manager

Oracle Directory Integration Platform and Oracle Directory Services Manager are deployed to a Managed Server. The procedure for CFC transformation is to configure the Managed Server to which they are deployed to listen on the cfcvip.example.com virtual IP. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the WLS_ODS managed server to listen on the cfcvip.example.com virtual IP.

12.2.4.3.2 Transforming Oracle Directory Integration Platform and Oracle Directory Services Manager Clients

Follow these steps to transform Oracle Directory Integration Platform and Oracle Directory Services Manager clients:

  1. Clients of Oracle Directory Integration Platform and Oracle Directory Services Manager must use the virtual IP cfcvip.example.com to access these applications.

  2. When Oracle HTTP Server is the front end for Oracle Directory Services Manager, the WebLogic configuration for Oracle Directory Services Manager must specify the virtual IP cfcvip.example.com as the address for the WLS_ODS Managed Server. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used by Oracle HTTP Server and Oracle Directory Services Manager. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

    #Oracle Directory Services Manager
    <Location /odsm>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    

12.2.4.4 Transforming Oracle Identity Federation and Its Client

This section describes how to transform Oracle Identity Federation and its clients.

12.2.4.4.1 Transforming Oracle Identity Federation

Oracle Identity Federation is a component that is deployed to a Managed Server. The procedure for Cold Failover Cluster transformation is to configure the Managed Server to which it is deployed to listen on the cfcvip.example.com virtual IP. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the WLS_OIF Managed Server to listen on the cfcvip.example.com virtual IP. Since Oracle Identity Federation Cold Failover Cluster deployments are likely to be split into Service Provider and Identity Provider, more than one instance of WLS_OIF is likely to exist in a given deployment. Use the same Cold Failover Cluster procedure for both WLS_OIF instances.

After configuring the Managed Server to listen on the cfcvip.example.com virtual IP, log into the Oracle Enterprise Manager Fusion Middleware Control and perform these steps:

  1. Go to Farm > Identity and Access > OIF.

  2. In the right frame, go to Oracle Identity Federation > Administration and then make these changes:

    1. Server Properties: change the host to cfcvip.example.com

    2. Identity Provider > Common: change the providerId to cfcvip.example.com

    3. Service Provider > Common: change the providerId to cfcvip.example.com

    4. Data Stores: If LDAP is the data store, then replace the value of Connection URL for User Data Store and Federation Data Store with cfcvip.example.com

    5. Authentication Engines > LDAP Directory: Set the ConnectionURL to cfcvip.example.com

  3. Restart the managed server so that the metadata generates.

12.2.4.4.2 Transforming Oracle Identity Federation Clients

Follow these steps to transform Oracle Identity Federation clients:

  1. Clients of Oracle Identity Federation must use the virtual IP cfcvip.example.com to access these applications.

  2. When Oracle HTTP Server is the front end for Oracle Identity Federation, the WebLogic configuration for Oracle Identity Federation must specify the virtual IP cfcvip.example.com as the address for the WLS_OIF Managed Server. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used by Oracle HTTP Server and Oracle Identity Federation. For example, use a text editor to make the following edits in the oif.conf file:

    #Oracle Identity Federation
    <Location /oif>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    

12.2.4.5 Transforming an Oracle SOA Suite

Oracle SOA Suite is made up of Java EE components deployed to a managed server. The typical configuration has deployments of OWSM-PM applications and SOA applications. The SOA applications are always deployed to a separate managed server. In many Cold Failover Cluster deployments OWSM-PM is deployed to the Administration Server, however, they can be deployed to a managed server by itself, for example, WLS_OWSM, or to the SOA managed server. The WLS_SOA container may have applications such as BPEL, UMS, and B2B deployed or may additionally have the BPM components deployed as well. In all cases, since these are Java EE components, the Cold Failover Cluster transformation procedure involves configuring the managed server to which they are deployed to listen on the virtual IP. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming managed servers WLS_OWSM and WLS_SOA.

In addition, follow these steps to transform a SOA component managed server:

  1. Set the front-end host for WLS_SOA managed server to cfcvip.example.com.

    1. Log into the Administration Console.

    2. In the Environment section, select Servers.

    3. Select the name of the managed server.

    4. Select Protocols, then select HTTP.

    5. In the Frontend Host field, enter the hostname as cfcvip.example.com.

    6. Set the Frontend Port to the HTTP port

    7. Click Save.

    8. Activate the changes.

    9. Restart the Managed Server.

    Note:

    For a detailed description of transferring already deployed composites to CFC, see section "Recovering Oracle SOA Suite After Loss of Host" in the Oracle Fusion Middleware Administrator's Guide.

  2. When using Oracle HTTP Server as the front end, the mod WebLogic configuration for the applications deployed to WLS_OWSM and WLS_SOA should provide the VIP cfcvip.example.com as the address of these managed server. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used by SOA components. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

    #SOA soa-infra app
    <Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    # SOA inspection.wsil
    <Location /inspection.wsil>
    SetHandler weblogic-handler
    </Location>
     
    # Worklist
    <Location /integration>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    # B2B
    <Location /b2bconsole>
    SetHandler weblogic-handler
    </Location>
     
    # UMS
    <Location /sdpmessaging/ >
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    # UMS WS
    <Location /ucs/messaging/webservice >
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogic port
    </Location>
     
    # UMS prefs
    <Location /sdpmessaging/userprefs-ui>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    # Default to-do taskflow
    <Location /workflow/DefaultToDoTaskFlow>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    # Workflow
    <Location /workflow>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    #Required if attachments are added for workflow tasks
    <Location /ADFAttachmentHelper>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
    
    # SOA composer application
    <Location /soa/composer>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    # BPM
    <Location /bpm/composer>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    # BPM
    <Location /bpm/workspace>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
    
    # BAM Web Application
    <Location /OracleBAM >
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    <Location /OracleBAMWS >
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogicPort port
    </Location>
     
    # WSM
    <Location /wsm-pm>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogic port
    </Location>
    

12.2.4.6 Transforming Oracle Access Manager and Its Clients

This section describes how to transform Oracle Access Manager to work in a Cold Failover Cluster environment.

As with other managed servers created using Configuration Wizard, a Cold Failover Cluster set up that requires the managed server to listen on a virtual IP can be done during the initial creation and by specifying the listen address of the managed server as the virtual hostname (cfcvip.example.com). In this case, the explicit transformation step is not needed.

12.2.4.6.1 Transforming Oracle Access Manager

Oracle Access Manager is deployed to a managed server (for example, WLS_OAM1) and the procedure for CFC transformation is to configure this managed server to listen on the virtual IP cfcvip.example.com. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the WLS_OAM1 managed server to listen on the cfcvip.example.com virtual IP. All other requirements related to the placement of the Middleware Home and other related domain artifacts on a shared storage that can be failed over apply, as described in Section 12.2.1, "Cold Failover Cluster Requirements."

The Oracle Access Manager console is deployed as part of the Administration Server for the domain. For Cold Failover Cluster configuration of this console, the whole Administration Server needs to be configured in Active Passive. The Administration Server can share the same virtual IP cfcvip.example.com, or you can configure it to fail over independently using a separate virtual IP and shared disk. If they are using the same virtual IP, the Administration Server and the Oracle Access Manager managed server will fail over as a unit.

12.2.4.6.2 Transforming Oracle Access Manager Clients

Follow these steps to transform Oracle Access Manager clients:

  1. Clients of Oracle Access Manager must use the virtual IP cfcvip.example.com to access these applications. Any wiring done with other components such as Oracle Identity Manager and Oracle Adaptive Access Manager should also use the virtual IP cfcvip.example.com to access the applications.

  2. When Oracle HTTP Server is the front end for Oracle Access Manager, the mod webLogic configuration for Oracle Access Manager must specify the virtual IP cfcvip.example.com as the address for the Oracle Access Manager managed server. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

    #Oracle Access Manager
    <Location /oam>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com:port
    </Location>
    
  3. When the Oracle Access Manager console as part of the Oracle Administration Server is also configured to be Active Passive, and the Administration Server is configured to be front-ended by Oracle HTTP Server, you must change the WebLogic host configuration in the webserver proxy plugin configuration files. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

    #Oracle Access Manager Admin Console deployed to the Admin Server
    <Location /oamconsole>
        SetHandler weblogic-handler
        WebLogicHost ADMINVHN
        WebLogicPort 7001
    </Location>
    

12.2.4.7 Transforming Oracle Adaptive Access Manager and Its Clients

This section describes how to transform Oracle Adaptive Access Manager to work in a Cold Failover Cluster environment.

As with other managed servers created using Configuration Wizard, a Cold Failover Cluster set up that requires the managed server to listen on a virtual IP can be done during the initial creation as well by specifying the listen address of the managed server as the virtual hostname (cfcvip.example.com). In this case, the explicit transformation step is not needed.

12.2.4.7.1 Transforming Oracle Adaptive Access Manager

Oracle Adaptive Access Manager is deployed to managed servers, both deployed to fail over as a single unit, and therefore sharing the same virtual IP and the same shared storage. The procedure to convert the OAAM Admin managed server and the OAAM Server managed server for CFC transformation is to configure these managed servers to listen on the virtual IP cfcvip.example.com. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure these managed servers to listen on the cfcvip.example.com virtual IP. All other requirements related to the placement of the Middleware Home and other related domain artifacts on a shared storage that can be failed over apply, as described in Section 12.2.1, "Cold Failover Cluster Requirements."

12.2.4.7.2 Transforming Oracle Adaptive Access Manager Clients

Follow these steps to transform Oracle Adaptive Access Manager clients:

  1. Clients of Oracle Adaptive Access Manager must use the virtual IP cfcvip.example.com to access these applications. Any wiring done with other components such as Oracle Access Manager and Oracle Identity Manager should also use the virtual IP cfcvip.example.com to access the applications.

  2. When Oracle HTTP Server is the front end for Oracle Adaptive Access Manager, the mod webLogic configuration for Oracle Adaptive Access Manager must specify the virtual IP cfcvip.example.com as the address for the Oracle Adaptive Access Manager managed servers. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

    #Oracle Adaptive Access Manager
    <Location /oaam_server>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com WebLogicPort port
    </Location>
    
    #Oracle Adaptive Access Manager Admin Console
    <Location /oaam_admin>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com:port
    </Location>
    

12.2.4.8 Transforming Oracle Identity Manager and Its Clients

This section describes how to transform Oracle Identity Manager to work in a Cold Failover Cluster environment.

As with other managed servers created using Configuration Wizard, a Cold Failover Cluster set up that requires the managed server to listen on a virtual IP can be done during the initial creation as well by specifying the listen address of the managed server as the virtual hostname (cfcvip.example.com). In this case, the explicit transformation step is not needed.

12.2.4.8.1 Transforming Oracle Identity Manager

Oracle Identity Manager is deployed to managed servers. The typical CFC deployment will have the Oracle Identity Manager managed server and the another managed server with Oracle SOA and Oracle Web Services Manager deployed to fail over as a single unit and therefore sharing the same virtual IP and the same shared storage. The procedure to convert both these managed server for CFC transformation is to configure this managed servers to listen on the virtual IP cfcvip.example.com. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure these managed servers to listen on the cfcvip.example.com virtual IP. All other requirements related to the placement of the Middleware Home and other related domain artifacts on a shared storage that can be failed over apply, as described in Section 12.2.1, "Cold Failover Cluster Requirements."

12.2.4.8.2 Transforming Oracle Identity Manager Clients

Follow these steps to transform Oracle Identity Manager clients:

  1. Clients of Oracle Identity Manager must use the virtual IP cfcvip.example.com to access these applications. Any wiring done with other components such as Oracle Access Manager and Oracle Adaptive Access Manager should also use the virtual IP cfcvip.example.com to access the applications. Since SOA is also configured to fail over with Oracle Identity Manager, the wiring from Oracle Identity Manager to SOA should also use the common virtual IP.

  2. When Oracle HTTP Server is the front end for Oracle Identity Manager, the mod webLogic configuration for Oracle Identity Manager must specify the virtual IP cfcvip.example.com as the address for the managed servers. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file or oim.conf file:

    #Oracle Identity Manager
    <Location /oim>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com:port
        WebLogicPort port
    </Location>
    

    Refer to Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for more information about making configuration changes in Oracle Identity Manager.

12.2.4.9 Transforming an Oracle WebCenter Portal Suite

The WebCenter Suite is made up of Java EE components. The typical WebCenter Suite deployment has four managed servers, though more are possible if you develop WebCenter Portal applications. Typical managed server deployments include:

  • WC_Spaces

  • WC_Portlet

  • WC_Collaboration

  • WC_Utilities

These are Java EE components, therefore, the procedure for Cold Failover Cluster transformation is to configure the Managed Server they are deployed to so that it listens on the Virtual IP. In many Cold Failover Cluster deployments of Oracle WebCenter Portal, OWSM-PM may be deployed to WC_PORTLETS and WC_SPACES container. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming Oracle WebCenter Portal Suite managed servers.

When you use Oracle HTTP Server as the front end, the mod_weblogic configuration for WebCenter Suite applications should provide the VIP cfcvip.example.com as the managed servers address instead. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points that WebCenter components use.

To use a virtual host as the managed servers' address:

  1. Click Environment >Servers > Control.

  2. Except for the Administration Server, stop all servers that are running.

  3. After all the servers have stopped, click Configuration.

  4. Click Lock & Edit

  5. For each server in the list, do the following:

    • Change the machine name to the VIP machine address cfcvip.example.com

    • Change the Listen Address to the VIP address cfcvip.example.com

    • Click Save

  6. After all the serves are set to run on the Virtual Host, click Activate Changes.

  7. Restart the servers

12.2.4.10 Transforming Oracle Portal, Forms, Reports, and Discoverer

Cold Failover Cluster configuration varies for each Oracle Portal, Forms, Reports, and Discoverer component. This section documents the steps for Cold Failover Cluster transformation of Oracle Portal, Forms, Reports, and Discoverer.

12.2.4.10.1 Transforming Oracle Forms for Cold Failover Cluster

Oracle Forms is made up of both Java EE and system components. To configure Oracle Forms for Cold Failover Cluster:

Note:

The transformation process requires that you shutdown the domain before editing these files.

  1. Transform the WLS_FORMS managed server. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for this procedure. Start the Domain Administration Server to do the Managed server transformation, and shut it down once the Managed Server transformation is finished.

  2. Transform the Oracle Forms OPMN. See Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" for this procedure.

  3. Transform Enterprise Manager. See Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance" for this procedure.

  4. Transform Oracle Forms Web tier components. See Section 12.2.3.10, "Transforming Web Tier Components and Clients" for this procedure.

  5. Reregister Single Sign-On using the steps described in the Section 12.2.4.15, "Single Sign-On Reregistration (If required)"

  6. In the forms.conf file located in the ORACLE_INSTANCE/config/OHS/component_name/moduleconf directory, change the mod weblogic configuration.

  7. Start the Administration Server and Managed Servers in the WebLogic Domain as well as the Oracle instances to validate the Cold Failover Cluster installation:

    <Location /forms>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
        DynamicServerList OFF
    </Location>
    
12.2.4.10.2 Transforming Oracle Reports for Cold Failover Cluster

Oracle Reports is made up of both Java EE and system components. To configure Oracle Reports for Cold Failover Cluster:

  1. Transform the WLS_REPORTS managed server. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for this procedure. Start the Domain Administration Server to do the Managed Server transformation, and shut it down once the Managed Server transformation is finished.

  2. Transform the Oracle Reports OPMN. See Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" for this procedure.

    In addition, do the following:

    1. In the opmn.xml file, located in the ORACLE_INSTANCE/config/OPMN/opmn directory, replace the physical_hostname with virtual_hostname for the Reports server name in ias-component to reflect its new name.

      From:

      <ias-component id="ReportsServer_<physical_hostname>_<instance_name>">
      ...
         <process-set id="ReportsServer_<physical_hostname>_<instance_name>" restart-on-death="true" numprocs="1">
      ...
         </process-set>
      ...
      </ias-component>
      

      To:

      <ias-component id="ReportsServer_<virtual_hostname>_<instance_name>">
      ...
         <process-set id="ReportsServer_<virtual_hostname>_<instance_name>" restart-on-death="true" numprocs="1">
      ...
        </process-set>
      ...
      </ias-component>
      

      For Example:

      <ias-component id="ReportsServer_cfcvip_asinst1">
      ...
       <process-set id="ReportsServer_cfcvip_asinst1" restart-on-death="true" numprocs="1">
      ...
       </process-set>
      ...
      </ias-component>
      
    2. In DOMAIN_HOME/opmn/topology.xml of the Administration Server domain home, change all occurrences of the Report server name from ReportsServer_<physical_hostname>_<instance_name> (example: ReportsServer_node1_asinst) to ReportsServer_<virtual_hostname>_<instance_name> (example: ReportsServer_cfcvip_asinst).

  3. Transform Oracle Enterprise Manager. See Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance" for this procedure.

  4. Transform Oracle Reports Web tier components. See Section 12.2.3.10, "Transforming Web Tier Components and Clients" for this procedure.

  5. Reregister Single Sign-On. To do this perform the steps described in the Section 12.2.4.15, "Single Sign-On Reregistration (If required)".

  6. In the reports_ohs.conf file located in the ORACLE_INSTANCE/config/OHS/component_name/moduleconf directory, change the following:

    <Location /reports>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    
  7. In the directory ORACLE_INSTANCE/config/ReportsServerComponent, rename the following directory:

    ReportsServer_physical_hostname_instance_name (for example: ReportsServer_node1_asinst1)
    

    To the following:

    ReportsServer_VIP_instance_name (for example: ReportsServer_cfcvip_asinst1)
    

    Note:

    All new logs for the report server go to ReportsServer_virtual_hostname_instance_name after restart of the instance.

  8. In the renamed directory, replace physical hostname with a virtual hostname in the following files:

    • component-logs.xml

    • logging.xml

  9. In the targets.xml file, located in the ORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/emd directory, change the following:

    1. Change all hostnames from node1.example.com to cfcvip.example.com

    2. Change the report server name from ReportsServer_<physical_hostname>_<instance_name> (for example: ReportsServer_node1_asinst1) to ReportsServer_<virtual_hostname>_<instance_name> (for example: ReportsServer_cfcvip_asinst1) for the following two elements:

      Target TYPE="oracle_repserv"

      Target TYPE="oracle_repapp"

  10. In the ORACLE_INSTANCE/reports directory, replace the physical hostname with a virtual hostname in reports_install.properties.

  11. In the ORACLE_INSTANCE/reports/server directory, rename the following files:

    • Rename reportsserver_physical_hostname_instance name.dat to reportsserver_virtual_ hostname_instance_name.dat

    • Rename rep_wls_reports_physical_ hostname_instance_name.dat to rep_wls_reports_virtual_hostname_instance_name.dat

  12. In the DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_<version_number>/1ww4ab/configuration directory (for example, the DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww4ab/configuration directory), replace physical hostname with virtual hostname in the rwservlet.properties file (including changes to any occurrence of the reports server name).

  13. In the DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_<version_number>/1ww4ab/META-INF directory (for example, the DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww4ab/META-INF directory), replace physical hostname with virtual hostname in the mbeans.xml file (including changes to any occurrence of the reports server name).

  14. Start the Administration Server and Managed Servers in the WebLogic Domain, as well as the Oracle instances to validate the Cold Failover Cluster installation.

12.2.4.10.3 Transforming Oracle Discoverer for Cold Failover Cluster

Oracle Discoverer is made up of both Java EE and system components. To configure Oracle Discoverer for Cold Failover Cluster:

  1. Transform the WLS_DISCO managed server. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for this procedure. Start the domain Administration Server to do the Managed Server transformation, and shut it down once the Managed Server transformation is finished.

  2. Transform the Oracle Discoverer OPMN. See Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" for this procedure.

  3. Transform Oracle Enterprise Manager. See Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance" for this procedure.

  4. Transform Oracle Discoverer Web tier components. See Section 12.2.3.10, "Transforming Web Tier Components and Clients" for this procedure.

  5. Reregister Single Sign-On. To do this perform the steps described in the Section 12.2.4.15, "Single Sign-On Reregistration (If required)".

  6. In the module_disco.conf file located in the ORACLE_INSTANCE/config/OHS/ohs1/module_disco.conf directory, change the following:

    <IfModule mod_weblogic.c><Location /discoverer>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogiPort port
        DynamicServerList ON
    </Location>
    </IfModule>
    
  7. Start the Administration Server and Managed Servers in the WebLogic Domain, as well as the Oracle instances to validate the Cold Failover Cluster installation.

12.2.4.10.4 Transforming Oracle Portal for Cold Failover Cluster

Oracle Portal is made up of both Java EE and system components. To configure Oracle Portal for Cold Failover Cluster:

  1. Transform the WLS_PORTAL managed server. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for this procedure. Start the domain Administration Server to do the Managed Server transformation, and shut it down once the Managed Server transformation is finished.

  2. Transform the Oracle Portal OPMN. See Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" for this procedure.

  3. Transform Oracle Enterprise Manager. See Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance" for this procedure.

  4. Transform Oracle Portal Web tier components. See Section 12.2.3.10, "Transforming Web Tier Components and Clients" for this procedure.

  5. Reregister Single Sign-On. To do this, perform the steps described in the Section 12.2.4.15, "Single Sign-On Reregistration (If required)".

  6. In the portal.conf file located in the ORACLE_INSTANCE/config/OHS/component_name/moduleconf, change the mod weblogic configuration:

    # WLS routing configuration
    <Location /portal>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    
    <Location /portalTools>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    
    <Location /wsrp-tools>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    
    <Location /richtextportlet>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    
    <Location /jpdk>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    
    <Location /portalHelp>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    
    <Location /portalHelp2>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location> 
    
  7. Start the Administration Server and Managed Servers in the WebLogic Domain, as well as the Oracle instances to validate the Cold Failover Cluster installation.

  8. Rewire the Portal Repository:

    1. Log into the domain WebLogic Server Enterprise Manager using the following URL:

      http://cfcvip.example.com:7001/em

    2. Change InValidation and Administrator password.

      In the Navigator Window Expand the Web Tier tree.

      Click the Web Cache component_name.

      From the drop-down list at the top of the page, select Administration - Passwords.

      Enter a new invalidator password, confirm it, and click Apply.

      Enter a new administrator password, confirm it and click Apply.

    3. Expand the Fusion Middleware menu in the left pane.

    4. Select Classic.

    5. Click Portal (WLS_PORTAL).

      The Portal Domain information page appears.

    6. Right-click on Portal and select Settings, and then Wire Configuration.

    7. Enter the following information for Portal Middle Tier

      Host: Enter the Cold Failover Cluster Virtual IP name of the Web Cache host cfcvip.example.com.

      Port: Enter the Web Cache port being used (HTTP or non HTTP)

      SSL Protocol: Check this box if appropriate.

    8. Enter the following information for Web Cache:

      Host: Enter the Cold Failover Cluster Virtual IP name of the Web Cache host cfcvip.example.com mysite.example.com

      Invalidation port: Enter the Invalidation port, for example, 9401.

      Invalidation User Name: Enter the user name for Portal invalidations.

      Invalidation Password: Enter the password for this account.

    9. Click Apply to start the rewire.

    10. When the rewire is complete, click the Portal menu option again, and ensure that the Portal URL is now the following:

      https://cfcvip.example.com:WCHTTPPort/portal/pls/portal

  9. Change Host Assertion in Oracle WebLogic Server.

    Because the Oracle HTTP Server acts as a proxy for WebLogic, by default certain CGI environment variables, including the host and port, are not passed through to WebLogic. To ensure that WebLogic is aware that it is using a virtual site name and port so that it can generate internal URLs appropriately:

    1. Log in to the Administration Console using the following URL:

      http://cfcvip.example.com:7001/console

    2. Select Environment, Servers, and then WLS_PORTAL.

    3. In the Change Center, click Lock & Edit.

    4. Click Protocols, and select HTTP.

    5. Enter the following values:

      Frontend Host: cfcvip.example.com

      Frontend HTTP Port: WCHTTPPort (8090)

      Frontend HTTPS Port: WCHTTPSPort (8094)

      This ensures that any HTTPS URLs created from within WebLogic are directed to port 443 on the load balancer.

    6. Click Save.

    7. Click Activate Changes in the Change Center window to enable editing.

    8. Restart the WLS_PORTAL managed server

12.2.4.10.5 Transforming Oracle Business Activity Management (BAM)

Oracle BAM is made up of Java EE components deployed to a managed server. Since these are Java EE components, the Cold Failover Cluster transformation procedure involves configuring the managed server to which they are deployed to listen on the virtual IP. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming managed servers WLS_BAM.

When using Oracle HTTP Server as the front end, the mod WebLogic configuration for the applications deployed to WLS_BAM should provide the VIP cfcvip.example.com as the address of these managed server. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used by SOA components. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

# BAM Web Application
<Location /OracleBAM >
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogic port
</Location>
12.2.4.10.6 Transforming a Custom ADF Deployment

For a deployment that uses a custom ADF application, use Cold Failover Cluster in the same way as any Fusion Middleware deployment. The domain is created in this case using the installation from Oracle Application Developer DVD. Since this is primarily a Java EE components. the Cold Failover Cluster transformation procedure involves configuring the managed server to which they are deployed to listen on the virtual IP. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming managed servers.

When using Oracle HTTP Server as the front end, the mod WebLogic configuration for the applications deployed to WLS_ADF (the name of the managed server for the customer app) should provide the VIP cfcvip.example.com as the address of these managed server. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used by SOA components. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

# BAM Web Application
<Location /ADFApplicationMountPoint >
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogic port
</Location>

12.2.4.11 Transforming Oracle WebCenter Content

The Oracle WebCenter Content has products such as Oracle WebCenter Content: Imaging (Imaging), Oracle WebCenter Content: Information Rights, Oracle WebCenter Content (WebCenter Content), Oracle WebCenter Content: Records, and Oracle WebCenter content: Inbound Refinery.

These managed servers are typically included when you install Oracle WebCenter Content:

  • Imaging (WLS_IPM)

  • WebCenter Content (WLS_UCM)

  • Records (WLS_URM)

  • Inbound Refinery (WLS_IBR)

  • Information Rights (WLS_IRM)

For Cold Failover deployments, the recommendation is to set up the Application tier and the Web tier as recommended for CFC deployments in previous sections of this chapter, and to follow the procedure for Cold Failover Cluster transformation for these managed servers. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming Imaging, UCM, and IBR managed servers.

Additional things to consider in Cold Failover Cluster deployments of Oracle WebCenter Content include:

  • In many Cold Failover Cluster deployments of Oracle WebCenter Content, the likely deployment topologies include:

    • All WebCenter Content components deployed together on one node of a hardware cluster and failing over together.

    • Components distributed across both nodes and configured for mutual failover.

  • All I/PM related files that need to be available when the I/PM server fails over should also be on the shared disk. This includes files such as the input files and the images. These should always be on the shared disk so they are accessible from all nodes of a CFC configuration. It is recommended that there is a separate volume for the input files and the image files.

  • All persistence stores such as one used by JMS and TLogs should also be on the shared disk.

  • All restrictions related to Inbound Refinery continue to apply in a CFC configuration. For information on configuring Inbound Refinery instances, refer to Oracle Fusion Middleware Administrator's Guide for Conversion.

  • All content related folders for UCM should be on a shared disk as well, which will fail over as a unit along with the UCM server configuration. This includes folders such as:

    • Content server instance folder

    • Native File repository location

    • Web Layout folder

  • When configuring UCM or URM using http://cfcvip.example.com:port/cs, the Webserver HTTP Address is the hostname and port of the location of the HTTP server front-ending the WCC managed servers. Modify HTTP Server address to be cfcvip.example.com:

    1. Open DOMAIN_HOME/ucm/cs/config/config.cfg

    2. Modify HttpServerAddress to cfcvip.example.com:por

    3. Save the modified config.cfg file and restart the Oracle WebCenter Content servers for the changes to take effect.

  • Depending on the high availability configuration of the HTTP server this can be a load balancer address, physical host or a virtual host. In the case where Oracle HTTP Server is also in a CFC deployment, the above value should be set to the virtual IP of the Oracle HTTP Server. When Oracle HTTP Server is collocated on the same hardware cluster as the WCC servers, this is likely to be cfcvip.example.com.

  • To add the Listen Addresses to the List of Allowed Hosts in Oracle WebCenter Content, add the IP address of cfcvip.example.com in DOMAIN_HOME/ucm/cs/config/config.cfg as follows:

    SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|<your.cfcvip.example.com.IP.address
    

    This field accepts wildcards in the value, for example 10.*.*.*.. You can change this value later by setting SocketHostAddressSecurityFilter.

    See Oracle WebCenter Content Quick Installation Guide for the details if you are using SocketHostNameSecurityFilter instead of SocketHostAddressSecurityFilter. Save the modified config.cfg file and restart the Oracle WebCenter Content servers for the changes to take effect.

  • In cases where UCM is configured to be in a Cold Failover Cluster (including the example above), when I/PM is wired to UCM, the recommendation is to use the virtual IP_Address of UCM. When doing this configuration using http://cfcvip.example.com:port/imaging:

    1. In the left-hand pane, click Manage Connections, and then Create Content Server Connection.

    2. Enter a name and description for the new connection, and then click Next.

    3. In the Connection Settings screen, enter the following:

      • SSL: Unchecked (Default)

      • Use Local Content Server : checked (Default

      • Server Port : 4444 (Default)

        Under Content Server Pool:, click Add and enter Host Name or IP address of the Content Server . Enter cfcvip.example.com.

      • Port: 4444 (Default)

      Click Next.

    4. In the connection security screen, leave the default selections for the WebLogic user, and then click Next.

    5. Review the connection details and click Submit.

  • To set the Server URL Configuration Parameter for Oracle IRM and change the Managed Server URL, see Oracle WebCenter Content Quick Installation Guide. For example:

    https://cfcvip.example.com:managedServerPort/irm_desktop
    
  • To transform Inbound Refinery for Cold Failover deployments check and modify as follows:

    1. Open DOMAIN_HOME/ucm/ibr/config.cfg

    2. To add the Listen Addresses to the List of Allowed Hosts in Inbound Refinery, add the IP address of cfcvip.example.com:

      SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|<your.cfcvip.example.com.IP.address

    3. Modify HTTP Server address to be cfcvip.example.com:

      HttpServerAddress=cfcvip.example.com:port

    4. Save the config.cfg file and restart the Oracle Inbound Refinery servers for the changes to take effect.

  • In addition, when Oracle HTTP Server is the front end for Oracle WebCenter Content applications, the mod_weblogic configuration should use the VIP cfcvip.example.com for the managed servers address. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used by WCC components. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

    # Content Server
    <Location /cs>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
        WLCookieName IDCCS_SESSIONID
    </Location>
     
    # URM
    <Location /urm>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
        WLCookieName IDCURM_SESSIONID
    </Location>
     
    # IBR
    <Location /ibr>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
        WLCookieName IDCIBR_SESSIONID
    </Location>
     
    # IPM
    <Location /imaging>
        SetHandler weblogic-handler
        WebLogicHost cfcvip.example.com
        WebLogic port
    </Location>
    
    # IRM
    <Location /irm_rights>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.example.com
    WebLogic port
    </Location>
    

12.2.4.12 Transforming Oracle Business Intelligence

Oracle Business Intelligence is an integrated business intelligence (BI) solution that provides the business user with a complete picture across the entire organization. Oracle Business Intelligence is designed to quickly and easily integrate diverse data sources, find information from the database, share the database information, and exploit the data to learn more about the business and its customers.

This section describes active-passive high availability for Oracle Business Intelligence Enterprise Edition, Oracle Business Intelligence Publisher and Oracle Real-Time Decisions.

Requirements for Transforming Oracle Business Intelligence

Before you transform Oracle BI, you must ensure that any OPMN revisions you made to transform OPMN take effect. (Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" describes the OPMN transformation steps you followed.)

To force OPMN revisions to take effect:

  1. Restart the Administration Server.

  2. Restart OPMN. See Using OPMN in the Oracle Fusion Middleware Oracle Process Manager and Notification Server Administrator's Guide for more information on restarting OPMN.

This section includes the following topics:

12.2.4.12.1 Transforming Oracle Business Intelligence Enterprise Edition and its Clients

This section describes how to transform Oracle Business Intelligence Enterprise Edition (Oracle BI EE) to work in a Cold Failover Cluster environment.

Transform Managed Server

Oracle BI Enterprise Edition is deployed to a managed server (for example, BI_SERVER1) and the procedure for Cold Failover Cluster transformation is to configure this managed server after install to listen on the virtual IP cfcvip.example.com. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.example.com virtual IP. After these steps, restart the managed server using the Administration Console or the WLST command line.

All requirements for placing the Middleware Home and other related domain artifacts on shared storage that can be failed over apply as Section 12.2.1, "Cold Failover Cluster Requirements" describes. The specific requirement for Cold Failover Cluster deployments of the Oracle BI Enterprise Edition is to ensure that the following artifacts are also on the shared disk and available on the same mount points on both nodes of the failover cluster. When configured in the default install, this happens implicitly:

  • BIEE Presentation Catalog

  • BIEE Repository Publishing Directory (RPD)

To transform an Oracle BI EE component managed server:

  1. Edit the biee-domain.xml file to replace the hostname with cfcvip.example.com. The biee-domain.xml file is located in this directory:

    MW_HOME/user_projects/domains/bifoundation_domain/config/fmwconfig
    
  2. Set the front-end host for the BI_SERVER managed server to cfcvip.example.com.

    1. Log into the Administration Console.

    2. In the Change Center, click Lock & Edit.

    3. In the Environment section, select Servers.

    4. Select the name of the managed server.

    5. Select Protocols, then select HTTP.

    6. In the Frontend Host field, enter the hostname as cfcvip.example.com.

    7. Set the Frontend Port to the HTTP port

    8. Click Save.

    9. Activate the changes.

    10. Restart the Managed Server.

Transforming System Components

To transform system components:

  1. Log into Oracle Fusion Middleware Console for the domain.

  2. Go to Business Intelligence > Core Application > Capacity Management > Scalability.

  3. For the Oracle Instance (instance1), change the ListenAddress to cfcvip.example.com.

  4. Click Lock and Edit Configuration and change the Listen Address to cfcvip.example.com.

  5. Click Apply.

  6. Click Activate Changes.

  7. Restart both the Managed servers and the System components (using opmnctl).

Transforming Oracle BI Enterprise Edition Clients

Note:

Change data sources that refer to the BI Enterprise Edition instance before you transform the managed server to CFC. See step 4.

To transform Oracle BI Enterprise Edition clients:

  1. Oracle BI Enterprise Edition clients must use the virtual IP cfcvip.example.com to access these applications.

  2. Since WSM-PM is deployed to the same managed server, ensure that the client side configuration changes required for WSM-PM are also complete.

  3. Configure other components in the BI Enterprise Edition product suite, such as Oracle BI Publisher, that use Oracle BI Enterprise Edition services to take advantage of these services using the virtual hostname.

  4. In BI Publisher, data sources that refer to this BI Enterprise Edition instance should change or be created (if new using the new virtual host). To change:

    1. Go to the BI Publisher Administration Console.

    2. Click JDBC Connection under Data Sources.

    3. Edit any Data source for BI Enterprise Edition for this instance to connect to cfcvip.example.com.

  5. Where BI Publisher is integrated with BIEE deployment, configure BI Publisher to discover the Presentation Services at the new virtual address. Check details for these in the BI publisher section of this chapter.

  6. When Oracle HTTP Server is the front end for Oracle BI Enterprise Edition, use a text editor to update the mod_wl_ohs.conf file to specify the virtual IP cfcvip.example.com as the address for the Oracle BI Server managed server. See the following example:

    # BIEE Analytics
    <Location /analytics>
       SetHandler weblogic-handler
       WebLogicHost cfcvip.example.com:<port>
     </Location>
    
    <Location /analytics-ws>
       SetHandler weblogic-handler
       WebLogicHost cfcvip.example.com:<port>
     </Location>
    
    <Location /bimiddleware>
       SetHandler weblogic-handler
       WebLogicHost cfcvip.example.com:<port>
     </Location>
    

Special Considerations for Windows

To achieve Cold Failover Cluster Deployment on a Windows platform:

  1. Make the shared disk available on drive (for example, E:\).

  2. Install BI EE suite (software-only install) on node1 of the Windows Cluster on E:\.

  3. Delete the software-only install from E:\ by removing the Middleware Home.

  4. Failover the same shared disk to Node2 and make it available on Node2 as the same drive (E:\).

  5. Install BI EE suite (software-only install) on Node2 of the Windows Cluster on E:\.

  6. Invoke the OUI Configuration Wizard and create the WLS domain and the Oracle Instance on E:\.

  7. On Node 1:

    1. Run regedit.

    2. Locate the node HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE.

    3. Right click on this node, click Export, and enter a filename.

    4. Locate the node HKEY_LOCAL_MACHINE\SOFTWARE\ODBC

    5. Right click on this node and click Export. Enter a file name.

    6. Locate the node HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services. Export each node within this node that starts with Oracle to a .reg file.

    7. Locate the node HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services. Export each node within this node that starts with Oracle to a .reg file.

    8. Locate the node HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Export each node within this node that begins Oracle to a .reg file

    9. Copy all the reg files that you exported to node 2.

    On Node 2:

    1. Double click on each .reg file you copied from node 1. For each file, click Yes to import the contents into the registry.

  8. Enable the Virtual IP on the current node (node2) and perform the transformation steps for this BI suite install in Section 12.2.4.12.1, "Transforming Oracle Business Intelligence Enterprise Edition and its Clients."

12.2.4.12.2 Transforming Oracle Business Intelligence Publisher and its Clients

This section describes how to transform Oracle Business Intelligence Publisher (Oracle BI Publisher) to work in a Cold Failover Cluster environment.

Transforming Oracle Business Intelligence Publisher

Note:

You must hand edit the BIP connection to BI Presentation server before transforming the managed server to CFC. Change the hostname in MW_HOME/user_projects/domains/bifoundation_domain/config/bipublisher/repository/Admin/Configuration/xmlp-server-config.xml, property SAW_SERVER.

To transform Oracle BI Publisher to work in a Cold Failover Cluster environment:

  1. Open the BI Publisher application at http://hostname:port/xmlpserver and login.

  2. Change the BI Scheduler 's JMS configuration:

    1. Click Administration.

    2. Click Scheduler Configuration (under System Maintenance)

    3. Change Weblogic JNDI URL to t3://cfcvip.example.com:9704

    4. Click Apply.

Transform Managed Server

Oracle BI Publisher is deployed to a managed server, for example, BI_SERVER1, and the procedure for Cold Failover Cluster transformation is to configure this managed server after install to listen on the virtual IP cfcvip.example.com. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.example.com virtual IP.

Then restart the managed server using the Administration Console or the WLST command line.

All requirements related to placing the Middleware Home and other related domain artifacts on shared storage that can be failed over apply as described in Section 12.2.1, "Cold Failover Cluster Requirements." The specific requirement for Cold Failover Cluster deployments of the Oracle BI Publisher is to ensure that the following artifacts are also on the shared disk and available on the same mount points on both failover cluster nodes. When configured in the default install, this happens implicitly:

  • Transaction logs and JMS persistence store

  • BI Publisher configuration folder

  • BI Publisher Catalog repository

  • BI Publisher Scheduler temp directory

BI EE Integration

When you deploy BI Publisher and BI EE together, BI Publisher is integrated to use BI EE Presentation Services. In this setup, the BI EE deployment is typically also a Cold Failover Cluster deployment listening on the same virtual hostname, cfcvip.example.com. In this case, you must change the BI Publisher configuration related to BI EE integration to ensure that BI Publisher discovers the BI EE Presentation Services on this new address. To do this:

  1. Enter the BI Publisher application URL http://hostname:port/xmlpserver and log in.

  2. Change the BI Scheduler JMS configuration:

    1. Click Administration.

    2. Click Scheduler Configuration (under System Maintenance).

    3. Change Weblogic JNDI URL to t3://cfcvip.example.com:9704

    4. Click Apply.

  3. Restart the Managed server using Admin server console or the command line.

All requirements for placing the Middleware Home and other related domain artifacts on a shared storage that can be failed over applies as Section 12.2.1, "Cold Failover Cluster Requirements" describes. The requirement for CFC deployments of Oracle Business Intelligence Publisher ensures that the following artifacts are also on the shared disk and available on the same mount points on both nodes of the failover cluster:

  • Transaction Logs and JMS persistence Store

  • BI publisher Configuration Folder

  • BI Publisher Catalog repository

  • BI Publisher Scheduler Temp Directory

Transforming Oracle BI Publisher Clients

To transform Oracle BI Publisher clients:

  1. Oracle BI Publisher clients must use the virtual IP cfcvip.example.com to access these applications.

  2. Since WSM-PM is deployed to the same managed server, ensure that the client side configuration changes required for WSM-PM are done as well.

  3. When Oracle HTTP Server is the front end for Oracle BI Publisher, use a text editor to update the mod_wl_ohs.conf file to specify the virtual IP cfcvip.example.com as the address for the Oracle BI Publisher managed server, as shown in the following example:

    # BI Publisher
    <Location /xmlpserver>
       SetHandler weblogic-handler
       WebLogicHost cfcvip.example.com:<port>
     </Location>
     
    # WSM-PM
    <Location /wsm-pm>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1:9704, APPHOST2:9704
    </Location>
    
12.2.4.12.3 Transforming Oracle Real-Time Decisions and its Clients

This section describes how to transform Oracle Real-Time Decisions (Oracle RTD) to work in a Cold Failover Cluster environment.

Transforming Oracle RTD

To transform Oracle RTD to a Cold Failover Cluster deployment, follow the instructions in this section.

Oracle RTD is deployed to a managed server (for example, BI_SERVER1) and the procedure for Cold Failover Cluster transformation is to configure this managed server after install to listen on the virtual IP cfcvip.example.com. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.example.com virtual IP.

All requirements related to the placement of the Middleware Home and other related domain artifacts on shared storage that can be failed over apply, as described in Section 12.2.1, "Cold Failover Cluster Requirements."

Transforming Oracle RTD Clients

To transform Oracle RTD clients:

  1. Oracle RTD clients must use the virtual IP cfcvip.example.com to access these applications.

  2. Since WSM-PM is deployed to the same managed server, ensure that the client side configuration changes required for WSM-PM are done as well.

  3. When Oracle HTTP Server is the front end for Oracle RTD, use a text editor to update the mod_wl_ohs.conf file to specify the virtual IP cfcvip.example.com as the address for the Oracle RTD managed server, as shown in the following example:

    <Location /rtis>
       SetHandler weblogic-handler
       WebLogicHost cfcvip.example.com:<port>
     </Location>
     
    <Location /schemas>
       SetHandler weblogic-handler
       WebLogicHost cfcvip.example.com:<port>
    </Location>
     
    <Location /ws>
       SetHandler weblogic-handler
       WebLogicHost cfcvip.example.com:<port>
    </Location>
     
    # WSM-PM
    <Location /wsm-pm>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1:9704, APPHOST2:9704
    </Location>
     
    # RTD
    <Location /ui>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1:9704, APPHOST2:9704
     </Location>
    

12.2.4.13 Transforming Oracle BI for Microsoft Office and its Clients

This section provides instructions to transform Oracle BI for Microsoft Office to work in a cold Failover Cluster environment.

Oracle BI for Microsoft Office is deployed to a managed server, for example, BI_Server1, and the procedure for Cold Failover Cluster transformation is to configure this server to listen on the virtual IP cfcvip.example.com. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.example.com virtual IP.

All requirements for Middleware Home placement and other domain artifacts on shared storage that can fail over apply as Section 12.2.1, "Cold Failover Cluster Requirements" describes.

Note:

For BI Office to work correctly in a CFC configuration, you must change the local host value in the bioffice.xml file to the new virtual IP value. See /bidomain/servers/bi_server1/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INF for the bioffice.xml file.

Transforming Oracle BI for Microsoft Office Clients

All client invocations of BI Office must use cfcvip.example.com. For OHS frontending the BIOFFICE, use a text editor to update the mod_wl_ohs.conf file to specify the virtual IP cfcvip.example.com as the address for the Oracle BI for Microsoft Office managed server. See the following example:

# BI Office
<Location /bioffice>
   SetHandler weblogic-handler
   WebLogicHost cfcvip.example.com
   WebLogicPort port
 </Location>
 
<Location /biofficeclient>
   SetHandler weblogic-handler
   WebLogicHost cfcvip.example.com
   WebLogicPort port
 </Location>

12.2.4.14 Transforming Oracle Data Integrator

This section describes steps to transform Oracle Data Integrator (ODI) managed server.

Note:

You can use the ODI Console or ODI Studio interface to manage transformation changes.

To transform ODI:

  1. Stop each standalone agent, and stop the Oracle Data Integrator applications deployed in Oracle WebLogic Server.

  2. Modify the repository connection information in the topology, if the database is on a different host:

    1. Connect to the restored Oracle Data Integrator repository using ODI Studio or ODI Console. Create a new connection for the master repository to the new database host, as described in "Connecting to the Master Repository" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

    2. Edit each of the Work Repositories. Click Connection and edit the connection information so that the JDBC URL points to the new database host containing the work repository.

    3. Edit each physical agent's configuration and provide the updated Host Name value and, if changed, the Port value.

    4. If there are standalone agent scripts generated and they contain the -PORT property, change the -PORT value to the new port value. The scripts are named agentName_agent.sh or agentName_agent.bat.

  3. For each standalone agent, edit the following files and change the ODI_MASTER_URL parameter to match the new database host location, if the database is on a different host:

    ORACLE_HOME/agent/bin/odiparams.*
    
  4. Edit the following file to change the database connection information and the port number:

    ORACLE_HOME/agent/bin/odi_opmn_standaloneagent_template.xml
    
  5. In the Oracle WebLogic Server configuration, edit the Data Sources to match the new database host location.

  6. Restart the standalone agents and the Oracle Data Integrator applications deployed in Oracle WebLogic Server.

After you transform the ODI managed server where the ODI Console/ODI Studio resides, you must complete the following configuration steps:

Configuring the Host to Reach the ODI Console/ODI Studio

Note:

You can use the ODI Console or ODI Studio interface to manage transformation changes.

To configure the host to reach the ODI Console/ODI Studio:

  1. Select EM Farm, ODI, and then oraclediagent.

  2. In menu ODI Console Admin, select Basic configuration.

  3. Change the hostname to your new virtual IP address instead of a physical IP address.

Configuring the Agent

Note:

You can use the ODI Console or ODI Studio interface to manage transformation changes.

To configure the agent:

  1. Select Topology, Agents and then Physical agents.

12.2.4.15 Single Sign-On Reregistration (If required)

Single Sign-On (SSO) reregistration typically applies only to Oracle Portal, Forms, Reports, and Discoverer. After the front end listening endpoint on Oracle HTTP Server for this tier changes to the Virtual IP, it becomes necessary to do SSO reregistration so that the URL to be protected is configured with the virtual IP.

Note:

For 11g, you must create a webgate using the new VIP instead of reregistering.

To reregister SSO, perform these steps on the 10.1.x installation of Identity Management where the SSO server resides

  1. Set the ORACLE_HOME variable to the SSO ORACLE_HOME location.

  2. Run ORACLE_HOME/sso/bin/ssoreg.sh (ssoreg.bat for Windows) with the following parameters:

    -site_name cfcvip.example.com:port
    -mod_osso_url http://cfcvip.example.com 
    -config_mod_osso TRUE
    -oracle_home_path ORACLE_HOME
    -config_file /tmp/osso.conf
    -admin_info cn=orcladmin
    -virtualhost
    -remote_midtier
    
  3. Copy /tmp/osso.conf file to the mid-tier home location:

    ORACLE_INSTANCE/config/OHS/ohs1

  4. Restart Oracle HTTP Server by running the following command from the ORACLE_INSTANCE/bin directory:

    ./opmnctl restartproc process-type=OHS
    
  5. Log into the SSO server through the following URL:

    http://sso.example.com/pls/orasso
    
  6. In the Administration page and then Administer Partner applications, delete the entry for node1.example.com.

12.2.5 Additional Actions for Fusion Middleware Failover

In a Cold Failover Cluster environment, a failover node (node2.example.com) must be equivalent to the install machine (node1.example.com) in all respects. To make the failover node equivalent to the installation node, perform the following procedure on the failover instance:

12.2.5.1 UNIX Platforms

For UNIX platforms follow these steps:

  1. Failover the Middleware Home from Node 1 (the installation node) to the failover node (Node 2), following the mount/unmount procedure described previously.

  2. As root, do the following:

    • Create an oraInst.loc file located in the /etc directory identical to the file on Node1.

    • Run the root.sh file located in the ORACLE_HOME directory on Node2, if it is required, and is available for the product suite.

  3. Create the oraInventory on the second node, using the attachHome command located in the ORACLE_HOME/oui/bin/attachHome.sh directory.

12.2.5.2 Windows Platform

For Windows, follow these steps:

For Application Server Instances (Web Tier, OID/OVD for IDM Installs, Oracle Portal, Form, Reports, and Discoverer):

  1. To create the OPMN service on Node 2, run the following commands:

    sc create OracleProcessManager_instance_name  binPath= "ORACLE_HOME\opmn\bin\opmn.exe -S -I ORACLE_INSTANCE" 
    

    For example:

    sc create OracleProcessManager_asinst binPath= "X:\Middleware\im_oh\opmn\bin\opmn.exe -S -I X:\Middleware\asinst" 
    
  2. On both Node 1 and 2, set the service OracleProcessManager_instance_name to be started manually.

    sc config OracleProcessManager_instance_name start= demand
    

Updating Windows Registries

  • For Oracle Business Intelligence Installations:

    When Oracle Business Intelligence is used in a Cold Failover Cluster, certain Windows registry entries used by Oracle Business Intelligence must be exactly the same on the active node and the passive node. To ensure that these registry entries are the same on the active and passive nodes, follow these steps for exporting registry entries on Node 1 and importing those registry entries on Node 2 (where Node 1 is the active node and Node 2 is the passive node).

    Follow these steps to export registry entries for Oracle Business Intelligence on Node 1:

    1. On Node 1, start the Windows Registry Editor. To do this, type the following from the Windows command line:

      C:\>regedit
      
    2. In the Registry Editor, go to and select the node HKEY_LOCAL_MACHINE\SOFTWARE\Oracle. Right-click the node and choose Export. Save these entries as a uniquely named .reg file.

    3. Go to and select the node HKEY_LOCAL_MACHINE\SOFTWARE\ODBC. Right-click the node and choose Export. Save these entries as a uniquely named .reg file.

    4. Go to and select the node HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services. Export each node within this node that begins with "Oracle" to a uniquely named .reg file.

    5. Go to and select the node HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services. Export each node within this node that begins with "Oracle" to a uniquely named .reg file.

    6. Go to and select the node HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Export each node within this node that begins with "Oracle" to a uniquely named .reg file.

    7. Copy all the .reg files you created to Node 2.

    8. Exit the Registry Editor.

    To import registry entries for Oracle Business Intelligence on Node 1 to Node 2, Double-click on each .reg file you copied from Node 1. In each case, click Yes to import the contents into the registry.

  • For All Installations:

    Export the registry HKEY_LOCAL_MACHINE\SOFTWARE\Oracle from Node 1 and import it to Node 2.

Environment Variables Considerations

If the system environment variable 'Path' on Node 1 contains any instance specific information, set this information in the same variable on Node 2.

Exporting Start Menu items from Node 1 and Importing them on Node 2

To copy the Start Menu from Node 1 to Node 2, copy the files under C:\Document and Settings\All Users\Start Menu\Programs\<Menu> from Node 1 to Node 2. You can do this with any Windows Backup tool, or Zip utility.

For example, using the Windows Backup Utility:

  1. Invoke the Windows Backup Utility by selecting Accessories, System Tools, and then Backup.

  2. Select C:\Document and Settings\All Users\Start Menu\Programs\<Menu>

  3. Copy the backup file to the second node.

  4. Restore the backup to the same location: C:\Document and Settings\All Users\Start Menu\Programs\

Node Manager Considerations

For Node Manager use the standard WebLogic Server procedure to configure Node Manager as a service.

Node Manager is configured as a service using the WL_HOME\server\bin\installNodeMgrSvc.cmd command. To configure Node Manager:

  • It must be set on both Nodes.

  • Node Manager should be set to start manually on both nodes.

To configure Node Manager on a Node,

  1. Ensure that the Middleware Home is available on the machine.

  2. Install the service running the above command.

  3. Set it to be started manually using the following command:

    sc config nodemanager_service_name start= demand
    

12.2.6 Transforming an Oracle Database

In a typical Cold Failover Cluster deployment of Oracle Fusion Middleware, the database is also deployed as a cold failover cluster. This section describes how to transform a single instance Oracle database to a Cold Failover Cluster database. Perform this transformation before seeding the database using RCU and subsequent Fusion Middleware installations that use this seeded database.

To enable the database for Cold Failover Cluster:

  1. Change the listener configuration that the database instance uses in the listener.ora file.

    Ensure that the HOST name in the listener configuration has the value of the virtual hostname. In addition, ensure that no other process (Oracle or third party) uses the listener port.

    <listener_name>  =
     (DESCRIPTION_LIST =
       (DESCRIPTION =
             (ADDRESS = (PROTOCOL = TCP)(HOST = <virtual_hostname>)(PORT = port))
       )
    )
    

    For example:

    LISTENER_CFCDB =
     (DESCRIPTION_LIST =
       (DESCRIPTION =
             (ADDRESS = (PROTOCOL = TCP)(HOST cfcdbhost.example.com)(PORT = 1521))
       )
     )
    
  2. Change the tnsnames.ora file.

    Change an existing TNS service alias entry or create a new one:

    <tns_alias_name> =
     (DESCRIPTION =
       (ADDRESS_LIST =
         (ADDRESS = (PROTOCOL = TCP)(HOST = <virtual_hostname>)(PORT = port))
       )
       (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = <db_service_name>)
          (INSTANCE_NAME = <db_instance_name>)
       )
     )
    
    )
    

    For example:

    CFCDB =
     (DESCRIPTION =
       (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCP)(HOST = cfcdbhost.example.com)(PORT = 1521))
       )
       (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = cfcdb)
          (INSTANCE_NAME = cfcdb)
       )
     )
    
    
  3. Change the local sp file to update the local_listener parameter of the instance.

    Log in as sysdba using SQL*Plus:

    SQL> alter system set local_listener='<tns_alias_name>' scope=both;
    )
    

    For example:

    SQL> alter system set local_listener='CFCDB' scope=both;
    
  4. Shutdown and restart the listener.

  5. Shutdown and restart the database instance.

  6. Create the database service for the application server.

    Oracle recommends a dedicated service separate from the default database service. To create this service, execute the following SQL*Plus command:

    SQL> execute DBMS_SERVICE.CREATE_SERVICE
    ('<cfc_db_service_name>','<cfc_db_network_name>')
    

    For example:

    SQL> execute DBMS_SERVICE.CREATE_SERVICE
    ('cfcdb_asservice','cfcdb_asservice')
     
    

    To start the service, execute the following SQL*PLUS command:

    SQL> execute DBMS_SERVICE.START_SERVICE ('cfcdb_asservice')
    

    You can set additional parameters for this service depending on the needs of the installation. See the Oracle Database PL/SQL Packages and Types Reference for details about the DBMS_SERVICE command.

12.2.6.1 Database Instance Platform-Specific Considerations

Consider the following procedures for Unix and Windows platform database instances:

For Unix:

  1. Manually Failover the Database Oracle Home from Node 1 (the installation node) to the failover node (Node 2) following the mount/unmount procedure described earlier.

  2. As root, do the following:

    • Create an oraInst.loc file located in the /etc directory identical to the file on Node1.

    • Create an oratab file located in the /etc directory, identical to the file on Node1.

    • Run the oracleRoot.sh file located in the ORACLE_HOME directory on Node2, if it is required, and is available for the product suite.

  3. Create the oraInventory file on the second node, using the attachHome command located in ORACLE_HOME/oui/bin/attachHome.sh directory.

For Windows:

If the system environment variable 'Path' on Node1 contains any information pertaining to this database, ensure this information is set in the same variable on Node 2. Export the registry HKEY_LOCAL_MACHINE\SOFTWARE\Oracle from Node 1 and import it to Node 2. Also, ensure the user system is also in the ORA_DBA group on Node2.

Using the SC tool from the Windows Resource Kit, create services for the following:

  • db service

    sc create OracleService<oracle_sid> start= demand  binPath= "ORACLE_HOME\bin\ORACLE.EXE <oracle_sid>"
    

    For example:

    sc create OracleServiceORCL start= auto 
    binPath= "C:\Oracle\db\product\11.1.0\bin\ORACLE.EXE <oracle_sid>"
    

    Note:

    oracle_sid should be in upper case

  • listener

    sc create Oracle<home_name>TNSListener start= demand binPath= "ORACLE_HOME\bin\TNSLSNR"
    

    For example:

    sc create OracleINFRATNSListener start= demand 
    binPath= "C:\Oracle\db\product\11.1.0\bin\TNSLSNR"
    
  • cluster services

    sc create OracleCSService start= auto
    binPath= "ORACLE_HOME\bin\ocssd.exe service"
    

    For example:

    sc create OracleCSService start= auto 
    binPath= "INFRAHOME\bin\ocssd.exe service"
    
  • database console

    sc create OracleDBConsole<oracle_sid> start= auto
    binPath= "ORACLE_HOME\bin\nmesrvc service"
    

    For example:

    sc create OracleDBConsoleorcl start= auto
    binPath= " C:\Oracle\db\product\11.1.0\bin\nmesrvc service"
    
  • job scheduler

    sc create OracleJobScheduler<oracle_sid> start= demand
    binPath= "ORACLE_HOME\bin\extjob.exe <oracle_sid>"
    

    For example:

    sc create OracleJobSchedulerORCL start= auto
    binPath= "C:\Oracle\db\product\11.1.0\INFRAHOME\bin\extjob.exe <oracle_sid>"
    

    Note:

    oracle_sid should be in upper case.

  • Vss service

    sc create OracleVssWriter<oracle_sid> start= demand binPath= "ORACLE_HOME\bin\OraVSSW.exe <oracle_sid>"
    

    For example:

    sc create OracleJobSchedulerORCL start= auto
    binPath= "C:\Oracle\db\product\11.1.0\INFRAHOME\bin\OraVSSW.exe <oracle_sid>"
    

    Note:

    oracle_sid should be in upper case.

12.3 Oracle Fusion Middleware Cold Failover Cluster Example Topologies

This section shows sample Cold Failover Cluster topologies. Since there are many possible combinations of topologies, these topologies are illustrative only. To achieve these topologies, more than one of the transformation steps apply. Refer to the steps mentioned earlier to configure the transformation.

This section includes the following topics:

12.3.1 Example Topology 1

Figure 12-3 shows an Oracle WebCenter Portal Cold Failover Cluster deployment. Both the Administration Server and the WebCenter Managed Servers are in the domain and failover as unit. Therefore, they share the same virtual IP and are installed together on the same shared disk. There may be an Oracle HTTP Server front ending this topology. It is on a separate node in the example topology. It can also be on the same node, and can be part of the Cold Failover Cluster deployment. In this example, the database is also on a separate node. However, it is equally likely that the database is on the same cluster and is also Cold Failover Cluster-based (using its own virtual IP and shared disk).

Figure 12-3 Cold Failover Cluster Example Topology 1

Description of Figure 12-3 follows
Description of "Figure 12-3 Cold Failover Cluster Example Topology 1"

12.3.2 Example Topology 2

Figure 12-4 shows an example SOA Cold Failover Cluster deployment. In this example, only the SOA instance is deployed as Cold Failover Cluster, and the Administration Server is on a separate node. The database is also on a separate node in this example topology. Oracle HTTP Server in this case is part of the Cold Failover Cluster deployment, and part of the same failover unit as the SOA Managed Servers. Important variants of this topology include a Cold Failover Cluster Administration Server on the same hardware cluster. It may share the same virtual IP and shared disk as the SOA Managed Servers (SOA and Administration Server are part of the same failover unit) or use a separate virtual IP, and shared disk (Administration Server fails over independently). Similarly, depending on the machine capacity, the database instance can also reside on the same hardware cluster.

Figure 12-4 Cold Failover Cluster Example Topology 2

Description of Figure 12-4 follows
Description of "Figure 12-4 Cold Failover Cluster Example Topology 2"

12.3.3 Example Topology 3

Figure 12-5 shows an Oracle Identity Management deployment. In this example topology, all components are on a two-node hardware cluster. Identity Management fails over as a unit, and both the Java EE (Administration Server and WLS_ods Managed Server) and system components are part of the same failover unit. They share the same virtual IP and shared disk (cfcvip1.example.com). The database is also on the same hardware cluster. It uses a different virtual IP, cfcvip2.example.com, and a different set of shared disks. During normal operations, the database runs on Node2 and the IDM stack runs on Node1. The other node acts as a backup for each.

This topology is recommended for most Cold Failover Cluster deployments. The example is for Identity Management, but this is true for the Oracle SOA, Oracle WebCenter Portal, and Oracle Portal, Forms, Reports, and Discoverer suites. In the recommended architecture, Oracle Fusion Middleware runs as one node of the hardware cluster. The Oracle database runs on the other node. Each node is a backup for the other. The Oracle Fusion Middleware instance and the database instance failover independently of each other, using different shared disks and different VIPs. This architecture also ensures that the hardware cluster resources are optimally used.

Figure 12-5 Cold Failover Cluster Example Topology 3

Cold Failover Cluster Example Topology 3
Description of "Figure 12-5 Cold Failover Cluster Example Topology 3"

12.4 Transforming the Administration Server in an Existing Domain for Cold Failover Cluster

This section describes the steps for transforming an Administration Server in an existing domain to Cold Failover Cluster.

Note:

The Cold Failover Cluster transformation procedure described in this section is not supported for Oracle Portal, Reports, Forms, and Discoverer.

Note:

After Administration Server transformation, client side changes for Administration Server and Enterprise Manager, as mentioned in Section 12.2.3.5, "Transforming the Administration Server for Cold Failover Cluster," may be required.

Assumptions

The procedures in this section assume that:

Start Topologies

See the following sections to achieve the start topologies:

These procedures also apply to customer applications deployed to Oracle WebLogic cluster installations, if the assumptions are met.

Figure 12-6 shows an example start topology before transforming the Administration Server.

Figure 12-6 Cold Failover Cluster Example Start Topology

Cold Failover Cluster Example Topology 1
Description of "Figure 12-6 Cold Failover Cluster Example Start Topology"

12.4.1 Destination Topologies

Figure 12-7 shows the possible destination topology after transforming the Administration Server for Cold Failover Cluster with the following characteristics:

  • The Administration Server Domain Home is moved out onto a shared disk that Node1 and Node2 can mount, but is mounted by either one of the two at any given point in time.

  • It continues to use the original Middleware Home available on Node1 and Node2.

  • The Listen Address of the Administration Server is moved to a virtual IP.

Figure 12-7 Possible Destination Topologies

Cold Failover Cluster Example Topology 1
Description of "Figure 12-7 Possible Destination Topologies"

12.4.2 Cold Failover Cluster Transformation Procedure

To transform the Administration Server in an existing domain:

  1. Shut down the cluster of the component Managed Servers and Administration Server.

  2. Shut down the Node Manager process on each of the nodes, if it is running.

  3. Back up the entire domain.

  4. Provision the Virtual IP on Node1. For example:

    For Linux:

    /sbin/ifconfig eth0:1 IP_Address netmask netmask
    /sbin/arping -q -U -c 3 -I eth0 IP_Address
    

    Where IP_Address is the virtual IP_Address and the netmask is the associated netmask.

    In the example below, the IP_Address is enabled on the interface Local Area Connection.

    /sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
    /sbin/arping -q -U -c 3 -I eth0 IP_Address
    

    For Windows:

    netsh interface ip add address interface IP_Address netmask
    

    Where IP_Address is the virtual IP_Address and the netmask is the associated netmask.

    In the example below, the IP_Address is enabled on the interface Local Area Connection.

    netsh interface ip add address "Local Area connection" IP_Address netmask
    
  5. Start the Administration Server from the local Domain Home.

    cd DOMAIN_HOME/bin
    ./startWeblogic.sh
    
  6. Transform the Administration Server instance to Cold Failover Cluster:

    Log into the Administration Console.

    Create a machine for the Virtual Host.

    1. Select Environment, and then Machines.

    2. In the Change Center, click Lock & Edit. Click New.

    3. In the Name field, enter cfcvip.example.com.

      Note:

      Keep the Listen Address field set to localhost; the CFC solution relies on this setting. Do not change it to the virtual IP_Address or any other value.

      The Administration Server requires a new Virtual Host Machine so that it can interact with multiple node managers, not just the local one. Each node manager on each host listens on all interfaces, both the real IP and the local host (127.0.0.1). The Administration Server uses the new Virtual Host Machine definition exclusively.

      The Virtual Host Machine must point to localhost because localhost is the relative internal address for whatever machine is active; it sticks with the Administration Server. The Administration Server changes from one host to another but keeps the same Virtual Name and VIP. The node manager that is associated with the Administration Server also changes, because the Administration Server uses the localhost attribute in conjunction with the first host and then again, after failover, in conjunction with the second host. See Figure x

    4. Select the appropriate operating system and click OK.

    5. Select the machine you just created.

    6. Click the Servers tab then click Add.

    7. Select an existing server, and associate it with this machine.

    8. In the Select Server drop-down list, ensure AdminServer is selected.

    9. Click Finish then click Activate Changes.

    Configure the administration server to listen on cfcvip.example.com.

    1. Select Environment, and then Servers from the Domain Structure menu.

    2. In the Change Center, click Lock & Edit.

    3. Click on the Administration Server (AdminServer).

    4. Change the Listen Address to cfcvip.example.com Click Save.

    Stop the Administration Server from the Administration Console.

    1. Select Environment, and then Servers from the Domain Structure menu.

    2. Click Control.

    3. Select Adminserver by clicking on the checkbox next to it.

    4. Shut down Adminserver by selecting Force Shutdown Now under Shutdown pull-down menu.

    5. Click Yes.

    Ensure that the VIP is enabled on the system and start the Administration Server from the command line:

    cd DOMAIN_HOME/bin
    ./startWeblogic.sh
    
  7. Validate the Administration Server by accessing the consoles on the virtual IP:

    • http://cfcvip.example.com:7001/console

    • http://cfcvip.example.com:7001/em

  8. Shut down the Administration Server on Node1 using the Administration Console.

  9. Ensure that the shared disk is provisioned and mounted on Node1.

  10. Pack the entire domain on Node1:

    cd ORACLE_COMMON_HOME/common/bin
    ./pack.sh -managed=false -domain=/localdisk/user_projects/domains/domain_name
    -template=cfcdomaintemplate_all.jar -template_name=cfc_domain_template_all
    
  11. Unpack it on the shared disk:

    ./unpack.sh -domain=/shareddisk/user_projects/domains/domain_name
    -template=cfcdomaintemplate_all.jar 
    -app_dir=/shareddisk/user_projects/apps -server_start_mode=prod
    
  12. Product suite-specific changes:

    In the Oracle Identity Management Product Suite:

    • Back up the config.xml file, located in the /shareddisk/user_projects/domains/domain_name/config/ directory in this example.

    • Change WCC Socket Host Filter to VIP in the following files:

      • {domain}/ucm/ibr/config/config.cfg

      • {domain}/ucm/urm/config/config.cfg

      • {domain}/ucm/cs/config/config.cfg

    • Edit the config.xml file, located in the /shareddisk/user_projects/domains/domain_name/config directory in this example, and make the following changes to source-path:

      For dipapp, change source path to ORACLE_HOME/ldap/odi/dipapp/dipapps.ear.

      For example:

      <app-deployment>
          <name>DIP#11.1.1.2.0</name>
          <target>cluster_ods</target>
          <module-type>ear</module-type>
          <source-path>ORACLE_HOME/ldap/odi/dipapp/dipapps.ear</source_path>
          <security-dd-model>DDOnly</security-dd-model>
          <staging-mode>nostage</staging-mode>
        </app-deployment>
      

      For the ODSM app, change the source path to ORACLE_HOME/ldap/odsm/odsm.ear

      For example:

      <app-deployment>
          <name>odsm#11.1.1.2.0</name>
          <target>cluster_ods</target>
          <module-type>ear</module-type>
          <source-path>ORACLE_HOME/ldap/odsm/odsm.ear</source-path>
          <security-dd-model>DDOnly</security-dd-model>
          <staging-mode>nostage</staging-mode>
        </app-deployment>
      
    • For the OIF:

      Change the source path of OIF-APP to ORACLE_HOME/fed/install/oif.ear:

      <app-deployment>
          <name>OIF#11.1.1.2.0</name>
          <target>cluster_oif</target>
          <module-type>ear</module-type>
          <source-path>ORACLE_HOME/fed/install/oif.ear</source-path>
          <security-dd-model>Advanced</security-dd-model>
          <staging-mode>nostage</staging-mode>
        </app-deployment>
      

      Change the source path of oif-libs to ORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear:

      <library>
        <name>oif-libs#11.1.1.2.0@11.1.1.2.0</name>
          <target>cluster_oif</target>
          <module-type>ear</module-type>
          <source-path>ORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear</source-path>
          <security-dd-model>DDOnly</security-dd-model>
        </library>
      
  13. Start the Administration Server:

    cd /shareddisk/user_projects/domains/domain_name/bin
    ./startWeblogic.sh
    
  14. Validate the Administration Server by accessing the consoles on the virtual IP.

    • http://cfcvip.example.com:7001/console

    • http://cfcvip.example.com:7001/em

  15. Shut down the Administration Server.

  16. Perform the following on Node1:

    mv /localdisk/user_projects/domains/domain_name
    /localdisk/user_projects/domains/domain_name_old
    mv /localdisk/user_projects/applications/domain_name
    /localdisk/user_projects/applications/domain_name_old
    cd ORACLE_COMMON_HOME/common/bin
    ./pack.sh -managed=true -domain=/shareddisk/user_projects/domains/domain_name
    -template=cfcdomaintemplate_mngd.jar -template_name=cfc_domain_template_mngd
    ./unpack.sh -domain=/localdisk/user_projects/domains/domain_name
    -template=cfcdomaintemplate_mngd.jar
    

    Note:

    These commands assume an applications directory exists under user_projects.

  17. Copy the template to Node2:

    scp ORACLE_COMMON_HOME/common/bin/cfcdomaintemplate_mngd.jar
    Node2:ORACLE_COMMON_HOME/common/bin
    
  18. Log in to Node2, and unpack on Node2

    mv /localdisk/user_projects/domains/domain_name
    /localdisk/user_projects/domains/domain_name_old
    mv /localdisk/user_projects/applications/domain_name
    /localdisk/user_projects/applications/domain_name_old
    cd ORACLE_COMMON_HOME/common/bin
    ./unpack.sh -domain=/localdisk/user_projects/domains/domain_name
    -template=cfcdomaintemplate_mngd.jar
    

    Note:

    These commands assume an applications directory exists under user_projects.

  19. For Oracle Identity Manager Suite, the following addition steps are required:

    For DIP:

    1. Locate the applications directory in the Oracle WebLogic Server domain directory on Node1:

      MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications
      
    2. Copy the applications directory and its contents on Node1 to the same location in the domain directory on Node2.

      scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers
                     /wls_ods1/applications
           user@IDMHOST2:MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig
                     /servers/wls_ods2/applications
      
      

    For OIF:

    1. Locate the applications directory in the Oracle WebLogic Server domain directory on Node1:

      MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers/wls_oif1/applications
      
    2. Copy the applications directory and its contents on Node1 to the same location in the domain directory on Node2.

      scp -rp MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers
                     /wls_oif1/applications
           user@IDMHOST2:MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig
                     /servers/wls_oif2/applications
      
  20. Start the Administration Server:

    cd /shareddisk/user_projects/domains/domain_name/bin
    ./startWeblogic.sh
    
  21. Start the node manager (if used) on Node1 and Node2:

    cd WL_HOME/server/bin
    ./startNodeManager.sh
    
  22. Start the component Managed Servers on Node1 and Node2 from the Administration Server Console (if Node Manager used) or from the command line.

  23. Validate the deployment using component-specific functional tests.

  24. Test Administration Server failover.

    Failover the Administration Server manually to the second node:

    1. Stop the Administration Server process (and any other process running out of a given Middleware Home).

    2. Unmount the shared storage from Node1 where the Middleware Home or domain directory exists.

    3. Mount the shared storage on Node2, following storage specific commands.

    4. Disable the virtual IP on Node1:

      For Linux:

      ifconfig interface:index down
      

      In the following example, the IP_Address is disabled on the interface eth0:

      ifconfig eth0:1 down
      

      For Windows:

      netsh interface ip delete address interface addr=IP_Address
      

      Where IP_Address is the virtual IP_Address.

      In the following example, the IP_Address is enabled on the interface Local Area Connection.

      netsh interface ip delete address 'Local Area connection' addr=130.35.46.17
      
    5. Enable the virtual IP on Node2.

    6. Start the Administration Server process using the following command:

      DOMAIN_HOME/bin/startWebLogic.sh
      

      Where DOMAIN_HOME is the location of your domain directory.

    Validate access to both the Administration Server and Oracle Enterprise Manager Administration Console.

    Validate with component-specific tests.

  25. After validation, fail back the Administration Server to the node where it will normally run (this could be Node1 or Node2) and run normal operations.