Considerations when planning and running SnapMirror

Prerequisites to running SnapMirror

The following prerequisites must be met before you can run SnapMirror:

You must purchase and enable the SnapMirror license.
If the SnapMirror source and destination are on different systems, you must purchase a license and enter the SnapMirror license code on each system. For information on enabling the SnapMirror license, see Entering license codes.
For SnapMirror volume replication, you must create a restricted volume to be used as the destination volume.
SnapMirror does not automatically create a volume. See the section on organizing data using volumes and qtrees in the Storage Management Guide for information about how to create volumes.
For SnapMirror volume replication, the destination volume must run under a version of Data ONTAP the same as or later than that of the SnapMirror source volume.
If you configure volume SnapMirror to support replication for the purpose of disaster recovery, both the source and destination systems should run the same version of ONTAP software.

Caution
If you upgrade your systems to a later version of Data ONTAP, upgrade the systems of SnapMirror destination volumes before you upgrade the systems of SnapMirror source volumes.
For SnapMirror qtree replication, you must not create a qtree to be used as a destination qtree; the snapmirror initialize command creates the destination qtree automatically.
For SnapMirror qtree replication, the destination qtree must run under Data ONTAP version 6.2 or later.
The name and IP address of the source system must be in the /etc/hosts file of the destination system or must be resolvable by way of DNS or yp.

Restrictions

When planning SnapMirror configuration, consider the following restrictions:

The source volume must be online.
See the Storage Management Guide for information about how to put a volume online.
For SnapMirror volume replication, the capacity of the destination volume must be greater than or equal to the capacity of the source volume. See Verifying the size of each volume for information about using the vol status -b command to check the capacity of the source volume and destination volume. See the Storage Management Guide for information about how to add disks to a volume. See Initializing a SnapMirror destination for information about disk sizes.
To support SnapMirror qtree replication, the destination volume must contain 5% more free space than the source qtree consumes.
The SnapMirror destination volume cannot be the root volume of a storage system. The SnapMirror source volume, however, can be the root volume.
A destination qtree can be on the root volume, but the /etc qtree cannot be a destination qtree.
Destination qtrees names cannot
- Consist of "*" or "-" or "/etc"
- Contain the character "." or the character combination "->" (this restriction applies to source qtrees too)
- Contain space or tab characters
- Be longer than 64 characters
- Be specified as "/vol/volname/" (with no qtree name)
- Be specified as "volname/qtree_name (with no /vol/)"
There must be a functional network to transfer data between two different storage systems.
Each storage system model supports a specified number of snapmirror update or vol copy operations at a time. (See Maximum number of simultaneous replication operations for the number of copy operations each system can support.)

Cautions

Be advised of the following cautions:

Do not delete Snapshot copies that SnapMirror creates in the source volume and then copies to the destination. The most recent SnapMirror Snapshot copy is referred to as the newest common Snapshot copy (NCS). Incremental changes to the destination depend on the newest common Snapshot copy. If SnapMirror cannot find the required Snapshot copy on the source, it cannot perform incremental changes to the destination.
Do not use the snapmirror release or snapmirror break command on the destination volume or qtree unless you no longer need to copy incremental changes from the source. The destination must be actively functioning as a destination to receive incremental updates.
Do not restrict or take the destination volume offline while SnapMirror is configured to transfer. Taking the destination offline prevents SnapMirror from performing updates to the destination.

Recommendations

Follow these recommendations to copy data efficiently:

For smoothest performance, stagger your Snapshot update schedules so that SnapMirror activity does not begin, or end at the exact minute a snap sched operation attempts to create a Snapshot copy.
If the SnapMirror feature is scheduled to perform Snapshot management at the same time as a snap sched activity, then the Snapshot management operations scheduled using the snap sched command might fail with syslog messages, "Skipping creation of hourly snapshot," and "Snapshot already exists."
For optimum SnapMirror volume replication performance, make sure that the SnapMirror source volume and destination volume contain disks of the same size, organized in the same RAID configuration.
If the SnapMirror source and destination are qtrees, volume size and configuration do not make any difference.
If you plan to do SnapMirror transfers through a firewall, you might need to know the port number used by SnapMirror. SnapMirror listens for connections on port 10566.

Snapshot schedule conflicts

If the SnapMirror feature is scheduled to perform Snapshot management at the same time as a snap sched activity, then the Snapshot management operations scheduled using the snap sched command might fail generating syslog messages such as, "Skipping creation of hourly snapshot," and "Snapshot already exists."

To avoid this condition, stagger your Snapshot update schedules so that SnapMirror activity does not begin, or end at the exact minute a snap sched operation attempts to create a Snapshot copy.

Ensuring accessible destinations when using CIFS

Directories on all SnapMirror source volumes that support CIFS clients must be in Unicode format before being replicated to a destination; otherwise, the directories in the read-only destination volume will not be in Unicode format and attempts through CIFS to access directories and open files on the destination volume can receive "access denied" errors.

You can ensure that both source volume and destination volume directories are in Unicode format using the following methods:

On the system console for the source volume, enter the following two commands:
- vol options volname convert_ucode on to convert any existing directories on the source volume to Unicode format.
- vol options volname create_ucode on to automatically create any new directories on the source volume in Unicode format.
Another option is to make sure that all directories on the source volume that will be accessed by CIFS clients are accessed by a CIFS client before initial replication to a destination. Such access on a writable source volume automatically converts that directory to Unicode format.

Adjusting the TCP window size

A TCP window is the amount of data that a source can send on a connection before it requires acknowledgement from the destination that the data was received. The default window size for SnapMirror operations is 1,994,752 bytes. This is a large window and, in some networks, particularly WANs, can result in the termination of the SnapMirror transfer or very low throughput. To change the TCP window size to fit your network better and avoid these problems, complete the following steps.

Step	Action
1	Calculate a TCP window size that works well in your network using the following fomula: WindowSize = (RoundTrip Delay) (DesiredRate) Example If your average round trip delay is 100 milliseconds and you want a rate of 10 Mbps, you should set the TCP window size to 125,000 bytes as the following equation shows: 0.1 * 10,000,000/8 = 125,000
2	Adjust the TCP window size by entering the following command: options snapmirror.window_size rate rate is the desired TCP window size.

Step

Action

Calculate a TCP window size that works well in your network using the following fomula:

WindowSize = (RoundTrip Delay) (DesiredRate)

Example

If your average round trip delay is 100 milliseconds and you want a rate of 10 Mbps, you should set the TCP window size to 125,000 bytes as the following equation shows:

0.1 * 10,000,000/8 = 125,000

Adjust the TCP window size by entering the following command:

options snapmirror.window_size rate

rate is the desired TCP window size.

Firewall usage

The destination storage system contacts the SnapMirror source storage system at TCP port 10566 using any of the permissible, available ports assigned by the system. Your firewall must allow requests to this port of the SnapMirror source storage system. It is recommended that you allow a range of TCP ports from 10565 to 10569.