Re: Keep VM 24X7 365 days
Anne & Lynn Wheeler
Tom Duerbusch wore:
> There are multiple layers to this...
>
> 1. As others have said, you can switch to another LPAR on the same or
> different hardware.
> 2. I've read about, but haven't actually used, a facility in Linux to
> switch a work load from one Linux machine to another. I think that
> started in SLES8.
> 3. The major applications, such as Oracle, have a facility to switch
> to another Oracle image running somewhere else (with both being in
> sync).
>
> It all depends on what you need and what you are willing to pay for.
> That last few minutes towards true 24X7 is rather costly.
>
> It isn't really a VM issue because VM isn't a true 24X7 operation
> system. With VM, we can fake things and come close to true 24X7, but
> compared to z/OS and parrallel sysplex, not close.
some recent postings with old historical references
a couple recent posts about fast recovery after failure
http://www.garlic.com/~lynn/2007c.html#21
http://www.garlic.com/~lynn/2007c.html#41
i had worked on complete rewrite of i/o subsystem for the disk
engineering and product test labs (bldg. 14&15) ... when I started
they were doing all their "testcell" testings in stand-alone
environment. They had done some attempts with MVS ... but at the time,
MVS MTBF (system crash or hang) was 15 minutes. The point of i/o
subsystem rewrite was to make it absolute bullet proof so that they
could have "on-demand" testing with multiple concurrent "testcells".
http://www.garlic.om/~lynn/subtopic.html#disk
some of this got me in lots of trouble with manager of MVS RAS
when I happen to mention some of it (like it was my fault that
MVS was crashing) ... reference to one example:
http://www.garlic.com/~lynn/2007.html#2
with old email example
http://www.garlic.com/~lynn/2007.html#email801015
another recent with old reference:
http://www.garlic.com/~lynn/2007b.html#28
then there is internal distribution of combination of lots
of enhancements
http://www.garlic.com/~lynn/2007c.html#12
that includes old email about it drastically improving
uptime at STL (now called silicon valley lab)
http://www.garlic.com/~lynn/2007c.html#email830709
There was a project in this time frame SJR to do a high availability
configuration with multiple vm/4341s ... however it ran into a lot of
internal corporate political problems. Pieces had to be significantly
modified (resulting in functional and performance degradation) before
any of it shipped. This was sort of in the same time-frame as R-Star
and Starburst. System/R was the original relational/sql implementation
done on VM. R-Star and Starburst were followon distributed efforts
http://www.garlic.com/~lynn/subtopic.html#systemr
Of course, when we got around to doing real HA product,
it wasn't with VM or mainframes
http://www.garlic.com/~lynn/subtopic.html#hacmp
In HA/CMP we had actually done the work on scaleup with
Oracle ... some past references
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/2007b.html#16
with old email
http://www.garlic.com/~lynn/2007b.html#email910928
A lot of work involved doing the DLM (distributed lock manager) for
HA/CMP ... since then, similar implementations with similar fall-over
recovery implementations have appeared.
My wife had earlier been con'ed into going to POK to be
in charge of loosely-coupled architecture. While there she
had created the peer-coupled shareddata architecture
http://www.garlic.com/~lynn/subtopic.html#shareddata
However, except for IMS hotstandby, there wasn't a lot
of uptake until sysplex.