[Gluster-users] how well will this work

[Jeff Darcy]

On 12/30/12 1:33 PM, Miles Fidelman wrote:
> What's the alternative, though?  Ok, for application files (say a word
> processing document) that works, but what about spools, databases, and
> such?  Seems like blocks are the common denominator.

It's all blocks underneath; it's a matter of how you get to those blocks.  If
you use a simulated block device which is actually a GlusterFS file, then
you'll be going through both FUSE and the loopback driver.  That actually works
OK for many things, but latency will be a bit high e.g. for databases.  One
option is to use the qemu interface, which avoids both sources of overhead.  In
fact, the overhead from virtualizing your database server is likely to be lower
than FUSE+loopback because our esteemed kernel colleagues seem a lot more
interested in making virtual I/O work better than in doing the same for FUSE.
It's still a tiny hit compared to running a DB on bare metal, but the value of
being able to survive a failure should more than outweigh that.

> For high-availability applications (like
> mine), 3-way replication would seem to be the major advantage of a
> cluster file system over DRBD.

It all depends on how many failures, of which type, you need to handle, and
what price you're willing to pay in terms of storage utilization.  It's easy to
get protection against two disk failures or one server/network failure using
replication plus RAID on the servers.  If you want protection against two
server failures, then there's geosync.  You could also try using local sync
(AFR) and it would probably work for you (as it does for Joe), but there's the
caveat that we're still working on some of the more unusual edge cases.  Only
you and your tests can say whether that's good enough.