clustered data ontap 8.3.1 update 1, snapmirror ... - netapp · pdf filenetapp university ....

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

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.

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.


http://www.netapp.com/us/legal/netapptmlist.aspx

E1-1 Clustered Data ONTAP 8.3.1 Update1: SnapMirror Storage Virtual Machines


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.




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:


http://netappusupport.custhelp.com/app/ask



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.

SYSTEM HOST NAME IP ADDRESS USER NAME PASSWORD

Data ONTAP cluster

management LIF SiteA 192.168.0.40 admin (case sensitive) Netapp123

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

Password: Netapp123

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:

a. Open Internet Explorer. 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 Source Destination Mirror Relationship Total Last


----------- ---- ------------ ------- -------------- -------- ------- -------

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:




----------- ---- ------------ ------- -------------- -------- ------- -------

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

Password: Netapp123

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:




----------- ---- ------------ ------- -------------- -------- ------- -------

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.




----------- ---- ------------ ------- -------------- -------- ------- -------

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-

recovery relationship that protected SVM-scoped

resources.

DR: vserver create

DR/Primary: vserver peer create/accept

DR: snapmirror create

You failed over clients to the SVM disaster-

recovery cluster. In order for the disaster-recovery

SVM to become the active SVM you had to break

the SnapMirror relationship.

DR: snapmirror update

DR: snapmirror quiesce

DR: snapmirror break

Primary: vserver stop

DR: vserver start

You reversed the SnapMirror relationship so that

the Primary cluster became the destination of the

SnapMirror relationship. You resynched so that

the Primary cluster contained all the data including

data that may have changed after the disaster-

recovery SVM became the active SVM.

Primary: snapmirror create

Primary: snapmirror resync

You recovered the original SVM on the primary

cluster. To do this you stopped the disaster-

recovery SVM and broke the reverse SnapMirror

relationship so that the primary SVM could

become the active SVM again.

Primary: snapmirror break

DR: vserver stop

Primary: vserver start

You re-activated the original SnapMirror SVM

relationship. DR: snapmirror resync

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:

a. Open Internet Explorer. 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

Password: Netapp123


https://192.168.0.11/wfa



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:


https://automationstore.netapp.com/pack-list.shtml



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


clustered data ontap 8.3.1 update 1, snapmirror ... - netapp · pdf filenetapp university ....

Documents