Designing Equipment for Real Application Clusters

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.

The most important design feature of the equipment used in HA RAC clusters is a layout that eliminates any single point of failure. The diagram in Figure 12.1 provides an opportunity to look at some design features and their impact on the potential success of HA RAC clusters in the environment.

Figure 12.1: Non-Redundant Configuration

Figure 12.1 shows a typical RAC configuration. However, this configuration, other than the RAC cluster itself, has no redundancy and many single points of failure. The single points of failure are:

* Firewall

* Application Server

* Fabric Switch

* SAN array

A failure of any one of these single points will result in system unavailability, no matter how well the RAC cluster itself is laid out, designed and tuned.

It is critical to ensure that there is no single point of failure in a high availability configuration. Figure 12.2 illustrates exactly what eliminating single points of failure means.

Figure 12.2: Example of a Redundant RAC Configuration

The system shown in Figure 12.2 has had the following redundancies added:

* A second firewall with an independent connection to the web.

* A second application server.

* A second fabric switch with redundant pathways.

* A second SAN array.

* A set of load balancers.

* A geo-remote RAC Guard configuration.

Now, the single points of failure in Figure 12.1 have been eliminated. A third server has also been added, as well as a SAN array in a geographically remote location. This third server and SAN ensure that not even a disaster at the primary location will bring the application down.  The application server and firewall for this third server are not shown and may not be required if the firewalls and application servers are in a different location from the database servers.

For highly active websites, the application servers may include web caches as well as OC4J servers. The servers that run OC4J are the building blocks of the application tier and provide the application service to the clients.  OC4J is J2EE compliant and includes:

* A JSP translator.

* A servlet container.

* An EJB container.

* Several other Java specifications. 

OC4J clustering connects servers that run individual containers so that they act in tandem. This provides more availability and scalability than a single Oracle instance can provide.  Additional OC4J instances can be added or removed transparently to increase scalability or do system maintenance.  The OC4J cluster at the primary site has identical hardware, OS, application server software, and application-specific software to the secondary site.  They are configured similarly in all respects.

By having Oracle10gAS Web Cache Cluster and load balancers in front of the OC4J clusters, performance, scalability, and availability of a web site are increased. Web Cache eliminates the need to repeatedly process requests on the application web server by storing frequently accessed URLs in memory.  Multiple instances of Web Cache can be configured to run as members of a cache cluster. This provides:

* Higher scalability of the website by allowing more content to be cached and more client connections.

* Higher availability by detecting failures and failing over of caches. 

Because each OC4J instance and cache cluster member is redundant on multiple sets of machines, problems and outages within a site are transparent to the client.  The OPMN monitoring infrastructure ensures nearly uninterrupted availability of an application?s services by automatically detecting and restarting failed components of the application tier or the Web Cache.

In Figure 12.2, the use of a RAC server platform capable of CPU partitioning is shown. This means that multiple CPUs, in systems like the E6800 from SUN, can be separated into virtual servers that act like independent servers. This partitions malfunctioning CPUs or memory, which is on the CPU cards in the E6800, and the rest of the server continues to work.

In addition, the SAN, perhaps a SUN T3, Hitachi or EMC Clariion or Symmetrix, can be configured using redundant disk configurations such as RAID-1, RAID5, or a combination, sometimes called plaid, of RAID1 and RAID5 that virtually eliminate downtime from the loss of a single disk.  It should be stressed that application performance can suffer horribly from a disk failure during either a disk rebuild with installed spares or a rebuild of the information using parity information from the other disks in a RAID5 set.