Chapter 6. Managing Software RAIDs with EVMS | ||||
|---|---|---|---|---|
 | 5.17. What’s Next | 6.2. Creating and Configuring a Software RAID |  | |
Chapter 6. Managing Software RAIDs with EVMS | ||||
|---|---|---|---|---|
| 5.17. What’s Next | 6.2. Creating and Configuring a Software RAID | | |
This section describes how to create and manage software RAIDs with the Enterprise Volume Management System (EVMS). EVMS supports only RAIDs 0, 1, 4, and 5 at this time. For RAID 6 and 10 solutions, see Chapter 7, Managing Software RAIDs 6 and 10 with mdadm.
A RAID combines multiple devices into a multi-disk array to provide resiliency in the storage device and to improve storage capacity and I/O performance. If a disk fails, some RAID levels keep data available in a degraded mode until the failed disk can be replaced and its content reconstructed.
A software RAID provides the same high availability that you find in a hardware RAID. The key operational differences are described in the following table:
Table 6.1. Comparison of Software RAIDs and Hardware RAIDs
The following table describes the advantages and disadvantages of the RAID levels supported by EVMS. The description assumes that the component devices reside on different disks and that each disk has its own dedicated I/O capability.
![[Important]](admon/important.png) | Important |
|---|---|
For information about creating complex or nested RAID devices with mdadm, see Chapter 7, Managing Software RAIDs 6 and 10 with mdadm. | |
Table 6.2. RAID Levels Supported by EVMS
The following table compares the read and write performance for RAID devices.
Table 6.3. Read and Write Performance for RAIDs
The following table compares the disk fault tolerance for RAID devices.
Table 6.4. Fault Tolerance for RAIDs
In EVMS management tools, the following RAID configuration options are provided:
Table 6.5. Configuration Options in EVMS
For efficient use of space and performance, the disks you use to create the RAID should have the same storage capacity. Typically, if component devices are not of identical storage capacity, then each member of the RAID uses only an amount of space equal to the capacity of the smallest member disk.
Version 2.3 and later of mdadm supports component devices up to 4 TB in size each. Earlier versions support component devices up to 2 TB in size.
| Important |
|---|---|
If you have a local disk, external disk arrays, or SAN devices that are larger than the supported device size, use a third-party disk partitioner to carve the devices into smaller logical devices. | |
You can combine up to 28 component devices to create the RAID array. The md RAID device you create can be up to the maximum device size supported by the file system you plan to use. For information about file system limits for SUSE® Linux Enterprise Server 10, see “Large File System Support” in the SUSE Linux Enterprise Server 10 Installation and Administration Guide..
In general, each storage object included in the RAID should be from a different physical disk to maximize I/O performance and to achieve disk fault tolerance where supported by the RAID level you use. In addition, they should be of the same type (disks, segments, or regions).
Using component devices of differing speeds might introduce a bottleneck during periods of demanding I/O. The best performance can be achieved by using the same brand and models of disks and controllers in your hardware solution. If they are different, you should try to match disks and controllers with similar technologies, performance, and capacity. Use a low number of drives on each controller to maximize throughput.
| Important |
|---|---|
As with any hardware solution, using the same brand and model introduces the risk of concurrent failures over the life of the product, so plan maintenance accordingly. | |
The following table provides recommendations for the minimum and maximum number of storage objects to use when creating a software RAID:
Connection fault tolerance can be achieved by having multiple connection paths to each storage object in the RAID. For more information about configuring multipath I/O support before configuring a software RAID, see Chapter 5, Managing Multipath I/O for Devices.
RAID 5 uses an algorithm to determine the layout of stripes and parity. The following table describes the algorithms.
Table 6.7. RAID 5 Algorithms
For information about the layout of stripes and parity with each of these algorithms, see Linux RAID-5 Algorithms.
The Multi-Disk (MD) plug-in supports creating software RAIDs 0 (striping), 1 (mirror), 4 (striping with dedicated parity), and 5 (striping with distributed parity). The MD plug-in to EVMS allows you to manage all of these MD features as “regions” with the Regions Manager.
The Device Mapper plug-in supports the following features in the EVMS MD Region Manager:
Multipath I/O: Connection fault tolerance and load balancing for connections between the server and disks where multiple paths are available. If you plan to use multipathing, you should configure MPIO for the devices that you plan to use in the RAID before configuring the RAID itself. For information, see Chapter 5, Managing Multipath I/O for Devices.
| Important |
|---|---|
The EVMS interface manages multipathing under the MD Region Manager, which originally supported the md multipath functions. It uses the legacy md terminology in the interface and in naming of device nodes, but implements the storage objects with Device Mapper. | |
Linear RAID: A linear concatenation of discontinuous areas of free space from the same or multiple storage devices. Areas can be of different sizes.
Snapshots: Snapshots of a file system at a particular point in time, even while the system is active, thereby allowing a consistent backup.
The Device Mapper driver is not started by default in the rescue system.
