[Info-vax] Marketing ideas for VSI ?

[Stephen Hoffman]

On 2018-12-14 14:46:56 +0000, Jon Schneider said:

> On 14/12/2018 13:41, Simon Clubley wrote:
>> One idea I had was something along the lines of the disaster-proof 
>> video showing what VMS clusters can do. I was thinking of a demo 
>> something along these lines:
> 
> I certainly get irritated by videos of people building clusters out of 
> Raspberry Pis running SimH with presumably no more of a concept of what 
> a cluster actually does from the client's point of view than I have.
> 
> My understanding is it's maybe the (Files-11) filesystem and maybe RDB 
> or something.  But if that's it how is that useful in today's world 
> when the clients are web browsers ?

Clustering is one way to provide data access across software 
upgrades—the app requirements around writing a clustering-capable and 
particularly around writing an app capable of its own rolling upgrades 
are very poorly documented, but are possible—and across server 
failures.  This access when configured with multi-host shared-write 
storage hardware and/or with software-based shared-write RAID-1 HDD or 
SSD storage.  The multi-host software RAID-1 can operate atop hardware 
RAID, though hardware RAID is far from a unique feature.

Oracle Rdb is a cluster-capable database app.  Rdb itself can deal with 
rolling upgrades within a cluster, but—like many apps on OpenVMS—can't 
itself provide for an app-level rolling upgrade; you have to briefly 
shut down and convert your database to upgrade to a newer version of 
Rdb.  Oracle RAC includes its own clustering support, and can perform 
most or all of what Rdb can provide on OpenVMS.

> So please explain what clustering actually _does_ and sell me VMS (not 
> that I am in a position to buy into it on behalf of anybody)

I have a passing familiarity with clustering and its implementation, 
and what you're asking is not an easy sale up against a replicating 
database, or against failover-capable storage, or sharding.   The 
proverbial product sweet spot is comparatively narrow.

Clustering provides a single-sign-on, and with multi-host shared-write 
data access into a single common data store, with the associated and 
integrated and necessary distributed coordination—the so-called 
distributed lock manager or DLM—and with HDD- or SSD-level multi-host 
distributed shared-write data replication (shadowing) available.

In place of clustering—on OpenVMS, and more generally—many folks use 
failover designs, or active-active or failover databases, or can 
tolerate eventual consistency, or can use sharded data across parallel 
servers.   In recent years, various app designs using in-memory storage 
across redundant servers with local logging for catastrophic recovery.  
 And recent system and storage speeds and VM guests have made 
brute-force reboots tenable for a number of folks.

Clustering is quite good for continuous uptime (and when configured and 
managed appropriately), though more than a few apps have designs that 
can limit that uptime, either around upgrades or around consistent 
backups.

Clustering is in the market space below redundant server design such as 
that of NSK, and above DNS and NetRAIN and ilk—though that too is a 
factor in clustering—and sharding-based designs, and database 
replication and related, and apps and designs that can operate with 
failover-capable file shares via FC SAN or SMB NAS or ilk.  Clustering 
also exists in the range below where you're going to have to shard your 
app and your data irrespective of clustering, as the coordination and 
locking overhead does increase and does eventually saturate as I/O 
loading increases across the HDDs or SSDs, and as multiple hosts in the 
cluster inherently have to coordinate their I/O caching activities.  If 
one host might hypothetically mostly-saturate an HDD or SSD, then a 
cluster of two or more hosts alternately tossing writes has that load 
plus the locking-related traffic...

Pragmatically, clustering has also priced itself out of many usages.

And the cluster set-up documentation and implementation is rough.

And the app documentation for developers and for set-up is weak.  Lots 
of you-should-know-this and some core cluster configuration doc that I 
stuck into a setup file template most of twenty years ago still isn't 
in the main docs.  And the whole configuration is absurdly manual, by 
present-day standards.  And combining two or more existing OpenVMS 
servers into an existing or into a new cluster can get *very* 
entertaining.

And RMS has no provisions for consistent backups of live RMS files, nor 
provisions for the online maintenance of indexed files.

And the whole caboodle well predates LDAP as shared authentication, and 
OpenVMS still doesn't integrate with LDAP past passwords.

These discussions usually then degenerate into discussions of ACID, and 
CAP and any app-specific tolerances for eventual consistency, sharding, 
and other scaling- and performance-related database topics.




-- 
Pure Personal Opinion | HoffmanLabs LLC