Oracle® Application Server Installation Guide
10g Release 2 (10.1.2) for Solaris Operating System (SPARC) B14088-03 |
|
Previous |
Next |
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 10.1, "Overview of High Availability Configurations"
Section 10.2, "Installation Order for High Availability Configurations"
Section 10.3, "Requirements for 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.
For a quick summary of the high availability configurations, see Section 10.1.4, "Summary of Differences".
Oracle Application Server provides an active-passive model for all its components using OracleAS Cold Failover Clusters. In an OracleAS 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. These instances can reside on the same machine or on different machines.
The most common properties of an OracleAS Cold Failover Cluster configuration include:
Shared storage
The passive Oracle Application Server instance in an active-passive configuration 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 Cluster solution.
The virtual hostname is the hostname associated with the virtual IP. This is the name that is chosen to give the Oracle Application Server middle-tier 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 (Middle-Tier)
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 Clusters or in an active-passive configuration using OracleAS Cold Failover Clusters.
See Chapter 11, "Installing in High Availability Environments: OracleAS Cold Failover Cluster" for installation details.
Oracle Application Server provides an active-active redundant model for all its components with OracleAS Cluster. In an OracleAS Cluster, two or more Oracle Application Server instances are configured to serve the same application workload. These instances can reside on the same machine or on different machines.The active instances may be front-ended by an external load balancer, which can redirect requests to any of the active instances, or by some other application-level configuration, such as address lists, to distribute the requests.
The most common properties of an OracleAS Cluster configuration include:
Identical instance configuration
The instances are meant to serve the same workload or application. Their configuration guarantees that they deliver the same exact reply to the same request. Some configuration properties may be identical and others may be instance-specific, such as local host name information.
Managed collectively
Changes made to one system will usually need to be propagated to the other systems in an active-active configuration.
Operate independently
In order to provide maximum availability, the loss of one Oracle Application Server instance in an active-active configuration should not affect the ability of the other instances to continue to serve requests.
The advantages of an OracleAS Cluster configuration include:
Increased availability
An active-active configuration is a redundant configuration. Loss of one instance can be tolerated because other instance 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. If configured correctly, new instances can also be added as the demand of the application grows.
In general, the term OracleAS 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 Cluster (type) to characterize the cluster solution. For example:
two or more J2EE instances are known as OracleAS Cluster (J2EE)
two or more OracleAS Portal instances are known as OracleAS Cluster (Portal)
two or more Oracle Identity Management instances are known as OracleAS Cluster (Identity Management)
For details on OracleAS Cluster (Identity Management), see Chapter 12, "Installing in High Availability Environments: OracleAS Cluster (Identity Management)".
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 13, "Installing in High Availability Environments: OracleAS Disaster Recovery".
Table 10-1 summarizes the differences among the high availability configurations.
Table 10-1 Differences Among the High Availability Configurations
|
OracleAS Cold Failover Cluster
|
OracleAS Cluster
|
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 |
No |
Shared storage |
Yes |
No |
No |
For all high availability configurations, you install the components in the following order:
OracleAS Metadata Repository
Oracle Identity Management components
If you are distributing the Oracle Identity Management components, you install them in the following order:
Oracle Internet Directory and Oracle Directory Integration and Provisioning
OracleAS Single Sign-On and Oracle Delegated Administration Services
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.
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 4, "Requirements", plus requirements specific to the high availability configuration that you plan to use. |
The common requirements are:
Section 10.3.2, "Check That Groups Are Defined Identically on All Nodes"
Section 10.3.4, "Check for Previous Oracle Installations on All Nodes"
You need at least two nodes in a high availability configuration. If a node fails for any reason, the second node takes over.
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 4.7, "Operating System Groups" for details.
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 4.7, "Operating System Groups" for details.
Has write privileges on remote directories.
Check that all the nodes where you want to install Oracle Application Server in a high availability configuration do not have existing oraInventory directories.
You need to do this because you want the installer to prompt you to enter a location for the oraInventory directory. The location of the existing oraInventory directory might not be ideal for the Oracle Application Server instance that you are about to install. For example, in OracleAS Cold Failover Cluster, you want the oraInventory directory to be on the shared storage. If the installer finds an existing oraInventory directory, it will automatically use it and will not prompt you to enter a location.
To check if a node contains an oraInventory directory that could be detected by the installer:
On each node, check for the /var/opt/oracle/oraInst.loc
file.
If a node does not contain the file, then it does not have an oraInventory directory that will be used by the installer. You can check the next node.
For nodes that contain the oraInst.loc
file, rename the directory to something else so that the installer does not see it. The installer then prompts you to enter a location for the oraInventory directory.
The following example renames the oracle
directory to oracle.orig
(you need to be root to do this):
prompt> su Password: root_password # cd /var/opt # mv oracle oracle.orig
When you run the installer to install Oracle Application Server, the installer creates a new /var/opt/oracle
directory and new files in it. You might need both oracle
and oracle.orig
directories. Do not delete either one or rename one over the other.
The installer uses the /var/opt/oracle
directory and its files. Be sure that the right oracle
directory is in place before running the installer (for example, if you are deinstalling or expanding a product).