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

Re: [dm-devel] Designing a new prio_callout

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 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
\_ 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
\_ 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] ,1 iqn.2001-07.com.company:qaiscsi2:blah1
tcp: [21],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 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.


Dr. Hannes Reinecke                   zSeries & Storage
hare 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 redhat com

Ethan John
(206) 841.4157

Ethan John
(206) 841.4157
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]