JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Cluster System Administration Guide     Oracle Solaris Cluster 4.1
search filter icon
search icon

Document Information

Preface

1.  Introduction to Administering Oracle Solaris Cluster

2.  Oracle Solaris Cluster and RBAC

3.  Shutting Down and Booting a Cluster

4.  Data Replication Approaches

Understanding Data Replication

Supported Data Replication Methods

Using Storage-Based Data Replication Within a Cluster

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

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

Best Practices When Using Storage-Based Data Replication

5.  Administering Global Devices, Disk-Path Monitoring, and Cluster File Systems

6.  Administering Quorum

7.  Administering Cluster Interconnects and Public Networks

8.  Adding and Removing a Node

9.  Administering the Cluster

10.  Configuring Control of CPU Usage

11.  Updating Your Software

12.  Backing Up and Restoring a Cluster

A.  Example

Index

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. Oracle Solaris Cluster supports both manual and automatic failover of the replicants with 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

image:Illustration: The preceding and following paragraphs describe the graphic.

Storage-based synchronous replication with EMC SRDF is supported with Oracle Solaris 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.

If contact with the remote storage device is lost, ensure that an application that is running on the primary cluster is not blocked by specifying a Fence_level of never or async. If you specify a Fence_level of data or status, the primary storage device refuses updates if the updates cannot be copied to the remote 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 Oracle service provider must reconfigure the remaining node to boot as a cluster member.

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

  3. You or your Oracle 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 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.