Using Storage-Based Data Replication

Storage-based data replication uses software installed on the storage device to manage the replication. Such software is specific to your particular storage device. Always refer to the documentation that shipped with your storage device when configuring storage-based data replication.

Depending on the software you use, you can use either automatic or manual failover with storage-based data replication. Sun Cluster supports both manual and automatic failover of the replicants with Hitachi TrueCopy software.

This section describes storage-based data replication as used in a campus cluster. Figure 4–2 shows a sample two-room configuration where data is replicated between two storage arrays. In this configuration, the primary storage array is contained in the first room, where it provides data to the nodes in both rooms. The primary storage array also provides the secondary storage array with replicated data.

During normal cluster operation, the secondary storage array is not visible to the cluster. However, if the primary storage array becomes unavailable, the secondary storage array can be manually configured into the cluster by a Sun service provider.

As shown in Figure 4–2, the quorum device is on an unreplicated volume. A replicated volume cannot be used as a quorum device.

Figure 4–2 Two-Room Configuration With Storage-Based Data Replication

Storage-based data replication can be performed synchronously or asynchronously in the Sun Cluster environment, depending on the type of application that is used.

Requirements and Restrictions When Using Storage-Based Data Replication

To ensure data integrity, use multipathing and the proper RAID package. The following list includes considerations for implementing a campus cluster configuration that uses storage-based data replication.

• Node-to-node distance is limited by the Sun Cluster Fibre Channel and interconnect infrastructure. Contact your Sun service provider for more information about current limitations and supported technologies.

• Do not configure a replicated volume as a quorum device. Locate any quorum devices on an unreplicated volume.

• Ensure that only the primary copy of the data is visible to cluster nodes. Otherwise, the volume manager might try to access both primary and secondary copies of the data, which could result in data corruption because the secondary copy is read-only.

• When you create a disk group or diskset that is using replicated devices, use the same name for the disk group or diskset and the Hitachi TrueCopy replica pair.

• Refer to the documentation that was shipped with your storage array for information about controlling the visibility of your data copies.

• Particular application-specific data might not be suitable for asynchronous data replication. Use your understanding of your application's behavior to determine how best to replicate application-specific data across the storage devices.

• If configuring the cluster for automatic failover, use synchronous replication.

  For instructions on configuring the cluster for automatic failover of replicated volumes, see Administering Storage-Based Replicated Devices.

Requirements and Restrictions for Automatic Failover With Storage-Based Replication

The following restrictions apply to using storage-based data replication with automatic failover.

• Oracle Real Application Clusters (RAC) is not supported.

• Only synchronous mode is supported.

• Replicated devices cannot be quorum devices.

• CVM and Solaris Volume Manager for Sun Cluster are not supported.

Manual Recovery Concerns When Using Storage-Based Data Replication

As with all campus clusters, those clusters that use storage-based data replication generally do not need intervention when they experience a single failure. However, if you are using manual failover and you lose the room that holds your primary storage device (as shown in Figure 4–2), problems arise in a two–node cluster. The remaining node cannot reserve the quorum device and cannot boot as a cluster member. In this situation, your cluster requires the following manual intervention:

1. Your Sun service provider must reconfigure the remaining node to boot as a cluster member.

2. You or your Sun service provider must configure an unreplicated volume of your secondary storage device as a quorum device.

3. You or your Sun service provider must configure the remaining node to use the secondary storage device as primary storage. This reconfiguration might involve rebuilding volume manager volumes, restoring data, or changing application associations with storage volumes.

Best Practices When Using TrueCopy for Storage-Based Data Replication

When setting up device groups that use the Hitachi TrueCopy software for storage-based data replication, observer the following practices:

• Always use the highest fence level, data, to avoid failover to an old copy of the data.

• Create one Hitachi TrueCopy device group per resource group. A one-to-one relationship should exist between the cluster resource group, the cluster device group, the VxVM disk group, and the Hitachi TrueCopy device group.

• Global file-system volumes and failover file-system volumes cannot be mixed in the same Hitachi TrueCopy device group.

• All RAID manager instances should be up and running at all times.