[Info-vax] Distributed Applications, Hashgraph, Automation

[Jim Johnson]

On Friday, February 16, 2018 at 6:30:10 PM UTC-8, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> > Richard Maher via Info-vax
> > Sent: February 16, 2018 7:55 PM
> > To: info-vax at rbnsn.com
> > Cc: Richard Maher <maher_rjSPAMLESS at hotmail.com>
> > Subject: Re: [Info-vax] Distributed Applications, Hashgraph, Automation
> 
> [snip...]
> 
> > servers"
> > are a thing of the past. On any server instance only one application
> > shall run. This makes a mockery of your monolith proposals.
> > 
> > >
> > >> 2) Geographical limitations
> > >
> > > If you want sync data (RPO=0), then in any multi-site environment, you
> > > are typically limited to <100km.
> > 
> > Pathetic!
> > 
> 
> Science and the speed of light. 
> 
> Course, it also depends on the R/W ratio of the application that also impacts exactly how far apart the two sites can be.
> 
> > >
> > >> 3) No PaaS capability
> > >
> > > That can come later .. the public cloud is just a modern hyped name for
> > > "outsourcing lite"
> > 
> > You just can't get your head around this can you :-(
> 
> Outsourcing definition - giving all or part of your IT to a vendor to manage for a variable service fee per month.
> 
> Public cloud definition - giving all or part of your IT to a vendor to manage for a variable service fee per month.
> 
> What am I missing?
> 
> Perhaps I should be drinking more Gartner kool-aide?
> 
> > >
> > > Many Customers who went to public clouds and/or outsourcing are
> > now
> > > coming back in house.
> > >
> > >>
> > >>>
> > >>> Btw, the modern day equivalent to memory channel and ultra low
> > >> latency
> > >>> data sharing is either Infiniband or RoCEv2 (RDMA over converged
> > >>> ethernet)
> > >>>
> > >>> Not sure where it is at right now, but RoCEv2 is on the research
> > > slide
> > >>> of the OpenVMS roadmap.
> > >>
> > >> Goodo.
> 
> Need an Aussie dictionary for that one.
> 
> 😊
> 
> > >>
> > >>>
> > >>> Imho, this type of cluster communications capability is critical to
> > > next
> > >>> generation cluster scalability of shared disk clusters.  It is how
> > > VSI
> > >>> can address the biggest counter argument to shared disk clusters -
> > >>> "shared disk clusters have scalability issues due to the requirement
> > > of
> > >>> a distributed lock manager"
> > >>
> > >> Oracle's DLM seems not to have these scalability issues.
> > >>
> > >
> > > Well, Oracle's DLM came from Tru64 UNIX DLM, which was a watered
> > down
> > > version of OpenVMS DLM, so I really do not see how the Oracle DLM
> > can be
> > > that much different from the OpenVMS DLM.
> > 
> > Educate yourself!
> > 
> > >
> > > Regardless, since few can afford Oracle Clustering, its no wonder you
> > do
> > > not hear any issues.
> > 
> > Oh I see, the cost conscious want VMS but not Oracle?
> > 
> 
> Last 10 years was all about reducing HW costs.
> 
> Next 10 years will be all about reducing SW costs.
> 
> Oracle, SAP and similar App / DB players with ridiculous pricing are in for some very tough years ahead. 
> 
> History - Windows/Linux X86-64 servers were never really considered technically "better" than Solaris/SPARC, OpenVMS/Tru64 Alpha etc in their prime.
> 
> However, Customers viewed Windows/Linux X86-64 as "good enough". 
> 
> Same thing is coming for the big SW companies.
> 
> [snip...]
> 
> Regards,
> 
> Kerry Main
> Kerry dot main at starkgaming dot com

Briefly, what I've seen about the cloud has many aspects, only a few align with outsourcing.  Not sure how much to go into that.


I was following the discussion on shared-everything vs. shared-nothing structures.  I've used both.  The RMS cache management was pretty expensive to run when I last looked at it.  It was especially bad for high write, high collision rate files.  This drove a different approach with the TP server in DECdtm.  It is structurally a shared nothing service on top of a shared everything access substrate.  It uses an unconventional leader election, in that the 'home' system always is the leader if it is alive, and the other systems elect one of themselves as the leader if it isn't.

(This was done via a pattern of use with the DLM, and I agree with Steve that either documenting the known patterns or encapsulating them for easier consumption could be useful)

This produced much better write performance, and good recovery availability times.  It allowed RDB to assume it had something like a cluster-wide TM without cross node overheads in the normal case.  At the time I thought this was a good hybrid between the two models.  There are aspects that I still think are.  If you have an efficient shared writable volume this is, I think, still a good design.  But I'm very aware that the aspects that matter can also be achieved with either remote storage servers (especially with rdma) or with direct replication (e.g. as you'd find with a Paxos log).

I think, but am not sure, that the Audit Server also used a leader election based shared nothing service on top of a shared volume.  Fwiw.


Let me add a caveat on the above.  I've been away from VMS for >15 years.  All my data on VMS is very old, and is likely very out of date.

Jim.