Jeff,
Thanks for the details. If I might trouble you for a few more...
Jeff Darcy wrote:
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.
I'm running Xen virtualization, and I understand how all the pieces fit
together for running paravitualized hosts over a local disk, software
raid, LVM, and DRBD - but none of those involve qemu. I wonder if you
could say a little bit about how all the pieces wire together, if I
wanted to mount a Gluster filesystem from a paravirtualized VM, through
the qemu interface?
Thanks again,
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users
