[Info-vax] IS everyone waiting?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of David Froble via Info-vax
> Sent: 26-Oct-16 1:15 PM
> To: info-vax at rbnsn.com
> Cc: David Froble <davef at tsoft-inc.com>
> Subject: Re: [Info-vax] IS everyone waiting?
> 
> Kerry Main wrote:
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On
> Behalf Of
> >> Phillip Helbig undress to reply via Info-vax
> >> Sent: 26-Oct-16 2:03 AM
> >> To: info-vax at rbnsn.com
> >> Cc: Phillip Helbig undress to reply
> >> <helbig at asclothestro.multivax.de>
> >> Subject: Re: [Info-vax] IS everyone waiting?
> >>
> >> In article <nup4f2$mfb$1 at dont-email.me>, David Froble
> >> <davef at tsoft-inc.com> writes:
> >>
> >>> Now, maybe I'm going off topic a bit, but, why cannot
> process
> >> (and
> >>> login) context be preserved should part of the cluster be
> > lost?
> >> Well, a process is running on one CPU.
> >>
> >>> Or is that more of something for Non-Stop?
> >> Sure, it's doable somehow, but not with any system as
> common or more
> >> so than VMS.
> >>
> >
> > There are 2 scenario's here-
> >
> > 1. Planned dynamic process migration to a different system in
a
> > cluster;
> 
> Personally, I don't see much benefit in this idea.  Yes, I'm
sure
> some might think it's valuable, but, I don't believe it
provides any
> value, on a cost vs value scale.
> 

- Being able to apply kernel or other patches that require
reboots without kicking people off the system - just "migrate
them" before the patching. Could even be done in prime time
instead of paying OT or weekend work (assuming other servers can
handle loads).

- being able to migrate a long running batch process to another
server 

- being able to dynamically balance workloads across different
systems in cluster

> > 2. Unplanned process migration to a different system (server
> failure
> > etc.) in a cluster;
> 
> Now, I do see value in this idea.  If absolute up time to
finish
> transactions, jobs, whatever is actually required.
> 
> Regardless, I question the wisdom of investing any effort into
> either.  Decent applications have appropriate safeguards to
avoid
> loss of data and / or work.
> No matter what is done, there will be a scenario that is not
> adequately covered.
>   Better to figure that sooner or later, shit will happen, and
be
> slightly prepared for recovery when it does.
> 
> Frankly, I can come up with a rather long list of features
better
> worked on than the topic(s) above.
> 

Unplanned downtime is less of an issue as the HW today is more
reliable than in the past.

However, maintaining App service performance and uptime SLA's is
becoming more critical, so things like dynamic process migration
would help things like upgrades, patches etc. to be much more
transparent and easier to implement.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com