Device files , SAN

[jpcast_real]

Hello Gurus,

I have 2 SANs configured in my HP-UX Serviceguard Cluster . Due to a power failure all the storageworks SAN switches were rebooted and also the HP-UX server . The HP-UX had problems during the startup and when finally everything was up , all the device files of the disks had changed . Two questions.

- how to restore this situation faster than making vgimport

- How to avoid that this happens again

Thanks for all

[Alzhy]

- how to restore this situation faster than making vgimport

ANS: vgimport is the only faster way I know

- How to avoid that this happens again

ANS: switch to VxVM as it is fully resilient in HW path changes

[Duncan Edmonstone]

Javier,

HP disk device file names are generated from hardware paths, which in turn are generated from FCID numbers in the SAN. If your device files have changed that's cos your hardware paths have changed, which in turn is because something in the SAN has changed...

On B series Brocade switches (and I think M series McData switches) the FCID is based on i) the domain ID of the switch, and ii) the port that the storage is plugged into. On C series Cisco switches by default the FCID is also based on the domain ID, but the rest of the FCID is assigned in much the same way as a DHCP IP address (first port logged in after reboot gets 01, next gets 02 etc.) so it can change - this configuration can be overridden to force persistent FCIDs.

So the question is:

a) what type of switch do you have?
b) what changed?

Whilst moving to VxVM would certainly mask the problem, it could potentially bite you again (when the internal tables that track hardware paths in the ioconfig files fill up). Also VxVM doesn't help with SAN attached tape drives...

HTH

Duncan

[jpcast_real]

Hello Duncan ,

I have an HP Storageworks 2/8 SAN Switch. I am really intereted in knowing how to fix the FCID of the different devices of the SAN . We suffer very often power outgages and the HP-UX server rebuilds the device files , making all the volume groups impossible to access . This situation is not affordable in a critical environment and I must solve it as fast as possible.

Thanks for your help.

[Uwe Zessin]

As far as I know, that switch does not provide FCID persistence - it is always a product of the switch's domain ID, the port number and the AL_PA (for public loop attachment). I am really surprised to hear that the device paths have changed. Can you provide an example of an old and a new path, please?

[jpcast_real]

Hello ,

I have a two cluster node . This change in the device file has just happened in one on the nodes , the other remains the same . I have two different SANS
-SAN IDs 1 and 4
-SAN IDs 2 and 3

You can see below the difference in the device files



OLD IOSCAN

disk 3 0/8/0/0.2.4.0.0.0.0 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c4t0d0 /dev/rdsk/c4t0d0
disk 4 0/8/0/0.2.4.0.0.0.1 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c4t0d1 /dev/rdsk/c4t0d1


disk 14 0/8/0/0.3.4.0.0.0.0 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0
disk 15 0/8/0/0.3.4.0.0.0.1 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c6t0d1 /dev/rdsk/c6t0d1


disk 25 0/9/0/0.1.4.0.0.0.0 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c8t0d0 /dev/rdsk/c8t0d0
disk 26 0/9/0/0.1.4.0.0.0.1 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c8t0d1 /dev/rdsk/c8t0d1


disk 36 0/9/0/0.4.4.0.0.0.0 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c10t0d0 /dev/rdsk/c10t0d0
disk 37 0/9/0/0.4.4.0.0.0.1 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c10t0d1 /dev/rdsk/c10t0d1



NEW IOSCAN

disk 63 0/8/0/0.1.4.0.0.0.0 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c13t0d0 /dev/rdsk/c13t0d0
disk 64 0/8/0/0.1.4.0.0.0.1 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c13t0d1 /dev/rdsk/c13t0d1



disk 79 0/8/0/0.4.4.0.0.0.0 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c15t0d0 /dev/rdsk/c15t0d0
disk 80 0/8/0/0.4.4.0.0.0.1 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c15t0d1 /dev/rdsk/c15t0d1
disk 81 0/8/0/0.4.4.0.0.0.2 sdisk CLAIMED DEVICE HP A6189B


disk 93 0/9/0/0.2.4.0.0.0.0 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c17t0d0 /dev/rdsk/c17t0d0
disk 94 0/9/0/0.2.4.0.0.0.1 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c17t0d1 /dev/rdsk/c17t0d1
disk 95 0/9/0/0.2.4.0.0.0.2 sdisk CLAIMED DEVICE HP A6189B


disk 109 0/9/0/0.3.4.0.0.0.0 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c19t0d0 /dev/rdsk/c19t0d0
disk 110 0/9/0/0.3.4.0.0.0.1 sdisk CLAIMED DEVICE HP A6189B
/dev/dsk/c19t0d1 /dev/rdsk/c19t0d1
disk 111 0/9/0/0.3.4.0.0.0.2 sdisk CLAIMED DEVICE HP A6189B

[jpcast_real]

I see the problem , I am completely stupid.+
****!!!"????

I connected the cables in the wrong way so the HW path change and for the reason the device files changed.


Thanks for your help.

Regards

[Uwe Zessin · Accepted solution]

Ahem. You said you had a power failure with a switch and server reboot. That does not swap any cables ;-)

If you move cables around, it is clear that FCIDs change (that's what CISCO tries to prevent with WWN-based FCID binding).

[ed skolnik]

Could someone point me to where FCIDâ s are stored in HP UX?