Oracle Application Server 10g Essentials [Electronic resources] نسخه متنی

2.5 High Availability

The availability of an application server
can be measured by comparing the actual amount of time it is
operational against the total time it could possibly be available.
Highly available systems may need to operate 100% of the time. To
accomplish that level of availability, you must address every
possible single point of failure. In addition to hardware and
software failures, you must have a way to continue operations while
both the hardware and software are being upgraded or replaced.

Oracle Application Server solves these high-availability problems
with clusters and with two different
failover solutions for the OracleAS Infrastructure.

2.5.1 Oracle Application Server Clusters

We introduced the concept of clusters earlier in this chapter.
Although both a farm and a cluster are made up of
multiple instances of Oracle Application Server components, a cluster
is a more integrated grouping than a farm.

In a cluster, the individual instances of a component are aware of
each other, and they cooperate to provide service. The OPMN server
keeps the members of a cluster informed as to the status of other
members in that cluster, so if one member fails, the others pick up
its load. The members of a cluster are designed to be
interchangeable, providing a higher level of availability than an
individual instance or a group of instances in a farm.

You can create clusters of OracleAS Web Cache instances or Oracle
Application Servers. As mentioned earlier, a cluster requires some
type of load balancer in front of the cluster to distribute the load.
The redundant nature of an individual instance within a cluster makes
clustering a way to provide a high-availability solution.

Oracle Application Server can also run on
hardware
clusters. These clusters provide an underlying redundancy and
transparency for anything running on them, including Oracle
Application Server.

2.5.2 Infrastructure Failover

Oracle Application Server clusters deliver high
availability with their own software. However, these clusters
don't provide high availability for the OracleAS
Infrastructure. Because all Oracle Application Server components need
to access the infrastructure and because the availability of an
entire system is dependent on every part of the system, this
deficiency can imperil the availability of your application server.

To address this risk, you can implement Oracle Application Server
10g with either of two types of failover
solutions:

Oracle Application Server Cold Failover Clusters

This approach uses hardware clustering to provide some measure of
availability protection.

Oracle Application Server Active Failover Clusters

This approach provides a higher level of availability and combines it
with increased scalability for your infrastructure.

2.5.2.1 OracleAS Cold Failover Clusters

The OPMN server manages most Oracle Application Server components and
services, and this server can automatically restart any failed
processes. This capability protects against the failure of individual
components of Oracle Application Server. However, larger problems,
such as server failure, are beyond the scope of OPMN. Thus, Oracle
Application Server provides an availability solution, OracleAS Cold
Failover Clusters, that guards against these larger-scale failures.

OracleAS Cold Failover Clusters are built on capabilities inherent in
a hardware cluster. A
hardware cluster facilitates the sharing of resources between nodes,
provides a health-monitoring heartbeat, and supports failover from
one node to another without impacting users. Hardware clusters
provide a "virtual IP" address,
which it can associate with either node in the cluster. Users
don't know which physical node is servicing requests
for the virtual IP address.

If you are familiar with database availability concepts, you
will recognize the term cold failover. With
Oracle Application Server, the term has the same meaning it does for
a database: one identical set of resources stands by, waiting for a
failure in the primary system. If that system fails, the cluster
starts to use the standby system. Figure 2-4 shows
the architecture of a typical OracleAS Cold Failover Clusters
implementation before a failure has occurred.

Figure 2-4. OracleAS Cold Failover Clusters prefailure

Because many Oracle Application Server components depend on the
infrastructure for continuous operation, OracleAS Cold Failover
Clusters are designed to protect the components of the OracleAS
Infrastructure. If an active node in an OracleAS Cold Failover
Cluster configuration fails, the IP address is switched to the
failover node, and the infrastructure processes are started on that
node. Once these processes are available, middle-tier components can
access the new infrastructure, as shown in Figure 2-5. Because the storage for both infrastructure
nodes is shared, there is no need to recreate or migrate the
information in the database.

Figure 2-5. OracleAS Cold Failover Clusters post-failure

You can have instances of other Oracle Application Server and
OracleAS Web Cache coexisting on either node in the OracleAS Cold
Failover Cluster. However, no failover for these instances is
supported. You can group the instances in their own cluster, but the
operation of these clusters is separate from the operation of the
OracleAS Cold Failover Cluster.

2.5.2.2 OracleAS Active Failover Clusters

Oracle Application Server
10g, in its initial release, provides limited
(i.e., beta-style) support for another type of failover solution:
Active Failover Clusters. OracleAS
Active Failover Clusters uses the same architecture as OracleAS Cold
Failover Clusters.

At the time of this writing, OracleAS Active Failover Clusters is still in limited release. By the time you read this book, OracleAS Active Failover Clusters is likely to be available for a number of platforms for Oracle Application Server. For up-to-date information on certified platforms, please see http://otn.oracle.com/products/ias/hi_av/10g_904_HA_Certificationl.

The big difference between OracleAS Active Failover Clusters and
OracleAS Cold Failover Clusters is that with OracleAS Active Failover
Clusters, you don't have to have one node in the
hardware cluster sitting around waiting for a failure. Both
infrastructure nodes can service infrastructure requests. Because
both nodes in an OracleAS Active Failover Cluster are servicing
requests, OracleAS Active Failover Clusters can provide some
scalability, in addition to the availability offered by both types of
failover clusters.

The architecture for an OracleAS Active Failover Cluster
configuration is shown in Figure 2-6.

Figure 2-6. OracleAS Active Failover Clusters architecture

The major differences between this configuration and a OracleAS
Cold Failover Cluster
configuration are the following:

An OracleAS Active Failover Cluster configuration uses a hardware
load balancer in front of the active infrastructure nodes.

The infrastructure uses

Real Application Clusters (RAC) for its
database.

Both nodes have the same infrastructure components running at the
same time, and the load is split between the infrastructure nodes. If
one node fails, the failover is much faster and more transparent than
it is for OracleAS Cold Failover Clusters.

OracleAS Active Failover Clusters use a RAC database to provide
scalability and availability for the OracleAS
Metadata Repository. RAC is
Oracle's clustered database solution. It runs on
a hardware cluster and allows any application to run against a
clustered database without modification. For more information on RAC,
please refer to the discussion in our companion database book
Oracle Essentials (O'Reilly).

In addition to using RAC for the OracleAS Metadata Repository,
OracleAS Active Failover Clusters have duplicate infrastructure
processes, such as those used for identity management, running on
each node in the cluster. All nodes in an OracleAS Active Failover
Cluster must have virtually identical configurations, down to the
pathnames for Oracle
HOME directories.