| Oracle® Fusion Middleware High Availability Guide 11g Release 1 (11.1.1) Part Number E10106-20 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware High Availability Guide 11g Release 1 (11.1.1) Part Number E10106-20 |
|
|
PDF · Mobi · ePub |
This chapter describes how to configure and manage active-passive topologies. It contains the following sections:
Section 12.1, "Oracle Fusion Middleware Cold Failover Cluster Topology Concepts"
Section 12.2, "Configuring Oracle Fusion Middleware for Active-Passive Deployments"
Section 12.3, "Oracle Fusion Middleware Cold Failover Cluster Example Topologies"
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.
You can use a two-node Cold Failover Cluster 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. If the active node fails, the standby node activates and the middle-tier components continue servicing clients from that node. All middle-tier components fail over to the new active node. No middle-tier components run on the failed node after the failover.
The most common properties of a Cold Failover Cluster configuration include:
Shared Storage: Shared storage is a key property of a Cold Failover Cluster. 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 all participating nodes in the Cold Failover Cluster configuration can access. 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.
Virtual hostname: In a Cold Failover Cluster solution, two nodes share a virtual hostname and a virtual IP. (The virtual hostname maps to the virtual IP and is used interchangeably in this guide.) However, only 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 moves 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 name cfcvip.mycompany.com provides the single view of this cluster. 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: Typically, a Cold Failover Cluster deployment uses a hardware cluster. 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 deploy 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 and shared storage for Oracle Fusion Middleware and database installs.
Clusterware running to manage node and component failures
Planned Switchover and Unplanned Failover: A typical Cold Failover Cluster deployment is a two-node hardware cluster. To maximize utilization, both 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 maintenance or if either node fails, the surviving node hosts 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:
Stop the middle-tier service on the primary node if the node is still available.
Fail over the virtual IP from the current active node to the passive node. Bring it down on the current node then enable it and bring it up on the passive node.
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.
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 enables 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. See Chapter 13, "Using Oracle Cluster Ready Services" for details on managing a Cold Failover Cluster environment with Oracle Cluster-Ready Services. Note that you can use any available clusterware to manage cluster failover.
Manual failover
With this approach, you run the planned switchover steps manually; both the detection of the failure and the failover itself is manual. This approach 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 fail over the instance to the passive node.
Active-Passive Topologies: Advantages
Increased availability
If the active instance fails or must be taken offline, an identically configured passive instance is ready to take over at any time. This provides an increased level of availability than a normal single instance deployment. Also, active-passive deployments provide availability and protection against planned and unplanned maintenance operation of the hardware. If you must bring down a node for planned maintenance, you can bring up middleware services on the passive node. You switch back to the old node at appropriate times.
Reduced operating costs
In an active-passive configuration only one set of processes is up and serving requests. Managing 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 simulate 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 applications 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 is 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 affect the single node Cold Failover Cluster deployment performance.
Active-passive deployments have a shorter downtime than a single node deployment. However, downtime is much shorter in an active-active deployment.
Oracle Fusion Middleware components come in a variety of Java EE container-deployed components and non-Java EE components. Oracle Internet Directory, Oracle Virtual Directory, and Oracle Reports are system components. Oracle SOA Suite and Oracle WebCenter Portal are Java EE components that are deployed to Oracle WebLogic Server.
Administration Console and Oracle Enterprise Manager Fusion Middleware Control also deploy to the WebLogic container. You can deploy both Java EE and system components to Cold Failover Cluster environments; they can co-exist on the same system or on different systems. When on the same system, you can configure them to failover as a unit, sharing the same virtual IP, or failover independently using separate virtual IPs. In most Oracle Fusion Middleware deployments, a database is used either for the component metadata created using Repository Creation Utility (RCU), or for application data. In many cases, a Cold Failover Cluster middle tier deployment uses a Cold Failover Cluster database, both deployed to the same cluster. The typical deployment has the two components configured as separate failover units using different VIPs and different shared disks on the same hardware cluster.
To create an active-passive topology for Oracle Fusion Middleware:
Install the component as a single instance configuration. If you plan to transform this instance to a Cold Failover Cluster deployment, install it using a shared disk. That is, the Middleware home, the Instance home (for system components) and the domain directory (for a WebLogic deployment on a shared disk). Everything that fails over as a unit should be on a shared disk.
After the installation, transform the deployment into a Cold Failover Cluster deployment and configure it to listen on a Virtual IP. The Virtual IP is configured on the current active node. It fails over, along with the Oracle Fusion Middleware deployment, to the passive node when failure occurs.
This general procedure applies to the Cold Failover Cluster Oracle database. For example, the Oracle database instance is installed as a single instance deployment and subsequently transformed for Cold Failover Cluster. A Cold Failover Cluster Oracle Fusion Middleware deployment can also use an Oracle Real Application Clusters (Oracle RAC) database.
The following sections describe the procedures for post-installation configuration to transform a single instance deployment to a Cold Failover Cluster deployment.
The rest of this chapter describes how to transform Cold Failover Cluster for each individual component in the Oracle Fusion Middleware suite. The first section details the procedure for the basic infrastructure components, and the subsequent section does so for the individual Oracle Fusion Middleware component. Any given deployment, for example an Oracle instance or domain, has more than one of these in a machine. To transform the entire instance or domain:
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).
This section includes the following topics:
Section 12.2.2, "Directories and Environment Variables Terminology"
Section 12.2.3, "Transforming Oracle Fusion Middleware Infrastructure Components"
Section 12.2.4, "Transforming Oracle Fusion Middleware Components"
A Cold Failover Cluster deployment has at least two nodes. You install on one of these nodes; the other node is the passive node. Requirements for both nodes are as follows:
The nodes should be similar in all respects at the operating system level. For example, they should be the same operating system, version, and patch level.
The nodes should have similar hardware characteristics. This ensures predictable performance during normal operations and on failover. Oracle suggests designing each node for capacity to handle both its normal role and the additional load required to handle a failover scenario. This is not required only if the SLA agreement indicates that, during outage scenarios, reduced performance is acceptable.
The nodes should have the same mount point free so that mounting shared storage can occur to the same node during normal operations and failover conditions.
The user ID and group ID on the two nodes are similar, and the user ID and group ID of the user owning the instance is the same on both nodes.
The oraInventory location is the same on both nodes and has similar accessibility of the instance or domain owner. The location of the oraInst.loc file, as well as the beahomelist file should be the same.
Since a given instance uses the same listen ports irrespective of the machine on which it is currently active, ensure that the ports that the Cold Failover Cluster instance uses are free on both the nodes.
Note:
Before you start the transformation, back up the entire domain. Oracle also recommends that you create a local backup file before editing it. For more information, see the Oracle Fusion Middleware Administrator's Guide. Oracle recommends backing up:
All domain directories
All Instance homes
The database repository and the Middleware homes (optional)
The following list describes the directories and variables used in this chapter:
ORACLE_BASE: This environment variable and related directory path refers to the base directory under which Oracle products are installed.
MW_HOME: This environment variable and related directory path refers to the location where Fusion Middleware (FMW) resides.
WL_HOME: This environment variable and related directory path contains installed files necessary to host a WebLogic Server.
ORACLE_HOME: This environment variable and related directory path refers to the location where a specific Oracle FMW Suite, such as SOA, is installed.
ORACLE_COMMON_HOME: The Oracle home that contains the binary and library files that are common to all the Oracle Fusion Middleware software suites. In particular, the Oracle Common home includes the files required for Oracle Enterprise Manager Fusion Middleware Control (which is used to manage the Fusion Middleware) and the Oracle Java Required Files (JRF).
DOMAIN_HOME: This directory path refers to the location where the Oracle WebLogic Domain information (configuration artifacts) is stored.
ORACLE_INSTANCE: An Oracle instance contains one or more system components, such as Oracle Web Cache, Oracle HTTP Server, or Oracle Internet Directory. An Oracle instance directory contains updatable files, such as configuration files, log files, and temporary files.
/localdisk: The root of the directory tree when the FMW install (either MW_HOME or DOMAIN_HOME) is on a local disk. It is used to represent the MW_HOME on local disk.
/shareddisk: Root of the directory tree when the FMW install (either MW_HOME or DOMAIN_HOME) is on a shared storage system that is mounted by any one node of a CFC configuration. It is used to represent the MW_HOME on shared disk.
The example values this guide uses and that Oracle recommends for consistency are:
ORACLE_BASE: /u01/app/oracle
MW_HOME (Apptier): ORACLE_BASE/product/fmw
ORACLE_COMMON_HOME: MW_HOME/oracle_common
WL_HOME: MW_HOME/wlserver_10.3
Example location for Applications Directory: ORACLE_BASE/admin/domain_name/apps
Example location for Oracle Instance: ORACLE_BASE/admin/instance_name
Oracle recommends ORACLE_BASE as the shared storage mount point. In most cases, this location helps to ensure that all the persistent bits of a failover unit are on the same shared storage. When more than one Cold Failover Cluster exists on a node, and each one fails over independently, different mount points will exist for each failover unit.
An Oracle Fusion Middleware deployment comprises basic infrastructure components that are common across all the product sets. This section describes Cold Failover Cluster transformation steps for these components.
There are two Administration Server topologies supported for Cold Failover Cluster configuration. The following sections describe these two topologies and provide installation and configuration steps to prepare the Administration Server for Cold Failover Cluster transformation.
This section includes the following topics:
Section 12.2.3.5, "Transforming the Administration Server for Cold Failover Cluster"
Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers"
Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server"
Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance"
Section 12.2.3.10, "Transforming Web Tier Components and Clients"
Figure 12-1 shows the first supported topology for Oracle Cold Failover Cluster.
Figure 12-1 Administration Server Cold Failover Cluster Topology 1
In Figure 12-1, the Administration Server runs on a two-node hardware cluster: Node 1 and Node 2. The Administration Server listens on the Virtual IP or hostname. The Middleware Home and the domain directory are on a shared disk that is mounted on Node 1 or Node 2 at any given point. Both the Middleware home and the domain directory should be on the same shared disk or shared disks that can fail over together. If an enterprise has multiple Fusion Middleware domains for multiple applications or environments, this topology is well suited for Administration Server high availability. You can deploy a single hardware cluster to host these multiple Administration Servers. Each Administration Server can use its own virtual IP and set of shared disks to provide high availability of domain services.
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 enables simultaneous mounts on more than one node. This is done as a regular single-instance installation. See the component chapters to install the Administration Server (and Enterprise Manager) alone. The overall procedure for each suite is as follows:
For Oracle SOA or Oracle WebCenter Portal:
Install the WebLogic Server software.
See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.
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 Portal.
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:
Install the WebLogic Server software.
See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.
Using Oracle Identity Management 11g Installer, install and configure the IDM Domain using the create domain option. In the Configure Components Screen, de-select everything except Enterprise Manager (selected by default)
See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
For Oracle Portal, Forms, Reports and Discoverer:
Install the WebLogic Server software.
See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.
Using Oracle Fusion Middleware 11g Portal, Forms, Reports, and Discoverer Installer, install and configure the Classic Domain using the create domain option. In the Configure Components Screen, ensure that Enterprise Manager is selected.
Note:
In this case, at least one more Managed Server for the product components is also installed in this process; you cannot install the Administration Server on its own. You must transform this Managed Server to CFC using the specific procedure for the component. It is part of the same failover unit as the Administration Server.
For Oracle Business Intelligence:
Install the WebLogic Server software.
See the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.
Using Oracle Fusion Middleware 11g Business Intelligence Installer, install and configure the Business Intelligence domain using the create new BI system option.
Note:
In this case, at least one more Managed Server for the product components is also installed in this process; you cannot install the Administration Server on its own. You must transform this Managed Server to CFC using the specific procedure for the component. It is part of the same failover unit as the Administration Server.
Configuring the Administration Server for Cold Failover Cluster
To configure the Administration Server for Cold Failover Cluster:
Provision the Virtual IP using the following commands as root user:
For Linux
/sbin/ifconfig interface:index IP_Address netmask netmask /sbin/arping -q -U -c 3 -I interface IP_Address
Where IP Address is the virtual IP address and the netmask is the associated netmask. In the following example, the IP address is being enabled on the interface eth0.
/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0 /sbin/arping -q -U -c 3 -I eth0 130.35.46.17
For Windows:
netsh interface ip add address interface IP Address netmask
Where IP Address is the virtual IP address and the netmask is the associated netmask. In the example below, the IP address is being enabled on the interface 'Local Area Connection'.
netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0
Transform the Administration Server instance to Cold Failover Cluster following the procedure in section Section 12.2.3.5, "Transforming the Administration Server for Cold Failover Cluster."
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
Failover the Administration Server manually to the second node using the following procedure:
Stop the Administration Server process (and any other process running out of a given Middleware Home)
Unmount the shared storage from Node1 where the Middleware Home and domain directory exists.
Mount the shared storage on Node2, follow storage specific commands.
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
Enable the virtual IP on Node2 using similar commands as in Step 1.
Start the Administration Server process.
DOMAIN_HOME/bin/startWebLogic.sh
Where DOMAIN_HOME is the location of your domain directory.
Validate access to both the Administration Server and Enterprise Manager console.
Figure 12-2 shows the second supported Administration Server topology for Oracle Cold Failover Cluster.
Figure 12-2 Administration Server Cold Failover Cluster Topology 2
In Figure 12-2, the Administration Server runs on a two-node hardware cluster: Node 1 and Node 2. The Administration Server is listening on the Virtual IP or hostname. The domain directory used by the Administration Server is on a shared disk. This is mandatory. This shared disk is mounted on Node 1 or Node 2 at any given point. The Middleware Homes, which contain the software, (WebLogic Home and the Oracle Home) are not necessarily on a shared disk. They can be on the local disk as well. The Administration Server uses the Middleware Home on Node1 for the software when it runs on Node1 and it uses the Middleware Home on Node2 when it runs on Node2. You must maintain the two Middleware Homes to be identical in terms of deployed products, Oracle Homes, and patches. In both cases, it uses the configuration available in the shared Domain Directory/Domain Home. Since this is shared, it ensures that the same configuration is used before and after failover.
This shared domain directory may also have other Managed Servers running. It may also be used exclusively for the Administration Server. If the domain directory is shared with other managed servers, appropriate consideration must be made for their failover when the Administration Server fails over. Some of these considerations are:
If the shared storage can be mounted as read/write on multiple nodes simultaneously, the Administration Server domain directory can be shared with other managed servers. In addition, it can fail over independently of the Managed Server. The Administration Server can failover and Managed Servers can continue to run independently on their designated nodes. This is possible because the Administration Server in this case requires only failover of the VIP, and does not require failover of the shared disk. The domain directory/domain home continues to remain available by the Managed Servers. Example of such storage include a NAS or a SAN/Direct attached storage with Cluster file system.
If only one node can mount the shared storage a time, sharing the Administration Server domain directory with a Managed Server implies that when the Administration Server fails over, the Managed Server that runs off the same domain directory must be shut down.
In this topology, you can use a hardware cluster to help automate failover (when used with properly configured clusterware). However, it is not required. A single hardware cluster can be deployed to host these multiple Administration Servers. Each Administration Server can use its own virtual IP and set of shared disks to provide domain services high availability.
This topology is supported for Oracle SOA Suite and Oracle WebCenter Portal Suite only.
Note:
For the Oracle Identity Management, an alternate topology is also supported for Cold Failover Cluster. See the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management for more details.
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 Portal:
Install the Oracle WebLogic Server software on Node 1.
Install the Oracle Home for SOA or WebCenter on Node 1.
Repeat steps 1 and 2 on Node 2.
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.
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:
Provision the Virtual IP. For example:
For Linux:
/sbin/ifconfig eth0:1 IP_Address netmask netmask /sbin/arping -q -U -c 3 -I eth0 IP_Address
Where IP_Address is the virtual IP address and the netmask is the associated netmask. In the following example, the IP address is being enabled on the interface eth0.
/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0 /sbin/arping -q -U -c 3 -I eth0 130.35.46.17
For Windows:
netsh interface ip add address interface IP_Adress netmask
Where IP_Address is the virtual IP address and the netmask is the associated netmask. In the example below, the IP address is being enabled on the interface "Local Area Connection".
netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0
Transform the Administration Server instance to Cold Failover Cluster using the procedure in Section 12.2.3.5, "Transforming the Administration Server for Cold Failover Cluster."
Validate the Administration Server by accessing the consoles on the virtual IP.
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
Failover the Administration Server manually to the second node:
Stop the Administration Server process and any other process running out of a given Middleware Home.
Unmount the shared storage from Node1 where the Middleware Home or domain directory exists.
Mount the shared storage on Node2, following storage specific commands.
Disable the virtual IP on Node1:
For Linux:
/sbin/ifconfig interface:index down
In the following example, the IP address is being disabled on the interface eth0.
/sbin/ifconfig eth0:1 down
For Windows:
netsh interface ip delete address interface addr=IP Address
Where IP Address is the virtual IP address. In the following example, the IP address is enabled on the interface 'Local Area Connection'.
netsh interface ip delete address 'Local Area connection' addr=130.35.46.17
Enable the virtual IP on Node 2.
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 Administration Server and Enterprise Manager console.
To transform the Administration Server installed on a shared disk from Node 1, follow the steps in this section. These steps transform the container, therefore, both the Administration Console and Oracle Enterprise Manager Fusion Middleware Control, are transformed for Cold Failover Cluster. This results in other components such as OWSM-PM, deployed to this container, to become Cold Failover Cluster ready as well. The address for all of these services transforms cfcvip.mycompany.com. After installation, to transform a non Cold Failover Cluster instance, to a Cold Failover Cluster:
Log into the Administration Console.
Create a Node for the Virtual Host
Select Environment, and then Machines.
In the Change Center, click Lock & Edit then New.
In the Name field, enter cfcvip.mycompany.com
Note:
Keep the Listen Address field set to localhost; the CFC solution relies on this setting. Do not change it to the virtual IP address or any other value.
For the Machine OS field, select the appropriate operating system.
Click Next then Finish.
On the Summary of Machines tab, click the machine name just created.
Click the Servers tab then click Add.
Select an existing server, and associate it with this machine.
In the select server drop down list ensure AdminServer is selected.
Click Activate Changes.
Configure the Administration Server to Listen on cfcvip.mycompany.com.
Select Environment, and then Servers from the Domain Structure menu.
In the Change Center, click Lock & Edit.
Click on the Administration Server (AdminServer)
Change the Listen Address to cfcvip.mycompany.com
Click Save.
Click Activate Changes.
Restart the Administration Server.
Note:
Typically Administration Server transformation to Cold Failover Cluster takes place at domain creation time No other changes to other parts of the domain are expected. If this change happens after domain creation and other components are installed in the domain, follow the steps in the following Administration Server transformation section.
Changing Client Side Configuration for Administration Server
Any existing entities in the domain must communicate with the Administration Server using the new address. For example, when starting the Managed Servers manually, the Administration Server address should be specified as cfcvip.mycompany.com.
In the instance.properties file, located in the INSTANCE_HOME/config/OPMN/opmn directory, make the following change:
adminHost=cfcvip.mycompany.com
If the Oracle Instance is to be registered or reregistered with a Cold Failover Cluster Administration Server using the OPMN registration commands, the AdminHost location in the opmnctl command should reference the new location of the Administration Server (cfcvip.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:
Set the directory to ORACLE_INSTANCE/EMAGENT/emagent_asinst_ 1/sysman/config.
In the emd.properties file, change node1.mycompany.com to cfcvip.mycompany.com in the following attributes:
REPOSITORY_URL
EmdWalletSrcUrl
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.
All Oracle Fusion Middleware components are deployed to a Managed Server. An important step to convert an application or component that is deployed to Oracle WebLogic Server to Cold Failover Cluster is to change its listen address to the virtual IP being used. This change is done for the specific Managed Server to which the component has been deployed. You can make this change using the Administration Console or using WLST commands.
The following example describes the generic steps for Cold Failover Cluster transformation of a Managed Server named WLS_EXMPL. These steps apply to any Managed Server in the Fusion Middleware components.
This section includes the following topics:
In the following procedure, cfcvip.mycompany.com is the virtual IP used for the Cold Failover Cluster and WLS_EXMPL is the managed server to be transformed.
Log into the Administration Console.
Create a machine for the virtual host:
Select Environment > Machines.
In the Change Center, click Lock & Edit then click New.
For the Name field, enter cfcvip.mycompany.com
For the Machine OS field, select the appropriate operating system.
Click Next and then click Finish.
Click the newly created Node.
Click Node Manager tab.
Update Listen Address: cfcvip.mycompany.com.
Click Save.
Click Activate Changes.
Stop the WLS_EXMPL Managed server:
Choose Environment > Servers.
Click Control.
Select WLS_EXMPL.
Select Force Shutdown Now in the Shutdown drop-down menu.
Associate the WLS_EXMPL Managed Server with the VirtualHost Machine:
Choose Environment > Servers.
In the Change Center, click Lock & Edit.
Click Configuration.
Select WLS_EXMPL.
For Node, assign the newly created Node by assigning it from the pull down menu.
For Listen Address, enter cfcvip.mycompany.com.
Click Save.
Click Activate Changes.
Start the WLS_EXMPL Managed Server:
Choose Environment > Servers.
Click Control.
Select WLS_EXMPL.
Click Start.
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):
In the command line, enter:
WL_HOME/server/bin/setWLSEnv.sh WL_HOME/common/bin/wlst.sh
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.
After the Managed server transformation completes, verify that all references to it use the new Listen Address cfcvip.mycompany.com. If Oracle HTTP Server serves as a front end to this Managed server, change any mod_wls_ohs configuration with mount points referring to applications in this Managed server to route to the new listening end point.
Node Manager can be used in a Cold Failover Cluster environment. The possible configurations are:
A Node Manager that listens on the virtual IP as well and fails over with the rest of the Cold Failover Cluster stack. With ASCRS based deployments, the Node Manager must be part of the same Middleware Home as where the Cold Failover Cluster Fusion Middleware instance is running. This Node Manager is assumed to be dedicated for this Fusion Middleware instance. In this case, Oracle recommends having additional Network Channels listening on the localhost configured. Other Node Managers may co-exist on the box listening on other ports. For more details, see Chapter 13, "Using Oracle Cluster Ready Services."
A Node Manager that does not failover with the rest of the Cold Failover Cluster stack. In this case, Node Manager is not configured for Cold Failover Cluster and listens on all IPs on the machine, and not specifically on the virtual IP for Cold Failover Cluster. The failover nodes also have a similarly configured Node Manager already available and configured. The Node associated with the WebLogic instance communicates with the Node Manager on the localhost. For more details, see the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.
For Cold Failover Cluster in general, port usage should be planned so that there are no port conflicts when failover occurs.
To convert the Node Manager to Cold Failover Cluster:
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.
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
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.
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 is registered with an Administration Server, make the following changes in these files:
In the topology.xml file in the DOMAIN_HOME/opmn directory of the Administration Server domain, change hostname entries for this specific Oracle instance (being transformed to Cold Failover Cluster) to cfcvip.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="/11gas3/MW/asinst" host="cfcvip.mycompany.com" port="6701">
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">
In the instance.properties file in the INSTANCE_HOME/config/OPMN/opmn directory, change adminHost=<physical hostname> to adminHost=<cfcvip.mycompany.com>.
Restart all OPMN components.
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:
Stop the Enterprise Manager agent using the following command:
cd INSTANCE_HOME/EMAGENT/emagent_dir/bin ./emctl stop agent
Set the directory to ORACLE_INSTANCE/EMAGENT/emagent_instance name/sysman/config.
In the emd.properties file, change node1.mycompany.com to cfcvip.mycompany.com for the emd_url attribute.
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>
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:
Set your directory to MW_HOME/user_projects/domains/domain_name/sysman/state.
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
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.
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.4.14, "Single Sign-On Reregistration (If required)."
Clients of Oracle HTTP Server
If an Oracle Web Cache instance is routing to Oracle HTTP Server that has been transformed to Cold Failover Cluster, in 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"/>
To transform an Oracle Web Cache for Cold Failover Cluster:
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, make this change on all nodes in the file located at C:\SystemRoot\system32\drivers\etc\hosts. SystemRoot is either Winnt or Windows.
In INSTANCE_HOME/config/WebCache/wc1/webcache.xml:
Change node1.mycompany.com to cfcvip.mycompany.com node1.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="cfcvip.mycompany.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>
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:
For UNIX platforms follow these steps:
Failover the Middleware Home from Node 1 (the installation node) to the failover node (Node 2), following the mount/unmount procedure described previously.
As root, do the following:
Create an oraInst.loc file located in the /etc directory identical to the file on Node1.
Run the root.sh file located in the ORACLE_HOME directory on node2, if it is required, and is available for the product suite.
Create the oraInventory on the second node, using the attachHome command located in the ORACLE_HOME/oui/bin/attachHome.sh directory.
For Windows, follow these steps:
For Application Server Instances (Web Tier, OID/OVD for IDM Installs, Oracle Portal, Form, Reports, and Discoverer):
To create the OPMN service on Node 2, run the following commands:
sc create OracleProcessManager_instance_name binPath= "ORACLE_HOME\opmn\bin\opmn.exe -S -I Instance_Home"
For example:
sc create OracleProcessManager_asinst binPath= "X:\Middleware\im_oh\opmn\bin\opmn.exe -S -I X:\Middleware\asinst"
On both Node 1 and 2, set the service OracleProcessManager_instance_name to be started manually.
sc config OracleProcessManager_instance_name start= demand
For Oracle Business Intelligence Installations:
When Oracle Business Intelligence is used in a Cold Failover Cluster, certain Windows registry entries used by Oracle Business Intelligence must be exactly the same on the active node and the passive node. To ensure that these registry entries are the same on the active and passive nodes, follow these steps for exporting registry entries on Node 1 and importing those registry entries on Node 2 (where Node 1 is the active node and Node 2 is the passive node).
Export the Oracle Business Intelligence Registry Entries on Node 1
Follow these steps to export registry entries for Oracle Business Intelligence on Node 1:
On Node 1, start the Windows Registry Editor. To do this, type the following from the Windows command line:
C:\>regedit
In the Registry Editor, go to and select the node HKEY_LOCAL_MACHINE\SOFTWARE\Oracle. Right-click the node and choose Export. Save these entries as a uniquely named .reg file.
Go to and select the node HKEY_LOCAL_MACHINE\SOFTWARE\ODBC. Right-click the node and choose Export. Save these entries as a uniquely named .reg file.
Go to and select the node HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services. Export each node within this node that begins with "Oracle" to a uniquely named .reg file.
Go to and select the node HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services. Export each node within this node that begins with Oracle to a uniquely named .reg file.
Go to and select the node HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Export each node within this node that begins with "Oracle" to a uniquely named .reg file.
Copy all the .reg files you created to Node 2.
Exit the Registry Editor.
Import the Oracle Business Intelligence Registry Entries on Node 2
Follow these steps to import registry entries for Oracle Business Intelligence on Node 1 to Node 2:
On Node 2, double-click Oracle_BI1\bifoundation\install\vc80\vcredist_x86.exe.
Double-click on each .reg file you copied from Node 1. In each case, click Yes to import the contents into the registry.
For all installations:
If the system environment variable 'Path' on Node 1 contains any instance specific information, set this information in the same variable on Node 2. Also export the registry HKEY_LOCAL_MACHINE\SOFTWARE\Oracle from Node 1 and import it to Node 2.
To copy the Start Menu from Node 1 to Node 2, copy the files under C:\Document and Settings\All Users\Start Menu\Programs\<Menu> from Node 1 to Node 2. You can do this with any Windows Backup tool, or Zip utility. For example, using the Windows Backup Utility:
Invoke the Windows Backup Utility by selecting Accessories, System Tools, and then Backup.
Select C:\Document and Settings\All Users\Start Menu\Programs\<Menu>
Copy the backup file to the second node.
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 Nodes.
Node Manager should be set to start manually on both nodes.
To configure Node Manager on a Node,
Ensure that the Middleware Home is available on the machine.
Install the service running the above command.
Set it to be started manually using the following command:
sc config nodemanager_service_name start= demand
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.
This section describes how to transform Oracle Internet Directory and its clients.
To transform an Oracle Internet Directory server from PS1:
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
Run the following command:
ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin –w <adminPasswd> -f oidcfc.ldif
OID must be up at the time of running this command. oidHost is the physical hostname listening end point installed with OID.
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
Reregister OID with the Administration Server
ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost
myAdminHost -adminPort 7001 -adminUsername weblogic -componentType OID
-componentName oid1 -Host cfcvip.mycompany.com
To upgrade Oracle Internet Directory from PS1, run the following:
ORACLE_HOME/opmn/bin/upgradenonj2eeapp.sh -oracleInstance ORACLE_INSTANCE
To transform an Oracle Internet Directory client:
All clients of the Oracle Internet Directory server should use the virtual IP cfcvip.mycompany.com to access that Oracle Internet Directory server.
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:
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
Enter the following value to set the LDAP address to the virtual IP:
OID_NODE_HOST>cfcvip.mycompany.com</OID_NODE_HOST>
An Oracle Directory Services Manager instance managing the Oracle Internet Directory server in Section 12.2.3.10.1, "Transforming Oracle HTTP Server" must use the virtual IP to connect to the Oracle Internet Directory server.
For example, from the Oracle Directory Services Manager screen, verify that you can connect to Oracle Internet Directory using the virtual server by following these steps:
Select the Connect to a directory --> Create A New Connection link in the upper right hand corner.
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)
This section describes how to transform Oracle Virtual Directory and its clients.
To transform an Oracle Virtual Directory server:
In a text editor, open the listeners.os_xml file in the ORACLE_INSTANCE/config/OVD/componentname directory.
Enter the following value to set the LDAP address to the virtual IP:
<host>cfcvip.mycompany.com</host>
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
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.
This section describes how to transform Oracle Directory Integration Platform, Oracle Directory Services Manager, and their clients.
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.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the WLS_ODS managed server to listen on the cfcvip.mycompany.com virtual IP.
Follow these steps to transform Oracle Directory Integration Platform and Oracle Directory Services Manager clients:
Clients of Oracle Directory Integration Platform and Oracle Directory Services Manager must use the virtual IP cfcvip.mycompany.com to access these applications.
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>
This section describes how to transform Oracle Identity Federation and its clients.
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.3.6, "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:
Go to Farm > Identity and Access > OIF.
In the right frame, go to Oracle Identity Federation > Administration and then make these changes:
Server Properties: change the host to cfcvip.mycompany.com
Identity Provider > Common: change the providerId to cfcvip.mycompany.com
Service Provider > Common: change the providerId to cfcvip.mycompany.com
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
Authentication Engine > LDAP Directory: Set the ConnectionURL to cfcvip.mycompany.com
The metadata needs to be generated after the above changes are done.
Follow these steps to transform Oracle Identity Federation clients:
Clients of Oracle Identity Federation must use the virtual IP cfcvip.mycompany.com to access these applications.
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>
Oracle SOA Suite is made up of Java EE components deployed to a managed server. The typical configuration has deployments of OWSM-PM applications and SOA applications. The SOA applications are always deployed to a separate managed server. In many Cold Failover Cluster deployments OWSM-PM is deployed to the Administration Server, however, they can be deployed to a managed server by itself, for example, WLS_OWSM, or to the SOA managed server. The WLS_SOA container may have applications such as BPEL, UMS, and B2B deployed or may additionally have the BPM components deployed as well. In all cases, since these are Java EE components, the Cold Failover Cluster transformation procedure involves configuring the managed server to which they are deployed to listen on the virtual IP. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming managed servers WLS_OWSM and WLS_SOA.
In addition, follow these steps to transform a SOA component managed server:
Set the front-end host for WLS_SOA managed server to cfcvip.mycompany.com.
Log into the Administration Console.
In the Environment section, select Servers.
Select the name of the managed server.
Select Protocols, then select HTTP.
In the Frontend Host field, enter the hostname as cfcvip.mycompany.com.
Set the Frontend Port to the HTTP port
Click Save.
Activate the changes.
Restart the Managed Server.
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 cfcvip.mycompany.com WebLogicPort 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>
This section describes how to transform Oracle Access Manager to work in a Cold Failover Cluster environment.
As with other managed servers created using Configuration Wizard, a Cold Failover Cluster set up that requires the managed server to listen on a virtual IP can be done during the initial creation and by specifying the listen address of the managed server as the virtual hostname (cfcvip.mycompany.com). In this case, the explicit transformation step is not needed.
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.3.6, "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, "Cold Failover Cluster Requirements."
The Oracle Access Manager console is deployed as part of the Administration Server for the domain. For Cold Failover Cluster configuration of this console, the whole Administration Server needs to be configured in Active Passive. The Administration Server can share the same virtual IP cfcvip.mycompany.com, or you can configure it to fail over independently using a separate virtual IP and shared disk. If they are using the same virtual IP, the Administration Server and the Oracle Access Manager managed server will fail over as a unit.
Follow these steps to transform Oracle Access Manager clients:
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.
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 cfcvip.mycompany.com:port
</Location>
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>
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.
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.3.6, "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, "Cold Failover Cluster Requirements."
Follow these steps to transform Oracle Adaptive Access Manager clients:
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.
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 cfcvip.mycompany.com WebLogicPort port
</Location>
#Oracle Adaptive Access Manager Admin Console
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
</Location>
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.
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.3.6, "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, "Cold Failover Cluster Requirements."
Follow these steps to transform Oracle Identity Manager clients:
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.
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 cfcvip.mycompany.com:port
WebLogicPort port
</Location>
Refer to Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for more information about making configuration changes in Oracle Identity Manager.
The WebCenter Suite is made up of Java EE components. The typical WebCenter Suite deployment has four managed servers, though more are possible if you develop WebCenter Portal applications. Typical managed server deployments include:
WC_SPACES
WC_PORTLETS
WC_COLLABORATION
WC_UTILITIES
These are Java EE components, therefore, the procedure for Cold Failover Cluster transformation is to configure the Managed Server they are deployed to so that it listens on the Virtual IP. In many Cold Failover Cluster deployments of Oracle WebCenter Portal, OWSM-PM may be deployed to WC_PORTLETS and WC_SPACES container. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming Oracle WebCenter Portal Suite managed servers.
When you use Oracle HTTP Server as the front end, the mod_weblogic configuration for WebCenter Suite applications should provide the VIP cfcvip.mycompany.com as the managed servers address instead. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points that WebCenter components use.
To use a virtual host as the managed servers address:
Verify that the Virtual Host cfcvip.mycompany.com is enabled on the machine that the managed server runs on.
Verify that the managed server Listen Address is set to cfcvip.mycompany.com.
Use the address cfcvip.mycompany.com in the mod_wl_ohs.conf file.
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.
Oracle Forms is made up of both Java EE and system components. To configure Oracle Forms for Cold Failover Cluster:
Note:
The transformation process requires that you shutdown the domain before editing these files.
Transform the WLS_FORMS managed server. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for this procedure. Start the Domain Administration Server to do the Managed server transformation, and shut it down once the Managed Server transformation is finished.
Transform the Oracle Forms OPMN. See Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" for this procedure.
Transform Enterprise Manager. See Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance" for this procedure.
Transform Oracle Forms Web tier components. See Section 12.2.3.10, "Transforming Web Tier Components and Clients" for this procedure.
Reregister Single Sign-On using the steps described in the Section 14.6.4.9.4, "Enable Single Sign On."
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>
Oracle Reports is made up of both Java EE and system components. To configure Oracle Reports for Cold Failover Cluster:
Transform the WLS_REPORTS managed server. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for this procedure. Start the Domain Administration Server to do the Managed Server transformation, and shut it down once the Managed Server transformation is finished.
Transform the Oracle Reports OPMN. See Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" for this procedure.
In addition, do the following:
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>
In DOMAIN_HOME/opmn/topology.xml of the Administration Server domain home, change all occurrences of the Report server name from ReportsServer_physical hostname_instance_name (example: ReportsServer_node1_asinst) to ReportsServer_virtual_hostname_instance_name (example: ReportsServer_cfcvip_asinst)
Transform Oracle Enterprise Manager. See Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance" for this procedure.
Transform Oracle Reports Web tier components. See Section 12.2.3.10, "Transforming Web Tier Components and Clients" for this procedure.
Reregister Single Sign-On. To do this perform the steps described in the Section 14.6.4.9.4, "Enable Single Sign On."
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>
In the directory INSTANCE_HOME/config/ReportsServerComponent, rename the following directory:
ReportsServer_physical_hostname_instance_name (for example: ReportsServer_node1_asinst)
To the following:
ReportsServer_VIP_instance_name (for example: ReportsServer_cfcvip_asinst)
Note:
All new logs for the report server go to ReportsServer_virtual_hostname_instance_name after restart of the instance.
In the renamed directory, replace physical hostname with a virtual hostname in the following files:
component-logs.xml
logging.xml
In the targets.xml file, located in the INSTANCE_HOME/EMAGENT/emagent_dir/sysman/emd directory, change the following:
Change all hostnames from node1.mycompany.com to cfcvip.mycompany.com
Change the report server name from ReportsServer_physical_hostname_instance_name (for example: ReportsServer_node1_asinst) to ReportsServer_virtual_hostname_instance_name (for example: ReportsServer_cfcvip_asinst) for the following two elements:
Target TYPE="oracle_repserv"
Target TYPE="oracle_repapp"
In the INSTANCE_HOME/reports directory, replace the physical hostname with a virtual hostname in reports_install.properties.
In the INSTANCE_HOME/reports/server directory, rename the following files:
Rename reportsserver_physical_hostname_instance name.dat to reportsserver_virtual_ hostname_instance name.dat
Rename rep_wls_reports_physical_ hostname_instance name.dat to rep_wls_reports_virtual_hostname_instance_name.dat
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).
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).
Start the Administration Server and Managed Servers in the WebLogic Domain, as well as the Oracle instances to validate the Cold Failover Cluster installation.
Oracle Discoverer is made up of both Java EE and system components. To configure Oracle Discoverer for Cold Failover Cluster:
Transform the WLS_DISCO managed server. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for this procedure. Start the domain Administration Server to do the Managed Server transformation, and shut it down once the Managed Server transformation is finished.
Transform the Oracle Discoverer OPMN. See Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" for this procedure.
Transform Oracle Enterprise Manager. See Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance" for this procedure.
Transform Oracle Discoverer Web tier components. See Section 12.2.3.10, "Transforming Web Tier Components and Clients" for this procedure.
Reregister Single Sign-On. To do this perform the steps described in the Section 14.6.4.9.4, "Enable Single Sign On."
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>
Oracle Portal is made up of both Java EE and system components. To configure Oracle Portal for Cold Failover Cluster:
Transform the WLS_PORTAL managed server. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for this procedure. Start the domain Administration Server to do the Managed Server transformation, and shut it down once the Managed Server transformation is finished.
Transform the Oracle Portal OPMN. See Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" for this procedure.
Transform Oracle Enterprise Manager. See Section 12.2.3.9, "Transforming Oracle Enterprise Manager for an Oracle Instance" for this procedure.
Transform Oracle Portal Web tier components. See Section 12.2.3.10, "Transforming Web Tier Components and Clients" for this procedure.
Reregister Single Sign-On. To do this, perform the steps described in the Section 14.6.4.9.4, "Enable Single Sign On."
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>
Rewire the Portal Repository:
Log into the domain WebLogic Server Enterprise Manager using the following URL:
http://cfcvip.mycompany.com:7001/em
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.
Expand the Fusion Middleware menu in the left pane.
Select Classic.
Click Portal
The Portal Domain information page appears.
Right-click on Portal and select Settings, and then Wire Configuration.
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.
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.
Click Apply to start the rewire.
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
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:
Log in to the Administration Console using the following URL:
http://cfcvip.mycompany.com:7001/console
Select WLS_PORTAL from the home page or select Environment, and then Clusters from the Domain Structure menu.
In the Change Center, click Lock & Edit.
Click Protocol, and select HTTP.
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.
Click Activate Changes in the Change Center window to enable editing.
Restart the WLS_PORTAL managed server
Oracle BAM is made up of Java EE components deployed to a managed server. Since these are Java EE components, the Cold Failover Cluster transformation procedure involves configuring the managed server to which they are deployed to listen on the virtual IP. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming managed servers WLS_BAM.
When using Oracle HTTP Server as the front end, the mod WebLogic configuration for the applications deployed to WLS_BAM should provide the VIP cfcvip.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>
For a deployment that uses a custom ADF application, use Cold Failover Cluster in the same way as any Fusion Middleware deployment. The domain is created in this case using the installation from Oracle Application Developer DVD. Since this is primarily a Java EE components. the Cold Failover Cluster transformation procedure involves configuring the managed server to which they are deployed to listen on the virtual IP. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming managed servers.
When using Oracle HTTP Server as the front end, the mod WebLogic configuration for the applications deployed to WLS_ADF (the name of the managed server for the customer app) should provide the VIP cfcvip.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>
The Oracle WebCenter Content has products such as Oracle WebCenter Content: Imaging (Imaging), Oracle WebCenter Content (WebCenter Content), Oracle WebCenter Content: Records, and Oracle WebCenter content: Inbound Refinery.
These managed servers are typically included when you install Oracle WebCenter Content:
Imaging (WLS_IPM)
WebCenter Content (WLS_UCM)
Records (WLS_URM)
Inbound Refinery (WLS_IBR)
For Cold Failover deployments, the recommendation is to set up the Application tier and the Web tier as recommended for CFC deployments in previous sections of this chapter, and to follow the procedure for Cold Failover Cluster transformation for these managed servers. See Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" for information on transforming Imaging, UCM (or URM), and IBR managed servers.
Additional things to consider in Cold Failover Cluster deployments of Oracle WebCenter Content include:
In many Cold Failover Cluster deployments of Oracle WebCenter Content, the likely deployment topologies include:
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 WCC 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 WCC 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:
In the left-hand pane, click Manage Connections, and then Create Content Server Connection.
Enter a name and description for the new connection, and then click Next.
In the Connection Settings screen, enter the following:
Content Server Version: CS 11g
Primary: cfcvip.mycompany.com:4444
Click Next.
In the connection security screen, leave the default selections for the WebLogic user, and then click Next.
Review the connection details and click Submit.
In addition, when Oracle HTTP Server is the front end for Oracle WebCenter Content applications, the mod_weblogic configuration should use the VIP cfcvip.mycompany.com for the managed servers address. To do this, change the WebLogic host configuration in the webserver proxy plugin configuration files for the mount points used by WCC components. For example, use a text editor to make the following edits in the mod_wl_ohs.conf file:
# Content Server
<Location /cs>
SetHandler weblogic-handler
WebLogicHost cfcvip.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>
Oracle Business Intelligence is an integrated business intelligence (BI) solution that provides the business user with a complete picture across the entire organization. Oracle Business Intelligence is designed to quickly and easily integrate diverse data sources, find information from the database, share the database information, and exploit the data to learn more about the business and its customers.
This section describes active-passive high availability for Oracle Business Intelligence Enterprise Edition, Oracle Business Intelligence Publisher and Oracle Real-Time Decisions.
Requirements for Transforming Oracle Business Intelligence
Before you transform Oracle BI, you must ensure that any OPMN revisions you made to transform OPMN take effect. (Section 12.2.3.8, "Transforming Oracle Process Management and Notification Server" describes the OPMN transformation steps you followed.)
To force OPMN revisions to take effect:
Restart the Administration Server.
Restart OPMN. See Using OPMN in the Oracle Fusion Middleware Oracle Process Manager and Notification Server Administrator's Guide for more information on restarting OPMN.
This section includes the following topics:
Section 12.2.4.12.1, "Transforming Oracle Business Intelligence Enterprise Edition and its Clients"
Section 12.2.4.12.2, "Transforming Oracle Business Intelligence Publisher and its Clients"
Section 12.2.4.12.3, "Transforming Oracle Real-Time Decisions and its Clients"
This section describes how to transform Oracle Business Intelligence Enterprise Edition (Oracle BI EE) to work in a Cold Failover Cluster environment.
Transform Managed Server
Oracle BI Enterprise Edition is deployed to a managed server (for example, BI_SERVER1) and the procedure for Cold Failover Cluster transformation is to configure this managed server after install to listen on the virtual IP cfcvip.mycompany.com. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.mycompany.com virtual IP. After these steps, restart the managed server using the Administration Console or the WLST command line.
All requirements for placing the Middleware Home and other related domain artifacts on shared storage that can be failed over apply as Section 12.2.1, "Cold Failover Cluster Requirements" describes. The specific requirement for Cold Failover Cluster deployments of the Oracle BI Enterprise Edition is to ensure that the following artifacts are also on the shared disk and available on the same mount points on both nodes of the failover cluster. When configured in the default install, this happens implicitly:
BIEE Presentation Catalog
BIEE Repository Publishing Directory (RPD)
To transform an Oracle BI EE component managed server:
Edit the biee-domain.xml file to replace the hostname with cfcvip.mycompany.com. The biee-domain.xml file is located in this directory:
MW_HOME/user_projects/domains/bifoundation_domain/config/fmwconfig
Set the front-end host for the BI_SERVER managed server to cfcvip.mycompany.com.
Log into the Administration Console.
In the Change Center, click Lock & Edit.
In the Environment section, select Servers.
Select the name of the managed server.
Select Protocols, then select HTTP.
In the Frontend Host field, enter the hostname as cfcvip.mycompany.com.
Set the Frontend Port to the HTTP port
Click Save.
Activate the changes.
Restart the Managed Server.
Transforming System Components
To transform system components:
Log into Oracle Fusion Middleware Console for the domain.
Go to Business Intelligence > Core Application > Capacity Management > Scalability.
For the Oracle Instance (instance1), change the ListenAddress to cfcvip.mycompany.com.
Click Lock and Edit Configuration and change the Listen Address to cfcvip.mycompany.com.
Click Apply.
Click Activate Changes.
Restart both the Managed servers and the System components (using opmnctl).
Transforming Oracle BI Enterprise Edition Clients
Note:
Change data sources that refer to the BI Enterprise Edition instance before you transform the managed server to CFC. See step 4.
To transform Oracle BI Enterprise Edition clients:
Oracle BI Enterprise Edition clients must use the virtual IP cfcvip.mycompany.com to access these applications.
Since WSM-PM is deployed to the same managed server, ensure that the client side configuration changes required for WSM-PM are also complete.
Configure other components in the BI Enterprise Edition product suite, such as Oracle BI Publisher, that use Oracle BI Enterprise Edition services to take advantage of these services using the virtual hostname.
In BI Publisher, data sources that refer to this BI Enterprise Edition instance should change or be created (if new using the new virtual host). To change:
Go to the BI Publisher Administration Console.
Click JDBC Connection under Data Sources.
Edit any Data source for BI Enterprise Edition for this instance to connect to cfcvip.mycompany.com.
Where BI Publisher is integrated with BIEE deployment, configure BI Publisher to discover the Presentation Services at the new virtual address. Check details for these in the BI publisher section of this chapter.
When Oracle HTTP Server is the front end for Oracle BI Enterprise Edition, 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 Server managed server. See the following example:
# BIEE Analytics <Location /analytics> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> <Location /analytics-ws> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> <Location /bimiddleware> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location>
Special Considerations for Windows
To achieve Cold Failover Cluster Deployment on a Windows platform:
Make the shared disk available on drive (for example, E:\).
Install BI EE suite (software-only install) on node1 of the Windows Cluster on E:\.
Delete the software-only install from E:\ by removing the Middleware Home.
Failover the same shared disk to node2 and make it available on node2 as the same drive (E:\).
Install BI EE suite (software-only install) on node2 of the Windows Cluster on E:\.
Invoke the OUI Configuration Wizard and create the WLS domain and the Oracle Instance on E:\.
On Node 1:
Run regedit.
Locate the node HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE.
Right click on this node, click Export, and enter a filename.
Locate the node HKEY_LOCAL_MACHINE\SOFTWARE\ODBC
Right click on this node and click Export. Enter a file name.
Locate the node HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services. Export each node within this node that starts with Oracle to a .reg file.
Locate the node HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services. Export each node within this node that starts with Oracle to a .reg file.
Locate the node HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Export each node within this node that begins Oracle to a .reg file
Copy all the reg files that you exported to node 2.
On Node 2:
Double click Oracle_BI1\bifoundation\install\vc80\vcredist_x86.exe
Double click on each .reg file you copied from node 1. For each file, click Yes to import the contents into the registry.
Enable the Virtual IP on the current node (node2) and perform the transformation steps for this BI suite install in Section 12.2.4.12.1, "Transforming Oracle Business Intelligence Enterprise Edition and its Clients."
This section describes how to transform Oracle Business Intelligence Publisher (Oracle BI Publisher) to work in a Cold Failover Cluster environment.
Transforming Oracle Business Intelligence Publisher
Note:
You must hand edit the BIP connection to BI Presentation server before transforming the managed server to CFC. Change the hostname in MW_HOME/user_projects/domains/bifoundation_domain/config/bipublisher/repository/Admin/Configuration/xmlp-server-config.xml, property SAW_SERVER.
To transform Oracle BI Publisher to work in a Cold Failover Cluster environment:
Open the BI Publisher application at http://hostname:port/xmlpserver and login.
Change the BI Scheduler 's JMS configuration:
Click Administration.
Click Scheduler Configuration (under System Maintenance)
Change Weblogic JNDI URL to t3://cfcvip.mycompany.com:9704
Click Apply.
Transform Managed Server
Oracle BI Publisher is deployed to a managed server, for example, BI_SERVER1, and the procedure for Cold Failover Cluster transformation is to configure this managed server after install to listen on the virtual IP cfcvip.mycompany.com. See Section 12.2.3.6, "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 Administration Console or the WLST command line.
All requirements related to placing the Middleware Home and other related domain artifacts on shared storage that can be failed over apply as described in Section 12.2.1, "Cold Failover Cluster Requirements." The specific requirement for Cold Failover Cluster deployments of the Oracle BI Publisher is to ensure that the following artifacts are also on the shared disk and available on the same mount points on both failover cluster nodes. When configured in the default install, this happens implicitly:
Transaction logs and JMS persistence store
BI Publisher configuration folder
BI Publisher Catalog repository
BI Publisher Scheduler temp directory
BI EE Integration
When you deploy BI Publisher and BI EE together, BI Publisher is integrated to use BI EE Presentation Services. In this setup, the BI EE deployment is typically also a Cold Failover Cluster deployment listening on the same virtual hostname, cfcvip.mycompany.com. In this case, you must change the BI Publisher configuration related to BI EE integration to ensure that BI Publisher discovers the BI EE Presentation Services on this new address. To do this:
Enter the BI Publisher application URL http://hostname:port/xmlpserver and log in.
Change the BI Scheduler JMS configuration:
Click Administration.
Click Scheduler Configuration (under System Maintenance).
Change Weblogic JNDI URL to t3://cfcvip.mycompany.com:9704
Click Apply.
Restart the Managed server using Admin server console or the command line.
All requirements for placing the Middleware Home and other related domain artifacts on a shared storage that can be failed over applies as Section 12.2.1, "Cold Failover Cluster Requirements" describes. The requirement for CFC deployments of Oracle Business Intelligence Publisher ensures that the following artifacts are also on the shared disk and available on the same mount points on both nodes of the failover cluster:
Transaction Logs and JMS persistence Store
BI publisher Configuration Folder
BI Publisher Catalog repository
BI Publisher Scheduler Temp Directory
Transforming Oracle BI Publisher Clients
To transform Oracle BI Publisher clients:
Oracle BI Publisher clients must use the virtual IP cfcvip.mycompany.com to access these applications.
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.
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:<port> </Location> # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 </Location>
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.3.6, "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, "Cold Failover Cluster Requirements."
Transforming Oracle RTD Clients
To transform Oracle RTD clients:
Oracle RTD clients must use the virtual IP cfcvip.mycompany.com to access these applications.
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.
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:<port> </Location> <Location /schemas> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> <Location /ws> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com:<port> </Location> # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 </Location> # RTD <Location /ui> SetHandler weblogic-handler WebLogicCluster APPHOST1:9704, APPHOST2:9704 </Location>
This section provides instructions to transform Oracle BI for Microsoft Office to work in a cold Failover Cluster environment.
Oracle BI for Microsoft Office is deployed to a managed server, for example, BI_Server1, and the procedure for Cold Failover Cluster transformation is to configure this server to listen on the virtual IP cfcvip.mycompany.com. Follow the steps in Section 12.2.3.6, "Transforming Oracle WebLogic Managed Servers" to configure the BI_SERVER1 managed server to listen on the cfcvip.mycompany.com virtual IP.
All requirements for Middleware Home placement and other domain artifacts on shared storage that can fail over apply as Section 12.2.1, "Cold Failover Cluster Requirements" describes.
Note:
For BI Office to work correctly in a CFC configuration, you must change the local host value in the bioffice.xml file to the new virtual IP value. See /bidomain/servers/bi_server1/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INF for the bioffice.xml file.
Transforming Oracle BI for Microsoft Office Clients
All client invocations of BI Office must use cfcvip.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 for Microsoft Office managed server. See the following example:
# BI Office <Location /bioffice> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com WebLogicPort port </Location> <Location /biofficeclient> SetHandler weblogic-handler WebLogicHost cfcvip.mycompany.com WebLogicPort port </Location>
Single Sign-On (SSO) reregistration typically applies only to Oracle Portal, Forms, Reports, and Discoverer. After the front end listening endpoint on Oracle HTTP Server for this tier changes to the Virtual IP, it becomes necessary to do SSO reregistration so that the URL to be protected is configured with the virtual IP. To reregister SSO, perform these steps on the 10.1.x installation of Identity Management where the SSO server resides:
Set the ORACLE_HOME variable to the SSO ORACLE_HOME location.
Run 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
Copy /tmp/osso.conf file to the mid-tier home location:
ORACLE_INSTANCE/config/OHS/ohs1
Restart Oracle HTTP Server by running the following command from the ORACLE_HOME/opmn/bin/directory:
./opmnctl restartproc process-type=OHS
Log into the SSO server through the following URL:
http://login.mycompany.com/pls/orasso
In the Administration page and then Administer Partner applications, delete the entry for node1.mycompany.com.
In a typical Cold Failover Cluster deployment of Oracle Fusion Middleware, the database is also deployed as a cold failover cluster. This section describes how to transform a single instance Oracle database to a Cold Failover Cluster database. Perform this transformation before seeding the database using RCU and subsequent Fusion Middleware installations that use this seeded database.
To enable the database for Cold Failover Cluster:
Change the listener configuration that the database instance uses in the listener.ora file.
Ensure that the HOST name in the listener configuration has the value of the virtual hostname. In addition, ensure that no other process (Oracle or third party) uses the listener port.
<listener_name> =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <virtual hostname>)(PORT = port))
)
)
For example:
LISTENER_CFCDB =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST cfcdbhost.mycompany.com)(PORT = 1521))
)
)
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)
)
)
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;
Shutdown and restart the listener.
Shutdown and restart the database instance.
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' )
To start the service, execute the following SQL*PLUS command:
SQL> execute DBMS_SERVICE.START_SERVICE( 'cfcdb_asservice' )
You can set additional parameters for this service depending on the needs of the installation. See the Oracle Database PL/SQL Packages and Types Reference for details about the DBMS_SERVICE command.
Consider the following procedures for Unix and Windows platform database instances:
For Unix:
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.
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.
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.
This section shows sample Cold Failover Cluster topologies. Since there are many possible combinations of topologies, these topologies are illustrative only. To achieve these topologies, more than one of the transformation steps apply. Refer to the steps mentioned earlier to configure the transformation.
Figure 12-3 shows an Oracle WebCenter Portal Cold Failover Cluster deployment. Both the Administration Server and the WebCenter Managed Servers are in the domain and failover as unit. Therefore, they share the same virtual IP and are installed together on the same shared disk. There may be an Oracle HTTP Server front ending this topology. It is on a separate node in the example topology. It can also be on the same node, and can be part of the Cold Failover Cluster deployment. In this example, the database is also on a separate node. However, it is equally likely that the database is on the same cluster and is also Cold Failover Cluster-based (using its own virtual IP and shared disk).
Figure 12-3 Cold Failover Cluster Example Topology 1
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
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 backup for each.
This topology is recommended for most Cold Failover Cluster deployments. The example is for Identity Management, but this is true for the Oracle SOA, Oracle WebCenter Portal, and Oracle Portal, Forms, Reports, and Discoverer suites. In the recommended architecture, Oracle Fusion Middleware runs as one node of the hardware cluster. The Oracle database runs on the other node. Each node is a backup for the other. The Oracle Fusion Middleware instance and the database instance failover independently of each other, using different shared disks and different VIPs. This architecture also ensures that the hardware cluster resources are optimally used.
Figure 12-5 Cold Failover Cluster Example Topology 3
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.3.5, "Transforming the Administration Server for Cold Failover Cluster," may be required.
Assumptions
The procedures in this section assume that:
All 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
See the following sections to achieve the start topologies:
Oracle SOA Suite: Section 5.13, "Configuring High Availability for Oracle SOA Service Infrastructure and Component Service Engines"
Oracle ADF: Section 6.2, "Configuring an Oracle ADF High Availability Deployment"
Oracle WebCenter Portal: Section 6.4, "Configuring High Availability for WebCenter Portal"
Oracle Identity Manager: Chapter 8, "Configuring High Availability for Identity Management Components"
These procedures also apply to customer applications deployed to Oracle WebLogic cluster installations, if the assumptions are met.
Figure 12-6 shows an example start topology before transforming the Administration Server.
Figure 12-6 Cold Failover Cluster Example Start Topology
Figure 12-7 shows the possible destination topology after transforming the Administration Server for Cold Failover Cluster with the following characteristics:
The Administration Server Domain Home is moved out onto a shared disk that Node1 and Node2 can mount, but is mounted by either one of the two at any given point in time.
It continues to use the original Middleware Home available on Node1 and Node2.
The Listen Address of the Administration Server is moved to a virtual IP.
Figure 12-7 Possible Destination Topologies
To transform the Administration Server in an existing domain:
Shut down the cluster of the component Managed Servers and Administration Server.
Shut down the Node Manager process on each of the nodes, if it is running.
Back up the entire domain.
Provision the Virtual IP on Node1. For example:
For Linux:
/sbin/ifconfig eth0:1 IP_Address netmask netmask /sbin/arping -q -U -c 3 -I eth0 IP_Address
Where IP_Address is the virtual IP address and the netmask is the associated netmask.
In the example below, the IP address is enabled on the interface Local Area Connection.
/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0 /sbin/arping -q -U -c 3 -I eth0 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
Start the Administration Server from the local Domain Home.
cd DOMAIN_HOME/bin
./startWeblogic.sh
Transform the Administration Server instance to Cold Failover Cluster:
Log into the Administration Console.
Create a Node for the Virtual Host.
Select Environment, and then Machines.
In the Change Center, click Lock & Edit. Click New.
In the Name field, enter cfcvip.mycompany.com.
Note:
Keep the Listen Address field set to localhost; the CFC solution relies on this setting. Do not change it to the virtual IP address or any other value.
The Administration Server requires a new Virtual Host Machine so that it can interact with multiple node managers, not just the local one. Each node manager on each host listens on all interfaces, both the real IP and the local host (127.0.0.1). The Administration Server uses the new Virtual Host Machine definition exclusively.
The Virtual Host Machine must point to localhost because localhost is the relative internal address for whatever machine is active; it sticks with the Administration Server. The Administration Server changes from one host to another but keeps the same Virtual Name and VIP. The node manager that is associated with the Administration Server also changes, because the Administration Server uses the localhost attribute in conjunction with the first host and then again, after failover, in conjunction with the second host. See Figure x
Select the appropriate operating system and click OK.
Select the machine you just created.
Click the Servers tab then click Add.
Select an existing server, and associate it with this machine.
In the Select Server drop-down list, ensure AdminServer is selected.
Click Finish then click Activate Changes.
Configure the administration server to listen on cfcvip.mycompany.com.
Select Environment, and then Servers from the Domain Structure menu.
In the Change Center, click Lock & Edit.
Click on the Administration Server (AdminServer).
Change the Listen Address to cfcvip.mycompany.com Click Save.
Stop the Administration Server from the Administration Console.
Select Environment, and then Servers from the Domain Structure menu.
Click Control.
Select Adminserver by clicking on the checkbox next to it.
Shut down Adminserver by selecting Force Shutdown Now under Shutdown pull-down menu.
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
Validate the Administration Server by accessing the consoles on the virtual IP:
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
Shut down the Administration Server on Node1 using the Administration Console.
Ensure that the shared disk is provisioned and mounted on Node1.
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
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
Product suite-specific changes:
In the Oracle Identity Management Product Suite:
Back up the config.xml file, located in the /shareddisk/user_projects/domains/domain_name/config/ directory in this example.
Change WCC Socket Host Filter to VIP in the following files:
{domain}/ucm/ibr/config/config.cfg
{domain}/ucm/urm/config/config.cfg
{domain}/ucm/cs/config/config.cfg
Edit the config.xml file, located in the /shareddisk/user_projects/domains/domain_name/config directory in this example, and make the following changes to source-path:
For dipapp, change source path to ORACLE_HOME/ldap/odi/dipapp/dipapps.ear.
For example:
<app-deployment>
<name>DIP#11.1.1.2.0</name>
<target>cluster_ods</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/ldap/odi/dipapp/dipapps.ear</source_path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>
For the ODSM app, change the source path to ORACLE_HOME/ldap/odsm/odsm.ear
For example:
<app-deployment>
<name>odsm#11.1.1.2.0</name>
<target>cluster_ods</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/ldap/odsm/odsm.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>
For the OIF:
Change the source path of OIF-APP to ORACLE_HOME/fed/install/oif.ear:
<app-deployment>
<name>OIF#11.1.1.2.0</name>
<target>cluster_oif</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/fed/install/oif.ear</source-path>
<security-dd-model>Advanced</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>
Change the source path of oif-libs to ORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear:
<library>
<name>oif-libs#11.1.1.2.0@11.1.1.2.0</name>
<target>cluster_oif</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
</library>
Start the Administration Server:
cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh
Validate the Administration Server by accessing the consoles on the virtual IP.
http://cfcvip.mycompany.com:7001/console
http://cfcvip.mycompany.com:7001/em
Shut down the Administration Server.
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.
Copy the template to Node2:
scp ORACLE_COMMON_HOME/common/bin/cfcdomaintemplate_mngd.jar Node2:ORACLE_COMMON_HOME/common/bin
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.
For Oracle Identity Manager Suite, the following addition steps are required:
For DIP:
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
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:
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
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
Start the Administration Server:
cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh
Start the node manager (if used) on Node1 and Node2:
cd WL_HOME/server/bin
./startNodeManager.sh
Start the component Managed Servers on Node1 and Node2 from the Administration Server Console (if Node Manager used) or from the command line.
Validate the deployment using component-specific functional tests.
Test Administration Server failover.
Failover the Administration Server manually to the second node:
Stop the Administration Server process (and any other process running out of a given Middleware Home).
Unmount the shared storage from Node1 where the Middleware Home or domain directory exists.
Mount the shared storage on Node2, following storage specific commands.
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
Enable the virtual IP on Node2.
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.
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.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|