In the storage industry, we have come to accept the concept of RAID. We started with striped and mirrored drives and have evolved to striped drives with parity or dual parity. RAID6, the latest version of RAID to take over the thinking in the storage industry is not exactly a ground breaking storage revelation; we have merely added a second parity stripe to RAID5. While we now have the ability to survive a dual drive fault, we still face the rapidly growing issue of rebuild times.
One terabyte drives with rebuild times of anywhere from a couple of hours to a couple of days were a little frightening because as we increase the rebuild times, we increase our vulnerability to a second drive fault. The drives in a system are typically from the same production batch of drives, and have been spinning in the system for about the same amount of time. With the failure of another drive in the storage array, we have added stress to the remaining drives as they read their parity to rebuild the failed drive while still receiving production I/O. With RAID6, we were fairly confident that in a 24 hour window we could rebuild our array before 3 drives failed. Enter 2TB drives with 10 and 20TB drives on the horizon. What’s the rebuild time of 2TB and greater drives going to be? 48 hours? 56 hours? A week? 2 weeks? And how are we going to protect the data when it takes 80 hours to rebuild an array? RAID7? RAID56.3? I don’t think just adding parity stripes is really going to cut it. There’s a limit that we will hit, at some point we might as well go back to RAID1 or RAID10, and give up half of our capacity so we can have failure on half of our drives.
Where to now? Just adding parity is an option (not perfect, but an answer none the less). Triple Parity, a.k.a RAID TP (yeah, I snickered too), implements three independent parities by extending RAID6 algorithms to tolerate three-disk failures. While impressive engineering, I’m not convinced that it solves the issue. Redundant Array of Inexpensive Nodes, a.k.a. RAIN, presents an interesting approach. With RAIN, we have multiple copies of our data distributed across servers and arrays with “extra” storage. These “nodes” just have to be on the network and are managed by software that tracks where data has been stored. This solution provides the additional benefit of increasing performance by spreading the load across the network. The underlying disk is protected with traditional RAID, but the multiple copies allow for multiple drive failures and even failure of complete nodes. RAIN can take advantage of otherwise unused storage in server and arrays, while this is amazing, what’s the real disk usage overhead. I don’t know, but I have to believe that it is higher than traditional RAID. Again, I’m impressed, but not convinced. Then there’s data dispersion. This claims half hour rebuild times with 1TB drives by randomly spreading data across multiple arrays in 1MB chunks. Data dispersion answers our rebuild issue, but we only have single drive failure protection and we have increased the number of drives in the array. Every additional disk included in an array increases the likelihood that an additional drive will fail during rebuild. With data dispersion, the number of disks increases our vulnerability to multiple disk failures during any given moment of time. So, while solving one problem, we have created another.
What’s the answer to data and drive protection as we move into larger and larger drives? I’m not sure the storage industry has figured that out yet. As the price per terabyte continues to drop, maybe one of these technologies will become more viable or, as I hope, a new technology will be developed that will bring rebuild times under control while lowering the traditional RAID storage space overhead.
Every additional disk included in an array increases the likelihood that one will fail, but by using error checking and/or mirroring, the array as a whole can be made more reliable by the ability to survive and recover from a failure.
Have more questions about RAID or disk storage? Feel free to contact Chi at 440-498-2300.
-Alex Fleming, Systems Engineer
