[dm-devel] Designing a new prio_callout

[Hannes Reinecke]

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 at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)