Revision: $Revision: 1.3 $ ($Date: 2007-01-10 15:36:27 $)
This objective has a weight of 6 points and contains the following objectives:
Candidates should be able to configure and implement software RAID. This objective includes using and configuring RAID 0, 1 and 5.
Candidates should be able to configure kernel options to support various drives. This objective includes software tools to view and modify hard disk settings.
Candidates should be able to create and remove logical volumes and physical volumes. This objective includes snapshots, and resizing logical volumes.
Revision: $Revision: 1.14 $ ($Date: 2008/06/12 12:30:38 $)
Candidates should be able to configure and implement software RAID. This objective includes using and configuring RAID 0, 1, and 5.
Key files, terms and utilities include:
| mdadm |
mdadm.conf |
| fdisk |
/proc/mdstat |
Resources: LinuxRef01;
Robbins01;
Bar00;
manpages for mdadm and mdadm.conf.
RAID stands for “Redundant Array of Inexpensive Disks” [1].
The basic idea behind RAID is to combine multiple small, inexpensive disk drives into an array which yields performance exceeding that of one large and expensive drive. This array of drives will appear to the computer as a single logical storage unit or drive.
Some of the concepts used in this chapter are important factors in deciding which level of RAID to use in a particular situation. Parity is a concept used to add redundancy to storage. A parity bit is a binary digit which is added to ensure that the number of bits with value of one in a given set of bits is always even or odd. By using part of the capacity of the RAID for storing parity bits in a clever way, single disk failures can happen without data-loss since the missing bit can be recalculated using the parity bit. I/O transactions are movements of data from or to a RAID device or it's members. Each I/O transaction consists of one or more blocks of data. A single disc can handle a maximum random number of transactions per second, since the mechanism has a seek time before data can be read or written. Depending on the configuration of the RAID, a single I/O transaction to the RAID can trigger multiple I/O transactions to it's members. This affects the performance of the RAID device in terms of maximum number of I/O transactions and data transfer rate. Data transfer rate is the amount of data a single disc or RAID device can handle per second. This value usually varies for read and write actions, random or sequential access etc.
RAID is a method by which information is spread across several disks, using techniques such as disk striping (RAID Level 0), disk mirroring (RAID level 1), and striping with distributed parity (RAID Level 5), to achieve redundancy, lower latency and/or higher bandwidth for reading and/or writing to disk, and maximize recoverability from hard-disk crashes.
The underlying concept in RAID is that data may be distributed across each drive in the array in a consistent manner. To do this, the data must first be broken into consistently-sized chunks (often 32K or 64K in size, although different sizes can be used). Each chunk is then written to each drive in turn. When the data is to be read, the process is reversed, giving the illusion that multiple drives are actually one large drive. Primary reasons to use RAID include:
There are a number of different ways to configure a RAID subsystem -- some maximize performance, others maximize availability, while others provide a mixture of both. For the LPIC-2 exam the following are relevant:
Level 0. RAID level 0, often called “striping”, is a performance-oriented striped data mapping technique. This means the data being written to the array is broken down into strips and written across the member disks of the array. This allows high I/O performance at low inherent cost but provides no redundancy. Storage capacity of the array is equal to the sum of the capacity of the member disks.
Level 1. RAID level 1, or “mirroring”, has been used longer than any other form of RAID. Level 1 provides redundancy by writing identical data to each member disk of the array, leaving a mirrored copy on each disk. Mirroring remains popular due to its simplicity and high level of data availability. Level 1 operates with two or more disks that may use parallel access for high data-transfer rates when reading, but more commonly operate independently to provide high I/O transaction rates. Level 1 provides very good data reliability and improves performance for read-intensive applications but at a relatively high cost. Array capacity is equal to the capacity of the smallest member disk.
Level 4. RAID level 4 uses parity concentrated on a single disk drive to protect data. It's better suited to transaction I/O rather than large file transfers. Because the dedicated parity disk represents an inherent bottleneck, level 4 is seldom used without accompanying technologies such as write-back caching. Array capacity is equal to the capacity of member disks, minus the capacity of one member disk.
Level 5. The most common type of RAID is level 5 RAID. By distributing parity across some or all of the member disk drives of an array, RAID level 5 eliminates the write bottleneck inherent in level 4. The only bottleneck is the parity calculation process. With modern CPUs and software RAID, that isn't a very big bottleneck. As with level 4, the result is asymmetrical performance, with reads substantially outperforming writes. Level 5 is often used with write-back caching to reduce the asymmetry. Array capacity is equal to the capacity of member disks, minus capacity of one member disk.
Linear RAID. Linear RAID is a simple grouping of drives to create a larger virtual drive. In linear RAID, the chunks are allocated sequentially from one member drive, going to the next drive only when the first is completely filled. This grouping provides no performance benefit for single process applications, as it is unlikely that any single I/O operations will be split between member drives. This changes when multiple processes access the same array and access becomes more random. Linear RAID also offers no redundancy, and in fact decreases reliability -- if any one member drive fails, the entire array cannot be used. The capacity is the total of all member disks.
RAID can be implemented either in hardware or in software; both scenarios are explained below.
The hardware-based system manages the RAID subsystem independently from the host and presents to the host only a single disk per RAID array.
A typical hardware RAID device might connect to a SCSI controller and present the RAID arrays as a single SCSI drive. An external RAID system moves all RAID handling intelligence into a controller located in the external disk subsystem.
RAID controllers also come in the form of cards that act like a SCSI controller to the operating system, but handle all of the actual drive communications themselves. In these cases, you plug the drives into the RAID controller just as you would a SCSI controller, but then you add them to the RAID controller's configuration, and the operating system never knows the difference.
Software RAID implements the various RAID levels in the kernel disk (block device) code. It also offers the cheapest possible solution: Expensive disk controller cards or hot-swap chassis are not required, and software RAID works with cheaper IDE disks as well as SCSI disks. With today's fast CPUs, software RAID performance can excel against hardware RAID.
Software RAID allows you to dramatically increase Linux disk IO performance and reliability without buying expensive hardware RAID controllers or enclosures. The MD driver in the Linux kernel is an example of a RAID solution that is completely hardware independent. The performance of a software-based array is dependent on the server CPU performance and load. Also, the implementation and setup of the software RAID can significantly influence performance.
The concept behind Software RAID is simple -- it allows you to combine
two (three for RAID5) or more block devices (usually disk partitions) into a single RAID
device. So if you have three empty partitions (for example: hda3, hdb3, and hdc3), using Software RAID, you can combine these partitions and address them as a single RAID device, /dev/md0.
/dev/md0 can then be formatted to contain a
filesystem and used like any other partition.
Configuring software RAID using mdadm (Multiple Devices Admin) requires only that the md driver be configured into the kernel, or loaded as a kernel module. The optional mdadm.conf file may be used to direct mdadm in the simplification of common tasks, such as defining multiple arrays, and defining the devices used by them. The mdadm.conf has a number of possible options, described later in this document, but generally, the file details arrays, and devices. It should be noted that although not required, the mdadm.conf greatly reduces the burden on administrators to "remember" the desired array cofiguration when launching.
The mdadm is used (as its acronym suggests) to configure and manage multiple devices. Multiple is key here. In order for RAID to provide any kind of redundancy to logical disks, there must obviously be at the very least two physical block devices in the array to establish redundancy, ergo protection. Since mdadm manages multiple devices, its application is not limited solely to RAID implementations, but may be also be used to establish multi pathing.
mdadm has a number of modes, listed below
| Assemble |
| Build |
| Create |
| Grow |
| Misc |
Linux: /etc/mdadm.comf and
/etc/rc.d/rc.local (or equivalent). The Linux
kernel provides a special driver, /dev/md0, to
access separate disk partitions as a logical RAID unit. These partitions
under RAID do not actually need to be different
disks, but in order to eliminate risks it is better to use different
disks. mdadm may also be used to establish multipathing, and also over filesystem devices (since multipathing is established at the block level), however as with establishing RAID over multiple filesystems on the same physical disk, ,multipathing on the same physical disk proivides only the vague illusion of redundancy, and its use should probably be restricted to test, or pure curiosity.
Follow these steps to set up software RAID in Linux:
/proc/mdstat
Each of these steps is now described in detail:
Initialize partitions to be used in the RAID setup. Create partitions using any disk partitioning tool.
Configure the driver.
A driver file for each independant array will be automatically created when mdadm creates the array, and will follow the convention /dev/md[n] for each increment. It may also be manually created using mknod and building a block device file, with a major number 9 (md device driver found in /proc/devices).
Initialize RAID drive. Here's an example of the sequence of commands needed to create and format a RAID drive (the section called “Configuring RAID (using mdadm)”):
/proc/mdstatRAID/dev/md0mkfs.ext3/dev/md0/etc/mdadm.confmdadmdiffmdadm/etc/mdadm.confRAID/etc/fstabmountmount -a/etc/mdadm.conf using the mdadm command./etc/fstabAutomate RAID activation after reboot.
Run mdadm --assemble in one of the startup files (e.g.
/etc/rc.d/rc.sysinit or
/etc/init.d/rcS)
When called with the "-s" option (scan) to mdadm --assemble, instructs mdadm to use the /etc/mdadm.conf if it exists, and otherwise to fallback to /proc/mdstat for missing information.
A typical system startup entry could be for example, mdadm --assemble -s.
mount the filesystem on the RAID drive.
Edit /etc/fstab to automatically mount the filesystem on the RAID drive. The entry in /etc/fstab is identical to normal block devices containing file systems.
Manual RAID activation and mounting. Run mdadm --assemble for each RAID block device you want to start manually. After starting the RAID device you can mount any filesystem present on the device using mount with the appropriate options.