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
|