SPL Cdot831upd1 Self Pacedlab

NETAPP UNIVERSITY
Clustered Data ONTAP 8.3.1 Update1:

SnapMirror Storage Virtual Machines
Self-paced Lab
Course ID: STRSW-SPL-CDOT831UPD1
Content Version: 1.0
NetApp University - Do Not Distribute

ATTENTION
The information contained in this course is intended only for training. This course contains information and activities that,
while beneficial for the purposes of training in a closed, non-production environment, can result in downtime or other
severe consequences in a production environment. This course material is not a technical reference and should not,
under any circumstances, be used in production environments. To obtain reference materials, refer to the NetApp product
documentation that is located at http://now.netapp.com/.
COPYRIGHT
© 2015 NetApp, Inc. All rights reserved. Printed in the U.S.A. Specifications subject to change without notice.
No part of this document covered by copyright may be reproduced in any form or by any means—graphic, electronic, or
mechanical, including photocopying, recording, taping, or storage in an electronic retrieval system—without prior written
permission of NetApp, Inc.
U.S. GOVERNMENT RIGHTS

Commercial Computer Software. Government users are subject to the NetApp, Inc. standard license agreement and
applicable provisions of the FAR and its supplements.
TRADEMARK INFORMATION
NetApp, the NetApp logo, Go Further, Faster, ASUP, AutoSupport, Campaign Express, Customer Fitness, CyberSnap,
Data ONTAP, DataFort, FilerView, Fitness, Flash Accel, Flash Cache, Flash Pool, FlashRay, FlexCache, FlexClone,
FlexPod, FlexScale, FlexShare, FlexVol, GetSuccessful, LockVault, Manage ONTAP, Mars, MetroCluster, MultiStore,
OnCommand, ONTAP, ONTAPI, RAID DP, SANtricity, SecureShare, Simplicity, Simulate ONTAP, Snap Creator,
SnapCopy, SnapDrive, SnapIntegrator, SnapLock, SnapManager, SnapMirror, SnapMover, SnapProtect, SnapRestore,
Snapshot, SnapValidator, SnapVault, StorageGRID, Tech OnTap, and WAFL are trademarks or registered trademarks of
NetApp, Inc. in the United States and/or other countries.
Other product and service names might be trademarks of NetApp or other companies. A current list of NetApp trademarks
is available on the Web at http://www.netapp.com/us/legal/netapptmlist.aspx.
E-2 Clustered Data ONTAP 8.3.1 Update1: SnapMirror Storage Virtual Machines
© 2015 NetApp, Inc. This material is intended only for training. Reproduction is not authorized.

CLUSTERED DATA ONTAP 8.3.1 UPDATE 1: SNAPMIRROR STORAGE
VIRTUAL MACHINES
EXERCISES
In the exercises for this course, you explore the new SnapMirror storage virtual machine (SVM) feature. The
exercise uses two clusters: a primary cluster and a disaster-recovery cluster. In the first part of the exercise,
you prepare the SVM for disaster recovery. In the second part, you use SnapMirror SVM to execute disaster-
recovery procedures.
OBJECTIVES
The exercises in this course focus on enabling you to do the following:
 Configure a SnapMirror SVM disaster-recovery relationship that protects SVM-scoped resources
 Verify that changes to source-side elements are replicated to the disaster-recovery cluster
 Practice client failover to the SVM on the disaster-recovery cluster and verify data access
 Recover and resynchronize the source SVM after a disaster
STUDY-AID ICONS
These four icons identify steps and comments to which you should give special attention.
Warning
If you misconfigure a step marked with this label, later steps might not work properly.
Check this step carefully before moving forward.
Attention
Review this step carefully to save time, learn a best practice, or avoid errors.
Information
A comment labeled with this icon provides more information about the topic or procedure.
Knowledge
A comment labeled with this icon provides reference material with more context.
E1-1 Clustered Data ONTAP 8.3.1 Update1: SnapMirror Storage Virtual Machines

EXERCISE ENVIRONMENT
The exercise environment consists of these elements:
 Windows Server 2012 R2 Active Directory
 CentOS 6.5: Linux 1 – used for NFS client access
 CentOS 6.5: Linux 2 – used for NFS client access
 Single-node cluster: siteA
 Single-node cluster: siteB_DR

EXERCISE 0: SYSTEM CHECK
In this exercise, you familiarize yourself with your equipment. If you encounter any issues with your
equipment, notify your instructor immediately or contact NetApp University Support:
http://netappusupport.custhelp.com/app/ask.
OBJECTIVES
This exercise focuses on enabling you to connect to a Data ONTAP cluster and check cluster health.
TASK 1: VERIFY CONNECTIVITY TO YOUR DATA ONTAP CLUSTER

In this task, you familiarize yourself with your assigned equipment and ensure connectivity to the Data
ONTAP system.
NOTE: If you encounter issues with your kit, read the self-help tips. If you cannot quickly resolve the issue,
notify your instructor or contact the NetApp Support team.
STEP ACTION
1. Verify that you see the Start page of your assigned Windows 2012 Server:

STEP ACTION
2. Scroll down and click the Desktop tile:
3. You use the PuTTY application from the Windows desktop to connect to the CLI of
the Data ONTAP cluster and of other remote servers in your environment. PuTTY is
a UI for the Telnet and SSH protocols.
4. On the desktop, double-click the PuTTY shortcut:

STEP ACTION
5. In the PuTTY Configuration dialog box, verify that the SiteA_cluster_mgmt saved session is
listed:
6. Double-click SiteA_cluster_mgmt:

STEP ACTION
7. At the Data ONTAP cluster login prompt, provide the cluster1 credentials:
 login as: admin
 Password: Netapp123
The Data ONTAP cluster CLI prompt and cursor appear:
8. If you are unable to log in to the Data ONTAP cluster, please wait for 5 minutes and
try again. There is some variability in the time for the cluster resources to activate in
the lab environment. If after 5 minutes you cannot log in please contact NetApp
University Support for assistance.
9. List the nodes of the Data ONTAP cluster and verify that the nodes are healthy and eligible (this
exercise uses single-node clusters, so you should see only one node):
cluster show
10. Double-click, log in to, and verify the SiteB_DR_cluster_mgmt saved session in the PuTTY
application (repeat Steps 5–9 for SiteB_DR_cluster_mgmt).
NOTE: The IP address of SiteB_DR_cluster_mgmt is 192.168.0.50.
END OF EXERCISE

EXERCISE 1: SVM DISASTER-RECOVERY PREPARATION
In this exercise, you configure a storage virtual machine (SVM) for disaster recovery. In the exercise
environment, the source and disaster-recovery clusters share a layer 2 network. To preserve the network
configuration used by each client during a failover event, the identity-preserve mode of SnapMirror
SVM is being used. The preserved configuration include elements such as IP addresses, CIFS machine
accounts, LDAP, etc. In this mode, IP addresses are retained by the disaster-recovery cluster during a failover
event and returned to the originating site (source SVM) after recovery and resynchronization.
OBJECTIVES
This exercise focuses on enabling you to do the following:
 Review the configuration details on the source SVM
 Prepare the source and disaster-recovery clusters for the SnapMirror relationship
 Create the disaster-recovery SVM
 Configure a peer relationship between the source and disaster-recovery SVMs to protect SVM-scoped
resources
 Configure and verify an SVM SnapMirror relationship
GRAPHICAL REPRESENTATION
By the end of this exercise, your clusters will be configured as in this diagram:

TASK 1: EXAMINE SOURCE SVM CONFIGURATIONS
In this task you examine the primary SVM configurations.
STEP ACTION
1. NetApp OnCommand System Manager is not a separate application, but a

management solution that is built in to the Data ONTAP 8.3 operating system.
To access the OnCommand System Manager, you open a browser, connect to the
cluster management LIF, and authenticate with the cluster administrator user name and
password.
HOST
SYSTEM NAME IP ADDRESS USER NAME PASSWORD
Data ONTAP cluster
SiteA 192.168.0.40 admin (case sensitive) Netapp123
management LIF
2. From the Windows desktop, access OnCommand System Manager:

a. Open Internet Explorer.
b. In the address bar, enter the management LIF IP address of the SiteA cluster as the URL:
3. Click Continue to this website:
4. Enter the administrator user name and password for siteA, and then click Sign In:

STEP ACTION
5. In the navigation pane on the left, expand Storage Virtual Machines > SiteA > svm_finance >
Storage and select Namespace:
6. Examine the namespace.

There are two volumes (one NFS and one CIFS) mounted in the svm_finance namespace. Note
the export policies.
Note that CIFS does not require an export policy, because it is typically centrally authenticated.
Also note that the separation of NFS and CIFS is not required, but this exercise does so for
simplicity.

STEP ACTION
7. In the navigation pane, expand Storage Virtual Machines > SiteA > svm_finance > Policies
and select Export Policies:
8. Verify that the rules for the finance2 export policy allow connections from all clients:
9. In the navigation pane, expand Storage Virtual Machines > SiteA > svm_finance > Storage
and select Volumes.
10.
Record the total size of the volumes in svm_finance: ______________

STEP ACTION
11. In the navigation pane, expand Storage Virtual Machines > SiteA > svm_finance > Storage
and select Shares:
12. Verify that the finance1 share contains the junction path to finance1_CIFS_volume:
13. On the Windows desktop, click the File Explorer icon:

STEP ACTION
14. In the left pane you can see that the finance1 share is already mapped to the Z:\
drive of the Windows Server that you are connected to:
15. Copy a file named File_500M from the CourseFiles folder to the finance1 share. On the
Windows Server desktop, double-click CourseFiles:

STEP ACTION
16. Right-click File_500M and select Copy:
17. In the left pane, click finance1:

STEP ACTION
18. In the Center pane, right-click anywhere and select Paste.
19. Verify that the file is now in the finance1 share:
Next, you validate that you can write data to the finance2_NFS_volume.
20. Double-click the PuTTY shortcut:

STEP ACTION
21. In the PuTTY Configuration dialog box, double-click the Linux 1 saved session:
22. At the Linux login prompt, provide these credentials:

 login as: root
23. The volume finance2_NFS_volume is pre-mounted, make sure the mount is active:
[root@centos65 mnt]# mount -a
24. Write a file in finance2_NFS_volume:

[root@centos65 ~]# cd /mnt/finance2
[root@centos65 ~]# touch nfs_test_file

STEP ACTION
25. Return to your open System Manager session and examine the Logical Interfaces for the
svm_finance. Expand Cluster > SiteA > Configuration and select Network:
26. In the Network pane, click the Network Interfaces tab and verify that
svm_finance_cifs_nfs_lif1 is listed:
27. The svm_finance_cifs_nfs_lif1 address will also be used on the siteB_DR cluster
during disaster-recovery failover. The address will be used on siteB_DR, because
identity-preserve mode will be used and because both clusters share the same
layer 2 data network. In other words, both the primary and disaster-recovery cluster
have ports in the same VLAN.

SVM DISASTER-RECOVERY PREPARATION
To perform disaster recovery for SnapMirror SVMs, you complete the tasks in this flowchart.
The following tasks prepare the clusters for disaster recovery using SnapMirror SVM. This flow diagram
shows the major steps in this activity. The diagram is color-coded to indicate where the actions occur. Green
steps occur on the primary cluster (siteA). Blue steps occur in the disaster recovery cluster (siteB_DR). Steps
with a pattern of blue and green occur in both clusters.
TASK 2: PREPARE THE CLUSTERS

In this task you verify that the cluster peer relationship is healthy and prepare the disaster-recovery cluster
with the necessary licenses, custom schedules, and free space.
STEP ACTION
1. From the clustershell session on siteB_DR, verify that the primary and disaster-recovery clusters
are peered and that the peer cluster is available:
siteB_DR::> cluster peer show
Peer Cluster Name Cluster Serial Number Availability Authentication
------------------------- --------------------- -------------- --------------
SiteA 1-80-000054 Available ok
2. Cluster node licenses must be identical on both clusters, with the exception of the
FlexArray license.

STEP ACTION
3. From the clustershell session on siteA, verify that the NFS, CIFS, and SnapMirror licenses are
installed on the primary cluster:
siteA::> system license show
Serial Number: 1-80-000054

Owner: SiteA
Package Type Description Expiration
----------------- ------- --------------------- --------------------
Base license Cluster Base License -
Serial Number: 1-81-0000000000000000000000070

Owner: SiteA-01
----------------- ------- --------------------- --------------------
NFS license NFS License -
CIFS license CIFS License -
SnapMirror license SnapMirror License -
4 entries were displayed.
4. From the clustershell session on siteB_DR, verify that the NFS, CIFS, and SnapMirror licenses
are installed on the disaster-recovery cluster:
siteB_DR::> system license show
Serial Number: 1-80-000054

Owner: SiteB_DR
----------------- ------- --------------------- --------------------
Base license Cluster Base License -
Serial Number: 1-81-0000000000000000000000071

Owner: SiteB_DR-01
----------------- ------- --------------------- --------------------
NFS license NFS License -
CIFS license CIFS License -
SnapMirror license SnapMirror License -

STEP ACTION
5. Verify that the primary and disaster-recovery clusters have the same cron schedules:
siteA::> job schedule cron show
Name Description
---------------- -----------------------------------------------------
5min @:00,:05,:10,:15,:20,:25,:30,:35,:40,:45,:50,:55
8hour @2:15,10:15,18:15
daily @0:10
hourly @:05
weekly Sun@0:15
siteB_DR::> job schedule cron show
Name Description
---------------- -----------------------------------------------------
5min @:00,:05,:10,:15,:20,:25,:30,:35,:40,:45,:50,:55
8hour @2:15,10:15,18:15
daily @0:10
hourly @:05
weekly Sun@0:15
6. In determining the space required for the disaster-recovery SVM you need to
account for the space required for the replicated volumes as well as the space
required for the SVM configuration data. The SVM configuration data requires at
least one non-root aggregate with minimum free space of 10 GB.
The best practice for the SVM configuration data is to have at least two non-root aggregates
with a minimum free space of 10 GB each.
7. From the clustershell on siteB_DR, verify that the aggregate can support the size of the volumes
in svm_finance (which you recorded in task 1, step 10) plus 10 GB for configuration data:
siteB_DR::> storage aggregate show
Aggregate Size Available Used% State #Vols Nodes RAID Status

--------- -------- --------- ----- ------- ------ ---------------- -----------
-
aggr0 10.02GB 4.83GB 95% online 1 SiteB-01 raid_dp,
normal
vmdisk_data_2
49.22GB 49.22GB 0% online 0 SiteB-01 raid_dp,
normal

TASK 3: CREATE THE DISASTER-RECOVERY SVM
In this task you create the disaster recovery SVM.
STEP ACTION
1. From the clustershell on siteB_DR, create the disaster-recovery SVM:

siteB_DR::> vserver create –vserver svm_finance_dr –subtype
dp-destination
2. You cannot configure a data-protection SVM from System Manager 8.3.1; you must
user either the CLI or the Workflow Automaton tool.
3. Verify that the SVM was created successfully:

siteB_DR::> vserver show
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
----------- ------- ---------- ---------- ----------- ---------- ----------
SiteB_DR admin - - - - -
SiteB-01 node - - - - -
svm_finance_dr
data dp-destination stopped - -
running
4. The operational status of the SVM is stopped, because it is a disaster-recovery

SVM. The SVM becomes active during failover to the disaster-recovery cluster.
5. Examine the volumes on the cluster:

siteB_DR::> volume show
Vserver Volume Aggregate State Type Size Available
--------- ------------ ------------ ---------- ---- ---------- ----------
SiteB-01 vol0 aggr0 online RW 3.16GB 775.8MB
6. At the time when the disaster-recovery SVM is initially created no corresponding

SVM root volume is created. The SVM root volume is created later, when the
SnapMirror SVM relationship is initialized. The volumes that are created during the
SnapMirror initialization process will be mounted into the disaster-recovery
namespace identically to the source namespace.
7. Note that the SVM root volume is not mirrored. No user data should be stored in the
SVM root volume. Any data stored in the SVM root volume other than junction-
paths is unprotected.

TASK 4: CREATE A PEER RELATIONSHIP BETWEEN THE SVMS
In this task, you create an SVM peer relationship between the primary SVM and the disaster-recovery SVM.
STEP ACTION
1. From the clustershell on siteB_DR, create the peer relationship with the primary SVM:
siteB_DR::> vserver peer create -vserver svm_finance_dr -peer-vserver
svm_finance -applications snapmirror -peer-cluster SiteA
2. From the clustershell on siteA, accept the peer relationship request:

siteA::> vserver peer accept -vserver svm_finance -peer-vserver
svm_finance_dr
3. Verify that the SVMs are peered:

siteA::> vserver peer show
Peer Peer Peering
Vserver Vserver State Applications
----------- ----------- ------------ ------------------
svm_finance svm_finance_dr
peered snapmirror
TASK 5: CONFIGURE AND VERIFY AN SVM SNAPMIRROR RELATIONSHIP

In this task you create a SnapMirror SVM relationship between the disaster-recovery SVM and the primary
SVM. You then initialize the relationship. After the SVM data and configurations have been mirrored, you
verify that the configurations from the primary SVM have been applied to the disaster-recovery SVM.
STEP ACTION
1. From the clustershell on siteB_DR, create the SnapMirror relationship with the primary SVM,:
siteB_DR::> snapmirror create -source-path svm_finance: -destination-
path svm_finance_dr: -type DP -throttle unlimited -policy DPDefault -
schedule hourly -identity-preserve true

STEP ACTION
2. The source and disaster-recovery clusters share the same layer 2 network. To preserve
the network configuration used by each client during a failover event, in step 1, you
used the the identity-preserve mode of SnapMirror SVM. In some use cases for
identity-preserve mode, the administrator may wish to modify some of the
network configuration settings after cutover.
3. For a full list of configuration items that are maintained when the identity-
preserve flag is set to true, refer to the Clustered Data ONTAP 8.3: SVM Disaster
Recovery Preparation Express Guide.
4. Verify that the SnapMirror relationship was created and is in the uninitialized state:
siteB_DR::> snapmirror show
Progress
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
----------- ---- ------------ ------- -------------- -------- ------- -------
svm_finance:
DP svm_finance_dr:
Uninitialized
Idle - true -
5. Initialize the relationship:

siteB_DR::> snapmirror initialize -destination-path svm_finance_dr:
6. Review the progress of the transfer of the SVM SnapMirror and its volumes
siteB_DR::> snapmirror show –expand
Progress
----------- ---- ------------ ------- -------------- -------- ------- -------
svm_finance:
DP svm_finance_dr:
Snapmirrored
Idle - true -
svm_finance:finance1_CIFS_volume
DP svm_finance_dr:finance1_CIFS_volume
Snapmirrored
Idle - true -
svm_finance:finance2_NFS_volume
DP svm_finance_dr:finance2_NFS_volume
Snapmirrored
Idle - true -
NOTE: the SnapMirror transfer can take several minutes, so you might need to issue the
command several times before the state reaches Snapmirrored for all volumes.

STEP ACTION
7. The snapmirror show –expand command shows you the SnapMirror

relationships between SVMs as well as volumes of SVMs, but you can only act
upon the SnapMirror relationship at the SVM level.
8. Examine the name of the Snapshot copy that was created for the SVM SnapMirror transfer:
SiteB_DR::> snapmirror show -vserver svm_finance_dr -fields
newest-snapshot,state
source-path destination-path state newest-snapshot
------------ ---------------- ------------ ----------------------------
--------------------------------------
svm_finance: svm_finance_dr: Snapmirrored vserverdr.2.77e6d085-30a8-
11e5-9aa1-0050560b0e3b.2015-07-23_151001
NOTE: The names of Snapshot copies for a SVM SnapMirror relationship start with
vserverdr.
9. Verify some of the key configuration information of the disaster recovery SVM by using System
Manger. From the Windows desktop, access OnCommand System Manager:
b. In the address bar, enter the management LIF IP address of the SiteB_DR cluster as the
URL:
10. Click Continue to this website:

STEP ACTION
11. Enter the administrator user name and password for siteB_DR, and then click Sign In:
12. In the navigation pane, expand Storage Virtual Machines > SiteB_DR > svm_finance_dr:
NOTE: You cannot view or modify the disaster-recovery SVM from System Manager.
13. From the clustershell on siteB_DR, examine the namespace of svm_finance_dr:

siteB_DR::> volume show -vserver svm_finance_dr -fields junction-path,
policy
vserver volume policy junction-path
-------------- -------------------- ------- ---------------------
svm_finance_dr finance1_CIFS_volume default /finance1_CIFS_volume
svm_finance_dr finance2_NFS_volume finance2
/finance2_NFS_volume
svm_finance_dr svm_finance_root default /
The namespace should match that of the svm_finance SVM on the primary cluster (task 1, step
5).

STEP ACTION
14. Examine the export-policy rules:

siteB_DR::> vserver export-policy rule show -vserver svm_finance_dr
Policy Rule Access Client RO
Vserver Name Index Protocol Match Rule
------------ --------------- ------ -------- --------------------- ---------
svm_finance_dr
default 1 any 0.0.0.0/0 any
svm_finance_dr
finance2 1 any 0.0.0.0/0 any
The export policy and rules should match those of the svm_finance SVM on the primary cluster
(task 1, steps 7 and 8).
15. Examine the shares for svm_finance_dr:

siteB_DR::> vserver cifs share show -vserver svm_finance_dr
Vserver Share Path Properties ACL
-------------- ------------- ----------------- ---------- -----------
svm_finance_dr admin$ / browsable -
svm_finance_dr c$ / oplocks
BUILTIN\Administrators / Full Control
browsable
changenotify
svm_finance_dr finance1 /finance1_CIFS_ oplocks Everyone / Full
Control
volume browsable
changenotify
svm_finance_dr ipc$ / browsable -
The shares should match those of the svm_finance SVM on the primary cluster (task 1, step 12).
16. Examine the data LIF on svm_finance_dr:

siteB_DR::> network interface show -vserver svm_finance_dr
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
svm_finance_dr
svm_finance_cifs_nfs_lif1
up/down 192.168.0.60/24 SiteB_DR-01 e0e true
The data LIF should have the same IP address and net mask as the svm_finance SVM on the
primary cluster (task 1, step 25). Note however that the home port for the LIF may be different
than the home port on the source cluster and may be different than in this guide. This is because
the SnapMirror SVM feature does a best effort at LIF placement and has its own set of rules for
home port selection of the LIF.

STEP ACTION
17. From the disaster-recovery SVM, you cannot access or view the contents of the
shares and volumes, because you are using identity-preserve mode. If you need
to be able to access the data in a read-only capacity while the primary cluster is
actively serving data, you must set identity-preserve mode to false.
END OF EXERCISE

EXERCISE 2: SVM DISASTER RECOVERY
In this exercise, you practice failing over clients to the disaster-recovery cluster. After the clients have been
updated to access the disaster-recovery SVM, you verify data access. You also modify the relationship so that
the disaster-recovery SVM becomes the source and the primary SVM becomes the destination. (A system
might need to use this reverse configuration for a time.) Finally you recover the primary SVM and return to
the original SVM SnapMirror relationship.
OBJECTIVES
 Practice client failover to the SVM in the disaster-recovery cluster and verify data access
 Reverse a SnapMirror relationship
 Recover and resynchronize the source SVM after a disaster
SVM DISASTER RECOVERY

The following tasks relate to disaster recovery using SnapMirror SVM. This flow diagram shows the major
steps involved in this activity. The diagram is color-coded to indicate where the actions occur. Green steps
occur on the primary cluster (siteA). Blue steps occur in the disaster recovery cluster (siteB_DR). Steps with a
pattern of blue and green occur in both clusters.

TASK 1: RECOVER FROM A DISASTER
In this task you recover a system from a disaster on the primary cluster by activating the disaster-recovery
SVM. Activating the disaster-recovery SVM involves quiescing the scheduled SnapMirror transfers and any
ongoing transfers, breaking the SVM disaster-recovery relationship, stopping the primary SVM, starting the
disaster-recovery SVM, and verifying the status of the disaster-recovery SVM.
Imagine that a disaster on the primary cluster causes the failures in this diagram:
STEP ACTION
1. From the clustershell on siteB_DR, quiesce SnapMirror tranfers:

siteB_DR::> snapmirror quiesce -destination-path svm_finance_dr:

STEP ACTION
2. Verify that the SnapMirror was quiesced:

Progress
----------- ---- ------------ ------- -------------- -------- ------- -------
svm_finance:
DP svm_finance_dr:
Snapmirrored
Quiesced - true -
3. You must break the SnapMirror relationship before activating the disaster recovery SVM:
siteB_DR::> snapmirror break -destination-path svm_finance_dr:
4. Verify that the SnapMirror relationship is in the Broken-off state:

Progress
----------- ---- ------------ ------- -------------- -------- ------- -------
svm_finance:
DP svm_finance_dr:
Broken-off
Idle - true -
5. From the clustershell on siteA, stop the source SVM:

siteA::> vserver stop -vserver svm_finance
NOTE: Because this exercise uses the identity-preserve mode for the SnapMirror SVM
relationship and the primary and disaster-recovery SVMs are on the same network subnet, you
must stop the source SVM before you activate the destination SVM.
6. Verify that the SVM stopped:

siteA::> vserver show
----------- ------- ---------- ---------- ----------- ---------- ----------
SiteA admin - - - - -
SiteA-01 node - - - - -
svm_finance data default stopped stopped svm_ vmdisk_
finance_ data_1
root
7. From the clustershell on siteB_DR, active the disaster-recovery SVM:

siteB_DR::> vserver start -vserver svm_finance_dr

STEP ACTION
8. Verify that the SVM started:

----------- ------- ---------- ---------- ----------- ---------- ----------
SiteB-01 node - - - - -
svm_finance_dr
data default running running svm_ vmdisk_
finance_ data_2
root
9. Because the same subnet is being used, no LIFs need to be updated. As soon as the
SVM is activated, the client can access the CIFS share. You verify client access in the
following steps.
10. Copy a file named File_750M from the CourseFiles folder to the finance1 share. (Refer to
exercise 1, task 1, Steps 14–19 for reference.)
11. NFS clients require an unmount and remount to access the volumes from the
disaster-recovery SVM.
12. From the Linux1 shell, move to the top level mount directory and unmount the NFS volume:
[root@centos65 mnt]# cd /mnt
[root@centos65 mnt]# umount -f 192.168.0.60:/finance2_NFS_volume
13. Now remount the NFS volume:

[root@centos65 mnt]# mount 192.168.0.60:/finance2_NFS_volume
/mnt/finance2
14. Verify that you can write to the finance2_NFS_volume:

[root@centos65 finance2]# touch /mnt/finance2/nfs_test_file2
[root@centos65 finance2]# ls /mnt/finance2

TASK 2: REVERSE THE SNAPMIRROR RELATIONSHIP
In this task, you reverse the SnapMirror relationship so that the disaster-recovery SVM becomes the source.
For these activities assume that the source SVM is recoverable. This diagram depicts the new SnapMirror
relationship:
STEP ACTION
1. Verify that the cluster peer relationship is healthy:

siteA::> cluster peer show
Peer Cluster Name Cluster Serial Number Availability Authentication
------------------- --------------------- -------------- --------------
SiteB_DR 1-80-000054 Available ok

STEP ACTION
2. On a live production system you would need to verify all of the items that you did
when you first created the SnapMirror SVM relationship. For example, on the
primary cluster you must verify the existence of all required feature licenses and
protocols, of any required custom schedules, and of a non-root aggregate with
minimum free space of 10 GB.
3. Verify that the SVMs are still peered:

SiteA::> vserver peer show
Peer Peer Peering
Vserver Vserver State Applications
----------- ----------- ------------ ------------------
svm_finance svm_finance_dr
peered snapmirror
4. Create a reverse SnapMirror relationship so that the primary SVM becomes the destination and
the disaster-recovery SVM becomes the source:
siteA::> snapmirror create -source-path svm_finance_dr: -
destination-path svm_finance: -type DP -throttle unlimited -policy
DPDefault -schedule hourly -identity-preserve true
5. Verify that the SnapMirror relationship was created. Note that the state is Broken-off.
siteA::> snapmirror show
Progress
----------- ---- ------------ ------- -------------- -------- ------- --------
svm_finance_dr:
DP svm_finance: Broken-off
Idle - true -
6. Resynchronize all changes (configuration and data) that have occurred on the disaster-recovery
SVM since it became the active SVM:
siteA::> snapmirror resync svm_finance:
7. Verify that the SnapMirror resynchronization has completed:

Progress
----------- ---- ------------ ------- -------------- -------- ------- --------
svm_finance_dr:
DP svm_finance: Snapmirrored
Idle - true -
NOTE: You might need to enter this command several times for the state to reach the final
Snapmirrored state. Before reaching the Snapmirrored state, the resynchronization is in the
Transferring state.

TASK 3: RECOVER THE PRIMARY SVM
In this task you activate the Primary SVM. To activate the primary SVM you must stop the disaster-recovery
SVM and perform a final SnapMirror update to get any changes since the most recent transfer. You then
reestablish the original SnapMirror SVM relationship and start the primary SVM.
This diagram depicts the return of the original SnapMirror relationship:
STEP ACTION
1. The system might need to operate in the reverse relationship for a period of time
before switching back to the original configuration (in which the primary SVM again
is the active SVM for the clients). You must plan this activity, because there is a
short client outage during switchback. Also note that during this time an
administrator may apply SVM configuration changes based upon new business requirements.

STEP ACTION
2. A normal system administration change might be an update to the security of the system. To
simulate such a change, lock down NFS client access to allow only the client IP address for
Linux 2 to access the finance2 NFS volume:
SiteB_DR::> vserver export-policy rule modify -vserver svm_finance_dr -
policyname finance2 -ruleindex 1 -clientmatch 192.168.0.22
3. Verify that you can no longer write to the finance2 folder using the Linux 1 client:
[root@centos65 finance2]# cd /mnt/finance2
-bash: cd: /mnt/finance2: Permission denied
4. In the PuTTY Configuration dialog box, double-click the Linux 2 saved session:
5. At the Linux login prompt, provide these credentials:

 login as: root
6. Verify that you can access and write to the finance2_NFS_volume using the Linux 2 client:
[root@centos65 ~]# mkdir /mnt/finance2
[root@centos65 ~]# mount 192.168.0.60:/finance2_NFS_volume
/mnt/finance2
[root@centos65 finance2]# touch /mnt/finance2/test_new_security_file
[root@centos65 finance2]# ls /mnt/finance2
nfs_test_file nfs_test_file2 test_new_security_file

STEP ACTION
7. Now you will switch the primary and disaster-recovery SVM back to their original
configuration, in which the primary SVM is the active SVM. From the clustershell on siteB_DR,
stop the disaster-recovery SVM:
siteB_DR::> vserver stop -vserver svm_finance_dr
8. Verify that the vserver stopped:

----------- ------- ---------- ---------- ----------- ---------- ----------
SiteB-01 node - - - - -
svm_finance_dr
data default stopped stopped svm_ vmdisk_
finance_ data_1
root
9. From the clustershell of siteA, make one last update to transfer all of the most recent data
changes and configuration changes to the primary SVM:
siteA::> snapmirror update –destination-path svm_finance:
10. Verify that the SnapMirror update has completed:

Progress
----------- ---- ------------ ------- -------------- -------- ------- --------
svm_finance_dr:
DP svm_finance: Snapmirrored
Idle - true -
Transferring state.
11. Break the SnapMirror relationship:

siteA::> snapmirror break -destination-path svm_finance:
12. Verify that the SnapMirror relationship is in the Broken-off state:

Progress
----------- ---- ------------ ------- -------------- -------- ------- -------
svm_finance_dr:
DP svm_finance:
Broken-off
Idle - true -
13. In order to restore the original relationship, delete the SnapMirror relationship:
siteA::> snapmirror delete -destination-path svm_finance:

STEP ACTION
14. Verify that the SnapMirror relationship was removed:

This table is currently empty.
15. Restart the primary SVM:

siteA::> vserver start –vserver svm_finance
16. In File Explorer, verify that you can access the finance1 share that is mapped to the Z:\ drive.
17. Verify the export policies that were changed while the disaster-recovery SVM was active are
visible in the primary SVM configuration (repeat task 1, steps 7 and 8).
18. Verify that the original SnapMirror relationship exists and is in the Broken-off state.
Progress
----------- ---- ------------ ------- -------------- -------- ------- -------
svm_finance:
DP svm_finance_dr:
Broken-off
Idle - true -
19. Resynchronize the SnapMirror relationship:

siteB_DR::> snapmirror resync -destination-path svm_finance_dr:
20. Verify that the SnapMirror resynchronization has completed:

Progress
----------- ---- ------------ ------- -------------- -------- ------- --------
svm_finance:
DP svm_finance_dr:
Snapmirrored
Idle - true -
Transferring state.

STEP ACTION
21. Summary: The table below summarizes the major steps and commands used in these
exercises.
Steps Commands
You configured a SnapMirror SVM disaster- DR: vserver create
recovery relationship that protected SVM-scoped
resources. DR/Primary: vserver peer
create/accept
DR: snapmirror create
You failed over clients to the SVM disaster- DR: snapmirror update
recovery cluster. In order for the disaster-recovery
SVM to become the active SVM you had to break DR: snapmirror quiesce
the SnapMirror relationship. DR: snapmirror break
Primary: vserver stop
DR: vserver start
You reversed the SnapMirror relationship so that Primary: snapmirror create
the Primary cluster became the destination of the
SnapMirror relationship. You resynched so that Primary: snapmirror resync
the Primary cluster contained all the data including
data that may have changed after the disaster-
recovery SVM became the active SVM.
You recovered the original SVM on the primary Primary: snapmirror break
cluster. To do this you stopped the disaster-
recovery SVM and broke the reverse SnapMirror DR: vserver stop
relationship so that the primary SVM could Primary: vserver start
become the active SVM again.
You re-activated the original SnapMirror SVM DR: snapmirror resync
relationship.
END OF EXERCISE

(OPTIONAL) EXERCISE 3: WORKFLOW AUTOMATION
In this exercise, you import the Storage Virtual Machine Disaster Recovery pack into the Workflow
Automation (WFA) tool and execute the Initialize or Updated Storage Virtual Machine SnapMirror workflow.
OBJECTIVES
 Import a WFA workflow pack
 Execute a storage virtual machine (SVM) disaster-recovery workflow
TASK 1: IMPORT A WFA WORKFLOW PACK

In this task you import the Storage Virtual Machine Disaster Recovery workflow pack.
STEP ACTION
1. From the Windows desktop, access WFA:

b. In the address bar, enter https://192.168.0.11/wfa
2. Click Continue to this website.
3. Enter the following credentials and click Sign In:

 Username: admin

STEP ACTION
4. In the toolbar, click the Storage Automation Store tab:
5. Scroll down in the Available Packs pane and click the Storage Virtual Machine Disaster
Recovery row:
6. At the bottom right of the pane, click Download Pack:

STEP ACTION
7. You are redirected to the webpage https://automationstore.netapp.com/pack-list.shtml. Enter

your login credentials for the store (for internal NetApp learners, these are your SSO
credentials):
8. Verify that you see the Storage Automation Store webpage:

STEP ACTION
9. Scroll down the page and at the Storage Virtual Machine Disaster Recovery row, click
Download Pack:
10. On the Terms and Conditions page, click Accept.
11. At the bottom of the page, enter the captcha and click Submit Query:
12. Click download:

STEP ACTION
13. When asked to open or save SVMDR_PACK_SIGN.dar, click Save:
14. When the download completes, click Open Folder.
15. Verify that the Downloads folder opens:
16. In Internet Explorer, return to the WFA tab and select Administration > Import:

STEP ACTION
17. Select This PC > Downloads > SVMDR_PACK_SIGN.dar and click Open:
18. When the Import Dar File dialog box appears, click Import:

STEP ACTION
19. When the Import Success dialog box appears, click OK:
20. Click the Portal tab and select Data Protection:
21. Review the Storage Virtual Machine Disaster Recovery workflows that were added:

STEP ACTION
22. Examine the details of these workflows by clicking the information (“i”) button for each one:
Note that on the first item a pop-up blocker will appear, click Allow. A new tab will open for
each item, return to the WFA tab to access the information button for the next workflow.

TASK 2: EXECUTE A DISASTER-RECOVERY WORKFLOW
In this task you execute the Initialize or Updates Storage Virtual Machine SnapMirror workflow.
STEP ACTION
1. Click the Initialize or Update Storage Virtual Machine SnapMirror workflow.

STEP ACTION
2. Specify these values:

 Destination Cluster: SiteB_DR
 Destination SVM: svm_finance_dr
 Source Cluster: SiteA
 Source SVM: svm_finance
 SnapMirror Operation: Update
 Options: Execute now
3. Click Execute.

STEP ACTION
4. Verify that workflow execution starts:
5. Verify that workflow execution completes successfully.
END OF EXERCISE

SPL Cdot831upd1 Self Pacedlab

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SPL Cdot831upd1 Self Pacedlab

Încărcat de

Drepturi de autor:

Formate disponibile

NETAPP UNIVERSITY

Clustered Data ONTAP 8.3.1 Update1:

NetApp University - Do Not Distribute

U.S. GOVERNMENT RIGHTS

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

TASK 1: VERIFY CONNECTIVITY TO YOUR DATA ONTAP CLUSTER

NetApp University - Do Not Distribute

2. Scroll down and click the Desktop tile:

4. On the desktop, double-click the PuTTY shortcut:

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

1. NetApp OnCommand System Manager is not a separate application, but a

2. From the Windows desktop, access OnCommand System Manager:

3. Click Continue to this website:

NetApp University - Do Not Distribute

6. Examine the namespace.

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

13. On the Windows desktop, click the File Explorer icon:

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

16. Right-click File_500M and select Copy:

17. In the left pane, click finance1:

NetApp University - Do Not Distribute

18. In the Center pane, right-click anywhere and select Paste.

19. Verify that the file is now in the finance1 share:

20. Double-click the PuTTY shortcut:

NetApp University - Do Not Distribute

22. At the Linux login prompt, provide these credentials:

24. Write a file in finance2_NFS_volume:

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

TASK 2: PREPARE THE CLUSTERS

NetApp University - Do Not Distribute

Serial Number: 1-80-000054

Serial Number: 1-81-0000000000000000000000070

Serial Number: 1-80-000054

Serial Number: 1-81-0000000000000000000000071

NetApp University - Do Not Distribute

siteB_DR::> job schedule cron show

Aggregate Size Available Used% State #Vols Nodes RAID Status

NetApp University - Do Not Distribute

1. From the clustershell on siteB_DR, create the disaster-recovery SVM:

3. Verify that the SVM was created successfully:

4. The operational status of the SVM is stopped, because it is a disaster-recovery

5. Examine the volumes on the cluster:

6. At the time when the disaster-recovery SVM is initially created no corresponding

NetApp University - Do Not Distribute

2. From the clustershell on siteA, accept the peer relationship request:

3. Verify that the SVMs are peered:

TASK 5: CONFIGURE AND VERIFY AN SVM SNAPMIRROR RELATIONSHIP

NetApp University - Do Not Distribute

5. Initialize the relationship:

NetApp University - Do Not Distribute

7. The snapmirror show –expand command shows you the SnapMirror

10. Click Continue to this website:

NetApp University - Do Not Distribute

13. From the clustershell on siteB_DR, examine the namespace of svm_finance_dr:

NetApp University - Do Not Distribute