Re: [Xen-users] lustre clustre file system and xen 3

[Javier Guerra <javier@xxxxxxxxxxx>]

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

Attachment: pgpXY0fEeBgSl.pgp
Description: PGP signature

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users