DATA STORAGE MANAGEMENT
Checklist: Seven RAID configuration essentials
Randy Grein
12.16.2004
Rating: --- (out of 5)
|
What you will learn from this tip: Seven quick tips for improving the performance and reliability of your RAID sets. Need a downloadable copy? Go here.
A full analysis of hardware, including RAID configurations, is beyond the scope of a short article, but the following tips should help:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Seven RAID configuration essentials |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|  |
|
|
|
|
|
1.Calculate on the worst case. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
A server that is fast enough most of the time generally isn't good enough, especially if the load is business-related. A drive rated at 50 MBps with sequential access can slow to as little as 1.5-2.5 MBps with small requests. And when things get busy, the system generally reverts to random access. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
2. Build in a hot spare! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unless you're at the console 24/7 and have a drive on the shelf, build in a hot spare. It may not get used for years, but you might need it next week. And it beats updating your resume. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
3. More drives are better. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Processors are fine, RAM is good, but when the load gets heavy, spindle count is king. Forget disk space, you need lots of spinning platters to satisfy your need for speed. Consider that network access is generally 100 MBps (gigabit Ethernet), the processor is capable of 1000 MBps -- and your hard drive is stuck anywhere between 2-50 MBps. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
4. RAID-5 for read access, not write. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RAID-5 is great for reads: it uses all disks and just one block. Write performance, however, stinks: it can be as little as n/4 times that of a single drive, where n is the number of drives in the array. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
5. Use RAID-10 for write access. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While RAID-10 "wastes" half the drives for data backup, disks are cheap and write performance can be twice that of the same drives in a RAID-5 setup. That's because there are no reads required, and only two write operations. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
6. Take RAID-5 degraded performance into consideration. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If you ever lose a drive from an array (and you will) remember that data on the failed drive needs to be reconstructed from the remaining drives. Rebuilding the missing drive (generally possible while online) will slow things further. Make sure you have the extra performance capacity! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
7. Consolidate to one array when possible and sensible. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Consider the drive count and the nature of the tasks being performed. Take this setup for example: a mirrored set for the OS, another for the log files and three drive arrays for your Exchange database. This configuration will give poor performance on all sets. Most of the time, the system is waiting on one set while the other is idle. For three sets, read performance on OS and LOG will be 2n, write performance will be n. For the exchange database read performance will be 3n, write performance is 3/4n -- worse than a single drive and worse than a mirrored pair! We're one spam attack from meltdown.
Take those same seven drives as a RAID-5 set and build logical drives as needed. We now have read performance of 7n, the same as the aggregate performance of the "authorized" system, except now the full performance is available wherever it is needed. Write performance is now (worst case) 7n/4 -- not quite the peak aggregate of the authorized system (2 3/4 times n), but greatly enhanced at any time where all volumes are not peaked simultaneously. This is especially important when performing any single threaded action -- defragmenting a drive, running checkdisk, or exchange integrity. In fact, the only time building separate arrays makes sense is for certain recovery conditions when a process can be well matched to the array performance, or the arrays are so large as to stretch the limits of reliability (generally 14 drives or more). Otherwise, consolidate! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For more information:
Tip: How to choose the right RAID for your array
Tip: These mistakes can kill RAID dead
Tip: A quick and dirty way to increase a RAID-5 array
About the author: Randy Grein is a networking consultant based in the Seattle area. A Master CNE, CCNA and former MCSE (3.5) he writes in his spare time on subjects ranging from hardware interactions to network systems strategy.
|
|
Rate this Tip
|
To rate tips, you must be a member of SearchStorage.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
|
|
|
|
