[Info-vax] MSCPMOUNT and cluster volume mounts (was: Re: WRONGVU)

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Fri Jul 5 16:30:16 EDT 2019


On 2019-07-05 17:11:23 +0000, Rod Regier said:

> Their advise was to have the re-joining node execute a procedure on 
> each of the other cluster member nodes to mount the shared drives local 
> to each of the other nodes.

I.... wouldn't use that approach.

Not as was stated, at least.  Not having the re-joining node run DCL 
procedures on other cluster member hosts secondary to bootstrap.

Rather, I'd use a local fork of the MSCPMOUNT example procedure 
provided with OpenVMS, started at boot on each host and running 
continuously.

MSCPMOUNT has some issues, but it works.  MSCPMOUNT.COM is not a 
particularly customizable example. The necessary DCL code changes are 
somewhat buried in the procedure.  The use of a data file or ilk would 
have been preferred.  Or the availability of a full-on LVM of course.  
But again, it works.  Start it at boot on each host, and let it run 
continuously.  One of the very few times MSCPMOUNT causes trouble is 
when you're reconfiguring a host-based volume shadowing RAID-1 
shadowset or ilk, and you'll have to remember to stop it and restart it 
around your shenanigan-ing.

If you're inclined, tweak the MOUNT logic such that the volume rebuilds 
and related processing runs on the faster and/or on the faster-I/O 
hosts, too.  That's less of an issue with many more recent 
configurations, but it was and remains possible for a rinky-dink VAX or 
some other boots-faster-but-runs-slower box could effectively lock-step 
the bootstrap sequence of the rest of the cluster behind the rebuilds.

And if it's not already obvious, I would not use /CLUSTER in that 
MSCPMOUNT procedure.


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list