[Info-vax] Wide area cluster, metro area network, seeking info

[Rich Jordan]

On Wednesday, June 16, 2021 at 4:30:59 PM UTC-5, Phillip Helbig (undress to reply) wrote:
> In article <4c3af469-77db-4d79... at googlegroups.com>,
> Rich Jordan <jor... at ccs4vms.com> writes: 
> 
> > More info. The base requirement is to have a backup system at an existing 
> > remote office; this backup system will be kept 'up to date' and available 
> > for use if the primary site or system fails.
> OK. If you have a cluster which is set up properly, then all of that 
> stuff just works.
> > One option is nightly backup/restore operations, so (up to) one day latency
> > .. This is considered the low end of acceptable. The customer asked about
> > options for keeping the backup closer to current.
> With HBVS, the latency is essentially zero. A WRITE won't complete 
> until all members have been written to. Split the shadow set across the 
> locations.
> > The system cannot be quiesced during production hours (about 11 hours per 
> > day weekdays) so we cannot run periodic backups during those hours. Programs 
> > just were not written that way.
> Another reason to go with a cluster and HBVS.
> > Since we can't do intraday backups, one option is shadowing, and so 
> > clustering. I didn't mention HBVS (my bad) but its the reason for the 
> > cluster option.
> OK.
> > I was mainly looking for info about running a cluster over a WAN 
> > connection/metro area network in case anyone had that experience, since 
> > much of the documentation available is pretty old and seems to 
> > concentrate on using FDDI bridges over what are currently modest speed 
> > links.
> These days, one can run a cluster over IP.
> > VSI _is_ involved and we are working with them on this possibility. At 
> > this point I think the additional license subscription costs are going 
> > to kill the HBVS/cluster option, especially if a third node was needed 
> > (and a third location and connection, and set of licenses). That means 
> > going with the one-day latency backup option and generating and testing 
> > the procedures for failing back to the main system when it is available 
> > again.
> I don't know what the license costs are. But with a cluster, someone 
> familiar with VMS could keep an eye on it in his spare time. With the 
> other option, someone will have to spend much more time on it. What are 
> salary costs?


Keeping shadowset on the main system and splitting off a member for backups periodically is possible but again given the nature of these programs and how they were written, NOT guaranteed to be 'transaction complete'.  Sure individual writes will be done but a program updating records across multiple files can still see a shadow member dismounted when it has finished one file but not the other.  We don't have transaction safe processing; this is old but very stable code running on RMS files.

I will ask about distributing the storage; that's outside my area of expertise.  We did almost all small-med VMS business, and like wide area distributed clusters, that kind of configuration just never came up.