Re: Portents of VMS death
From: John Smith (a_at_nonymous.com)
Date: 06/05/03
- Next message: David J. Dachtera: "Re: [The Inquirer] "HP trying to dump OpenVMS ?""
- Previous message: John Smith: "Re: Would HP even consider offering customers VMS under Scenarios A, B, or C? Nah."
- In reply to: Main, Kerry: "RE: Portents of VMS death"
- Next in thread: leslie: "Re: Portents of VMS death"
- Reply: leslie: "Re: Portents of VMS death"
- Reply: Paul Sture: "Re: Portents of VMS death"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 05 Jun 2003 01:50:35 GMT
Sorry for top posting...
Every time I reply to a post of Kerry's, it never quotes
properly.......
Excerpted from http://h71033.www7.hp.com/object/rdfpd.html
"HP NonStop servers are at the top of the single-system
high-availability pyramid. But there are times when you want to
geographically distribute your application processing to protect it
from a site failure or regional disaster.
For more than a decade, major companies relying on the world's leading
fault-tolerant computing platform, the NonStop server, have also
turned to HP NonStop Remote Database Facility (RDF) software to
replicate critical data and enable uninterrupted service. With NonStop
RDF software, one can ignore the concept of primary and backup
systems, but think in terms of primary and backup databases. You can
implement a wide variety of configurations, including multiple backup
databases for each primary database or a single backup for multiple
primary databases. And every source and target system can be running
live transactions.
Using the audit log generated by HP NonStop Transaction Management
Facility (NonStop TMF) software, changes to primary databases are
instantaneously replicated to backup databases on one or more target
systems, no matter how many transactions per second your application
generates. If a primary database becomes inaccessible for any reason,
processing can continue using the backup database with minimal service
disruption or data loss.
NonStop RDF software only replicates databases designated as critical
by the customer. As transactions are applied to the primary database,
changes are replicated to the backup database, which can be used for
billing, decision support, reporting, or other activities. NonStop RDF
software does not place limits on the type or distance of the
communications link.
Application processes that cannot tolerate any data loss whatsoever
can request that transactions be lockstepped between the primary and
backup databases. A simple system call ensures that the process cannot
continue until the changed data is safely stored on the target
system.(2PC in other words??) The application decides which
transactions should or should not be lockstepped for maximum
flexibility.
Optimized throughput for instantaneous database mirroring
NonStop RDF software minimizes the effects of regional disasters by
efficiently sending audit trail information to one or more target
systems. Active throughput is approximately 3 megabytes per second per
audit trail, and if the two systems somehow become disconnected,
NonStop RDF can catch up at more than double that rate. Replication
scales linearly as audit trails are added, up to a total of 16. As
soon as the changes are received by a target system, they are safe
from a source system failure. "
.....
"There is no need to be offline after a takeover while a transaction
manager or database recovery tool scans logs searching for incomplete
transactions. NonStop RDF takeover processing takes only seconds to
complete. For the shortest possible takeover time, you can code your
applications to start up, then wait until NonStop RDF software
completes the takeover before beginning active work on the backup
database (see figure 3). If the target system is processing
transactions, such as in a split-workload arrangement, that processing
can continue without interruption. In fact, users on the target system
don't even know that the software is hard at work ensuring that the
backup database is transactionally consistent after a takeover. Users
who were on the source system can be up and running on the target
system within seconds. You can even perform the initial load of the
backup database while the primary database remains online."
All in all, I think I'd rather use a VMS cluster.
----------------------
"Main, Kerry" <Kerry.Main@hp.com> wrote in message
news:FD827B33AB0D9C4E92EACEEFEE2BA2FB0588F8@tayexc19.americas.cpqcorp.
net...
JF -
NSK based systems use NonStop RDF (remote data facility i.e.
replication) for disaster tolerance. NSK is based on a shared nothing
architecture which means one master writer and then replicate those
updates to other facilities.
NSK does not support active-active clusters where different systems
directly update the same data at the same time. There are advantages
and
disadvantages with both approaches.
Reference:
http://h71033.www7.hp.com/page/RDF_SW.html
------------------
> -----Original Message-----
> From: JF Mezei [mailto:jfmezei.spamnot@istop.com]
> Sent: June 4, 2003 5:43 PM
> To: Info-VAX@Mvb.Saic.Com
> Subject: Re: Portents of VMS death
>
>
> Rob Young wrote:
> > From: Andy Glew <glew@cs.wisc.edu>
> > And the Bank of Nova Scotia used to have its Tandem nodes
> in Halifax,
> > Montreal, Norway, and somewhere in the Caribbean.
>
>
> As of 1992, Tandem was still not able to "cluster" across
> buildings like VMS
> could. They could do the equivalent of decnet, with
> transaction replication
> which would require some "rebuild" to get the backup nodes back up.
>
> Also, if you are talking about POS/ATM controllers (used in
> banks), yes, you
> could have Tandems in various cities collecting transactions
> from local
> "terminals" and doing preliminary validation and then using a
> link to send the
> transaction to the IBM mainframe in the toronto head office.
> This is not a
> question of "clustering" but rather distributed processing.
>
> In banks, Tandems are used as glorified communications
> controllers/buffers.
> They handle the transaction and then forward it to the
> appropriate mainframe
> for processing (for instance, when using Bank A card at Bank
> B machines, the
> Tandem is what routes the transaction over). And the Tandem
> will buffer
> transactions for its own bank when that bank's mainframe is
> down (blindly
> authorized up to a certain amount, no matter what you
> actually have in your
> account), and once the mainframe is back up, will transfer
> those transactions
> to the mainframe for processing. (hint: if you do a
> transaction at an ATM and
> your bank balance is not available, it means that the ATM is
> "offline" and
> transcation won't actually execute until the mainframe is back up)
>
> With tandem, you have a backup process running on a different
> CPU with the
> application written to keep the backup process in sync so
> that it can pickup
> if the primary one fails. This means memory interface between
> 2 CPUs, dual
> disk access etc etc. Doing this across buildings would
> require shared memory
> access via fibre. VMS can't do that yet, in a galaxy, shared
> memory between
> VMS instances has to be in the same box too.
>
> Now, Tandem may have solved the shared memory issue since I
> last had a serious
> look at it. (which would give it quite an edge over VMS).
>
- Next message: David J. Dachtera: "Re: [The Inquirer] "HP trying to dump OpenVMS ?""
- Previous message: John Smith: "Re: Would HP even consider offering customers VMS under Scenarios A, B, or C? Nah."
- In reply to: Main, Kerry: "RE: Portents of VMS death"
- Next in thread: leslie: "Re: Portents of VMS death"
- Reply: leslie: "Re: Portents of VMS death"
- Reply: Paul Sture: "Re: Portents of VMS death"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
