$mount/cluster tries to remotely mount non-served disks

[Ziggy Filek]

I have a cluster of 3 ES80 (A,B and C)on Fibre Channel using volumes shadowed between 2 EVAs. I recently booted an AS2100 (D)into this cluster just to provide a vote. The AS2100 has its own system disk and does not share any disks with the big cluster, neither does it use shadowing. When volumes are mounted on the big cluster using $mount/cluster, an irritating error message appears about mount failure on node D. Interestingly the error is about lack of shadowing license on D, not about the fact that the common volumes on EVAs are not even served! It is not a big deal, but I'd like to have that supressed. One way would be to mount all volumes with /system instead of /cluster on all nodes (they are all visible thru FC). Is there any functional difference in after-mount behaviour between volumes mounted /cluster and /system? In particular, would copy and merge operations on shadow sets be affected?

Thanks, Ziggy

[John Gillings · Accepted solution]

Ziggy,

MOUNT/CLUSTER is just a convenient way to distribute the same MOUNT command to all nodes in a cluster. There's no logic to check if it "makes sense" on the remote node, just check that it works on the local node, then blindly send it to the other nodes. Any errors encountered on the remote nodes are reported at the requesting node.

In most clusters that's a useful thing to do, but in your (rather unusual) case, some MOUNT commands are invalid on just one node. The error reported will be the first one detected by the remote node. In your case that's the shadow license check. If you give the node the appropriate license, it will no doubt fail with some kind of "invalid volume" condition.

You could use SYSMAN to limit a MOUNT/SYSTEM command to a subset of nodes.

$MCR SYSMAN
SYSMAN> SET ENVIRONMENT/NODE=(A,B,C)
SYSMAN> DO MOUNT/SYSTEM whatever...

> Is there any functional difference
>in after-mount behaviour between
>volumes mounted /cluster and /system?

No. Note that /CLUSTER and /SYSTEM aren't really variations of the same thing. /CLUSTER implies /SYSTEM, but just directs the MOUNT/SYSTEM to be propagated to all other nodes. See HELP MOUNT/CLUSTER.

>In particular, would copy and merge
>operations on shadow sets be affected?

Maybe... note that one node is chosen to perform the copy or merge. With MOUNT/CLUSTER you don't have any control over the sequence of MOUNT commands (except that the local node is always performed first). If you use SYSMAN, the MOUNTs will be executed in the order you specify. You *MAY* be able to use this to distribute shadow copy/merge load across nodes. For example:

SET ENVIRONMENT/NODE=(A,B,C)
DO MOUNT/SYSTEM DSA1
SET ENVIRONMENT/NODE=(B,C,A)
DO MOUNT/SYSTEM DSA2
SET ENVIRONMENT/NODE=(C,A,B)
DO MOUNT/SYSTEM DSA3

There are other ways of controlling and prioritising shadow operations, depending on what version you're running. You would need to experiment to determine if it's useful to rotate the node list.

[Ziggy Filek]

John: Thanks for this detailed response!
Ziggy