[Info-vax] Distributed Applications, Hashgraph, Automation

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of Jim
> Johnson via Info-vax
> Sent: February 18, 2018 12:59 PM
> To: info-vax at rbnsn.com
> Cc: Jim Johnson <jjohnson4250 at comcast.net>
> Subject: Re: [Info-vax] Distributed Applications, Hashgraph, Automation
> 

[snip...]

> 
> 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.
> 

Imho - Just as there are many different types of public cloud there are many different types of outsourcing, but the basics are the same.

Some outsourcers provide a gui based service catalogue that has work flows supporting automation, work flows and approvals etc.

While many like to think the GUI based "point-click" to create some VM's is cool or new technology, this is really only a GUI based service catalogue which has been part of ITSM for decades.

In reality there are a number of third party commercial add-ons to VMware that will do this exact thing for internal private clouds aka internal shared services aka the "IT Utility".

> 
> 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.

Jim - I don't think we ever met while you were at DEC, but I have had numerous "solving the problems of the world" brew sessions with J Apps and M Keyes who speak very highly of you as being one of the industry leaders in file system / TP designs, so your feedback is more than welcome here.

😊

For those not familiar with Jim's past work, check this out:
<http://www.hpl.hp.com/hpjournal/dtj/vol8num2/vol8num2art1.pdf>

Btw, from what I understand, the new file system (VAFS?) VSI is working on right now is being designed to address some of the issues you mentioned.

You may find this interesting:
<http://www.hp-connect.se/SIG/New_File_System_VMS_Boot%20Camp_2016.pdf>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com