Autopath (active/active SecurePath) and path failover

[Bryan Rooney]

- HP-UX (ia64) 12.23 Sept 2006 patch level
- Oracle 10.2.0.2 DB/ASM (over raw HP EVA 8000 LUN) w/ Failover Groups
- Device multipath software: HP Autopath (Active/Active SecurePath)

We presented an application (Oracle ASM) with mknods of the lead device paths handled by Autopath. Failover for those mknods did not work as Autopath only fails over the specific devices it is aware of. We found this out the hard way when we had a SAN hardware failure and lost half our paths and pathing failover did not occur.
Has anyone had success with assigning the application the lead Autopath device path or assigning the virtual device (/dev/rdsk/hpap). I've heard from one other that even supplying the lead device path did not work for HP's CFS.
Maybe we should only be using the virtual (hpap)?
Also, if Autopath only handles the devices it shows in its display command, does that mean that it will only handle the dsk and not the rdsk (rdsk is not displayed in display )?command

Thanks for any insight that can be provided,

Bryan

[TwoProc]

I don't have/use Autopath, but I always that that all it did was provide the best path from the alternates to deliver data. You still had to provide all of the alternates to Autopath for it to choose from. Otherwise, you would just be autopathing the one path.

But - I don't use it, and the doc I read up on it was years ago, and not even for your version of the OS, but an older one. So my info I'm giving is only an old opinion. Some more information from folks actually using it with newer OSs would be a better point of reference.

[Bryan Rooney]

Here is an example of the 16 active paths we're running per SAN LUN:

============================================
Lun WWN : 6005-08B4-0010-5378-0000-A000-007A-0000
Virtual Device File : /hpap/dsk/hpap6
Load Balancing Policy : Shortest Queue Length
Lun Timeout : Infinite Retry (-1)
============================================
Device Path Status
============================================
/dev/dsk/c16t0d7 Active
/dev/dsk/c18t0d7 Active
/dev/dsk/c26t0d7 Active
/dev/dsk/c28t0d7 Active
/dev/dsk/c130t0d7 Active
/dev/dsk/c53t0d7 Active
/dev/dsk/c55t0d7 Active
/dev/dsk/c65t0d7 Active
/dev/dsk/c67t0d7 Active
/dev/dsk/c92t0d7 Active
/dev/dsk/c94t0d7 Active
/dev/dsk/c100t0d7 Active
/dev/dsk/c102t0d7 Active
/dev/dsk/c128t0d7 Active
/dev/dsk/c136t0d7 Active
/dev/dsk/c138t0d7 Active

============================================

Basically, we've beem told to use the lead device (/dev/dsk/c16t0d7) by HP/Oracle CTC group and HP Support has said to use the virtual device only (/hpap/dsk/hpap6).
I'm hoping someone has flushed this out in real life to find out what really works.
I'm hoping to get our staging environment setup to test this out for certain, but it will be much later than sooner, unfortunately.

Bryan

[Eric SAUBIGNAC]

Bonsoir Bryan,


which version of autopath do you use (swlist HPswsp). It should be, no, it must be A.3.0F.02F.02F.

<<< Also, if Autopath only handles the devices it shows in its display command, does that mean that it will only handle the dsk and not the rdsk (rdsk is not displayed in display )?command >>>

With lower version of Secure path (that is autopath when you install active/active) I had problem with rdsk : autopath did not handle correctly the failing of the path you are working one. It was in an HP Integrity VM context where rdsk, not dsk, are presented to a Virtual Machine. Should you loose the correspondig path of the rdsk presented to the VM and the VM was hanging.

As far as I know, Oracle ASM works with rdsk, not dsk. So I think that you are simply facing this problem. You will find updates at http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=1825336&prodTypeId=18964&prodSeriesId=471465&swLang=8&taskId=135&swEnvOID=7

If the version of Securepath is not the problem and if renaming special file name is just to have a more "comfortable" way of working, you can also create symbolic links to the true rdsk device. It works well with ASM (I am not DBA :-( but some said).

Ho, I just think to this : what about "autopath display" ? I guess it is OK and every devices are shown. If not, that could also be the source of the problem. With older version, after a reboot you had to issue a "autopath discover" command to have disks handled by autopath. With the latest, just have to do "autopath discover ON" and after a reboot all disks are handled by autopath.

Tell us ...

Hope this will help

Regards

Eric

[Bryan Rooney]

Eric -
Thank you for your the reply:

"Which version of autopath do you use (swlist HPswsp). It should be, no, it must be A.3.0F.02F.02F."

Yes, we are using Autopath SP2 (2F.2F).

Does 2F.2F resolve the dsk verses rdsk issue for Autopath?

Thanks,
Bryan

[Eric SAUBIGNAC · Accepted solution]

Yes Bryan, it does in a VM context where Virtual Disks are raw devices (rdsk).

And it also works in a context where one of my client has an ASM database configured with raw devices from an EVA 4000 with autopath configured. So I guess it should also works for you

I did a little test for you :

---> autopath display :

==================================================================
HPswsp Version : A.3.0F.02F.02F
==================================================================
Auto Discover : ON
==================================================================
Array Type : EVA-AA
Array WWN : 5000-1FE1-5004-2650
Read Optimize : ON
Path Verification Period : 00:10
==================================================================
Lun WWN : 6005-08B4-0010-2499-0002-3000-01C7-0000
Virtual Device File : /hpap/dsk/hpap0
Load Balancing Policy : Shortest Service Time
Lun Timeout : Infinite Retry (-1)
==================================================================
Device Path Status
==================================================================
/dev/dsk/c4t0d1 Active
/dev/dsk/c6t0d1 Active
/dev/dsk/c8t0d1 Active
/dev/dsk/c10t0d1 Active

==================================================================

---> then I have disconnected one HBA :

/dev/dsk/c4t0d1 Failed
/dev/dsk/c6t0d1 Failed
/dev/dsk/c8t0d1 Active
/dev/dsk/c10t0d1 Active

---> then I have created a special file with a weak name "toto" and same major/minor than c6t0d1. So since c6t0d1 is failed, toto is also failed :

sdisk card instance 4 SCSI target 0 SCSI LUN 1 section 0 at address 0/2/1/0.21.0.0.0.0.1 /dev/rdsk/c4t0d1
sdisk card instance 6 SCSI target 0 SCSI LUN 1 section 0 at address 0/2/1/0.21.1.0.0.0.1 /dev/rdsk/c6t0d1
sdisk card instance 6 SCSI target 0 SCSI LUN 1 section 0 at address 0/2/1/0.21.1.0.0.0.1 /dev/rdsk/toto
sdisk card instance 8 SCSI target 0 SCSI LUN 1 section 0 at address 0/5/1/0.11.0.0.0.0.1 /dev/rdsk/c8t0d1
sdisk card instance 10 SCSI target 0 SCSI LUN 1 section 0 at address 0/5/1/0.11.1.0.0.0.1 /dev/rdsk/c10t0d1

crw-r----- 1 bin sys 188 0x040100 Dec 17 15:55 /dev/rdsk/c4t0d1
crw-r----- 1 bin sys 188 0x060100 Dec 17 15:43 /dev/rdsk/c6t0d1
crw-rw-rw- 1 orasm0 dba 188 0x060100 Jan 28 11:05 /dev/rdsk/toto
crw-r----- 1 bin sys 188 0x080100 Dec 17 15:43 /dev/rdsk/c8t0d1
crw-r----- 1 bin sys 188 0x0a0100 Dec 17 15:43 /dev/rdsk/c10t0d1

- Finally I have copied 1 Gb from /dev/rdsk/toto to a temporary file without problem :

dd if=/dev/rdsk/toto of=/tmp/esc bs=1024k count=1000
1000+0 records in
1000+0 records out

In conclusion you can see that autopath handles correctly failover on a raw device even if it has not a "normal" name.

Regards

Eric

[Bryan Rooney]

We are moving to use of the /hpap/rdsk virtual devices for our ASM installs, instead of the lead autopath device /dev/rdsk.
We have not had success with using rdsk lead devices with ASM as we have lost LUNs during path failover. We did HBA disable/disconnect tests against the hpap virtual devices and path failover has been successful. However, we cannot use the hpap virtual devices for our LVM VG's that use SAN disk. The vgimport command will not let us use the /hpap/dsk pathing:

# vgimport -m /etc/lvmconf/vgora.mapfile -v vgora /hpap/dsk/hpap7
vgimport: Illegal path "/hpap/dsk/hpap7"

So we'll have to stick with the lead paths for LVM VG's. Maybe LVM is not as sensative as ASM to path failover.