[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