Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

SYSMAN> IO AUTOCONFIGURE to see a new SAN

 
Drew Shelton
Occasional Advisor

SYSMAN> IO AUTOCONFIGURE to see a new SAN

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
7 REPLIES
Jan van den Ende
Honored Contributor

Re: SYSMAN> IO AUTOCONFIGURE to see a new SAN

Drew,

SYSMAN>IO FIND

will ask the SAN to tell its devices.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Bill Hall
Honored Contributor

Re: SYSMAN> IO AUTOCONFIGURE to see a new SAN

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
Bill Hall
Jess Goodman
Esteemed Contributor

Re: SYSMAN> IO AUTOCONFIGURE to see a new SAN

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).
I have one, but it's personal.
Robert Brooks_1
Honored Contributor

Re: SYSMAN> IO AUTOCONFIGURE to see a new SAN

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
Honored Contributor

Re: SYSMAN> IO AUTOCONFIGURE to see a new SAN

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?
it depends
Jon Pinkley
Honored Contributor

Re: SYSMAN> IO AUTOCONFIGURE to see a new SAN

Forgot the attachment.
it depends
Drew Shelton
Occasional Advisor

Re: SYSMAN> IO AUTOCONFIGURE to see a new SAN

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