* 3PAR transparent failover with Linux
@ 2014-09-11 12:58 Thomas Glanzmann
2014-09-23 22:11 ` Sebastian Herbszt
0 siblings, 1 reply; 4+ messages in thread
From: Thomas Glanzmann @ 2014-09-11 12:58 UTC (permalink / raw)
To: dm-devel
Hello,
we have two 3PARs 7400 which are configured for transparent failover. In
the following manner:
Active Passive
3PAR-1 - RCOPY - 3PAR-2
\ /
\ /
Active Standby
Optimized /
\ /
Linux Box
When we run multipath -l before the failover two paths were 'active' the
other paths 'failed'. Once we failed over and the ALUA state changed,
all paths went to 'failed':
360002ac0000000000000000a0000cc14 dm-17 3PARdata,VV
size=50G features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:6:0 sdak 66:64 failed undef running
|- 6:0:7:0 sdal 66:80 failed undef running
|- 7:0:6:0 sdbw 68:160 failed undef running
`- 7:0:7:0 sdbx 68:176 failed undef running
But we were able to continue I/O. So I wonder why multipath reported 'failed'
but allowed to continue I/O. So from our standpoint the I/O was continuing. The
transparent failover successfull. This is not supported by 3PAR for Linux but
it is for VMware ESX.
wrz3164:~ # sg_inq /dev/sdak
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x06 [SPC-4]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=1 Resp_data_format=2
SCCS=0 ACC=0 TPGS=1 3PC=1 Protect=0 [BQue=0]
EncServ=0 MultiP=1 (VS=0) [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
[SPI: Clocking=0x0 QAS=0 IUS=0]
length=168 (0xa8) Peripheral device type: disk
Vendor identification: 3PARdata
Product identification: VV
Product revision level: 3131
Unit serial number: <removed>
I would like to know if other people have experimented with 3PAR and
transparent failover. The above was with SLES 11SP3 and SuSE packaged
multipathd 0.4.9. We tried the HP configuration and the configuration
which was in the git head of multipath-tools which I also used during
the failover test:
device {
vendor "3PARdata"
product "VV"
path_grouping_policy "multibus"
path_checker "directio"
features "0"
hardware_handler "0"
prio "const"
rr_weight "uniform"
}
Cheers,
Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: 3PAR transparent failover with Linux 2014-09-11 12:58 3PAR transparent failover with Linux Thomas Glanzmann @ 2014-09-23 22:11 ` Sebastian Herbszt 2014-09-24 3:32 ` Thomas Glanzmann 2014-09-24 7:10 ` Thomas Glanzmann 0 siblings, 2 replies; 4+ messages in thread From: Sebastian Herbszt @ 2014-09-23 22:11 UTC (permalink / raw) To: device-mapper development; +Cc: thomas, Sebastian Herbszt Thomas Glanzmann wrote: > Hello, > we have two 3PARs 7400 which are configured for transparent failover. In > the following manner: > > Active Passive > 3PAR-1 - RCOPY - 3PAR-2 > \ / > \ / > Active Standby > Optimized / > \ / > Linux Box > > When we run multipath -l before the failover two paths were 'active' the > other paths 'failed'. Once we failed over and the ALUA state changed, > all paths went to 'failed': > > 360002ac0000000000000000a0000cc14 dm-17 3PARdata,VV > size=50G features='0' hwhandler='0' wp=rw > `-+- policy='service-time 0' prio=0 status=enabled > |- 6:0:6:0 sdak 66:64 failed undef running > |- 6:0:7:0 sdal 66:80 failed undef running > |- 7:0:6:0 sdbw 68:160 failed undef running > `- 7:0:7:0 sdbx 68:176 failed undef running Do you have a log of the failover? I think path_grouping_policy set to "multibus" suggests all paths are equal. Is this actually true for this configuration? I assume paths to 3PAR-1 (active) should have a higher priority than paths to 3PAR-2 (passive). Since the 3PAR supports ALUA I would change the path_grouping_policy to "group_by_prio" and prio to "alua". What is the output of "sg_rtpg -d" for all paths before and after the failover? > But we were able to continue I/O. So I wonder why multipath reported 'failed' > but allowed to continue I/O. So from our standpoint the I/O was continuing. The > transparent failover successfull. This is not supported by 3PAR for Linux but > it is for VMware ESX. Have you tried setting the path_checker to "tur"? What is the output of "sg_turs -vvv" for all paths? Sebastian ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 3PAR transparent failover with Linux 2014-09-23 22:11 ` Sebastian Herbszt @ 2014-09-24 3:32 ` Thomas Glanzmann 2014-09-24 7:10 ` Thomas Glanzmann 1 sibling, 0 replies; 4+ messages in thread From: Thomas Glanzmann @ 2014-09-24 3:32 UTC (permalink / raw) To: device-mapper development; +Cc: Sebastian Herbszt Hello Sebastian, > Do you have a log of the failover? no. > What is the output of "sg_rtpg -d" for all paths before and after the > failover? I have no longer access to the systems in question, but if the opportunity presents itself again, I'll try your suggestions and report back. Thank you for the feedback. I understand that I wasn't even looking for ALUA. Cheers, Thomas ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 3PAR transparent failover with Linux 2014-09-23 22:11 ` Sebastian Herbszt 2014-09-24 3:32 ` Thomas Glanzmann @ 2014-09-24 7:10 ` Thomas Glanzmann 1 sibling, 0 replies; 4+ messages in thread From: Thomas Glanzmann @ 2014-09-24 7:10 UTC (permalink / raw) To: Sebastian Herbszt; +Cc: device-mapper development Hello Sebastian, * Sebastian Herbszt <herbszt@gmx.de> [2014-09-24 00:14]: > What is the output of "sg_rtpg -d" for all paths before and after the > failover? I took this information only after the failover: Report target port groups: target port group id : 0x102 , Pref=0 target port group asymmetric access state : 0x02 T_SUP : 1, O_SUP : 0, LBD_SUP : 0, U_SUP : 1, S_SUP : 1, AN_SUP : 0, AO_SUP : 1 status code : 0x00 vendor unique status : 0x00 target port count : 14 Relative target port ids: 0x7db 0x7dc 0x7e5 0x7e6 0x7e7 0x83f 0x840 0x849 0x84a 0x84c 0x8a3 0x8a4 0x8ad 0x8ae 0x8af 0x907 0x908 0x911 0x912 0x914 target port group id : 0x101 , Pref=1 target port group asymmetric access state : 0x00 T_SUP : 1, O_SUP : 0, LBD_SUP : 0, U_SUP : 1, S_SUP : 1, AN_SUP : 0, AO_SUP : 1 status code : 0x00 vendor unique status : 0x00 target port count : 10 Relative target port ids: 0x3f3 0x3f4 0x3fd 0x3fe 0x457 0x458 0x461 0x462 0x4bb 0x4bc 0x4c5 0x4c6 0x51f 0x520 0x529 0x52a Report target port groups: target port group id : 0x102 , Pref=0 target port group asymmetric access state : 0x02 T_SUP : 1, O_SUP : 0, LBD_SUP : 0, U_SUP : 1, S_SUP : 1, AN_SUP : 0, AO_SUP : 1 status code : 0x00 vendor unique status : 0x00 target port count : 14 Relative target port ids: 0x7db 0x7dc 0x7e5 0x7e6 0x7e7 0x83f 0x840 0x849 0x84a 0x84c 0x8a3 0x8a4 0x8ad 0x8ae 0x8af 0x907 0x908 0x911 0x912 0x914 target port group id : 0x101 , Pref=1 target port group asymmetric access state : 0x00 T_SUP : 1, O_SUP : 0, LBD_SUP : 0, U_SUP : 1, S_SUP : 1, AN_SUP : 0, AO_SUP : 1 status code : 0x00 vendor unique status : 0x00 target port count : 10 Relative target port ids: 0x3f3 0x3f4 0x3fd 0x3fe 0x457 0x458 0x461 0x462 0x4bb 0x4bc 0x4c5 0x4c6 0x51f 0x520 0x529 0x52a Report target port groups: target port group id : 0x101 , Pref=1 target port group asymmetric access state : 0x00 T_SUP : 1, O_SUP : 0, LBD_SUP : 0, U_SUP : 1, S_SUP : 1, AN_SUP : 0, AO_SUP : 1 status code : 0x00 vendor unique status : 0x00 target port count : 14 Relative target port ids: 0x3f3 0x3f4 0x3fd 0x3fe 0x3ff 0x457 0x458 0x461 0x462 0x464 0x4bb 0x4bc 0x4c5 0x4c6 0x4c7 0x51f 0x520 0x529 0x52a 0x52c target port group id : 0x102 , Pref=0 target port group asymmetric access state : 0x02 T_SUP : 1, O_SUP : 0, LBD_SUP : 0, U_SUP : 1, S_SUP : 1, AN_SUP : 0, AO_SUP : 1 status code : 0x00 vendor unique status : 0x00 target port count : 10 Relative target port ids: 0x7db 0x7dc 0x7e5 0x7e6 0x83f 0x840 0x849 0x84a 0x8a3 0x8a4 0x8ad 0x8ae 0x907 0x908 0x911 0x912 Report target port groups: target port group id : 0x101 , Pref=1 target port group asymmetric access state : 0x00 T_SUP : 1, O_SUP : 0, LBD_SUP : 0, U_SUP : 1, S_SUP : 1, AN_SUP : 0, AO_SUP : 1 status code : 0x00 vendor unique status : 0x00 target port count : 14 Relative target port ids: 0x3f3 0x3f4 0x3fd 0x3fe 0x3ff 0x457 0x458 0x461 0x462 0x464 0x4bb 0x4bc 0x4c5 0x4c6 0x4c7 0x51f 0x520 0x529 0x52a 0x52c target port group id : 0x102 , Pref=0 target port group asymmetric access state : 0x02 T_SUP : 1, O_SUP : 0, LBD_SUP : 0, U_SUP : 1, S_SUP : 1, AN_SUP : 0, AO_SUP : 1 status code : 0x00 vendor unique status : 0x00 target port count : 10 Relative target port ids: 0x7db 0x7dc 0x7e5 0x7e6 0x83f 0x840 0x849 0x84a 0x8a3 0x8a4 0x8ad 0x8ae 0x907 0x908 0x911 0x912 Cheers, Thomas ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-09-24 7:10 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-09-11 12:58 3PAR transparent failover with Linux Thomas Glanzmann 2014-09-23 22:11 ` Sebastian Herbszt 2014-09-24 3:32 ` Thomas Glanzmann 2014-09-24 7:10 ` Thomas Glanzmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.