1 / 43

RAID: HIGH PERFORMANCE, RELIABLE SECONDARY STORAGE

RAID: HIGH PERFORMANCE, RELIABLE SECONDARY STORAGE. P. M. Chen, U. Michigan E. K. Lee, DEC SRC G. A. Gibson, CMU R. H. Katz, U. C. Berkeley D. A. Patterson, U. C. Berkeley. Highlights. The seven RAID organizations Why RAID-1, RAID-3 and RAID-5 are the most interesting

max
Download Presentation

RAID: HIGH PERFORMANCE, RELIABLE SECONDARY STORAGE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. RAID: HIGH PERFORMANCE, RELIABLE SECONDARY STORAGE P. M. Chen, U. Michigan E. K. Lee, DEC SRC G. A. Gibson, CMU R. H. Katz, U. C. Berkeley D. A. Patterson, U. C. Berkeley

  2. Highlights • The seven RAID organizations • Why RAID-1, RAID-3 and RAID-5 are the most interesting • The small write problem occurring with RAID-5 • Possible solutions • Review of actual implementations

  3. Original Motivation • Replacing large and expensive mainframe hard drives (IBM 3310) by several cheaper Winchester disk drives • Will work but introduce a data reliability problem: • Assume MTTF of a disk drive is 30,000 hours • MTTDL for a set of n drives is 30,000/n • n = 10 means MTTDL of 3,000 hours

  4. Today’s Motivation • “Cheap” SCSI hard drives are now big enough for most applications • We use RAID today for • Increasing disk throughput by allowing parallel access • Eliminating the need to make disk backups • Disk drives are too big to be backed up in an efficient fashion

  5. RAID 0 • Spread data over multiple disk drives • Advantage • Simple to implement • Fast • Disadvantage • Very unreliable • RAID 0 with n disks has MMTF equal to 1/n of MTTF of a single disk

  6. RAID 1 • Mirroring • Two copies of each disk block ontwo separate drives • Advantages • Simple to implement and fault-tolerant • Disadvantage • Requires twice the disk capacity of normal file systems

  7. RAID 2 • Instead of duplicating the data blocks we use an error correction code • Very bad idea because disk drives either work correctly or do not work at all • Only possible errors are omission errors • We need an omission correction code • A parity bit is enough to correct a single omission

  8. RAID 2

  9. RAID 3 • Requires N+1 disk drives • N drives contain data • 1/N of each data block on each drive • Block b[k] now partitioned into N fragments b[k,1], b[k,2], ... b[k,N] • Parity drive contains exclusive or of these N fragments p[k] = b[k,1]  b[k,2]  ... b[k,N]

  10. RAID 3 A stripe consists of a single block

  11. RAID 4 • Requires N+1 disk drives • N drives contain data (individual blocks) • parity drive contains exclusive or of the N blocks in stripe p[k] = b[k]  b[k+1]  ... b[k+N-1]

  12. RAID 4 A stripe now contains multiple blocks

  13. RAID 5 • Single parity drive of RAID-4 is involved in every write • Will limit parallelism • RAID-5 distribute the parity blocks among the N+1 drives

  14. RAID 5

  15. The small write problem • Specific to RAID 5 • Happens when we want to update a single block • Block belongs to a stripe • How can we compute the new value of the parity block p[k] b[k] b[k+1] b[k+2] ...

  16. First solution • Read values of N-1 other blocks in stripe • Recompute p[k] = b[k]  b[k+1]  ... b[k+N-1] • Solution requires • N-1 reads • 2 writes (new block and parity block)

  17. Second solution • Assume we want to update block b[m] • Read old values of b[m] and parity block p[k] • Compute p[k] = new b[m]  old b[m]  old p[k] • Solution requires • 2 reads (old values of block and parity block) • 2 writes (new block and parity block)

  18. RAID 6 • Each stripe has two redundant blocks: • P + Q redundancy • Advantage • Much higher reliability • Disadvantage: • Costlier updates

  19. PERFORMANCE COMPARISON • Focus on system throughput • Measure it against system cost expressed in number of disk drives

  20. Throughputs per dollar

  21. Discussion • Performance per dollar of RAID 3 is always less or equal to that of a RAID 5 system • For small writes, • RAID 3, 5 and 6 areequally cost -effective at small group sizes • RAID 5 and 6 arebetter for large group sizes

  22. RELIABILITY • Theoretical reliability is very high • Especially for RAID 6 • In practice, • System crashes can causeparity inconsistencies • Uncorrectable bit errors can happen during repair times (one in 1014 bits) • Correlated disk failures happen!

  23. Impact of parity inconsistencies • Happen when system crashes during an update • New data were written but parity block was not updated • Has little impact on RAID 3 (bad block) • Significant impact on RAID 5 • Bigger impact on RAID 6 • Same as simultaneous failures of both P& Q blocks

  24. Discussion • System crashes and unrecoverable bit errors have biggest effect on MTTDL • P + Q redundant disks protect against correlated disk failures and unrecoverable bit errors • Still vulnerable to system crashes • Should use NVRAM for write buffers

  25. IMPLEMENTATION CONSIDERATIONS • Must prevent users from reading corrupted data from a failed disk • Mark blocks located on the failed disk invalid • Mark reconstructed blocks valid • To avoid regenerating all parity blocks after a crash • Must keep track of parity consistency and store it in stable storage

  26. Discussion • Maintaining consistent/inconsistent state information for all parity blocks is a problem for software RAID systems • Rarely have NVRAM • If updates are local, keep track in stable storage of a small number of parity blocks that could be inconsistent • Otherwise use group commits

  27. SMALL WRITES REVISITED (I) • Asynchronous writes can help if future updates overwrites previous ones • Caching recently read blocks can help if old data necessary to compute new parity are in cache • Caching recently written parity can also help • Parity is computer over many logically consecutive blocks

  28. SMALL WRITES REVISITED (II) • Floating Parity • Make parity update cheaper, by putting parity in a rotationally-nearby unallocated block • Requires directories for locations of nearby unallocated blocks • Should be implemented at controller level

  29. SMALL WRITES REVISITED (III) • Parity Logging : • Defers cost of parity update by logging XOR of old data and new data • Replay log file later to update parity • Reduces update cost to two blocking writes(if we have in the old data block in RAM) • It works because nearly all storage systems have idle times.

  30. Declustered Parity (I) • Addresses issue of high read cost when recovering from a failure a failure • Looking at example: • A failure of disk 2 generates additional read requests to disks 0, 1 and 3 every time a read request is made for a block that was stored on disk 2

  31. Declustered Parity (II)

  32. Declustered Parity (III) • With declustered parity: • Same disk belongs to different groups • Looking at example: • Disk 2 is in groups (0,1, 2, 3), (4, 5, 2 , 3) and so on • Additional read requests caused by a failure of disk 2 are now spread among all remaining disks

  33. Declustered Parity (IV) • Extra workload caused by the failure of a disk is now shared by all remaining disks • Sole Disadvantage: • A failure of any two disks will now result in data loss • In a standard set of RAID array, the two failed disks had to be in the same array

  34. Exploiting On-Line Spare Disks • Distributed Sparing: • No dedicated spare disk • Each disk has 1/(N+1) of its capacity reserved • Parity Sparing: • Also spreads the spare space but uses it to sore additional party blocks • Can split groups into half groups • More …

  35. Distributed Sparing S0, S1 and S2 represent spare blocks

  36. CASE STUDIES • TicketTAIP • AutoRAID • See presentation

  37. TickerTAIP (I) • Traditional RAID architectures have • A central RAID controller interfacing to the host and processing all I/O requests • Disk drives organized in strings • One disk controller per disk string (mostly SCSI)

  38. TickerTAIP (II) • Capabilities of RAID controller are crucial to the performance of RAID • Can become memory-bound • Presents a single point of failure • Can become abottleneck • Having a spare controlleris an expensive proposition

  39. TickerTAIP (III) • Uses a cooperating set ofarray controller nodes • Major benefits are: • Fault-tolerance • Scalability • Smooth incremental growth • Flexibility: can mix and match components

  40. TickerTAIP (IV) Hostinterconnects Controller nodes

  41. TickerTAIP ( V) A TickerTAIP array consists of: • Worker nodes connected with one or more local disks through a bus • Originator nodes interfacing with host computer clients • A high-performance small area network: • Mesh based switching network (Datamesh) • PCI backplanes for small networks

  42. TickerTAIP ( VI) • Can combine or separate worker and originator nodes • Parity calculations are done in decentralized fashion: • Bottleneck is memory bandwidth not CPU speed • Cheaper than having faster paths to a dedicated parity engine

  43. CONCLUSION • RAID original purpose was to take advantage of Winchester drives that were smaller and cheaper than conventional disk drives • Replace a single drive by an array of smaller drives • Nobody does that anymore! • Main purpose of RAID is to build fault-tolerant file systems that do not need backups

More Related