The Basics:
When mirroring asynchronously, SnapMirror replicates Snapshot copy images from a source volume or qtree to a partner destination volume or qtree, thus replicating source object data to destination objects at regular intervals. SnapMirror source volumes and qtrees are writable data objects whose data is to be replicated. The source volumes and qtrees are the objects that are normally visible, accessible, and writable by the storage system’s clients.
The SnapMirror destination volumes and qtrees are read-only objects, usually on a separate storage system, to which the source volumes and qtrees are replicated. Customers might want to use these read-only objects for auditing purposes before the objects are converted to writable objects. In addition, the read-only objects can be used for data verification. The more obvious use for the destination volumes and qtrees is to use them as true replicas for recovery from a disaster. In this case, a disaster takes down the source volumes or qtrees and the administrator uses SnapMirror commands to make the replicated data at the destination accessible and writable.
SnapMirror uses information in control files to maintain relationships and schedules. One of these control files, the snapmirror.conf file, located on the destination system, allows scheduling to be maintained. This file, along with information entered by using the snapmirror.access option or the snapmirror.allow file is used to establish a relationship between a specified source volume, or qtree for replication, and the destination volume, or qtree where the mirror is kept.
Snapshot Copy Behavior in SnapMirror:
SnapMirror uses a Snapshot copy as a marker for a point in time for the replication process. A copy is kept on the source volume as the current point in time that both mirrors are in sync. When an update occurs, a new Snapshot copy is created and is compared against the previous Snapshot copy to determine the changes since the last update. SnapMirror marks the copies it needs to keep for a particular destination mirror in such a way that the snap list command displays the keyword snapmirror next to the necessary Snapshot copies.
The snapmirror destinations command can be used to see which replica of a particular copy is marked as required at any time. On the source volume, SnapMirror creates the Snapshot copy for a particular destination and immediately marks it for that destination. At this point, both the previous copy and the new copy are marked for this destination. After a transfer is successfully completed, the mark for
the previous copy is removed and deleted. Snapshot copies left for cascade mirrors from the destination also have the snapmirror tag in the snap list command output.
Use the snapmirror destinations -s command to find out why a particular Snapshot copy is marked. This mark is kept as a reminder for SnapMirror to not delete a copy. This mark does not stop a user from deleting a copy marked for a destination that will no longer be a mirror; use the snapmirror release command to force a source to forget about a particular destination. This is a safe way to have SnapMirror remove its marks and clean up Snapshot copies that are no longer needed. Deleting a Snapshot copy that is marked as needed by SnapMirror is not advisable and must be done with caution in order not to disallow a mirror from updating. While a transfer is in progress, SnapMirror uses the busy lock on a Snapshot copy. This can be seen in the snap list command output. These locks do prevent users from deleting the Snapshot copy. The busy locks are removed when the transfer is complete.
For volume replication, SnapMirror creates a Snapshot copy of the whole source volume that is copied to the destination volume. For qtree replication, SnapMirror creates Snapshot copies of one or more source volumes that contain qtrees identified for replication. This data is copied to a qtree on the destination volume and a Snapshot copy of that destination volume is created.
Snapshot examples:
A volume SnapMirror Snapshot copy name has the following format:
dest_name(sysid)_name.number
Example: fasA(0050409813)_vol1.6 (snapmirror)
dest_name is the host name of the destination storage system.
sysid is the destination system ID number.
name is the name of the destination volume.
number is the number of successful transfers for the Snapshot copy, starting at 1. Data ONTAP increments this number for each transfer.
A qtree SnapMirror Snapshot copy name has the following format:
dest_name(sysid)_name-src|dst.number
Example: fasA(0050409813)_vol1_qtree3-dst.15 (snapmirror)
dest_name is the host name of the destination storage system.
sysid is the destination system ID number.
name is the name of the destination volume or qtree path.
src|dst identifies the Snapshot copy location.
number is an arbitrary start point number for the Snapshot copy. Data ONTAP increments this number for each transfer.
In the output of the snap list command, Snapshot copies needed by SnapMirror are followed by the SnapMirror name in parentheses.
Caution: Deleting Snapshot copies marked snapmirror can cause SnapMirror updates to fail.
Modes of SnapMirror:
SnapMirror can be used in three different modes: SnapMirror Async, SnapMirror Sync, and SnapMirror Semi-Sync.
SnapMirror Async:
SnapMirror Async can operate on both qtrees and volumes. In this mode, SnapMirror performs incremental block-based replication as frequently as once per minute.
The first and most important step in this mode involves the creation of a one-time baseline transfer of the entire dataset. This is required before incremental updates can be performed. This operation proceeds as follows.
1. The source storage system creates a Snapshot copy (a read-only point-in-time image of the file system). This copy is called the baseline copy.
2. All data blocks referenced by this Snapshot copy and any previous copies are transferred in case of volume SnapMirror and written to the destination file system. Qtree SnapMirror only copies the latest Snapshot copy.
3. After the initialization is complete, the source and destination file systems have at least one Snapshot copy in common.
After the initialization is complete, scheduled or manually triggered updates can occur. Each update transfers only the new and changed blocks from the source to the destination file system. This operation proceeds as follows:
1. The source storage system creates a Snapshot copy.
2. The new copy is compared to the baseline copy to determine which blocks have changed.
3. The changed blocks are sent to the destination and written to the file system.
4. After the update is complete, both file systems have the new Snapshot copy, which becomes the baseline copy for the next update.
Because asynchronous replication is periodic, SnapMirror Async is able to consolidate the changed blocks and conserve network bandwidth. There is minimal impact on write throughput and write latency.
SnapMirror Sync:
Certain environments have very strict uptime requirements. All data that is written to one site must be mirrored to a remote site or system synchronously. SnapMirror Sync mode is a mode of replication that sends updates from the source to the destination as they occur, rather than according to a predetermined schedule. This helps enable data written on the source system to be protected on the destination even if the entire source system fails. SnapMirror Semi-Sync mode, which minimizes data loss in a disaster while also minimizing the extent to which replication affects the performance of the source system, is also provided.
No additional license fees need to be paid to use this feature, although a free special license snapmirror_sync must be installed; the only requirements are appropriate hardware, the correct version of Data ONTAP, and a SnapMirror license for each storage system. Unlike SnapMirror Async mode, which can replicate volumes or qtrees, SnapMirror Sync and Semi-Sync modes work only with volumes. SnapMirror Sync can have a significant performance impact and is not necessary or appropriate for all applications.
The first step in synchronous replication is a one-time baseline transfer of the entire dataset. After the baseline transfer is completed, SnapMirror will make the transition into synchronous mode with the help of NVLOG and CP forwarding. Once SnapMirror has made the transition into synchronous mode, the output of a SnapMirror status query shows that the relationship is “In-Sync.”
SnapMirror Semi-Sync:
SnapMirror provides a semi-synchronous mode, also called SnapMirror Semi-Sync. This mode differs from the synchronous mode in two key ways:
1. User writes don’t need to wait for the secondary or destination storage to acknowledge the write before continuing with the transaction. User writes are acknowledged immediately after they are committed to the primary or source system’s memory.
2. NVLOG forwarding is not used in semi-synchronous mode. Therefore SnapMirror Semi-Sync might offer faster application response times. This mode makes a reasonable compromise between performance and RPO for many applications.
Note: Before Data ONTAP 7.3, SnapMirror Semi-Sync was tunable, so that the destination system could be configured to lag behind the source system by a user-defined number of write operations or seconds. This was configurable by specifying a variable called outstanding in the SnapMirror configuration file. Starting in Data ONTAP 7.3, the outstanding parameter functionality is no longer available and there is a new mode called semi-sync. When using semi-sync mode, only the consistency points are synchronized. Therefore this mode is also referred to as CP Sync mode.
Configuration of semi-synchronous mode is very similar to that of synchronous mode; simply replace sync with semi-sync, as in the following example:
fas1:vol1 fas2:vol1 – semi-sync
That's it:)
