FireWire Real Application Cluster
January 21, 2003Brian Carr and William Garrett
Combine RAC, Linux and FireWire disk for low-cost development environment.
With the demands of a 24/7 marketplace, a highly available and scalable database is getting increasingly more important. In the past, you had to choose from one of two options in a cluster. High availability clusters were used to protect your database from hardware failure. Load balanced clusters with many nodes were used to support a much larger volume of traffic than single multi-processor implementations. Redundant components such as additional nodes, multiple interconnects, and arrays of disks helped provide high availability. Such redundant hardware architectures avoid single points-of-failure and provide exceptional fault resilience. RAC takes the cluster architecture even further, providing improved fault resilience and incremental system growth by offering connection failover and load balancing in the same cluster. In the event of a system failure, RAC ensures your database will still be available. In the event of a large spike in traffic, RAC can distribute the load over many nodes. Not only does RAC make good sense from a data availability and performance point of view, but with large SMP servers going for a premium price a pair of 2 processor servers can be half the cost of a single 4 processor server. RAC gives you the availability and scalability that enterprises demand.
RAC provides the following key benefits to e-business application deployments:
An alternative to using a Storage Area Network (SAN) or Network Attached Storage (NAS) is an external FireWire hard drive enclosure. This allows a low cost solution for testing your systems in a RAC environment prior to roll-out on your production RAC. With the use of commodity hardware you can build your development environment for a fraction of the cost.
This article looks at the process and some helpful tips to help you configure RAC for your development environment using a low cost alternative to a SAN, etc. After reading this article you should be able to setup your RAC environment more quickly and with fewer headaches.
Background / Overview
Our environment was set up to provide us with a low cost development environment to see how RAC fit into our application environment. We had two Compaq 700 MHz Pentium3 desktops, each with 512MB RAM and 10GB internal drives. We also had a spare switch to use for the interconnect. The only hardware we needed to purchase was an external FireWire enclosure, an IDE hard drive and two FireWire adapters. These additional hardware components came up to less than $400.
The focus of this article is using a FireWire drive with RAC on Linux. Therefore we will not rehash the installation of RAC on Linux since this is well documented in Note Id 184821.1 available on Metalink. You should also read the Oracle RAC installation documentation. We will focus on configuring Linux for FireWire support and how to test your RAC configuration for failover. By the end of this article you will understand the steps necessary to setup your own RAC environment for testing clustered applications. For those familiar with Linux and Oracle we estimate approximately 1-2 days worth of work to setup your development RAC environment.
1: Ensure your configuration is certified.
The setup we used was Red Hat 7.1 with RAC 9.0.1. If you're interested in using another distribution of Linux or 9iR2 be sure to check the certified configurations.
2: Obtain proper FireWire chipset and adapters.
Some FireWire chipsets are better than others at handling multiple logins. In order for RAC to work properly both nodes need to be logged in to the external FireWire hard drive simultaneously. We used an external hard drive enclosure that contained an Oxford Semiconductor OXFW911 sbp2 chipset, which supports up to four concurrent logins. The hardware savings is quite noticeable here, as two FireWire adapters and a shared disk can be bought for less than a single fiber channel controller (let alone the cost of a full SAN implementation).
3: Kernel configuration
In order for FireWire to be recognized by Linux it is recommended that you use a 2.4.19 updated kernel. We downloaded and unpacked the updated kernel from http://linux1394.otncast.otnxchange.oracle.com/
4: Driver modification
As specified in the sbp2.c file of the new kernel source, you'll want to change this file to allow support of multiple logins. To do this change the line
static int sbp2_exclusive_login=1
static int sbp2_exclusive_login=0
This modification is well documented in the file and will allow both nodes to have access to the external FireWire hard drive simultaneously. You will want to read through the rest of the source code in this file as there are several tuning parameters which can be set here.