Chapter 4 Data Replication Approaches

This chapter describes available data replication approaches with Sun Cluster. You must understand both host-based and storage-based data replication before you can select the combination of replication approaches that best serves your cluster.

This release of Sun Cluster supports the following releases of Sun's availability suite software:

• Sun StorageTek Availability Suite 4

• Sun StorEdge Availability Suite 3.2.1

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

This chapter contains the following sections:

• Understanding Data Replication

• Using Host-Based Data Replication

• Using Storage-Based Data Replication

• Example: Configuring Host-Based Data Replication With Sun StorEdge Availability Suite or Sun StorageTek Availability Suite Software

Understanding Data Replication

Data replication is the copying of 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. In this way, data replication helps assure high availability and disaster tolerance for your cluster.

Sun Cluster supports the following approaches to data replication:

• Host-based data replication uses special software to replicate disk volumes between geographically dispersed nodes in real time. Remote mirror replication enables data from the master volume of the primary node to be replicated to the master volume of the geographically dispersed secondary node. A remote mirror bitmap tracks differences between the master volume on the primary disk and the master volume on the second disk.

  Host-based data replication is a less expensive data replication solution because it does not require storage arrays. Host-based data replication uses locally-attached disks. However, host-based data replication uses host resources to perform data replication and does not support scalable applications like Oracle RAC. For more information about using host-based data replication in a campus cluster environment, see Using Host-Based Data Replication . For more information about using host-based data replication between two or more clusters, see Sun Cluster Geographic Edition Data Replication Guide for Hitachi TrueCopy.

• Storage-based data replication uses special software to move the work of data replication off the cluster nodes and onto the storage device. This software relocation frees some node processing power to serve cluster requests. Storage-based data replication can be especially important in campus cluster configurations because this type of data replication supports scalable applications and offloads the hosts. Also, storage-based replication supports scalable applications such as Oracle RAC. For more information about using storage-based data replication in a campus cluster environment see Using Storage-Based Data Replication. For more information about using storage-based replication between two or more clusters and the Sun Cluster GeoEdition product that automates the process, see Sun Cluster Geographic Edition Data Replication Guide for Sun StorageTek Availability Suite.

Sun StorageTek Availability Suite software provides a mechanism for host-based data replication across geographically distant clusters. Example: Configuring Host-Based Data Replication With Sun StorEdge Availability Suite or Sun StorageTek Availability Suite Software at the end of this chapter provides a complete example of such a cluster configuration.

Using Host-Based Data Replication

This section describes host-based data replication in a two-room campus cluster. A two-room configuration with host-based data replication is defined as follows:

• Two separate rooms.

• Both rooms with one node each and disk subsystems.

• Data replicated across disk subsystems in these rooms.

• At least one disk subsystem. This is connected to both hosts, used as a quorum device, and located in one of the rooms.

---

Note –

The examples in this section illustrate general campus cluster configurations and are not intended to indicate required or recommended configurations. For simplicity, the diagrams and explanations concentrate only on features unique to understanding campus clustering. For example, public-network Ethernet connections are not shown.

---

In this configuration, the system cannot recover automatically if the quorum disk is lost. Recovery requires intervention from your Sun service provider.

Figure 4–1 Two-Room Campus Cluster With Host-Based Data Replication (No Multipathing)

Figure 4–1 is similar to a standard noncampus configuration. The most obvious difference in a campus cluster is that Fibre Channel switches have been added to switch from multimode to single-mode fibers.

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.

---

Note –

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.

Example: Configuring Host-Based Data Replication With Sun StorEdge Availability Suite or Sun StorageTek Availability Suite Software

This section provides a complete example of configuring host-based data replication between clusters by using Sun StorageTek Availability Suite 3.1 or 3.2 software or Sun StorageTek Availability Suite 4.0 software. The example illustrates a complete cluster configuration for an NFS application that provides detailed information about how individual tasks can be performed. All tasks should be performed in the global zone. The example does not include all of the steps that are required by other applications or other cluster configurations.

If you use role-based access control (RBAC) instead of superuser to access the cluster nodes, ensure that you can assume an RBAC role that provides authorization for all Sun Cluster commands. This series of data replication procedures requires the following Sun Cluster RBAC authorizations if the user is not superuser:

• solaris.cluster.modify

• solaris.cluster.admin

• solaris.cluster.read

See Chapter 2, Sun Cluster and RBAC for more information about using RBAC roles. See the Sun Cluster man pages for the RBAC authorization that each Sun Cluster subcommand requires.

Understanding Sun StorageTek Availability Suite Software in a Cluster

This section introduces disaster tolerance and describes the data replication methods that Sun StorageTek Availability Suite software uses.

Disaster tolerance is the ability of a system to restore an application on an alternate cluster when the primary cluster fails. Disaster tolerance is based on data replication and failover. Failover is the automatic relocation of a resource group or device group from a primary cluster to a secondary cluster. If the primary cluster fails, the application and the data are immediately available on the secondary cluster.

Data Replication Methods Used by Sun StorageTek Availability Suite Software

This section describes the remote mirror replication method and the point-in-time snapshot method used by Sun StorageTek Availability Suite software. This software uses the sndradm(1RPC) and iiadm(1II) commands to replicate data.

Remote Mirror Replication

Figure 4–3 shows remote mirror replication. Data from the master volume of the primary disk is replicated to the master volume of the secondary disk through a TCP/IP connection. A remote mirror bitmap tracks differences between the master volume on the primary disk and the master volume on the secondary disk.

Figure 4–3 Remote Mirror Replication

Remote mirror replication can be performed synchronously in real time, or asynchronously. Each volume set in each cluster can be configured individually, for synchronous replication or asynchronous replication.

• In synchronous data replication, a write operation is not confirmed as complete until the remote volume has been updated.

• In asynchronous data replication, a write operation is confirmed as complete before the remote volume is updated. Asynchronous data replication provides greater flexibility over long distances and low bandwidth.

Point-in-Time Snapshot

Figure 4–4 shows point-in-time snapshot. Data from the master volume of each disk is copied to the shadow volume on the same disk. The point-in-time bitmap tracks differences between the master volume and the shadow volume. When data is copied to the shadow volume, the point-in-time bitmap is reset.

Figure 4–4 Point-in-Time Snapshot

Replication in the Example Configuration

Figure 4–5 illustrates how remote mirror replication and point-in-time snapshot are used in this example configuration.

Figure 4–5 Replication in the Example Configuration

Guidelines for Configuring Host-Based Data Replication Between Clusters

This section provides guidelines for configuring data replication between clusters. This section also contains tips for configuring replication resource groups and application resource groups. Use these guidelines when you are configuring data replication for your cluster.

This section discusses the following topics:

• Configuring Replication Resource Groups

• Configuring Application Resource Groups

  • Configuring Resource Groups for a Failover Application

  • Configuring Resource Groups for a Scalable Application

• Guidelines for Managing a Failover or Switchover

Configuring Replication Resource Groups

Replication resource groups collocate the device group under Sun StorageTek Availability Suite software control with the logical host name resource. A replication resource group must have the following characteristics:

• Be a failover resource group

  A failover resource can run on only one node at a time. When a failover occurs, failover resources take part in the failover.

• Have a logical host name resource

  The logical host name must be hosted by the primary cluster. After a failover or switchover, the logical host name must be hosted by the secondary cluster. The Domain Name System (DNS) is used to associate the logical host name with a cluster.

• Have an HAStoragePlus resource

  The HAStoragePlus resource enforces the switchover of the device group when the replication resource group is switched over or failed over. Sun Cluster software also enforces the switchover of the replication resource group when the device group is switched over. In this way, the replication resource group and the device group are always colocated, or mastered by the same node.

  The following extension properties must be defined in the HAStoragePlus resource:

  • GlobalDevicePaths. This extension property defines the device group to which a volume belongs.

  • AffinityOn property = True. This extension property causes the device group to switch over or fail over when the replication resource group switches over or fails over. This feature is called an affinity switchover.

  For more information about HAStoragePlus, see the SUNW.HAStoragePlus(5) man page.

• Be named after the device group with which it is colocated, followed by -stor-rg

  For example, devgrp-stor-rg.

• Be online on both the primary cluster and the secondary cluster

Configuring Application Resource Groups

To be highly available, an application must be managed as a resource in an application resource group. An application resource group can be configured for a failover application or a scalable application.

Application resources and application resource groups configured on the primary cluster must also be configured on the secondary cluster. Also, the data accessed by the application resource must be replicated to the secondary cluster.

This section provides guidelines for configuring the following application resource groups:

• Configuring Resource Groups for a Failover Application

• Configuring Resource Groups for a Scalable Application

Configuring Resource Groups for a Failover Application

In a failover application, an application runs on one node at a time. If that node fails, the application fails over to another node in the same cluster. A resource group for a failover application must have the following characteristics:

• Have an HAStoragePlus resource to enforce the switchover of the device group when the application resource group is switched over or failed over

  The device group is colocated with the replication resource group and the application resource group. Therefore, the switchover of the application resource group enforces the switchover of the device group and replication resource group. The application resource group, the replication resource group, and the device group are mastered by the same node.

  Note, however, that a switchover or failover of the device group or the replication resource group does not cause a switchover or failover of the application resource group.

  • If the application data is globally mounted, the presence of an HAStoragePlus resource in the application resource group is not required but is advised.

  • If the application data is mounted locally, the presence of an HAStoragePlus resource in the application resource group is required.

    Without an HAStoragePlus resource, the switchover or failover of the application resource group would not trigger the switchover or failover of the replication resource group and device group. After a switchover or failover, the application resource group, replication resource group, and device group would not be mastered by the same node.

  For more information about HAStoragePlus, see the SUNW.HAStoragePlus(5) man page.

• Must be online on the primary cluster and offline on the secondary cluster

  The application resource group must be brought online on the secondary cluster when the secondary cluster takes over as the primary cluster.

Figure 4–6 illustrates the configuration of an application resource group and a replication resource group in a failover application.

Figure 4–6 Configuration of Resource Groups in a Failover Application

Configuring Resource Groups for a Scalable Application

In a scalable application, an application runs on several nodes to create a single, logical service. If a node that is running a scalable application fails, failover does not occur. The application continues to run on the other nodes.

When a scalable application is managed as a resource in an application resource group, it is not necessary to collocate the application resource group with the device group. Therefore, it is not necessary to create an HAStoragePlus resource for the application resource group.

A resource group for a scalable application must have the following characteristics:

• Have a dependency on the shared address resource group

  The nodes that are running the scalable application use the shared address to distribute incoming data.

• Be online on the primary cluster and offline on the secondary cluster

Figure 4–7 illustrates the configuration of resource groups in a scalable application.

Figure 4–7 Configuration of Resource Groups in a Scalable Application

Guidelines for Managing a Failover or Switchover

If the primary cluster fails, the application must be switched over to the secondary cluster as soon as possible. To enable the secondary cluster to take over, the DNS must be updated.

The DNS associates a client with the logical host name of an application. After a failover or switchover, the DNS mapping to the primary cluster must be removed, and a DNS mapping to the secondary cluster must be created. Figure 4–8 shows how the DNS maps a client to a cluster.

Figure 4–8 DNS Mapping of a Client to a Cluster

To update the DNS, use the nsupdate command. For information, see the nsupdate(1M) man page. For an example of how to manage a failover or switchover, see Example of How to Manage a Failover or Switchover.

After repair, the primary cluster can be brought back online. To switch back to the original primary cluster, perform the following tasks:

1. Synchronize the primary cluster with the secondary cluster to ensure that the primary volume is up-to-date.

2. Update the DNS so that clients can access the application on the primary cluster.

Task Map: Example of a Data Replication Configuration

Table 4–1 lists the tasks in this example of how data replication was configured for an NFS application by using Sun StorageTek Availability Suite software.

Table 4–1 Task Map: Example of a Data Replication Configuration

Task	Instructions
1. Connect and install the clusters.	Connecting and Installing the Clusters
2. Configure device groups, file systems for the NFS application, and resource groups on the primary cluster and on the secondary cluster.	Example of How to Configure Device Groups and Resource Groups
3. Enable data replication on the primary cluster and on the secondary cluster.	How to Enable Replication on the Primary Cluster How to Enable Replication on the Secondary Cluster
4. Perform data replication.	How to Perform a Remote Mirror Replication How to Perform a Point-in-Time Snapshot
5. Verify the data replication configuration.	How to Verify That Replication Is Configured Correctly

Connecting and Installing the Clusters

Figure 4–9 illustrates the cluster configuration the example configuration uses. The secondary cluster in the example configuration contains one node, but other cluster configurations can be used.

Figure 4–9 Example Cluster Configuration

Table 4–2 summarizes the hardware and software that the example configuration requires. The Solaris OS, Sun Cluster software, and volume manager software must be installed on the cluster nodes before Sun StorageTek Availability Suite software and patches are installed.

Table 4–2 Required Hardware and Software

Hardware or Software	Requirement
Node hardware	Sun StorageTek Availability Suite software is supported on all servers that use Solaris OS. For information about which hardware to use, see the Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS.
Disk space	Approximately 15 Mbytes.
Solaris OS	Solaris OS releases that are supported by Sun Cluster software. All nodes must use the same version of the Solaris OS. For information about installation, see the Sun Cluster Software Installation Guide for Solaris OS
Sun Cluster software	Sun Cluster 3.2 software. For information about installation, see the Sun Cluster Software Installation Guide for Solaris OS.
Volume manager software	Solstice DiskSuite or Solaris Volume Manager software or VERITAS Volume Manager (VxVM) software. All nodes must use the same version of volume manager software. Information about installation is in the Chapter 4, Configuring Solaris Volume Manager Software, in Sun Cluster Software Installation Guide for Solaris OS and Chapter 5, Installing and Configuring VERITAS Volume Manager, in Sun Cluster Software Installation Guide for Solaris OS
Sun StorageTek Availability Suite software	For information about how to install the software, see the installation manuals for your release of Sun StorageTek Availability Suite or Sun StorageTek Availability Suite software: Sun StorEdge Availability Suite 3.1 - Sun StorEdge Availability documentation Sun StorEdge Availability Suite 3.2 - Sun StorEdge Availability documentation Sun StorageTek Availability Suite 4.0 – Sun StorageTek Availability documentation
Sun StorageTek Availability Suite software patches	For information about the latest patches, see http://www.sunsolve.com.

Example of How to Configure Device Groups and Resource Groups

This section describes how device groups and resource groups are configured for an NFS application. For additional information, see Configuring Replication Resource Groups and Configuring Application Resource Groups.

This section contains the following procedures:

• How to Configure a Device Group on the Primary Cluster

• How to Configure a Device Group on the Secondary Cluster

• How to Configure the File System on the Primary Cluster for the NFS Application

• How to Configure the File System on the Secondary Cluster for the NFS Application

• How to Create a Replication Resource Group on the Primary Cluster

• How to Create a Replication Resource Group on the Secondary Cluster

• How to Create an NFS Application Resource Group on the Primary Cluster

• How to Create an NFS Application Resource Group on the Secondary Cluster

• How to Verify That Replication Is Configured Correctly

The following table lists the names of the groups and resources that are created for the example configuration.

Table 4–3 Summary of the Groups and Resources in the Example Configuration

Group or Resource	Name	Description
Device group	devgrp	The device group
Replication resource group and resources	devgrp-stor-rg	The replication resource group
	lhost-reprg-prim, lhost-reprg-sec	The logical host names for the replication resource group on the primary cluster and the secondary cluster
	devgrp-stor	The HAStoragePlus resource for the replication resource group
Application resource group and resources	nfs-rg	The application resource group
	lhost-nfsrg-prim, lhost-nfsrg-sec	The logical host names for the application resource group on the primary cluster and the secondary cluster
	nfs-dg-rs	The HAStoragePlus resource for the application
	nfs-rs	The NFS resource

With the exception of devgrp-stor-rg, the names of the groups and resources are example names that can be changed as required. The replication resource group must have a name with the format devicegroupname-stor-rg.

This example configuration uses VxVM software. For information about Solstice DiskSuite or Solaris Volume Manager software, see the Chapter 4, Configuring Solaris Volume Manager Software, in Sun Cluster Software Installation Guide for Solaris OS.

The following figure illustrates the volumes that are created in the device group.

Figure 4–10 Volumes for the Device Group

---

Note –

The volumes that are defined in this procedure must not include disk-label private areas, for example, cylinder 0. The VxVM software manages this constraint automatically.

---

How to Configure a Device Group on the Primary Cluster

Before You Begin

Ensure that you have completed the following tasks:

• Read the guidelines and requirements in the following sections:

  • Understanding Sun StorageTek Availability Suite Software in a Cluster

  • Guidelines for Configuring Host-Based Data Replication Between Clusters

• Set up the primary and secondary clusters as described in Connecting and Installing the Clusters.

1. Access nodeA as superuser or assume a role that provides solaris.cluster.modify RBAC authorization.

   The node nodeA is the first node of the primary cluster. For a reminder of which node is nodeA, see Figure 4–9.

2. Create a disk group on nodeA that contains volume 1, vol01 through volume 4, vol04.

   For information about configuring a disk group by using the VxVM software, see the Chapter 5, Installing and Configuring VERITAS Volume Manager, in Sun Cluster Software Installation Guide for Solaris OS.

3. Configure the disk group to create a device group.

   nodeA# cldevicegroup create -t vxvm -n nodeA nodeB devgrp

   The device group is called devgrp.

4. Create the file system for the device group.

   nodeA# newfs /dev/vx/rdsk/devgrp/vol01 < /dev/null nodeA# newfs /dev/vx/rdsk/devgrp/vol02 < /dev/null

   No file system is needed for vol03 or vol04, which are instead used as raw volumes.

Next Steps

Go to How to Configure a Device Group on the Secondary Cluster.

How to Configure a Device Group on the Secondary Cluster

Before You Begin

Complete the procedure How to Configure a Device Group on the Primary Cluster.

1. Access nodeC as superuser or assume a role that provides solaris.cluster.modify RBAC authorization.

2. Create a disk group on nodeC that contains four volumes: volume 1, vol01, through volume 4, vol04.

3. Configure the disk group to create a device group.

   nodeC# cldevicegroup create -t vxvm -n nodeC devgrp

   The device group is named devgrp.

4. Create the file system for the device group.

   nodeC# newfs /dev/vx/rdsk/devgrp/vol01 < /dev/null nodeC# newfs /dev/vx/rdsk/devgrp/vol02 < /dev/null

   No file system is needed for vol03 or vol04, which are instead used as raw volumes.

Next Steps

Go to How to Configure the File System on the Primary Cluster for the NFS Application.

How to Configure the File System on the Primary Cluster for the NFS Application

Before You Begin

Complete the procedure How to Configure a Device Group on the Secondary Cluster.

1. On nodeA and nodeB, become superuser or assume a role that provides solaris.cluster.admin RBAC authorization.

2. On nodeA and nodeB, create a mount-point directory for the NFS file system.

   For example:

   nodeA# mkdir /global/mountpoint

3. On nodeA and nodeB, configure the master volume to be mounted automatically on the mount point.

   Add or replace the following text in the /etc/vfstab file on nodeA and nodeB. The text must be on a single line.

   /dev/vx/dsk/devgrp/vol01 /dev/vx/rdsk/devgrp/vol01 \ /global/mountpoint ufs 3 no global,logging

   For a reminder of the volumes names and volume numbers that are used in the device group, see Figure 4–10.

4. On nodeA, create a volume for the file system information that is used by the Sun Cluster HA for NFS data service.

   nodeA# vxassist -g devgrp make vol05 120m disk1

   Volume 5, vol05, contains the file system information that is used by the Sun Cluster HA for NFS data service.

5. On nodeA, resynchronize the device group with the Sun Cluster software.

   nodeA# cldevicegroup sync devgrp

6. On nodeA, create the file system for vol05.

   nodeA# newfs /dev/vx/rdsk/devgrp/vol05

7. On nodeA and nodeB, create a mount point for vol05.

   The following example creates the mount point /global/etc.

   nodeA# mkdir /global/etc

8. On nodeA and nodeB, configure vol05 to be mounted automatically on the mount point.

   Add or replace the following text in the /etc/vfstab file on nodeA and nodeB. The text must be on a single line.

   /dev/vx/dsk/devgrp/vol05 /dev/vx/rdsk/devgrp/vol05 \ /global/etc ufs 3 yes global,logging

9. Mount vol05 on nodeA.

   nodeA# mount /global/etc

10. Make vol05 accessible to remote systems.

    1. Create a directory called /global/etc/SUNW.nfs on nodeA.

       nodeA# mkdir -p /global/etc/SUNW.nfs

    2. Create the file /global/etc/SUNW.nfs/dfstab.nfs-rs on nodeA.

       nodeA# touch /global/etc/SUNW.nfs/dfstab.nfs-rs

    3. Add the following line to the /global/etc/SUNW.nfs/dfstab.nfs-rs file on nodeA.

       share -F nfs -o rw -d "HA NFS" /global/mountpoint

Next Steps

Go to How to Configure the File System on the Secondary Cluster for the NFS Application.

How to Configure the File System on the Secondary Cluster for the NFS Application

Before You Begin

Complete the procedure How to Configure the File System on the Primary Cluster for the NFS Application.

1. On nodeC, become superuser or assume a role that provides solaris.cluster.admin RBAC authorization.

2. On nodeC, create a mount-point directory for the NFS file system.

   For example:

   nodeC# mkdir /global/mountpoint

3. On nodeC, configure the master volume to be mounted automatically on the mount point.

   Add or replace the following text in the /etc/vfstab file on nodeC. The text must be on a single line.

   /dev/vx/dsk/devgrp/vol01 /dev/vx/rdsk/devgrp/vol01 \ /global/mountpoint ufs 3 no global,logging

4. On nodeC, create a volume for the file system information that is used by the Sun Cluster HA for NFS data service.

   nodeC# vxassist -g devgrp make vol05 120m disk1

   Volume 5, vol05, contains the file system information that is used by the Sun Cluster HA for NFS data service.

5. On nodeC, resynchronize the device group with the Sun Cluster software.

   nodeC# cldevicegroup sync devgrp

6. On nodeC, create the file system for vol05.

   nodeC# newfs /dev/vx/rdsk/devgrp/vol05

7. On nodeC, create a mount point for vol05.

   The following example creates the mount point /global/etc.

   nodeC# mkdir /global/etc

8. On nodeC, configure vol05 to be mounted automatically on the mount point.

   Add or replace the following text in the /etc/vfstab file on nodeC. The text must be on a single line.

   /dev/vx/dsk/devgrp/vol05 /dev/vx/rdsk/devgrp/vol05 \ /global/etc ufs 3 yes global,logging

9. Mount vol05 on nodeC.

   nodeC# mount /global/etc

10. Make vol05 accessible to remote systems.

    1. Create a directory called /global/etc/SUNW.nfs on nodeC.

       nodeC# mkdir -p /global/etc/SUNW.nfs

    2. Create the file /global/etc/SUNW.nfs/dfstab.nfs-rs on nodeC.

       nodeC# touch /global/etc/SUNW.nfs/dfstab.nfs-rs

    3. Add the following line to the /global/etc/SUNW.nfs/dfstab.nfs-rs file on nodeC:

       share -F nfs -o rw -d "HA NFS" /global/mountpoint

Next Steps

Go to How to Create a Replication Resource Group on the Primary Cluster.

How to Create a Replication Resource Group on the Primary Cluster

Before You Begin

Complete the procedure How to Configure the File System on the Secondary Cluster for the NFS Application.

1. Access nodeA as superuser or assume a role that provides solaris.cluster.modify, solaris.cluster.admin, and solaris.cluster.read RBAC authorization.

2. Register the SUNW.HAStoragePlus resource type.

   nodeA# clresourcetype register SUNW.HAStoragePlus

3. Create a replication resource group for the device group.

   nodeA# clresourcegroup create -n nodeA,nodeB devgrp-stor-rg

   -n nodeA,nodeB

   Specifies that cluster nodes nodeA and nodeB can master the replication resource group.

   devgrp-stor-rg

   The name of the replication resource group. In this name, devgrp specifies the name of the device group.

4. Add a SUNW.HAStoragePlus resource to the replication resource group.

   nodeA# clresource create -g devgrp-stor-rg -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=devgrp \ -p AffinityOn=True \ devgrp-stor

   -g

   Specifies the resource group to which resource is added.

   -p GlobalDevicePaths=

   Specifies the extension property that Sun StorageTek Availability Suite software relies on.

   -p AffinityOn=True

   Specifies that the SUNW.HAStoragePlus resource must perform an affinity switchover for the global devices and cluster file systems defined by -x GlobalDevicePaths=. Therefore, when the replication resource group fails over or is switched over, the associated device group is switched over.

   For more information about these extension properties, see the SUNW.HAStoragePlus(5) man page.

5. Add a logical host name resource to the replication resource group.

   nodeA# clreslogicalhostname create -g devgrp-stor-rg lhost-reprg-prim

   The logical host name for the replication resource group on the primary cluster is named lhost-reprg-prim.

6. Enable the resources, manage the resource group, and bring the resource group online.

   nodeA# clresourcegroup online -e -M -n nodeA devgrp-stor-rg

   -e

   Enables associated resources.

   -M

   Manages the resource group.

   -n

   Specifies the node on which to bring the resource group online.

7. Verify that the resource group is online.

   nodeA# clresourcegroup status devgrp-stor-rg

   Examine the resource group state field to confirm that the replication resource group is online on nodeA.

Next Steps

Go to How to Create a Replication Resource Group on the Secondary Cluster.

How to Create a Replication Resource Group on the Secondary Cluster

Before You Begin

Complete the procedure How to Create a Replication Resource Group on the Primary Cluster.

1. Access nodeC as superuser or assume a role that provides solaris.cluster.modify, solaris.cluster.admin, and solaris.cluster.read RBAC authorization.

2. Register SUNW.HAStoragePlus as a resource type.

   nodeC# clresourcetype register SUNW.HAStoragePlus

3. Create a replication resource group for the device group.

   nodeC# clresourcegroup create -n nodeC devgrp-stor-rg

   create

   Creates the resource group.

   -n

   Specifies the node list for the resource group.

   devgrp

   The name of the device group.

   devgrp-stor-rg

   The name of the replication resource group.

4. Add a SUNW.HAStoragePlus resource to the replication resource group.

   nodeC# clresource create \ -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=devgrp \ -p AffinityOn=True \ devgrp-stor

   create

   Creates the resource.

   -t

   Specifies the resource type.

   -p GlobalDevicePaths=

   Specifies the extension property that Sun StorageTek Availability Suite software relies on.

   -p AffinityOn=True

   Specifies that the SUNW.HAStoragePlus resource must perform an affinity switchover for the global devices and cluster file systems defined by -x GlobalDevicePaths=. Therefore, when the replication resource group fails over or is switched over, the associated device group is switched over.

   devgrp-stor

   The HAStoragePlus resource for the replication resource group.

   For more information about these extension properties, see the SUNW.HAStoragePlus(5) man page.

5. Add a logical host name resource to the replication resource group.

   nodeC# clreslogicalhostname create -g devgrp-stor-rg lhost-reprg-sec

   The logical host name for the replication resource group on the primary cluster is named lhost-reprg-sec.

6. Enable the resources, manage the resource group, and bring the resource group online.

   nodeC# clresourcegroup online -e -M -n nodeC devgrp-stor-rg

   online

   Brings online.

   -e

   Enables associated resources.

   -M

   Manages the resource group.

   -n

   Specifies the node on which to bring the resource group online.

7. Verify that the resource group is online.

   nodeC# clresourcegroup status devgrp-stor-rg

   Examine the resource group state field to confirm that the replication resource group is online on nodeC.

Next Steps

Go to How to Create an NFS Application Resource Group on the Primary Cluster.

How to Create an NFS Application Resource Group on the Primary Cluster

This procedure describes how application resource groups are created for NFS. This procedure is specific to this application and cannot be used for another type of application.

Before You Begin

Complete the procedure How to Create a Replication Resource Group on the Secondary Cluster.

1. Access nodeA as superuser or assume a role that provides solaris.cluster.modify, solaris.cluster.admin, and solaris.cluster.read RBAC authorization.

2. Register SUNW.nfs as a resource type.

   nodeA# clresourcetype register SUNW.nfs

3. If SUNW.HAStoragePlus has not been registered as a resource type, register it.

   nodeA# clresourcetype register SUNW.HAStoragePlus

4. Create an application resource group for the device group devgrp.

   nodeA# clresourcegroup create \ -p Pathprefix=/global/etc \ -p Auto_start_on_new_cluster=False \ -p RG_dependencies=devgrp-stor-rg \ nfs-rg

   Pathprefix=/global/etc

   Specifies the directory into which the resources in the group can write administrative files.

   Auto_start_on_new_cluster=False

   Specifies that the application resource group is not started automatically.

   RG_dependencies=devgrp-stor-rg

   Specifies the resource group that the application resource group depends on. In this example, the application resource group depends on the replication resource group devgrp-stor-rg.

   If the application resource group is switched over to a new primary node, the replication resource group is automatically switched over. However, if the replication resource group is switched over to a new primary node, the application resource group must be manually switched over.

   nfs-rg

   The name of the application resource group.

5. Add a SUNW.HAStoragePlus resource to the application resource group.

   nodeA# clresource create -g nfs-rg \ -t SUNW.HAStoragePlus \ -p FileSystemMountPoints=/global/mountpoint \ -p AffinityOn=True \ nfs-dg-rs

   create

   Creates the resource.

   -g

   Specifies the resource group to which the resource is added.

   -t SUNW.HAStoragePlus

   Specifies that the resource is of the type SUNW.HAStoragePlus.

   -p FileSystemMountPoints=/global/

   Specifies that the mount point for the file system is global.

   -p AffinityOn=True

   Specifies that the application resource must perform an affinity switchover for the global devices and cluster file systems defined by -p GlobalDevicePaths=. Therefore, when the application resource group fails over or is switched over, the associated device group is switched over.

   nfs-dg-rs

   The name of the HAStoragePlus resource for the NFS application.

   For more information about these extension properties, see the SUNW.HAStoragePlus(5) man page.

6. Add a logical host name resource to the application resource group.

   nodeA# clreslogicalhostname create -g nfs-rg \ lhost-nfsrg-prim

   The logical host name of the application resource group on the primary cluster is named lhost-nfsrg-prim.

7. Enable the resources, manage the application resource group, and bring the application resource group online.

   1. Enable the HAStoragePlus resource for the NFS application.

      nodeA# clresource enable nfs-rs

   2. Bring the application resource group online on nodeA .

      nodeA# clresourcegroup online -e -M -n nodeA nfs-rg

      online

      Brings the resource group online.

      -e

      Enables the associated resources.

      -M

      Manages the resource group.

      -n

      Specifies the node on which to bring the resource group online.

      nfs-rg

      The name of the resource group.

8. Verify that the application resource group is online.

   nodeA# clresourcegroup status

   Examine the resource group state field to determine whether the application resource group is online for nodeA and nodeB.

Next Steps

Go to How to Create an NFS Application Resource Group on the Secondary Cluster.

How to Create an NFS Application Resource Group on the Secondary Cluster

Before You Begin

Complete the procedure How to Create an NFS Application Resource Group on the Primary Cluster.

1. Access nodeC as superuser or assume a role that provides solaris.cluster.modify, solaris.cluster.admin, and solaris.cluster.read RBAC authorization.

2. Register SUNW.nfs as a resource type.

   nodeC# clresourcetype register SUNW.nfs

3. If SUNW.HAStoragePlus has not been registered as a resource type, register it.

   nodeC# clresourcetype register SUNW.HAStoragePlus

4. Create an application resource group for the device group.

   nodeC# clresourcegroup create \ -p Pathprefix=/global/etc \ -p Auto_start_on_new_cluster=False \ -p RG_dependencies=devgrp-stor-rg \ nfs-rg

   create

   Creates the resource group.

   -p

   Specifies a property of the resource group.

   Pathprefix=/global/etc

   Specifies a directory into which the resources in the group can write administrative files.

   Auto_start_on_new_cluster=False

   Specifies that the application resource group is not started automatically.

   RG_dependencies=devgrp-stor-rg

   Specifies the resource groups that the application resource group depends on. In this example, the application resource group depends on the replication resource group.

   If the application resource group is switched over to a new primary node, the replication resource group is automatically switched over. However, if the replication resource group is switched over to a new primary node, the application resource group must be manually switched over.

   nfs-rg

   The name of the application resource group.

5. Add a SUNW.HAStoragePlus resource to the application resource group.

   nodeC# clresource create -g nfs-rg \ -t SUNW.HAStoragePlus \ -p FileSystemMountPoints=/global/mountpoint \ -p AffinityOn=True \ nfs-dg-rs

   create

   Creates the resource.

   -g

   Specifies the resource group to which the resource is added.

   -t SUNW.HAStoragePlus

   Specifies that the resource is of the type SUNW.HAStoragePlus.

   -p

   Specifies a property of the resource.

   FileSystemMountPoints=/global/

   Specifies that the mount point for the file system is global.

   AffinityOn=True

   Specifies that the application resource must perform an affinity switchover for the global devices and cluster file systems defined by -x GlobalDevicePaths=. Therefore, when the application resource group fails over or is switched over, the associated device group is switched over.

   nfs-dg-rs

   The name of the HAStoragePlus resource for the NFS application.

   For more information about these extension properties, see the SUNW.HAStoragePlus(5) man page.

6. Add a logical host name resource to the application resource group.

   nodeC# clreslogicalhostname create -g nfs-rg \ lhost-nfsrg-sec

   The logical host name of the application resource group on the secondary cluster is named lhost-nfsrg-sec.

7. Add an NFS resource to the application resource group.

   nodeC# clresource create -g nfs-rg \ -t SUNW.nfs -p Resource_dependencies=nfs-dg-rs nfs-rg

8. Ensure that the application resource group does not come online on nodeC.

   nodeC# clresource disable -n nodeC nfs-rs nodeC# clresource disable -n nodeC nfs-dg-rs nodeC# clresource disable -n nodeC lhost-nfsrg-sec nodeC# clresourcegroup online -n "" nfs-rg

   The resource group remains offline after a reboot, because Auto_start_on_new_cluster=False.

9. If the global volume is mounted on the primary cluster, unmount the global volume from the secondary cluster.

   nodeC# umount /global/mountpoint

   If the volume is mounted on a secondary cluster, the synchronization fails.

Next Steps

Go to Example of How to Enable Data Replication.

Example of How to Enable Data Replication

This section describes how data replication is enabled for the example configuration. This section uses the Sun StorageTek Availability Suite software commands sndradm and iiadm. For more information about these commands, see the Sun StorageTek Availability documentation.

This section contains the following procedures:

• How to Enable Replication on the Primary Cluster

• How to Enable Replication on the Secondary Cluster

How to Enable Replication on the Primary Cluster

1. Access nodeA as superuser or assume a role that provides solaris.cluster.read RBAC authorization.

2. Flush all transactions.

   nodeA# lockfs -a -f

3. Confirm that the logical host names lhost-reprg-prim and lhost-reprg-sec are online.

   nodeA# clresourcegroup status nodeC# clresourcegroup status

   Examine the state field of the resource group.

4. Enable remote mirror replication from the primary cluster to the secondary cluster.

   This step enables replication from the master volume on the primary cluster to the master volume on the secondary cluster. In addition, this step enables replication to the remote mirror bitmap on vol04.

   • If the primary cluster and secondary cluster are unsynchronized, run this command:

     • For Sun StorEdge Availability Suite software:

       nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

     • For Sun StorageTek Availability Suite software:

       nodeA# /usr/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • If the primary cluster and secondary cluster are synchronized, run this command:

     • For Sun StorEdge Availability Suite software:

       nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -E lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -E lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

5. Enable autosynchronization.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -a on lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -a on lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   This step enables autosynchronization. When the active state of autosynchronization is set to on, the volume sets are resynchronized if the system reboots or a failure occurs.

6. Verify that the cluster is in logging mode.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -P

   The output should resemble the following:

   /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: logging

   In logging mode, the state is logging, and the active state of autosynchronization is off. When the data volume on the disk is written to, the bitmap file on the same disk is updated.

7. Enable point-in-time snapshot.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03 nodeA# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/devgrp/vol02

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/iiadm -e ind \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03 nodeA# /usr/sbin/iiadm -w \ /dev/vx/rdsk/devgrp/vol02

   This step enables the master volume on the primary cluster to be copied to the shadow volume on the same cluster. The master volume, shadow volume, and point-in-time bitmap volume must be in the same device group. In this example, the master volume is vol01, the shadow volume is vol02, and the point-in-time bitmap volume is vol03.

8. Attach the point-in-time snapshot to the remote mirror set.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -I a \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03

   This step associates the point-in-time snapshot with the remote mirror volume set. Sun StorageTek Availability Suite software ensures that a point-in-time snapshot is taken before remote mirror replication can occur.

Next Steps

Go to How to Enable Replication on the Secondary Cluster.

How to Enable Replication on the Secondary Cluster

Before You Begin

Complete the procedure How to Enable Replication on the Primary Cluster.

1. Access nodeC as superuser.

2. Flush all transactions.

   nodeC# lockfs -a -f

3. Enable remote mirror replication from the primary cluster to the secondary cluster.

   • For Sun StorEdge Availability Suite software:

     nodeC# /usr/opt/SUNWesm/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeC# /usr/sbin/sndradm -n -e lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   The primary cluster detects the presence of the secondary cluster and starts synchronization. Refer to the system log file /var/opt/SUNWesm/ds.log for Sun StorEdge Availability Suite or /var/adm for Sun StorageTek Availability Suite for information about the status of the clusters.

4. Enable independent point-in-time snapshot.

   • For Sun StorEdge Availability Suite software:

     nodeC# /usr/opt/SUNWesm/sbin/iiadm -e ind \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03 nodeC# /usr/opt/SUNWesm/sbin/iiadm -w \ /dev/vx/rdsk/devgrp/vol02

   • For Sun StorageTek Availability Suite software:

     nodeC# /usr/sbin/iiadm -e ind \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03 nodeC# /usr/sbin/iiadm -w \ /dev/vx/rdsk/devgrp/vol02

5. Attach the point-in-time snapshot to the remote mirror set.

   • For Sun StorEdge Availability Suite software:

     nodeC# /usr/opt/SUNWesm/sbin/sndradm -I a \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03

   • For Sun StorageTek Availability Suite software:

     nodeC# /usr/sbin/sndradm -I a \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol02 \ /dev/vx/rdsk/devgrp/vol03

Next Steps

Go to Example of How to Perform Data Replication.

Example of How to Perform Data Replication

This section describes how data replication is performed for the example configuration. This section uses the Sun StorageTek Availability Suite software commands sndradm and iiadm. For more information about these commands, see the Sun StorageTek Availability Suite documentation.

This section contains the following procedures:

• How to Perform a Remote Mirror Replication

• How to Perform a Point-in-Time Snapshot

• How to Verify That Replication Is Configured Correctly

How to Perform a Remote Mirror Replication

In this procedure, the master volume of the primary disk is replicated to the master volume on the secondary disk. The master volume is vol01 and the remote mirror bitmap volume is vol04.

1. Access nodeA as superuser.

2. Verify that the cluster is in logging mode.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -P

   The output should resemble the following:

   /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync: off, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: logging

   In logging mode, the state is logging, and the active state of autosynchronization is off. When the data volume on the disk is written to, the bitmap file on the same disk is updated.

3. Flush all transactions.

   nodeA# lockfs -a -f

4. Repeat Step 1 through Step 3 on nodeC.

5. Copy the master volume of nodeA to the master volume of nodeC.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -m lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -m lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

6. Wait until the replication is complete and the volumes are synchronized.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -w lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -w lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

7. Confirm that the cluster is in replicating mode.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -P

   The output should resemble the following:

   /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: replicating

   In replicating mode, the state is replicating, and the active state of autosynchronization is on. When the primary volume is written to, the secondary volume is updated by Sun StorageTek Availability Suite software.

Next Steps

Go to How to Perform a Point-in-Time Snapshot.

How to Perform a Point-in-Time Snapshot

In this procedure, point-in-time snapshot is used to synchronize the shadow volume of the primary cluster to the master volume of the primary cluster. The master volume is vol01, the bitmap volume is vol04, and the shadow volume is vol02.

Before You Begin

Complete the procedure How to Perform a Remote Mirror Replication.

1. Access nodeA as superuser or assume a role that provides solaris.cluster.modify and solaris.cluster.admin RBAC authorization.

2. Disable the resource that is running on nodeA.

   nodeA# clresource disable -n nodeA nfs-rs

3. Change the primary cluster to logging mode.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   When the data volume on the disk is written to, the bitmap file on the same disk is updated. No replication occurs.

4. Synchronize the shadow volume of the primary cluster to the master volume of the primary cluster.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/devgrp/vol02 nodeA# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/devgrp/vol02

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/iiadm -u s /dev/vx/rdsk/devgrp/vol02 nodeA# /usr/sbin/iiadm -w /dev/vx/rdsk/devgrp/vol02

5. Synchronize the shadow volume of the secondary cluster to the master volume of the secondary cluster.

   • For Sun StorEdge Availability Suite software:

     nodeC# /usr/opt/SUNWesm/sbin/iiadm -u s /dev/vx/rdsk/devgrp/vol02 nodeC# /usr/opt/SUNWesm/sbin/iiadm -w /dev/vx/rdsk/devgrp/vol02

   • For Sun StorageTek Availability Suite software:

     nodeC# /usr/sbin/iiadm -u s /dev/vx/rdsk/devgrp/vol02 nodeC# /usr/sbin/iiadm -w /dev/vx/rdsk/devgrp/vol02

6. Restart the application on nodeA.

   nodeA# clresource enable -n nodeA nfs-rs

7. Resynchronize the secondary volume with the primary volume.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

Next Steps

Go to How to Verify That Replication Is Configured Correctly.

How to Verify That Replication Is Configured Correctly

Before You Begin

Complete the procedure How to Perform a Point-in-Time Snapshot.

1. Access nodeA and nodeC as superuser or assume a role that provides solaris.cluster.admin RBAC authorization.

2. Verify that the primary cluster is in replicating mode, with autosynchronization on.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -P

   The output should resemble the following:

   /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync: on, max q writes:4194304, max q fbas:16384, mode:sync,ctag: devgrp, state: replicating

   In replicating mode, the state is replicating, and the active state of autosynchronization is on. When the primary volume is written to, the secondary volume is updated by Sun StorageTek Availability Suite software.

3. If the primary cluster is not in replicating mode, put it into replicating mode.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

4. Create a directory on a client machine.

   1. Log in to a client machine as superuser.

      You see a prompt that resembles the following:

      client-machine#

   2. Create a directory on the client machine.

      client-machine# mkdir /dir

5. Mount the directory to the application on the primary cluster, and display the mounted directory.

   1. Mount the directory to the application on the primary cluster.

      client-machine# mount -o rw lhost-nfsrg-prim:/global/mountpoint /dir

   2. Display the mounted directory.

      client-machine# ls /dir

6. Mount the directory to the application on the secondary cluster, and display the mounted directory.

   1. Unmount the directory from the application on the primary cluster.

      client-machine# umount /dir

   2. Take the application resource group offline on the primary cluster.

      nodeA# clresource disable -n nodeA nfs-rs nodeA# clresource disable -n nodeA nfs-dg-rs nodeA# clresource disable -n nodeA lhost-nfsrg-prim nodeA# clresourcegroup online -n "" nfs-rg

   3. Change the primary cluster to logging mode.

      • For Sun StorEdge Availability Suite software:

        nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

      • For Sun StorageTek Availability Suite software:

        nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

      When the data volume on the disk is written to, the bitmap file on the same disk is updated. No replication occurs.

   4. Ensure that the PathPrefix directory is available.

      nodeC# mount | grep /global/etc

   5. Bring the application resource group online on the secondary cluster.

      nodeC# clresourcegroup online -n nodeC nfs-rg

   6. Access the client machine as superuser.

      You see a prompt that resembles the following:

      client-machine#

   7. Mount the directory that was created in Step 4 to the application on the secondary cluster.

      client-machine# mount -o rw lhost-nfsrg-sec:/global/mountpoint /dir

   8. Display the mounted directory.

      client-machine# ls /dir

7. Ensure that the directory displayed in Step 5 is the same as the directory displayed in Step 6.

8. Return the application on the primary cluster to the mounted directory.

   1. Take the application resource group offline on the secondary cluster.

      nodeC# clresource disable -n nodeC nfs-rs nodeC# clresource disable -n nodeC nfs-dg-rs nodeC# clresource disable -n nodeC lhost-nfsrg-sec nodeC# clresourcegroup online -n "" nfs-rg

   2. Ensure that the global volume is unmounted from the secondary cluster.

      nodeC# umount /global/mountpoint

   3. Bring the application resource group online on the primary cluster.

      nodeA# clresourcegroup online -n nodeA nfs-rg

   4. Change the primary cluster to replicating mode.

      • For Sun StorEdge Availability Suite software:

        nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

      • For Sun StorageTek Availability Suite software:

        nodeA# /usr/sbin/sndradm -n -u lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

      When the primary volume is written to, the secondary volume is updated by Sun StorageTek Availability Suite software.

See Also

Example of How to Manage a Failover or Switchover

Example of How to Manage a Failover or Switchover

This section describes how to provoke a switchover and how the application is transferred to the secondary cluster. After a switchover or failover, update the DNS entries. For additional information, see Guidelines for Managing a Failover or Switchover.

This section contains the following procedures:

• How to Provoke a Switchover

• How to Update the DNS Entry

How to Provoke a Switchover

1. Access nodeA and nodeC as superuser or assume a role that provides solaris.cluster.admin RBAC authorization.

2. Change the primary cluster to logging mode.

   • For Sun StorEdge Availability Suite software:

     nodeA# /usr/opt/SUNWesm/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   • For Sun StorageTek Availability Suite software:

     nodeA# /usr/sbin/sndradm -n -l lhost-reprg-prim \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 lhost-reprg-sec \ /dev/vx/rdsk/devgrp/vol01 \ /dev/vx/rdsk/devgrp/vol04 ip sync

   When the data volume on the disk is written to, the bitmap volume on the same device group is updated. No replication occurs.

3. Confirm that the primary cluster and the secondary cluster are in logging mode, with autosynchronization off.

   1. On nodeA, confirm the mode and setting:

      • For Sun StorEdge Availability Suite software:

        nodeA# /usr/opt/SUNWesm/sbin/sndradm -P

      • For Sun StorageTek Availability Suite software:

        nodeA# /usr/sbin/sndradm -P

      The output should resemble the following:

      /dev/vx/rdsk/devgrp/vol01 -> lhost-reprg-sec:/dev/vx/rdsk/devgrp/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: devgrp, state: logging

   2. On nodeC, confirm the mode and setting:

      • For Sun StorEdge Availability Suite software:

        nodeC# /usr/opt/SUNWesm/sbin/sndradm -P

      • For Sun StorageTek Availability Suite software:

        nodeC# /usr/sbin/sndradm -P

      The output should resemble the following:

      /dev/vx/rdsk/devgrp/vol01 <- lhost-reprg-prim:/dev/vx/rdsk/devgrp/vol01 autosync:off, max q writes:4194304,max q fbas:16384,mode:sync,ctag: devgrp, state: logging

   For nodeA and nodeC, the state should be logging, and the active state of autosynchronization should be off.

4. Confirm that the secondary cluster is ready to take over from the primary cluster.

   nodeC# fsck -y /dev/vx/rdsk/devgrp/vol01

5. Switch over to the secondary cluster.

   nodeC# clresourcegroup switch -n nodeC nfs-rg

Next Steps

Go to How to Update the DNS Entry.

How to Update the DNS Entry

For an illustration of how DNS maps a client to a cluster, see Figure 4–8.

Before You Begin

Complete the procedure How to Provoke a Switchover.

1. Start the nsupdate command.

   For information, see the nsupdate(1M) man page.

2. Remove the current DNS mapping between the logical host name of the application resource group and the cluster IP address, for both clusters.

   > update delete lhost-nfsrg-prim A > update delete lhost-nfsrg-sec A > update delete ipaddress1rev.in-addr.arpa ttl PTR lhost-nfsrg-prim > update delete ipaddress2rev.in-addr.arpa ttl PTR lhost-nfsrg-sec

   ipaddress1rev

   The IP address of the primary cluster, in reverse order.

   ipaddress2rev

   The IP address of the secondary cluster, in reverse order.

   ttl

   The time to live, in seconds. A typical value is 3600.

3. Create a new DNS mapping between the logical host name of the application resource group and the cluster IP address, for both clusters.

   Map the primary logical host name to the IP address of the secondary cluster and map the secondary logical host name to the IP address of the primary cluster.

   > update add lhost-nfsrg-prim ttl A ipaddress2fwd > update add lhost-nfsrg-sec ttl A ipaddress1fwd > update add ipaddress2rev.in-addr.arpa ttl PTR lhost-nfsrg-prim > update add ipaddress1rev.in-addr.arpa ttl PTR lhost-nfsrg-sec

   ipaddress2fwd

   The IP address of the secondary cluster, in forward order.

   ipaddress1fwd

   The IP address of the primary cluster, in forward order.