[Info-vax] Distributed Applications, Hashgraph, Automation

[Stephen Hoffman]

On 2018-02-15 12:22:27 +0000, Phillip Helbig (undress to reply said:


> Other people in the industry refer to a wide variety of configurations  
> as "clusters", though many offer not even the most basic of VMS cluster 
>  benefits.  In a VMS cluster with shared disks, more is usually 
> involved  than in other "clusters" with shared disks.

Shared storage is a simple model, though the volume-level granularity 
of sharing makes the whole scheme somewhat less than efficient when 
you're really trying to push I/O around.  The locking overhead inherent 
in the sharing also limits how well the whole design works.  The apps 
tend to know what information the apps need to share.  Sharing the 
whole volume certainly works, and it's fairly simple to work with, but 
a volume-level shared-access file system doesn't abstract app network 
access and data sharing all that well and the sharing itself is 
inherently self-limiting, around performance and around details such as 
online or offline backups.  Yeah, with 10 GbE and SSD for locks and for 
storage respectively, that ceiling is rather higher than it used to be. 
 But the shared storage also tends to tip over apps that don't expect 
that to even be happening, including OpenVMS native apps that aren't 
developed as cluster-aware.

OpenVMS needs to fully adopt LDAP, and replace SYSUAF and RIGHTSLIST.  
Fully integrate LDAP with MAIL and other network services.  Across 
clusters.

OpenVMS needs to make clustering vastly easier to configure, and easier 
to manage.  ~Dozens of manually-referenced shared files is not a user 
interface, it's a hilariousness.

UICs and identifiers are a problem for adding and removing hosts.  
That's all tossed at the system manager to manually de-conflict.  Or to 
ignore, with all the hilariousness that can then entail.  Deprecate 
those for most uses and UUID all the underlying parts.

The lock manager API needs a wrapper for simpler usage for common 
tasks.  Electing a primary process, notifications of associated apps 
and processes arriving and departing, etc.

Notifications need to be integrated and consolidated and not scattered 
across a dozen different interfaces and APIs and files.

Task scheduling for the local host, for the cluster, and across clusters.

Message-passing needs to be available and increasingly preferred over 
shared disk for apps that require performance.

File shares.  Client and server.  Integrated.   Gotta play nice with 
SMB.  Current-version SMB.   For most folks, SMB is what shared storage 
means.  Not SCS, and not what OpenVMS clustering provides.   (No, I 
wouldn't expect to see SCS replaced with SMB.  But that's certainly an 
interesting idea.  NQ, Tuxera or otherwise might be a starting point 
here, too.)

Ubiquitous encryption.  Ubiquitous distributed authentication.  
System-integrated TLS and DTLS.  This also includes encrypted SCS.  
Make unencrypted SCS a special-case security downgrade.   Use 
processor-level cryptographic support, and consider requiring 
processors with that support.  APIs that help developers avoid the 
common errors.  Fully-integrated certificate support with a maintained 
root store, and with an overhauled UI.

Secured and encrypted key store for passwords and private keys, 
preferably distributed.

Secured automatic software distributions for VSI and for third-party 
apps.  Opt-in automatic installations for priority patches.

Online backups.  Easier restorations and recoveries.  Not just for 
integrity, but because OpenVMS servers have been breached and OpenVMS 
servers will get breached, and intrusion detection is largely missing 
and tends to be delayed allowing attackers access for far too long, and 
server restoration and recovery as currently implemented is a horrid 
process.

Fully-integrated IP.  Not layered. Not add-on.  Not anything resembling 
the current kitting and organization, a wonderful case that dates back 
to early VMS development's now-absurd antipathy toward IP.   Always 
present.  Always installed.  IPv4 and IPv6.  Current services also 
always present and always integrated and always configured (if not 
enabled), including Apache, Tomcat, DNS, DHCPv6, etc.  Message-passing, 
too.

telnet, ftp, DECnet and any other insecure protocols either need to be 
wrapped and updated and secured, or they need to be deprecated and 
removed.

Image-install and boot and connect into the newly-installed guest 
securely, and without requiring a hardware console.  Making OpenVMS 
easier and simpler to deploy, whether you're running your own hardware 
or VMs, or you're hosting.  Yes, some folks want to run OpenVMS hosted 
elsewhere.  Get over it.  Make it easier.  Make it as secure as it can 
reasonably be, using SGX or otherwise where appropriate.

We're also headed toward byte-addressable non-volatile main storage, 
and that's going to be a big chance to storage.  
https://www.usenix.org/system/files/conference/fast18/fast18-won.pdf  
Etc.

Clustered is the default system configuration, and the default 
installation configuration.  Not standalone.  Allow advanced users to 
de-tune and de-configure, where that's specifically necessary.  No 
separate license, either.  Make OpenVMS hosts trivial to connect and to 
coordinate and to securely serve and share storage.  Don't erect 
roadblocks and impediments and complexity on the path to one of the 
most powerful remaining features within the whole platform.

Or we can discuss the most heavily advertised algorithms, like what a 
b-tree algorithm would have turned into had that algorithm had a 
slightly better marketing agent and funding from a sketchy-looking 
crypto currency acting as a close associate.  Or we can endlessly 
debate the features and limitations of pre-millennium clustering and 
who was first with what terminology, of course.   Or we can debate 
marketing the current cluster-related features and support, because 
that's worked out so well over the past twenty+ years.    I'm sure 
that'll all work out well for the future of OpenVMS, too.   Or we can 
realize that we're headed forward, not back to Itanium or Alpha nor to 
VAX, and that we're not headed back to ISO or DECnet or wide-open 
connections, nor to existing and old assumptions around staffing and 
skills and software and network environments.


-- 
Pure Personal Opinion | HoffmanLabs LLC