[Info-vax] IS everyone waiting?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 20-Oct-16 11:30 AM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] IS everyone waiting?
> 
> On 2016-10-20 14:16:07 +0000, Kerry Main said:
> 
> > When any OpenVMS customer uses common system disks in a
> cluster, the
> > recommendation is to setup a common non-system disk
> between the OS
> > instances to share common files. That's a decades old best
> practice
> > for the OpenVMS community.
> 
> I really like clustering.   Host-based volume shadowing (HBVS) is
> one
> of the most unique features that's still left here, too.    But
> clustering and shadowing and related is a complete dumpster file
> to set one up, it's a pain to upgrade, and dependencies on 2000s-
> era and earlier technical management isn't the path forward to
> improved
> satisfaction and sales.   Particularly if anyone is looking at the
> competitive products, and where the competitive products will
> be in
> ~2021 or ~2026.
> 

No one is arguing that there is not room for improvements.

> > Reference sect 11.3:
> >
> http://h41379.www4.hpe.com/doc/82final/6318/6318pro_020.ht
> ml
> >
> > While automating this might seem like a benefit, many Cust's
> would
> > also argue that because of all the various custom config's, this is
> > better left to the local SysAdmin.
> 
> Utter disaster, that.   Absurdly complex, failure-prone and then
> there's the wonderful hassle to deal with patches and upgrades
> given
> the need to copy files back to the disks.   Oh, and the complexity
> of
> the configuration involved is categorically moronic.
> 

Have you ever tried to manage a large Windows or UNIX cluster?

Sure, there is room for improvements with OpenVMS clustering, but clustering on other platforms is a rats nest as well.

> > Setting up a OpenVMS cluster has lots of benefits, but like
> every OS
> > platform, OpenVMS clusters do require more planning and
> work to setup
> > and configure than an individual system.
> 
> Sure, if we're accustomed to the idiocy of user-hostile and half-
> assed user interfaces, then there's the complete lack of a whole
> pile of features such as distributed scheduling, distributed
> logging, distributed coordination, distributed management,
> system and performance tuning and data collection, LDAP and
> directory integration, and then there's the case where you might
> want to manage several clusters as one — configurations for
> lower latency or geographic distribution, for instance — and even
> an experienced system manager can
> have "fun" with that.   

I actually agree that ED should eventually be developed to become a distributed directory more like Active Directory whereby it is not only SSO, but also resource management (aka group policies etc). 

For lack of a better term, I like to call this a "cluster of clusters"  (includes standalone systems as well).

Having stated this, Geo clusters are for experienced resources to design, plan and implement. They will use things like WAN simulators to test App distance latency, data replication transfer speeds, impact on shadowing etc., firewall challenge, end user response times, etc. 

> If you're consolidating several OpenVMS
> servers
> into a cluster — app stacking, sans sandboxes or such — you're
> also handed the "fun" of rationalizing and coordinating all the
> UICs and usernames and identifiers, too — migration into a
> cluster has always
> been a project, and one that tends to get ignored.   (The utter
> clown
> shoes idea of randomly picking different UICs for TCP/IP Services
> and different selections of usernames that may or may not be
> present is an ongoing source of entertainment for these projects,
> too.)  Then there's the lack of job management and volume
> management, and the "fun" of getting applications stopped and
> the volumes dismounted cleanly, which is particularly
> "interesting" for folks with HBVS seeking to avoid unnecessary
> copies and merges.  Or of using the distributed lock manager for
> what it can really do, or getting connection security working via
> TLS and authentication, or a whole host of other developer-level
> issues and discussions.
> 

Regardless of the OS platform, large user management in today's world is cross platform (SSO) and requires careful design and planning. If you are really serious, then you not only look at the OS / directory layer, but also the upper layers of Identity and Access Management.

Sample 100% Java product - reference: (scroll down for block diagram)
https://www.forgerock.com/

Application upgrades is always a challenge and is not something specific to OpenVMS because they are application specific. When Apps are designed, they seldom think about how to upgrade them cleanly other than the traditional stopping the app, updating the app, optionally restarting the system and then restarting the App.

> TL;DR: hand a very OpenVMS-experienced user a pile of tools and
> logical names and randomly-named files and top it all off with a
> dollop of add-on HPE/VSI tools, locally-written or third-party-
> sourced software and tools for coordinating processes and
> applications and code, and read a disparate and scatter-shot stack
> of product and patch and related documentation, and clustering
> and HBVS and the the distributed
> lock manager and such a works.   It all works well.   Getting to a
> working configuration is absurdly complex, and failure-prone.
> 

I agree areas like OpenVMS patching, tools and other areas can be improved.

Having stated this, you are never going to get to the point whereby clusters are going to be simple enough for sysadmins with very little cluster or OS knowledge are going to be able to properly setup clusters in a medium to large environment - on ANY OS platform.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com