[Info-vax] Third node into 2-node cluster
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Thu Mar 28 10:46:30 EDT 2019
On 2019-03-28 13:49:48 +0000, Richard B said:
> Thanks all for the great advice. However, I'm not sure I understand
> why I would want to point any logicals to the existing 2-node cluster.
> This third node will be a voting/quorum member only. That will be it's
> only function. No one, aside from me, will log into it, no one will
> use any of its resources, nada, nothing, zilch. (It will, however,
> suck power!). It has it's own system disk, will have VOTES=1 set and
> any disks on the existing 2-node cluster (MSCP-served) may well be
> mounted on this new node but not shadowed with this 3rd node. Or am I
> missing something?
Not this, again. Okay. Once more into the breach. OpenVMS clusters
are a single security domain. That is, the UICs and the Process IDs
(PIDs) and the rest are common across all hosts.
Those UICs are written all over the storage, which you're sharing.
If you follow the path you're on and ignore the advice, it'll mostly work.
But some stuff will work weird. Some stuff will be too accessible.
Some not accessible at all. Some stuff will work. Other stuff will
not.
This'll happen slowly and incrementally, particularly as users are
added or removed and as configuration and usage changes are made.
You'll probably start out with "just" a few skewed accounts with the
bizarro world of the TCP/IP setup, and with a few skewed ownerships on
storage devices, and the UIC skewage and the oddities will spread from
there.
You might have RICHARDB when logged in on one host that'll work fine,
and RICHARDB logged in on another that won't. Files that get odd
ownerships.
If this then follows the usual pattern of folks new to clusters, you'll
be back here in a year or three—or your replacement will be back
here—wondering why something works or something does not work, or why
SUBMIT or MAIL is tossing an error, or why the protections are messed
up. Or you'll be grumbling to management about OpenVMS—justifiably,
too, given this whole user interface is such a mess—and y'all will be
pondering or will be working on a port.
This whole management configuration is an utter embarrassment, and
particularly given its immediate proximity to a much-vaunted operating
system feature.
This is a 1980s-era logical-names-and-files-and-accreted-compatibility
mess that we all get to deal with when we're creating a cluster. We
can't use a cluster without wading through this idiocy.
Those that have done those know the knobs and many of us have become
inured to the problems. New-to-OpenVMS or new-to-clustering folks...
The new folks get the worst of the documentation and setup and
management interface, and several shedloads of documentation to wade
through and none of which succinctly describes setting up a cluster.
This is where a few folks will appear in the discussion and will
suggest "hire competent and experienced folks!", and that'll work. But
I have to wonder why adding hosts to a cluster takes such an effort,
and involves so much hand-editing and so many logical names.
And all this is before pondering what happens when adding a new host or
when splitting off a host. And that's certainly before discussing
automating the addition of hosts, and which opens up a number of
related configuration and setup issues. Of finding and of resolving
the UIC skewage when a host is added. And that's all before pondering
why we're not using something akin to LDAP to manage all of these
details and not this ever-increasing wad of archaic and arcane RMS
files and a clearly-expedient UI design straight out of the 1980s.
ps: yes, it's possible and sometimes even necessary to have multiple
SYSUAF files due to the way OpenVMS (doesn't) work and due to the
single security domain. The UIC values must be coordinated across all
of the SYSUAF files present.
> Again, thanks for all the advice/suggestions.
You're in the deep end of the pool with OpenVMS, and clustering setup
is one of the deeper parts of the OpenVMS pool. You can go with the
accumulated wisdom and with what's buried in SYLOGICALS.TEMPLATE and
related, or you can accrue that wisdom anew. In production.
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list