PVlinks

[Paul Masse]

Has anyone seen a white paper or other documentation that describes the functionality of alternate paths in HP/UX 11.00? I am expecially interested in the expected behavior when the primary path fails. After the paths switch, does LVM
monitor the failed path and restore the original configuration when the problem has been resolved? Is there a threshold that can be set to "give up" after a defined number of retries? Thanks in advance ...

[Antoanetta Naghiu]

Hi,
See: http://www.unixsolutions.hp.com/hpsapwp.html

[Brian M. Fisher]

The information I found regarding alternate links can be found at:

http://docs.hp.com/dynaweb/hpux11/@Generic__CollectionView

and doing a search on alternate links.

I hope this helps,
Brian
<*(((>< er

[Anthony deRito]

The below example is from n earlier post to a question regarding alternate links on a Model 20 NIKE array. If your using HP-UX 11..0 and SP256 array, you will still find some usefull info....

The following example is for a Model 20 with 2 SPs installed and four LUNs configured into 4 RAID 5 groups.

LUN 0,1 bound to SPA at 2/44.5
LUN 2,3 bound to SPB at 2/52.6

We also have one volume group /dev/vg08 on LUN 0 with a filesystem on it for testing.
We have also applied all disk,LVM... patches

1. Make sure autotraspassing is on:

Make sure you have the most recent firmware for your NIKE. Call the Response Center to verify. You will see the current version on the top of the Presentation Screen of Grid Manager.
GO to FE mode by holding doen the Ctrl key and pressing the p key then hold down the Shift key while typing in fe.
From the main menu, select 5) Change Parameters -> 2) Change Storage System Parameters > 5) Select Storage System Options Package. Make sure current type is set to "2". If it set to "A" autotraspass is not available. Change it to "2". The SP needs to reboot.

2) Run ioscan -nfH on each path and check that 4 device files are created for each path. If autotraspass was not turned on, you would only see 2 devices file for each SP. (Only part of output shown below...)

ioscan -nfH 2/44.5

2/44.5.0 /dev/dsk/c7t5d0
2/44.5.1 /dev/dsk/c7t5d1
2/44.5.2 /dev/dsk/c7t5d2
2/44.5.3 /dev/dsk/c7t5d3

ioscan -nfH 2/52.6

2/52.6.0 /dev/dsk/c8t6d0
2/52.6.1 /dev/dsk/c8t6d1
2/52.6.2 /dev/dsk/c8t6d2
2/52.6.3 /dev/dsk/c8t6d3

4) Lets run vgdisplay to verify the configuration of vg08

--- Physical volumes ---
PV name /dev/dsk/c7t5d0
PV Status available
Total PE 1988
Free PE 1988

5) Lets create our alternate link:

vgextend /dev/vg08 /dev/dsk/c8t6d0

Notice we use the "d0" device file for the opposite path.

6) Lets run vgdisplay again

--- Physical volumes ---
PV Name /dev/dsk/c7t5d0
PV name /dev/dsk/c8t6d0 Alternate Link
PV Status available
Total PE 1988
Free PE 1988

Notice how the alternate link is shown nicely by vgdisplay.

7) test your failover easily by throwing the switch on the back of the SPA to "disable". Perform some I/O on the filesystem. Watch the console for switch information. It will look something like:

"LVM: Performed a switch for Lun ID = 1 (pv = 0x648d000), from raw device 0x1c056100 (with priority: 0, and current flags: 0x240) to raw device 0x1c065100
(with priority: 1, and current flags: 0x0)."

Enable the SP again by turning the switch back on. Watch the console for another switch command like:
"vmunix: LVM: PV n has been returned to vg[n]"


8) Do the same above steps for all other volume groups on LUN 1, 2 and 3.

9) Make sure if you go into FE mode, get out when you are done! To get out, press and hold Ctrl key then press p key. Then press and hold shift key and type user.

Good luck!

Tony

[Anthony Goonetilleke]

The switching back from a primary link failure depends on how you initially set it up. Here is a small extract from a ITRC doc that explains it quite well

"If the primary failed LVM would switch to the first alternate.
With the default -S autoswitchback setting, LVM would keep on polling the primary until it returned and switch back. With -S n it would stay on the first alternate. Should the primary and first alternate both fail then the second alternate would be used. Because the decision on link ordering is based upon the order of the PV names in the lvmtab file, then on reboot or full re-activation the ordering will be reinstated. This can be changed by using vgreduce/vgextend."

[Stefan Farrelly]

The value which controls trespassing (switching to the alternate PV link) is the "IO Timeout (seconds)" as shown on an lvdisplay command. The question is what is this value ? Eventually we got Cupertino to reply that this value is hardcoded in the SCSI driver code, its 30 seconds and you cant change it (at present).

So, after 30 seconds of no response from a device LVM will attempt to switch to the alternate link, if available. Once this happens (trespassed) it will stay using the alternate path until the server is rebooted. If in the meantime you fix the problem with the original path (ie. fix a Nike controller problem) then you can attempt to manually switch the link back to the primary using the pvchange -S command.

Actually, you can also cause a trespass by absolutely flooding the devices with several dd commands (sending output to /dev/null) this will cause such a queue on the IO channel (and eventually an IO timeout) that it should force LVM to switch to the alternate path. Weve managed to do this with Nike disks no problem.