LVM using PVLINKs even if AutoPath is installed (EVA arrays) ! This Good?

[Alzhy]

I was brought to an environment to check out their configs and all. An extensive 11.23 and EVA storage back end ecosystem.

I notice AutoPath (aka SecurePath for A/A arrays) is installed BUT it seems the admin opted to use PVLINKs in the LVM configuration?

There are AutoPath Virtual devices i.e. /hpap/dsk/hpapNNN established.

I am wondering whether the AutoPath devices was the better and correct approach instead of PVLINKS?

I've used AutoPath for the XP and EVA disk arrays before but I've opted to use instead VxVM DMP (and in 11.31 the built in MPxIO)... So I am wondering if this config is proper?

Many thanks in advance!

[Henry Fauni · Accepted solution]

It's possible that previous admin might still be using AutoPath device files. If the virtual device file and primary path major/minor numbers of device files are the same, then you're using autopath.

# ll /dev/dsk/c23t1d0
brw-r----- 1 bin sys 31 0x171000 Dec 18 10:19 /dev/dsk/c23t1d0
root@oradev03:/
# ll /hpap/dsk/hpap168
brw------- 1 root sys 31 0x171000 May 25 23:23 /hpap/dsk/hpap168

Partial portion of "autopath display" shown below:

==================================================================
Lun WWN : 6005-08B4-0010-5228-0001-0000-03F6-0000
Virtual Device File : /hpap/dsk/hpap168
Load Balancing Policy : Shortest Service Time
Lun Timeout : Infinite Retry (-1)
==================================================================
Device Path Status
==================================================================
/dev/dsk/c23t1d0 Active
/dev/dsk/c25t1d0 Active
/dev/dsk/c28t1d0 Active
/dev/dsk/c30t1d0 Active

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

The first Device Path entry is the AutoPath device file to use!

It doesn't hurt to configure additional alternate paths, as long as you configure the AutoPath device file as the primary path.

Below are the available Load Balancing policies available:

# autopath set_lbpolicy -?
description : set load balancing policy

usage:
autopath set_lbpolicy < {policy name} {path} >

Policy name: The load balancing policy to set
Valid policies are
RR : Round Robin.
SST : Shortest Service Time.
SQL : Shortest Queue Length.
NLB/OFF : No load Balancing.
Path: Device Special File e.g./dev/dsk/c#t#d#

Yes, if you have the AutoPath software available and you do not have VxVM DMP, then why not use it? It's a lot easier to manage multipathing.

[Alzhy]

Graci.

So I could also have used /hpap/(r)dsk/hpap168 as my PV path right? And set LB policy? Just like /dev/dm-N on Linux device mapper configured native multi-pathing?

Thanks again.

N.

[Sagar Sirdesai]

Hi
I would always prefer to configure autopath provide high availibilty and load balancing.

The PVlinks will only provide you HA and that also needs a manual intervention with a possibility of delay in availibilty of data.

autopath will do HA and load balancing tranparently

Sagar

[Basheer_2]

Hello Dear,

We do have PVlinks configured not Auto PATH.
the reason was to save money on the secure path.

Sagar is correct. Since you have XP, which is an active-active and gives Load balance.

[Duncan Edmonstone]

> So I could also have used /hpap/(r)dsk/hpap168 as my PV path right? And set LB policy? Just like /dev/dm-N on Linux device mapper configured native multi-pathing?

No you can't do that. The singkle virtual device path is for specific applications like Oracle ASM which need this.

For LVM you should continue to use the standard DSFs under /dev. This is made quite explicit in the manual:

http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c01683918/c01683918.pdf

See p95

As far as PVlinks are concerned, you certainly should configure them for boot volumes if you are booting off SAN, otherwise its up to you. I think it helps to track the DSFs better and makes it easier for other admins to see what's going on, even if they don't know about Secure Path - but it won't really do anything except for boot volumes.

HTH

Duncan

[Alzhy]

Duncan,

Wow, so if AutoPath is installed - I should use the primary path listed in "autpath display" *and* still add the other paths as PV Links/Aletrnate Paths?

And I can only use /dev/rdsk/hpapNN devices under RAW device usage (for instance ASM under Oracle?)

BTW, what about LVM Raw devices under LVM in the same way as VxVM Raw Volumes -- are those supported as ASM devices?


Under VxVM -- the rule is that each VOL that will be used as ASM device shall be wholly contained on a phyiscal LUN (not stiped or concatenated). I wonder is the same is applicable to LVM Raw Volumes that are wholly contained on sigle PVs.

Say:

/dev/vg_db12345/rasmvol01 -- on PV c1t1d0
/dev/vg_db12345/rasmvol02 -- on PV c1t2d0
.. and so on

and the ASM disk string would be /dev/vg_db12345/rasm*


Thanks.

[Duncan Edmonstone]

> Wow, so if AutoPath is installed - I should use the primary path listed in "autopath display" *and* still add the other paths as PV Links/Aletrnate Paths?

You can use any of the physical paths listed in "autopath display", just not the virtual one. Whether you add the alternate path to your VG is entirely up to you - no real need to as SP will still load balance across all available paths even if you add only one. (The exception to this of course is boot LUNs.) As I said, it does no harm to add them though and makes things clearer to the "casual observer sysadmin" to see whats going on, so why not?

> And I can only use /dev/rdsk/hpapNN devices under RAW device usage (for instance ASM under Oracle?)

Yes - in fact ASM and Syabase raw devs is the only time I've seen the /hpap devices used.

> BTW, what about LVM Raw devices under LVM in the same way as VxVM Raw Volumes -- are those supported as ASM devices?

Well yeah, but the only thing you get out of that is path resiliency. My first recommendation to anyone using ASM would be "use 11iv3 or use MPIO software like Secure Path or Power Path" (actually my *real* first recommendation would be "don't use ASM"!) Adding LVM or VxVM in there I think just complicates things (I know you have different opinions on that).

You can also get some "sticky" situations where ASM won't close all the open file descriptors on an ASM disk group even when you've asked it to close and disconnect it. This makes using ASM with LVM or VxVM paricularly difficult in failover clusters (not RAC clusters which behave slightly differently) - I've seen situations where ASM has apparently taken offline a disk group, but the VGs won't deactivate as it in fact still has file descriptors open - it happens with raw devices as well, but is less of a problem as there is not VG to deactivate/deport.

HTH

Duncan

[Henry Fauni]

"Wow, so if AutoPath is installed - I should use the primary path listed in "autpath display" *and* still add the other paths as PV Links/Aletrnate Paths?"

Let me just answer this one for Duncan. Yes, use the first Device path listed in "autopath display" as your LVM primary path in order to take advantage of the AutoPath policy you have set. You can verify you're using the correct one, by comparing major/minor numbers of the device file with the virtual device file as I have described in my earlier response. Adding LVM alternate paths doesn't hurt. In case of problems with AutoPath, you still have the native LVM pvlinks to fall back on. Just make sure you use the correct device file as primary path.

[Matthew Darcy_2]

this has been a fatastic thread for me - very very interesting. Thank you.

[Michael Steele_2]

HI

I do it for tracking free disks.

I have made mistakes in the past of re-adding already used alternates by extending vg's with these already used luns. Power Path or Auto Path won't update /etc/lvmtab, so these alternates don't show up in vgdisplay. And although SAM gives the correct status of used and free, I rely on scripts to check systems with a hundred luns and they are written to check /etc/lvmtab or vgdisplay.