Building Disaster Recovery Serviceguard Solutions Using Continentalclusters for Linux B.01.00.00

Maintaining the data replication environment
Continentalclusters supports the pre-integrated physical replication solutions using Continuous
Access P9000 and XP, Continuous Access EVA, and 3PAR Remote Copy.
• See, “Maintaining Continuous Access P9000 and XP Data Replication Environment” (page 47)
for administering Continentalclusters when the Continentalclusters solution is built on Continuous
Access P9000 and XP for the physical data replication.
• See, “Maintaining Metrocluster with Continuous Access EVA P6000 for Linux data replication
environment” (page 49) for administering Continentalclusters when the Continentalclusters
solution uses Continuous Access EVA.
• See, “Maintaining 3PAR Remote Copy data replication environment” (page 49) for
administering Continentalclusters when the Continentalclusters uses 3PAR Remote Copy data
replication solution.
Maintaining Continuous Access P9000 and XP Data Replication Environment
Resynchronizing the device group
After certain failures, data is no longer remotely protected. In order to restore disaster-tolerant data
protection after repairing or recovering from the failure, you must manually run the command
pairresync. This command must run successfully for disaster-tolerant data protection to be
restored. Following is a partial list of failures that require running the pairresync command to
restore disaster-tolerant data protection:
• Failure of ALL Continuous Access links without restart of the application.
• Failure of ALL Continuous Access links with Fence Level DATA with restart of the application
on a primary host.
• Failure of the entire recovery Data Center for a given application package.
• Failure of the recovery P9000 and XP disk array for a given application package while the
application is running on a primary host.
Following is a partial list of failures that require full resynchronization to restore disaster-tolerant
data protection. Resynchronization is automatically initiated by moving the application package
back to its primary host after repairing the failure.
• Failure of the entire primary Data Center for a given application package.
• Failure of all of the primary hosts for a given application package.
• Failure of the primary P9000 and XP disk array for a given application package.
• Failure of all Continuous Access links with application restart on a secondary host.
NOTE: The preceding steps are automated provided the default value of 1 is being used for the
auto variable AUTO_PSUEPSUS. After the Continuous Access link failure is fixed, you must halt
the package at the failover site and restart on the primary site. However, if you want to reduce
downtime, you must manually invoke pairresync before failback.
Full resynchronization must be manually initiated (as described in the next section) after repairing
the following failures:
• Failure of the recovery P9000 and XP disk array for a given application package followed
by application startup on a primary host.
• Failure of all Continuous Access links with Fence Level NEVER or ASYNC with restart of the
application on a primary host.
Pairs must be manually recreated if both the primary and recovery P9000 and XP disk arrays are
in the SMPL (simplex) state.
Maintaining the data replication environment 47