Question: How do you determine the device file mappings with two systems share the same AUTORAID.

[Jack C. Mahaffey]

I have two systems sharing the same SureStore E Model 12H disk array. Volume groups are active on primary system only. How are the device file names determined on the non-active server for when the volume groups need to be imported. Their paths are different and so are their device file names.

jack...

[A. Clay Stephenson · Accepted solution]

Hi Jack:

When you mention active, I assume that you mean
MC/SG. You can do a vgexport -s -p -m mapfile vg that adds the array_id to the mapfile. Vgimport -s then looks for devices with that array id.

The bad new using that method is that you are going to cause you imported VG to use only the primary path. If you want to split I/O across both external paths then you need to do a little more work.

Bear in mind that on both hosts the SCSI ID and LUN will remain the same. Therefore, you already know the tYdZ part of the devive node. You need to know the cX part. Do an ioscan -fn to locate the SCSI controller with your 12H attached. Just above it, there should be an 'ext_bus' list under 'Class'; look for the matching Instance Number (the 'I' column) and that value becomes you controller part (the cX) of /dev/dsk/cXtYdZ or /dev/rdsk/cXtYdZ.

If you want to actually import to take advantage of both external path, the attached document explains it pretty well.

Regards, Clay

[Holger Knoppik]

Hi Jack !
Hmmm, quite difficult! OK, run ioscan -fnCdisk on both systems, then arraydsp -a and redirect them into files. On both systems, you will see all LUNs. If you try a pvdisplay on a device belonging to the other server, you will get some stuff like "Couldn't display the vg to which belongs " Are you going to build a cluster ?
Hope this helps a bit, CU
RGDS, Holger

[Jack C. Mahaffey]

We're not running Service Guard. I'm with you on the performance issues regarding the alternate paths. I understand it and we do use them. Since I did not create the original LUNs on the AUTORAID I don't know if the device file naming convention was determined by whoever created the LUNs or were they automatically generated by LUN creation software. i.e. arraycfg ?.

I would like to be able to query the array where traceability is provided by showing which device files are associated with which LUNs. Doing a arraydsp -d /dev/rdsk/ will show me which disk array is managing the device. It does not show me which LUN is allocated to the device.

It may be real simple, such as LUN 0 will correspond to last digit of the device file name whereas c6t2d0 corresponds to LUN 0 and c6t2d1 corresponds to LUN 1.

My company decided not to go the Service Guard route. We do have, however, two production disk arrays connected to two hosts. One acts as the primary and the second as the failover. The failover server is actually used as the failover server for two production hosts so the failover server is connected to two prodution disk arrays for different hosts. The init level and variable settings determine which server is to activate the production volume groups. For example, the first two device files on one host are c0t1d0 and c2t0d1. On the other host, they are c0t1d0 and c5t0d1.

I may have made things more confusing than necessary... oh well..

jack...

[A. Clay Stephenson]

Okay Jack, here's the deal.

There can be at most 8 LUN's (0 thru 7) on an AutoRAID. This is a total value and not a 'per attached host' value.

The device node scheme is simple as well. /dev/rdsk/cXtYdZ (or /dev/dsk/cXtYdZ for the block devices) is decoded as follows.

The LUN number becomes the 'Z' part so that LUN
3 is d3. The AutoRAID controller SCSI ID is the 'Y' part. Let's say that your 'X' AutoRAID controller is SCSI ID 1 and that your 'Y' AutoRAID controller is SCSI ID 2. We now know the 'Z' parts for LUN 3.
t1d3 (primary path) and then t2d3 (alternate path). Both of these are paths to the same LUN.
The tricky part is the 'X' part and that is specific to each host. I'll try to explain this once more. On each host, do an ioscan -fn | lp. That will give you a hard-copy listing.
Locate any of the 12H disks (you should see C5447A associated with them). Now, look above them until you come to the first 'ext_bus' in 'Class' column. The instance 'I' number associated with this is your 'X' part. You should find the 'ext_bus' associated with both 12H controllers. Let's say those were 8 for the 12H 'X' controller and 9 for the 'Y' controller.

Finally, for LUN 3, SCSI ID's 1 and 2, controllers 8 and 9 we know all the values.

c8t1d3 (primary) and c9t2d3 (alternate) and again both of these refer to the same LUN (3).

There is no magic bullet here; you have to work. By the way, everything I said in my previous attachment still applies except for the cluster stuff (e.g. vgchange -c y).

[Martin Burnett_2]

Hello Jack,

As stated the vgexport "-s" (which must be used with the m,p and v options) records the vgid (not arrayid) from the volume group into the map file that is created. The vgid is stored on each pv (physical volume) that belongs to the volume group in the volume group reserve area (vgra). This is a reserved area at the beginning of the physical volume. When the volume group is vgexported this information remains in tact on the pv in the vgra. You then take the map file to the other server and use it to vgimport with the "-s" option. The system will then go out and attempt to read the vgra on all of the attached disks the system has access to. Those disks that have the correct vgid stored in the vgra (that matches the map file vgid) will then be imported into the volume group and the lvmtab updated accordingly.


Martin

[Jack C. Mahaffey]

Thanks all... I'm a little smarter now :)