* 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.