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.
<br><br><div><span class="gmail_quote">On 8/10/07, <b class="gmail_sendername">Ethan John</b> <<a href="mailto:ethan.john@gmail.com">ethan.john@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hannes, thanks again for your help with this.<br> <br>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.
<br><br>Being able to set path priorities manually would be ideal, but it seems like this is impossible, right?<br><br>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:
<br>mpath45 (20002c9020020001a00151b6b46bb57b0) dm-1 company,iSCSI target<br>[size=15G][features=0][hwhandler=0]<br>\_ round-robin 0 [prio=1][active]<br> \_ 22:0:0:1 sdc 8:32  [active][ready]<br>\_ round-robin 0 [prio=1][enabled]
<br> \_ 23:0:0:1 sde 8:64  [active][ready]<br>mpath44 (20002c9020020001200151b6b46bb57ae) dm-0 company,iSCSI target<br>[size=15G][features=0][hwhandler=0]<br>\_ round-robin 0 [prio=1][enabled]<br> \_ 22:0:0:0 sdb 8:16  [active][ready]
<br>\_ round-robin 0 [prio=1][enabled]<br> \_ 23:0:0:0 sdd 8:48  [active][ready]<br><br>Note that there are only two active sessions:<br># iscsiadm -m session<br>tcp: [20] <a href="http://10.53.152.22:3260" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
10.53.152.22:3260
</a>,1 iqn.2001-07.com.company:qaiscsi2:blah1<br>tcp: [21] <a href="http://10.53.152.23:3260" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">10.53.152.23:3260</a>,2 iqn.2001-07.com.company:qaiscsi2:blah1
<br><br>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.
<br><br>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?
<div><span class="e" id="q_114506f4b1a5ad6a_1"><br><br><div><span class="gmail_quote">On 8/10/07, <b class="gmail_sendername">Hannes Reinecke</b> <<a href="mailto:hare@suse.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
hare@suse.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ethan John wrote:<br>> Is it possible to manually set the priority of a path after a connection has<br>> been established?<br>><br>> Since we're doing failover-only (only 1 active path at a time), it would be
<br>> nice to tell users that they can manually reset priority after a failure.<br>> For example, in a configuration with two paths, where one is active and the<br>> other is passive for two differeent volumes, a failure of one path will
<br>> result in all traffic going through the one remaining path. After the second<br>> path comes back up, all traffic will still be written to the first path<br>> (paths are not rebalanced after a failure).<br>

><br>Not necessarily. There is the keyword 'failback', which can be set to<br>IMMEDIATE, causing all paths to fail back to the original path once it<br>comes back.<br><br>And as you don't actually need to send any commands for facilitate
<br>the failover I doubt you'd need to develop your own hardware handler.<br><br>The existing tweaks should be enough, I think.<br><br>Cheers,<br><br>Hannes<br>--<br>Dr. Hannes Reinecke                   zSeries & Storage
<br><a href="mailto:hare@suse.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">hare@suse.de</a>                          +49 911 74053 688<br>SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
<br>GF: Markus Rex, HRB 16746 (AG Nürnberg)<br><br>--<br>dm-devel mailing list
<br><a href="mailto:dm-devel@redhat.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dm-devel@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/dm-devel" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://www.redhat.com/mailman/listinfo/dm-devel</a><br></blockquote></div><br><br clear="all">
<br></span></div><div><span class="e" id="q_114506f4b1a5ad6a_2">-- <br>Ethan John<br><a href="http://www.flickr.com/photos/thaen/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.flickr.com/photos/thaen/
</a><br>(206) 841.4157
</span></div></blockquote></div><br><br clear="all"><br>-- <br>Ethan John<br><a href="http://www.flickr.com/photos/thaen/">http://www.flickr.com/photos/thaen/</a><br>(206) 841.4157