Strange behaviour of newly added HSZ80 disk

[Dirk Bogaerts]

2x DS20E cluster OpenVMS 7.2-1 with diskstorage :
* HSZ50 : DKC disks (being phased out)
* HSZ80 : DKA disks
* internal storage : some DKB disks

After adding the last 2 pairs of disks in the HSZ80 (as mirrors), one pair (DKA100) looks 'differently' in SHOW DEV than all the others (including the other final pair added as DKA101).
With 'differently' I mean that SHOW DEV gives no 'Host/Alternate host' info, as all the others DKA's do (see attachment for all the details).
Although the DKA100 can be mounted clusterwide and DCL INIT worked normally, I'm not going to use this device until I understand (and fix) the SHOW DEV differences. Haven't got a clue for the moment...

[Hein van den Heuvel]

I hate to suggest it, but rebooting node2 will probably fix it.
First I would (re-)try SYSMAN> IO AUTOCONFIGURE

It seems pretty clear that NODE2 saw DKA100 first true the MSCP path and did not fail over to the direct path when that became visible.
One must assume the diect path is avaiable as DKA101 is on exactly the same path.
Do you actually (expect to) need MSCP serving ever in you configuration? If not then this problem could probably have been avoided by making sure that SYSGEN param MSCP_LOAD = 0.

Although the versions do not lien up completely, maybe some of the following still applies:

http://h71000.www7.hp.com/DOC/82FINAL/6318/6318pro_024.html

A.7.3 Restrictions and Known Problems

"For versions prior to OpenVMS Alpha Version 7.2, a node's access to a disk will not fail over from a direct SCSI path to an MSCP served path.
There is also no failover from an MSCP served path to a direct SCSI path. Normally, this type of failover is not a consideration, because when OpenVMS discovers both a direct and a served path, it chooses the direct path permanently. However, you must avoid situations in which the MSCP served path becomes available first and is selected by OpenVMS before the direct path becomes available. To avoid this situation, observe the following rules:
A node that has a direct path to a SCSI system disk must boot the disk directly from the SCSI port, not over the LAN.
If a node is running the MSCP server, then a SCSI disk must not be added to the multihost SCSI bus after a second node boots (either by physically inserting it or by reconfiguring an HSZxx).
If you add a device after two nodes boot and then configure the device using SYSMAN, the device might become visible to one of the systems through the served path before the direct path is visible. Depending upon the timing of various events, this problem can sometimes be avoided by using the following procedure:


$ MCR SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> IO AUTOCONFIGURE


To ensure that the direct path to a new device is used (including HSZxx virtual devices), reboot each node after a device is added."

and...

A.7.6.2 Rules for Hot Plugging
"SCSI IDs that are empty when a system boots must remain empty as long as that system is running. This rule applies only if there are multiple processors on the SCSI bus and the MSCP server is loaded on any of them. (The MSCP server is loaded when the MSCP_LOAD system parameter is set to 1).
This is required to ensure that nodes on the SCSI bus use their direct path to the disk rather than the served path..."

fwiw,
Hein.

[Robert Brooks_1]

The implementation of multipath for V7.2-1 does not support local and remote paths; only multipath local paths were visible prior to V7.3-1.

Given the staggering number of multipath-related fixes with later versions, I'd strongly suggest that you upgrade to (at least) V7.3-2, if not V8.2.


-- Rob

[Dirk Bogaerts]

Thanks Hein & Robert for the quick reply.

Hein, indeed, I should have mentioned that both systems have been rebooted (but not simultaneous), as SYSMAN> IO AUTO did not give the correct result.
I could disable MSCP for the moment, but how can we explain the difference with other disks, now that both nodes have been rebooted. Or is it because it's the first device on the 'A' scsi HBA (a bit far fetched as idea) that MSCP interferes ?

Robert, I'm working now in Transparent mode but will move to Multibus/Multipath on 7.3-2 (once all Oracle versions are upgrade-compatible).

Dirk

[Jan van den Ende]

Dirk,

it should already be clear from the previous posts, that 7.3-2 is the way to go.
All I can add is our own experience: ALL are drives are ALL visible via the various (multi-) oaths, AND via MSCP.
And ALL have in the course of various upgrades (and (sigh!) a SAN cable maintenance mishap) been running happily over the various pathways (including MSCP), as manifested by displaying a path as "current".
(Well, MSCP was only current at one site, when we temporarily lost SAN connectivity, while maintaining intersite systems connection. It was "exciting", but it DID show the strength of VMS.)

To summ it up:

Go 7.3-2 (I read it, just waitng for Oracle compliance), and live happy with multipath and MSCP.

hth

Proost.

Have one on me (maybe at the Bootcamp in Nashua?)

jpe