Internal or local storage is still an important attribute of many server designs, and protecting local storage...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
should be near the top of any systems administrator's to-do list. Although it is possible to create one large volume from all of the disks, it is more common to segment the available storage into RAID groups to form multiple, independent RAID arrays from the available storage. Some servers allow for the formation of RAID groups at the BIOS level, but you can also use third-party tools, such as IBM’s MegaRAID Storage Manager, Symantec Corp.’s FileStore or EMC Corp.’s CLARiiON. This tip describes the process and addresses best practices for setting up RAID groups on servers with local storage.
Setting up RAID groups
The process of actually creating a RAID group is usually simple, though the exact process varies from one product to another. Let’s look at Symantec’s FileStore as an for example. You must begin by navigating through the console tree to All Devices | Clustered NAS Storage | Storage Resources | RAID Groups. Next, click the Create button to begin creating the new RAID group. Now, choose the types of disks that you want to use (Fibre Channel, SATA, etc.), and then choose the type of RAID group that you want to create (RAID 10, RAID 50, etc.). Finally, assign a name to the RAID group that you are creating, choose the disks that you want to include in the RAID group and click OK.
RAID group limitations
In spite of the simplicity involved in setting up RAID groups, it is important to adhere to some best practices. The first bit of advice when setting up RAID groups is to understand any system storage limitations. Administrators could be limited in the number of logical unit numbers (LUNs) that they can bind to a single RAID group. For example, a CLARiiON will only allow a system to bind 32 LUNs to each RAID group. As such, administrators may have to base their RAID group planning around the number of LUNs that their server must accommodate.
Of course, this is only an example. Each product has its own limitations. For instance, some products may prevent you from mixing and matching drive sizes or speeds.
You may also discover that there is a practical limitation associated with software-based RAID solutions, because such products consume CPU cycles when performing tasks, such as stripping, mirroring and parity checks. Therefore, you might have to limit the number of RAID groups that you use based not on the software’s limitations, but rather on the effect that the software has on your server’s performance.
Avoid making changes
As you decide how you want to structure your RAID groups, keep in mind that setting up RAID groups tends to be a semi-permanent operation. Although it is possible to restructure your RAID groups, doing so almost always means that any data that exists within the RAID group will be deleted as a part of the operation. The exception to this is that most enterprise-class RAID controller cards offer an online capacity expansion feature that allows for the addition of disks to a RAID group, thereby increasing the RAID group’s capacity through a non-destructive operation. Regardless of capacity expansion features, it's critical to protect the data on any RAID group before attempting any kind of resizing process.
Use equal-sized drives
As you begin setting up RAID groups, it is important to use hard drives of equal sizes within each RAID group whenever possible. A couple of years ago, I had an older server with a RAID 5 array consisting of four 300 GB hard drives. One of the drives failed, and I was unable to find another 300 GB drive. Since I was under pressure to get the drive replaced quickly, I used a 750 GB drive (which was the only size that I could buy locally). The replacement drive worked, but over half of the drive’s capacity was wasted. To make matters worse, the array did not perform nearly as well with mismatched drives because of differences in the mismatched drives’ formatting.
Know the pros and cons of RAID types
Finally, newer controller cards support many different RAID levels ranging from longtime standards to truly exotic. Each RAID level has advantages and disadvantages, so it is important to know the pros and cons of the various RAID levels before you implement them.
RAID 6 or dual parity, for example, has the benefit of being able to protect against two simultaneous disk failures. However, the disadvantages usually outweigh the benefits. For example, if the controller card fails, then the entire array's contents will be lost, even if no disks have failed. Furthermore, RAID 6 is computationally intensive because parity must be calculated for two separate drives. This additional overhead can impact write speeds unless the RAID controller contains a coprocessor that is specifically dedicated to offloading parity computations. In any case, rebuilding a RAID 6 array after a disk failure can take days to complete.
In case you are wondering, many servers do include redundant disk controllers, but a disk can only be connected to a single controller. Therefore, the redundancy is only beneficial if you are using a mirrored array such as RAID 10.
RAID 10 is universally supported, has no single point of failure (assuming that you are using redundant disk controllers) and a RAID 10 array can be rebuilt quickly. However, 50% of the array’s total storage capacity is lost to data mirroring, which can be a major issue for anyone who needs high capacity storage.
Of course, these are just examples of some of the pros and cons associated with two types of RAID groups. There are many other RAID levels that you might also wish to consider when setting up RAID groups.
About the author: Brien Posey is a seven time Microsoft MVP with two decades of IT experience. During that time he has published many thousands of articles and has written or contributed to dozens of IT books. Prior to becoming a freelance writer, Posey served as CIO for a national chain of hospitals and healthcare facilities. He has also worked as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.