Filter
Top Products
Disk Environment Overview 97
database would be corrupted and would have to be recovered from image copies
and log data. In all cases notification of this miss must be known at secondary.
When that happens for hundreds of volumes, without a clear notification of status
of impacted secondary volumes, recovery can be extremely long. For more
information on this topic, please refer to
RAMAC Virtual Array: Implementing
Peer-to-Peer Remote Copy
, SG24-5338.
Figure 29 on page 97 shows time-sequenced I/O writes in a synchronous remote
copy environment.
Figure 29. Time Sequenced I/Os
9.5.4.2 Geographically Dispersed Parallel Sysplex
Currently some System/390 platform users have set up a sysplex over multiple
sites for availability, capacity, and/or workload balancing reasons. However, these
configurations provide reduced continuous application availability because, if a
disaster occurs at the site where the data resides, the surviving portion of the
sysplex will be down until lengthy data recovery actions can be completed.
Moreover, data recovery can be expected to be incomplete and may lag actual
production status by up to 24 hours.
A
geographically dispersed parallel sysplex (GDPS) is a multisite availability
solution that merges sysplex and remote copy technologies. GDPS provides an
integrated disaster survival capability that addresses the system, the network,
and the data parts of an application environment.
The primary objective of GDPS is to minimize application outages that would
result from a site failure by ensuring that, no matter what the failure scenario is at
the failing site, data in the surviving site is consistent and is therefore a valid base
for a quick application restart. An
installation-defined policy determines whether
the switch will occur with limited loss or no loss of data.
In the event of a site failure (including disasters), the surviving site will continue to
function and absorb the work of the failed site. In the event of a planned site
outage, the workload executing in the site undergoing a planned outage will be
quiesced and restarted at the other site. Current experience indicates that for
large operational sites a
planned switch from one site to the other takes less than
60 minutes (including networking), and
site unplanned outage recovery takes less
than 45 minutes. Only a single keystroke is required to invoke a GDPS action.
The Need for Time-Consistency
Many examples where the start of
one write is time dependent on
the completion of a previous write
Data base & log
Catalogs, VTOCs
Index & data components
Time sequence could be
exposed in remote copy
To be managed through
PPRC Critical attribute
Automation / Freeze function
P
LOG
S
LOG
P
DB
S
DB
(1) Log update
(3) Mark DB
update
complete
(2) DB update