[Info-vax] Clustering (was: Re: Marketing ideas for VSI ?)

[Stephen Hoffman]

On 2018-12-16 15:10:29 +0000, Dave Froble said:

> On 12/16/2018 3:55 AM, Phillip Helbig (undress to reply) wrote:
>> In article <mailman.3.1544908232.23319.info-vax_rbnsn.com at rbnsn.com>,
>> Kerry Main <kemain.nospam at gmail.com> writes:
>> 
>>> OpenVMS Clustering is simply a high end and solid implementation of a 
>>> shared disk (everything) cluster. Other implementations of this same 
>>> shared disk cluster strategy are z/OS and Linux/GFS2.
>> 
>> Do these other systems have other things which I consider essential to 
>> clusters?
> 
> Do keep in mind that other environments have seemed to exist for some 
> time now, and get people's jobs done.

OpenVMS often provides that for existing customers.  Quite well, in many cases.

Different products and different trade-offs and different compromises 
for different targets.

>> generic and specific queues
> 
> I'd guess there are methods for printing.  Don't know about batch, or, 
> other purposes VMS's queue manager can be used for.

Print queues are still around on most platforms, though job schedules 
have replaced the half-baked scheduling that OpenVMS folks are 
accustomed to tussling with and contending with.

The OpenVMS job controller and the operator communications are firmly 
stuck in the late 1970s or early 1980s, unfortunately.

>> queues which will failover to another node
>> 
>> cluster-alias IP address
> 
> I'd guess that other systems handle networking tasks.

OpenVMS uses weaker versions of NetRAIN, and DNS-based load-balancing.  
These are common across many environments.  OpenVMS is far weaker 
around using LDAP to locate services, and around using LDAP to store 
shared authentication and configuration and user data across a cluster, 
across a mix of hosts and clusters, and across multiple clusters, and 
across some very different architectures and operating systems.

>> cluster-wide logical names
> 
> Does any other system have logical names?  Not that I know.  But, I 
> don't get out much.

Soft and hard links for file system access, databases for access, 
property lists and configuration files for preferences and 
configuration data, and LDAP for replicated configuration data and ilk.

>> something like SYSMAN
> 
> It seems that people do manage non-VMS systems ....

Various options, some of which can push ssh sessions and that'll work 
with OpenVMS.  That's for systems that are still seeing a lot of manual 
management, which is getting rare.   HPE has been pushing DMTF/RedFish, 
and OpenVMS plays not at all here.

>> something like shared SYSUAF etc
> 
> Steve will shove LDAP under your nose, should you fail to recognize it 
> yourself.

That Phillip persists in asking this same question?

Yes, LDAP.

>> a database which can be open on all nodes---no failover, no standby, no 
>> switching, just continuation of processing on the remaining nodes
> 
> It appears that this can be a feature of the database, rather than the OS.

Correct.  Databases deal with this.  Active-active, and replicated.

Choose your particular tolerance for consistency, for availability, and 
for partitioning.

As with any clustering scheme.

A shared data store limits scaling.

>> something like the distributed lock manager which applications can use
> 
> The DLM is a very useful tool.  But it is not unique, and implementing 
> such is a bit less than "rocket science", which itself is no longer so 
> esoteric.

https://lwn.net/Articles/136308 — among others.

>> Arguably, all of these (all of which have been in VMS for a long time) 
>> are essential for a "proper" cluster.
> 
> Got to be careful, as "proper" is very much open to opinion.

For some of the OpenVMS discussions of competitive platforms and 
features, the discussion can become reminiscent of No True Scotsman, 
too.

OpenVMS has a pre-packaged and integrated configuration and there's 
definitely some value in that.  Licensing and set-up and documentation 
issues and discussions aside.  Substantial work awaits when bringing 
what's available forward to a more competitive offering, too.  Too many 
folks have become far too inured in using logical names and batch 
queues for tasks those features are ill-suited for, for instance.

TL;DR: If you look for an exact feature fit, you're probably writing 
marking copy or you're wiring an RFQ.  If you're looking to find a 
solution to your particular application and its requirements, wiring 
specific requirements can and variously will reduce your options and 
alternatives.


-- 
Pure Personal Opinion | HoffmanLabs LLC