| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RES: RES: RES: [Xen-users] Shared volume: Software-ISCSI or GFS or OCFS2
I got it.
My current situation is :
We have several Lun's attached to each hosts. None of them attached to more
than one at sime time. But we can do it. It's pretty easy.
As I Said, my goal is the less downtime as possible. I don't need live
migration I guess.
Im quite confused on how I can achieve the Best performance and less
downtime with my configuration.
Here it is:
01 EMC Storage (currently with several Lun's configured).
03 Dell PowerEdge 2900 Hosts with Fibre Channel PCI cards connected to a
fibre switch
06 domU's Linux PV
08 domU's Windows 2003 R2 64bits
06 domU's Windows 2008 64bits
Few other domU's with time.
Im trying to plan a stable backup procedure together with minimum downtime.
I can also use Symantec Backup Exec to take care of Backup stuff directly
for the guests (domU's)...
What do you guys suggest?
Thanks
Bruno
-----Mensagem original-----
De: John Haxby [mailto:john.haxby@xxxxxxxxxx]
Enviada em: quinta-feira, 20 de novembro de 2008 10:37
Para: Bruno Bertechini
Cc: 'Rustedt, Florian'; 'Bastian Blank'; xen-users@xxxxxxxxxxxxxxxxxxx
Assunto: Re: RES: RES: [Xen-users] Shared volume: Software-ISCSI or GFS or
OCFS2?
Bruno Bertechini wrote:
> Well.. Let me use this thread and popup my environment and ask for
> suggestions:
>
> We have a EMC storage and 03 hosts (all with fibre channel adapters).
>
>
> Choice 1 :
>
> Regarding Xen backend : Files or LVM ? I'm thinking to use LVM to use
online
> resize/snapshots. Are there huge performance differences?
>
> I can't define a infrastructure for EMC/NFS/OCFS/etc without choose before
> select the appropriate backend.
>
> What do you suggest guys?
>
Do you want (live) migration? If so then you'll need to be able to
access the files/LUNs/logical volumes from each machine in the cluster.
That probably constrains your choices somewhat: there is cluster LVM
(clvm) but I don't know enough to say anything for or against it; nfs
and ocfs2 will both work of course; and then there's the third choice of
LUNs in the EMC storage being assigned to more than one machine or
migrated from machine to machine and I have no idea how that is done as
I don't have that kind of hardware to hand.
I will say this something resizing and snapshots though.
You don't need LVM for resizing: you can grow a file by dd'ing empty
space from /dev/zero on to the end of it. You'll need to restart the
guest that's using the file to pick up the new file size (although I
think that might have changed in 3.3, I'm not sure). Likewise you can
grow LUNs defined in the array.
Snapshots are not the panacea you might think. If you just take a
snapshot of a guest's virtual disk then what you've got is a corrupt
virtual disk because you haven't got what was in the guest's memory and
on the way to the disk. If you xm save the guest and copy the memory
snapshot the disk then what you've done is basically a fork(2) of an OS
-- when you restore the backed up copy it'll carry on doing exactly what
it was doing at the time of the backup. My favourite example of the day
is what happens when that guest is about to change a database over a
network connection -- that change will happen twice. Let's hope it's
$salary = $salary * 1.1.
jch
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home