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
