This chapter provides conceptual information about Solaris Volume Manager RAID 5 volumes. For information about performing related tasks, see Chapter 14, RAID 5 Volumes (Tasks).
This chapter contains the following:
RAID level 5 is similar to striping, but with parity data distributed across all components (disk or logical volume). If a component fails, the data on the failed component can be rebuilt from the distributed data and parity information on the other components. In Solaris Volume Manager, a RAID 5 volume is a volume that supports RAID level 5.
A RAID 5 volume uses storage capacity equivalent to one component in the volume to store redundant information (parity) about user data stored on the remainder of the RAID 5 volume's components. That is, if you have three components, the equivalent of one will be used for the parity information. If you have five components, then the equivalent of one will be used for parity information. The parity is distributed across all components in the volume. Like a mirror, a RAID 5 volume increases data availability, but with a minimum of cost in terms of hardware and only a moderate penalty for write operations. However, you cannot use a RAID 5 volume for root (/), /usr, and swap, or for existing file systems.
Solaris Volume Manager automatically resynchronizes a RAID 5 volume when you replace an existing component. Solaris Volume Manager also resynchronizes RAID 5 volumes during rebooting if a system failure or panic took place.
Figure 13–1 shows a RAID 5 volume, d40.
The first three data chunks are written to Disks A through C. The next chunk that is written is a parity chunk, written to Drive D, which consists of an exclusive OR of the first three chunks of data. This pattern of writing data and parity chunks results in both data and parity being spread across all disks in the RAID 5 volume. Each drive can be read independently. The parity protects against a single disk failure. If each disk in this example were 2 Gbytes, the total capacity of d40 would be 6 Gbytes. (One drive's worth of space is allocated to parity.)
The following figure shows an example of an RAID 5 volume that initially consisted of four disks (components). A fifth disk has been dynamically concatenated to the volume to expand the RAID 5 volume.
The parity areas are allocated when the initial RAID 5 volume is created. One component's worth of space is allocated to parity, although the actual parity blocks are distributed across all of the original components to distribute I/O. When you concatenate additional components to the RAID, the additional space is devoted entirely to data. No new parity blocks are allocated. The data on the concatenated components is, however, included in the parity calculations, so it is protected against single device failures.
Concatenated RAID 5 volumes are not suited for long-term use. Use a concatenated RAID 5 volume until it is possible to reconfigure a larger RAID 5 volume and copy the data to the larger volume.
When you add a new component to a RAID 5 volume, Solaris Volume Manager “zeros” all the blocks in that component. This process ensures that the parity will protect the new data. As data is written to the additional space, Solaris Volume Manager includes it in the parity calculations.
When you work with RAID 5 volumes, consider the Requirements for RAID 5 Volumes and Guidelines for RAID 5 Volumes. Many striping guidelines also apply to RAID 5 volume configurations. See Requirements for Stripes and Concatenations.
A RAID 5 volume must consist of at least three components. The more components a RAID 5 volume contains, however, the longer read and write operations take when a component fails.
RAID 5 volumes cannot be striped, concatenated, or mirrored.
Do not create a RAID 5 volume from a component that contains an existing file system. Doing so will erase the data during the RAID 5 initialization process.
A RAID 5 volume (with no hot spares) can only handle a single component failure.
When you create RAID 5 volumes, use components across separate controllers, because controllers and associated cables tend to fail more often than disks.
Use components of the same size. Creating a RAID 5 volume with components of different sizes results in unused disk space.
Because of the complexity of parity calculations, volumes with greater than about 20 percent writes should probably not be RAID 5 volumes. If data redundancy on a write-heavy volume is needed, consider mirroring.
If the different components in the RAID 5 volume reside on different controllers and the accesses to the volume are primarily large sequential accesses, then setting the interlace value to 32 Kbytes might improve performance.
You can expand a RAID 5 volume by concatenating additional components to the volume. Concatenating a new component to an existing RAID 5 decreases the overall performance of the volume because the data on concatenations is sequential. Data is not striped across all components. The original components of the volume have data and parity striped across all components. This striping is lost for the concatenated component, although the data is still recoverable from errors because the parity is used during the component I/O. The resulting RAID 5 volume continues to handle a single component failure.
Concatenated components also differ in the sense that they do not have parity striped on any of the regions. Thus, the entire contents of the component are available for data.
Any performance enhancements for large or sequential writes are lost when components are concatenated.
You can create a RAID 5 volume without having to “zero out” the data blocks. To do so, do one of the following:
Use the metainit command with the -k option. The -k option recreates the RAID 5 volume without initializing it, and sets the disk blocks to the OK state. This option is potentially dangerous, as any errors that exist on disk blocks within the volume will cause unpredictable behavior from Solaris Volume Manager, including the possibility of fabricated data.
Initialize the device and restore data from tape. See the metainit(1M) man page for more information.
Solaris Volume Manager has the capability to replace and enable components within mirrors and RAID 5 volumes. The issues and requirements for doing so are the same for mirrors and RAID 5 volumes. For more information, see Overview of Replacing and Enabling Components in RAID 1 and RAID 5 Volumes.
RAID 5 volumes allow you to have redundant storage without the overhead of RAID 1 volumes, which require two times the total storage space to provide data redundancy. By setting up a RAID 5 volume, you can provide redundant storage of greater capacity than you could achieve with RAID 1 on the same set of disk components, and, with the help of hot spares (see Chapter 15, Hot Spare Pools (Overview) and specifically How Hot Spares Work), nearly the same level of safety. The drawbacks are increased write time and markedly impaired performance in the event of a component failure, but those tradeoffs might be insignificant for many situations. The following example, drawing on the sample system explained in Chapter 4, Configuring and Using Solaris Volume Manager (Scenario), describes how RAID 5 volumes can provide extra storage capacity.
Other scenarios for RAID 0 and RAID 1 volumes used 6 slices (c1t1d0, c1t2d0, c1t3d0, c2t1d0, c2t2d0, c2t3d0) on six disks, spread over two controllers, to provide 27 Gbytes of redundant storage. By using the same slices in a RAID 5 configuration, 45 Gbytes of storage is available, and the configuration can withstand a single component failure without data loss or access interruption. By adding hot spares to the configuration, the RAID 5 volume can withstand additional component failures. The most significant drawback to this approach is that a controller failure would result in data loss to this RAID 5 volume, while it would not with the RAID 1 volume described in Scenario—RAID 1 Volumes (Mirrors).