SL10498 Hol

SnapMirror Unified Replication
October 2018 | SL10498 Version 1.3

1 Introduction
SnapMirror and SnapVault deliver powerful data management capabilities, including the ability to protect critical
data, while providing the flexibility to replicate data between on-premise or cloud-based ONTAP storage tiers.
• SnapMirror provides asynchronous mirroring of volumes from one Storage Virtual Machine (SVM) to
another, even across different clusters whether they are on-prem or in the cloud.
• SnapVault provides storage-efficient and long-term retention of backups also through asynchronous
replication.
• Bandwidth utilization is reduced by using native network compression thus accelerating data transfers
and enabling a lower recovery point objective (RPO).
• Unified replication allows you to configure disaster recovery and archiving on the same destination
volume. When unified replication is appropriate, it offers benefits in reducing the amount of secondary
storage you need, limiting the number of baseline transfers, and further decreasing network traffic.
• By incorporating storage efficient unified replication transfer costs especially for cloud hyperscalers is
reduced.
With SnapMirror and SnapVault, you can reduce your overall TCO, and make it easier to justify Disaster
Recovery investment by putting your DR site to active business use.
1.1 Lab Objectives

The overall objective of this lab is to familiarize you with Data Protection and Replication technologies like
SnapMirror and SnapVault in ONTAP. You will learn how to modify policies as part of SnapVault and SnapMirror
relationships. Additionally, the lab will take you through the steps required to configure and monitor SnapVault
and SnapMirror relationships using NetApp Manageability tools and the Command Line Interface.
1.2 Prerequisites
In order to use this lab successfully, the following are the recommended prerequisites:
• This lab assumes you have a basic working knowledge of ONTAP, but does not require any previous
experience with SnapMirror or SnapVault.

2 © 2018 NetApp, Inc. All rights reserved. NetApp Proprietary
2 Lab Environment
All of the servers and storage controllers presented in this lab are virtual devices, and the networks that
interconnect them are exclusive to just your lab session. The virtual storage controllers (vsims) offer nearly all the
same functionality as do physical storage controllers, but at a reduced performance profile. Currently, the main
exception is that vsims do not offer HA support.
Figure 2-1: Virtual Servers and Storage Controllers
Table 1: Table of Systems
Host Name Operating System Role/Function IP Address

jumphost Windows Server 2012 R2 Primary desktop in lab 192.168.0.5
cluster1 (1 node) ONTAP 9.4 Storage controller 192.168.0.101
dc1 Windows Server 2012 R2 Active Directory / DNS 192.168.0.253
rhel1 Redhat Enterprise Linux NFS Client 192.168.0.61
6.8

Table 2: User IDs and Passwords
Host Name User ID Password Comments

jumphost DEMO\Administrator Netapp1! Domain Administrator
cluster1 admin Netapp1! FAS administrator
dc1 DEMO\Administrator Netapp1! Domain Administrator
rhel1 root Netapp1! Administrator

3 Lab Limitations
This lab has the following limitations:
• All of the servers and storage controllers presented in this lab are virtual devices. Consequently, any
operations that involve moving large quantities of data will not exhibit performance representative of
real systems.
• Some of the speciaized tasks in this lab are performed using command line sessions due to current
restrictions of the standard GUI tool.

4 Lab Activities
Key NetApp capabilities will be highlighted:
• Tour the Environment
• Unplanned Switchover: High Availability for Business Continuity
• MetroCluster Healing and Switchback
4.1 SnapMirror Overview

SnapMirror is disaster recovery technology, designed for failover from primary storage to secondary ONTAP
storage at a geographically remote site or even the cloud. As its name implies, SnapMirror creates a replica, or
mirror, of your working data in secondary storage from which you can continue to serve data in the event of a
catastrophe at the primary site.
SnapMirror periodically updates the replica to keep it up-to-date with changes that have been written to the
primary. The SnapMirror subsystems are designed to keep many pairs of source (primary) and destination
(secondary) copies up-to-date in an efficient and scalable manner.
Once two volumes have an established SnapMirror relationship, the scheduler assumes the responsibility for
triggering replication updates. The following operations are performed during each update:
• A new snapshot copy is created on the source volume.
• The difference between the new snapshot copy and the last replication snapshot copy is determined,
and then transferred to the destination volume. This transfer includes any other snapshot copies that
were created between the last replication snapshot and the new one.
• When the transfer is complete, the new snapshot copy exists on the destination volume.
SnapMirror protection relationships can be resynchronized in either direction after a failover without recopying
the entire volume. If a relationship is resynchronized in the reverse direction, only new data written since the last
successful synchronization snapshot is sent back to the destination.
4.1.1 View Existing SnapMirror Relationship
1. On the Jumphost, launch the Chrome web browser from the task bar.
Figure 4-1:
2. Use the cluster2 System Manager button on the browser's bookmark bar to launch and log in to
System Manager for "cluster2".
3. Fill in the System Manager login credentials:
• User Name: admin
• Password: Netapp1!
4. Click the Sign In button to log in to System Manager.

3
Figure 4-2:
System Manager displays the Dashboard view for cluster2.

5. In the dashboard view for “cluster2”, click Protection > Relationships on the left menu.

5
Figure 4-3:
System Manager now displays the Relationships pane.

Note: If you don't see any relationships, verify that you have opened System Manager for
"cluster2". Remember protection relationships are created and managed on the destination
cluster.
6. In the “Relationships” pane, select the relationship with the source volume snapmirror_src1. You may
need to expand the column headings by dragging the separators to see the full name of the source
volume.
7. Note that this particular SnapMirror relationship is using the DPDefault policy. This is a default policy
supplied with ONTAP that contains reasonable defaults suitable for most typical relationships.
8. Look at the Details tab at the bottom of the lower pane to view the details of the SnapMirror relationship
from the perspective of the destination cluster. You may need to use the scrollbar at the bottom of the
pane to view all the available fields.
9. With the snapmirror_src1 relationship still selected, click the Edit button on the toolbar above the list of
protection relationships.

9
7
6
Figure 4-4:
The “Edit Relationship” dialog window opens, and displays the source and destination volumes for the
selected relationship. Here you can alter the relationships' assigned Mirror Policy and Schedule. You can
again see that this relationship is using the “DPDefault” Mirror Policy, but now you can also see that it is
using the predefined schedule 5min, which the accompanying summary information indicates runs every
day, every 5 minutes of each hour.
If you wanted to create a new policy or a new schedule, you could use the hyperlinks on the right of this
window to start that process, but to view the details of existing policies or schedules you have to look
elsewhere, as you will see later in this lab.
10. Click the Cancel button to close this window without applying any changes.
10
Figure 4-5:

The “Edit Relationship” window closes, and focus returns to the Relationships view in System Manager.
11. On left menu, click on Storage > SVMs.
12. Click the link for svm_dst1.
12
11
Figure 4-6:
System Manager displays the “Overview” page for svm_dst1.

13. Click on the SVM Settings tab at upper right of the overview window.
13
Figure 4-7:
14. In the pane that now displays on the left hand side of the window, click Protection Policies, which you
will find under the “Policies” section of that pane.
15. Note that there are no policies listed in the “Protection Policies” pane, not even the standard DPDefault
policy. ONTAP comes with several pre-defined standard policies, none of which are editable, and this
view only displays custom policies.

Note: To see the details of the predefined standard policies you must select Protection >
Protection Policies from left-hand menu. You are welcome to try this on your own if you like,
but doing so is not covered in this lab exercise.
16. In the right pane, click the Create button.
16
15
14
Figure 4-8:
The “Create Policy” window opens. In this window you can see the various properties that you can
assign to a custom protection policy through System Manager.
17. Examine the fields in this window. A “Policy Type” value of “Asynchronous Mirror” indicates a
SnapMirror relationship, and when selected the other fields in this window allow you to control various
aspects of the resulting SnapMirror relationship. The other possible “Policy Type” values are used for
"Mirror Vault" (Unified Replication) and SnapVault relationships. Notice how the contents of the “Create
Policy” window change as you select different “Policy Type” values.
18. When you are finished reviewing the contents of the “Create Policy” window, click Cancel.

17
18
Figure 4-9:
The “Create Policy” window closes, and focus returns to the “SVM Settings” view in System Manager.
Now you will take a closer look at the schedules that exist on cluster2.
19. On the left-hand menu, navigate to Protection > Schedules.
20. In the “Schedules” pane, select the 5min schedule.
21. Click the Edit button.
21
20
19
Figure 4-10:

The “Edit Schedule - 5min” window opens. As you saw earlier, this particular schedule will run every 5
minutes, but now you can see the many options you have for defining a schedule. Feel free to explore
the different scheduling options that become available when you switch between the Basic, Interval,
and Advanced radio button selections.
22. When you are finished exploring, click Cancel to discard any changes you may have made to the 5min
schedule during your exploration.
22
Figure 4-11:
The “Edit Schedule - 5min” window closes, and focus returns to the “Schedules” view in System
Manager.
Since SnapMirror leverages NetApp Snapshot technology, several aspects of SnapMirror behavior
are governed by the underlying volume’s snapshot configuration. For volumes that are in a SnapMirror
relationship, the source volume’s snapshot configuration applies to both the source and destination
volumes, so you will now look at cluster1 to view the source volume’s snapshot configuration.
23. Open a new Chrome browser tab.
24. Click on the browser bookmarks button for cluster1 System Manager.
25. Enter the User Name admin, and the password Netapp1!.
26. Click Sign In.
System Manager displays the “Dashboard” view for cluster1.
27. On the left menu select Storage > Volumes.
28. Select the snapmirror_src1 volume hyperlink in the “Volumes” pane.

28
27
Figure 4-12:
29. On the upper right of the “Volumes” pane, select More Actions > Manage Snapshots >
Configuration Settings.
29
Figure 4-13:
The “Configure Volume Snapshot Copies” window opens.

30. The Snapshot Reserve (%) field specifies what percentage of the volume’s disk space is set aside
for Snapshot copies. For FlexVol volumes, the default Snapshot copy reserve is set to 2 percent of the
disk space. The active file system cannot consume the Snapshot copy reserve space, but the Snapshot

copy reserve, if exhausted, can use space in the active file system. Verify that the Snapshot reserve
percentage field is set to 2%.
31. Click Cancel.
30
31
Figure 4-14:
The “Configure Volume Snapshot Copies” window closes, and focus returns to the Volumes view in
System Manager.
4.1.2 Create a SnapMirror Relationship
The topology for this portion of the lab is:

Figure 4-15:
Figure 4-16:
System Manager for cluster2.

2
Figure 4-17:

6. In the “Relationships” pane, click Create.
4
Figure 4-18:
The “Browse SVM” window opens.

7. Select the entry for the SVM named svm_dst1
8. Click Select.

6
Figure 4-19:
The “Browse SVM” window closes, and the “Create Protection Relationship” window opens.
9. In the "Create Protection Relationship" dialog box, select or enter the following:
Relationship Type: Mirror
Cluster: cluster1
SVM: snap_src1
Volume: Click Browse and select the volume mirror_me
Destination Volume SVM: verify it is set to svm_dst1
Volume name suffix: Leave default for this exercise.
Mirror Policy: Click Browse and select DPDefault
Schedule: Click Browse and select 5min
10. Scroll down to the bottom of this window and make sure the Initialize Relationship checkbox is
checked. (This checkbox is not shown in the accompanying screenshot, but is checked by default.)
11. Click Create.

8 9
10
Figure 4-20:
The “Create Protection Relationship” window closes, and focus returns to the “Relationships” view of
You can now view information regarding the SnapMirror relationship you just created.
12. While still in the “Relationships” window, select the mirror_me relationship. The Relationship State may
display as “Uninitialized”, and the Transfer Status as “Transferring”.
11 12
Figure 4-21:
13. In the main pane, click the Refresh button periodically until the “Transfer Status” value changes to
“Idle”.

14. Observe that the "Relationship State" field value has changed from the previous value of "Uninitialized"
to “SnapMirrored”.
13 14
Figure 4-22:
At this point, the baseline transfer of the volume’s contents from the source volume to the destination
volume has completed. Updates to this relationship will occur according to the assigned schedule, in
this case, every five minutes.
4.1.3 Perform a Manual Update
1. With the newly created protection relationship still selected, clicking on the Operations > Update button
at the top of the Relationships pane.
Figure 4-23:

The “Update” window opens.
2. The default values are all fine in this window, so click the Update button.
Figure 4-24:
The “Update” window closes.

3. The “Transfer Status” field for the relationship changes to “Transferring”.
Figure 4-25:
4. Click the Refresh button again periodically while you watch the update process execute. Once it finishes
the “Transfer State” field will display “Idle” again, at which point the SnapMirror update operation is
complete.
Figure 4-26:

In this activity you have viewed an existing SnapMirror protection relationship including the assigned policy and
schedule. You then established protection of a volume using the mirror-type of SnapMirror replication.
4.2 SnapVault Overview

SnapVault is archiving technology, designed for disk-to-disk Snapshot copy replication for standards compliance
and other governance-related purposes. In contrast to a SnapMirror relationship, in which the destination usually
contains only the Snapshot copies currently in the source volume, a SnapVault destination typically retains point-
in-time Snapshot copies created over a much longer period.
You might want to keep monthly Snapshot copies of your data over a 20-year span, for example, to comply with
government accounting regulations for your business. Since there is no requirement to serve data from vault
storage, you can use slower, less expensive disks on the destination system.
SnapVault and SnapMirror share the same command infrastructure. You specify which method you want to use
when you create a SnapMirror policy. Both methods require peered clusters and peered SVMs.
Another important architectural change is that SnapVault in clustered ONTAP replicates at the volume level as
opposed to the Qtree level, as in 7-Mode SnapVault. This means that the source of a SnapVault relationship must
be a volume, and that volume must replicate to its own volume on the SnapVault secondary.
Backing up volumes to a SnapVault backup involves starting the baseline transfer (the initial transfer when you
first establish the SnapVault relationship), performing scheduled incremental transfers, updating the SnapVault
common snapshot, and restoring data upon request.
• Baseline transfers
As with SnapMirror, SnapVault performs a baseline transfer the first time you invoke it. The SnapMirror
policy for the relationship defines the contents of the baseline and any updates.
Baseline transfer under the default SnapVault policy (XDPDefault) makes a Snapshot copy of the
source volume, then transfers that copy and the data blocks it references to the destination volume.
Unlike SnapMirror, SnapVault does not include older Snapshot copies in the baseline.
• Incremental transfers
Updates are asynchronous, following the schedule you configure. The rules you define in the policy
for the relationship identify which new Snapshot copies to include in updates and how many copies to
retain. The labels defined in the policy (“monthly,” for example) must match one or more labels defined
in the Snapshot policy on the source. Otherwise, replication fails.
At each update under the XDPDefault policy, SnapMirror transfers Snapshot copies that have been
made since the last update, provided they have labels matching the labels defined in the policy rules.
• Update SnapVault common snapshot
At the end of each Snapshot copy transfer session, which can include transferring multiple Snapshot
copies, the most recent incremental Snapshot copy in the SnapVault backup is used to establish a new
common base between the primary and secondary volumes, and is exported as the active file system.
• Data restore
If data needs to be restored to the primary volume, or to a new volume, the SnapVault secondary
transfers the specified data from the SnapVault backup.
4.2.1 SnapVault Exercise
In this exercise you will review the details of an existing SnapVault relationship between a source and destination
volume.
The topology for this exercise is as follows:

Figure 4-27:
Tasks
Open OnCommand System Manager for Cluster2
View an existing SnapVault Relationship
Edit existing relationship to view what can be modified
View Protection policies
4.2.1.1 View Existing SnapVault Relationship

Figure 4-28:

3
Figure 4-29:

6. In the “Relationships” pane, select the relationship for the source volume snapvault_src1. You may
need to expand the column headers if the source volume name is partially obscured.
7. Note that this particular SnapVault relationship is using the XDPDefault policy which is another
indicator that this is a SnapVault relationship. This is a default policy supplied with ONTAP that contains
reasonable defaults suitable for most typical relationships.
8. Look at the Details tab at the bottom of the lower pane to view the details of the SnapVault relationship
from the perspective of the destination cluster. You may need to use the scrollbar at the bottom of the
pane to view all the available fields.
9. With the snapvault_scr1 relationship still selected., click the Edit button on the menu bar above the list
of protection relationships.

9
5 6 7
8
Figure 4-30:
The “Edit Relationship” window opens.

10. Note the source and destination volumes for this relationship.
11. In the “Configuration Details” section, you can again see that this relationship is using the XDPDefault
Policy and the predefined schedule 5min,which the accompanying summary information indicates runs
every day, every 5 minutes of each hour.
12. You can click the Browse button next to the policy or schedule fields to change the policy and schedule
assignments for this relationship. Leave these fields as they are for this lab.
13. If you want to create a new policy, or a new schedule, use the hyperlinks on the right to start that
procedure.
14. Click the Cancel button to discard any changes you might have made.

10
12 13
11
14
Figure 4-31:
The “Edit Relationship” window closes, and focus returns to the “Relationship” view in System Manager.
15. From the left menu, click Storage > SVMs.
16. In the SVM list, click the svm_dst1 hyperlink.

16
15
Figure 4-32:
System Manager displays the “Overview” page for the svm_dst1 SVM.
17. Click on the SVM Settings tab at upper right of the overview window.
17
Figure 4-33:
18. In the pane that now displays on the left hand side of the window, click Protection Policies, which you
will find under the “Policies” section of that pane.
19. Note that there are no policies listed in the “Protection Policies” pane, not even the standard
XDPDefault policy. ONTAP comes with several pre-defined standard policies, none of which are
editable, and this view only displays custom policies.

Note: To see the details of the predefined standard policies you must select Protection >
Protection Policies from left-hand menu. You are welcome to try this on your own if you like,
but doing so is not covered in this lab exercise.
20. In the right pane, click the Create button.
20
19
18
Figure 4-34:
The “Create Policy” window opens. In this window you can see the various properties that you can
assign to a custom protection policy through System Manager.
21. Change the “Policy Type:” field to Vault, which indicates this will be a SnapVault policy.
22. Here you can see many of the same configuration options you saw when you examined how to create
a SnapMirror policy in a previous exercise, including the ability to set transfer priorities, and to enable
network compression. The other options under the “Policy Rules” section enable you to assign labels
and retention values for your SnapVault snapshots.
Note: As you will see in the Unified Replication Exercise, assigning labels help to identify
snapshots based on any criteria (backup type, application, frequency, etc). Setting the retention
provides control over the number of snapshots retained.
23. Since the procedure for creating a SnapVault relationship is otherwise the same as creating a
SnapMirror relationship (as you did in the preceding exercise), in the interest of saving time you will not
continue creating a SnapVault relationship here. After you review the contents of the “Create Policy”
window, click the Cancel button to exit the window without applying any changes.

21
23
Figure 4-35:
The “Create Policy” window closes, and focus returns to the “SVM Settings” view in System Manager.
SnapVault and SnapMirror share the same scheduling engine, and can also share the same schedules,
although in practice it is common to use different schedules for these two types of relationships as they
often require different update frequencies.
In this activity, you have viewed an existing SnapVault relationship including the assigned policy and schedule.
Since SnapMirror and SnapVault share the same scheduling engine the the creation and setup of a protection
relationship are quite similar. Unified Replication increases that similarity further as you will see in an upcoming
lab exercise.
4.3 SnapMirror Unified Replication Overview

SnapMirror Unified Replication refers to the use of SnapMirror with the same (unified) logical replication engine as
in NetApp SnapVault® technology. This unified relationship type is designated Extended Data Protection (XDP)
and provides single baseline functionality at the volume level, drastically reducing storage and network bandwidth,
which translates immediately into cost savings. SnapMirror provides support for applications to fail over to a
secondary volume and continue operating as well as the capability to fail back to the primary location at a later
date. This capability is sometimes referred to as disaster recovery (DR) or mirroring. SnapVault provides support
for long-term retention of data for compliance, backup, archival, and other reasons. This support is sometimes

referred to as vaulting or backup. SnapMirror Unified Replication brings together the powerful capabilities of both
at the volume level.
There are four major benefits to using SnapMirror Unified Replication:
• Only one baseline copy of a volume is needed on the secondary storage (without Unified Replication,
SnapMirror and SnapVault each need their own baseline copy).
• Less network traffic is required between the primary and secondary (a single baseline plus fewer
snapshots over time).
• There is simplified upgrading of replication relationships to newer ONTAP releases. (Without Unified
Replication you can replicate only from higher to lower releases. Doing so can cause serious
operational issues with complex replication topologies. With Unified Replication you can replicate from
lower to higher AND from higher to lower as long as both sides are ONTAP 8.3 or higher.)
• If a primary volume that is the source of a SnapMirror relationship becomes corrupted for any reason,
the secondary inevitably becomes corrupted as well. With Unified Replication, it is now possible to
recover the primary volume from any arbitrary SnapVault or SnapMirror snapshot.
4.3.1 Unified Replication Exercise
This exercise will demonstrate the powerful capabilities of Unified Replication (SnapMirror and SnapVault existing
within the same volume sharing the same baseline). It will demonstrate how you can set labels and retention
times on the individual snapshots in a volume to behave like a vault snapshot or a DR snapshot.
The tasks you will perform are listed below.
Tasks
Create policies for Unified Replication
Create Mirror-Vault relationship
Create Snapshots and perform update
4.3.1.1 Create Policies

Figure 4-36:
System Manager for "cluster1".

3
Figure 4-37:

5. In the dashboard view for “cluster1”, click Protection > Protection Policies on the left menu.
System Manager now displays the Protection Policies pane.
6. On the upper left of the Protection Policies listing click Create.
Figure 4-38:

6
7. In the Create Policy dialog box select or enter the following:

Policy Type: Mirror Vault
Policy Name: oracle
Transfer Priority: Normal
8. Still in the dialog box under "Policy Rules" enter the following:
SnapMirror label: oraclevault
Destination Retention Count: 60
Click plus sign next to retention count
SnapMirror label: oracleDR
Destination Retention Count: 14
Click plus sign next to retention count
9. Click Create.

7
9
Figure 4-39:
10. Open a browser session for "cluster2" and repeat the previous steps. The same policy must exist on
both source and destination clusters.
4.3.1.2 Create Relationship

1. In the browser session for “cluster2”, click Protection > Relationships on the left menu.
System Manager now displays the Protection Relationships pane.
2. On the upper left of the Protection Relationships listing click Create

2
Figure 4-40:
3. Select the entry for the SVM named svm_dst1

4. Click Select.

3
Figure 4-41:
The “Browse SVM” window closes, and the “Create Protection Relationship” window opens.
5. In the “Relationship Type” section, set
Relationship Type: Mirror Vault (Unified Replication).
6. In the “Source Volume” section, set
Cluster:cluster1
SVM: snap_src1
Volume: Click Browse and select Unified_Replication_src1.
7. In the “Destination Volume” section, verify
SVM: svm_dst1 - If there were more than one SVM on this cluster, this would be a drop-down
selection box.
Volume Name Suffix: _dest - A custom suffix for the destination volume. For this exercise, leave the
default.
8. In the “Configuration Details” section, set
Mirror and Vault Policy: Click Browse... to select oracle.
Schedule: leave default
9. Scroll down to the bottom of this window and make sure the Initialize Relationship checkbox is
checked. (This checkbox is not shown in the accompanying screenshot, but should be checked by
default.)
10. Click Validate to check the specifications for this relationship.

5
9
7
10
Figure 4-42:
11. Once the validation is complete, click Create to create the relationship.

11
Figure 4-43:
12. In the relationship listing monitor the status of the creation and initialization of the newly created Unified
Replication relationship.
12
Figure 4-44:
4.3.1.3 Create Snapshots and Perform Update

1. Open PuTTY sessions to both "cluster1" and "cluster2" (if you don't already have open PuTTY sessions
to them), logging in to each as the user admin with the password Netapp1!.

1
Figure 4-45:
2. On "cluster1" create some snaphots to transfer during the next SnapMirror update.
Note: The -snapmirror-label option specifies a label that is used by the Vaulting subsystem
when you back up Snapshot copies to the Vault Destination. The -expiry-time option indicates
the time at which the Snapshot copy becomes eligible for deletion.
cluster1::> snapshot create -vserver snap_src1 -volume Unified_Replication_src1

-snapshot oraclevault -snapmirror-label oraclevault
cluster1::> snapshot create -vserver snap_src1 -volume Unified_Replication_src1

-snapshot oracleDR -snapmirror-label oracleDR
cluster1::> snapshot show -vserver snap_src1 -volume Unified_Replication_src1

---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
snap_src1
unified_rep_src1
snapshot_12082016_142038_98 128KB 0% 26%
weekly.2016-08-14_0015 520KB 1% 59%
weekly.2016-08-21_0015 176KB 0% 32%
snapmirror.f37fb61f-5433-11e6-9502-005056010cf1_2152686027.2016-08-25_191500
76KB 0% 17%
daily.2016-08-26_0010 500KB 1% 58%
daily.2016-09-21_0010 624KB 1% 63%
hourly.2016-09-21_1305 72KB 0% 16%
hourly.2016-09-21_1405 72KB 0% 16%
hourly.2016-09-21_1505 72KB 0% 16%
hourly.2016-09-21_1605 680KB 1% 65%
hourly.2016-09-21_1705 72KB 0% 16%
hourly.2016-09-21_1805 68KB 0% 16%
68KB 0% 16%
oraclevault 68KB 0% 16%
oracleDR 64KB 0% 15%
15 entries were displayed.
3. On "cluster2", update the destination volume with the new snapshots you just created on the source
volume.
cluster2::> snapmirror update -destination-path svm_dst1:Unified_Replication_src1_dest

Operation is queued: snapmirror update of destination
"svm_dst1:Unified_Replication_src1_dest".
4. Verify that all the snapmirror relationships are all idle, indicating the snapmirror update operation is
complete.
cluster2::> snapmirror show

Progress
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
snap_src1:cascade_src1
DP svm_dst1:cascade_dst1
Snapmirrored
Idle - true -

snap_src1:mirror_me
XDP svm_dst1:snap_src1_mirror_me_mirror
Snapmirrored
Idle - true -
snap_src1:snapvault_src1
XDP svm_dst1:snapvault_dst1
Snapmirrored
Idle - true -
snap_src1:unified_rep_src1
XDP svm_dst1:unified_rep_dst1
Snapmirrored
Idle - true -
5. On "cluster2" view the local snapshots.
cluster2::> snapshot show -volume Unified_Replication_src1_dest

---Blocks---
Vserver Volume Snapshot Size Total% Used%

-------- -------- ------------------------------------- -------- ------ -----
svm_dst1 unified_rep_dst1
108KB 0% 23%
oraclevault 108KB 0% 23%
oracleDR 108KB 0% 23%
64KB 0% 15%
Here you see the snapshots you created at the beginning of this exercise, one as a DR type snapshot
and the other as a backup (i.e. vault) type snapshot by virtue of their different labels and retention
periods. This is significant because snapshots both reside within the same volume. Prior to ONTAP 8.3
this would have required two separate volumes and two separate baselines as it was not possible to mix
the two.
In this activity, you have created a protection relationship between two volumes that combines both a mirror and
a vault relationship (Unified Replication) that reduces network bandwidth and necessary capacity by sharing a
baseline initialization.
4.4 Failover/Failback Overview

In the event of a disaster scenario you can convert SnapMirror destination volumes to active primaries hosting
your business critical applications. Then once the DR event passes and the primary site is available, you can
easily revert your operations back to their original sources with minimal data transfer, and no loss of data. You
can initiate such a failover at will, so disaster scenarios can be planned and tested anytime.
The following sequences illustrate how to implement a failover scenario, and assumes that you already have an
initialized SnapMirror relationship in place for the volumes in question.
1. Normal Operation

Figure 4-46:
2. After the primary volume becomes unavailable, a SnapMirror break operation is performed to fail over
each volume. In the ONTAP operating system, wildcards can be used to perform a SnapMirror operation
on multiple volumes with one command.
Note: If the volumes have been mounted in the namespace, and CIFS shares and NFS export
policies created and applied, clients then have read-write access to the NAS data.
Figure 4-47:
3. Once the volume becomes available again, any changes that occurred during the failover can be
replicated back to the original source volume.
Figure 4-48:
Note: It is important to remember that once the resynchronization is complete, the volume on cluster 2
is still the "source" volume now. Steps 1 and 2 would have to be repeated to return the relationship to its
original state.

4.4.1 Failover/Failback Exercise
In this exercise you will use OnCommand System Manager to make an existing SnapMirror destination volume
writeable, and then reverse the relationship so that the original source volume now mirrors the contents of the
original destination volume.
The tasks you will perform are listed below:
Tasks
Break a SnapMirror relationship
Set up data for testing
Create a snapshot
Reverse resynchronize relationship
Verify results of reverse resync
4.4.1.1 Break a SnapMirror Relationship

Figure 4-49:
2. Use the cluster2 System Manager button on the browser's bookmark bar to launch and System
Manager for cluster2.

3
Figure 4-50:


5
Figure 4-51:

6. In the “Relationships” pane, select the relationship for the source volume snapmirror_src1. You may
need to expand the column headers if the source volume name is partially obscured.
7. In the lower pane, select the Details tab so you can see the status details for the selected SnapMirror
relationship.
8. Back in the “Relationships” pane, verify that the snapmirror_src1 relationship is still selected, and then
click Operations > Break from the menu.

6 8
Figure 4-52:
The “Break” window opens.

9. Check the OK to break the selected relationship checkbox.
10. Click the Break button.
9
10
Figure 4-53:
The “Break” window remains open while System Manager processes the break operation, then
automatically closes when finished, and focus returns to the “Relationships” view in System Manager.
11. Notice in the “Details” section that the relationship state has changed to “Broken Off”, which indicates
that the destination volume no longer accepts updates from the source volume, and also that the
destination volume is now writeable.
12. The “Is Healthy” field may also have gone from green to red indicating that the relationship is not
healthy. You may need to hit the Refresh button a few times (wait 5-10 seconds between presses)
before this change becomes visible.

Attention: It can sometimes take several minutes for the “Is Healthy” indicator to go red, even
with refreshes, so feel free to continue with the exercise if your indicator is still green, so long as
the relationship state displays “Broken Off”.
12
11
Figure 4-54:
4.4.1.2 Set Up Data for Testing

Now you will create a new file on both the source and destination volumes. The files will have different names so
you can see what happens when you reverse and re-sync the SnapMirror relationship later in this procedure.
1. On the desktop of the Jumphost, open Windows Explorer from the taskbar.

1
Figure 4-55:
2. In Windows Explorer, navigate to the J:\snapmirror_src1 folder.

3. Right-click in the folder and select New > Text Document in the context menu.
3
Figure 4-56:
4. Name the file source.txt.

4
Figure 4-57:
5. Now navigate to the K:\snapmirror_src1_dest folder.

6. Right-click in the folder and select New > Text Document in the context menu.
6
Figure 4-58:
7. Name the file destination.txt.

7
Figure 4-59:
Next you are going to create a snapshot on the source volume. Don't forget that the mirror has been broken off
so the original destination volume doesn't know about the source.txt file and the original source volume doesn't
know about the destination.txt file.
4.4.1.3 Create a Snapshot

1. Go to System Manager browser tab for cluster1. If necessary, log in with the user name admin, and the
password Netapp1!.
2. On the left menu, click on Storage > Volumes.
3. In the volume list, select the hyperlink for the snapmirror_src1 volume..

3
Figure 4-60:
4. On the upper right of the Volumes pane, navigate to More Actions > Manage Snapshots > Create.
Figure 4-61:
The “Create Snapshot Copy” window opens.

5. Change the “Snapshot Copy Name” to my_snapshot.
6. Click the Create button.

5
6
Figure 4-62:
The “Create Snapshot Copy” window closes, and focus returns to the “Volume:snapmirror_src1” view in
System Manager.
7. Click the Snapshot Copies button in the upper left of the Volumes pane.
Figure 4-63:
8. Locate my_snapshot in the snapshot list to verify it's existence.

8
Figure 4-64:
4.4.1.4 Reverse Resynchronize Relationship

At this point the contents of the source and destination volumes both differ from their states when SnapMirror
last synchronized them together. Now you will re-sync the SnapMirror relationship, but in the reverse direction,
where the contents of the original source volume (currently the destination) are synchronized from the original
destination (currently the source) volume.
1. Go to System Manager browser tab for cluster2. If necessary, log in with the user name admin, and the
password Netapp1!.

2
Figure 4-65:

3. In the “Relationships” pane, select the relationship for the source volume snapmirror_src1.
4. Select Operations > Reverse Resync from the menu bar.

3
Figure 4-66:
The “Reverse Resync” window opens.

5. Check the OK to reverse resync the relationship checkbox.
6. Click the Reverse Resync button.

5
6
Figure 4-67:
The “Reverse Resync” window remains open while System Manager completes the reverse operation,
and then automatically closes when finished, returning you to the “Relationships” pane in System
Manager.
7. Notice that the “snapmirror_src1” source volume is no longer present in the protection relationship list for
cluster2. This is because the relationship roles have been reversed.

7
Figure 4-68:
4.4.1.5 Verify Results of Reverse Resync

1. In Chrome, select the System Manager browser tab for cluster1. Log in again if necessary.
2. On the left menu, navigate to Protection > Relationships.
3. There is now an entry in the “Relationships” pane on cluster1 for the newly reversed relationship. Select
this entry (i.e., the one where the source volume is “snapmirror_dst1”).
4. In the Details tab in the lower pane, and observe that the source location is now
“svm_dst1:snapmirror_dst1”, and the destination location is “snap_src:snapmirror_src1”.

3
2
Figure 4-69:
5. On the left menu, select Storage > Volumes.

6. In the list of volumes, click on the snapmirror_src1 hyperlink.

6
Figure 4-70:
7. On the menu at the top of the pane, click the Snapshot Copies tab.
8. Try to locate the “my_snapshot” snapshot you created earlier in this exercise after breaking off the
original SnapMirror relationship. That snapshot is not present now because when you reversed the
relationship, the source volume reverted to the most recent snapmirror snapshot that both the source
and destination volumes had in common, which is an earlier snapshot than “my_snapshot”. The resync
then replicated any changes on the destination volume that had occured after that common snapshot
back to the source volume.

7
Figure 4-71:
9. Go back to Windows Explorer, select the K: drive (the original destination volume), and navigate to the
snapmirror_src1_dest folder.
10. Observe that the destination.txt file you previously created here is still present.

9
10
Figure 4-72:
11. Still in Windows Explorer, select the J: drive (the original source volume), and then navigate to the
snapmirror_src1 folder.
12. Observe that the source.txt file you previously created here is now gone, and that the destination.txt file
you created on the original destination volume is now present here too.

11
12
Figure 4-73:
The contents of the original source volume now mirror the contents of the original destination volume
when it was updated after the break. If you attempted to write any new files to the original source
volume, you would find that this volume is now read-only.
To make this volume writable again, and once again the “original” source volume in the SnapMirror
relationship, repeat the failover procedure, this time swapping the source and destination clusters,
SVMs, and volumes during the break and reverse re-sync steps. In order to save time, this lab guide
does not walk you through those steps, but you are welcome to do it on your own if you are interested.
In this activity you have take the steps necessary to make a SnapMirror destination available for production
(writable) should the primary site become unavailable. You also resynchronized the relationship in reverse which
is necessary prior to bringing the primary site back online for production.

5 References
The following references were used to help create this lab guide:
• TR-4015-0118 SnapMirror Configuration Best Practices
• ONTAP 9 Data Protection Power Guide

Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact
product and feature versions described in this document are supported for your specific environment.
The NetApp IMT defines the product components and versions that can be used to construct
configurations that are supported by NetApp. Specific results depend on each customer's installation in
accordance with published specifications.
NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any
information or recommendations provided in this publication, or with respect to any results that may be obtained
by the use of the information or observance of any recommendations provided herein. The information in this
document is distributed AS IS, and the use of this information or the implementation of any recommendations or
techniques herein is a customer’s responsibility and depends on the customer’s ability to evaluate and integrate
them into the customer’s operational environment. This document and the information contained herein may be
used solely in connection with the NetApp products discussed in this document.
®
Go further, faster
© 2018NetApp, Inc. All rights reserved. No portions of this document may be reproduced without prior written consent
of NetApp, Inc. Specifications are subject to change without notice. NetApp, the NetApp logo, Data ONTAP®,
ONTAP®, OnCommand®, SANtricity®, FlexPod®, SnapCenter®, and SolidFire® are trademarks or registered
trademarks of NetApp, Inc. in the United States and/or other countries. All other brands or products are trademarks or
registered trademarks of their respective holders and should be treated as such.

SL10498 Hol

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SL10498 Hol

Transféré par

Droits d'auteur :

Formats disponibles

SnapMirror Unified Replication

October 2018 | SL10498 Version 1.3

1.1 Lab Objectives

SnapMirror Unified Replication

Figure 2-1: Virtual Servers and Storage Controllers

Table 1: Table of Systems

Host Name Operating System Role/Function IP Address

SnapMirror Unified Replication

Host Name User ID Password Comments

SnapMirror Unified Replication

SnapMirror Unified Replication

4.1 SnapMirror Overview

4.1.1 View Existing SnapMirror Relationship

SnapMirror Unified Replication

System Manager displays the Dashboard view for cluster2.

SnapMirror Unified Replication

System Manager now displays the Relationships pane.

SnapMirror Unified Replication

SnapMirror Unified Replication

System Manager displays the “Overview” page for svm_dst1.

SnapMirror Unified Replication

SnapMirror Unified Replication

SnapMirror Unified Replication

SnapMirror Unified Replication

The “Configure Volume Snapshot Copies” window opens.

SnapMirror Unified Replication

4.1.2 Create a SnapMirror Relationship

The topology for this portion of the lab is:

SnapMirror Unified Replication

SnapMirror Unified Replication

System Manager displays the Dashboard view for cluster2.

The “Browse SVM” window opens.

SnapMirror Unified Replication

SnapMirror Unified Replication

SnapMirror Unified Replication

4.1.3 Perform a Manual Update

SnapMirror Unified Replication

The “Update” window closes.

SnapMirror Unified Replication

4.2 SnapVault Overview

4.2.1 SnapVault Exercise

SnapMirror Unified Replication

4.2.1.1 View Existing SnapVault Relationship

SnapMirror Unified Replication

System Manager displays the Dashboard view for cluster2.

SnapMirror Unified Replication

The “Edit Relationship” window opens.

SnapMirror Unified Replication

SnapMirror Unified Replication

SnapMirror Unified Replication

SnapMirror Unified Replication

4.3 SnapMirror Unified Replication Overview

SnapMirror Unified Replication

4.3.1 Unified Replication Exercise

4.3.1.1 Create Policies

SnapMirror Unified Replication

System Manager displays the Dashboard view for cluster1.

SnapMirror Unified Replication

7. In the Create Policy dialog box select or enter the following:

SnapMirror Unified Replication

4.3.1.2 Create Relationship

SnapMirror Unified Replication

3. Select the entry for the SVM named svm_dst1