On Thursday 18 May 2006 1:25 pm, Karsten Nielsen wrote:
> Mayby I frased my question wrong. I have read a lot on the mailing list
> about pros and cons of different ways to make the file backend avalible
> to multiple physical servers.
i think the main objection for most of us is the use of file backed domUs.
using files for the domU's storage is fine for testing on a single machine,
but for performance it's much better to use block devices. if you want to do
live migration, then you have to make those block devices available to both
physical boxes; therefore you should use a shared block device (NDB, DRBD,
iSCSI, AoE, FC, etc).
some people have used NFS (or samba!) file servers to hold the files holding
the domU's storage, but performance suffers a lot, and all involved resources
are much more heavily taxed (dom0 RAM, LAN bandwitdh, NFS box RAM).
another 'mixed' usage is to use a shared block device, but instead of
splitting it with LVM2 or EVMS, you could use a cluster file system (usually
GFS or OCFS2) to hold the files. it's somewhat 'lighter' than using a
fileserver, but still the filesystem is a significant overhead compared to
going straight to the block device.
also, in both cases, the VBD implementation is much more streamlined when you
use a block device instead of a file.
another way to see it is that the guest OSs want to have some disks. disks
are block devices. those virtual disks won't be 'real' physical disks, but
still want to do block-like IO. therefore, it's more efficient if the whole
chain of data between the real disks and the guest OS is done with block
device protocols, without any filesystem in between.
--
Javier
pgpUyvzEEk8KU.pgp
Description: PGP signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home