[dm-devel] Designing a new prio_callout

[Ethan John]

For the record, setting rr_min_io to something extremely large (we're using
2 billion now, since I'm assuming it's a C integer) solves the immediate
problem that we're having (overhead in path switching causing poor
performance). Telling people to use mpath_prio_random is still less than
ideal for any small number of iSCSI targets, but it a better short-term
solution for us than nothing.

On 8/10/07, Ethan John <ethan.john at gmail.com> wrote:
>
> Hannes, thanks again for your help with this.
>
> I haven't noticed that failback does the right thing, but I'll try it out
> again. Could be something we're doing wrong. In any case, there's very
> little documentation on all this, and I'm trying to develop some kind of
> strategy for our Linux customers to use until we get ALUA implemented.
>
> Being able to set path priorities manually would be ideal, but it seems
> like this is impossible, right?
>
> Here's the situation we have right now. I initiate two connections to one
> target, across two sessions with two different IPs, with two LUs. Multipath
> looks like this:
> mpath45 (20002c9020020001a00151b6b46bb57b0) dm-1 company,iSCSI target
> [size=15G][features=0][hwhandler=0]
> \_ round-robin 0 [prio=1][active]
>  \_ 22:0:0:1 sdc 8:32  [active][ready]
> \_ round-robin 0 [prio=1][enabled]
>  \_ 23:0:0:1 sde 8:64  [active][ready]
> mpath44 (20002c9020020001200151b6b46bb57ae) dm-0 company,iSCSI target
> [size=15G][features=0][hwhandler=0]
> \_ round-robin 0 [prio=1][enabled]
>  \_ 22:0:0:0 sdb 8:16  [active][ready]
> \_ round-robin 0 [prio=1][enabled]
>  \_ 23:0:0:0 sdd 8:48  [active][ready]
>
> Note that there are only two active sessions:
> # iscsiadm -m session
> tcp: [20] 10.53.152.22:3260 ,1 iqn.2001-07.com.company:qaiscsi2:blah1
> tcp: [21] 10.53.152.23:3260,2 iqn.2001-07.com.company:qaiscsi2:blah1
>
> So the result is that all activity is routed to the first session that was
> initiated. I want to change the priorities of the paths to allow for traffic
> to go to the first IP for mpath45 and the second IP for mpath46.
>
> Obviously ALUA is the way to go for this in the future, but we won't have
> the resources to implement that, so I'm looking for an interim solution that
> will scale to thousands of clients. Right now, the only thing I can tell
> people is to manually initiate connections to certain targets through
> certain IP addresses -- basically, doing the load balancing themselves. Is
> there a better way?
>
> On 8/10/07, Hannes Reinecke <hare at suse.de> wrote:
> >
> > Ethan John wrote:
> > > Is it possible to manually set the priority of a path after a
> > connection has
> > > been established?
> > >
> > > Since we're doing failover-only (only 1 active path at a time), it
> > would be
> > > nice to tell users that they can manually reset priority after a
> > failure.
> > > For example, in a configuration with two paths, where one is active
> > and the
> > > other is passive for two differeent volumes, a failure of one path
> > will
> > > result in all traffic going through the one remaining path. After the
> > second
> > > path comes back up, all traffic will still be written to the first
> > path
> > > (paths are not rebalanced after a failure).
> > >
> > Not necessarily. There is the keyword 'failback', which can be set to
> > IMMEDIATE, causing all paths to fail back to the original path once it
> > comes back.
> >
> > And as you don't actually need to send any commands for facilitate
> > the failover I doubt you'd need to develop your own hardware handler.
> >
> > The existing tweaks should be enough, I think.
> >
> > 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)
> >
> > --
> > dm-devel mailing list
> > dm-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/dm-devel
> >
>
>
>
> --
> Ethan John
> http://www.flickr.com/photos/thaen/
> (206) 841.4157
>



-- 
Ethan John
http://www.flickr.com/photos/thaen/
(206) 841.4157
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20070814/16bacedd/attachment.htm>