2.5 High Availability | Oracle Application Server 10g Essentials

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 10 g 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 10 g , 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_Certification.html.

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.