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 application server instances are configured to serve the same application workload but only one is active at any particular time.

A two-node Cold Failover Cluster can be used to achieve active-passive availability for Oracle Application Server middle-tier components. In a Cold Failover Cluster, one node is active while the other is passive, on standby. In the event that the active node fails, the standby node is activated, and the middle-tier components continue servicing clients from that node. All middle-tier components are failed 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:

  • Shared Storage: The passive Oracle Fusion Middleware instance in an active-passive configuration has access to the same Oracle binaries, configuration files, domain directory, and data as the active instance. You configure this access by placing these artifacts in storage that can be accessed by all participating nodes in the Cold Failover Cluster configuration. Typically the active node has shared storage mounted, while the passive node's is unmounted but accessible if the node becomes active. The shared storage can be a dual ported disk device accessible to both the nodes, or a device-based storage such as a NAS or a SAN. You can install shared storage on a regular file system. With Cold Failover Cluster, you mount the volume on one node at a time. Shared storage is a key property of a Cold Failover Cluster deployment.

  • Virtual hostname: In the Cold Failover Cluster solution, a virtual hostname and a virtual IP are shared between the two nodes (the virtual hostname maps to the virtual IP and is used interchangeably in this guide). However, only one node, the active node, can use this virtual IP at any one time. When the active node fails and the standby node is made active, the virtual IP is moved to the new active node. The new active node now services all requests through the virtual IP. The Virtual Hostname provides a single system view of the deployment. A Cold Failover Cluster deployment is configured to listen on this virtual IP. For example, if the two physical hostnames of the hardware cluster are node1.mycompany.com and node2.mycompany.com, the single view of this cluster can be provided by the name cfcvip.mycompany.com. In the DNS, cfcvip.mycompany.com maps to the virtual IP, which floats between node1 and node2. When a hardware cluster is used, it manages the failover of the virtual IP without the middle tier clients detecting which physical node is active and actually servicing requests.

  • Hardware Cluster: A hardware cluster is typically used for Cold Failover Cluster deployments. The hardware cluster addresses the management of shared storage and virtual IP in its architecture. It plays a role in reliable failover of these shared resources, providing a robust active-passive solution. Most Cold Failover Cluster are deployed to hardware clusters that include the following:

    • Two nodes that are in the same subunit

    • A high speed private interconnect between the two nodes

    • Public network interfaces, on which the client requests are served and the virtual IP is enabled.

    • Shared storage accessible by the two nodes. This includes shared storage that acts as a quorum device as well as shared storage for Oracle Fusion Middleware and database installs.

    • Clusterware running to manage node and component failures

  • Planned Switchover and Unplanned Failover: The typical Cold Failover Cluster deployment is a two-node hardware cluster. To maximize utilization, both of these nodes typically have some elements of the deployment running, with the other node acting as a backup node for the appropriate element if needed. For example, a deployment may have the application tier (WebLogic container) running on one node and the Web tier (Oracle HTTP Server) running on the other node. If either node is brought down for hardware or software maintenance, or if either node crashes, the surviving node is used to host the services of the down node while continuing to host its current services.

    The high-level steps for switch-over to the standby node are as follows:

    1. Stop the middle-tier service on the primary node (if the node is still available).

    2. Fail over the virtual IP from the current active node, to the passive node. This involves bringing it down on the current node and enabling it and bringing up on the passive node.

    3. Fail over the shared disk from the current active node to the passive node. This involves unmounting the shared disk from the current node and mounting it on the passive node.

    4. Start the middle-tier service on the passive node, which becomes active.

    For failover management, there are two possible approaches:

    • Automated failover using a cluster manager facility

      The cluster manager offers services, which allows development of packages to monitor the state of a service. If the service or the node is found to be down (either due to planned operation or unplanned operation), it automatically fails over the service from one node to the other node. The package can be developed to attempt to restart the service on a given node before failing over. Similarly, when the active node itself is down, the clusterware can detect the down state of the node and attempt to bring it up on the designated passive node. These can be automated using any clusterware to provide failover in a completely automated fashion.

      Oracle Fusion Middleware provides this capability using Oracle Clusterware. Please refer to Chapter 13, "Using Oracle Cluster Ready Services" for details of managing a Cold Failover Cluster environment with Oracle Cluster-Ready Services. However, you can use any available clusterware to manage cluster failover.

    • Manual failover

      For this approach, the planned switchover steps are executed manually. Both the detection of the failure and the failover itself is manual, Therefore this method may result in a longer period of service unavailability.

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 failover the instance to the passive node.

Active-Passive Topologies: Advantages

  • Increased availability

    If the active instance fails for any reason or must be taken offline, an identically configured passive instance is prepared to take over at any time. This provides an increased level of availability than a normal single instance deployment. Active-passive deployments also are used to provide availability and protection against planned and unplanned maintenance operation of the hardware used. When a node needs to be brought down for planned maintenance such as a patch apply or OS upgrade or any other reason, the middle ware services can be brought up on the passive node. Switchback to the old node can be done at appropriate times.

  • Reduced operating costs

    In an active-passive configuration only one set of processes is up and serving requests. Management of the active instance is generally less costly than managing an array of active instances.

  • A Cold Failover Cluster topology is less difficult to implement because it does not require a load balancer, which is required in active-active topologies

  • A Cold Failover Cluster topology is less difficult to implement than active-active topologies because you are not required to configure options such as load balancing algorithms, clustering, and replication.

  • Active-passive topologies better simulates a one-instance topology than active-active topologies.

  • Application independence

    Some applications may not be suited to an active-active configuration. This may include applications which rely heavily on application state or on information stored locally. Singleton application by very nature are more suitable for active-passive deployments. An active-passive configuration has only one instance serving requests at any particular time.

Active-Passive Topologies: Disadvantages

  • Active-passive topologies do not scale as well as active-active topologies. You cannot add nodes to the topology to increase capacity.

  • State information from HTTP session state and EJB stateful session beans is not replicated, and therefore gets lost when a node terminates unexpectedly. Such state can be persisted to the database or to the file system residing on a shared storage, however, this requires additional overhead that may impact performance of the single node Cold Failover Cluster deployment.

  • Active-passive deployments have a shorter downtime than a single node deployment. However, downtime is much shorter in an active-active deployment.

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. Components such as Oracle Internet Directory, Oracle Virtual Directory, Oracle HTTP Server, Oracle Web Cache, Runtime Engines of Oracle Forms, and Oracle Reports are system components. Components such as the Oracle SOA Suite, Oracle WebCenter Suite, Oracle Identity Management components, such as ODSM and DIP are Java EE components that are deployed to Oracle WebLogic Server.

WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control are also deployed to the WebLogic container. Both Java EE and system components can be deployed 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.

For Oracle Fusion Middleware, the recommended procedure to create an active-passive topology is:

  • Install the component as a single instance configuration. If you planned to transform this instance to a Cold Failover Cluster deployment, install it using a shared disk. This means that the Middleware home, the Instance home, in the case of system components, and the domain directory, in case of a WebLogic deployment are on a shared disk. Everything that fails over as a unit should be on a shared disk.

  • After the installation, you 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 of the individual components 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 present in a given machine. To transform the entire instance or domain:

  • Decide which components form a unit of failover.

  • Deploy them on the same shared disk.

    Note:

    For details about installing and deploying Oracle Fusion Middleware components, see the installation guide for the specific Fusion Middleware component.

  • Determine a virtual IP to use for this unit of failover. Typically, a single virtual IP is used for all the components, but separate IPs can be used as long as all of them fail over together.

  • Apply the transformation procedure to each of the individual components to transform the deployment as a whole. Since more than one of these sections will apply for Cold Failover Cluster transformation of an installation, the order of transformation should always be as follows:

    • Transform the Administration Server or Enterprise Manager instance (if applicable).

    • Transform all managed servers in the deployment.

    • Transform the Oracle instances (non-Java EE deployments).

12.2.1 General Requirements for Cold Failover Cluster

As described earlier, a Cold Failover Cluster deployment has at least two nodes in the deployment. The installation is done on one of these nodes. The other node is the passive node. The requirements on these two nodes are as follows:

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

  • The nodes should be similar in terms of the 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, as well as the additional load required to handle a failover scenario. However, if the SLA agreement indicates that during outage scenarios, reduced performance is acceptable, this is not required.

  • The nodes should have the same mount point free so that mounting of 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, it is required to ensure that the ports used by the Cold Failover Cluster instance are free on both the nodes.

Note:

Before beginning the transformation, back up of your entire domain. Oracle also recommends creating a local backup file before editing it. For details on backing up your domain, see the Oracle Fusion Middleware Administrator's Guide. Oracle recommends backing up:

  • All domain directories

  • All Instance homes

  • Optionally, the database repository and the Middleware homes

  • For all the sections below, before changing any file, ensure that a local backup copy is made before editing the file.

12.2.1.1 Terminology for Directories and Directory Environment Variables

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 (for example, SOA, WebCenter, or Identity Management) 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 Directory: 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: /localdisk stands for 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: /shareddisk stands for 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 used and recommended for consistency for these directories 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
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

Location for Applications Directory: ORACLE_BASE/admin/domain_name/apps (for example)

Location for Oracle Instance: ORACLE_BASE/admin/instance_name (for example)

All entities on disk that failover as a unit should preferably be on the same mount point. They can, however, be on separate shared storage, on separate mount points as well. Oracle recommends that the mount point for the shared storage is ORACLE_BASE. In most cases, this ensures 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 fails over independent of the other, different mount points will exist for each such failover unit.

12.2.2 Transforming Oracle Fusion Middleware Infrastructure Components

An Oracle Fusion Middleware deployment is made up of 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.

12.2.2.1 Administration Server Topology 1

Figure 12-1 illustrates 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 is listening on the Virtual IP or hostname. The Middleware Home and the domain directory is on a shared disk that is mounted on 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. 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 high availability of domain services.

12.2.2.1.1 Topology 1 Installation Procedure

To install and configure Cold Failover Cluster for the application 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 allows simultaneous mounts on more than one node. This is done as a regular single-instance installation. Please refer to the component chapters for details on installing the Administration Server (and Enterprise Manager) alone. The overall procedure for each suite is as follows:

For Oracle SOA or Oracle WebCenter:

  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 or WebCenter.

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

  3. 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 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 (this is 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, make sure that Enterprise Manager is also selected.

Note:

In this case, at least one more Managed Server for the product components is also installed in this process (the Administration Server by itself cannot be installed). This Managed Server must also be transformed to CFC using the specific procedure for the component. It is part of the same failover unit as the Administration Server.

Note:

In this case, at least one more Managed Server for the product components is also installed in this process (the Administration Server by itself cannot be installed). This Managed Server must also be transformed 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.

    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.2.3, "Transforming the Administration Server for Cold Failover Cluster."

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

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

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

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

    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

      Where IP Address is the virtual IP. In the example below, the 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 similar 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.2.2 Administration Server Topology 2

Figure 12-2 illustrates 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 is running on Node1 and it uses the Middleware Home on Node2 when it is running on Node2. These two Middleware Home must be maintained to be the same 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 be failed 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.

A hardware cluster may be used in this topology. The cluster helps 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 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.2.2.1 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 or Oracle WebCenter:

  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:

    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.

    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" 130.35.46.17 255.255.224.0

  2. Transform the Administration Server instance to Cold Failover Cluster using the procedure in Section 12.2.2.3, "Transforming the Administration Server for Cold Failover Cluster."

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

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

    http://cfcvip.mycompany.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:

      ifconfig interface:index down

      In the following example, the IP address is being 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
DOMAIN_HOME/bin/startWebLogic.sh

      Where DOMAIN_HOME is the location of your domain directory.

    5. Enable the virtual IP on Node 2.

    6. Start up 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.2.3 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 step transform the container, therefore, both the WebLogic Server 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.mycompany.com. After installation, to transform a non Cold Failover Cluster instance, to a Cold Failover Cluster:

  1. Log into the WebLogic Server Administration Console.

  2. Create a Machine for the Virtual Host

    1. Select Environment, and then Machines.

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

    3. Click New.

    4. In the Name field, enter cfcvip.mycompany.com

    5. Select the appropriate operating system.

    6. Click OK.

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

    8. Click the Servers tab.

    9. Click Add.

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

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

    11. Click Activate Changes.

  3. Configure the Administration Server to Listen on cfcvip.mycompany.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.mycompany.com

    5. Click Save.

    6. Click Activate Changes.

    7. Restart the Administration Server.

      Note:

      Since it is typically expected that transformation to Cold Failover Cluster for the Administration Server is done at domain creation time No other changes to other parts of the domain are expected. If this change happens post 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.mycompany.com.

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

adminHost=cfcvip.mycompany.com

If the Oracle Instance is to be registered or re-registered 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.mycompany.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_asinst_ 1/sysman/config.

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

    • REPOSITORY_URL

    • EmdWalletSrcUrl

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

    cd INSTANCE_HOME/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.2.4 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 WebLogic Server 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.

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

For this procedure, the WebLogic Server Administration Console must be running. In the following example, cfcvip.mycompany.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 WebLogic Server Administration Console.

  2. Create a machine for the virtual host:

    1. Select Environment > Machines.

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

    3. Click New.

    4. For the Name field, enter cfcvip.mycompany.com

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

    6. Click OK.

    7. Click the newly created Machine.

    8. Click Node Manager tab.

    9. Update Listen Address: cfcvip.mycompany.com.

    10. Click Save.

    11. Click Activate Changes.

  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.mycompany.com.

    7. Click Save.

    8. Click Activate Changes.

  5. Start the WLS_EXMPL Managed Server:

    1. Choose Environment > Servers.

    2. Click Control.

    3. Select WLS_EXMPL.

    4. Click Start.

12.2.2.4.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://admin.mycompany.com:7001')

wls:/DomainName/serverConfig> edit()
wls:/DomainName/edit> startEdit()
wls:/DomainName/edit !> create('cfcvip.mycompany.com','Machine')
wls:/DomainName/edit !> cd('Machines/cfcvip.mycompany.com/NodeManager/cfcvip.mycompany.com')
wls:/DomainName/edit !> set('ListenAddress', 'cfcvip.mycompany.com')
wls:/DomainName/edit !>cd ('Servers')
wls:/DomainName/edit/Servers !>cd ('WLS_EXMPL')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('Machine',' cfcvip.mycompany.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('ListenAddress',' cfcvip.mycompany.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !> save()
wls:/DomainName/edit/Servers/WLS_EXMPL !> activate()
wls:/DomainName/edit/Servers/WLS_EXMPL> exit()

    Stop (if not already down) and start the Managed server.

    Once the Managed server transformation is completed, all references to it should use the new Listen Address - cfcvip.mycompany.com. If Oracle HTTP Server serves as a front end to this Managed server, then any mod_wls_ohs configuration with mount points referring to applications in this Managed server should be changed to route to the new listening end point.

12.2.2.5 Transforming Node Manager

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

  • Using 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 Machine 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.mycompany.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.mycompany.com as part of these steps.

12.2.2.6 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 application 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 has already been 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 host name entries for this specific Oracle instance (being transformed to Cold Failover Cluster) to cfcvip.mycompany.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.mycompany.com"/>

    For the instance itself:

    <ias-instance id="asinst " instance-home="/11gr1as3/MW/asinst" host="cfcvip.mycompany.com" port="6701">

  2. In the opmn.xml file in the INSTANCE_HOME/config/OPMN/opmn directory, replace the "<physicalhostname>" with cfcvip.mycompany.com:

    </ias-component><ias-component id="ReportsServer_<physicalhostname>_asinst_2">
<process-set id="ReportsServer_<physicalhostname>_asinst_2" restart-on-death="true" numprocs="1">

  3. In the instance.properties file in the INSTANCE_HOME/config/OPMN/opmn directory, change "adminHost=<physical hostname>" to "adminHost=<cfcvip.mycompany.com>".

12.2.2.7 Transforming Oracle Enterprise Manager for an Oracle Instance

When an Oracle instance such as Oracle Internet Directory, Oracle Virtual Directory, Web Tier components, and Oracle Portal, Forms, Reports, and Discoverer components is transformed to Cold Failover Cluster, the Enterprise Manager agent that is part of this Oracle instance must be transformed to Cold Failover Cluster as well.

To transform the Enterprise Manager agent:

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

    cd INSTANCE_HOME/EMAGENT/emagent_dir/bin 
./emctl stop agent

  2. Set the directory to ORACLE_INSTANCE/EMAGENT/emagent_instance name/sysman/config.

  3. In the emd.properties file, change node1.mycompany.com to cfcvip.mycompany.com for the emd_url attribute.

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

    cd INSTANCE_HOME/EMAGENT/emagent_dir/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.mycompany.com:port"/> 
       <Target TYPE="host" NAME=cfcvip.mycompany.com  DISPLAY_NAME=cfcvip.mycompany.com/> 
</Targets>

  5. Stop and restart the agent

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

Make the following changes for the Enterprise Manager server in the Administration Server domain directory:

  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.mycompany.com to cfcvip.mycompany.com

12.2.2.8 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.2.8.1 Transforming Oracle HTTP Server

To transform Oracle HTTP Server for Cold Failover Cluster:

In INSTANCE_HOME/config/OHS/component_name/httpd.conf, change the following attributes

Listen cfcvip.mycompany.com:port #OHS_LISTEN_PORT
Listen cfcvip.mycompany.com:port #OHS_PROXY_PORT
ServerName cfcvip.mycompany.com

Also, perform a single sign-on reregistration, as described in Section 12.2.3.14, "Single Sign-On Re-registration (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 INSTANCE_HOME/config/WebCache/component_name/webcache.xml, change the following attributes:

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

HOST ID="h1" NAME="cfcvip.mycompany.com" PORT="8888" LOADLIMIT="100"
 OSSTATE="ON"/>
<HOST ID="h2" NAME="cfcvip.mycompany.com" PORT="8890" LOADLIMIT="100" OSSTATE="ON"
 SSLENABLED="SSL"/>
12.2.2.8.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.mycompany.com For example, On node Node1, the /etc/hosts file (on UNIX), the entry would be n.n.n.n node1 node1.mycompany.com wcprfx wcprfx.mycompany.com

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

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

  2. In INSTANCE_HOME/config/WebCache/wc1/webcache.xml:

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

      SITE NAME="cfcvip.mycompany.com"

    • Change the Virtual Host Name entries to be cfcvip.mycompany.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.mycompany.com" ID="h0"/>
        <HOST SSLENABLED="SSL" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
 PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8890"
 NAME="cfcvip.mycompany.com" ID="h3"/>
        <VIRTUALHOSTMAP PORT="8094" NAME="cfcvip.mycompany.com">
            <HOSTREF HOSTID="h3"/>
        </VIRTUALHOSTMAP>
        <VIRTUALHOSTMAP PORT="8090" NAME="cfcvip.mycompany.com">
            <HOSTREF HOSTID="h0"/>
        </VIRTUALHOSTMAP>

    • Change cache name entries to be based of wcprfx.mycompany.com where wcprfx.mycompany.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_HOME"
 HOSTNAME="wcprfx.mycompany.com" ORACLEHOME="ORACLE_HOME"
 NAME=" wcprfx.mycompany.com-WebCache">

    • In the MULTIPORT section, change IPADDR from ANY to cfcvip.mycompany.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="stbdd01-vip.us.oracle.com"/>
            <LISTEN SSLENABLED="SSL" PORTTYPE="NORM" PORT="8094"
 IPADDR="cfcvip.mycompany.com">
              <WALLET>ORACLE_INSTANCE/config/WebCache/wc1/keystores/
default</WALLET>
            </LISTEN>
            <LISTEN PORTTYPE="ADMINISTRATION" PORT="8091"
 IPADDR="cfcvip.mycompany.com"/>
            <LISTEN PORTTYPE="INVALIDATION" PORT="8093" IPADDR="
 cfcvip.mycompany.com"/>
            <LISTEN PORTTYPE="STATISTICS" PORT="8092"
 IPADDR="cfcvip.mycompany.com"/>
        </MULTIPORT>

12.2.2.9 Instance-specific considerations

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

12.2.2.9.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 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 on the second node, using the attachHome command located in the ORACLE_HOME/oui/bin/attachHome.sh directory.

12.2.2.9.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 Machine 2, run the following commands:

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

    For example:

    sc create OracleProcessManager_asinst binPath= "X:\Middleware\im_oh\opmn\bin\opmn.exe -S -I X:\Middleware\asinst"

  2. On both Machine 1 and 2, set the service OracleProcessManager_instance_name to be started manually.

    sc config OracleProcessManager_instance_name start= demand

For all installations:

If the system environment variable 'Path' on Machine 1 contains any instance specific information, set this information in the same variable on Machine 2. Also export the registry HKEY_LOCAL_MACHINE\SOFTWARE\Oracle from Machine 1 and import it to Machine 2.

To copy the Start Menu from Machine 1 to Machine 2, copy the files under C:\Document and Settings\All Users\Start Menu\Programs\<Menu> from Machine 1 to Machine 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\

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

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

To configure Node Manager on a Machine,

  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.3 Transforming Oracle Fusion Middleware Components

This section describes the considerations and the transformation steps for each of the Oracle product suites. For detailed explanation on the product components, see the appropriate component chapter in this guide.

12.2.3.1 Transforming Oracle Internet Directory and Its Clients

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

12.2.3.1.1 Transforming Oracle Internet Directory

Follow these steps to transform an Oracle Internet Directory server:

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

    dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry 
changetype: modify 
replace: orclhostname 
orclhostname: cfcvip.mycompany.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. The oidHost used in the above command is the physical hostname listening end point that OID was installed with.

  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. Re-Register OID with the Administration Server

    ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost
 myAdminHost -adminPort 7001 -adminUsername weblogic -componentType OID
 -componentName oid1 -Host cfcvip.mycompany.com
12.2.3.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.mycompany.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.mycompany.com</OID_NODE_HOST>

  3. An Oracle Directory Services Manager instance managing the Oracle Internet Directory server in Section 12.2.2.8.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.mycompany.com

      • Port: 389

      • SSL Enabled: Leave blank

      • User Name: cn=orcladmin

      • Password: ********

      • Start Page: Home (default)

12.2.3.2 Transforming Oracle Virtual Directory and Its Clients

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

12.2.3.2.1 Transforming Oracle Virtual Directory

Follow these steps 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.mycompany.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.3.2.2 Transforming Oracle Virtual Directory Clients

All clients of Oracle Virtual Directory must use the virtual IP cfcvip.mycompany.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.mycompany.com as the location of the Oracle Virtual Directory instance.

12.2.3.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.3.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.mycompany.com virtual IP. Follow the steps in Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" to configure the WLS_ODS managed server to listen on the cfcvip.mycompany.com virtual IP.

12.2.3.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.mycompany.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.mycompany.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.mycompany.com
    WebLogic port
</Location>

12.2.3.4 Transforming Oracle Identity Federation and Its Client

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

12.2.3.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.mycompany.com virtual IP. Follow the steps in Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" to configure the WLS_OIF Managed Server to listen on the cfcvip.mycompany.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.mycompany.com virtual IP, log into the Oracle Enterprise Manager Fusion Middleware Control and perform these steps:

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

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

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

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

    3. Service Provider > Common: change the providerId to cfcvip.mycompany.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.mycompany.com

    5. Authentication Engine > LDAP Directory: Set the ConnectionURL to cfcvip.mycompany.com

The metadata needs to be generated after the above changes are done.

12.2.3.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.mycompany.com to access these applications.

  2. When Oracle HTTP Server is the front end for Oracle Identity Federation, the WebLogic configuration for Oracle Directory Services Manager must specify the virtual IP cfcvip.mycompany.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 Directory Services Manager. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:

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

12.2.3.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.2.4, "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.mycompany.com.

    1. Log into Oracle WebLogic Server 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 host name as cfcvip.mycompany.com.

    6. Set the Frontend Port to the HTTP port

    7. Click Save.

    8. Activate the changes.

    9. Restart the Managed Server.

  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.mycompany.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.mycompany.com
    WebLogic port
</Location>

# Worklist
<Location /integration/>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

# B2B
<Location /b2b>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

# UMS
<Location /sdpmessaging/ >
    SetHandler weblogic-handler
    WebLogicHost cfc.mycompany.com:port
</Location>
 
# UMS WS
<Location /ucs/messaging/webservice >
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

# WSM
<Location /wsm-pm>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

# workflow
<Location /workflow>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    SetHandler weblogic-handler 
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
 </Location>

# Required if SOA is being used for Oracle Image and Process Management
# SOA inspection.wsil
<Location /inspection.wsil>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

12.2.3.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 as well by specifying the listen address of the managed server as the virtual hostname (cfcvip.mycompany.com). In this case, the explicit transformation step is not needed.

12.2.3.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.mycompany.com. Follow the steps in Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" to configure the WLS_OAM1 managed server to listen on the cfcvip.mycompany.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, "General Requirements for Cold Failover Cluster."

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 could share the same virtual IP cfcvip.mycompany.com, or it could be configured 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.3.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.mycompany.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.mycompany.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.mycompany.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 cfvcip.mycompany.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.3.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.mycompany.com). In this case, the explicit transformation step is not needed.

12.2.3.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.mycompany.com. Follow the steps in Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" to configure these managed servers to listen on the cfcvip.mycompany.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, "General Requirements for Cold Failover Cluster."

12.2.3.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.mycompany.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.mycompany.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.mycompany.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 cfvcip.mycompany.com:port
</Location>

#Oracle Adaptive Access Manager Admin Console
<Location /oaam_admin>
    SetHandler weblogic-handler
    WebLogicHost cfvcip.mycompany.com:port
</Location>

12.2.3.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.mycompany.com). In this case, the explicit transformation step is not needed.

12.2.3.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.mycompany.com. Follow the steps in Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" to configure these managed servers to listen on the cfcvip.mycompany.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, "General Requirements for Cold Failover Cluster."

12.2.3.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.mycompany.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.mycompany.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.mycompany.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 cfvcip.mycompany.com:port
</Location>

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

12.2.3.9 Transforming an Oracle WebCenter Suite

The WebCenter Suite is made up of Java EE components. The typical WebCenter Suite deployment has three managed servers, though more are possible when you have WebCenter custom applications. Typical managed server deployments include:

  • WC_SPACES

  • WC_PORTLETS

  • WC_COLLABORATION

  • WC_UTILITIES

These are Java EE components, therefore, the procedure for Cold Failover Cluster transformation is to configure the Managed Server to which they are deployed to listen on the Virtual IP. In many Cold Failover Cluster deployments of Oracle WebCenter, OWSM-PM may be deployed to WLS_Portlets and WLS_Spaces container. See Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" for information on transforming Oracle WebCenter Suite managed servers.

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

LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"
 
# Spaces
 
<Location /webcenter>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
<Location /webcenterhelp>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
<Location /rss>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
# Portlet
 
<Location /portalTools>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
<Location /wsrp-tools>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
# WSM
 
<Location /wsm-pm>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
# Discussions, Personalization, Analytics, and Activity Graph
 
<Location /owc_discussions>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
<Location /owc_personalization>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
<Location /owc_analytics>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>
 
<Location /owc_activitygraph>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location

12.2.3.10 Transforming Oracle Portal, Forms, Reports, and Discoverer

is made up of these four separate components. 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.3.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 the domain be shutdown before editing these files.

  1. Transform the WLS_FORMS managed server. See Section 12.2.2.4, "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.2.6, "Transforming Oracle Process Management and Notification Server" for this procedure.

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

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

  5. Reregister Single Sign-On using the steps described in the Section 14.6.4.9.4, "Enable Single Sign On."

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

    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.mycompany.com
    WebLogic port
    DynamicServerList OFF
</Location>
12.2.3.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.2.4, "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.2.6, "Transforming Oracle Process Management and Notification Server" for this procedure

    In addition, do the following:

    1. In the opmn.xml file, located in the INSTANCE_HOME/config/OPMN/opmn, directory, change the Reports server name in ias-component to reflect its new name.

      For example:

      <ias-component id="ReportsServer_virtual_hostname_instance_name">
<process-set id="ReportsServer_virtual_hostname_instance_name"
 restart-on-death="true" numprocs="1">
</ias-component>

      For example:

      <ias-component id="ReportsServer_cfcvip_asinst1">
   <process-set id="ReportsServer_ cfcvip asinst1"restart-on-death="true"
   numprocs="1">
</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: ReportServer_node1_asinst) to ReportsServer_virtual_hostname_instance_name (example: ReportServer_cfcvip_asinst)

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

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

  5. Reregister Single Sign-On. To do this perform the steps described in the Section 14.6.4.9.4, "Enable Single Sign On."

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

    <Location /reports>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

  7. In the directory INSTANCE_HOME/config/ReportsServerComponent, rename the following directory:

    ReportsServer_physical_hostname_instance_name (for example: ReportServer_node1_asinst)

    To the following:

    ReportsServer_VIP_instance_name (for example: ReportServer_cfcvip_asinst)

    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 INSTANCE_HOME/EMAGENT/emagent_dir/sysman/emd directory, change the following:

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

    2. Change the report server name from ReportsServer_physical_hostname_instance_name (for example: ReportServer_node1_asinst) to ReportsServer_VIP_instance_name (for example: ReportServer_cfcvip_asinst) for the following two elements:

      Target TYPE="oracle_repserv"

      Target TYPE="oracle_repapp"

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

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

    • Rename reportsserver_physical hostname_instance name.dat to reportsserver_virtual host name_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>/1ww3jm/configuration directory (for example, the DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww3jm/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>/1ww3jm/META-INF directory (for example, the DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww3jm/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.3.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.2.4, "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.2.6, "Transforming Oracle Process Management and Notification Server" for this procedure.

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

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

  5. Reregister Single Sign-On. To do this perform the steps described in the Section 14.6.4.9.4, "Enable Single Sign On."

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

    <IfModule mod_weblogic.c><Location /discoverer>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
    DynamicServerList ON
</Location>
</IfModule>
12.2.3.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.2.4, "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.2.6, "Transforming Oracle Process Management and Notification Server" for this procedure.

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

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

  5. Reregister Single Sign-On. To do this, perform the steps described in the Section 14.6.4.9.4, "Enable Single Sign On."

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

    # WLS routing configuration
<Location /portal>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

<Location /portalTools>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

<Location /wsrp-tools>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

<Location /richtextportlet>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

<Location /jpdk>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

<Location /portalHelp>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

<Location /portalHelp2>
    SetHandler weblogic-handler
    WebLogicHost cfcvip.mycompany.com
    WebLogic port
</Location>

  7. Rewire the Portal Repository:

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

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

    2. Change InValidation and Administrator password.

      In the Navigator Window Expand the Web Tier tree.

      Click the component wc1.

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

      Enter a new invalidation 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

      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 Midtier

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

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

      SSL Protocol: Enter this value 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.mycompany.com mysite.mycompany.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.mycompany.com:WCHTTPPort/portal/pls/portal

  8. 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 Web Logic is ware that it is using a virtual site name and port so that it can generate internal URLs appropriately:

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

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

    2. Select WLS_PORTAL from the home page or select Environment, and then Clusters from the Domain Structure menu.

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

    4. Click Protocol, and select HTTP.

    5. Enter the following values:

      Frontend Host: Cfcvip.mycompany.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 Activate Changes in the Change Center window to enable editing.

    7. Restart the WLS_PORTAL managed server

12.2.3.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.2.4, "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.mycompany.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.mycompany.com
    WebLogic port
</Location>
12.2.3.10.6 Transforming a Custom ADF Deployment

For a deployment that uses a custom ADF application, Cold Failover Cluster can be used in the same way as any of the Fusions 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.2.4, "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.mycompany.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.mycompany.com
    WebLogic port
</Location>

12.2.3.11 Transforming an Oracle Enterprise Content Management Suite

The Oracle Enterprise Content Management Suite (ECM Suite) has products such as Oracle Imaging and Process Management (Oracle I/PM), Oracle Universal Content Management (Oracle UCM), Oracle Universal Records Management (URM), and Oracle Inbound Refineries (Oracle IBR).

These managed servers typically included when the ECM Suite is installed:

  • Oracle I/PM (WLS_IPM)

  • Oracle UCM (WLS_UCM)

  • Oracle URM (WLS_URM)

  • Oracle IBR (WLS_IBR)

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.2.4, "Transforming Oracle WebLogic Managed Servers" for information on transforming Oracle I/PM, UCM (or URM), and IBR managed servers.

Additional things to consider in Cold Failover Cluster deployments of ECM Suite include:

  • In many Cold Failover Cluster deployments of ECM Suite, the likely deployment topologies include:

    • Both I/PM and UCM deployed together on the same node of a hardware cluster.

    • A deployment with I/PM on one node of a hardware cluster and UCM on the other node of a hardware cluster 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.mycompany.com:port/cs, the Webserver HTTP Address is the hostname and port of the location of the HTTP server front-ending the ECM managed servers. 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 ECM servers, this is likely to be cfcvip.mycompany.com.

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

      • Content Server Version: CS 11g

      • Primary: cfcvip.mycompany.com:4444

      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.

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

    LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"

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

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

12.2.3.12.1 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

The following section describes how to transform Oracle BI Publisher to work in a Cold Failover Cluster environment.

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.mycompany.com. Follow the steps in Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.mycompany.com virtual IP.

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

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, "General Requirements for Cold Failover Cluster." The specific requirement for Cold Failover Cluster deployments of the Oracle BI Publisher is to make sure 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:

  • Transaction logs and JMS persistence store

  • BI Publisher configuration folder

  • BI Publisher Catalog repository

  • BI Publisher Scheduler temp directory

Transforming Oracle BI Publisher Clients

Follow these steps to transform Oracle BI Publisher clients:

  1. Oracle BI Publisher clients must use the virtual IP cfcvip.mycompany.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 file to specify the virtual IP cfcvip.mycompany.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.mycompany.com
   WebLogic port
 </Location>
 
# WSM-PM
<Location /wsm-pm>
   SetHandler weblogic-handler
   WebLogicHost cfcvip.mycompany.com
   WebLogic port
</Location>
12.2.3.12.2 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.mycompany.com. Follow the steps in Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.mycompany.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, "General Requirements for Cold Failover Cluster."

Transforming Oracle RTD Clients

Follow these steps to transform Oracle RTD clients:

  1. Oracle RTD clients must use the virtual IP cfcvip.mycompany.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 file to specify the virtual IP cfcvip.mycompany.com as the address for the Oracle RTD managed server, as shown in the following example:

    <Location /rtis>
   SetHandler weblogic-handler
   WebLogicHost cfcvip.mycompany.com
   WebLogic port
 </Location>
 
<Location /schemas>
   SetHandler weblogic-handler
   WebLogicHost cfcvip.mycompany.com
   WebLogic port
</Location>
 
<Location /ws>
   SetHandler weblogic-handler
   WebLogicHost cfcvip.mycompany.com
   WebLogic port
</Location>
 
# WSM-PM
<Location /wsm-pm>
   SetHandler weblogic-handler
   WebLogicHost cfcvip.mycompany.com
   WebLogic port
</Location>
 
# RTD
<Location /ui>
   SetHandler weblogic-handler
   WebLogicHost cfcvip.mycompany.com
   WebLogic port
 </Location>

12.2.3.13 Transforming Oracle BI Office and its Clients

This section describes how to transform Oracle BI Office to work in a cold Failover Cluster environment. To transform Oracle BI Office to a Cold Failover Cluster Deployment, follow the instructions in this section.

Oracle BI 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.mycompany.com. Follow the steps in Section 12.2.2.4, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.mycompany.com virtual IP.

All requirements related to Middleware Home placement and other domain artifacts on shared storage that can be failed over apply as Section 12.2.1, "General Requirements for Cold Failover Cluster" 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 VIP value.

Transforming Oracle BI Office Clients

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

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

12.2.3.14 Single Sign-On Re-registration (If required)

Single Sign-On (SSO) re-registration typically applies only to Oracle Portal, Forms, Reports, and Discoverer. Once the front end listening endpoint on Oracle HTTP Server for this tier has been changed to the Virtual IP, it becomes necessary to do SSO re-registration so that the URL to be protected is configured with the virtual IP. To re-register 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. Execute ORACLE_HOME/sso/bin/ssoreg.sh (ssoreg.bat for Windows) with the following parameters:

    -site_name cfcvip.mycompany.com:port
-mod_osso_url http://cfcvip.mycompany.com 
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

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

  4. Copy /tmp/osso.conf file to the mid-tier home location:

    ORACLE_INSTANCE/config/OHS/ohs1

  5. Restart Oracle HTTP Server by issuing the following command from the ORACLE_HOME/opmn/bin/directory:

    opmnctl restartproc process-type=OHS

  6. Log into the SSO server through the following URL:

    http://login.mycompany.com/pls/orasso

  7. In the Administration page and then Administer Partner applications, delete the entry for node1.mycompany.com.

12.2.4 Transforming an Oracle Database

In an Oracle Fusion Middleware deployment, the Oracle database plays an important role. In a typical Cold Failover Cluster deployment of Oracle Fusion Middleware, the database is also deployed as a cold failover cluster. This section described the steps to transform a single instance Oracle database to a Cold Failover Cluster database. This transformation should be done 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 used by the database instance.

    This requires changes to the listener.ora file. Ensure that the HOST name in the listener configuration has the value of the virtual hostname. In addition, ensure that the listener port is not in use by any other process (Oracle or third party).

    <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.mycompany.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.mycompany.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 used with the Oracle Application server. 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' )
 
SQL> execute DBMS_SERVICE.START_SERVICE(   'cfcdb_asservice' )

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

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

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

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

In this section illustrates some example 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.

12.3.1 Example Topology 1

Figure 12-3 shows an Oracle WebCenter 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.mycompany.com). The database is also on the same hardware cluster. It uses a different virtual IP (cfcvip2.mycompany.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 back up for each.

This topology is the recommended topology for most Cold Failover Cluster deployments. The example is for Identity Management, but this is true for the oracle SOA, Oracle WebCenter, and Oracle Portal, Forms, Reports, and Discoverer suites as well. In this 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 utilized.

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:

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

Assumptions

The procedures in this section assume that:

  • All the Fusion Middleware components are in a nostage deployment.

  • The starting topology is an active-active cluster of the product suite (Node1 and Node2).

  • The administration server is on Node1 to start.

  • It shares the same domain home as the Managed Server on Node1.

  • The MW_HOME path is the same on both Node1 and Node2.

Start Topologies

Refer to the following sections to achieve the start topologies:

These procedures also apply to customer applications deployed to Oracle WebLogic cluster installations, provided the previously stated 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 is mountable by both Node1 and Node2, 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. Shutdown the cluster of the component Managed Servers and Administration Server.

  2. Shutdown the Node Manager process on each of the nodes (if it is running).

  3. Back up of the entire domain.

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

    For Linux:

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

    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 enabled on the interface "Local Area Connection."

    netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0

  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 Oracle WebLogic Server Administration Console.

    Create a Machine for the Virtual Host.

    1. Select Environment, and then Machines.

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

    3. Click New.

    4. In the Name field, enter cfcvip.mycompany.com

    5. Select the appropriate operating system.

    6. Click OK.

    7. Select the machine you just created.

    8. Click the Servers tab.

    9. Click Add.

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

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

    12. Click Finish.

    13. Click Activate Changes.

    Configure the administration server to listen on cfcvip.mycompany.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.mycompany.com

    5. 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.mycompany.com:7001/console

    • http://cfcvip.mycompany.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.

    • 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 up 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.mycompany.com:7001/console

    • http://cfcvip.mycompany.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 up 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.