New on SAN

[Co van Berkel]

Hi,
We run on two rp4440-2 HP-UX 11.11 (v1) with MC/SG 11.16 in a cluster.

We are connected to a SAN:
- IBM DS4800 (SAN)
- SATA disks
- Cisco MDS 9216i (switch)
- HP A6795A Fibre Channel PCI XL2 Adapter

I am new to a san, so we have a question.

a. We installed on the two clusternodes, per node, two FC HBA's;
b. Configured them on the SAN;
c. Then there is a LUN created;
d. insf -e (discoverd the FC HBA's and LUN)
e. Create a VG (LVM).

Now we see on node-1:
- /dev/dsk/c12t0d0 (pri)
- /dev/dsk/c16t0d0 (alt).

Now we see on node-2:
- /dev/dsk/c12t0d0 (pri)
- /dev/dsk/c15t0d0 (alt).

QEUSTION:
How to keep all disk device files, of a VG using a SAN LUN, equal on all nodes in a cluster?

Is there a "best practice" solution?

Regards,
CvB

[Steven E. Protter · Accepted solution]

Shalom,

insf -C disk
discovers disk.

If you want th pathes to be the same the HBA needs to be in the same slot with the same scsi id, though on older scsi this could make problems fo rhte shared storage.

The device files do not need to be equal.

If you want them to be equal,you will need to follow the guidelines above and renumber hardware instance, which is a bit dangerous.


http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=726164
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1033544
SEP

[Calandrello]

Friend the CTD of records (/dev/dsk/cxtxxxx) exactly does not need to be, therefore the record is the same. so and necessario that you import and export the VG in node 2 with the command vgexport -s -p -m vgname.map /dev/vgxxx and imports with the command vgimport -s -m vgname.map /dev/vgxxx

[Co van Berkel]

Hey,

What to do as in the /etc/lvmtab the pri and alt disk's are not in the same order on all nodes?

In "man vgimport" they say:
"Do a vgreduce and than a vgextend.
But this can't be done without having the VG connected in RW mode.

How to do this, in a MCSG configuration of two nodes, on the node where the VG in NOT active?

Regards,
CvB.

[Calandrello]

Friend
follows all the steps to create vgs and to configure in the SG in first node executes: to mkdir /dev/vgxx mknod /dev/vgxx/group c 64 0x00001 vgcreate /dev/vgxxx /dev/dsk/cxtxxxx vgexport -s -p -m /tmp/vgxx.map /dev/vgxxx RCP -rp /tmp/vgxx.map node2: /tmp in node2 it executes the following commands: to mkdir /dev/vgxx
mknod /dev/vgxx/group 0x00001 c 64
vgimport -s -m /tmp/vgxx.map /dev/vgxx
it configures scripts of the package to mount and to disassemble they filesystem them

[Co van Berkel]

Hey,

Yep, that's what we do for some years already, BUT...

The order of the /dev/dsk/cxtxdx devices in the /etc/lvmtab differs between the two nodes.

Because the order of the devices are random after the â vgimportâ ?

This can be a problem if the alternate device is first in order than the primary device in the case of a SAN lun?
Right or not right?

Regards,
CvB.

[Calandrello]

Friend
this not and a problem therefore in the record this marked the area of VGRA that marks which VG the record belongs. then the CDT does not matter to be different

[Ermin Borovac]

To keep primary/alternate paths in the same order you can either:

Use vgexport/vgimport with -f option.

OR

Simply specify PV paths on the command line to vgimport (you only have two PVs).

There is no need to use vgexport/vgimport -s option.

Once you import the volume group on the adoptive node you can activate it in read-only mode and check that PV paths are in the right order.

# vgchange -a r
# vgdisplay -v
# vgcfgbackup
# vgchange -a n

[Co van Berkel]

Many thanks for all the info.

I know now how to handle.

Regards,
CvB.