[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