SYSMAN> IO AUTOCONFIGURE to see a new SAN

[Drew Shelton]

I'm migrating my cluster from one SAN to another. Each node has 2 HBA's, so each node is now connected to both SANs. IO AUTO on the first node found the new devices. But I'm using MSCP, so the second node now sees the disks via MSCP and IO AUTO on that node won't pick them up via the HBA. How can I force the second node to see the disks via the HBA?

Thanks,
Drew

[Jan van den Ende]

Drew,

SYSMAN>IO FIND

will ask the SAN to tell its devices.

Proost.

Have one on me.

jpe

[Bill Hall]

I suspect this is "normal" for the unmentioned version of VMS you are running. Reboot the second node and it will see and use the direct paths correctly. I do recall seeing this in our first migration to SAN based storage at V7.3-1 as we presented new units to the cluster. IIRC, this was fixed in V8.2 or maybe in an ECO.

Bill

[Jess Goodman]

Assuming VMS version 7.3-2 or later after SYSMAN IO AUTO the second node should see the direct path(s) even though it is still using the MSCP path. SHOW DEVICE/FULL will show all the known paths at the bottom of the display.

If direct path(s) are available I think you can then switch to one of them with:
$ SET DEVICE /SWITCH /PATH="paste_path_here"
But I'm not sure in what VMS version the ability to switch from a current MSCP path was added.

Next time before doing SYSMAN IO AUTO on one node temporarily STOP the CONFIGURE process on all the nodes (don't depend on doing the IO AUTO after SET ENVIR/CLUSTER since it is still done one node at a time and CONFIGURE may find the MSCP path before a later node executing IO AUTO finds the direct path).

[Robert Brooks_1]

If direct path(s) are available I think you can then switch to one of them with:
$ SET DEVICE /SWITCH /PATH="paste_path_here"
But I'm not sure in what VMS version the ability to switch from a current MSCP path was added.

--

The "ability to switch from a current MSCP path" was added at the time that remote path support was added to multipath, which was V7.3-1.

Also added at that time was the "automatic failback" mechanism whereby multipath will
automatically switch from an MSCP path to a working local path.

This covers the case where all local paths have gone bad, forcing an automatic switch to an MSCP path, but a local path becomes good, and (relevant here) the case where MSCP was the first path found, but a local path is later discovered. In both cases, it should take no more than a minute from the time that a working local path is found to when the path switch happens.

This all assumes that the multipath poller is working. In other words, don't play with the SYSGEN param MPDEV_POLLER; leave it = 1.

-- Rob

[Jon Pinkley]

Drew,

I verified this on a 7.3-2 system with reasonably current patches. As Rob Brooks stated this all happens automatically if you have not done something to disable it.

Here's what I did:

We have a single EVA, but have each host separate from the EVA's point of view. I.e. we present vdisks to each individual host, not to the "cluster", so I was able to do the following:

1. create vdisk with o/s unit id different than any existing $1$dga unit. (in this case 1830)
2. present the vdisk to 1 of the cluster members, but not the other.
3. sysman io auto/log As expected the device is seen with a direct connection only on the host it was presented to. The other host sees the unit as an MSCP served device. This is similar to the initial condition you report.
4. present the vdisk to the other cluster member.
5, Repeat step 3. This time the only the second system notices a new device configured. A show device/ful still shows the MSCP connection as "primary", but no longer as the "current" path. Traffic does no longer goes over the MSCP served path. The only "odd" behavior is that MONITOR shows the traffic as "remote" even though it is not using the MSCP path. Whether this is fixed in MONITOR 8.3, I don't know.

Attached is log of the IO AUTO/LOG and show device/full output.

We need more info.

1. Are you sure the host that is using the MSCP connection can actually "see" the device? I.e. are the SAN switches zoned properly, and the selective presentation on your disk controller allowing the HBA to communicate with the "disk"?

You are probably going to need to shutdown and get to wwidmgr to really know, if every thing looks correct from the SWITCH and controller. Have you looked at the connections from the SAN switches point of view?

My gut feeling is that something is misconfigured on the Switch (zoning) or the controller (what is it by the way? HSG, EVA, shark, EMC, something else?)

p.s. Are you the same Drew Shelton that rode to the Mill with R.G. at VMS Bootcamp 2007?

[Jon Pinkley]

Forgot the attachment.

[Drew Shelton]

Apologies to all, I should have said that I'm running 7.3-2.

Jon,
I suspect you are correct about the zoning. The new SAN is owned by another company, and the cluster is being transferred to them. A third party is configuring that SAN.

And yes, I am the same Drew Shelton from last year's bootcamp.

Drew