| Toolbox: Oracle 9i (9.0.1.4.0) Database Server with RAC option; Red Hat Linux 7.1. Topics include Oracle database installation, Linux kernel versions, and kernel settings. You should have a good knowledge of Oracle database administration and Linux (or UNIX) operating system management, but whether you're an established DBA and UNIX administrator or merely a DBA and Linux "newbie," the basic advice and techniques here will save you lots of time and aggravation. |
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:
- Flexible and effortless scalability, so that adding nodes to the database is easy and manual intervention is not required to re-partition data when processor nodes are added.
- A high availability solution that masks node and component failures from end-users.
- A single management interface for DBAs to perform installation, configuration, backup, upgrade, and monitoring functions once. Oracle automatically distributes the management functions to the appropriate nodes. This means the DBA manages one virtual server.
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.
- Connect and login to http://www.metalink.oracle.com
- Click on the "Certify and Availability" button on the menu frame
- Click on View Certifications by Product hyperlink
- Choose "Real Application Clusters"
- Choose the correct platform.
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://www.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 to:
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.
No comments:
Post a Comment