SAN fabric changes affect disk presentation to VMS?

[Rob Gibson]

Hello all - I am preparing to migrate a VMS 7.3 host to some new SAN switches. One concern I have is that the change in the SAN fabric and/or the physical disconnect/reconnect of the HBA fiber could cause VMS to "lose" track of the current LUNs.

I can provide more information on the devices, configurations, etc as necessary but I wanted to know at a high level if VMS concerns itself with SAN paths when addressing/identifying a given LUN.

TIA,
Rob

[Robert Brooks_1 · Accepted solution]

If you really mean V7.3 (and not V7.3-2), then I'd STRONGLY urge you to upgrade to V7.3-2.

The entire I/O stack for SAN storage (the SCSI class driver DKDRIVER, the fibre channel drivers FGE/PGADRIVER, and the multipath layer) are MUCH more tolerant and capable of handling SAN problems than the V7.3 code).

Note that I have not directly answered your question, because there is too much vagueness in your query, but my short answer would be "no"; I may be taking a much more literal interpretation of your question than you'd really want.


-- Rob (who used to work DKDRIVER and multipath for VMS Engineering)

[Hein van den Heuvel]

Heed Rob's advise. He knows what he's talking about!

IF VMS would present a given storage device as a different unit, then surely that will eb hidden from the application through logical names no? Hopefully the LABEL (mount/over=id) will tell you which disk was ultimately found. PLEASE make sure all device references are through logical names (like DISK$label), never hard paths ($1$DGA...).

fwiw,
Hein.

[Volker Halle]

Rob G,

as long as you retain the same LUN identifier for a given disk, OpenVMS will use whatever path is available to reach that LUN.

If you disconnect/reconnect or otherwise change your fabric config while the disks are mounted, you will see mount-verifications and path-switches, but as long as there is a working path, OpenVMS will find it.

Volker.

[Robert Atkinson]

Rob,
changing the bridge in the middle shouldn't stop your SAN working. However, be wary of any Zoning you may have set up on the switch.

Rob.

[Tom O'Toole]

It's a good question because the state of affairs is not so good on other systems, for example, aix, to bring up one I deal with a lot. Apparently we are totally spoiled by the robustness of VMS on the SAN. Users of other systems expect it's normal to shutdown their systems for san changes. I don't get it. Why spend all that money on setting up redundant san fabrics if it doesn't give benefits like being able to move/redeploy stuff?

[The Brit]

Rob,
I agree with all of the comments above, especially those from Rob Brooks (he is definately an authority in this area). At the highest level though the question of whether VMS will lose track of the LUN's, the answer in "unlikely".
The broader question should be "Is this going to cause me any problems?" To this the answer is "depends".
It depends on how you have your systems configured.
1. do you use HBVS?
2. if so do you have you unit presented from different storage subsystems.
3. do your VMS systems have multiple HBA's.
4. are you attached to multiple fabrics.
5. are your disk controllers pathed to the same independent fabrics.

If the answers to the above (particularly 3, 4, & 5.) is yes, then the other thing you need to consider is any "zoning" that may be present on the switches.

If you are using HBVS then providing that 2. is true then you have an additional safe guard since, if you lose connectivity to a unit, normally all that would happen would be that the device will go into "Mount Verify" and then after timeout, the unit will drop out of your shadow set.

Dave.

[Rob Gibson]

All - thank you for taking the time to advise me on the SAN switch migration. We completed the migration two weekends ago and all went fairly well. The host systems were using V7.3-2 after all. The only real issue we saw was that the systems were configured to boot from SAN which meant we had to enter a few commands at the >>> prompt to have it rediscover the boot LUN. HP support easily helped us resolve this issue.