C H A P T E R 3 - Configuration Considerations

C H A P T E R 3

Configuration Considerations

This chapter discusses Point-in-Time Copy software configuration issues.

This chapter covers the following topics:

Using the Point-in-Time Copy Software With the Remote Mirror Software

Point-in-Time Copy Software in a Sun Cluster 3.1/3.2 Environment

Additional Performance Considerations

Using the Point-in-Time Copy Software With the Remote Mirror Software

Sun StorageTek Availability Suite 4.0 Remote Mirror software enables the replication, or mirroring, of volumes hosted on a Solaris system across any TCP/IP network. Remote Mirror software is used to ensure volume level backups at physically remote locations.

Remote Mirror software, like Point-in-Time Copy software, synchronizes volumes. After a synchronization has been performed, the primary and secondary remote mirror volumes are remotely replicated. This means that the two volumes are kept up-to-date with each other. For additional information, see Related Documentation. A few of the highlights of using Point-in-Time Copy software and Remote Mirror software together are described in this section.

To ensure the highest level of data integrity and system performance on both sites during normal operations, use Point-in-Time Copy software in conjunction with Remote Mirror software.

When using the Point-in-Time Copy software with the Remote Mirror software, a point-in-time copy can be replicated to a physically remote location, providing a consistent copy of the volume as part of an overall disaster recovery plan. Depending upon the configuration of the shadow volume set, such a copy can be kept relatively up-to-date without noticeable impact on normal processing.

For example, a point-in-time copy of a remote mirror primary volume can be transferred to the secondary site. Applications can remain open and active at the primary site while the point-in-time copy is established. This works well if the secondary volume can be out of sync with the primary volume by some small time delta. The advantage in this approach is that the overhead involved in remotely mirroring the primary data is reduced if the point-in-time copy is mirrored instead. Keeping the secondary site slightly out of sync with the primary site also enables verification of the primary data prior to replicating the data on the secondary site.

Using Point-in-Time Copy software with Remote Mirror software, you can create a point-in-time copy of a remote mirror secondary volume before beginning synchronization of the secondary volume from the primary site. Protection against double failure is provided by the point-in-time copy of the replicated data. If a subsequent failure occurs during resynchronization, the point-in-time copy can be used as a fallback position. Resynchronization can be resumed when the subsequent failure issues have been resolved. Once the secondary site is fully synchronized with the primary site, the Point-in-Time Copy software volume set can be disabled or put to other uses (such as remote backup, remote data analysis, or other functions) at the secondary site.

Interaction in the Sun StorageTek Data Service I/O Stack

The I/O operation that the Point-in-Time Copy software performs internally during an enable, copy, or update operation can alter the contents of the shadow volume without any new I/O coming down the Solaris I/O stack. When this happens, the I/O is not intercepted in the storage volume (SV) layer. If the shadow volume is also a remote mirror volume, the Remote Mirror software does not see these I/O operations. In this situation, the data modified by the I/O is not replicated on the target remote mirror volume.

To allow this replication to occur, the Point-in-Time Copy software can be configured to offer the Remote Mirror software the changed bitmap. If the Remote Mirror software is in logging mode, it accepts the bitmap. If the bitmap is accepted, the Remote Mirror software adds the Point-in-Time Copy software changes to its own list of changes to be replicated to the remote node. If the Remote Mirror software is in replication mode for the volume, it rejects the bitmap from the Point-in-Time Copy software. This, in turn, causes the enable, copy, or update operation to fail. Once remote mirror logging has been reenabled, the Point-in-Time Copy software operation can be reissued.

Using a Point-in-Time Copy Shadow Volume Set to Back Up a Remote Mirror Resync

The Remote Mirror software, with the sndradm -I command, enables the system administrator to configure a point-in-time shadow volume set to be used just prior to a Remote Mirror software resync operation. The remote mirror secondary volume is the master volume of the point-in-time shadow volume set. Just before the remote mirror resync, the point-in-time shadow volume set is enabled. If the remote mirror resync fails for any reason, the secondary volume, as the master in its point-in-time shadow volume set, can be restored by performing a shadow-to-master update.

Caution - The volumes specified for use as the point-in-time shadow volume set (shadow and bitmap) must not be in use for any other purpose. Loss of the remote mirror secondary volume's data can occur if the resync fails and the point-in-time volumes have been concurrently used for another purpose.

Caution - It is possible to set up configurations in which data loss can occur, particularly in both multihop remote mirror replication and remote mirror disaster recovery scenarios. The system administrator must assure that this does not happen. See the Sun StorageTek Availability Suite 4.0 Remote Mirror Software Administration Guidefor further information.

Using Point-in-Time Copy Volume Sizing With the Remote Mirror Software

In a point-in-time copy snapshot, the shadow volume is made to look exactly like the master volume, including matching the number of blocks. If the master volume is larger or smaller than the shadow volume, the shadow volume appears to be resized at the moment the snapshot is taken. Physically, the shadow has not changed size, but the point-in-time copy kernel module always reports that the shadow is the same size as the master.

This can present several problems with the Remote Mirror software, which does not expect the size of the volume to change:

If you plan to use a remote mirror primary or secondary volume as a point-in-time copy shadow volume, the master and the shadow of that point-in-time copy volume set must be exactly the same size. If they are different, you see an error when attempting to enable the point-in-time copy volume set with the iiadm -e command.

You might also see this error during a disable iiadm -d command. If the shadow volume of the existing point-in-time copy volume set is not the same size as the master volume, and a remote mirror volume set was enabled using that shadow volume as the primary or secondary, the Point-in-Time Copy software stops you from performing the disable operation.

Point-in-Time Copy Software in a Sun Cluster 3.1/3.2 Environment

Point-in-Time Copy software volumes can be hosted in the Sun Cluster 3.1 environment and the Sun Cluster 3.2 environment. Clustering allows point-in-time copy replications to fail over, or continue unaffected, if a node hosting a point-in-time copy shadow volume set crashes. Failing over involves placing the volumes of the affected node under the control of another node in the cluster and continuing the replication when the new node takes control. This process is automated by the Sun Cluster environment as part of its control of volume management.

A successful Point-in-Time Copy software fail over requires proper configuration of the shadow volume sets in a Sun Cluster resource group. A resource group is a grouping of items in a Sun Cluster that are interrelated in such a way as to make it impossible to fail over a single member of the group without failing over all members of the group. That is, members of a resource group are dependent upon one another when a node in the cluster fails over. Detailed information about resource groups is available in the Sun Cluster documentation.

Failovers

When the Point-in-Time Copy software is running in a cluster and the node it is running on fails, the Sun Cluster software detects the failure and initiates failover. Conceptually, failover involves restarting the processes that were running on the failing node on another node, without losing any information. This information is application dependent and outside the control of the Sun Cluster environment. The environment coordinates the movement of the associated file systems, shadow volume sets, volumes, networking, and configuration data.

In the case of Point-in-Time Copy software, control of the volumes being referenced (master volume, shadow volume, and bitmap volume) must be moved to the new node. Then operations restart at the point where they left off.

The Point-in-Time Copy software must be configured such that the master volume, the bitmap volume, and the overflow volume are part of the same volume manager device group. All members of the device group must be available at the point at which the Point-in-Time Copy software comes up in the boot sequence. The shadow volume can be in a different device group, in order to afford the use of export, import, and join in a Sun Cluster.

Because of its position in the kernel I/O stack, failing over the Point-in-Time Copy software is similar to failing over a volume manager. The Sun StorageTek software and the Sun Cluster software work together to ensure that I/O processing on point-in-time copy volumes is enabled at the correct point in the failover process on the new node, and that processing on in-transit I/O is completed. The bitmap volumes are utilized to continue with operations on the new node. The bitmap volumes for point-in-time copy volumes running in a Sun Cluster environment must be disk-based, not memory-based.

Additional Performance Considerations

Consider the following when configuring a system for use with Point-in-Time Copy software:

Configure to avoid hot spots. Do not put multiple volumes on a single spindle.

Disk speeds of both the master volume and the shadow volume affect the performance of the master volume during independent shadow volume set synchronizations.

The performance of the master volume is affected by accesses to a dependent shadow volume.

If the Sun StorageTek Availability Suite software is used with a file system, tuning the number of SV threads often produces better performance.

Several performance considerations exist for the Sun StorageTek Availability Suite 4.0 Point-in-Time Copy software and this list is not comprehensive.

When a filesystem flushes its cache, it generates many parallel writes. SV's default setting of 32 threads could produce a bottleneck. The maximum number of threads allowed is 1024.

Note - Each thread consumes 32k of memory.

The tuneable, sv_threads, is in /usr/kernel/drv/sv.conf. Because sv.conf values are read when a module loads, changes to the sv_threads value will not take effect until you restart the Availability Suite services using dscfgadm.