Researchers reveal radical RAID rethink
“Pipelined erasure coding” helps storage to scale at speed
Singaporean researchers have proposed a new way to protect the integrity of data in distributed storage systems and say their “RapidRAID” system offers top protection while consuming fewer network, computing and storage array resources than other approaches.
RAID – redundant arrays of inexpensive disks – has been a storage staple for a almost quarter of a century. The technique involves replicating data across a number of disks so that failure or loss of a single spindle does not result in data loss. When a drive dies, RAID means a new drive can be added to an array and the data from the original drive will be restored. Different “levels” of RAID work with varying quantities of disk and deliver different levels of reliability.
RAID has, of late, become less popular as various scale-out architectures offer different approaches to redundant data storage. The technique is also challenged by multi-terabyte disk drives, as the sheer quantity of data on such disks means rebuilding a drive can take rather longer, and hog more IOPS, than many users are willing to endure.
Erasure codes are one of the techniques challenging RAID and can most easily be understood as a form of metadata. Erasure codes allow fragments of data to be spread across a wider pool of disks, before the desired data is re-assembled using fragments from multiple sources. Erasure codes feature in the Google File System, Hadoop’s file system, Azure and several commercial products.
Some have even described erasure codes as delivering RAIN – a redundant array of inexpensive nodes – that is positioned as a successor to RAID.
The Singaporean researchers’ work, available on arXiv, proposes a new scheme called RapidRAID that goes beyond other implementations of erasure codes, reducing the amount of storage required to create a viable archive while also speeding the time required to create that archive.
The team thinks this is possible with what it calls “pipelined insertion” under which:
“… the encoding process is distributed among those nodes storing replicated data of the object to be encoded, which exploits data locality and saves network traffic. We then arrange the encoding nodes in a pipeline where each node sends some partially encoded data to the next node, which creates parity data simultaneously on different storage nodes, avoiding the extra time required to distribute the parity after the encoding process is terminated.”
The paper linked to above then proposes RapidRAID, a set of erasure codes which, just like RAID, offer different levels of data protection.
Tests of the new codes are described in the paper, which compares RapidRAID to the Reed-Solomon erasure codes used in many current implementations. In a test involving 50 thin clients and 16 EC2 instances, the researchers proclaim RapidRAID superior in some ways.
The researchers therefore declare RapidRAID a viable big data enabler, but conclude that there’s more work to be done before it can be declared suitable for applications that require more than two copies of data.
The codes are available for download on github. ®
The real reason behind the problems with RAID and larger disk sizes isn't IOPS or anything else, but the uncorrected read error rate. To rebuild a RAID 5 array after a failure you have to read all the data from all the surviving members of the array. The larger the disk, the more likely you are to hit an uncorrected read error which will silently corrupt the reconstructed data.
This is why ZFS does block based checksums, specifically to catch this kind of problem
NetApp gets around it by using non-standard hard drives. NetApp drives have a 520 byte sector, and several (or all, I forget) of those extra bytes are for a checksum.
Good points An0n C0w4rd
The thing which makes ZFS very robust, is all data storage and data transfers are checksummed, so that it doesn't matter where the data gets corrupted, you know about it, and promptly.
I wonder if RaidRAID does comprehensive checksumming; if not, I wouldn't trust it.
I had a disk failure on a ZRAID2 5 disk array, lost nothing, and didn't notice any performance issues during a 56 hour resilver, for the replaced 2TB disk.
If RapidRAID is based on nodes, how is it going to help the 90% of people who just want to protect the data on a dozen HDs, and don't want to build their own Googleplex ?