hba and vg configuration

[Ignacio Javier]

Hello everybody:

I have a two node cluster HP.UX 11.23 with SG11.16.
The situiation right now is that every node acess a EMC disc cabinet by an unique hba.

I have configured and distributed my volumen groups this way:

/dev/vg_desa
/dev/dsk/c5t1d0
/dev/dsk/c5t2d0
/dev/vg_inte
/dev/dsk/c5t1d1
/dev/dsk/c5t2d1
/dev/vg_expl
/dev/dsk/c5t1d2
/dev/dsk/c5t2d2
/dev/vg_pruebas
/dev/dsk/c5t1d3
/dev/dsk/c5t2d3

This disks are EMC LUN´s.

The SAN team has configured a switch and the cabinet, so the luns are visible by another hba that i have on my nodes.

Actually, it was done some time ago and i could see the luns with ioscan. Before this i had a patch problem and now i am in the same point i was some time ago.

So, the question is that i am not sure what steps do i have to do to configure Serviceguard correctly.

I know that when i conect the fc cabel and see the luns with ioscan, i have to make a insf -e to create de dispositive files.

I am not sure if i have to include this dispositives in the same volume groups the other dispositive were in.

Finally i will install EMC´s powerpath to control the alternate links.

Sorry becouse of the extension

Thans in advance

[Steven E. Protter]

Shalom,

No insf -e didn't create device files for disks.

insf -C disk

or a system boot which runs the same command did the job.

What needs to happen is that the LUNs need to be assigned to the WWN, World Wide Name of the new HBA cards, ioscan and insf -C be run.

Better yet a system boot if posible.

After that the process is standard, pvcreate, extend a volume group or create a volume group, vanailla LVM.

SEP

[Stephen Doud · Accepted solution]

Duplicate paths to a LUN is a good thing - it eliminates a single point of failure.
After attaching the alternate HBA to the SAN switch (which should be a second switch, for redundancy), do 'insf -e' to create the additional special files for the new path to the LUN(s). Then add the new paths to the /etc/lvmtab file using (example): "vgextend /dev/vg_expl /dev/dsk/c7t1d2 /dev/dsk/c7t2d2".
Create an LVM map file of the VG
# vgexport -pvs -m map.vg_expl /dev/vg_expl
# rcp map.vg_expl :/etc/lvmconf

On the othernode:
# mkdir /dev/vg_expl
# mknod /dev/vg_expl/group c 64 0x0N0000 (where N is a unique minor number compared to the other VGs' group minor numbers)
# vgimport -vs -m /etc/lvmconf/map.vg_expl /dev/vg_expl

On either host:
# strings /etc/vg_expl == should show now all paths to the LUN

[Ignacio Javier]

Ok thanks a lot.

I will proceed that way...but...

When i do a ioscan -fnkC disk and I get all the special files, how do i know the ones that are accessing the same LUN ? i ask this to do the vgextend comand correctly..

My ioscan -fnkC disk result:

disk 3 0/2/1/0.5.12.0.0.0.0 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t0d0 /dev/rdsk/c5t0d0
disk 4 0/2/1/0.5.12.0.0.0.1 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t0d1 /dev/rdsk/c5t0d1
disk 5 0/2/1/0.5.12.0.0.1.0 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t1d0 /dev/rdsk/c5t1d0
disk 6 0/2/1/0.5.12.0.0.1.1 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t1d1 /dev/rdsk/c5t1d1
disk 7 0/2/1/0.5.12.0.0.1.2 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t1d2 /dev/rdsk/c5t1d2
disk 8 0/2/1/0.5.12.0.0.1.3 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t1d3 /dev/rdsk/c5t1d3
disk 9 0/2/1/0.5.12.0.0.1.4 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t1d4 /dev/rdsk/c5t1d4
disk 10 0/2/1/0.5.12.0.0.1.6 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t1d6 /dev/rdsk/c5t1d6
disk 11 0/2/1/0.5.12.0.0.1.7 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t1d7 /dev/rdsk/c5t1d7
disk 12 0/2/1/0.5.12.0.0.2.0 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t2d0 /dev/rdsk/c5t2d0
disk 13 0/2/1/0.5.12.0.0.2.1 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t2d1 /dev/rdsk/c5t2d1
disk 14 0/2/1/0.5.12.0.0.2.2 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t2d2 /dev/rdsk/c5t2d2
disk 15 0/2/1/0.5.12.0.0.2.3 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c5t2d3 /dev/rdsk/c5t2d3
disk 16 0/2/1/1.6.12.0.0.0.0 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0
disk 17 0/2/1/1.6.12.0.0.1.0 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c6t1d0 /dev/rdsk/c6t1d0
disk 18 0/2/1/1.6.12.0.0.1.1 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c6t1d1 /dev/rdsk/c6t1d1
disk 19 0/2/1/1.6.12.0.0.1.2 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c6t1d2 /dev/rdsk/c6t1d2
disk 20 0/2/1/1.6.12.0.0.1.3 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c6t1d3 /dev/rdsk/c6t1d3
disk 21 0/2/1/1.6.12.0.0.1.4 sdisk CLAIMED DEVICE EMC SYMMETRIX
/dev/dsk/c6t1d4 /dev/rdsk/c6t1d4
disk 22 0/2/1/1.6.12.0.0.1.6 sdisk CLAIMED DEVICE EMC SYMMETRIX



My lvmtab file:


/dev/vg_desa
/dev/dsk/c5t1d0
/dev/dsk/c5t2d0
/dev/vg_inte
/dev/dsk/c5t1d1
/dev/dsk/c5t2d1
/dev/vg_expl
/dev/dsk/c5t1d2
/dev/dsk/c5t2d2
/dev/vg_pruebas
/dev/dsk/c5t1d3
/dev/dsk/c5t2d3

should i guess that /dev/dsk/c6t1d0 is accesing the same lun c5t1d0 is ?

Thanks everybody

[CAS_2]

If c6t1d0 is an alternate path to c5t1d0, LVM will recognize instantly.

Run the vgextend command. If one of the new PVs is not an alternate link, vgextend will complain because it scans the LVM header of the new PVs and do some checks before accept them.

[CAS_2]

The right procedure is using "syminq" or "inq" EMC tool.