Re: Designing a new prio_callout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the heads-up about ALUA. We're looking into it.

What is the purpose of the custom mpio_prio_* applications that ship
with open-iscsi if not to handle multipathing?

On 7/25/07, Hannes Reinecke <hare@xxxxxxx> wrote:
> Ethan John wrote:
> > I hope I found the right list for this.
> >
> > My company is developing an iSCSI solution, and in looking into Linux
> > compatability and performance, we're concerned that our architecture
> > doesn't
> > play well with the existing multipath configurations that are available.
> >
> > We cannot support what Linux calls multibus, or what the fiber world seems
> > to call active/active. We will need folks to configure failover
> > exclusively.
> >
> > It appears that the current multipathing failover configuration assigns a
> > priority to each path (by default, just assigns the same priority to all
> > paths). This is bad for us, as we're presenting iSCSI targets across
> > multiple machines in a cluster; ideally, a user will have multiple devices,
> > each with a separate path to a separate machine, with failover to the other
> > machines in the cluster. The default setup of multipath will map all
> > connections to a single machine, which is no load balancing at all.
> >
> > I've fooled around with various other values for default_prio_callot
> > (besides the /bin/true), and the one that seems to work best is actually
> > mpath_prio_random.
> >
> Argl.
>
> > In fact, mpath_prio_random would actually work perfectly, except that it
> > seems to swap path priorities extremely often -- several times a minute. So
> > my company needs to develop a new script, probably much like the
> > mpath_prio_emc or mpath_prio_netapp ones, so that we can hint at load
> > balancing across devices with failover as the multipathing policy.
> >
> > I've been completely unable to find documentation on this. Where might I
> > look? Is this even the right direction in which to be looking for a
> > solution to this problem?
> >
> Have you looked a ALUA ?
> It's in SPC-3 section 5.8: 'Target port group access states'.
>
> This is the preferred way of handling these things.
> And is supported by multipath-tools.
>
> Mind you, only implicit ALUA is supported. Explicit ALUA
> support will be implemented, too, once someone actually
> uses it :-)
>
> Please do not design your own way of handling failover. This
> has shown too many difficulties in the past.
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke                   zSeries & Storage
> hare@xxxxxxx                          +49 911 74053 688
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Markus Rex, HRB 16746 (AG Nürnberg)
>
> --
> dm-devel mailing list
> dm-devel@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/dm-devel
>


-- 
Ethan John
http://www.flickr.com/photos/thaen/
(206) 841.4157

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux