As far as I know you should be able to do the same as with a SAN. you
can have multiple block-dev entries (to handle your aggregated IO) per
path group. Some one on the list please correct me if Im wrong.. So in
my previous example things would expand like this to handle your
aggregated IO to the device. <br>
<br>
media-oracle (30690a018a0b3d369dd4f04191c4090f9)<br>[size=8 GB][features="0"][hwhandler="0"]<br>\_
round-robin 0
[active]                          
  <br>  \_ 2:0:8:0 sdj 8:144 [active][ready]            }    <br> \_
another dev
here                                   
} These all make up path group one <br>
 \_ another dev
here                                   
}<br>
\_ round-robin 0 [enabled]<br>  \_ 3:0:8:0 sdr 65:16 [active][ready]           } <br>
 \_ another dev
here                                  
}<br>
 \_ another dev
here                                  
} These all make up path group two<br>
 \_ another dev
here                                  
}<br>
<br>
Our ISCSI net is very isolated and built with failover so unless we
loose two switches at once there should be no hick-up. Sorry cant fill
in any more on that end.<br>
<br>
On a side note.. can we go of list Id like to hear more about your
Equallogic issue. Ive got some wierd nonsense filling up my OS logs and
Equallogic can't figure it out either. <br><br>
-- <br>
:wq!<br>
kevin.foote<br>
<br><div><span class="gmail_quote">On 11/14/07, <b class="gmail_sendername">Michael Vallaly</b> <<a href="mailto:vaio@nolatency.com">vaio@nolatency.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;">
Kevin,<br><br>Correct
me if im wrong, but I if I changed the path_grouping_policy to
"failover" I lose the ability to aggregate IO traffic across multiple
active paths at once. Unfortunately in our situation the performance
hit would be undesirable.<br><br>With your setup do your backend block
device names ever change? Say if you had an extended network outage and
had to manually reconnect to the SAN?<br><br>-Mike<br><br>On Wed, 14 Nov 2007 13:26:32 -0500<br>"Kevin Foote" <<a href="mailto:kevin.foote@gmail.com">kevin.foote@gmail.com</a>> wrote:<br><br>> Mike,<br>
> If you are going for failover things should look like this..<br>> We go to an Equallogic PS box as well .. through a QLA4052 HBA<br>><br>> You need to change this line in your /etc/multipath.conf file to<br>
> reflect what you want multipathd to do.<br>> >         path_grouping_policy    multibus<br>> should read ...<br>>          path_grouping_policy    failover<br>><br>> In turn your maps will look like this ..  (multipath -ll)
<br>> media-oracle (30690a018a0b3d369dd4f04191c4090f9)<br>> [size=8 GB][features="0"][hwhandler="0"]<br>> \_ round-robin 0 [active]<br>>   \_ 2:0:8:0 sdj 8:144 [active][ready]<br>> \_ round-robin 0 [enabled]
<br>>   \_ 3:0:8:0 sdr 65:16 [active][ready]<br>><br>> and dmsetup table <dev><br>> #> dmsetup table /dev/mapper/media-oracle<br>> 0 16803840 multipath 0 0 2 1 round-robin 0 1 1 8:144 100 round-robin 0
<br>> 1 1 65:16 100<br>><br>> will show a multipath failover setup<br>><br>><br>> --<br>> :wq!<br>> kevin.foote<br>><br>> On Nov 14, 2007 1:07 AM, Michael Vallaly <<a href="mailto:vaio@nolatency.com">
vaio@nolatency.com</a>> wrote:<br>> ><br>> > Hello,<br>> ><br>>
> I am currently using the dm-multipather (multipath-tools) to allow
high-availability / increased capacity to our Equallogic iSCSI SAN. I
was wondering if anyone had come across a way to re-instantiate a
failed path / paths from a multipath target, when the backend device
(iscsi initiator) goes away.<br>> ><br>> > All goes well
until we have a lengthy network hiccup or non-recoverable iSCSI error
in which case the multipather seems to get wedged. The path seems to
get stuck in a [active][faulty] state and the backend block device
(sdX) actually gets removed from the system. I have tried reconnecting
the iSCSI session, after this happens, and get a new (different IE: sdg
vs. sdf) backend block level device, but the multipather never picks it
up / never resumes IO operations, and I generally have then to power
cycle the box.<br>> ><br>> > We have anywhere from 2 to 4
iSCSI sessions open per multipath target, but even one path failing
seems to cause the whole multipath to die. I am hoping there is a way
to continue on after a path failure, rather than the power cycle. I
have tried multipath-tools 0.4.6/0.4.7/0.4.8, and almost every
permutation of the configuration I can think of. Maybe I am missing
something quite obvious.<br>> ><br>> > Working Multipather<br>> > <snip><br>> > mpath89 (36090a0281051367df57194d2a37392d5) dm-4 EQLOGIC ,100E-00<br>> > [size=300G][features=1 queue_if_no_path][hwhandler=0]
<br>> > \_ round-robin 0 [prio=2][active]<br>> >  \_ 5:0:0:0  sdf 8:80  [active][ready]<br>> >  \_ 6:0:0:0  sdg 8:96  [active][ready]<br>> > </snip><br>> ><br>> > Wedged Multipather (when a iSCSI session terminates) (All IO queues indefinitely)
<br>> > <snip><br>> > mpath94 (36090a0180087e6045673743d3c01401c) dm-10 ,<br>> > [size=600G][features=1 queue_if_no_path][hwhandler=0]<br>> > \_ round-robin 0 [prio=0][enabled]<br>> >  \_ #:#:#:#  -   #:#   [active][faulty]
<br>> > </snip><br>> ><br>> > Our multipath.conf looks like this:<br>> > <snip><br>> > defaults {<br>>
>        
udev_dir                /dev<br>> >         polling_interval        10<br>>
>        
selector                "round-robin
0"<br>> >         path_grouping_policy    multibus<br>>
>        
getuid_callout          "/lib/udev/scsi_id
-g -u -s /block/%n"<br>>
>        
#prio_callout            /bin/true<br>>
>        
#path_checker            readsector0<br>>
>        
path_checker            directio<br>>
>        
rr_min_io              
100<br>> >        
rr_weight              
priorities<br>> >        
failback                immediate<br>>
>        
no_path_retry          
fail<br>> >         #user_friendly_names     no<br>> >         user_friendly_names     yes<br>> > }<br>> ><br>> > blacklist {<br>> >         devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st|sda)[0-9]*"
<br>> >         devnode "^hd[a-z][[0-9]*]"<br>> >         devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"<br>> > }<br>> ><br>> ><br>> > devices {<br>> >         device {
<br>>
>                
vendor                  "EQLOGIC"<br>>
>                
product                
"100E-00"<br>>
>                
path_grouping_policy    multibus<br>>
>                
getuid_callout          "/lib/udev/scsi_id
-g -u -s /block/%n"<br>>
>                
#path_checker            directio<br>>
>                
path_checker            readsector0<br>>
>                
path_selector          
"round-robin 0"<br>>
>                
##hardware_handler        "0"<br>>
>                
failback                immediate<br>>
>                
rr_weight              
priorities<br>>
>                
no_path_retry          
queue<br>>
>                
#no_path_retry          
fail<br>>
>                
rr_min_io              
100<br>>
>                
product_blacklist       LUN_Z<br>> >         }<br>> > }<br>> ><br>> > </snip><br>> ><br>> > Thanks for your help.<br>> ><br>> > - Mike Vallaly<br>> ><br>> >
<br>> ><br>> ><br>> ><br>> > --<br>> > dm-devel mailing list<br>> > <a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>> > <a href="https://www.redhat.com/mailman/listinfo/dm-devel">
https://www.redhat.com/mailman/listinfo/dm-devel</a><br>> ><br>><br>> --<br>> dm-devel mailing list<br>> <a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>> <a href="https://www.redhat.com/mailman/listinfo/dm-devel">
https://www.redhat.com/mailman/listinfo/dm-devel</a><br><br><br>--<br>dm-devel mailing list<br><a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/dm-devel">https://www.redhat.com/mailman/listinfo/dm-devel
</a><br></blockquote></div><br><br>