Sun Cluster System Administration Guide for Solaris OS

Chapter 4 Data Replication Approaches

This chapter describes data replication technologies you can use with Sun Cluster software. Data replication is defined as copying data from a primary storage device to a backup or secondary device. If the primary device fails, your data is available from the secondary device. Data replication helps assure high availability and disaster tolerance for your cluster.

Sun Cluster software supports the following types of data replication:

To perform data replication, you must have a device group that has the same name as the object you are replicating. A device can belong to only one device group at a time, so if you already have a Sun Cluster device group that contains the device, you must delete the group before you add that device to a new device group. For instructions on creating and managing Solaris Volume Manager, Veritas Volume Manager, ZFS, or raw-disk device groups, see Administering Device Groups in Chapter 5.

You must understand both host-based and storage-based data replication before you can select the replication approach that best serves your cluster. For more information about using Sun Cluster Geographic Edition to manage your data replication for disaster recovery, see the Sun Cluster Geographic Edition Overview.

This chapter contains the following sections:

Understanding Data Replication

Sun Cluster supports the following approaches to data replication:

Supported Data Replication Methods

Sun Cluster software supports the following methods of data replication between clusters or within a cluster:

  1. Replication Between Clusters – For disaster recovery, you can use host-based or storage-based replication to perform data replication between clusters. Generally, you would choose either host-based replication or storage-based replication, rather than a combination of the two. You can manage both types of replication with Sun Cluster Geographic Edition software.

    • Host-Based Replication

      • Sun StorageTek Availability Suite 4, starting with the Solaris 10 OS

      • Sun StorEdge Availability Suite 3.2.1 on the Solaris 9 OS

      In this manual, references to Sun StorageTek Availability Suite software also apply to Sun StorEdge Availability Suite software unless specifically stated otherwise.

      If you want to use host-based replication without Sun Cluster Geographic Edition software, see the instructions in Appendix A, Example, Configuring Host-Based Data Replication With Sun StorEdge Availability Suite or Sun StorageTek Availability Suite Software.

    • Storage-Based Replication

      • Hitachi TrueCopy and Hitachi Universal Replicator, through the Sun Cluster Geographic Edition

      • EMC Symmetrix Remote Data Facility (SRDF), through the Sun Cluster Geographic Edition

      If you want to use storage-based replication without Sun Cluster Geographic Edition software, see the documentation for your replication software.

  2. Replication Within a Cluster – This method is used as a replacement for host-based mirroring.

    • Storage-Based Replication

      • Hitachi TrueCopy and Hitachi Universal Replicator

      • EMC Symmetrix Remote Data Facility (SRDF)

  3. Application-Based Replication – Oracle Data Guard is an example of application-based replication software. This type of software is used only for disaster recovery. For more information, see the Sun Cluster Geographic Edition Data Replication Guide for Oracle Data Guard

Using Storage-Based Data Replication Within a Cluster

Storage-based data replication uses software installed on the storage device to manage the replication within a cluster or a campus cluster. Such software is specific to your particular storage device, and is not used for disaster recovery. 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, Hitachi Universal Replicator, and EMC SRDF software.

This section describes storage-based data replication as used in a campus cluster. Figure 4–1 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 data to replicate.


Note –

Figure 4–1 illustrates that the quorum device is on an unreplicated volume. A replicated volume cannot be used as a quorum device.


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

Illustration: The preceding and following paragraphs
describe the graphic.

Storage-based data replication with Hitachi TrueCopy or Hitachi Universal Replicator can be performed synchronously or asynchronously in the Sun Cluster environment, depending on the type of application you use. If you want to perform automatic failover in a campus cluster, use TrueCopy synchronously. Storage-based synchronous replication with EMC SRDF is supported with Sun Cluster; asynchronous replication is not supported for EMC SRDF.

Do not use EMC SRDF's Domino mode or Adaptive Copy mode. Domino mode makes the local and target SRDF volumes unavailable to the host when the target is unavailable. Adaptive Copy mode is generally used for data migrations and data center moves and it not recommended for disaster recovery.

Do not use the Data or Status modes in Hitachi TrueCopy or Hitachi Universal Replicator. If the secondary storage device fails, you might experience problems writing to the primary storage device.

Requirements and Restrictions When Using Storage-Based Data Replication Within a Cluster

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

Manual Recovery Concerns When Using Storage-Based Data Replication Within a Cluster

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–1), 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 Storage-Based Data Replication

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

When using EMC SRDF software for storage-based data replication, use dynamic devices instead of static devices. Static devices require several minutes to change the replication primary and can impact failover time.