RAID-Z + JBOD or RAID-5?
I was at the SUN-NUS Opensource Day on Friday, and after the event, we all adjourned for dinner. You know, when geeks gather, we inevitably will start discussing the hacks we are deploying for one reason or the other. Or thorny problems. And hence, I brought up my "huge dataset" problem.
Now, the traditional way of doing storage carving is to do RAID-5 on the SAN, cut each RAID-5 set into smaller luns to map to the operating system. If need be, some of the luns will be RAID-1/striped together in the OS. Why? RAID-5 for redundancy, smaller luns as the RAID-5 set is too big, and striped luns to expand storage when required.
So, what's the big problem? Wee Yeh (http://prstat.blogspot.com) pointed out that lun carving is done ACROSS the RAID-5 disk set. It simply follows the way RAID-5 parity is done.
"ACROSS"!!!! Wait a moment... Doesn't this mean if a disk fails, performance is impacted across all the luns in the disk set? And if 2 disks fails, ALL the luns in the disk set are dead! So, if one lun is for applications, another is for data storage, and the third is for user directories, the entire computing stack is down. Unrecoverably dead. Geebes!!!!! <head rolls>
Of course, being a nice guy, Wee Yeh suggests using JBOD disk sets + RAID-Z using ZFS. Since ZFS will do the parity checks, there is still redundancy. If a hard disk fails, the ZFS pool continues to work. If 2 disks fail, at least the damage is contained to this ZFS pool. Added advantage is that both the SAN storage and ZFS will scream when the first hard disk dies, as opposed to only the SAN storage screaming, while the OS remains oblivious. And ZFS has parity checks during disk read/write, nicely overcoming the lack of parity read/write checks on SATA disks.
Okay, time to do some hard thinking
Trackback URL for this post:
- jmarki's blog
- 346 reads



Comments
Post new comment