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 filers, you must purchase a license and enter the SnapMirror license code on each filer. 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 information in the System Administration Storage Management Guide in the section "Data Organization Using Volumes and Qtrees" for information about how to create volumes.
- For SnapMirror volume replication, the destination volume must run under a version of Data ONTAP equal to or later than that of the SnapMirror source volume. If you upgrade your filers to a newer version of Data ONTAP, upgrade the filers of SnapMirror destination volumes before you upgrade the filers 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 filer must be in the /etc/hosts file of the destination filer or must be resolvable by way of DNS or yp.
Restrictions
When planning SnapMirror configuration, consider the following restrictions:
Cautions
Be advised of the following cautions:
- Do not delete snapshots that SnapMirror creates in the source volume and then copies to the destination. The most recent SnapMirror snapshot is referred to as the newest common snapshot (NCS). Incremental changes to the destination depend on the newest common snapshot. If SnapMirror cannot find the required snapshot 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:
Ensuring accessible destinations via 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 filer 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.
|
Copyright © 1994-2003, Network Appliance, Inc. All rights
reserved.
Part No. 210-00476
File: mirror4.htm
Last updated: 11/13/03 17:17:26