7 Installing in High Availability Environments: Overview

This chapter provides an overview of the high availability configurations supported by Oracle Application Server. Subsequent chapters provide the details. This chapter also lists the common requirements.

Contents of this chapter:

• Section 7.1, "Overview of High Availability Configurations"

• Section 7.2, "Installation Order for High Availability Configurations"

• Section 7.3, "Requirements for High Availability Configurations"

7.1 Overview of High Availability Configurations

This chapter provides only a brief overview of the high availability configurations in Oracle Application Server. For a complete description of the configurations, see the Oracle Application Server High Availability Guide.

Oracle Application Server supports the following types of high availability configurations at installation time. Note that there are multiple variants of each type.

• Section 7.1.1, "OracleAS Cold Failover Cluster"

• Section 7.1.2, "OracleAS Clusters"

• Section 7.1.3, "OracleAS Disaster Recovery"

• Section 7.1.4, "Summary of Differences"

For a quick summary of the high availability configurations, see Section 7.1.4, "Summary of Differences".

7.1.1 OracleAS Cold Failover Cluster

Oracle Application Server provides an active-passive model for its components using OracleAS Cold Failover Clusters. In an OracleAS Cold Failover Cluster topology, two or more Oracle Application Server instances are configured to serve the same application workload but only one instance is active at any particular time. These instances run on two different nodes in a hardware cluster. These two nodes also have access to a shared storage, on which you install the Oracle home for the Oracle Application Server instance.

One of the nodes in the hardware cluster is the active node. It mounts the shared storage and runs the Oracle Application Server instance. The other node is the passive, or standby, node. It runs only when the active node fails. During the failover event, the passive node mounts the shared storage and runs the Oracle Application Server instance.

The most common properties of an OracleAS Cold Failover Cluster configuration include:

• Shared storage

  The Oracle home for the Oracle Application Server instance is typically installed on storage that is shared by the nodes in the OracleAS Cold Failover Cluster topology. The passive Oracle Application Server instance has access to the same Oracle binaries, configuration files, and data as the active instance.

• Virtual hostname

  During OracleAS Infrastructure installation, you can specify a virtual hostname in the Specify Virtual Hostname screen. This OracleAS Infrastructure virtual hostname can be managed by a hardware cluster or a load balancer and is used by the middle-tier and OracleAS Infrastructure components to access the OracleAS Infrastructure. This is regardless of whether the OracleAS Infrastructure is in a single node installation, in the OracleAS Cold Failover Cluster solution, or in the OracleAS Clusters solution.

  The virtual hostname is associated with a virtual IP. This is the name that gives the Oracle Application Server middle tiers a single system view of the OracleAS Infrastructure with the help of a hardware cluster or load balancer. This name-IP entry must be added to the DNS that the site uses, so that the middle-tier nodes can associate with the OracleAS Infrastructure without having to add this entry into their local /etc/hosts (or equivalent) file. For example, if the two physical hostnames of the hardware cluster are node1.mycompany.com and node2.mycompany.com, the single view of this cluster can be provided by the name selfservice.mycompany.com. In the DNS, selfservice maps to the virtual IP address of the OracleAS Infrastructure, which either floats between node1 and node2 via a hardware cluster or maps to node1 and node2 by a load balancer, all without the middle tier knowing which physical node is active and actually servicing a particular request.

  See Also:

  Oracle Application Server High Availability Guide

  You cannot specify a virtual hostname during Oracle Application Server middle-tier installation, but you can still use a virtual hostname via a hardware cluster or load balancer by following the post-installation configuration steps for cold failover cluster middle tiers.

• Failover procedure

  An active-passive configuration also includes a set of scripts and procedures to detect failure of the active instance and to failover to the passive instance while minimizing downtime.

The advantages of an OracleAS Cold Failover Cluster configuration include:

• Increased availability

  If the active instance fails for any reason or must be taken offline, an identically configured passive instance is prepared to take over at any time.

• Reduced operating costs

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

• 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. An active-passive configuration has only one instance serving requests at any particular time.

In general, the term OracleAS Cold Failover Cluster describes clustering at the Oracle Application Server instance level. However, if it is necessary to call out the specific type of instances being clustered, this document will use OracleAS Cold Failover Cluster (type) to characterize the cluster solution. For example:

• OracleAS Cold Failover Cluster (Identity Management)

• OracleAS Cold Failover Cluster (Infrastructure)

From the entry point of an Oracle Application Server system (content cache) to the back end layer (data sources), all the tiers that are crossed by a client request can be configured in a redundant manner either in an active-active configuration using OracleAS Clusterss or in an active-passive configuration using OracleAS Cold Failover Clusters.

See Chapter 8, "Installing in High Availability Environments: OracleAS Cold Failover Cluster" for installation details.

7.1.2 OracleAS Clusters

Oracle Application Server provides an active-active model for all its components with OracleAS Clusters. In an OracleAS Clusters, two or more Oracle Application Server instances are configured to serve the same application workload. These instances typically run on different nodes.

You need an external load balancer in front of the nodes. Clients direct requests to these nodes through the load balancer, which then sends the requests to one of the nodes for processing. The load balancer uses its own algorithm to decide which node to send a request to.

The most common properties of an OracleAS Clusters configuration include:

• Identical instance configuration

  The instances are meant to serve the same workload or application. Their identical configuration guarantees that they deliver identical responses to the same request. Note that some configuration properties are allowed to be instance-specific, such as local host name information.

• Managed as a virtual single instance

  Changes in configuration made to one instance usually need to be propagated to the other instances in an active-active topology.

• Independent operation

  The loss of one Oracle Application Server instance in an active-active topology should not affect the ability of the other instances to continue to serve requests.

The advantages of an OracleAS Clusters configuration include:

• Increased availability

  An active-active topology has built-in redundancy (multiple Oracle Application Server instances run the same components). Loss of one instance can be tolerated because other instances can continue to serve the same requests.

• Increased scalability and performance

  Multiple identically-configured instances provide the capability to have a distributed workload shared among different machines and processes. New instances can also be added as the demand of the application grows.

In general, the term OracleAS Clusters describes clustering at the Oracle Application Server instance level. However, if it is necessary to call out the specific type of instances being clustered, this document will use OracleAS Clusters (type) to characterize the cluster solution. For example:

• two or more Oracle Identity Management instances are known as OracleAS Cluster (Identity Management)

For details on OracleAS Cluster (Identity Management), see Chapter 9, "Installing in High Availability Environments: OracleAS Cluster (Identity Management)".

7.1.3 OracleAS Disaster Recovery

OracleAS Disaster Recovery configurations have the following characteristics:

• A production site and a standby site that mirrors the production site. Typically, these sites are located some distance from each other to guard against site failures such as floods, fires, or earthquakes. During normal operation, the production site handles all the requests. If the production site goes down, the standby site takes over and handles all the requests.

• Each site has all the hardware and software to run. It contains nodes for running OracleAS Infrastructure and the middle tiers; load balancers; and DNS servers.

OracleAS Disaster Recovery includes OracleAS Infrastructure and middle tiers. For details, see Chapter 10, "Installing in High Availability Environments: OracleAS Disaster Recovery".

7.1.4 Summary of Differences

Table 7-1 summarizes the differences among the high availability configurations.

Table 7-1 Differences Among the High Availability Configurations

	OracleAS Cold Failover Cluster	OracleAS Clusters	OracleAS Disaster Recovery
Node configuration	Active-Passive	Active-Active	Active-Passive
Hardware cluster	Yes	No	Optional (hardware cluster required only if you installed the OracleAS Infrastructure in an OracleAS Cold Failover Cluster configuration)
Virtual hostname	Yes	No	Yes
Load balancer	No	Yes	NoFoot 1
Shared storage	Yes	No	No

^Footnote 1 Geographic load balancer may be used to perform site name switchover.

7.2 Installation Order for High Availability Configurations

For all high availability configurations, you install the components in the following order:

1. OracleAS Metadata Repository

2. Oracle Identity Management components

   If you are distributing the Oracle Identity Management components, you install them in the following order:

   1. Oracle Internet Directory and Oracle Directory Integration Platform

   2. OracleAS Single Sign-On and Oracle Delegated Administration Services

3. Middle tiers

   Note that you can install middle tiers before the other components and reassociate them with the high availability configuration following installation of the other components.

7.3 Requirements for High Availability Configurations

This section describes the requirements common to all high availability configurations. In addition to these common requirements, each configuration has its own specific requirements. See the individual chapters for details.

Note:

You still need to meet the requirements listed in Chapter 2, "Requirements", plus requirements specific to the high availability configuration that you plan to use.

The common requirements are:

• Section 7.3.1, "Check Minimum Number of Nodes"

• Section 7.3.2, "Check That Groups Are Defined Identically on All Nodes"

• Section 7.3.3, "Check the Properties of the oracle User"

7.3.1 Check Minimum Number of Nodes

You need at least two nodes in a high availability configuration. If a node fails for any reason, the second node takes over.

7.3.2 Check That Groups Are Defined Identically on All Nodes

Check that the /etc/group file on all nodes in the cluster contains the operating system groups that you plan to use. You should have one group for the oraInventory directory, and one or two groups for database administration. The group names and the group IDs must be the same for all nodes.

See Section 2.6, "Operating System Groups" for details.

7.3.3 Check the Properties of the oracle User

Check that the oracle operating system user, which you log in as to install Oracle Application Server, has the following properties:

• Belongs to the oinstall group and to the osdba group. The oinstall group is for the oraInventory directory, and the osdba group is a database administration group. See Section 2.6, "Operating System Groups" for details.

• Has write privileges on remote directories.

7.3.4 Check for Previous Oracle Installations on All Nodes

Check that all the nodes where you want to install in a high availability configuration do not have existing oraInventory directories.

Details of all Oracle software installations are recorded in the Oracle Installer Inventory directory. Typically, this directory is unique to a node and named oraInventory. The directory path of the Oracle Installer Inventory directory is stored in the oraInst.loc file.

The existence of this file on a node confirms that the node contains some Oracle software installation. Since the high availability configurations require installations on multiple nodes with Oracle Installer Inventory directories on a file system that may not be accessible on other nodes, the installation instructions in this chapter and subsequent chapters for high availability configurations assume that there have not been any previous installations of any Oracle software on any of the nodes that are used for this high availability configuration. The oraInst.loc file and the Oracle Installer Inventory directory should not exist on any of these nodes prior to these high availability installations.

To check if a node contains an oraInventory directory that could be detected by the installer:

1. On each node, check for the existence of the oraInst.loc file. This file is stored in the /etc directory.

   If a node does not contain this file, then it does not have an oraInventory directory that will be used by the installer. You can check the next node.

2. For nodes that contain the oraInst.loc file, rename the file and the oraInventory directory. The installer then prompts you to enter a location for a new oraInventory directory.

   For example enter the following commands as root:

   # cat /etc/oraInst.loc
   inventory_loc=/localfs/app/oracle/oraInventory 
   inst_group=dba 
   # mv /etc/oraInst.loc /etc/oraInst.loc.orig 
   # mv /localfs/app/oracle/oraInventory /localfs/app/oracle/oraInventory.orig
   
   

Since the oraInst.loc file and the Oracle Installer Inventory directory are required only during the installation of Oracle software, and not at runtime, renaming them and restoring them later does not affect the behavior of any installed Oracle software on any node. Make sure that the appropriate oraInst.loc file and Oracle Installer Inventory directory are in place before starting the Oracle Universal Installer.

Note:

For an OracleAS Disaster Recovery configuration, the correct oraInst.loc file and associated oraInventory directory are required during normal operation, not just during installation.