SAN disk primary path and MSCP

[roose]

Hi folks,

We are currently doing an activity on our 2-node clustered ES80 AlphaOpenVMS v7.3-1 servers, using a newly allocated 160GB and 100GB disks from an EMC DMX2000 SAN.

While we were doing the activity and monitoring the disks (monitor disk), we saw initially that on node 1, the new disks that were just mounted had the "R" beside the volume name and before the numeric values. Referring back to the OVMS documentation, this meant to us that the disk is being remotely "served" (for the lack of better word) to node 1, when it is supposed to see the disks "directly". We dismounted the disk clusterwide, did an MC SYSMAN IO AUTO on both nodes, but still, the same thing was seen. Next, we tried to do a $ SET DEV $1$DGAxxx/PATH=PGxx.xxxx/SWITCH, and again, this did not do anything on node 1. All the while, node 2 did not seem to show anything unusual and disks seems to be seen "directly".

I am attaching the output from $ sho dev $1$dgaxxx/full for both node 1 and node 2 for your reference.

Our concern here is that with the MSCP path being taken by node 1 to access the new disks, then, if anything happens to node 2, node 1 will just die as well. Or is this not the case and the other paths should take over? Because normally on our environment, we don't see the MSCP path as the primary, instead, mostly are PGxx paths.

Thanks in advance for your help.

[Uwe Zessin]

The so-called 'primary path' ist just the *first* path that was detected. Unless I have overlooked something, however, both systems have switches to FC pathes, so there should be no problem.

[Wim Van den Wyngaert]

Uwe,

I have a 4100 with dual HSG80. I see the scsi paths too when I do show dev but I don't get the R in monitor disks. VMS 7.3.

MSCP_LOAD 1
MSCP_SERVE_ALL 1

Any idea why ?

Wim

[Wim Van den Wyngaert]

Oops, make that fc instead of scsi.

Wim

[Volker Halle · Accepted solution]

Roose,

the important piece of information to look at is the CURRENT PATH, not the primary path detected during boot.

OpenVMS V7.3-1 (or higher) will also automatically fail back from the MSCP-server path to a direct path to the FC disk, once it becomes available.

Volker.

[Peter Zeiszler]

At the boot prompt what does your your N# and WWID# show? I had to make sure my FC device paths were setup using wwidmgr.

On your output it appears that S1P02 was the first machine up and MSCP served the disks. The system S1P01 was served the disks on boot up and then detected the multipath information. The devices show that you are currently using the direct connect.
-----------------
sho dev $1$dga1882/fu
I/O paths to device 3
Path MSCP (S1P02), primary path.
Error count 0 Operations completed 1056
Path PGA0.5006-048C-49AE-6CF9 (S1P01).
Error count 0 Operations completed 6
Path PGB0.5006-048C-49AE-6CF6 (S1P01), current path.
Error count 0 Operations completed 54
-----------------
Primary path is the MSCP serve from S1P02. But the CCurrent path is PGB0.5006-048C-49AE-6CF6.

If you want to test this try this set of commands:
show device/full $1$DGA1882:
set device $1$DGA1882:/path=PGA0.5006-048C-49AE-6CF9/switch
show device/full $1$DGA1882:


Check your paths before and after the set device command.
You should see a quick opcom message on that disk with details of the multipath and also a mount verify.

[Robert Brooks_1]

Check your paths before and after the set device command.
You should see a quick opcom message on that disk with details of the multipath and also a mount verify.

----

If mount verification suppression is enabled, it's quite likely that no mount verification message will appear via OPCOM.

Please see the sysgen parameters MVSUPMSG_INTVL and MVSUPMSG_NUM for more information. I think that these were added for V7.3-2.

[roose]

Thanks guys! We also opened up a case with local HP per management request and confirmed what you folks advised me.