As we see more and more customers’ data repositories headed into hundreds of terabytes and even petabytes, the issues of data protection, both in production and archive, are growing areas of concern for them. With more organizations wanting to minimize tape – or simply finding that they have too much data to archive hat way – the emphasis shifts to better on-disk protection models that are flexible enough to accommodate changing needs with regard to data primacy.
In the traditional protection world, RAID 5 has largely given way to RAID 6, and RAID 7 appears on the horizon as the latest potential fix to what is a sliding scale of drive reliability mapped against repository size.
Drives fail. Always have, probably always will. They also do not always succeed in giving you back the same data you originally gave them, creating soft error rates that must be taken into account with true failures when determining data integrity. But as drives get larger and rebuild times proportionately longer, it becomes critical to either dramatically improve error rates or improve protection schema beyond current RAID capabilities – or both.
Drive error rates are reported as 10x, which corresponds to the predicted number of bit read errors over a certain capacity. This measurement is referred to with some variability as the Bit Error Rate (BER), Unrecoverable Read Error (URE), or Unrecoverable Bit Error (UBE) – for the limited purposes of this article those terms are interchangeable. A 1014 error rate represents a bad bit for every 12.5TB of reads, while at 1016 that capacity increases to 1.25PB – it is easy to see that, at scale, enterprise-class drives with higher BER’s are very important.
If you imagine a 15-shelf drive at RAID 5, there is a hot spare and a parity drive – that leaves about 13TB of useable space. Under normal conditions, BER is not an issue, as parity will take care of any bad data; however, if a drive fails, the entire 13TB has to be read. If the drives are rated 1014 (1 error per 12.5TB), there is almost a guarantee of a read error. This means file loss or, worse, a rebuild error. In a ‘hot’ area of the repository, heavy utilization (and often younger drives if that data sat is expanding) can cause decreased drive lifetimes[i], and often negatively impact access times.
If drives get bigger and the BER stays the same, eventually the lines cross and there is a failure on every rebuild. RAID fails at this point. In 2007, storage pundit Robin Harris suggested that RAID 5 would be dead in 2009; it seems not to be true on the whole, but arguably very true at PB scale.[ii] Solutions then offered for this problem included mirroring data, replicating full data sets, or taking 1-2 weekly fulls – all inefficient ways to manage PB-scale repositories.
So many organizations now use RAID 6, where dual parity coupled with improved BER provides a much greater sense of data integrity. There are trade-offs, however: higher CPU utilization, increased wattage/GB, and higher parity overhead. Many repositories are efficiently functioning within those limits, but the risk continues to grow at scale and will eventually threaten RAID 6 just as it currently does RAID 5.[iii]
While the 2019 reference in the Harris article foretelling the death of RAID 6 is admittedly a long way off – much can change within the industry in that scale of time – the more immediate problem appears to be drive throughput and its impact on rebuild times. Large drive capacities, coupled with lagging throughput metrics, create windows of vulnerability; when a drive fails, RAID 6 becomes RAID 5 for the duration of the rebuild (hours? days?), and RAID 5 simply becomes nothing. These are the windows in which data can be lost.
Parts of the industry are now actively calling for RAID 7 implementations to stay ahead of the curve[iv], but many of our customers view increased costs and decreased efficiency as an excuse to take a look at new approaches – dynamic protection schema, faster rebuild environments, protection from silent data corruption, and customizable CPU allocation within their repositories as ways to stem the tide of the RAID chase and bring efficiency and integrity to their ever-increasing data storage needs.
[i] “Failure Trends in a Large Disk Drive Population”, Eduardo Pinheiro, Wolf-Dietrich Weber, Luiz André Barroso, 5th USENIX Conference on File and Storage Technologies (FAST 2007)
[ii] http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162
[iii] http://storagemojo.com/2010/02/27/does-raid-6-stops-working-in-2019
[iv] http://queue.acm.org/detail.cfm?id=1670144