2

Do you think that KVM (or XEN) virtual machine using GlusterFS as storage will be really slow?

My idea is to use GlusterFS to avoid the limits of the local file system. If an hypervisor will go down, another one could take care of the 'orphans' VMs. Even the live migration should be straight forward.

hookenz
  • 14,472
  • 23
  • 88
  • 143
rtacconi
  • 745
  • 4
  • 14
  • 28

2 Answers2

3

If you want to build a "shared nothing" cluster for high availability, a master-slave DRBD setup with any filesystem on top of it should do the trick. If you want some kind of load balancing, you should evaluate GlusterFS, but it will definitely a bit slower on both nodes than a non-clustered FS due to certain clustering-reated overhead. I have never tried GlusterFS, but I tried OCFS2. I found it not stable enough in virtualized environments, although it worked well on a real hardware.

Alex
  • 7,939
  • 6
  • 38
  • 52
  • 1
    +1 for proven technology and simplicity before reaching for additional solutions. Depending on other factors, trying newer things is often a good recommendation but I've not followed GlusterFS and Ceph in terms of significant production deployments. Also, researchers can feel social pressure to live on the hemorrhaging edge. –  Nov 05 '11 at 12:40
2

Theoretically it should work perfectly fine. I would recommend though that your Gluster Network and bandwidth from the xen or kvm host is reasonably fast. As a minimum I'd bond 2 or more gigabit ethernet interfaces for greater performance. If budget allows, use infiniband.

Gluster version 3.4 has now been improved to support this type of use case.

Features for GlusterFS 3.4
...
Eager locking - significantly improves VM image storage

You could also use ceph as an alternative. This is now built into qemu which xen & kvm are built on top of.

Personally I think the DRDB way is a bit limited. It works well for simple smaller deployments though.

hookenz
  • 14,472
  • 23
  • 88
  • 143