Filter
Top Products
Disk Environment Overview 99
During normal operations GDPS continuously monitors all systems and
specifically looks for messages indicating that PPRC volume pairs are being
suspended. At the occurrence of a
suspend, GDPS immediately freezes the
image of the secondary disk configuration, to ensure
restartability of the
applications in the backup location.
The next step is to analyze the reason for the suspend, because each cause can
have different levels fo effect. For instance, if the suspend was caused by a
secondary equipment problem, it makes sense not to interrupt primary application
processing. However, if the suspend was caused by a primary equipment failure,
then GDPS, after having stopped the secondary device updates, will either allow
applications to continue or force them to stop. The choice is driven by an
installation policy. If the failure is part of a disaster unfolding in the primary
location, workload restartability is ensured by freezing the secondary data image.
If the primary site applications were stopped, no data loss will ever occur.
Automation taking control at a suspend event is possible because the storage
server starts an
automation window when a suspend condition is detected. The
write operation that forced the condition to surface is not completed until the
automation has taken specific action. The automation window is essential in
taking control at the right moment and ensuring data consistency in the backup
location.
If there is a need to make the switch to the backup facility, GDPS executes all the
mechanics of removing the failed site systems from the sysplex, changing the
status of the former secondary disk configuration to bring the primary back up,
switching the network to the backup location, reconfiguring processor capacity in
the surviving site as required to support the fallback mode of operation, and
finally restarting the application.
9.5.4.3 Extended Remote Copy
XRC is the asynchronous implementation of remote copy. Copies are also
established by disk volume, but there is the concept of
session, which relates a
number of disk volumes that may be associated with the same application. The
remote copies are managed by session, and
write sequence consistency is
maintained across all disk volumes. Although the
data currency at the secondary
may
lag behind the primary by some seconds or minutes, the consistency of the
data is preserved even where data is spread across multiple LCUs or storage
servers. Figure 31 on page 100 describes the XRC data flow.
Preservation of the write sequence consistency enables easier recovery of any
database management system at the secondary site in the event of the disaster.
XRC is implemented through the System Data Mover (SDM) function of DFSMS.
For DB2, the recovery is easier because all volumes are brought to a
consistent
status
,soaDB2 restart can be done. The way to ensure recoverability is to use
the ERRORLEVEL=SESSION parameter and to place all DB2 volumes in the
same XRC session.
The ability to perform a DB2 restart means that recovery at the secondary site
may be as quick as a recovery from a failure on the production system. The only
drawback to an asynchronous implementation of remote copy is that the currency
of the data may lag behind the primary system. This may result in some
transactions having to be manually reentered after recovery at the secondary