You can replicate data from a SnapMirror destination to another system using SnapMirror.
Therefore, a system that is a destination for one SnapMirror relationship can act as the source for another SnapMirror relationship. This is useful when you need to copy data from one site to many sites.
Instead of replicating data from a single source to each of the destinations, you can replicate data from one destination to another destination, in a series. This is referred to as cascading.
Note: You can replicate data from a destination volume in the same way you replicate from a writable source volume.
Related concepts
Initialization of a SnapMirror destination on page 110
Related tasks
Setting up a basic SnapMirror operation on page 99 Enabling SnapMirror by entering license codes on page 77
Related references
Methods for specifying destination systems on the SnapMirror source on page 119 Maximum number of concurrent replication operations on page 116
Supported cascade configurations for SnapMirror
Only certain types of SnapMirror configurations support cascading.
The supported cascading configurations are listed in the following table. Any other configuration, such as extending the cascade beyond the number of cascades shown in the table, is not supported.
This limitation does not apply to the strictly asynchronous volume SnapMirror cascading configuration, which can propagate to more than three systems.
The following table lists the two-hop cascade configurations that are supported for SnapMirror replication:
System A to system B System B to system C
Synchronous SnapMirror Asynchronous volume SnapMirror
Asynchronous volume SnapMirror Asynchronous volume SnapMirror Asynchronous volume SnapMirror Qtree SnapMirror
Qtree SnapMirror Asynchronous volume SnapMirror
This table should be read from left to right.
Example
The first line states that system A has a synchronous SnapMirror relationship with system B, and that system B has an asynchronous volume SnapMirror relationship with system C.
When the first hop in the cascade is synchronous SnapMirror, the synchronous replication can be to one destination system only. Subsequent SnapMirror replications cascading from that destination system must be asynchronous and can be to multiple destination systems.
Supported three-hop cascade configurations for SnapMirror
Only certain combinations of SnapMirror replication types are supported for three-hop cascade configurations.
Cascades of three SnapMirror relationships whose first relationship is a synchronous SnapMirror relationship are supported on Data ONTAP 7.1.2 and 7.2.1 releases, and later releases.
The following table lists the three-hop cascade configurations that are supported for SnapMirror replication:
System A to system B System B to system C System C to system D Synchronous SnapMirror Asynchronous volume
SnapMirror
Asynchronous volume SnapMirror
Synchronous SnapMirror Asynchronous volume SnapMirror
Qtree SnapMirror
Asynchronous volume SnapMirror
Asynchronous volume SnapMirror
Asynchronous volume SnapMirror
Asynchronous volume SnapMirror
Asynchronous volume SnapMirror
Qtree SnapMirror
Asynchronous volume SnapMirror
Qtree SnapMirror Asynchronous volume
SnapMirror
Qtree SnapMirror Asynchronous volume
SnapMirror
Asynchronous volume SnapMirror
Sample cascade setup
To support a series of cascading volume destinations as shown in the preceding diagram, the entries in the /etc/snapmirror.conf file in each of the systems is the cascade should be similar to the following entries:
systemA:vol1 systemB:vol1 - 15 * * 1,2,3,4,5 systemA:vol1 systemL:vol1 - 15 * * 1,2,3,4,5 systemB:vol1 systemC:vol1 - 25 * * 1,2,3,4,5 systemC:vol1 systemD:vol1 - 35 * * 1,2,3,4,5 systemL:vol1 systemM:vol1 - 25 * * 1,2,3,4,5 systemM:vol1 systemX:vol1 - 35 * * 1,2,3,4,5 systemM:vol1:systemN:vol1 - 35 * * 1,2,3,4,5 systemX:vol1 systemY:vol1 - 45 * * 1,2,3,4,5 systemX:vol1 systemZ:vol1 - 45 * * 1,2,3,4,5
Note: When specifying the destination update schedule in the snapmirror.conf file, you should stagger the update times instead of starting multiple destination updates at the same time. If SnapMirror does not have enough resources to perform all scheduled destination updates, it postpones some updates. As a result, SnapMirror might need to perform subsequent updates at times that are different from those you specify in the snapmirror.conf file.
How SnapMirror handles Snapshot copies for cascading destinations
SnapMirror retains on the original source volume the Snapshot copies needed for transfers to destinations further down the line. Snapshot copies that are still needed by a destination are labeled snapmirror in the output of the snap list command. SnapMirror deletes the Snapshot copies it no longer needs.
If you remove a destination from the cascade, you can use the snapmirror release command from the immediate source to tell SnapMirror to delete the Snapshot copies associated with that destination.
Listing SnapMirror destinations for a volume in a cascading series
You can use the snapmirror destinations command to display the destinations for a volume in a cascading series.
About this task
The snapmirror destinations command also displays entries related to vol clone command and dump command operations (if any) for SnapMirror source or destination volumes.
Step
1. From the system with the volume serving as the source, enter the following command:
snapmirror destinations [-s] [volume_name]
The -s option generates a list of the names of the Snapshot copies retained for each destination.
volume_name is the name of the source volume for which you want to see the destinations.
Listing SnapMirror destinations for a volume in a cascading series Suppose that you have used the snapmirror destinations command for a cascade configuration depicted in the following figure:
The output for the snapmirror destinations command for such a cascade configuration is similar to the following:
systemA> snapmirror destinations vol1 Path Destination
/vol/vol1 systemB:vol1->systemC:vol1->systemD:vol1
/vol/vol1 systemL:vol1->systemM:vol1->systemX:vol1->systemY:vol1 /vol/vol1 systemL:vol1->systemM:vol1->systemX:vol1->systemZ:vol1 /vol/vol1 systemL:vol1->systemM:vol1->systemN:vol1
Note: If you do not specify a volume name in the command, the output includes information about each destination volume on the system.
Restructuring a cascade
You might want to restructure a cascade to balance the load on your systems; to use a system or volume for a different purpose; or to perform upgrades, maintenance, or repairs.
About this task
For example, in the following cascade structure, you might want to make systemD:vol1 a destination of systemM:vol1 instead of a destination of systemC:vol1.
Figure 1: Restructuring the relationship of the destinations in a cascade
Steps
1. On the destination system, change the /etc/snapmirror.conf file to indicate the new source for the destination.
Example
systemM:vol1 systemD:vol1 - 35 * * 1,2,3,4,5 2. As required, choose one of the actions from the following table.
If the newest Snapshot copy on the destination...
Then...
Exists on the source Use the following command to update the destination from the new source.
snapmirror update -S
source_volume dest_system:dest_volume For example:
snapmirror update -S systemM:vol1 systemD:vol1 Does not exist on
the source
Perform one of the following tasks.
• Update the new source from the original source using the snapmirror update command. Wait for the destination to update.
• Make the destination writable using the snapmirror break command.
Then resynchronize the destination with the new source using the snapmirror resync command.
3. Release the former source using the following command:
snapmirror release source_volume [[dest_system:]dest_volume]
Example
systemC> snapmirror release systemC:vol1 systemD:vol1
Disconnecting a destination from a cascading series
The diagram depicts the change in the SnapMirror cascade configuration.
Figure 2: Disconnecting a destination in a cascade
For the configuration depicted in the preceding diagram, suppose that from systemB you enter the following command:
snapmirror release vol1 systemC:vol1 These results follow.
• systemA:vol1 continues to be the source for the destination systemB:vol1.
• systemC:vol1 no longer copies from systemB:vol1. SnapMirror retains Snapshot copies for systemC and below.
• If systemC requests an update from systemB, the destination is reestablished if it is still not writable and the base Snapshot copy still exists on the source.
• systemD:vol1 still copies systemC:vol1.
• All the destinations that depend on systemL:vol1 continue functioning as before.
You can check that the destination was released by running the snapmirror destinations command on systemA, as follows.
systemA> snapmirror destinations -s systemA:vol1 Volume Snapshot Destination vol1 systemB(0015269532)_vol1.37 systemB:vol1
vol1 systemL(0015269532)_vol1.42 systemL:vol1->systemM:vol1->systemXvol1->systemY:vol1 vol1 systemL(0015269532)_vol1.42 systemL:vol1->systemM:vol1->systemXvol1->systemZ:vol1 vol1 systemL(0015269532)_vol1.42 systemL:vol1->systemM:vol1->systemN:vol1
Note: If you want to permanently release a destination, you should delete the entry in the /etc/snapmirror.conf file. Alternatively, you can comment out the entry by preceding it with a pound sign (#). Otherwise, SnapMirror attempts to update the destination.