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
