alternate link on Service Guard using SC 10 and multifunction card

[Ricky_4]

We are wondering once we transferred the package from the adoptive node and verified the its primary link path, the adoptive node is always used the primary link path of primary node as the alternate link. By the way, we used alternate link on SC10 and multifunction card(dual PCI100bt TX and dual SCSI port) on a two-node cluster under Service Guard 11.12. How do we resolve that the primary link should always be the same between the primary and adoptive node?

For additional info:
vgdisplay from primary node
# vgdisplay -v vgdb | grep Link
PV Name /dev/dsk/c4t0d0 Alternate Link
PV Name /dev/dsk/c4t1d0 Alternate Link
PV Name /dev/dsk/c4t2d0 Alternate Link
PV Name /dev/dsk/c4t3d0 Alternate Link
PV Name /dev/dsk/c4t8d0 Alternate Link
PV Name /dev/dsk/c4t9d0 Alternate Link
PV Name /dev/dsk/c4t10d0 Alternate Link
PV Name /dev/dsk/c4t11d0 Alternate Link

vgdisplay after we transferred the package going to adoptive node
# vgdisplay -v vgdb | grep Link
PV Name /dev/dsk/c7t0d0 Alternate Link
PV Name /dev/dsk/c7t1d0 Alternate Link
PV Name /dev/dsk/c7t2d0 Alternate Link
PV Name /dev/dsk/c7t3d0 Alternate Link
PV Name /dev/dsk/c7t8d0 Alternate Link
PV Name /dev/dsk/c7t9d0 Alternate Link
PV Name /dev/dsk/c7t10d0 Alternate Link
PV Name /dev/dsk/c7t11d0 Alternate Link

[Carsten Krege]

The order of primary and alternate links is determined by the order used to add the disks to the lvmtab.

If you use

# vgcreate /dev/vgXX /dev/dsk/ /dev/dsk/

the order will be correct on creating a new VG. Similarly you can do this on vgimport:

# vgimport /dev/vgXX /dev/dsk/ /dev/dsk/

Use the vgimport command if the VG is not activated on the server, ie. the package is running on the other node.

If the order of primary and alternate is wrong and the VG is activated do the following:

# vgreduce /dev/vgXX /dev/dsk/

The pvlink left over in the VG, now becomes automatically the primary link. Now you readd the alternate link:

# vgextend /dev/vgXX /dev/dsk/

In your example do the following on the adoptive node (when VG is activated, otherwise reimport the VG):

primary link: c7t0d0
alternate link: c4t0d0

# vgreduce /dev/vgdb /dev/dsk/c4t0d0
Now c7t0d0 is configured as primary link.
# vgextend /dev/vgdb /dev/dsk/c4t0d0
Now c4t0d0 is readded as alternate link.


Please note that the device file names on the nodes can differ, ie. c4t0d0 is not necessarily the same disk/pvlink on both nodes.


Carsten

[Mark van Hassel]

Hi,

It depends on how you imported the vg on the adoptive node:

vgimport -v -s [vgname] [pvname1] [pvname1'] [pvname2'] [pvname2] ....

The order of the pv's is the key to which pv is primary and which alternate. The pv first specified will be the primary link.

Also, when the vg is active on your adoptive node you can use vgreduce and vgextend to swap the links around:

vgreduce [vgname] [pvname1]
vgextend [vgname] [pvname1]

This results in [pvname1'] as primary and [pvname1] as alternate path.

[Varghese Mathew]

Hi,

You need to give in the specific device names(PV links) in the order whe you use the vgimport command in shared mode in the adoptive node like the first the PV link will act as the primary path, the second as the alternate/second path so on..

So you need to work around your current setup , like a total vg reorg. is required in the adoptive node. You can vgreduce/vgexport then do the vgextend/vgimport after that. Then get a new cluster configuration file, check for any errors, if any correct the same and then apply ..over all the nodes.

Thats it..

Hope this helps
Cheers !!!
Mathew