Components of VVR

This section explains the components of VVR, which contain configuration information. The components include:

• Replicated Volume Group (RVG)
• Storage Replicator Log (SRL)
• Replication Link---RLINK
• Data Change Map (DCM)

Sample Configuration to Illustrate the Different VVR Components



Click the thumbnail above to view full-sized image.

Replicated Volume Group

In the case of a database, several processes perform writes to disks. Database processes write in a specific order. This order must be maintained at all times including when recovering from a disk failure. For example, the database posts any database change to the log before writing to the table space. To convey to VVR that these two volumes are related, these two volumes must be grouped.

A Replicated Volume Group (RVG) is a group of volumes within a given VxVM disk group configured for replication. An RVG is always a subset of a VxVM disk group. One or more related volumes in a disk group can be configured as an RVG. By related volumes, we mean a set of volumes to which application writes must be replicated in order on the Secondary.

All related volumes must be part of the same disk group. Unrelated volumes must not be grouped together in an RVG. Multiple RVGs can be configured inside one disk group, although this is not a recommended configuration.

Volumes that are associated with an RVG and contain application data are called data volumes. The data volumes in the RVG are under the control of an application, such as a Database Management System, that requires write-order fidelity among the writes to the volumes.

Write-ordering is strictly maintained within an RVG during replication to ensure that each remote volume is always consistent, both internally and with all other volumes of the group. Each RVG can have a maximum of 1023 data volumes. VVR replicates data from a Primary RVG to a Secondary RVG.

The concept of Primary and Secondary is per RVG, not per system. A system can simultaneously be a Primary host for some RVGs and Secondary host for others. An RVG also contains the Storage Replicator Log (SRL) and Replication Link (RLINK), which are explained in the following sections in Storage Replicator Log and Replication Link---RLINK.

Storage Replicator Log

The Storage Replicator Log (SRL) is a circular buffer of writes for an RVG. Each RVG contains one SRL. Writes to the data volumes in the RVG are first queued in the SRL on the Primary host before they are sent to the Secondary. VVR uses the SRL to track the order of writes to data volumes in the RVG. The SRL enables VVR to maintain write-order fidelity at the Secondary RVG.

From a VxVM perspective, the SRL is just another volume. Because all writes are written to the SRL first, it is important for the SRL to have optimum write performance. This means all performance techniques used to increase write performance of a volume apply to the SRL. For most implementations, the SRL is striped across multiple drives for write performance, and mirrored to an equal set of drives for protection.

Each write to the disks generates two writes: one to the SRL, and one to a data volume. For this reason, the data volumes and SRL volumes must be configured on different physical disks to improve write performance. Note that VVR does not allow application writes to the SRL.

The SRL on the Secondary host performs a different function from the one on the Primary. Under normal operations, the Secondary SRL is not used. While VVR is recovering after a temporary failure in communication between the Primary and Secondary, or from a Primary or Secondary host failure, certain writes are stored in the Secondary SRL and applied together to maintain data consistency. This ensures that the Secondary transitions from one consistent data state to another.

Replication Link---RLINK

An RLINK is associated with an RVG and establishes the link between the Primary and a Secondary RVG. Each RLINK associated with a Primary RVG represents one Secondary. Each RLINK associated with a Secondary RVG represents a Primary. The attributes of an RLINK specify the replication parameters for the corresponding Secondary. For example, the network to be used for replication between the Primary and the Secondary can be specified as the attribute of the RLINK.

A Primary RVG can have up to 32 associated RLINKs. Although a Secondary RVG can also have 32 associated RLINKs, it can have only one active RLINK; this active RLINK represents the Primary that is currently replicating to this Secondary RVG.

VVR reads data from the SRL and sends it to each Secondary. Each Secondary receives data at its own rate. A write is removed from the SRL when all the Secondary RVGs have successfully received the writes. If a Secondary does not keep up with the write rate, the SRL could overflow for the corresponding RLINK.

Data Change Map

VVR uses the Data Change Map (DCM) to track writes when the SRL overflows and thus enables you to avoid complete resynchronization of the data on the Secondary. DCM is a component of VVR that contains a bitmap and can be optionally associated with a data volume on the Primary RVG. It is almost identical to the DRL in a VxVM volume, but the bits represent ranges that are different between the Primary and the Secondary, rather than between mirrors.

While the DCM is active, each bit that has been set in the DCM represents a region whose contents are different between the Primary and the Secondary. The DCM becomes active only when the SRL is no longer large enough to hold accumulated updates. At an appropriate time, the administrator initiates a resynchronization and causes VVR to incrementally synchronize the Secondary with the Primary by looking up the bitmap. Note that the Secondary is inconsistent between the time the DCM resynchronization starts and completes because write-order fidelity is not preserved. After the resynchronization is complete, the Secondary RVG is consistent and replication resumes as usual.

The Automatic Synchronization, SRL Overflow Protection with DCM, and Fast Failback features use the DCM. Each data volume in the RVG must have a valid DCM associated with it before the DCM can be used.

Under normal circumstances, writes are sent to the Secondary in the order in which they are received at the Primary. Consequently, the Secondary data is consistent with the Primary and can be used to take over the Primary if a disaster occurs. Note that under normal circumstances, the DCM is not in use.

When the resynchronization of the DCM starts, the Secondary becomes inconsistent because the DCM resynchronization writes are not necessarily in the same order as the application writes. The Secondary becomes consistent only after the resynchronization of the DCM is complete. As a result, the Secondary cannot be used for disaster recovery while the DCM resynchronization continues.