Optimizing RAID Controllers.

This article is the first in a two-part series.

RAID optimizes the availability, performance, and cost characteristics of storage subsystems to best meet a set of application requirements, but these attributes cannot be simultaneously configured for their individual optimal values. Tradeoffs are required to achieve the desired balance and selecting the appropriate RAID level and caching strategy are primary components of achieving the right balance.

Data Mapping

A RAID array is a set of disks presented to operating systems as logical volumes with varying capacity, availability, and performance characteristics. Disk arrays are constructed by:

* Grouping drives into RAID groups;

* Imposing one or multiple RAID levels on each RAID group;

* Partitioning each RAID group into logical volumes.

Essential RAID Concepts

RAID technology masks the characteristics of individual disk drives and transparently presents logical disks to the operating system, i.e., the OS sees logical disks on its I/O channels as if they were physical disk drives. The RAID firmware maps logical disk block addresses used by applications, file, and database systems to physical disk block addresses using algorithms that implement alternative data organizations called RAID levels. RAID technology protects data from disk failures by storing redundant information; a mirrored array (Fig 1) stores identical copies of data on different disks and a parity array (Fig 2) distributes data across a set of disks to balance the I/O load for improved performance. In a parity array, a corresponding parity check data is computed, stored, and used to reconstruct data for each data stripe in the event of disk failure. RAID technology:

* Maps physical disk to logical disks.

* Maps logical blocks to physical blocks.

* Protects stored data.

RAID Levels

Researchers at the University of California at Berkeley initially defined six RAID levels. While not technically a RAID level since it does not include data redundancy, "RAID 0," in which logical blocks are striped across disks in an array with each block mapped to a single disk, is commonly referred to as a RAID level. In "RAID 1," logical blocks are replicated and stored on two different disks to achieve data redundancy. Other RAID levels include:

* RAID 2:

Logical blocks are distributed across "data disks" and protected by Hamming code. RAID 2 was never deployed on commercial systems.

* RAID 3:

Each logical disk block is distributed across all data disks in an array and parity check data is stored on a dedicated "parity disk." RAID 3 provides excellent bandwidth for applications that transfer complete data stripes in each I/O operation and has been delivered on specialized systems such as video server.

* RAID 4:

Logical blocks are striped across "data disks" in an array with each block mapped to a single disk and independently accessible (an important performance characteristic for applications such as OLTP). Parity check data is stored on a dedicated parity disk in the array. Since RAID 5 is essentially a performance-enhanced variant of this RAID level, RAID 4 has been displaced in market.

* RAID 5:

Logical blocks are striped across all disks in an array with each block mapped to a single disk. Parity check blocks are distributed across all disks to prevent the parity disk in RAID 4 from becoming an I/O bottleneck.

Other RAID levels have been defined as combinations of the original RAID levels to further enhance data accessibility or performance. For example, Mylex combines RAID 1 and 5 with RAID 0 to form advanced RAID levels called RAID 10 and 50.

RAID Level Tradeoffs

Aside from JBOD (Just a Bunch Of Disks) configurations, in which RAID technology is not applied, almost all data is stored using RAID levels 0, 1, 5, or an advanced RAID level. The Table summarizes the availability, performance, capacity, and cost attributes of these levels.

Parity Check Data

With the exception of RAID 1, the other RAID levels provide I/O load balancing by striping data across disks. The I/O load is distributed or balanced across disk resources preventing an otherwise heavily loaded disk from bottlenecking system performance. RAID 5 uses parity check data to make a disk pool fault tolerant. Parity check data is generated by calculating the "exclusive OR" of the contents of the data in a stripe. If a disk fails, the contents of the failed disk can be regenerated by calculating the exclusive OR of the surviving disks, including the disk with the parity check data. Write performance in a parity array is reduced by the "read-modify-write penalty." Before a write can be completed to disk, the contents of the disk blocks that will be modified (including the parity blocks) are read, new parity check data is calculated and then the blocks are updated.

XORing data is compute intensive that can be accelerated with a hardware assist. RAID controllers are available with XOR ASICs that compute the parity check data on the fly. These controllers can sustain RAID 5 write performance well in excess of 100MB/sec and bandwidth-intensive applications using RAID 5 generally execute at least twice as fast if the RAID controller is capable of on-the-fly parity generation.

Caching RAID Controllers

In heavily loaded system environments, a RAID controller is a better solution than RAID software executing on the server. With dedicated processing resources, RAID controllers deliver superior performance without adding server overhead. RAID controllers are available in two flavors:

* Internal RAID controllers packaged with the server.

* External RAID controllers packaged in a disk enclosure.

Internal controllers are lower cost; external controllers can be shared in a SAN topology. Controller-based data caching can double or triple I/O performance, depending on application access patterns, and is the key hardware parameter for optimizing performance and data availability.

Read Caching

Read caching is based on the locality of reference principle--applications are more likely to reference data that is stored in close proximity to previously referenced data than they are to reference data stored on distant areas of the disk. In other words, the next block an application will probably want to read has a high probability of being stored in the same data stripe as the last block read. While read caching algorithms vary in sophistication, the basic notion is the same--with each read operation, grab the requested block and the rest of the blocks in the stripe, hence the term "read-ahead" caching. The requested block is returned to the application and the rest are stored in the read cache. If a subsequent read I/O wants a block stored in the cache, a cache hit and then a long trip out to the disk pool is avoided.

The second part of this article will appear in the March issue of CTR.

Kevin Smith is the senior director of business management and marketing for external products at Mylex Corporation (Boulder, CO).

       Disk failure             I/O               Usable
         Tolerant           Performance          Capacity
RAID 0      No                Highest            N [*] C
RAID 1     Yes      Slower than RAID 0 for both (N [*]C)/2
                         reads and writes
RAID 5     Yes       Same as RAID 0 for reads;  (N-1) [*]C
                      Much slower for writers
              Cost
RAID 0       Lowest
RAID 1    Twice RAID 0
RAID 5 Higher than RAID 0;
        lower than RAID 1
(*.)"N" equals the number of disks and "C" equals disk
capacity