Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

Pull-Based Replication
In addition to disk-based journaling, Continuous Access Journal uses pull-style replication. The
primary storage system does not dedicate resources to pushing data across the replication link.
Rather, a replication process on the remote system pulls the data from the primary system's journal
volume, across the Continuous Access link, and writes it to the journal volume at the receiving site.
The replication process then applies the journaled writes to the remote data volumes, using metadata
and consistency algorithms to ensure data integrity.
In the default configuration, Continuous Access Journal considers replication complete when the
data is received in mirrored system cache at the remote system, written to the journal disk, and
applied to the remote data volumes. Since the process that controls asynchronous replication is
located on the remote system, this approach shifts most of the replication workload to the remote
site, reducing resource consumption on the primary storage system. In effect, Continuous Access
Journal restores primary site storage to its intended role as a transaction processing resource, not
a replication engine. The pull-style replication engine also contributes to resource optimization. It
controls the replication process from the secondary system and frees up valuable production
resources on the primary system.
Mitigation of Network Problems
In Continuous Access Asynchronous replication, typical issues include temporary communication
problems, such as Continuous Access link failure or insufficient bandwidth for peak-load
requirements. These conditions can cause cache-based “push” replication methods to fail. When
this happens, traditional replication solutions suspend the replication process and go into bitmap
mode, noting changed tracks in a bitmap for future resynchronization. Recovery typically involves
a destructive process such as rewriting all the changed tracks, with possible loss of data consistency
for ordered writes.
In contrast, Continuous Access Journal logs every change to the journal disk at the primary site,
including the metadata needed to apply the changes consistently. Should the replication link
between sites fail, Continuous Access Journal keeps logging changes in the local journal so that
they can be transmitted later, without interruption to the protection process or the application. The
journal data is simply transferred after the network link failure or bandwidth limitation is corrected,
with no loss of consistency. The recovery time may be extended a bit during temporary link failures
or congestion, but the asynchronous replication process does not fail, and the catch-up process is
simple and automatic. Data consistency is preserved.
With Continuous Access Journal, the remote storage system pulls data from the primary journal
volumes over the data replication network as fast as the bandwidth allows while adjusting to
available network conditions. If available bandwidth does not support optimal replication, such
as during peak-load spikes in transaction volume, the primary journal volumes buffer the data on
disk until more bandwidth becomes available.
Fence Level
The Continuous Access Journal has the asynchronous data replication characteristic. In P9000 or
XP, the fence level of the Continuous Access journal is defined to “async”, the same as the
Continuous Access Asynchronous fence level.
Journal Group
The journal group is a component of the Continuous Access Journal operations that consists of two
or more data and journal volumes. The data update sequence from the host is managed per the
journal group. This ensures the data update sequence consistency between the paired journal
groups is maintained.
Journal groups are managed according to the journal group number. The paired journal numbers
of journal groups can be different. One journal group can have more than one data volume and
journal volume belong to it.
160 Building Disaster Recovery Serviceguard Solutions Using Metrocluster with Continuous Access for P9000 and XP