RE: [Xen-users] Storage alternatives

[Nathan Eisenberg <nathan@xxxxxxxxxxxxxxxx>]

Honestly, I'd probably suggest you discard the idea entirely and switch to 
using heartbeat to manage the iSCSI resources.  Alternatively, I believe you 
could also use iSCSI multipath to point to two initiators presenting the same 
DRBD backed volume.

Consider your failure scenario:

If you have a storage node go offline in your current configuration for any 
real length of time, when it becomes available again, all of the nodes will 
begin to resync the array simultaneously.  With a single DomU, you'll just 
consume the vast majority of either your Disk IO or Network IO.  However, if 
you had a dozen guests, and they all start to rebuild their RAID1s from the 
same source SAN to the same destination SAN, through the same network link (in 
and out), at the same time, things are probably going to grind to an absolute 
halt.

RAID is nearly always best when it is used right above the physical disks.  The 
more layers you put between the RAID and the disks, the more bad things(tm) 
seem to occur.

Best Regards,
Nathan Eisenberg
Atlas Networks, LLC
Phone: 206-577-3078
support@xxxxxxxxxxxxxxxx
www.atlasnetworks.us


-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of John Madden
Sent: Wednesday, March 11, 2009 10:13 AM
To: Javier Guerra
Cc: xen-users@xxxxxxxxxxxxxxxxxxx; Jan Marquardt
Subject: Re: [Xen-users] Storage alternatives

On Wed, 2009-03-11 at 10:54 -0500, Javier Guerra wrote:
> the first think i'd do is move all the volume management from DomU to Dom0.
> 
> IOW: the iSCSI initiator and RAID (i guess it's RAID1) should be on
> Dom0, and the DomU configs should refer the resultant blockdevices.

Agreed.  You could even potentially move the mirroring down to the
storage nodes (mirrored nbd/etc. devices) and HA the iSCSI target
service itself to reduce dom0's work, although that would depend on you
being comfortable with iSCSI moving around during a storage node
failure, which may be a risk factor.

John




-- 
John Madden
Sr. UNIX Systems Engineer
Ivy Tech Community College of Indiana
jmadden@xxxxxxxxxxx

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





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