RDF/IMP, IMPX, and ZLT System Management Manual

Zero Lost Transactions (ZLT)
HP NonStop RDF/IMP, IMPX, and ZLT System Management Manual—524388-002
16-4
Hardware Setup
If you lose the primary system to a disaster and that disaster does not affect the
standby and backup systems, no committed transactions are lost because RDF on
the backup system can fetch all missing audit records from the remote mirrors. If a
regional disaster takes down both the primary and the standby systems, however, you
can still resume business on the backup system but without the ZLT guarantee (some
transactions committed on the primary system may be lost).
There is one risk to the ZLT guarantee. If the primary system fails in a way where the
remote mirrors become inaccessible, and if transaction processing continues for some
number of seconds through use of the local mirrors, some committed transactions
could be lost. How many committed transactions are lost depends upon how long the
extractor on the primary system can continue to send audit records before being
stopped by the unplanned outage. Note, however, that if an unplanned outage makes
the local mirrors inaccessible first, the ZLT guarantee still applies because the audit
trail write operations still proceed to the remote mirrors.
Hardware Setup
To set up RDF for ZLT with remote mirror capability you must have established your
hardware setup first. That is, you must set up remote mirroring for every audit-trail
volume that relates to the RDF environment before you configure RDF.
Documentation for the various hardware considerations is available in the appropriate
sections of the ServerNet Nomadic Disk (Release 2) Installation and Service Guide
and the ServerNet Nomadic Disk (Release 2) User's Guide.
Assigning CPUs on the Standby System
By default, the same CPUs configured for each extractor on the primary system are
used for the corresponding extractor on the standby system, provided that both the
necessary primary and backup CPUs are available on the standby system.
If the necessary primary or backup CPU for an extractor is not available on the standby
system, the RDF monitor process selects from those CPUs that are available. If the
monitor must select the primary CPU for all extractors, it puts the primary processes of
the extractors in as many different CPUs as possible to achieve load balancing;
however, only if there are enough CPUs. If, for example, you have six extractors
configured, but you only have two CPUs on your standby system, the monitor places
the primary processes of three extractors on one CPU and the primary processes for
the other three extractors on the other CPU. Note that if the monitor process selects
the primary CPU of an extractor and the configured backup CPU is not available on the
standby system, then the extractor does not run as a process pair; it only has the
primary process.
Note. Because the remote mirrors will be connected to your standby system in the
event of an unplanned takeover, you should choose disk names that will not conflict
with disks already connected to the standby system.