[Gluster-devel] GlusterFS Spare Bricks?

7220022 7220022 at gmail.com
Tue Apr 10 08:39:17 UTC 2012


Are there plans to add provisioning of spare bricks in a replicated (or
distributed-replicated) configuration? E.g., when a brick in a mirror set
dies, the system rebuilds it automatically on a spare, similar to how it'd
done by RAID controllers.
 
Nor would it only improve the practical reliability, especially of large
clusters, but it'd also make it possible to make better-performing clusters
off less expensive components. For example, instead of having slow RAID5
bricks on expensive RAID controllers one uses cheap HBA-s and stripes a few
disks per brick in RAID0 - that's faster for writes than RAID 5/6 by an
order of magnitude (and, by the way, should improve rebuild times in Gluster
many are complaining about.).  A failure of one such striped brick is not
catastrophic in a mirrored Gluster - but it's better to have spare bricks
standing by strewn across cluster heads.
 
A more advanced setup at a hardware level involves creating "hybrid disks"
whereas HDD vdisks are cached by enterprise-class SSD-s.  It works
beautifully and makes HDD-s amazingly fast for random transactions.  The
technology's become widely available for many $500 COTS controllers.
However, it is not widely known that the results with HDD-s in RAID0 under
SSD cache are 10 to 20 (!!) times better than with RAID 5 or 6.
 
There is no way to use RAID0 in commercial storage, the main reason being
the absence of hot-spares.  If on the other hand the spares are handled by
Gluster in a form of (cached hardware-RAID0) pre-fabricated bricks both very
good performance and reasonably sufficient redundancy should be easily
achieved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120410/08c98e5e/attachment-0003.html>


More information about the Gluster-devel mailing list