It can be useful to copy from a SnapMirror destination when the data you want to copy is on a destination that is closer to you than the same data on a source. It is also useful to copy from a destination when you need to copy data from one site to many sites. Instead of propagating the data from one central master site to each of the destination sites, which would require expensive network connections or excessive CPU time, you can propagate the data from one destination to another destination and from that one to the next, in a series.
In the example below, the data on systemA is copied on nine different storage systems, but only two of the systems copy the data directly from the source. The other seven storage systems copy the data from a destination site.
Note
The cascading procedure is supported for SnapMirror volume replication only. Cascading is not supported for SnapMirror qtree replication.
Because there are different types of SnapMirror available to you, it is not clear what types of SnapMirror are supported as you cascade from one storage system to another. The supported cascading configurations are listed in the following table.
This table should be read from left to right. For example, the first line states that filerA has a synchronous volume SnapMirror relationship with filerB and that filerB has an asynchronous volume SnapMirror relationship with filerC.
You can copy from a destination volume the same way you copy from a writable source volume. For information on how to set up a destination, see Enabling SnapMirror.
To support a series of cascading volume destinations as shown in the diagram above, the /etc/snapmirror.conf file in each of the cascaded systems would look like this:
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, 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.
SnapMirror retains the Snapshot copies on the original source volume 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 use the snapmirror release command from the immediate source to tell SnapMirror to delete the Snapshot copies associated with that destination.
You can cascade volume destinations from a synchronous Snapmirror destination, but the cascading series is slightly different from that for asynchronous SnapMirror. For a synchronous SnapMirror, the first replication is the only synchronous SnapMirror replication in the cascade, and the synchronous replication can be to one destination storage system only. Subsequent SnapMirror replications cascading from that destination system must be asynchronous and can be to multiple destination systems.
To display the SnapMirror destinations for a source volume, complete the following step.
Following is an example of the snapmirror destinations command output for the configuration in the diagram above.
systemA> snapmirror destinations vol1
Path Destination
/vol/vol1 systemB:vol1->systemC:vol1->systemD:vol8
/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
If you do not specify a volume name in the command, the output includes information about each destination volume on the storage system.
You might restructure a cascade to balance loading of your systems; to use a storage system or volume for a different purpose; or to perform upgrades, maintenance, or repairs. For example, in the cascade structure that follows, you might want to make systemD:vol1 a destination of systemM:vol1 instead of a destination of systemC:vol1.
To restructure the relationship of the destinations in a cascade, complete the following steps.
For the example shown in the diagram that follows, suppose that from systemB you enter the following command:
snapmirror release vol1 systemC:vol1
These results follow:
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 need to either delete the entry in the /etc/snapmirror.conf file or comment out the entry by preceding it with a pound sign (#). Otherwise, SnapMirror continues to try to update the destination.
Copyright © 1994-2005, Network Appliance, Inc. All rights
reserved.
Part No. 210-01081_B0
File: mirror28.htm
Last updated: 01-Dec-2005 16:36:03