ONTAP Administration: What's New in ONTAP 9 - NetApp · PDF fileNETAPP UNIVERSITY ONTAP Administration: What’s New in ONTAP 9.0 Exercise Guide Course ID: STRSW-ILT-ADMIN90 (STRSW-SPL-ADM9LAB)

Exercise Guide

ONTAP Administration: What's New in ONTAP 9.0

NETAPP UNIVERSITY

ONTAP Administration: What’s New in ONTAP 9.0 Exercise Guide Course ID: STRSW-ILT-ADMIN90 (STRSW-SPL-ADM9LAB) Catalog Number: STRSW-ILT-ADMIN90-EG Content Version: 1.0

NetApp University - Do Not Distribute

E-2 ONTAP Administration: What’s New in ONTAP 9.0: Welcome

© 2016 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

© 2016 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

E-3 ONTAP Administration: What’s New in ONTAP 9.0: Welcome


TABLE OF CONTENTS

WELCOME..................................................................................................................................................... E-1

MODULE 1: ONTAP 9 SOFTWARE ........................................................................................................... E1-1

MODULE 2: MANAGEMENT SOFTWARE ENHANCEMENTS ................................................................. E2-1

MODULE 3: UNIFIED STORAGE ENHANCEMENTS ............................................................................... E3-1

MODULE 4: ALL FLASH FAS ENHANCEMENTS .................................................................................... E4-1

MODULE 5: DATA AVAILABILITY AND PROTECTION ENHANCEMENTS ........................................... E5-1

APPENDIX A: ANSWERS ..........................................................................................................................EA-1


E1-1 ONTAP Administration: What’s New in ONTAP 9.0: ONTAP 9 Software


MODULE 1: ONTAP 9 SOFTWARE

STUDY-AID ICONS

These four icons might be used throughout your exercises to identify steps that require your 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 1: VERIFY EXERCISE ENVIRONMENT

In this exercise, you familiarize yourself with your equipment, synchronize system time, assign a Network

Time Protocol (NTP) time server, and ensure that licenses have been installed.

OBJECTIVES

This exercise focuses on enabling you to do the following:

Ensure connectivity to both ONTAP clusters. Synchronize system time between the ONTAP clusters and the Windows domain controller. Assign a network time server IP address for the ONTAP clusters. Ensure that required licenses are installed on the ONTAP clusters.

EXERCISE EQUIPMENT DIAGRAM

Your lab contains the following virtual machines (VMs):

One Windows 2012 R2 Server system

Two CentOS Linux 6.5 Server systems

One ONTAP 9 2-node cluster (cluster1)

One ONTAP 9 single-node cluster (cluster2)

To connect to the Windows Server jump-host, use the connection information that was assigned to you by

your instructor. From this Windows desktop, you connect to the other servers in your exercise environment.




Machine Host Name IP Addresses User Name Password

Windows 2012 R2 Server jump

host w2k12 192.168.0.11 LEARN\Administrator Netapp123

CentOS Linux 6.5 Server linux1 192.168.0.21 root (case sensitive) Netapp123


ONTAP cluster management

LIF (cluster1) cluster1 192.168.0.50 admin (case sensitive) Netapp123

node1 (cluster1) cluster1-01 192.168.0.51 admin (case sensitive) Netapp123








TASK 1: ENSURE CONNECTIVITY TO YOUR ONTAP CLUSTERS

In this task, you familiarize yourself with the Windows Server desktop. You ensure connectivity to the

ONTAP clusters and verify the health of the ONTAP clusters.

STEP ACTION

1. On your local Windows desktop, click the Remote Desktop Connection link.

2. In the Remote Desktop Connection dialog box, enter the IP address of your remote machine, and

then click Connect.

You should see the desktop of the remote machine.

3. On your Windows Server, minimize the Windows Server Manager Dashboard (if it is open), and

then click the Desktop tile.

4. To connect to the ONTAP cluster UI, browse to the NetApp OnCommand System

Manager URL which is built in to ONTAP 9. (NetApp OnCommand System Manager

will be introduced in task 3 of this exercise).

To connect to the CLI of the ONTAP cluster, you use PuTTY. PuTTY is a UI for the Telnet and

Secure Shell (SSH) protocols.

5. On the desktop, double-click the putty icon.

6. You can connect to the ONTAP cluster1 cluster through the cluster1_mgmt cluster

management LIF. You can also connect through cluster1-01_mgmt and cluster1-

02_mgmt node management LIFs.




STEP ACTION

7. In the PuTTY Configuration dialog box, double-click cluster1_mgmt:

8. The first time you connect, you may receive a PuTTY Security Alert. Click Yes.




STEP ACTION

9. At the ONTAP cluster login prompt, provide the cluster1 credentials:

login as: admin

Password: Netapp123

The ONTAP cluster CLI prompt and cursor appear.

10. If you have any difficulty logging in to the ONTAP cluster CLI, refer to this table.

Ensure that you are using the correct username and password in the correct case (both

are case-sensitive).

SYSTEM HOST NAME IP ADDRESS USER NAME PASSWORD

ONTAP cluster

management LIF cluster1 192.168.0.50 admin (case sensitive) Netapp123

11. Enter the following command to list the nodes of the ONTAP cluster and verify that the nodes are

healthy and eligible (this exercise uses both a 2-node and single-node cluster, so you should see

two nodes for cluster1 and one node when this step is repeated for cluster2):

cluster1::> cluster show

Sample output:

Node Health Eligibility

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

cluster1-01 true true

cluster1-02 true true

2 entries were displayed.

12. Enter the following command to list the version of ONTAP running on each node:

cluster1::> version -node *

Sample output:

cluster1-01:

NetApp Release 9.0X23: Wed Jun 01 06:15:36 UTC 2016

cluster1-02:

NetApp Release 9.0X23: Wed Jun 01 06:15:36 UTC 2016





STEP ACTION

13. Repeat steps 5 through 12 for cluster2_mgmt.




TASK 2: SYNCHRONIZE SYSTEM TIME FOR WINDOWS DOMAINS

In this task, you manually synchronize the time zone, system date, and time on the Windows Server to the

system date and time in the ONTAP cluster.

STEP ACTION

1. Windows domains must be synchronized to within 5 minutes of all member servers.

If the time of the ONTAP cluster is not synchronized with a domain controller, then the

ONTAP cluster cannot join or remain joined to the Windows domain.

Without synchronization, computers in the Windows domain cannot access resources in the

ONTAP cluster, and resources in the cluster cannot access the Windows domain.

In the next steps, you synchronize date, time, and time zone between the ONTAP clusters and the

Windows domain controller.

2. Verify the date, time, and time zone on the Windows Server desktop by clicking the time and date

display in the lower-right corner of the desktop window:

3. To verify the date, time, and time zone click Change date and time settings:




STEP ACTION

4. Review the date, time, and time zone on the Windows Server:

5. In the following steps, you determine what time zone has been configured on your

ONTAP cluster and then, if necessary, you change the cluster time zone to US/Pacific.

Etc/UTC Time Zone

Coordinated Universal Time (UTC) is the primary time standard by which the world regulates

clocks and time. UTC is one of several replacements for Greenwich Mean Time (GMT).

The zone info database, which is a collaborative compilation of time zone information, has a

special area called “Etc.” The Etc area is for administrative zones, particularly for “Etc/UTC.”

which represents UTC.

6. Time zones can differ across Microsoft Windows domains, as long as the date and time

across the time zones are synchronized. However, you might need to configure the time

zone of your ONTAP cluster.

7. Open a PuTTY session to the cluster1 cluster management LIF (cluster1_mgmt), enter the

following command to show the configured time zone:

cluster1::> timezone

Sample output:

Timezone: Etc/UTC




STEP ACTION

8. If the time zone of the ONTAP cluster is different than the time zone of the Windows Server (see

step 4), enter the following case-sensitive command to change the cluster time zone configuration:

cluster1::> timezone US/Pacific

Sample output:

1 entry modified

9. Enter the following command to display the date and time on the ONTAP cluster:

cluster1::> date

Sample output:

Node Date Time zone

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

cluster1-01

Sun Apr 03 07:36:05 2016 US/Pacific

cluster1-02

Sun Apr 03 07:36:04 2016 US/Pacific


10. Compare the date and time on the Windows Server (see step 4) with the date and time in the

ONTAP cluster (see step 9).

11. The date command ensures consistency across nodes by setting the date and time on

all nodes in the ONTAP cluster. The date command has the following format: date

[year][month][day][hour][minute]. Example:

cluster1::> date 201604160600

cluster1::> date

Sample output:

Node Date Time zone

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

cluster2-01

Sat Apr 16 06:00:05 2016 US/Pacific

cluster1-02

Sat Apr 16 06:00:05 2016 US/Pacific


12. If the date and time are more than five minutes apart, enter the following command to change the

date and time on the ONTAP cluster:

cluster1::> date [year][month][day][hour][minute]

13. The date command also accepts the -u parameter to set the date and time in UTC

mode. In UTC mode, the format is -u [<[[[[[cc]yy]mm]dd]hhmm[.ss]]>].

See the ONTAP Commands: Manual Page Reference for more information.

14. Repeat steps 7 through 12 for cluster2.




TASK 3: ASSIGN A NETWORK TIME PROTOCOL (NTP) SERVER TO THE CLUSTERS

In this task, you access the NetApp OnCommand System Manager built-in management program to assign a

network time server (NTP) for cluster1 and cluster2.

STEP ACTION

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

solution (web service) that is built-into the ONTAP operating system.

To access the OnCommand System Manager, you open a browser, connect to the

cluster management LIF, and authenticate with the cluster admin user name and password.


ONTAP cluster


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

a. Open web browser. b. In the address bar, enter the cluster-management logical interface (LIF) IP address

https://192.168.0.50.

3. In previous ONTAP versions, an HTTP request to the cluster-management LIF would

be redirected to HTTPS (example: http://192.168.0.50 would be redirected to

https://192.168.0.50). In ONTAP 9, you need to do an explicit HTTPS request.

4. If there is a problem with the website’s security certificate, click the Continue to this website

link.

5. When the System Manager window opens, enter the following credentials:

User name: admin

Password: Netapp123


https://192.168.0.50/

http://192.168.0.50/

https://192.168.0.50/



STEP ACTION

6. On the command bar, click the Configurations tab.

7. You may need to maximize your browser window to see all of the tabs.

8. In the Configurations pane, click Date and Time.

9. In the Date and Time configuration window, click Edit.

10. In the Edit Date and Time window, enter the IP address (192.168.0.11) of the Windows Server

and click Add.




STEP ACTION

11. Click OK.

12. In the Date and Time configuration window, verify that the Windows Server IP address has been

set as the time server for cluster1.

13. Repeat steps 2 through 12 for cluster2.


ONTAP cluster


14. To avoid issues with the CIFS protocol, always assign one of the domain controllers as

the network time server for ONTAP clusters. The ONTAP cluster NTP service setting

keeps all nodes in the cluster synchronized with Windows domain time.

END OF EXERCISE


E2-1 ONTAP Administration: What’s New in ONTAP 9.0: Management Software Enhancements


MODULE 2: MANAGEMENT SOFTWARE ENHANCEMENTS

EXERCISE 1: COMMAND LINE MANAGEMENT ENHANCEMENTS

In this exercise, you configure a login banner and a message of the day (MOTD) to communicate

administrative information to CLI users of the cluster or a particular storage virtual machine (SVM).

OBJECTIVES


Update the login banner. Modify the message of the day message.


























TASK 1: UPDATE THE LOGIN BANNER

In this task, you configure a login banner to provide additional administrative information to CLI users of

cluster1.

STEP ACTION

1. On the Windows Server desktop, double-click the putty icon.

2. In the PuTTY Configuration dialog box, double-click cluster1_mgmt.


login as: admin

Password: Netapp123


4. Enter the following command to view the current cluster-wide login banner:

cluster1::> security login banner show

Sample output:

The login banner has not been configured for the cluster or any data Vserver.

5. Enter the following case-sensitive command to change the cluster-wide login banner:

cluster1::> security login banner modify -message "Authorized users

ONLY!"

6. Open a second PuTTY session to the cluster1 cluster management LIF (cluster1_mgmt), and

provide the cluster1 credentials:

login as: admin

Password: Netapp123

The new login banner appears.




STEP ACTION

7. Enter the following case-sensitive command to reset the cluster-wide login banner back to the

default:

cluster1::> security login banner modify -message ""




TASK 2: MODIFY THE MESSAGE OF THE DAY MESSAGE

In this task, you modify the message of the day message to provide additional administrative information to

CLI users of cluster2.

STEP ACTION

1. The message of the day (MOTD) provides administrative information after security

credentials are validated. This means that the message can be more informative and

tailored directly to the administrator that has just logged in. The MOTD message can

include:

• Cluster name, node name, or SVM name

• Cluster date and time

• Name of the user logging in

• Last login for the user on any node in the cluster

• Login device name or IP address

• Operating system name

• Software release version

• Effective cluster version string




login as: admin

Password: Netapp123


5. Enter the following command to view the current cluster-wide MOTD:

cluster2::> security login motd show

Sample output:

The message of the day has not been configured for the cluster or any data Vserver.




STEP ACTION

6. Enter the following case-sensitive command to go into interactive mode to change the login

MOTD for the entire cluster2 cluster:

cluster2::> security login motd modify -vserver cluster2

Sample output:

Enter the message of the day for Vserver "cluster2".

Max size: 2048. Enter a blank line to terminate input. Press Ctrl-C to abort.

0 1 2 3 4 5 6 7 8

12345678901234567890123456789012345678901234567890123456789012345678901234567890

7. Enter (or cut and paste) the following case-sensitive text:

###########################################

# Operating System Name = \s #

# Software Release = \r #

# Node = \n #

# Name = \N #

# Active Sessions = \u #

# Current Time = \t #

# Current Date = \d #

###########################################

8. A blank line is required to exit interactive mode.

9. Open a second PuTTY session to the cluster2 cluster management LIF (cluster2_mgmt), and

provide the cluster2 credentials:

login as: admin

Password: Netapp123

The new login MOTD appears.




STEP ACTION

10. Enter the following command to reset the login MOTD back to the default:

cluster2::> security login motd modify -vserver cluster2 -message ""

END OF EXERCISE




EXERCISE 2: ONCOMMAND SYSTEM MANAGER WALKTHROUGH

In this exercise, you explore the new OnCommand System Manager interface.

OBJECTIVES


Navigate OnCommand System Manager. Update OnCommand System Manager administration settings.






















TASK 1: NAVIGATING NETAPP ONCOMMAND SYSTEM MANAGER

In this task, you navigate the new OnCommand System Manager interface.

STEP ACTION



https://192.168.0.50.


User name: admin

Password: Netapp123

3. The new System Manager landing page is the Dashboard. Take a few minutes to review the

information presented on the Dashboard.

4. How many disks are available in the cluster? How many of the available disks are SSDs?

______________________________________________________________________________


https://192.168.0.50/



STEP ACTION

5. Did you click both tabs in the Dashboard view? What information is presented in the Cluster

Performance tab?

______________________________________________________________________________

6. On the command bar, click the Volumes tab.

7. Review the Volumes pane and the general volume information (including tabs) at the bottom of

the pane.

8. Moving from left to right on the command bar, click the LUNs tab.

9. Is there a LUNs tab on the command bar? If not, why?

______________________________________________________________________________

10. On the command bar, click the SVMs tab.




STEP ACTION

11. Review the SVMs pane.

12. In the Name column of the SVMs pane, click on one of the SVMs.

13. Review each of the commands on the SVM command bar.

14. Where can you find the date of the most recent Snapshot copy for volume

finance2_NFS_volume?

______________________________________________________________________________

15. On the command bar, click the Network tab. Review the Network pane.

16. Are any of the network interfaces not on their home port? If so, send the LIF to its home port.

17. On the command bar, click the Hardware and Diagnostics > Aggregates tab.

18. Review the Aggregates pane.




STEP ACTION

19. Review the tabs at the bottom of the screen.

20. On the command bar, explore the contents of the remaining Hardware and Diagnostics tabs.

21. On the command bar, click the Protection > Schedules tab.

22. Review the Schedules pane.

23. On the command bar, explore the contents of the remaining Protection tabs.

24. On the command bar, click the Configurations tab.

25. In the Configurations navigation pane, review the Cluster Settings.




STEP ACTION

26. In the Configurations navigation pane, review the Services.

27. In the Configurations navigation pane, review the Cluster User Details.

28. You can find help on any OnCommand System Manager command by clicking the Help

menu located on the command bar.

29. On the command bar, click Help and review each of the Help menu options.

30. Explore clicking OnCommand System Manager Help from within different locations in System

Manager (example: click the SVMs tab and then click the Help > OnCommand System

Manager Help tab).




TASK 2: UPDATING NETAPP ONCOMMAND SYSTEM MANAGER ADMINISTRATION SETTINGS

In this task, you update OnCommand System Manager administration settings.

STEP ACTION

1. On the command bar, click Administration > Settings.

2. In the setting window, set the Inactivity Timeout to 180.

3. Click OK.

4. On the command bar, click the for the quick navigation menu.

5. On the quick navigation menu, click Add Licenses.

6. In the Add License Packages window, add the iSCSI license

WIXAQBZFXNVOGDAAAAAAAAAAAAAA.

7. Click Add.




STEP ACTION

8. In the Add licenses status window, verify the iSCSI License has a green check.

9. Click Close.

10. On the command bar, verify that the LUNs tab is now available (and the Volumes tab is

removed).

END OF EXERCISE


E3-1 ONTAP Administration: What’s New in ONTAP 9.0: Unified Storage Enhancements


MODULE 3: UNIFIED STORAGE ENHANCEMENTS

EXERCISE 1: MOVING A CIFS SERVER FROM AN ACTIVE DIRECTORY DOMAIN TO A WORKGROUP

In this exercise, you move an existing CIFS server configuration from a Microsoft Windows 2012 R2 Server

Active Directory domain to a Windows workgroup.

OBJECTIVES


Verify a CIFS server configuration and stop the server.

Modify a CIFS server configuration from a domain to a workgroup.

Verify and test the workgroup configuration.

























TASK 1: VERIFY THE CIFS SERVER CONFIGURATION AND STOP THE SERVER

In this task, you verify the CIFS server configuration and administratively down the server using

OnCommand System Manager.

STEP ACTION

1. On the Windows Server machine, open File Explorer and navigate to the M: drive.

2. Create a new text document.

3. Open the text document and verify that the document can be read.




STEP ACTION



https://192.168.0.50.


User name: admin

Password: Netapp123

6. On the command bar, click SVMs.

7. In the SVMs pane, click svm_smb_main.

8. On the SVM svm_smb_main command bar, click SVM Settings.

9. You can still click a different command even if the current pane is still loading.

10. In the SVM Settings navigation pane, click CIFS.


https://192.168.0.50/



STEP ACTION

11. In the CIFS management pane, click Configuration.

12. In the Configuration pane, verify the CIFS server configuration (Authentication Style is Active

Directory and Active Directory Domain Name is LEARN.NETAPP.LOCAL).

13. Click Stop.

14. In the Stop CIFS Server window, select OK to terminate sessions checkbox and click OK.

15. In the Configuration pane, verify that the Service Status is Stopped.




TASK 2: MODIFY THE CIFS SERVER CONFIGURATION FROM A DOMAIN TO A WORKGROUP

In this task, you modify the CIFS server authentication method from a Windows Active Directory domain to a

Windows workgroup.

STEP ACTION




login as: admin

Password: Netapp123


4. Enter the following command to display the CIFS server status:

cluster1::> vserver cifs show -vserver svm_smb_main

Sample output:

Vserver: svm_smb_main

CIFS Server NetBIOS Name: SMB_MAIN

NetBIOS Domain/Workgroup Name: LEARN

Fully Qualified Domain Name: LEARN.NETAPP.LOCAL

Organizational Unit: CN=Computers

Default Site Used by LIFs Without Site Membership:

Workgroup Name: -

Authentication Style: domain

CIFS Server Administrative Status: down

CIFS Server Description:

List of NetBIOS Aliases: -




STEP ACTION

5. Enter the following command to convert the CIFS server configuration from an Active Directory

domain to a Windows workgroup. Enter y when prompted to continue:

cluster1::> vserver cifs modify -vserver svm_smb_main -workgroup

WORKGROUP

Sample output:

Warning: To enter workgroup mode, all domain-based features must be disabled

and their configuration removed automatically by the system, including

continuously-available shares, shadow copies, and AES. However,

domain-configured share ACLs such as "LEARN.NETAPP.LOCAL\userName"

will not work properly, but cannot be removed by Data ONTAP. Remove

these share ACLs as soon as possible using external tools after the

command completes. If AES is enabled, you may be asked to supply the

name and password of a Windows account with sufficient privileges to

disable it in the "LEARN.NETAPP.LOCAL" domain.

Do you want to continue? {y|n}: y

Successfully queued CIFS Server Modify job [id: 63] for CIFS server "SMB_MAIN".

To view the status of the job, use the "job show -id <jobid>" command.

6. Enter the following command to view the job status. Replace the jobid 61 with the jobid that you

received:

cluster1::> job show -id 63

Sample output:

Owning

Job ID Name Vserver Node State

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

108 CIFS Server Modify Job svm_smb_main cluster1-01 Success

Description: Modifying CIFS server: 1. mode: Domain to Workgroup

7. To complete the conversion, you should also remove the Active Directory domain

configuration from the domain controller; however, since some of the other exercises in

this course still require the domain configuration, we can skip this step in the process.




STEP ACTION

8. Enter the following command to verify the CIFS server has been converted to a Windows

workgroup configuration:

cluster1::> vserver cifs show -vserver svm_smb_main

Sample output:

Vserver: svm_smb_main

CIFS Server NetBIOS Name: SMB_MAIN

NetBIOS Domain/Workgroup Name: WORKGROUP

Fully Qualified Domain Name: -

Organizational Unit: -

Default Site Used by LIFs Without Site Membership: -

Workgroup Name: WORKGROUP

Authentication Style: workgroup

CIFS Server Administrative Status: up

CIFS Server Description:

List of NetBIOS Aliases: -

9. Enter the following command to create a new SMB workgroup user wgusr. Enter and confirm a

new password (Netapp123) when prompted:

cluster1::> vserver cifs users-and-groups local-user create -vserver

svm_smb_main -user-name wgusr

Sample output:

Enter the password:

Confirm the password:




TASK 3: VERIFY AND TEST THE MODIFIED CONFIGURATION

In this task, you map the SMB workgroup share to the Windows Server and verify that you are able to write

data to the share and read data from the share.

STEP ACTION

1. On the Windows Server machine, open a command prompt and enter the following command to

delete the “M” drive mapping:

C:\Users\Administrator.W2K12> net use m: /delete /yes

Sample output:

m: was deleted successfully.

2. Enter the following command to map the Windows “X” drive to the new SMB workgroup share.

Enter the password from the previous step when prompted:

C:\Users\Administrator.W2K12> net use x: \\192.168.0.60\smb_main_share

/USER:SMB_MAIN\wgusr

Sample output:

The command completed successfully.

3. On the Windows Server machine, open File Explorer and navigate to the X: drive.

4. Verify that the file exists from task 1 step 2.





STEP ACTION

6. Edit the text document, add text, and save the document.


END OF EXERCISE




EXERCISE 2: CONFIGURING AN SVM FOR SMB WORKGROUPS

In this exercise, you create a storage virtual machine (SVM) and configure the SVM to join an SMB

workgroup. Then you create a volume mounted in the namespace, configure SMB sharing, and test the share

on a Windows workgroup peer machine.

OBJECTIVES


Create a data aggregate.

Create an SVM for SMB workgroups.

Verify and test the workgroup configuration.

























TASK 1: CREATE A DATA AGGREGATE

In this task, you verify that the CIFS license is installed and then you create a data aggregate for the SVM.

STEP ACTION




login as: admin

Password: Netapp123


4. Enter the following command to display the license status and verify that CIFS is licensed:

cluster2::> system license show

Sample output:

Serial Number: 1-80-000056

Owner: cluster2

Package Type Description Expiration

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

Base license Cluster Base License -

Serial Number: 1-81-0000000000000000000000072

Owner: cluster2-01


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

NFS license NFS License -

CIFS license CIFS License -

SnapMirror license SnapMirror License -

SnapVault license SnapVault License -

SnapLock license SnapLock License -





STEP ACTION

5. Enter the following command to create a five disk aggregate for the SVM. Enter y when prompted

to continue:

cluster2::> storage aggregate create -aggregate n1_aggr_smb_wrkgrp

-diskcount 5

Sample output:

Info: The layout for aggregate "n1_aggr_smb_wrkgrp" on node "cluster2-01" would be:

First Plex

RAID Group rg0, 5 disks (block checksum, raid_dp)

Position Disk Type Size

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

dparity NET-1.15 SSD -

parity NET-1.16 SSD -

data NET-1.17 SSD 500MB



Aggregate capacity available for volume use would be 1.32GB.


[Job 29] Job succeeded: DONE




TASK 2: CREATE AN SVM FOR SMB WORKGROUPS

In this task, you create an SVM that provides SMB workgroup resources to a Windows workgroup peer.

STEP ACTION

1. Enter the following command to create an SVM with root volume svm_smb_rootvol located

on aggregate n1_aggr_smb_wrkgrp:

cluster2::> vserver create -vserver svm_smb_wrkgrp -aggregate

n1_aggr_smb_wrkgrp -rootvolume svm_smb_rootvol -rootvolume-security-

style ntfs

Sample output:

[Job 30] Job succeeded:

Vserver creation completed

2. Enter the following command to display the protocols configured for the svm_smb_wrkgrp

SVM:

cluster2::> vserver show-protocols -vserver svm_smb_wrkgrp

Sample output:

Vserver: svm_smb_wrkgrp

Protocols: nfs, cifs, fcp, iscsi, ndmp

3. Enter the following command to remove all of the protocols configured for SVM

svm_smb_wrkgrp except cifs:

cluster2::> vserver remove-protocols -protocols nfs,fcp,iscsi,ndmp,http

-vserver svm_smb_wrkgrp

4. Enter the following command to create a data logical interface (LIF):

cluster2::> network interface create -vserver svm_smb_wrkgrp -lif

svm_smb_lif1 -role data -data-protocol cifs -home-node cluster2-01

-home-port e0d -subnet-name cluster2_delta_subnet

5. Enter the following command to create rule #1 for the default export policy:

cluster2::> vserver export-policy rule create -policyname default

-clientmatch 0.0.0.0/0 -rorule any -rwrule none -vserver svm_smb_wrkgrp

6. Enter the following command to create an CIFS server on SVM svm_smb_wrkgrp:

cluster2::> vserver cifs create -vserver svm_smb_wrkgrp -cifs-server

SMBWRKGRP -workgroup WORKGROUP

7. Export policies for SMB access are optional starting with Data ONTAP 8.2, and they

are disabled by default. You can enable export policies for SMB if you want to provide

an additional layer of SMB access control, in addition to Storage-Level Access Guard

and share and file permissions. See CIFS File Access Reference Guide for additional

information.




STEP ACTION

8. Enter the following command to create a 1 GB volume used to serve the SMB workgroup:

cluster2::> volume create -volume smb_wrkgrp_volume -aggregate

n1_aggr_smb_wrkgrp -size 1GB -vserver svm_smb_wrkgrp -junction-path

/smb_wrkgrp_volume -security-style ntfs

Sample output:

[Job 31] Job succeeded: Successful

9. Enter the following command to create an SMB share for the new volume:

cluster2::> cifs share create -share-name smb_wrkgrp_volume -path

/smb_wrkgrp_volume

10. Enter the following command to create a new SMB workgroup user wrkgrp_user. Enter and

confirm a new password (Netapp123) when prompted:

cluster2::> vserver cifs users-and-groups local-user create -vserver

svm_smb_wrkgrp -user-name wrkgrp_user

Sample output:

Enter the password:

Confirm the password:




TASK 3: VERIFY AND TEST THE WORKGROUP CONFIGURATION

In this task, you map the SMB workgroup share to the Windows Server and verify that you are able to write

data to the share and read data from the share.

STEP ACTION


map the Windows “W” drive to the new SMB workgroup share. Enter the password from the

previous step when prompted:

C:\Users\Administrator.W2K12> net use w:

\\192.168.0.161\smb_wrkgrp_volume /USER:SMBWRKGRP\wrkgrp_user

Sample output:


2. On the Windows Server machine, open File Explorer and navigate to the W: drive.





STEP ACTION



END OF EXERCISE


E4-1 ONTAP Administration: What’s New in ONTAP 9.0: All Flash FAS Enhancements


MODULE 4: ALL FLASH FAS ENHANCEMENTS

No exercise is associated with Module 4.


E5-1 ONTAP Administration: What’s New in ONTAP 9.0: Data Availability and Protection Enhancements


MODULE 5: DATA AVAILABILITY AND PROTECTION ENHANCEMENTS

EXERCISE 1: CONFIGURING SNAPLOCK FOR FILE RETENTION

In this exercise, you create two SnapLock volumes (both a SnapLock Compliance volume and a SnapLock

Enterprise volume), and then you write files to each volume, commit the changes, and then test the committed

state of each volume.

OBJECTIVES


Create SnapLock compatible aggregates.

Create SnapLock volumes.

Create SnapLock volume shares.

Manage SnapLock volumes.




One CentOS Linux 6.5 Server system






















TASK 1: CREATE SNAPLOCK COMPATIBLE AGGREGATES

In this task, you create one SnapLock Enterprise aggregate and one SnapLock Compliance aggregate.

STEP ACTION



https://192.168.0.50.


User name: admin

Password: Netapp123

3. On the command bar, click Configurations.

4. In the Configurations pane, click Licenses.

5. Click the License Details tab.


https://192.168.0.50/



STEP ACTION

6. In the License Details pane, verify that SnapLock is licensed on both nodes in the cluster.

7. On the command bar, click Hardware and Diagnostics > Aggregates.

8. In the Aggregates pane, click Create.




STEP ACTION

9. On the Create Aggregate page, enter the following values:

Name: n2_aggr_sle

Disk Type: FCAL (click Browse and select FCAL cluster1-02)

Number of Disks: 5

RAID Configuration: RAID-DP, RAID group size of 16 disks

New Usable Capacity: 10.55 GB (Estimated)

SnapLock Type: SnapLock Enterprise

Initialize ComplianceClock: <selected>

Mirror this aggregate: <unselected>

10. The SnapLock ComplianceClock only needs to be initialized once on each storage

system.

11. Click Create.

12. In the Aggregates pane, click Create.




STEP ACTION

13. On the Create Aggregate page, enter the following values:

Name: n2_aggr_slc

Disk Type: FCAL (click Browse and select FCAL cluster1-02)

Number of Disks: 5

RAID Configuration: RAID-DP, RAID group size of 16 disks

New Usable Capacity: 10.55 GB (Estimated)

SnapLock Type: SnapLock Compliance

14. Click Create.

15. In the Aggregates pane, verify that both aggregates were created.




TASK 2: CREATE SNAPLOCK VOLUMES

In this task, you create one SnapLock Enterprise volume and one SnapLock Compliance volume.

STEP ACTION


2. In the SVMs pane, click svm_snaplock.

3. On the SVM svm_snaplock command bar, click Volumes.

4. In the Volumes pane, click Create.




STEP ACTION

5. On the General tab of the Create Volume page, enter the following values:

Name: vol_snaplock_enterprise

Aggregate: n2_aggr_sle

Storage Type: NAS

Total Size: 8 GB

Snapshot Reserve (%): 5 (default)

Data Space: 7.6 GB

Snapshot Space: 409.6 MB

Thin Provisioned: <unselected>

6. Click SnapLock tab.




STEP ACTION

7. On the SnapLock tab of the Create Volume page, enter the following values:

Autocommit Period: Not specified (default)

Minimum data retention: 3 Months

Maximum data retention: 1 Years

Default Retention Period: Set to Minimum Retention period (default)

8. Retention periods can be modified after the volume is created.

9. Click Create.

10. In the Volumes pane, click Create to create a new volume.




STEP ACTION

11. On the General tab of the Create Volume page, enter the following values:

Name: vol_snaplock_compliance

Aggregate: n2_aggr_slc

Storage Type: NAS

Total Size: 8 GB

Snapshot Reserve (%): 5 (default)

Data Space: 7.6 GB

Snapshot Space: 409.6 MB

Thin Provisioned: <unselected>

12. Click SnapLock tab.




STEP ACTION

13. On the SnapLock tab of the Create Volume page, enter the following values:

Autocommit Period: Not specified (default)

Minimum data retention: 0 Years (default)

Maximum data retention: 10 Years

Default Retention Period: Set to Maximum Retention period (default)

14. Click Create.

15. In the Volumes pane, verify that both volumes were created.

16. On the SVM svm_snaplock command bar, click SVM Settings.




STEP ACTION

17. In the SVM Settings pane, click Export Policies.

18. In the Export Rules pane, make sure that Rule Index 1 is selected and click Edit.

19. In the Modify Export Rule window, select Read/Write for UNIX and select Allow Superuser

Access.

20. Click OK.




TASK 3: CREATE SNAPLOCK VOLUME SHARES

In this task, you create SMB shares for both volumes.

STEP ACTION

1. On the SVM svm_snaplock command bar, click Shares.

2. In the Shares pane, click Create Share.

3. On the Create Share page, enter the following values:

Folder To Share: /vol_snaplock_enterprise

Share Name: vol_snaplock_enterprise

Comment: <blank>

Enable continuous availability for Hyper-V and SQL: <unselected>

Encrypt data while accessing this share: <unselected>

4. Click Create.

5. Repeat steps 2 through 4 to create share vol_snaplock_compliance.




STEP ACTION

6. In the Shares pane, verify that both shares were created.




TASK 4: MANAGE SNAPLOCK ENTERPRISE VOLUME

In this task, you add files to the SnapLock Enterprise volume, commit and lock the volume, and verify that

the volume is locked and un-writable.

STEP ACTION


map the Windows “S” drive to the new share:

C:\Users\Administrator.W2K12> net use s:

\\192.168.0.61\vol_snaplock_enterprise

Sample output:


2. On the Windows Server machine, open File Explorer and navigate to the S: drive.

3. Create a new text document and name it New SLE Document. (Windows will automatically add

the .txt extension when you select New > Text Document).




STEP ACTION




7. In the PuTTY Configuration dialog box, double-click linux1.




STEP ACTION

8. At the Linux Server login prompt, provide the linux1 credentials:

login as: root

Password: Netapp123

The Linux Server CLI prompt and cursor appear.

9. Enter the following command to create a new directory to mount the SnapLock Enterprise volume

under /mnt:

[root@centos65 ~]# mkdir /mnt/vol_snaplock_enterprise

10. Enter the following command to mount the SnapLock Enterprise volume under

/mnt/vol_snaplock_enterprise:

[root@centos65 ~]# mount 192.168.0.61:/vol_snaplock_enterprise

/mnt/vol_snaplock_enterprise

11. Enter the following command to verify that the document created on Windows can be read in

Linux:

[root@centos65 ~]# cat /mnt/vol_snaplock_enterprise/"New SLE

Document.txt"

Sample output:

This is a SnapLock Enterprise test document.

12. Enter the following command to append text to the document and enter text (Oops, this

sentence needed to be added to the file.) into the document:

[root@centos65 ~]# cat >>/mnt/vol_snaplock_enterprise/"New SLE

Document.txt"

Sample output:

Oops, this sentence needed to be added to the file.

13. Enter <CNTL-C> to close the file input.

14. Enter the following command to verify that the document can still be read:

[root@centos65 ~]# cat /mnt/vol_snaplock_enterprise/"New SLE

Document.txt"

Sample output:

This is a text document on a SnapLock Enterprise volume mounted on Linux.

Oops, this sentence needed to be added to the file.

15. Files can be committed (or locked) manually using client utilities or tools, or

automatically by setting retention periods. Clients based on the Unix operating system

(like Linux) can use chmod -w to manually commit or lock the file. Where -w

represents turning off write capability to the file.




STEP ACTION

16. Enter the following command to display file attributes for all files in the

/mnt/vol_snaplock_enterprise directory:

[root@centos65 ~]# ls -al /mnt/vol_snaplock_enterprise/

Sample output:

total 16

drwxr-xr-x. 2 root root 4096 Jun 7 10:11 .

drwxr-xr-x. 4 root root 4096 Jun 7 10:13 ..

-rwxr-xr-x. 1 root bin 98 Jun 7 10:13 New SLE Document.txt

drwxrwxrwx. 2 root root 4096 Jun 7 10:06 .snapshot

17. Enter the following command to manually lock the file:

[root@centos65 ~]# chmod -w /mnt/vol_snaplock_enterprise/"New SLE

Document.txt"

18. Enter the following command to redisplay file attributes for all files in the

/mnt/vol_snaplock_enterprise directory (notice the write mode for the files owner has been

removed):

[root@centos65 ~]# ls -al /mnt/vol_snaplock_enterprise/

Sample output:

total 16



-r-xr-xr-x. 1 root bin 98 Jun 7 10:13 New SLE Document.txt


19. Enter the following command (normally used to append additional text to the document) and

verify that the file is locked:

[root@centos65 ~]# cat >>/mnt/vol_snaplock_enterprise/"New SLE

Document.txt"

Sample output:

-bash: /mnt/vol_snaplock_enterprise/New Linux SLE Document.txt: Permission denied

20. What are your results when you try to edit the document in Windows Notepad?

______________________________________________________________________________

21. Try to edit the document in Windows WordPad, are the results any different?

______________________________________________________________________________




TASK 5: MANAGE SNAPLOCK COMPLIANCE VOLUME

In this task, you add files to the SnapLock Compliance volume, commit and lock the volume, and verify that

the volume is locked and un-writable.

STEP ACTION


map the Windows “T” drive to the new share:

C:\Users\Administrator.W2K12> net use t:

\\192.168.0.61\vol_snaplock_compliance

Sample output:


2. On the Windows Server machine, open File Explorer and navigate to the T: drive.

3. Create a new text document and name it New SLC Document. (Windows will automatically add

the .txt extension when you select New > Text Document).




STEP ACTION








STEP ACTION


login as: root

Password: Netapp123


9. Enter the following command to create a new directory to mount the SnapLock Compliance

volume under /mnt:

[root@centos65 ~]# mkdir /mnt/vol_snaplock_compliance

10. Enter the following command to mount the SnapLock Compliance volume under

/mnt/vol_snaplock_compliance:

[root@centos65 ~]# mount 192.168.0.61:/vol_snaplock_compliance

/mnt/vol_snaplock_compliance

11. Enter the following command to verify that the document created on Windows can be read in

Linux:

[root@centos65 ~]# cat /mnt/vol_snaplock_compliance/"New SLC

Document.txt"

Sample output:

This is a SnapLock Compliance test document.

12. Enter the following command to append text to the document and enter text (Wow - I did it

again, this sentence needed to be added to the file.) into the document:

[root@centos65 ~]# cat >>/mnt/vol_snaplock_compliance/"New SLC

Document.txt"

Sample output:

Wow - I did it again, this sentence needed to be added to the file.


14. Enter the following command to verify that the document can still be read:

[root@centos65 ~]# cat /mnt/vol_snaplock_compliance/"New SLC

Document.txt"

Sample output:

This is a SnapLock Compliance test document.

Wow - I did it again, this sentence needed to be added to the file.

15. As mentioned previously, files can be committed (or locked) manually using client

utilities or tools, or automatically by setting retention periods. Windows clients can use

attrib +r to manually commit or lock the file. Where +r represents turning on the

read-only flag on the file.




STEP ACTION


display file attributes for all files on the Windows “T” drive:

C:\Users\Administrator.W2K12> attrib t:*

Sample output:

A T:\New SLC Document.txt

17. Enter the following command to manually lock the file:

C:\Users\Administrator.W2K12> attrib +r t:\"New SLC Document.txt"

18. Enter the following command to redisplay file attributes for all files on the “T” drive (notice the

read-only “R” attribute):

C:\Users\Administrator.W2K12> attrib t:*

Sample output:

A R T:\New SLC Document.txt





STEP ACTION

20. Add text, and save and close the document.

21. Open up the document. Did the update get saved?

______________________________________________________________________________

END OF EXERCISE




EXERCISE 2: CREATING A SNAPLOCK FOR SNAPVAULT RELATIONSHIP

In this exercise, you create a SnapLock for SnapVault protection relationship between volumes on two

different clusters.

OBJECTIVES


Create SVM peer relationship.

Create protection relationship.

Manage the protection relationship.



























TASK 1: CREATE SVM PEER RELATIONSHIP

In this task, you create an SVM peer relationship between an SVM on cluster1 and an SVM on cluster2.

STEP ACTION

1. This task requires commands be entered on both cluster1 and cluster2. Be aware of the

cluster prompt (cluster1::> and cluster2::>) that each command is being entered

on.




login as: admin

Password: Netapp123


5. An SVM peer relationship requires a cluster peer relationship to be created first. Your

lab environment should already have intercluster LIFs created on every node from both

clusters, and the cluster peer relationship already established.

6. Enter the following command to verify the availability of the cluster peer relationship between

cluster1 and cluster2:

cluster1::> cluster peer show

Sample output:

Peer Cluster Name Cluster Serial Number Availability Authentication

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

cluster2 1-80-000056 Available ok

7. Enter the following command to create an SVM SnapMirror peer relationship between SVM

svm_snaplock on cluster1 and SVM svm_slock_source on cluster2:

cluster1::> vserver peer create -vserver svm_snaplock -peer-cluster

cluster2 -peer-vserver svm_slock_source -applications snapmirror

Sample output:

Info: [Job 68] 'vserver peer create' job queued




STEP ACTION

8. Enter the following command to check the status of the peer request:

cluster1::> vserver peer show-all -vserver svm_snaplock

Sample output:

Peer Peer Peering Remote

Vserver Vserver State Peer Cluster Applications Vserver

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

svm_snaplock svm_slock_source initiated cluster2 snapmirror svm_slock_source




login as: admin

Password: Netapp123


12. Enter the following command to verify the cluster peer relationship between cluster2 and cluster1:


Sample output:


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


13. Enter the following command to check to see if any peer requests have been made:

cluster2::> vserver peer show-all -vserver svm_slock_source

Sample output:



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

svm_slock_source svm_snaplock pending cluster1 snapmirror svm_snaplock




STEP ACTION

14. Enter the following command to accept the peer request from cluster1:

cluster2::> vserver peer accept -vserver svm_slock_source -peer-vserver

svm_snaplock

Sample output:

Info: [Job 32] 'vserver peer accept' job queued

15. Enter the vserver peer show-all command again to check the status of the peer accept:

cluster2::> vserver peer show-all -vserver svm_slock_source

Sample output:



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

svm_slock_source svm_snaplock peered cluster1 snapmirror svm_snaplock

16. Return to the cluster1 PuTTY session.

17. Enter the vserver peer show-all command again to check the status of the peer accept:

cluster1::> vserver peer show-all -vserver svm_snaplock

Sample output:



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

svm_snaplock svm_slock_source peered cluster2 snapmirror svm_slock_source




TASK 2: CREATE SNAPLOCK FOR SNAPVAULT RELATIONSHIP

In this task, you create a SnapLock for SnapVault protection relationship between an existing volume on

cluster2 and a new SnapLock Enterprise volume on cluster1.

STEP ACTION



https://192.168.0.50.


User name: admin

Password: Netapp123

3. On the command bar, click Protection > Relationships.

4. In the Relationships pane, click Create.


https://192.168.0.50/



STEP ACTION

5. In the Browse SVM page, select svm_snaplock and click Select.




6. On the Create Protection Relationship page, enter the following values:

Relationship Type: Vault

Source Volume

Cluster: cluster2 (default)

Storage Virtual Machine: svm_slock_source

Volume: slock_source_NFS_volume

Destination Volume

Storage Virtual Machine: svm_snaplock

Volume: New Volume

Volume name: slock_source_NFS_volume_vault

Aggregate: n2_aggr_sle

Enable dedupe: <selected>

Default Retention Period: 5 Years

Configuration Details

Vault Policy: XDPDefault (default)

Schedule: None

Initialize Relationship: <selected>




STEP ACTION

7. Initializing the relationship results in the base Snapshot copy being transferred to the

destination volume.

8. Click Create.

9. Review all the information, and then click OK.

10. In the Relationships pane, verify that the relationship was created.




TASK 3: MANAGE THE SOURCE AND DESTINATION VOLUMES

In this task, you modify the source volume export policy on cluster2 and mount the destination volume in the

namespace on cluster1.

STEP ACTION

1. From the Windows Server desktop, access OnCommand System Manager for cluster2:


https://192.168.0.150.


User name: admin

Password: Netapp123


4. In the SVMs pane, select svm_slock_source and click Manage.

5. Clicking the SVM name in the SVMs pane is the same as selecting the SVM row and

clicking Manage.

6. On the SVM svm_slock_source command bar, click SVM Settings.


https://192.168.0.150/



STEP ACTION


8. In the Policy pane, select slock_source.

9. In the Export Rules pane, make sure that Rule Index 1 is selected and click Edit.

10. In the Modify Export Rule window, select Read-Only and select Allow Superuser Access.

11. Click OK.




STEP ACTION

12. On the SVM svm_slock_source command bar, click Namespace.

13. In the Namespace pane, select the root (/) and click Change Export Policy.

14. In the Change Export Policy window, select slock_source in the Export Policy pulldown menu

(this step is one method of adding the export policy rule that is missing after an SVM is created

using the OnCommand System Manager wizard).

15. Click Change.

16. Return to the cluster1 OnCommand System Manager session.

17. From OnCommand System Manager for cluster1, on the command bar, click SVMs.

18. In the SVMs pane, click svm_snaplock.

19. On the SVM svm_snaplock command bar, click Namespace.




STEP ACTION

20. In the Namespace pane, click Mount.

21. In the Mount Volume window, select slock_source_NFS_volume_vault from the pulldown list

for Volume Name and keep the defaults for Junction Name and Junction Path.

22. Click Mount.




TASK 4: MANAGE SNAPLOCK FOR SNAPVAULT RELATIONSHIP

In this task, you add a file to the volume on cluster2 and manually update the changes to the SnapVault

volume on cluster1.

STEP ACTION




login as: root

Password: Netapp123


4. Enter the following command to create a new directory to mount the source volume under /mnt:

[root@centos65 ~]# mkdir /mnt/slock_source_NFS_volume

5. Enter the following command to mount the source volume under /mnt/

slock_source_NFS_volume:

[root@centos65 ~]# mount 192.168.0.160:/slock_source_NFS_volume

/mnt/slock_source_NFS_volume

6. Enter the following command to create a sample log file and enter text (LOG <Today’s Date>

Sample log data.) into the document:

[root@centos65 ~]# cat >/mnt/slock_source_NFS_volume/log2016_z11

Sample output:

LOG 05/26/2016 Sample log data.


8. Enter the following command to verify that the log file can be read:

[root@centos65 ~]# cat /mnt/slock_source_NFS_volume/log2016_z11

Sample output:

LOG 05/26/2016 Sample log data.




STEP ACTION




login as: root

Password: Netapp123


12. Enter the following command to create a new directory to mount the vault volume under /mnt:

[root@centos65 ~]# mkdir /mnt/slock_source_NFS_volume_vault

13. Enter the following command to mount the SnapLock Compliance volume under

/mnt/vol_snaplock_compliance:

[root@centos65 ~]# mount 192.168.0.61:/slock_source_NFS_volume_vault

/mnt/slock_source_NFS_volume_vault

14. Enter the following command to verify that the log file has not been synchronized to the

SnapVault volume yet:

[root@centos65 ~]# ls -al /mnt/slock_source_NFS_volume_vault

Sample output:

total 12

drwxr-xr-x. 2 root root 4096 Apr 27 17:30 .

drwxr-xr-x. 6 root root 4096 May 26 17:08 ..

drwxrwxrwx. 3 root root 4096 May 26 12:38 .snapshot

15. Return to the cluster2 OnCommand System Manager session (to manually create a Snapshot copy

of the source volume).





STEP ACTION

17. In the SVMs pane, click svm_slock_source.

18. On the SVM svm_slock_source command bar, click Volumes.

19. In the Volumes pane, select slock_source_NFS_volume.

20. Click Snapshot Copies > Create.

21. In the Create Snapshot Copy window, enter the Snapshot Copy Name exercise5-

1_snapshot_copy.

22. Click Create.

23. Return to the cluster1 OnCommand System Manager session.

24. From OnCommand System Manager for cluster1, on the command bar, click Protection >

Relationships.




STEP ACTION

25. In the Relationships pane, select svm_slock_source and click Operations > Update.

26. In the Update window, select Select Snapshot copy (click Browse and select exercise5-

1_snapshot_copy).

27. Click Update.

28. From the command line on linux1, enter the following command to verify that the log file has

been synchronized to the SnapVault volume:

[root@centos65 ~]# ls -al /mnt/slock_source_NFS_volume_vault

Sample output:

total 12



-rw-r--r--. 1 root root 32 Jun 7 10:51 log2016_z11


29. Enter the following command (normally used to append additional text to the document) and

verify that the log file is locked:

[root@centos65 ~]# cat >>/mnt/slock_source_NFS_volume_vault/log2016_z11

Sample output:

-bash: /mnt/slock_source_NFS_volume_vault/log2016_z11: Permission denied

END OF EXERCISE




EXERCISE 3: MANAGING RAID-TEC AGGREGATES

In this exercise, you create a RAID-TEC aggregate, convert a RAID-DP aggregate to RAID-TEC, and you

verify the operability of a degraded RAID-TEC aggregate.

OBJECTIVES


Create a RAID-TEC aggregate.

Convert a RAID-DP aggregate to a RAID-TEC aggregate.

Verify the operability of a degraded RAID-TEC aggregate.


























TASK 1: CREATE A RAID-TEC AGGREGATE

In this task, you create a RAID-TEC aggregate from seven spare disks.

STEP ACTION




login as: admin

Password: Netapp123





STEP ACTION

4. Enter the following command to display all of the spare disks in the cluster:

cluster2::> storage aggregate show-spare-disks

Sample output:

Original Owner: cluster2-01

Pool0

Spare Pool

Usable Physical

Disk Type Class RPM Checksum Size Size Status

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

NET-1.8 FCAL performance 15000 block 3.93GB 3.93GB zeroed













NET-1.34 SSD solid-state - block 520.5MB 527.6MB zeroed













STEP ACTION

5. Enter the following command to create a RAID-TEC aggregate using seven of the available spare

disks. Enter y when prompted to continue:

cluster2::> storage aggregate create -node cluster2-01 -aggregate

n1_aggr_raid_tec -raidtype raid_tec -diskcount 7

Sample output:

Info: The layout for aggregate "n1_aggr_raid_tec" on node "cluster2-01" would be:

First Plex

RAID Group rg0, 7 disks (block checksum, raid_tec)

Position Disk Type Size

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

tparity NET-1.8 FCAL -

dparity NET-1.26 FCAL -

parity NET-1.9 FCAL -

data NET-1.27 FCAL 3.91GB




Aggregate capacity available for volume use would be 14.06GB.






STEP ACTION

6. Enter the following command to view the status of the new RAID-TEC aggregate (notice the

RAID type and parity information):

cluster2::> storage aggregate show-status -aggregate n1_aggr_raid_tec

Sample output:

Owner Node: cluster2-01

Aggregate: n1_aggr_raid_tec (online, raid_tec) (block checksums)

Plex: /n1_aggr_raid_tec/plex0 (online, normal, active, pool0)

RAID Group /n1_aggr_raid_tec/plex0/rg0 (normal, block checksums)

Usable Physical

Position Disk Pool Type RPM Size Size Status

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

tparity NET-1.8 0 FCAL 15000 3.93GB 3.93GB (normal)

dparity NET-1.26 0 FCAL 15000 3.93GB 3.93GB (normal)

parity NET-1.9 0 FCAL 15000 3.93GB 3.93GB (normal)

data NET-1.27 0 FCAL 15000 3.93GB 3.93GB (normal)








TASK 2: CONVERT A RAID-DP AGGREGATE TO A RAID-TEC AGGREGATE

In this task, you convert a RAID-DP aggregate to a RAID-TEC aggregate.

STEP ACTION




login as: admin

Password: Netapp123


4. Enter the following command to verify the RAID type of the n1_aggr_raid_dp aggregate:

cluster1::> storage aggregate show -aggregate n1_aggr_raid_dp -fields

raidtype

Sample output:

aggregate raidtype

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

n1_aggr_raid_dp raid_dp

5. Enter the following command to display the disks used to create aggregate n1_aggr_raid_dp

(notice the disk type):

cluster1::> storage disk show -aggregate n1_aggr_raid_dp

Sample output:

Usable Disk Container Container

Disk Size Shelf Bay Type Type Name Owner

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

NET-1.7 3.93GB - 22 FCAL aggregate n1_aggr_raid_dp cluster1-01










STEP ACTION

6. Enter the same command with the -fields position parameter to display the disks and the

RAID (RAID-DP) position of the disk (data, parity, or dparity):

cluster1::> storage disk show -aggregate n1_aggr_raid_dp -fields

position

Sample output:

disk position

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

NET-1.7 parity

NET-1.8 data

NET-1.15 dparity

NET-1.16 data

NET-1.18 data

NET-1.22 data


7. Enter the following command to verify that there is at least one spare disk available on node1, and

the disk type matches the disk type used in the n1_aggr_raid_dp aggregate:

cluster1::> storage aggregate show-spare-disks -node cluster1-01

Sample output:

Original Owner: cluster1-01

Pool0

Spare Pool

Usable Physical

Disk Type Class RPM Checksum Size Size Status

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


















STEP ACTION

8. Enter the following command to convert the n1_aggr_raid_dp aggregate from RAID-DP to

RAID-TEC:

cluster1::> storage aggregate modify -aggregate n1_aggr_raid_dp

-raidtype raid_tec

9. Enter the following command to verify that the RAID type of the n1_aggr_raid_dp aggregate has

been changed to RAID-TEC:

cluster1::> storage aggregate show -aggregate n1_aggr_raid_dp -fields

raidtype

Sample output:

aggregate raidtype

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

n1_aggr_raid_dp raid_tec

10. Enter the storage disk show command with the -fields position parameter again to

display the disks and the RAID (RAID-TEC) position of the disk (data, parity, dparity, or

tparity), compare your output to the output in step 6:

cluster1::> storage disk show -aggregate n1_aggr_raid_dp -fields

position

Sample output:

disk position

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

NET-1.7 parity

NET-1.8 data

NET-1.15 dparity

NET-1.16 data

NET-1.17 tparity

NET-1.18 data

NET-1.22 data


11. In a production environment using the aggregate naming scheme suggested above, the

best practice would be to rename the aggregate to n1_aggr_raid_tec or similar.




TASK 3: VERIFY THE OPERABILITY OF A DEGRADED RAID-TEC AGGREGATE

In this task, you verify the operability of a degraded RAID-TEC aggregate after failing three disks in the

aggregate.

STEP ACTION

1. Enter the following command to verify that the RAID-TEC aggregate is in a normal state:

cluster1::> storage aggregate show-status -aggregate n2_aggr_raid_tec2

Sample output:


Aggregate: n2_aggr_raid_tec2 (online, raid_tec) (block checksums)

Plex: /n2_aggr_raid_tec2/plex0 (online, normal, active, pool0)

RAID Group /n2_aggr_raid_tec2/plex0/rg0 (normal, block checksums)

Usable Physical


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









2. Enter the following command to fail one of the disks that is being used for the n2_aggr_raid_tec2

aggregate. Enter y when prompted to fail the disk:

cluster1::> storage disk fail -disk NET-1.73 -immediate true

Sample output:

Warning: The system will not prefail the disk and its contents will not be

copied to a replacement disk before being failed out. Do you want to

fail out the disk immediately? {y|n}: y




STEP ACTION

3. Enter the following command to verify that the disk that was failed in the previous step, has been

replaced (and the new disk is reconstructing the contents of the previously failed disk) and the

aggregate is still in a normal state:


Sample output:


Aggregate: n2_aggr_raid_tec2 (online, raid_tec, reconstruct) (block checksums)


RAID Group /n2_aggr_raid_tec2/plex0/rg0 (reconstruction 1% completed, block checksums)

Usable Physical


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




data NET-1.79 0 FCAL 15000 3.93GB 3.93GB

(reconstruction 1% completed)





4. Enter the following command to fail a second disk that is being used for the n2_aggr_raid_tec2



Sample output:







STEP ACTION


replaced and the aggregate is still in a normal state:


Sample output:




RAID Group /n2_aggr_raid_tec2/plex0/rg0 (double reconstruction 3% completed, block

checksums)

Usable Physical


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











6. Enter the following command to fail a third disk that is being used for the n2_aggr_raid_tec2



Sample output:







STEP ACTION


replaced and the RAID Group is now in a triple reconstruction state due to the three failed disk

rebuilds:


Sample output:




RAID Group /n2_aggr_raid_tec2/plex0/rg0 (triple reconstruction 5% completed, block

checksums)

Usable Physical


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












8. What would happen if you try to fail data disk NET-1.49?

______________________________________________________________________________

END OF EXERCISE




EXERCISE 4: SNAPMIRROR FOR STORAGE VIRTUAL MACHINES

In this exercise, you explore the SnapMirror for 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. This flow diagram shows the major steps involved in preparing the clusters for

disaster recovery using SnapMirror SVM:

In the second part, you use SnapMirror SVM to execute disaster-recovery failover and recovery. 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. This flow diagram shows the major steps involved in the second part of the activity:

OBJECTIVES


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.



























TASK 1: EXAMINE SOURCE SVM CONFIGURATIONS

In this task, you examine the primary SVM configurations.

STEP ACTION

1. From the Windows Server desktop, access OnCommand System Manager for cluster1:

c. Open web browser. d. In the address bar, enter the cluster-management logical interface (LIF) IP address

https://192.168.0.50.


User name: admin

Password: Netapp123


4. In the SVMs pane, click svm_finance.

5. On the SVM svm_finance command bar, click Namespace and examine the volumes mounted in

the namespace and their export policies. If volumes: finance3_NAS_volume and

finance4_CIFS_volume are not mounted in the namespace, mount them.

6. On the SVM svm_finance command bar, click SVM Settings.


https://192.168.0.50/



STEP ACTION


8. In the Export Rules pane, make sure that Rule Index 1 for each policy (default and finance2)

allows connections from all clients.

9. On the SVM svm_finance command bar, click Volumes and examine the volumes and their sizes.

10. On the SVM svm_finance command bar, click Shares and examine the CIFS share for

finance1_CIFS_volume.

11. On the command bar, click Network.




STEP ACTION

12. In the Network pane, click Network Interfaces.

13. Examine the svm_finance_cifs_nfs_lif1 network interface.

14. The svm_finance_cifs_nfs_lif1 address will also be used on the cluster2 cluster during

disaster-recovery failover. The address will be used on cluster2, 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.

15. On the Windows Server machine, open File Explorer and navigate to the F: drive.

16. Verify that the file File_500M exists.






STEP ACTION


login as: root

Password: Netapp123


20. Enter the following command to mount the finance2_NFS_volume volume under /mnt/finance2/

(the /mnt/finance2 directory should already be created):

[root@centos65 ~]# mount 192.168.0.62:/finance2_NFS_volume

/mnt/finance2/

21. Enter the following command to verify that the file File_240M exists:

[root@centos65 ~]# ls -al /mnt/finance2/

Sample output:

total 245920

drwxr-xr-x. 2 root root 4096 May 30 22:12 .

drwxr-xr-x. 6 root root 4096 May 31 03:48 ..

-rw-r--r--. 1 root root 250814668 Dec 1 2014 File_240M

drwxrwxrwx. 7 root root 4096 May 31 04:05 .snapshot




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



on.




login as: admin

Password: Netapp123







STEP ACTION


login as: admin

Password: Netapp123


8. An SVM peer relationship requires a cluster peer relationship to be created first. Your

lab environment should already have intercluster LIFs created on every node from both

clusters, and the cluster peer relationship already established.

9. Enter the following command to verify the availability of the cluster peer relationship between

cluster1 and cluster2:


Sample output:


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


10. cluster2::> cluster peer show

Sample output:


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


11. Cluster node licenses must be identical on both clusters, with the exception of the

FlexArray license.




STEP ACTION

12. Enter the following command to display the license status and verify all of the license packages

installed on cluster1 are also installed on cluster2:

cluster1::> system license show

Sample output:


Owner: cluster1


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


iSCSI demo iSCSI License 10/10/2016 01:00:00

Serial Number: 1-81-0000000000000000000000070

Owner: cluster1-01


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






Serial Number: 1-81-0000000000000000000000071

Owner: cluster1-02


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










STEP ACTION

13. cluster2::> system license show

Sample output:


Owner: cluster2


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


Serial Number: 1-81-0000000000000000000000072

Owner: cluster2-01


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







14. Enter the following command to verify that the primary and disaster-recovery clusters have the

same cron schedules:

cluster1::> job schedule cron show

Sample output:

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





STEP ACTION

15. cluster2::> job schedule cron show

Sample output:

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


16. 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. In a production environment, 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.

17. Enter the following command on cluster1 to calculate the total aggregate size of the storage

needed for the disaster-recovery cluster:

cluster1::> volume show -vserver svm_finance

Sample output:

Vserver Volume Aggregate State Type Size Available Used%

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

svm_finance finance1_CIFS_volume n1_aggr_raid_dp online RW 1.50GB 955.7MB 37%

svm_finance finance2_NFS_volume n2_aggr_raid_tec2 online RW 2GB 1.66GB 16%

svm_finance finance3_NAS_volume n1_aggr_main online RW 2GB 1.90GB 5%

svm_finance finance4_CIFS_volume n1_aggr_main online RW 1GB 972.3MB 5%

svm_finance svm_finance_root n1_aggr_main online RW 20MB 18.61MB 6%


18. By default, each of these volumes will be protected (except the root volume). For this

exercise, we are going to demonstrate selective protection and only the following

volumes will be protected: finance1_CIFS_volume and finance2_NFS_volume.




STEP ACTION

19. Enter the following command on cluster2 to verify that the n1_aggr_main_dr aggregate can

support the size of the volumes in svm_finance:

cluster2::> storage aggregate show

Sample output:

Aggregate Size Available Used% State #Vols Nodes RAID Status

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

aggr0_n1 16.70GB 11.51GB 31% online 1 cluster2-01 raid_dp,

normal

n1_aggr_main_dr 21.09GB 20.07GB 5% online 2 cluster2-01 raid_dp,

normal

...





TASK 3: CREATE THE DISASTER-RECOVERY SVM

In this task, you create the disaster-recovery SVM on cluster2.

STEP ACTION

1. From the clustershell on cluster2, enter the following command to create a disaster-recovery

SVM:

cluster2::> vserver create -vserver svm_finance_dr -subtype

dp-destination

Sample output:

[Job 34] Job succeeded:

Vserver creation completed

2. You cannot configure a data-protection SVM from OnCommand System Manager 9.0;

you must use either the CLI or the OnCommand Workflow Automaton tool.




STEP ACTION

3. Enter the following command to verify that the disaster-recovery SVM was created:

cluster2::> vserver show -vserver svm_finance_dr

Sample output:

Vserver: svm_finance_dr

Vserver Type: data

Vserver Subtype: dp-destination

Vserver UUID: 2e8f81ef-2d04-11e6-b4e2-

0050568530a5

Root Volume: -

Aggregate: -

NIS Domain: -

Root Volume Security Style: -

LDAP Client: -

Default Volume Language Code: C.UTF-8

Snapshot Policy: default

Comment:

Quota Policy: default

List of Aggregates Assigned: -

Limit on Maximum Number of Volumes allowed: unlimited

Vserver Admin State: running

Vserver Operational State: stopped

Vserver Operational State Stopped Reason: dp-destination-not-started

Allowed Protocols: nfs, cifs, fcp, iscsi, ndmp

Disallowed Protocols: -

Is Vserver with Infinite Volume: false

QoS Policy Group: -

Caching Policy Name: -

Config Lock: false

IPspace Name: Default

Foreground Process: -

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. 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.

6. 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 SVM PEER RELATIONSHIP

In this task, you create you create an SVM peer relationship between the primary SVM on cluster1 and the

disaster-recovery SVM on cluster2.

STEP ACTION



on.

2. From the clustershell on cluster2, enter the following command to create an SVM peer

relationship between svm_finance (on cluster1) and svm_finance_dr (on cluster2):

cluster2::> vserver peer create -vserver svm_finance_dr -peer-cluster

cluster1 -peer-vserver svm_finance -applications snapmirror

Sample output:

Info: [Job 35] 'vserver peer create' job queued

3. Enter the following command to check the status of the peer request specific to SVM

svm_finance_dr:

cluster2::> vserver peer show-all -vserver svm_finance_dr

Sample output:



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

svm_finance_dr svm_finance initiated cluster1 snapmirror svm_finance

4. From the clustershell on cluster1, enter the following command to check the status of the peer

request specific to SVM svm_finance:

cluster1::> vserver peer show-all -vserver svm_finance

Sample output:



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

svm_finance svm_finance_dr pending cluster2 snapmirror svm_finance_dr

5. Enter the following command to accept the peer request from cluster2:

cluster1::> vserver peer accept -vserver svm_finance -peer-vserver

svm_finance_dr

Sample output:

Info: [Job 70] 'vserver peer accept' job queued




STEP ACTION

6. Enter the following command to confirm that the SVMs are peered:


Sample output:



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

svm_finance svm_finance_dr peered cluster2 snapmirror svm_finance_dr

7. Repeat step 6 on cluster2 (svm_finance_dr) to confirm that cluster2 also sees the SVMs as peered.




TASK 5: CREATE 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 cluster2, enter the following command to create the SnapMirror

relationship with the primary SVM:

cluster2::> snapmirror create -source-path svm_finance: -destination-

path svm_finance_dr: -type DP -throttle unlimited -policy DPDefault

-schedule hourly -identity-preserve true

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 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. Enter the following command to verify that the SnapMirror relationship was created and is in the

uninitialized state:

cluster2::> snapmirror show

Sample output:

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. Return to the cluster1 PuTTY session.




STEP ACTION

6. As mentioned earlier, only two volumes will be mirrored. From the clustershell on cluster1, enter

the following command to check the vserver-dr-protection flag for each of the volumes

associated with SVM svm_finance:

cluster1::> volume show -vserver svm_finance -fields

vserver-dr-protection

Sample output:

vserver volume vserver-dr-protection

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

svm_finance finance1_CIFS_volume protected

svm_finance finance2_NFS_volume protected

svm_finance finance3_NAS_volume protected

svm_finance finance4_CIFS_volume protected

svm_finance svm_finance_root unprotected


7. To remove a volume from mirroring considerations, set the vserver-dr-

protection flag to unprotected.

8. From the clustershell on cluster1, enter the following command to remove the two volumes from

mirroring consideration:

cluster1::> volume modify -vserver svm_finance -volume

finance3_NAS_volume,finance4_CIFS_volume -vserver-dr-protection

unprotected

Sample output:

Volume modify successful on volume finance3_NAS_volume of Vserver svm_finance.

Volume modify successful on volume finance4_CIFS_volume of Vserver svm_finance.

2 entries were modified.

9. From the clustershell on cluster2, enter the following command to initialize the SnapMirror

relationship:

cluster2::> snapmirror initialize -destination-path svm_finance_dr:

10. Enter the following command to review the progress of the SVM SnapMirror relationship

transfer:

cluster2::> snapmirror show -expand

Sample output:

Progress



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

svm_finance: DP svm_finance_dr: Uninitialized Transferring - true -




STEP ACTION

11. Continue to check the status until the state changes to Snapmirrored:

cluster2::> snapmirror show -expand

Sample output:

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 -


12. 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.

13. The snapmirror show –expand command shows the SnapMirror relationships

between SVMs as well as volumes of SVMs, but you can only act upon the SnapMirror

relationship at the SVM level.

14. Enter the following command to examine the name of the Snapshot copy that was created for the

SVM SnapMirror transfer:

cluster2::> snapmirror show -vserver svm_finance_dr -fields

newest-snapshot,state

Sample output:

source-path destination-path state newest-snapshot

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

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

svm_finance: svm_finance_dr: Snapmirrored vserverdr.0.2e8f81ef-2d04-11e6-b4e2-

0050568530a5.2016-06-07_160903

15. The names of Snapshot copies for a SVM SnapMirror relationship start with vserverdr.

16. Enter the following command to examine the namespace of the svm_finance_dr SVM:

cluster2::> volume show -vserver svm_finance_dr -fields junction-path,

policy

Sample output:

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 /





STEP ACTION

17. Enter the following command to examine the export-policy rules of the svm_finance_dr SVM:

cluster2::> vserver export-policy rule show -vserver svm_finance_dr

Sample output:

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


18. Enter the following command to examine the SMB shares of the svm_finance_dr SVM:

cluster2::> vserver cifs share show -vserver svm_finance_dr

Sample output:

Vserver Share Path Properties Comment ACL

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

svm_finance_dr admin$ / browsable - -

svm_finance_dr c$ / oplocks - BUILTIN\Administrators

/ Full Control

browsable

changenotify

show-previous-versions

svm_finance_dr finance1 /finance1_CIFS_ oplocks - Everyone / Full Control

volume browsable

changenotify

show-previous-versions

svm_finance_dr ipc$ / browsable - -


19. Enter the following command to examine the data LIF of the svm_finance_dr SVM:

cluster2::> network interface show -vserver svm_finance_dr

Sample output:

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.62/24 cluster2-01 e0c true

20. The data LIF should have the same IP address and net mask as the svm_finance SVM

on the primary cluster (task 1, step 13). 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

21. 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.




TASK 6: FAILOVER TO THE DISASTER-RECOVERY SVM

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.

STEP ACTION



on.

2. From the clustershell on cluster2, enter the following command to quiesce SnapMirror tranfers:

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

3. Enter the following command to verify that the SnapMirror was quiesced:


Sample output:

Progress



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

svm_finance: DP svm_finance_dr: Snapmirrored Quiesced - true -

4. Enter the following command to break the SnapMirror relationship before activating the disaster

recovery SVM:

cluster2::> snapmirror break -destination-path svm_finance_dr:

5. Enter the following command to verify that the SnapMirror relationship is in the Broken-off

state:


Sample output:

Progress



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

svm_finance: DP svm_finance_dr: Broken-off Idle - true -




STEP ACTION

6. From the clustershell on cluster1, stop the source SVM:

cluster1::> vserver stop -vserver svm_finance

Sample output:


7. 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.

8. Enter the following command to verify that the SVM stopped:

cluster1::> vserver show -vserver svm_finance

Sample output:

Vserver: svm_finance

Vserver Type: data

Vserver Subtype: default

Vserver UUID: 7c443e57-2c27-11e6-8ef4-

005056854720

Root Volume: svm_finance_root

Aggregate: n1_aggr_main

NIS Domain: -

Root Volume Security Style: unix

LDAP Client: -


Snapshot Policy: default

Comment:




Vserver Admin State: stopped


Vserver Operational State Stopped Reason: admin-state-stopped

Allowed Protocols: nfs, cifs

Disallowed Protocols: fcp, iscsi, ndmp


QoS Policy Group: -


Config Lock: false






STEP ACTION

9. From the clustershell on cluster2, enter the following command to active the disaster-recovery

SVM:

cluster2::> vserver start -vserver svm_finance_dr

Sample output:


10. Enter the following command to verify that the SVM started:


Sample output:


Vserver Type: data



0050568530a5


Aggregate: n1_aggr_raid_tec

NIS Domain: -


LDAP Client: -


Snapshot Policy: default-DR

Comment:




Vserver Admin State: running

Vserver Operational State: running

Vserver Operational State Stopped Reason: -




QoS Policy Group: -


Config Lock: false



11. 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.




STEP ACTION

12. NFS clients require an unmount and remount to access the volumes from the disaster-

recovery SVM.




login as: root

Password: Netapp123


16. Enter the following command to change directory to /mnt:

[root@centos65 ~]# cd /mnt

17. Enter the following command to unmount the NFS volume:

[root@centos65 mnt]# umount -f 192.168.0.62:/finance2_NFS_volume

18. Enter the following command to remount the NFS volume:

[root@centos65 mnt]# mount 192.168.0.62:/finance2_NFS_volume

/mnt/finance2

19. Enter the following command to write to the finance2_NFS_volume:

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

20. Enter the following command to verify that you can write to the volume:

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

Sample output:

File_240M nfs_test_file




TASK 7: 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.

STEP ACTION

1. From the clustershell on cluster1, verify that the cluster peer relationship is healthy:


Sample output:


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


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. Enter the following command to verify that the SMVs are still peered:


Sample output:



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

svm_finance svm_finance_dr peered cluster2 snapmirror svm_finance_dr

4. Enter the following command to create a reverse SnapMirror relationship so that the primary

SVM becomes the destination and the disaster-recovery SVM becomes the source:

cluster1::> snapmirror create -source-path svm_finance_dr:

-destination-path svm_finance: -type DP -throttle unlimited -policy

DPDefault -schedule hourly -identity-preserve true




STEP ACTION

5. Enter the following command to verify that the SnapMirror relationship was created. Note that the

state is Broken-off:

cluster1::> snapmirror show -vserver svm_finance

Sample output:

Progress



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

svm_finance_dr: DP svm_finance: Broken-off Idle - true -

6. Enter the following command to resynchronize all changes (configuration and data) that have

occurred on the disaster-recovery SVM since it became the active SVM:

cluster1::> snapmirror resync svm_finance:

7. Enter the following command to verify that the SnapMirror resynchronization has completed:


Sample output:

Progress



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

svm_finance_dr: DP svm_finance: Snapmirrored Idle - true -

8. 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 8: 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.

STEP ACTION



on.

2. 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.

3. A normal system administration change might be an update to the security of the system. From

the clustershell on cluster2, enter the following command to simulate such a change, lock down

NFS client access to allow only the client IP address for linux2 to access the finance2 NFS

volume:

cluster2::> vserver export-policy rule modify -vserver svm_finance_dr

-policyname finance2 -ruleindex 1 -clientmatch 192.168.0.22

4. From the command line of linux1, verify that you can no longer access the finance2 folder:

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

Sample output:

-bash: cd: /mnt/finance2: Permission denied






STEP ACTION


login as: root

Password: Netapp123


8. Enter the following command to create a new directory to mount the NFS volume under /mnt:

[root@centos65 ~]# mkdir /mnt/finance2

9. Enter the following command to mount the NFS volume:

[root@centos65 ~]# mount 192.168.0.62:/finance2_NFS_volume /mnt/finance2

10. Enter the following command to write to the finance2_NFS_volume:

[root@centos65 ~]# touch /mnt/finance2/test_new_security_file

11. Enter the following command to verify that you can write to the volume:

[root@centos65 ~]# ls /mnt/finance2

Sample output:

File_240M nfs_test_file test_new_security_file

12. 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 cluster2, stop the disaster-

recovery SVM:

cluster2::> vserver stop -vserver svm_finance_dr

Sample output:





STEP ACTION

13. Enter the following command to verify that the SVM is stopped:


Sample output:


Vserver Type: data



0050568530a5


Aggregate: n1_aggr_raid_tec

NIS Domain: -


LDAP Client: -


Snapshot Policy: default-DR

Comment:




Vserver Admin State: stopped


Vserver Operational State Stopped Reason: admin-state-stopped




QoS Policy Group: -


Config Lock: false



14. From the clustershell on cluster1, enter the following command to make one last update to transfer

all of the most recent data changes and configuration changes to the primary SVM:

cluster1::> snapmirror update -destination-path svm_finance:




STEP ACTION

15. Enter the following command to verify that the SnapMirror update has completed:


Sample output:

Progress



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

svm_finance_dr: DP svm_finance: Snapmirrored Idle - true -

16. Enter the following command to break the SnapMirror relationship:

cluster1::> snapmirror break -destination-path svm_finance:

17. Enter the following command to verify that the SnapMirror relationship is in the Broken-off

state:


Sample output:

Progress



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

svm_finance_dr: DP svm_finance: Broken-off Idle - true -

18. In order to restore the original relationship, enter the following command to delete the SnapMirror

relationship:

cluster1::> snapmirror delete -destination-path svm_finance:

19. Enter the following command to verify that the SnapMirror relationship was removed:


Sample output:

There are no entries matching your query.

20. Enter the following command to restart the primary SVM:

cluster1::> vserver start -vserver svm_finance

Sample output:


21. On the Windows Server machine verify the SMB access, open File Explorer and navigate to the

F: drive.




STEP ACTION

22. Verify that the file File_500M exists.

23. 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 6, 7, and 8). The new client mask

should be 192.168.0.22.

24. From the clustershell on cluster2, enter the following command to verify that the original

SnapMirror relationship exists and is in the Broken-off state:


Sample output:

Progress



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

svm_finance: DP svm_finance_dr: Broken-off Idle - true -

25. Enter the following command to resynchronize the SnapMirror relationship:

cluster2::> snapmirror resync -destination-path svm_finance_dr:

26. Enter the following command to verify that the SnapMirror resynchronization has completed:


Sample output:

Progress



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

svm_finance: DP svm_finance_dr: Snapmirrored Idle - true -

27. 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.

END OF EXERCISE


EA-1 ONTAP Administration: What’s New in ONTAP 9.0: Answers


NETAPP UNIVERSITY

ONTAP Administration: What’s New in ONTAP 9.0 Appendix A: Answers

Course ID: STRSW-ILT-ADMIN90 (STRSW-SPL-ADM9LAB) Catalog Number: STRSW-ILT-ADMIN90-EG Content Version: 1.0




MODULE 2: MANAGEMENT SOFTWARE ENHANCEMENTS

EXERCISE 2: ONCOMMAND SYSTEM MANAGER WALKTHROUGH

TASK 1: NAVIGATING NETAPP ONCOMMAND SYSTEM MANAGER

STEP ACTION

4. How many disks are available in the cluster? How many of the available disks are SSDs?

_84 total disks available, and 28 of them are

SSDs_____________________________________________________________________________

5. Did you click both tabs in the Dashboard view? What information is presented in the Cluster

Performance tab?

_Throughput in MBps, IOPS in Ops/s, and Latency in

ms/op_____________________________________________________________________________

9. Is there a LUNs tab on the command bar? If not, why?

_No, the LUNs tab is only present if one of the SAN protocols is

licensed._____________________________________________________________________________

14. Where can you find the date of the most recent Snapshot copy for volume finance2_NFS_volume?

_Navigate to the Volumes tab on the svm_finance SVM command bar, select the

finance2_NFS_volume and click the Snapshot Copies tab on the bottom of the screen (not the

Snapshot Copies pulldown menu on the command bar). The most recent Snapshot copy is listed first by

default._____________________________________________________________________________

END OF EXERCISE




MODULE 5: DATA AVAILABILITY AND PROTECTION ENHANCEMENTS

EXERCISE 1: CONFIGURING SNAPLOCK FOR FILE RETENTION

TASK 4: MANAGE SNAPLOCK ENTERPRISE VOLUME

STEP ACTION

20. What are your results when you try to edit the document in Windows Notepad?

_In Windows Notepad, the document appears to save but the new text is not there when you reopen the

document._____________________________________________________________________________

21. Try to edit the document in Windows WordPad, are the results any different?

_In Windows WordPad, the document cannot be saved under the same name. A message appears when

attempting to save with the same name “This file os set to read-only. Try again with a different file

name._____________________________________________________________________________

TASK 5: MANAGE SNAPLOCK COMPLIANCE VOLUME

STEP ACTION

21. Open up the document. Did the update get saved?

_No_____________________________________________________________________________

END OF EXERCISE




EXERCISE 3: MANAGING RAID-TEC AGGREGATES

TASK 3: VERIFY THE OPERABILITY OF A DEGRADED RAID-TEC AGGREGATE

STEP ACTION

8. What would happen if you try to fail data disk NET-1.49?

_Error: command failed: Failed to fail the disk. Reason: Raid group

degraded.________________________________________________________________________

_____

END OF EXERCISE


Documents

ONTAP Administration: What's New in ONTAP 9 - NetApp · PDF fileNETAPP UNIVERSITY ONTAP Administration: What’s New in ONTAP 9.0 Exercise Guide Course ID: STRSW-ILT-ADMIN90 (STRSW-SPL-ADM9LAB)