topic Re: Device files , SAN in HPE EVA Storage

Device files , SAN

jpcast_real — Mon, 31 Jan 2005 09:51:07 GMT

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

Re: Device files , SAN

Alzhy — Mon, 31 Jan 2005 10:10:55 GMT

- 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

Re: Device files , SAN

Duncan Edmonstone — Tue, 01 Feb 2005 04:59:12 GMT

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

Re: Device files , SAN

jpcast_real — Tue, 01 Feb 2005 09:35:15 GMT

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.

Re: Device files , SAN

Uwe Zessin — Tue, 01 Feb 2005 09:45:39 GMT

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?

Re: Device files , SAN

jpcast_real — Tue, 01 Feb 2005 10:21:17 GMT

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

Re: Device files , SAN

jpcast_real — Tue, 01 Feb 2005 10:30:22 GMT

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

Re: Device files , SAN

Uwe Zessin — Tue, 01 Feb 2005 10:43:05 GMT

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).

Re: Device files , SAN

ed skolnik — Tue, 15 Feb 2005 14:24:48 GMT

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