Implementing Off-Host Point-In-Time Copy Solutions

As shown in Example Implementation of an Off-Host Point-In-Time Copy Solution, by accessing snapshot volumes from a lightly loaded host (shown here as the OHP host), CPU- and I/O-intensive operations for online backup and decision support are prevented from degrading the performance of the primary host that is performing the main production activity (such as running a database). Also, if you place the snapshot volumes on disks that are attached to host controllers other than those for the disks in the primary volumes, it is possible to avoid contending with the primary host for I/O resources. To implement this, paths 1 and 2 shown in the following figures should be connected to different controllers.

Example Implementation of an Off-Host Point-In-Time Copy Solution

Click the thumbnail above to view full-sized image.

The figure Example Connectivity for Off-Host Solution Using Redundant-Loop Access gives an example of how you might achieve such connectivity using Fibre Channel technology with 4 Fibre Channel controllers in the primary host. This layout uses redundant-loop access to deal with the potential failure of any single component in the path between a system and a disk array.

Example Connectivity for Off-Host Solution Using Redundant-Loop Access

Click the thumbnail above to view full-sized image.

Example Implementation of an Off-Host Point-In-Time Copy Solution Using a Cluster Node shows how off-host processing might be implemented in a cluster by configuring one of the cluster nodes as the OHP node.

Example Implementation of an Off-Host Point-In-Time Copy Solution Using a Cluster Node

Click the thumbnail above to view full-sized image.

Alternatively, the OHP node could be a separate system that has a network connection to the cluster, but which is not a cluster node and is not connected to the cluster's private network. This arrangement is illustrated in Example implementation of an Off-Host Point-In-Time Copy Solution Using a Separate OHP Host.

Example implementation of an Off-Host Point-In-Time Copy Solution Using a Separate OHP Host

Click the thumbnail above to view full-sized image.

Using VERITAS FlashSnap to implement Off-Host Processing Solutions illustrates the steps that are needed to set up the processing solution on the primary host. Disk Group Split/Join is used to split off snapshot volumes into a separate disk group that is imported on the OHP host.

Using VERITAS FlashSnap to implement Off-Host Processing Solutions

Click the thumbnail above to view full-sized image.

Data Integrity in Volume Snapshots

A volume snapshot represents the data that exists in a volume at a given point in time. As such, VxVM does not have any knowledge of data that is cached by the overlying file system, or by applications such as databases that have files open in the file system. If the fsgen volume usage type is set on a volume that contains a VERITAS File System (VxFS), intent logging of the file system metadata ensures the internal consistency of the file system that is backed up. For other file system types, depending on the intent logging capabilities of the file system, there may potentially be inconsistencies between in-memory data and the data in the snapshot image.

For databases, a suitable mechanism must additionally be used to ensure the integrity of tablespace data when the volume snapshot is taken. The facility to temporarily suspend file system I/O is provided by most modern database software. The examples provided in this document illustrate how to perform this operation. For ordinary files in a file system, which may be open to a wide variety of different applications, there may be no way to ensure the complete integrity of the file data other than by shutting down the applications and temporarily unmounting the file system. In many cases, it may only be important to ensure the integrity of file data that is not in active use at the time that you take the snapshot.

Choices for Snapshot Resynchronization

When a snapshot volume is reattached to its original volume within a shared disk group, there are two choices for resynchronizing the data in the volume:

• Resynchronize the snapshot from the original volume---updates the snapshot with data from the primary volume that has changed since the snapshot was taken. The snapshot is then again ready to be taken for the purposes of backup or decision support.
• Resynchronize the original volume from the snapshot---updates the original volume with data from the snapshot volume that has changed since the snapshot was taken. This may be necessary to restore the state of a corrupted database or file system, or to implement upgrades to production software, and is usually much quicker than using alternative approaches such as full restoration from backup media.