Data ONTAP 7.3 Fundamentals Student Guide

NetApp University
Data ONTAP 7.3 Fundamentals

Student Guide
NetApp University - Do Not Distribute

NETAPP UNIVERSITY
Data ONTAP® 7.3 Fundamentals

Student Guide
Version Number: 5.0
Release Number: Data ONTAP 7.3
Course Number: STRSW-ED-ILT-DOTF-REV05
Course Number: STRSW-ED-ILT-DOTF-REV05-SG

ATTENTION
The information contained in this guide is intended for training use only. This guide 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 and therefore are not intended as a reference
guide. This guide is not a technical reference and should not, under any circumstances, be used in
production environments. To obtain reference materials, please refer to the NetApp product
documentation located at www.now.com for product information.
COPYRIGHT
© 2008 NetApp. All rights reserved. Printed in the U.S.A. Specifications subject to change
without notice.
No part of this book 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 the copyright owner.
NetApp reserves the right to change any products described herein at any time and without notice.
NetApp assumes no responsibility or liability arising from the use of products or materials described
herein, except as expressly agreed to in writing by NetApp. The use or purchase of this product or
materials does not convey a license under any patent rights, trademark rights, or any other intellectual
property rights of NetApp.
The product described in this manual may be protected by one or more U.S. patents, foreign patents,
or pending applications.
RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph
(c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7103
(October 1988) and FAR 52-227-19 (June 1987).
TRADEMARK INFORMATION
NetApp, the NetApp logo, and Go further, faster, FAServer, NearStore, NetCache, WAFL, DataFabric,
FilerView, SecureShare, SnapManager, SnapMirror, SnapRestore, SnapVault, Spinnaker Networks,
the Spinnaker Networks logo, SpinAccess, SpinCluster, SpinFS, SpinHA, SpinMove, SpinServer, and
SpinStor are registered trademarks of Network Appliance, Inc. in the United States and other countries.
Network Appliance, Data ONTAP, ApplianceWatch, BareMetal, Center-to-Edge, ContentDirector, gFiler,
MultiStore, SecureAdmin, Smart SAN, SnapCache, SnapDrive, SnapMover, Snapshot, vFiler, Web
Filer, SpinAV, SpinManager, SpinMirror, and SpinShot are trademarks of NetApp, Inc. in the United
States and/or other countries.
Apple is a registered trademark and QuickTime is a trademark of Apple Computer, Inc. in the United
States and/or other countries.
Microsoft is a registered trademark and Windows Media is a trademark of Microsoft Corporation in the
United States and/or other countries.
RealAudio, RealNetworks, RealPlayer, RealSystem, RealText, and RealVideo are registered
trademarks and RealMedia, RealProxy, and SureStream are trademarks of RealNetworks, Inc. in the
United States and/or other countries.
All other brands or products are trademarks or registered trademarks of their respective holders and
should be treated as such.
NetApp is a licensee of the CompactFlash and CF Logo trademarks.
2 Data ONTAP® 7.3 Fundamentals: Welcome
© 2008 NetApp. This material is intended for training use only. Not authorized for reproduction purposes.
TABLE OF CONTENTS
WELCOME ............................................................................................................................1
MODULE 1: OVERVIEW ......................................................................................................1-1
MODULE 2: INSTALLATION AND CONFIGURATION ......................................................2-1
MODULE 3: BASIC ADMINISTRATION .............................................................................3-1
MODULE 4: ADMINISTRATION SECURITY ......................................................................4-1
MODULE 5: NETWORKING ................................................................................................5-1
MODULE 6: PHYSICAL STORAGE MANAGEMEN ...........................................................6-1
MODULE 7: LOGICAL STORAGE MANAGEMENT ...........................................................7-1
MODULE 8: CIFS .................................................................................................................8-1
MODULE 9: NFS ...................................................................................................................9-1
MODULE 10: QTREES AND SECURITY STYLE ..............................................................10-1
MODULE 11: SAN ...............................................................................................................11-1
MODULE 12: SNAPSHOT COPIES ...................................................................................12-1
MODULE 13: WRITE AND READ REQUEST PROCESSING............................................13-1
MODULE 14: SYSTEM DATA COLLECTION ....................................................................14-1
MODULE 15: FLEXSHARE ................................................................................................15-1
MODULE 16: NDMP FUNDAMENTALS ............................................................................16-1
MODULE 17: ACTIVE-ACTIVE CONTROLLER CONFIGURATION .................................17-1
MODULE 18: FINAL WORDS .............................................................................................18-1
This page is intentionally left blank.
Welcome

Data ONTAP® 7.3
Fundamentals
Release#: Data ONTAP 7.3
Course Part#: STRSW-ED-ILT-
DOTF-REV05
DATA ONTAP® 7.3 FUNDAMENTALS
Logistics
Introductions
Schedule (start time, breaks, lunch, close)
Telephones and messages
Food and drinks
Restrooms
© 2008 NetApp. All rights reserved. 2
LOGISTICS
Safety
Alarm signal
Evacuation route
Assembly area
Electrical safety
SAFETY
Course Objectives
By the end of this course, you should be able to:

List and describe types of storage systems (enterprise,
virtualized, nearline, and high-performance computing)
Use the NOW™ (NetApp on the Web) knowledge base
to resolve technical issues
Describe the Data ONTAP® operating system
Identify client-server and multi-tiered storage systems
Manage and configure system interfaces
Identify and use naming services
Use a storage system console to access and execute
commands
COURSE OBJECTIVES
Course Objectives (Cont.)
Explain features of the WAFL® (Write Anywhere File

Layout) file system
Identify and manage Snapshot™ copies
Create and manage aggregates, volumes, and disks
Configure and manage Network File System (NFS)
exports
Setup and manage Common Internet File System
protocol (CIFS) shares
Describe storage area network (SAN) features in Data
ONTAP
Identify techniques to collect performance data for a
storage system
COURSE OBJECTIVES (CONT.)
Course Agenda
Day 1
– Data ONTAP Fundamentals
– Installation and Configuration
– Basic Administration
Day 2
– Administration Security
– Networking
– Physical Storage Management
COURSE AGENDA
Course Agenda (Cont.)
Day 3
– Logical Storage Management
– Common Internet File System
– Network File System
– Qtrees and Security Styles
Day 4
– Storage Area Networks
– Snapshot Copies
– Write and Read Request Processing
– System Data Collection
COURSE AGENDA (CONT.)
Course Agenda (Cont.)
Day 5
– FlexShare™
– Active-Active Controller Configuration
– NDMP Fundamentals
– Final Words
COURSE AGENDA (CONT.)
Information Sources
NOWTM (NetApp on the Web) Site

– http://NOW.NetApp.com
NetApp University
– http://www.netapp.com/us/services/university/
NetApp University Support

– http://netappusupport.custhelp.com
INFORMATION SOURCES
Typographic Conventions
Convention Type of Information
Book titles
Word or characters that require special attention
Variable names or placeholders for information you
must supply, for example:
Italic Font
Enter the following command:
ifstat [-z] {-a interface}
Interface is the name of the interface for which
you want to view statistics.
Command names, daemon names, and option

names
Monospaced font Information displayed on the system console or
other computer monitors
The contents of files
Words or characters you type, for example:
Bold monospaced font Enter the following command:
options httpd.enable on
TYPOGRAPHIC CONVENTIONS

©© 2008
2008 Network
NetApp. Appliance, Inc.isAll
This material rights reserved.
intended Specifications
for training use only. Notare subject tofor
authorized change without purposes.
reproduction notice. NetApp, the Network Appliance logo,

NearStore, SnapLock, and SnapVault are registered trademarks and Network Appliance, DataFort, FlexClone, and FlexVol are trademarks of
Network Appliance, Inc. in the U.S. and/or other countries. Windows is a registered trademark of Microsoft Corporation. UNIX is a registered
trademark of The Open Group. Oracle is a registered trademark of Oracle Corporation. All other brands or products are trademarks or registered
trademarks of their respective holders and should be treated as such.
Overview

MODULE 1: DATA ONTAP FUNDAMENTALS
Overview
Module 1
OVERVIEW
1-1 Data ONTAP® 7.3 Fundamentals: Overview
Module Objectives
By the end of this module, you should be able to:

State the advantages, features, and functions
of a storage system
Identify the key features of NetApp® product
series
Distinguish between SAN and NAS topologies
Describe the basic functions of the Data
ONTAP operating system
Access the NOW™ (NetApp on the Web)
knowledge base to obtain software and
hardware documentation
MODULE OBJECTIVES
Products
PRODUCTS
Storage System
The primary function of a storage system is to

store data.
NetApp™ enterprise storage systems function
as "unification engines" that simultaneously
support FC and IP SANs, and NAS.
STORAGE SYSTEM
STORAGE-SYSTEM ARCHITECTURES
The primary function of a storage system is to store data. NetApp storage systems have
integrated disks that store data in a variety of network and storage environments including
SAN and NAS
The two main protocols used in SAN are Fibre Channel Protocol (FCP) and Internet Small
Computer System Interface (iSCSI). The two main protocols used in NAS are Network File
System (NFS) and Common Internet File System (CIFS). NetApp storage systems use the
Data ONTAP operating system to ensure simple operation, speed, and reliability.
Unified Storage
iSCSI NFS
CIFS Corporate
FC Ethernet LAN
SAN NAS
(Blocks) (Files)
NetApp
FAS
UNIFIED STORAGE
SAN
• Is a block-based storage system
• Makes data available over the network
• Uses FC and iSCSI protocols
NAS
• Is a file-based storage system
• Makes data available over the network
• Uses NFS and CIFS protocols
The NetApp SAN and unified storage architecture provides an outstanding level of
investment protection and flexibility. The fabric attached storage (FAS) system at the bottom
implies one “box” However, the actual storage environment includes small and large FAS
systems, and NearStore® systems.
NetApp Data ONTAP 7G Products
Data Center Remote Office/ Near-line Storage
Storage Dept Storage Storage Virtualization
FAS3000 Series & FAS200 Series & NearStore® on FAS V-Series

FAS6000 Series FAS2000 Series Economical secondary Dynamic virtualization for
Unified, enterprise-class Remote and departmental storage heterogeneous storage
storage storage
Data ONTAP® 7G Operating System – NAS, FC SAN, IP SAN
Provisioning & Performance Data Data
Manageability
Volume Mgmt Management Protection Retention
• FlexClone® • FlexCache™ • MetroCluster • SnapLock ® • ApplianceWatch™ • Operations Manager
• FlexVol® • FlexShare™ • Open Systems • LockVault™ for MOM • Protection Manager
• MultiStore® SnapVault® • CommandCentral™ • Provisioning Manager
System • ReplicatorX™ Storage • SnapDrive®
Resiliency • SnapManager®
• File Storage
• Active-active
Management • SnapMirror®
• VFM® (Virtual File
Resource Manager
• controller • FilerView® • SnapRestore® Manager)
configuration • Snapshot™
• RAID-DP® • SnapVault Included at no additional cost
• SnapValidator®
Not restricted to Data ONTAP 7G environments
• SyncMirror®
NETAPP DATA ONTAP 7G PRODUCTS
NETAPP HARDWARE
NETAPP FAS
NetApp FAS systems comprise some of the largest families of compatible storage systems in
the storage industry today. NetApp FAS systems integrate easily into complex enterprise
environments and provide shared access to UNIX, Microsoft ® Windows®, Linux®, and
Web data while simultaneously supporting FC SAN, IP SAN, iSCSI, and NAS. FAS systems
are designed to consolidate and serve data for e-mail, Enterprise Content Management
(ECM), technical applications, files, home directories, and Web content.
NEARSTORE
NearStore is a near-line storage system that uses FC disk drives organized in disk shelves.
NearStore systems store data that requires faster access than tape storage, but requires less
activity than primary data. The product requires a software license to allow ATA and FC
disks on the same system. NearStore combines the Data ONTAP operating system with
inexpensive serial advanced technology attachment (SATA) disks to provide disk storage
performance and flexibility at near-tape storage costs.
V-SERIES SYSTEMS
V-Series systems are virtual storage systems for a multiprotocol, multivendor storage
environment. V-Series enables NAS and SAN simultaneous access to existing FC SAN
infrastructures.
NETAPP SOFTWARE
The NetApp manageability software family consists of four suites that provide software tools
for effective data management.
The NetApp Application Suite delivers increased productivity and flexibility across the
entire enterprise. The various NetApp SnapManager® software products enable you to
improve data availability, reduce unexpected data loss, and increase storage management
flexibility by leveraging the power of integrated NetApp storage systems.
The NetApp Server Suite includes the SnapDrive® and ApplianceWatch™ product families.
SnapDrive provides a server-aware alternative to maintaining manual host connections to
underlying NetApp storage systems. ApplianceWatch products integrate with third-party
system management tools from HP, IBM, and Microsoft. ApplianceWatch allows
administrators to view, monitor, and manage NetApp storage systems from within their
respective system-management environments.
The NetApp Data Suite, consisting of Protection Manager and VFM® (Virtual File Manager,
Enterprise Edition and Migration Edition), provides effective tools for abstracting storage and
enables administrators and users to think in terms of data and data management rather than
the underlying storage.
With the NetApp Storage Suite of products, including Operations Manager, File Storage
Resource Manager, SAN Manager, and Command Central Storage, you will be able to do
more with less. Instead of managing separate physical storage systems, you can view and
manage multiple devices from central consoles.
“Not restricted to Data ONTAP 7G environments” means:

• In the case of Open Systems SnapVault®, the agents run on systems that do not use the Data
ONTAP operating system (UNIX, Linux, or Windows systems). The agents communicate with a
SnapVault secondary which must run on a machine equipped with Data ONTAP 7G.
• ReplicatorX™ and VFM software executes on machines that are not running Data ONTAP 7G,
and can be sold into environments where not a single Data ONTAP 7G-based storage system has
been sold. They are identified here because combining them with storage systems equipped with
Data ONTAP and software that is based on Data ONTAP (for example, FlexClone®) can be quite
powerful.
NETAPP STORAGE SUITE:

NETAPP COMMANDCENTRAL STORAGE BY SYMANTEC
NetApp CommandCentral™ Storage (CCStorage) by Symantec® provides a centralized

operational console for delivering storage management services in large-scale, heterogeneous,
FC and iSCSI SAN environments. It complements the NetApp native storage management
technology and integrates storage resource management, performance and policy
management, provisioning, and SAN management capabilities. The efficient management of
heterogeneous SAN storage resources underpins service-level agreements, ensuring improved
performance and availability. In addition, CCStorage offers customizable, policy-based
management to automate notification, recovery, and other user-definable actions.
FILE STORAGE RESOURCE MANAGER
File Storage Resource Manager (FSRM) enables you to better understand the types of files in
your storage environment. Data is classified in terms of file size, file age, modification
history, access history, file type usage, and file owner usage. This data-classification
information gives you a clear picture of data within your organization. It allows you to put
policies in place that eliminate stale data, unused data, and data stored by personnel who are
no longer employed by your company.
FSRM also provides quota management. Administrators can set soft thresholds and hard
quotas. The system then issues policy violation notices. These FSRM features all contribute
to better storage utilization.

OPERATIONS MANAGER
NetApp Operations Manager (formerly DataFabric® Manager) delivers comprehensive

monitoring and management for NetApp enterprise-storage and content-caching
environments. From a central point of control, Operations Manager provides alerts, reports,
and configuration tools to keep your storage infrastructure in line with your business
requirements, for maximum availability and reduced total cost of ownership (TCO).
No other single management application provides the same level of NetApp monitoring and
management for NetApp FAS systems and NearStore near-line storage systems. The detailed
performance and health monitoring tools available through Operations Manager gives
administrators proactive information to help resolve potential problems before they occur,
and to troubleshoot problems faster when they do occur.
PROTECTION MANAGER
Protection Manager is an intuitive and innovative backup and replication-management

software package for NetApp disk-based data protection environments. Protection Manager
delivers greater assurance of data protection and higher productivity by providing policy-
based management (including automated data protection set up). This management
application allows you to apply consistent data protection policies across the enterprise,
automate complex data protection processes, and pool backup and replication resources for
higher utilization.
PROVISIONING MANAGER
Provisioning Manager provides automated, policy-based provisioning for NetApp NAS and
SAN environments. The software automates manual and repetitive provisioning processes,
increasing the productivity of administrators, and improves availability of data by providing
policy compliance for provisioned storage.
Provisioning Manager improves the productivity of storage administrators by automating

repetitive provisioning processes and allowing the delegation of provisioning activities to
others. This product also helps improve capacity utilization by leveraging flexible volumes
and intelligently provisioning storage from resource pools.
FAS2000 Series Overview
FAS2020 FAS2050
High-performance Serial-Attached SCSI (SAS) infrastructure
SAS or SATA drives configurable internally
Single controller or dual controller for high availability (HA)
Unified storage for iSCSI, NAS, FC SAN, FC tape, SCSI tape
Each controller has dual GigE ports and dual 4Gb FC ports
Onboard remote platform management
12 internal drive bays (2U) 20 internal drive bays (4U)

No PCIe slots 1 PCIe slot per controller
Up to 4 external shelves Up to 6 external shelves
FAS2000 SERIES OVERVIEW

The NetApp FAS2000 series systems support “internal” disk drive configurations. The
FAS2050 features 20 drives in a 4U chassis and provides flexibility with PCIe expansion
slots. The SAN-attached storage provides the same high performance and quality as FC
drives, but the interface also supports lower-cost SATA drives.
You can use the FAS2000 series to manage your dispersed, expanding, and complex data
requirements, and leverage the common operating system, management tools, backup and
restore functions, and disaster-recovery solutions to support your special business needs. The
FAS2000 series also helps reduce system costs with high data availability and less downtime
costs.
The FAS3000 Series features:
A modular system with integrated I/O
– Eight 4Gb FC and eight GbE on
board
– Meets the needs of most
configurations
– Occupies six rack units (RU)
Superior scalability
– Up to 504 TB storage capacity
– Up to 504 FC or SATA spindles
– Six PCI slots
– Up to 32 FC ports
– Up to 32 GbE ports
Built-in, enterprise-class manageability
with enhanced capabilities through RLM

The above summary assumes active-active, failover configuration for FAS3000 Series
systems.
Use the FAS3000 to manage up to twice as much data. The FAS3000 can use the Data
ONTAP FlexShare™ software to dynamically adjust workload priorities so that important
applications always get a fast response. Other key benefits include:
• A single platform to satisfy multiple requirements for SAN, NAS, primary storage, and secondary
storage
• Consistent, stable performance when creating Snapshot copies
• Easy upgrades and expansion within the FAS3000 family, and to the high-end FAS6000 family
Storage capacity for the FAS3000 is dependent on the number of spindles and the per-disk
storage density. The 504 TB maximum capacity assumes 504 SATA drives (with 1 TB each).
Enhanced manageability is achieved through the addition of the optional Remote LAN
Module (RLM). Some of the key features offered by RLM include failure alert through e-mail
notifications, real-time monitor and event logging, console redirection, and remote power-
cycling.
The FAS6000 Series features:
A modular system with integrated I/O
– Sixteen 4Gb FC* and twelve GbE
onboard***
– Occupies twelve RU***
Superior scalability
– Up to 1176 TB storage capacity**
– Up to 1176 FC or SATA spindles**
– Up to 56 FC ports***
– Up to 52 GbE ports***
Built-in, enterprise-class manageability
with enhanced capabilities through RLM
* Available on FAS6040 and FAS6080

** Requires Data ONTAP 7.2.4 or higher
***Enterprise active-active configuration

The FAS6000 series is designed for the largest enterprise applications and demanding
technical applications. Because they are highly scalable and very flexible, the FAS6000
systems are ideally suited for storage consolidation supporting hundreds of applications.
Data can be stored either in file or block format. Supported protocols include FCP, NFS,
CIFS, HTTP, and iSCSI.
Shelf Compatibility
DS14 DS14mk2 DS14mk4 R100/R150 DS14mk2-AT

Grey Color Grey Color Black Color ATA Shelf Black Color
FAS6000
9 9 9 9
FAS3000
9 9 9 9
FAS2000
9 9 9 9
R200
9 9
FAS2XX
9 9
SHELF COMPATIBILITY
DISK SHELVES
NetApp storage systems use disk shelves as an alternative to sequential-access tape drives.
Each storage system has several FC ports at the rear of the system where you can attach disk
shelves. The number of ports varies by storage system.
NAS Versus SAN
NAS VERSUS SAN
NAS Versus SAN Topology
iSCSI NFS
CIFS Corporate
FC Ethernet LAN
SAN NAS
(Blocks) (Files)
NetApp
FAS
NAS VERSUS SAN TOPOLOGY

NAS, which is file-based, was initially designed for data sharing in a LAN environment and
incorporates file system capabilities into the storage device. In a NAS environment, servers
are connected to a storage system through a standard Ethernet network and use standard file
access protocols such as NFS and CIFS to make storage requests. Local file system calls from
clients are redirected to the NAS device, which provides shared file storage for all clients. If
clients are desktop systems, the NAS device provides "serverless" file serving. If clients are
server systems, the NAS device offloads the data management overhead from the servers.
SAN, which is block-based, lowers TCO and increases the performance and availability of
corporate storage resources. Because of these benefits, SANs that are based on FC technology
have become standard in many corporate data centers.
NetApp IP SAN (iSCSI) encapsulates SCSI block-storage commands into Ethernet packets
for transport over IP networks, enabling companies to leverage standard, familiar Ethernet
networking infrastructures to create affordable SANs.
Data ONTAP Supported Protocols
Data ONTAP supports

the following protocols:
NAS NFS
– NFS
CIFS
– CIFS
– FTP iSCSI
– HTTP
– WebDAV LAN (TCP/IP)
SAN
– FCP FCP Data
ONTAP
– iSCSI Platform
FC
DATA ONTAP SUPPORTED PROTOCOLS

NFS: The NFS protocol allows UNIX and PC NFS clients to mount file systems to local
mount points. The storage appliance supports NFS v2, NFS v3, NFS v4, and NFS over User
Datagram Protocol (UDP) and transmission control protocol (TCP).
CIFS: The CIFS protocol supports Windows 2000, Windows for Workgroups, and Windows
NT 4.0.
HTTP: The HTTP enables Web browsers to display files that are stored on the storage
appliance.
FTP: The FTP enables UNIX clients to remotely transfer files to and from the storage
appliance.
WebDAV: Web-based Distributed Authoring and Versioning (WebDAV) enables certain

applications to create, modify, and access files over HTTP-extended methods.
FCP or iSCSI: The FCP or iSCSI protocols enable a storage device to communicate with one
or more hosts running operating systems such as Solaris™ or Windows in a SAN
environment. You can also configure logical units of storage (LUNs) for multiprotocol
access, block access, or as files for file access (or both).
Architecture
ARCHITECTURE
Data ONTAP Architecture
Client Data ONTAP
Network
Client
Network Protocols WAFL® RAID Storage

Client
Client
NVRAM
Physical Disks
Memory
Client
DATA ONTAP ARCHITECTURE

Data ONTAP is the operating system that all NetApp storage systems use and consists of:
• Network Interface: The point of interconnection between a user terminal network. The network
layer delivers data to RAM through the simple kernel and some libraries.
• Protocol Stack: The protocol stack takes the data placed into RAM by the network layer to
process further. Processing is based on protocols (CIFS, NFS, FCP, iSCSI, FTP, HTTP).
• Write Anywhere File Layout (WAFL): WAFL is an intelligent file system that actively
optimizes write performance by identifying the most effective way to lay out data on the disk.
• RAID Layer: Provides RAID 4 and RAID-DP™ protection by taking the data processed by
WAFL. The RAID layer creates stripes used to calculate parity. The RAID layer also protects data
by performing RAID scrubs and assists in the reconstruction of failed disks.
• Storage: Manages data transfer to and from disks. The storage layer is responsible for writing to
the disks. According to the data delivered by WAFL and RAID, it optimizes the write process to
the disks.
• Nonvolatile Random Access Memory (NVRAM): NVRAM is the battery backup of all
incoming write requests. All transactions that change the state of the file system are processed in
system RAM and logged in NVRAM. Write requests are acknowledged when the request is stored
in both system RAM and NVRAM. Because writes are processed in system RAM, NVRAM
provides battery-backed protection against data loss only in emergency situations. NVRAM is read
only after an improper shutdown, most often due to an emergency loss of power.
NetApp on the Web
NetApp on the Web (NOW) is the NetApp online

support and services Web site.
NETAPP ON THE WEB
NETAPP ON THE WEB (NOW) SITE
The NOW knowledge database provides a source for support, information, and
documentation. NOW is a NetApp customer- and employee-driven knowledge base
accessible at either:
http://www.netapp.com
or
http://now.netapp.com
After you have logged into the NOW database, the Service and Support page is displayed.
From this page, you can access the following administrative support:
• Technical Assistance
• Submit or check the status of a technical assistance case
• Submit or check the status of a Return Materials Authorization (RMA)
• Find bug reports
• Documentation
• Downloads
• Your product information
• Troubleshooting solutions
Simulate ONTAP Benefits
Simulate ONTAP™ provides the following

benefits:
Simulates the experience of administering a
NetApp storage system with all features
available
Allows administrators to:
– Experiment with new features (simulator runs
with a full set of licenses)
– Practice procedures in a non-production
environment
– Experiment with new versions of Data ONTAP
SIMULATE DATA ONTAP BENEFITS

The Data ONTAP Simulator for Linux provides you with the experience of administering a
NetApp storage system―complete with a "simulated" set of populated disks―with all the
features of Data ONTAP at your disposal.
NOTE: Support for the Data ONTAP Simulator is on a best-effort volunteer basis; therefore,
support is not guaranteed. Please do not call the Global Support Centers for Simulator support
issues.
SIMULATOR REQUIREMENTS
• Hardware
Intel® processor-based PC
Network card
Recommended 256 MB main memory
Minimum 250 MB free hard drive space
• Linux installed, running, and networked
• Tested on Red Hat® Linux 7.1 through 9.0, SUSE 8.1, and 8.2
• Must log in as root for installation
Summary
In this module, you should have learned to:

State the advantages, features, and functions
of a storage system
Identify the key features of NetApp product
series
Distinguish between SAN and NAS topologies
Describe the basic functions of the Data
ONTAP operating system
Access the NOW knowledge base to obtain
software and hardware documentation
MODULE SUMMARY
Exercise
Module 1: Data ONTAP
Fundamentals
Estimated Time: 45 minutes
EXERCISE
Please refer to your Exercise Guide for more instruction.
Install Config

MODULE 2: INSTALLATION AND CONFIGURATION
Installation and
Configuration
Module 2
INSTALLATION AND CONFIGURATION
2-1 Data ONTAP® 7.3 Fundamentals: Installation and Configuration
Module Objectives
Access the NOW site for the following documents:
– NetApp Configuration Guide
– Data ONTAP System Administration Guide
Locate hardware components using Parts Finder
Collect data for installation using a configuration
worksheet
Interpret the network interface configuration
Set up console access for a storage system
Configure a storage system using the setup
command
Describe how to perform Data ONTAP software
upgrades and reboots
MODULE OBJECTIVES
Documentation
DOCUMENTATION
NOW Support
NOW is an online support and services Web site

that provides:
Product support through knowledge base
Documentation
– Parts Finder
– Data ONTAP guides
System Administration Guide
Software Setup Guide
– Configuration Guide
– Configuration Worksheet
NOW SUPPORT
PRODUCT DOCUMENTATION
Product documentation and additional information about your new storage system is available
online on the NOW site at http://now.netapp.com. From the NOW site, you can view a list of
all licenses purchased for your storage appliance.
ADDITIONAL INFORMATION
For the latest information about your version of Data ONTAP, see the Data ONTAP Release
Notes and Read Me First documents.
SOFTWARE
The system software is preinstalled, you don’t need CD’s or system boot diskettes to install or
configure a new storage system. If for any reason you need to reinstall the system software,
you can access to the NOW site.
Parts Finder
PARTS FINDER
The Parts Finder Web site allows you to search the parts database for spare parts and view
details about the part. There are currently three methods to search for a part:
• By part number
• By the description provided in the sysconfig output
• By category
System Administration Guide
SYSTEM ADMINISTRATION GUIDE
The System Administration Guide describes how to configure, operate, and manage NetApp
storage systems running Data ONTAP 7.3 software. This guide provides information about
all storage system models.
Software Setup Guide
SOFTWARE SETUP GUIDE
The Software Setup Guide describes how to set up and configure storage systems running
Data ONTAP 7.3 software. This guide provides information about all supported storage
system models.
System Configuration Guide
SYSTEM CONFIGURATION GUIDE
The System Configuration Guide Web site provides configuration information for all NetApp
storage systems running multiple versions of Data ONTAP. It also provides a table of
component compatibilities for both normal environments and high-availability configurations.
Console Access
CONSOLE ACCESS
Console Access
DB9-RJ45
Connection to
console port
Bits per second 9600

Data bits 8
Parity None
Stop bits 1
Flow control None
CONSOLE ACCESS
For console access, you can connect to a terminal (or terminal server) to the storage system
console port through a standard RS232 connection such as a DB9-to-DB9 serial cable (null
modem) with the following settings for the serial communication port:
• Bits per second: 9600
• Data bits: 8
• Parity: None
• Stop bits: 1
• Flow control: None
Console access can be password protected.

NOTE: For illustration purposes, the figure above shows a standard PC or laptop computer
connected to the storage system console. The adminhost then uses a terminal emulation
program to access the console session.
Console Access from a Terminal Server
RS-232
RS-232
RS-232
RS-232
Terminal
Server
TCP/IP Network
CONSOLE ACCESS FROM A TERMINAL SERVER
To avoid the sometimes difficult task of connecting several consoles in the lab you can
instead connect a terminal server. A terminal server is a specialized computer with several
console ports that allows administrators to access a storage system console through the
network, which is important when rebooting a system or for hardware debugging.
You can access the storage system from the console by using the IP address of the terminal
server with the port number for the storage system.
Storage System Administration Interfaces
Storage System
B. Telnet A. Console
RS-232
D. SSH
(secure shell)
C. Terminal
Server DOT
E. rsh CLI
NIC shell
(non-interactive)
F. FilerView
(Web-based; GUI)
Telnet
G. Operations Manager
(Web-based; GUI)
HTTP
STORAGE SYSTEM ADMINISTRATION INTERFACES
A. RS232 (console)―DOT shell

B. Telnet―Telnet service DOT shell
One at a time for either
Echo on other access (option to turn off)
NOTE: There should never be more than one Data ONTAP shell running at one time.
C. Terminal server―Connection to RS232 allows telnet access to RS232 port (equivalent to
console access)
D. SSH―Secure Shell
E. RSH―Remote Shell
F. FilerView® (HTTP)
G. Operations Manager (HTTP)
Data ONTAP Command Format
command subcommand –option argument
Example:
system> aggr create –traid-dp <aggrname>
NOTE: Refer to the Commands Manual for specific information.
DATA ONTAP COMMAND FORMAT
Command Levels
Level Prompt Command For
Administrative > Administration
Privilege *> Special tasks:
Troubleshooting
System tuning
Testing
Displaying statistics
COMMAND LEVELS
Data ONTAP provides two separate sets of commands based on privilege level, either
administrative or advanced. You can set the privilege level using the priv command.
The administrative level provides access to commands that are sufficient for managing your
storage system. The advanced level provides access to these same administrative commands
as well as additional troubleshooting commands.
Advanced level commands should only be used with the guidance of NetApp technical
support. When using Advanced level commands, the following warning is displayed:
“Warning: These advanced commands are potentially dangerous; use them only when
directed to do so by Network Appliance personnel.”
Changing Command Levels
priv set Command
Use the priv set command to change
command levels:
priv set level
Change to the advanced command level:
system> priv set advanced
system*>
Change to the administrative command level:
system> priv set admin
system>
CHANGING COMMAND LEVELS: PRIV SET COMMAND
The initial privilege level for the console and for each RSH session is Administrative. Use the
priv set command to change the privilege level. When you change to the advanced level,
the prompt includes an asterisk.
Viewing Manual (man) Pages From the CLI
To view a man page from the CLI:

system> man <command>
To view information about man pages:
system> help
To view a list of commands:
system> ?
NOTE: Data ONTAP commands are case-sensitive.
VIEWING MANUAL (MAN) PAGES FROM THE CLI
When using the command line interface (CLI), you can get CLI syntax help by entering the
name of the command followed by help or the question mark (?).
For a list of all commands available at the current privilege level (administrative or
advanced), at the CLI prompt, type the question mark (?).
Command References on
Data ONTAP FilerView Menu
COMMAND REFERENCES ON DATA ONTAP FILERVIEW MENU
FilerView is an HTTP/Web-based graphical management interface that enables you to

manage most storage system functions from a Web browser rather than entering commands at
the console through a telnet session, or using the rsh command, or by using scripts or
configuration files.
You can also use FilerView to view information about the storage system, its physical storage
units (such as adapters, disks, and RAID groups), and its data storage units (such as
aggregates, volumes, and LUNs). You can also use FilerView to view statistics about network
traffic.
FilerView is easy to use and provides access to online Help, which explains Data ONTAP
features and how to use them.
Reboot and Installation
REBOOT AND INSTALLATION
Halting a Storage System
Use the halt command to shut down a

storage system:
system> halt
system> halt –t [interval]
– Flushes all data from memory to disk
– Avoids potential data loss for clients
Use the reboot command to halt a system
and automatically reboot it:
system> reboot
system> reboot –t [interval]
HALTING A STORAGE SYSTEM
Use the halt command to perform an orderly shutdown that flushes file system updates to
disk and clears the NVRAM.
REASONS TO USE THE HALT COMMAND

The storage system stores requests in NVRAM. For the following reasons, always execute the
halt command before turning off the storage system:
• The halt command flushes all data from memory to disk, eliminating a potential point of failure.
• The halt command avoids potential data loss on CIFS clients.
If a CIFS client is disconnected from the storage system, the users' applications are terminated
and changes made to open files since the last save are lost.
IMPORTANT
Always warn CIFS users in advance when you halt the storage system. This gives users a
chance to save changes and avoid losing data when the CIFS service is interrupted.
NOTE: To properly display CIFS shutdown messages on clients running Windows 95 or

Windows for Workgroups, you must configure the WinPopup program to receive messages.
Clients running Windows NT and Windows XP automatically display messages from the
storage system and need no additional configuration.
USING THE REBOOT COMMAND
Using the reboot command is the same as halting and then booting the storage system.
During a reboot, the contents of the storage system NVRAM are flushed to disk and the
storage system sends a warning message to CIFS clients.
Boot Sequence
BOOT SEQUENCE
Boot Sequence
As the storage system boots, press Ctrl-C to

display the special boot menu on the console.
CFE version 1.2.0 based on Broadcom CFE: 1.0.35

Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
Portions Copyright (C) 2002,2003 Network Appliance Corporation.
CPU type 0x1040102: 600MHz

Total memory: 0x20000000 bytes (512MB)
Starting AUTOBOOT press any key to abort...

Loading: 0xffffffff80001000/8659992 Entry at 0xffffffff80001000
Starting program at 0xffffffff80001000
Press CTRL-C for special boot menu
.........................................
BOOT SEQUENCE
The special boot menu or maintenance menu (1-5 menu) is displayed either when a boot
variable is set or Ctrl-C is pressed during boot.
You can also enter one of the following boot options at the boot environment prompt:
• CFE> for FAS200, FAS3020, and FAS3050 systems
• LOADER> for FAS3040, FAS3070, and FAS6000 series systems
BOOT_ONTAP
The boot_ontap option boots the current Data ONTAP software release stored on the
CompactFlash card. By default, the storage system automatically boots this release if you do
not select another option from the basic menu.
BOOT_PRIMARY
The boot_primary option boots the Data ONTAP release stored on the CompactFlash card
as the primary kernel. This option overrides the firmware AUTOBOOT_FROM environment
variable if it is set to a value other than PRIMARY. By default, the boot_ontap and
boot_primary commands load the same kernel.
BOOT_BACKUP
The boot_backup option boots the backup Data ONTAP release from the CompactFlash
card. The backup release is created during the first software upgrade to preserve the kernel
that was preinstalled on the storage system. It provides a "known good" release from which
you can boot the storage system if it fails to automatically boot the primary image.
NETBOOT
The netboot option boots from a Data ONTAP version stored on a remote HTTP or TFTP
(Trivial File Transfer Protocol) server. The netboot option enables you to:
• Boot an alternative kernel if the CompactFlash card becomes damaged
• Upgrade the boot kernel for several devices from a single server
To enable netboot, you must configure networking for the storage system (using Dynamic
Host Configuration Protocol or static IP address) and place the boot image on a configured
server.
Accessing the Flash Boot Commands
As the storage system boots, the special boot

menu allows you to control the booting
sequence.
Special boot options menu will be available.
NetApp Release 7.3RC1: Wed Mar 5 02:17:31 PST 2008

Copyright (c) 1992-2008 Network Appliance, Inc.
Starting boot on Fri May 16 19:50:18 GMT 2008
(1) Normal boot.

(2) Boot without /etc/rc.
(3) Change password.
(4) Initialize all disks.
(4a)Same as option 4, but create a flexible root volume.
(5) Maintenance mode boot.
Selection (1-5)?
ACCESSING THE FLASH BOOT COMMANDS
The menu choices available from the special boot menu allow you to continue booting the
storage appliance under normal or special conditions.
Menu selections 2 and 5 are used for troubleshooting. Selections 4 (or 4a) are usually
performed at the beginning of a system installation. To choose a selection on the command
line, enter the option number.
SPECIAL BOOT MENU OPTIONS
Menu Option Function
(1) Normal boot. This option allows the system to boot as normal.
(2) Boot without /etc/rc. This option performs a normal boot, but bypasses execution of the
etc/rc file. Following this boot, the system runs normally, but without
the configuration normally provided to it by the etc/rc file and system
daemons. To make the system fully operational, you can enter the
commands in the etc/rc file manually.
As a general rule, use this command when there is something in the
etc/rc file causing the storage appliance to misbehave. Often, only
ifconfig, nfs on , and exportfs –a commands are executed
manually, allowing NFS or CIFS to become operational. The etc/rc
file is then edited to remove any offending lines and the system is
rebooted. In this scenario, CIFS is disabled and cannot be restarted until
the system is rebooted.
(3) Change password. This option allows you to change the root password of the filer. It is
usually used when you forget the current password and cannot use the
online passwd command.
(4) Initialize all disks. This command zeroes all the disks in the storage appliance and re-enters
(4a)Same as option 4, but creates a the setup menu. It is typically used only once during system
flexible root volume. reinstallation. This option first prompts you to confirm your choice.
After confirming, there is no way to retrieve data that was previously on
the disks. Zeroing the disks can take time (sometimes hours), depending
on how many disks, and the capacity of each disk.
NOTE: Do not use this option unless you are certain you want to
initialize your disks.
(5) Maintenance mode boot. This option enters a special system mode with only a small subset of
commands available. It is usually used to diagnose hardware problems
(often disk-related). In maintenance mode, WAFL volumes are
recognized but not used, the /etc/rc file is not interpreted, and few
system services are started. NFS and CIFS cannot be used. Disk
reconstructions do not occur. No file system upgrade occurs, even if the
system is newer than the OS release previously installed.
Boot Sequence
As the storage system boots, if you do not press Ctrl-C

(or you select Normal boot), the system:
1. Loads the Data ONTAP kernel into physical memory
from the CompactFlash.
2. Checks the root volume on the physical disk.
...
Wed Apr 7 20:53:00 GMT [mgr.boot.reason_ok:notice]: System rebooted.
CIFS local server is running.
system> Wed Apr 7 20:53:01 GMT [console_login_mgr:info]: root logged
in from console
Wed Apr 7 20:53:23 GMT [NBNS03:info]: All CIFS name registrations
complete for local server
system>
BOOT SEQUENCE
Boot Sequence (Cont.)
As the storage system boots and the Data ONTAP kernel

is loaded, it reads-in the following configuration and
system files from the /etc directory.
/etc/rc file (boot initialization)
/etc/registry file (option configurations)
/etc/hosts file (local name resolution)
Wed Apr 7 20:52:50 GMT [fmmbx_instanceWorke:info]: Disk 0b.18 is a
primary mailbox disk
...Loading Volume vol0
Wed Apr 7 20:52:53 GMT [rc:notice]: The system was down for 64 seconds
Wed Apr 7 20:52:54 GMT [dfu.firmwareUpToDate:info]: Firmware is up-to-
date on all disk drives
Wed Apr 7 20:52:58 GMT [ltm_services:info]: Ethernet e0a: Link up
add net default: gateway 10.32.91.1
Wed Apr 7 20:53:00 GMT [mgr.boot.floppy_done:info]: NetApp Release
7.3RC1 boot complete.
BOOT SEQUENCE (CONT.)
NORMAL BOOT SEQUENCE

The /etc/rc, /etc/registry, and /etc/hosts files (as well as others) are read during
a normal boot.
NOTE: Additional files might be used depending on the protocols that have been licensed.
Installation
There are three types of Data ONTAP software

updates:
New installations (systems with Data
ONTAP preinstalled)
Upgrades
Redeployments
INSTALLATION
1. Familiarize yourself with the requirements for the release you are installing.
2. Consider the following:
• Requirements for upgrading to Data ONTAP from your existing software
• Potential changes to your system following the upgrade
• Appropriate upgrade method for storage systems in an active-active configuration
• If you run the SnapMirror® software, you must identify storage systems with destination
and source volumes
3. Perform any necessary upgrades before upgrading to Data ONTAP. These upgrades
might include:
• Storage system firmware
• Disk firmware
4. Obtain the Data ONTAP system files from the NOW site at http://now.netapp.com/.
5. Install the Data ONTAP system files, and then download them to your storage
system(s).
Using the Setup Script
Runs automatically during initial system

configuration
Use the configuration worksheet to prepare
Run script at any time
– Use to change existing configuration
Reboot for changes to take effect
– Alternative to a reboot:
system> source /etc/rc
USING THE SETUP SCRIPT
The setup command can be run from the storage system CLI at any time; however, it is
usually run during initial system configuration when it is invoked automatically.
Do not run the setup command unless you want to reconfigure your system.
Configuration
CONFIGURATION
Configuration Worksheet
eng_router
10.10.10.1
NetApp1 OurDomain
Joey 10.10.10.100
GMT 10.10.10.200
Bldg. 1
en_US
adminhost
10.10.10.20
e0
10.10.10.100
10.10.10.30
255.255.255.0
Administrator
vif1 nollip
4
e4a,e4b,e4c,e4d
CONFIGURATION WORKSHEET
The setup script requires information specific to your network environment. A configuration
worksheet is provided in the Software Setup Guide. You can use the worksheet to gather the
necessary configuration information.
NOTE: You may not need to complete every field on this worksheet, depending on your
specific installation requirements.
HOST NAME
The host name is the name by which the storage appliance is identified on the network. If the
storage appliance is licensed for the NFS protocol, the host name can be no longer than 32
characters. If the storage system is licensed for the CIFS protocol, the host name can be no
longer than 15 characters. The host name must be unique for each storage appliance in a
cluster.
PASSWORD
The storage system requires a password before granting administrative access on the console,
through a telnet session, or through the remote shell protocol.
TIME ZONE
For a list of valid time zones, see the Setup Guide. The time zone must be identical on both
storage appliances in a clustered system.
LOCATION
The location is a description of the physical location of the storage system. This information
sets the SNMP location information.
LANGUAGE
Language refers to the language used for multiprotocol storage systems when both the CIFS
and NFS protocols are licensed. For a list of supported languages and language abbreviations,
see the Setup Guide. The language must be identical on both storage appliances in a cluster.
ADMINISTRATION HOST
The administration host is a client computer that is allowed to access the storage appliance
through a telnet session or through the remote shell protocol. In /etc/exports, adminhost
is granted root access to / so that it can access and modify the configuration files in /etc. All
other NFS clients are granted access only to /home. If no adminhost is specified, all clients
are granted root access to the root directory (not recommended for sites where security is a
concern).
ETHERNET
If your network uses standard Ethernet or Gigabit Ethernet (GbE) interfaces, you must gather
the following information for each interface:
• Network interface name―The name of the Ethernet (or GbE) interface, depending on what port
the Ethernet card is installed in. Examples include: e0 (for Ethernet single); e1 (for GbE); and e3a,
e3b, e3c, e3d (for Ethernet quad-port). Data ONTAP automatically assigns network interface
names as it discovers them.
• IP address―A unique address for each network interface.
• Subnet mask (network mask)―The subnet mask for the network to which each network
interface is attached. Example: 255.255.255.0
• Partner IP address (interface to take over)―If your storage system is licensed for cluster
takeover, record the interface name or IP address belonging to the partner that this interface should
take over.
• Jumbo frames―Jumbo frames are packets that are longer than the standard Ethernet (IEEE
802.3) frame size of 1,518 bytes. Because jumbo frames are not part of the IEEE standard, the
frame size definition for jumbo frames is vendor-specific. The most commonly used jumbo frame
sizes are 9,018 bytes and higher.
VIRTUAL INTERFACE
Specify the interface name rather than the interface IP address.
ROUTER (ROUTING GATEWAY)

Identify the gateway name and IP address for the primary gateway that is used for routing
outbound network traffic.
DNS DOMAIN
Enter the name of your network domain name service (DNS). The DNS domain name must
be identical on both storage systems in an active-active configuration. Record the IP
addresses of your DNS servers.
NIS DOMAIN NAME

Record the name of your NIS domain. The NIS domain is used to authenticate users. The NIS
domain name must be identical on both storage systems in an active-active configuration.
NIS SERVERS
Enter the IP or host names of your preferred NIS servers.
WINDOWS DOMAIN
If your site uses Windows servers, it has one or more Windows domains. Record the name of
the Windows domain to which the storage appliance should belong.
WINS SERVERS
Identify the servers that handle your Windows Internet Name Service (WINS) name
registrations, queries, and releases. If you choose to make the storage appliance visible
through WINS, you should record up to four WINS IP addresses.
WINDOWS 2000 USER (WINDOWS 2000 ADMINISTRATOR)

This is the name of the administrative Windows 2000 domain user who has sufficient
privileges to add this storage appliance to the Windows 2000 domain. This entry is required
only if you are using a Windows 2000 domain.
WINDOWS 2000 USER PASSWORD

This is the domain password to be used for the Windows 2000 user or administrative user. If
your domain is a Windows 2000 domain, you must use the password for the user who has
sufficient privileges to add this storage appliance to the domain.
ACTIVE DIRECTORY
This is the container for the storage appliance accounts, which can be either the default of
computers or a previously created organizational unit (OU) specified by you. The path for the
OU must be specified in reverse order and separated by commas. Example: If the path is
eng\dev\mgmt, the active directory distinguished name is: ou=mgmt, ou=dev, ou=eng.
NOTE: A user in the Windows 2000 domain can create the account in advance, and then
Data ONTAP updates that account.
Network Interface Configuration
The NetApp storage system automatically

names interfaces
Interface names are based on:
– Network type
– Motherboard bus slot number
– Port number, with multiport interface
NETWORK INTERFACE CONFIGURATION
For storage systems with PCI buses, the network interface naming is as follows:
• Ethernet interface names start with the letter e, followed by the slot number (for example, e0), and
then the port number. If the adapter card is a quad-port Ethernet card, an example of an interface
name is e1a and e1b.
• PCI-based storage systems automatically create host names for network interfaces by appending
the interface slot number to the storage system host name. For example, if the storage system is
named toaster, the host name for e0 is toaster-e0, and the host name for e1a is
toaster-1a.
Administration Host
Any workstation that is either an NFS or a

CIFS client on the network
– Designated by you during setup
Benefits of an administration host:
– Limits access to the storage system’s root file
system
– Provides a text editor to edit configuration files
– Provides the ability to administer a storage
system remotely
ADMINISTRATION HOST
Setup
SETUP
The setup Script
Please enter the new hostname []: system

Do you want to configure virtual network interfaces? [n]:
Please enter the IP address for Network Interface e0a []: 10.10.10.30
Please enter the netmask for Network Interface e0a [255.0.0.0]: 255.255.255.0
Please enter media type for e0a {100tx-fd, tp-fd, 100tx, tp, auto (10/100/1000)}
[auto]:
Please enter flow control for e0a {none, receive, send, full} [full]:
Do you want e0a to support jumbo frames? [n]:
Would you like to continue setup through the web interface? [n]:
Please enter the name or IP address of the default gateway: 10.10.10.1
The administration host is given root access to the filer's
/etc files for system administration. To allow /etc root access
to all NFS clients enter RETURN below.
Please enter the name or IP address of the administration host: adminhost
Please enter the IP address for adminhost: 10.10.10.20
Please enter timezone [GMT]: US/Pacific
Where is the filer located? []: Bldg. 1
THE SETUP SCRIPT
The setup script installs new versions of /etc/rc, /etc/hosts, /etc/exports,

/etc/resolv.conf, /etc/hosts.equiv, and /etc/dgateways to reflect the new
configuration. When setup is complete, the new configuration does not take effect until the
storage system is rebooted. You can reconfigure a storage system any time by typing setup
at the console prompt (this is not recommended unless you are performing a new installation).
If a reconfiguration is performed, the old contents of these five configuration files are saved
in rc.bak, exports.bak, resolv.conf.bak, hosts.bak, hosts.equiv.bak, and
dgateways.bak.
The empty brackets ([ ]) indicates that there is no default setting for the question. When the
brackets have a value, then the displayed value is the default.
Check Software Version & License Status
system> version
system> sysconfig -v
System ID: 0084166726 (NetApp1)
System Serial Number: 3003908 (NetApp1)
slot 0: System Board 599 MHz (TSANTSA D0)
Model Name: FAS250
Part Number: 110-00016
Revision: D0
Serial Number: 280646
Firmware release: CFE 1.2.0 system> license
Processors: 2
Processor revision: B2 nfs site ABCDEFG
Processor type: 1250 cifs site BCDEFGH
Memory Size: 510 MB http site CDEFGHI
NVMEM Size: 64 MB of Main Memory Used
cluster not licensed
snapmirror not licensed
snaprestore not licensed
CHECK SOFTWARE VERSION & LICENSE STATUS
SOFTWARE VERSION
You can verify your software version by using the sysconfig or sysconfig -v command,
or by using the version command. One way to verify the software version on the disks is to
change to the /etc/boot directory and then view the link to which that directory points.
FIRMWARE VERSION
There are two primary ways to verify your firmware version: use sysconfig –v, or halt the
storage system and type version from the OK prompt. Ensure that the firmware version on
your system is what it should be and that you have the most current version of the firmware
for your platform.
LICENSES
Use the license command to verify that all licenses are listed for your storage appliance.
The licenses that are displayed in the autosupport log are encrypted versions of the actual
licenses. If all authorized licenses are not displayed using this command, contact NetApp.
NOTE: You can also access the license information using FilerView. Under Filer, select
Manage Licenses.
Message Logging
Message logging is done by a syslogd daemon
The /etc/syslog.conf configuration file on the
storage system's root volume determines how system
messages are logged
Messages can be sent to:
– The console
– A file
– A remote system
By default, all system messages are sent to the
console and logged in the /etc/messages file
You can access the /etc/messages files via
– An NFS or CIFS client (discussed later in this course)
– The FilerView administration tool
MESSAGE LOGGING
The syslog contains information and error messages that the storage system displays on the
console and logs in the /etc/messages file.
To specify the types of messages that the storage system logs, use the Syslog Configuration
page in FilerView to edit the /etc/syslog.conf file. This file specifies which types of
messages are logged by the syslogd daemon. (A daemon is a process that runs in the
background, rather than under the direct control of a user.)
The /etc/syslog.conf File
The /etc/syslog.conf file consists of lines

with space-separated fields in the following
format:
facility.level action
The facility parameter specifies the
subsystem from which the message originated
The level parameter describes the severity
level of the message
The action parameter specifies where to send
messages
THE /ETC/SYSLOG.CONF FILE
By default, the /etc/syslog.conf file does not exist; however, there is a sample
/etc/syslog.conf file. To view a manual page, enter the man syslog.conf command.
The facility parameter uses one of the following keywords: kern, daemon, auth, cron,
or local7.
The level parameter is a keyword from the following ordered list (higher to lower):
emerg, alert, crit, err, warning, notice, info, debug.
The action parameter can be in one of three forms:
• A pathname (beginning with a leading slash)―Selected messages will be appended to the
specified log file.
• A hostname (preceded by ‘@’)―Selected messages will be forwarded to the syslogd daemon on
the named host.
• /dev/console―Selected messages are written to the console.
For more information about /etc/syslog.conf settings, see the System Administration
Guide.
Upgrades
UPGRADES
Options to Upgrade
NetApp periodically releases new versions of Data
ONTAP
Release families means major release to major
release upgrade
– First two digits of the release is the version number
Examples: 7.0, 7.1, 7.2
– Point releases have a new third digit
Examples: 7.2.1.1, 7.2.2L1
Download upgrades from the NOW site
Install an upgrade using either:
– CLI
software update <subcommand>
– A Windows or UNIX client to unzip or untar to the
shared or mounted /etc directory
OPTIONS TO UPGRADE
The process of upgrading a storage system can vary from release to release. Because disk
firmware is usually tied to the Data ONTAP version, there may be additional considerations
besides the ones identified here. For more information about the specific release you are
upgrading to, including instructions for downgrading to a previous version of Data ONTAP,
see the Upgrade Guide.
NOTE: The information presented in this course represents a generalized approach to
upgrading the operating system. Because some specifics may change between releases, be
sure to consult the appropriate guide for more information.
The software update Command
To upgrade Data ONTAP, enter
the command: software
update
This command:
Copies Data ONTAP
release file into
/etc/software
Root Volume Unzips Data ONTAP release
file
/etc
Updates /etc/boot (to be
loaded to CompactFlash)
/disk_fw Places other files in /etc
/boot /software (such as FilerView HTML
Other
System
files and disk firmware)
Files NOTE: The system continues
running the previous version of
Data ONTAP until rebooted.
THE SOFTWARE UPDATE COMMAND
The software update command allows you to upgrade Data ONTAP from the console
without using CIFS or NFS.
Before you using this command, you must first establish an HTTP host and download the
appropriate software (the Windows executable file for the specific platform, for example,
XX_setup_i.exe) from the NOW site to the host. After the .exe files are downloaded on an
HTTP server, you can install them on any storage appliance by using the software
install command.
The software update command requires the fewest number of steps and the least amount
of time to upgrade Data ONTAP. To upgrade Data ONTAP using the software install
command:
1. Verify the HTTP host and source URL.
2. Execute the software update command.
3. Reboot Data ONTAP.
Module Summary
In this module, you should have learned:

The NOW site provides an excellent source for
documentation and support.
The Configuration Worksheet aids in initial
configuration of a storage system.
Console access provides direct feedback on events
that occur on storage systems.
Pressing Ctrl-C during boot prompts the user with a
special boot menu.
The setup command runs when a storage system is
first turned on.
The software command provides a simple way to
upgrade Data ONTAP.
MODULE SUMMARY
Exercise
Module 2: Installation and
Configuration
EXERCISE
Basic Admin

MODULE 3: BASIC ADMINISTRATION
Basic
Administration
Module 3
BASIC ADMINISTRATION
3-1 Data ONTAP® 7.3 Fundamentals: Basic Administration
Module Objectives

Connect remotely to the CLI of a FAS system
using the console and a remote host
Access FilerView to manage a storage system
Execute commands using the console, a
remote host, and FilerView
Demonstrate how to use commands to analyze
a FAS system
Configure and manage the AutoSupport
service for a FAS system
MODULE OBJECTIVES
Graphical Interfaces
GRAPHICAL INTERFACES
Administration Options
A storage system may be managed from a:

GUI
CLI
ADMINISTRATION OPTIONS
Graphical Interfaces
A storage system can be managed through

multiple graphical interfaces:
FilerView administration tool
Operations Manager (formerly DataFabric®
Manager)
Microsoft® Windows® interfaces such as
Computer Management for certain CIFS
functionality
GRAPHICAL INTERFACES
FilerView Administration Tool
http://<system name or ipaddress>/na_admin
FILERVIEW ADMINISTRATION TOOL
The FilerView interface is a Web-based graphical management interface that enables you to
manage most storage system functions from a Web browser rather than from the console, a
telnet session, or the rsh command. FilerView supports Windows, UNIX, Solaris, Linux,
and HP-UX® environments.
To access a storage system from a client using FilerView, complete the following steps:
1. Start your Web browser.
2. Enter the following URL:
http://filername/na_admin
Where filername is either the fully qualified name (or the short name) or the IP address
of your storage system.
3. Click FilerView.
A new browser window is displayed. If you are running SecureAdmin™ 2.1.1 or later,
click Secure FilerView to start an encrypted browser session.
4. Select a management function. If prompted, supply an administrative user name and
password.
Operations Manager
Operations Manager is a Web application that discovers,

monitors, and manages NetApp storage from a
management console for maximum availability, reduced
TCO, and business policy compliance.
OPERATIONS MANAGER
NetApp Operations Manager (formerly DataFabric Manager) delivers comprehensive

monitoring and management for NetApp enterprise-storage and content-caching
environments. From a central point of control, Operations Manager provides alerts, reports,
and configuration tools to keep your storage infrastructure in line with your business
requirements for maximum availability and reduced TCO.
Operations Manager is a simple, centralized administration tool that enables comprehensive
management of enterprise-storage and content-delivery infrastructures. No other single
management application provides the same level of NetApp monitoring and management for
NetApp FAS systems and NearStore near-line storage. The detailed performance and health
monitoring tools available through Operations Manager gives administrators proactive
information to help resolve potential problems before they occur, and to troubleshoot
problems faster if and when they do occur.
Alternative GUIs
Some operating systems have other interfaces, such as

Windows Computer Management, that interact with the
functionality of the storage system.
ALTERNATIVE GUIS
Microsoft Windows Server 2000 and later, as well as client operating systems such as
Microsoft Windows XP and later, provide Computer Management, a management console
that is able to connect to a storage system. Microsoft Management Consoles (MMC) can also
be used to remotely administer a storage system.
Command Line
Interface
COMMAND LINE INTERFACE
Command Line Interface
The CLI is a powerful tool to administer storage

systems and can be accessed through:
Console
Telnet
Remote LAN Module (RLM)
FilerView CLI
Remote Shell (RSH)
Secure Shell (SSH)
system> Wed Apr 7 20:53:01 ...
logged in from console
system>
COMMAND LINE INTERFACE
Telnet to the Console
Login>
Password>
TELNET TO THE CONSOLE
The ability to telnet to a console is useful because it allows remote access to that console.
However, it is limited by the fact that only one telnet session at a time is allowed.
The storage system can be configured to allow telnet access only by certain hosts using one
of the following commands:
options trusted.hosts
or
options telnet.hosts (deprecated)
The storage system can be configured to terminate an unused telnet session automatically
using the following commands:
options autologout.telnet.enable
options autologout.telnet.timeout
To terminate a telnet session immediately without waiting for the timeout period, you can
also use the logout telnet command from RSH or the console.
Remote LAN Module
The RLM, which is available in some hardware

configurations, provides:
Remote access to your storage system
regardless of the system state
Continuous power and secure access
RLM Port
REMOTE LAN MODULE
The RLM is a management card available on FAS6000/V6000 and FAS3000/V3000 series

systems that provides remote platform management capabilities.
The RLM is powered by standby voltage that is available as long as the system has input
power to at least one of the appliance's power supplies. Therefore, the RLM is always
operational, regardless of the system operating state.
RLM PROVIDES A SECURE CONNECTION

The RLM was designed with security as a core requirement and uses a dedicated 10/100
Mbps Ethernet interface. You must use a secure shell (SSH) client to log in to the RLM. It
does not provide plain, text-based protocols such as telnet or RSH. To log into the RLM, you
can continue to use the same user credentials as defined in Data ONTAP.
ADDITIONAL FEATURES
The RLM provides secure, out-of-band access to the system that can be used regardless of the
system state. The RLM offers a number of remote management capabilities for NetApp
systems including remote access, monitoring, troubleshooting, logging, and alerting.
Some additional features of the RLM:
• Remote access to the storage system console without using a serial terminal or a terminal
concentrator
• Remote access to control system power if you need to power off, power on, or power cycle the
system remotely without using a LAN-based power strip
• Remote initiation of a core dump without requiring the use of the Non-Maskable Interrupt (NMI)
button on the system
• Remote access to hardware system event logs even when the system is down
The RLM also extends the AutoSupport capabilities of the NetApp system by sending alerts
or "down-filer" notifications through an AutoSupport message when the system goes down,
regardless of whether or not the system is able to send AutoSupport messages. These
AutoSupport messages provide proactive alerts to NetApp to help provide you with faster
service.
CONFIGURING THE RLM

You can configure an RLM using Data ONTAP in one of three ways:
1. During the initial setup
2. Using the setup command
3. Using the rlm setup command
FilerView CLI
FILERVIEW CLI
FilerView allows you to access a telnet session to administer the storage system from a CLI.
NOTE: Only one telnet session at a time is allowed, regardless of whether you are using the
FilerView CLI editor or an alternative telnet emulator.
CLI Session Limitations
A storage system allows only one session and

one user at a time. Attempts to create additional
sessions will generate an error.
Too many users logged in! Please try again later. Connection
closed.
To create two separate sessions to use at the

same time:
telnet.distinct.enable
NOTE: If separate sessions are not created,

administrators must share the same session.
CLI SESSION LIMITATIONS
The FilerView interface allows only one telnet session at a time. If you try to open a telnet
session in FilerView or the CLI directly, and there is already an active session open, you will
receive an error message.
When you close the Use Command Line window in FilerView, the telnet session is also
closed.
Remote Shell
RSH allows you to issue console commands without a

console session.
To use RSH, enable it with the following:

options rsh.enable on
If there is a console password, you must modify
/etc/hosts.equiv to allow access
Multiple RSH commands can be issued using the
following syntax:
– UNIX
rsh <storage_system> “<command>[; <command>]”
– Windows
rsh <storage_system> –l <user> “<command>”
REMOTE SHELL
To configure RSH access from a host:

• Verify that RSH is enabled on the storage system by using the options rsh command.
If RSH is disabled, enable it on the storage system using the options rsh.enable on
command.
• If no console password has been set, RSH access is allowed without a hosts.equiv file.
Subsequently, setting the console password prevents RSH access until a hosts.equiv file is
created. An entry for the server and account name in the storage system’s /etc/hosts.equiv
file must be created. For example, if the Windows server IP is 192.168.2.2 and the login name
is user1, the following entry should be in the hosts.equiv file on the storage
system:192.168.2.2 user1
NOTE: Be sure to add an empty line or new line at the end of the hosts.equiv file. Also,
in Windows, the RSH "username" is required in the /etc/hosts.equiv file. In UNIX, if
the RSH "username" is omitted, only "root" may access RSH from the host(s) listed in the
/etc/hosts.equiv file. This allows user1 to run RSH from the Windows host.
Secure Shell
SSH is a network protocol that allows data

exchange over a secure channel. SSH also:
Allows for secure administrative access to the
storage system
Requires no license
Can be implemented using the secureadmin
command or by using FilerView
For a complete description of the SSH feature,

see the System Administration Guide.
SECURE SHELL
USING FILERVIEW TO EXECUTE THE SECUREADMIN COMMAND

When you use the secureadmin command, it makes it very difficult for anyone to intercept
a storage system administrator's password over the network because the password and all
administrative communications are encrypted. The secureadmin command also provides a
secure communication channel between a client and the storage system using one or both of
the following protocols:
• SSH―Provides a secure remote shell and interactive network session. The secureadmin
command supports SSH 1.x clients and SSH 2.0 clients.
• SSL―Provides secure Web access for FilerView and Data ONTAP Application Program
Interfaces (APIs).
Common Commands
COMMON COMMANDS
Basic Administration Commands
system> ?
? halt nfs snapvault
aggr help nfsstat snmp
backup hostname nis software
cf httpstat options source
cifs ifconfig orouted storage
config ifstat partner sysconfig
dafs igroup passwd sysstat
date ipsec ping timezone
df ipspace priv traceroute
disk iscsi qtree ups
disk_fw_update iswt quota uptime
dns license rdate useradmin
download lock reboot version
dump logger restore vfiler
echo logout rmc vif
ems lun route vlan
environment man routed vol
exportfs maxfiles rsm vscan
fcp mt savecore wcc
fcstat nbtstat secureadmin ypcat
file ndmpcopy setup ypgroup
filestats ndmpd shelfchk ypmatch
fpolicy netdiag snap ypwhich
ftp netstat snapmirror
system>
BASIC ADMINISTRATION COMMANDS
At the normal administration privilege level, entering a question mark (?) at the command
line displays the commands available to a system administrator for disk management,
networking, system management, physical and virtual interface configuration, and related
tasks.
Some of these commands are simple; some use arguments; some perform obvious functions
such as backup, ping, or help. To display a brief description of a command, enter help
command name on the command line. To display the full syntax of a command, including
associated arguments, enter command name on the command line.
You can also use FilerView to access the manual pages for each command.
Advanced Privilege Commands
system> priv set advanced
Warning: These advanced commands are potentially dangerous; use
them only when directed to do so by Network Appliance
df personnel. led_on quota sysstat
disk led_on_all rdate test_lcd
disk led_on_off rdfile timezone
disk_fw_update led_test reboot toe
disk_list led_test_one registry traceroute
disk_stat license remote ups
dns lmem_stat restore uptime
download lock result useradmin
dump log revert_to version
echo logger rm vfiler
ems logout rmc vif
environ ls rmt vlan
environment lun rod vol
exit man route vscan
exportfs maxfiles routed wafl
fcadmin mbstat rsm wafl_susp
fcp mem_scrub_stats rtag wcc
fcstat mt savecore wrfile
file mv scsi ypcat
filestats nbtstat secureadmin ypgroup
fpolicy ndmpcopy setup ypmatch
ftp priv set admin
ndmpd sh ypwhich
getXXbyYY
ADVANCED PRIVILEGE COMMANDS
Advanced privilege commands are additional commands that provide more control and access
to the storage system. In some cases, these commands are simply normal commands with
additional arguments or options available.
CAUTION: Because advanced privilege commands are potentially dangerous, they should
only be used by knowledgeable personnel.
You can access advanced privilege commands using the priv set advanced command.
This command changes the command-line prompt by embedding an asterisk (*) in the prompt
when advanced privileges are enabled. To return to basic administration mode, use the priv
set admin command.
There are additional administration commands that are considered advanced but are available
in the basic administration mode. However, these commands are hidden and do not appear
when you enter help while in the basic administration mode.
Basic System Configuration
The following are basic system configuration commands:

System configuration
– sysconfig
– sysconfig -v
RAID configuration
– sysconfig –r
– vol status -r
Disk configuration
– sysconfig -d
Check your configuration
– sysconfig -c
BASIC SYSTEM CONFIGURATION
Many console commands provide storage system configuration information. You can use
these commands to:
• Check your system configuration
• Monitor system status
• Verify the correct system
Configuring Your
System
CONFIGURING YOUR SYSTEM
Configuring Your System
To change the configuration of a storage system, use

one of the following methods:
CLI
– options
– vol options
Configuration files
– /etc/hosts
– /etc/rc
– /etc/hosts.equiv
– /etc/dgateways
FilerView
AutoSupport to report configurations (discussed later)
CONFIGURING YOUR SYSTEM
SYSTEM CONFIGURATION OPTIONS: COMMANDS VERSUS CONFIGURATION FILES

Use system or volume-options commands to change configurable storage system software
options. These options commands:
• Can all be entered on the console, with some available using FilerView
• Are automatically added to the storage appliance’s registry in the /etc/registry file
• Are persistent across reboots
• Do not require that you edit any configuration files
To make non-options configurations permanent, you must edit configuration files such as
/etc/rc, /etc/hosts.equiv, /etc/dgateways, and /etc/hosts.
CLI Commands
System options:
options [option name] [value]
Example: options rsh.enable on
NOTE: If no value is entered, the current value is displayed.
Volume options:
vol options volname [option name] [value]
Aggregate options:
aggr options aggrname [option name] [value]
CLI COMMANDS
The options or vol options commands are used to change configurable storage system
software options.
If no options are specified, then the current value of all available options is printed. If an
option is specified with no value, then the current value of that option is printed. If only a part
of an option is specified with no value, then the list of all options that start with the partial-
option string is printed. This is similar to the UNIX grep command.
The default value for most options is off, which means that the option is not set.
Changing the value to on enables the option. For most options, the only valid values are:
• On (also expressed as yes, true, or 1) in any combination of upper and lower case
• Off (also expressed as no, false, or 0) in any combination of upper and lower case
If the default is not set to off, the description of an option indicates the default setting along
with allowable values (if it is not an on-or-off option).
For options that accept string values, use a double quote ("") as the option argument if you
want to set the option to be the null string. Normally, arguments are limited to 255 characters
in length.
Registry Files
Registry files contain many persistent

configurations.
IMPORTANT: The registry should not be edited directly.
File Usage
/etc/registry Current registry
/etc/registry.lastgood Copy of registry after last
successful boot
/etc/registry.bck First-level backup
/etc/registry.default Default registry
REGISTRY FILES
REGISTRY DATABASE
Persistent configuration information and other data is stored in a registry database.
There are several backups of the registry database that are automatically used if the original
registry becomes unusable. The /etc/registry.lastgood is a copy of the registry as it
existed after the last successful boot.
The /etc/registry is edited by Data ONTAP and should not be manually edited.
Configuration commands such as the network interface configuration (ifconfig) must
remain in the /etc/rc file.
Editing Configuration Files
The following are important configuration files:

/etc/rc
/etc/hosts
/etc/hosts.equiv
There are three ways to edit a configuration file:
Access the /etc directory and use local
editing tools
Use commands on the console
Use FilerView to edit configuration files
EDITING CONFIGURATION FILES
EDITING BOOT CONFIGURATION FILES

The storage system boot configuration files contain commands that run automatically when
the storage system is booted. These files are located in the /etc directory of the storage
appliance’s root volume.
The rc configuration file contains:
• Network interface configuration information
• Commands that automatically export NFS mounts
The hosts file is used for name-machine resolution, while the hosts.equiv is used to
develop a trust relationship for certain applications such as RSH.
RECOVERING FROM CONFIGURATION FILE ERRORS

The storage system can become inaccessible if:
• You introduce errors into the /etc/rc file during editing
• The network interface configuration commands in the /etc/rc file specify an incorrect address
or the file contains other misconfigured items
You can correct errors through the console using the ifconfig and exportfs commands.
Or, if CIFS is enabled, you can access the /etc/rc file from a CIFS client and then correct
the NFS export error after the network interface is properly configured.
Editing Configurations from Host
#Auto-generated by setup Sun Mar 29 15:05:20 GMT

1970
127.0.0.1 localhost
10.254.134.43 DEV-FAS250 DEV-FAS250-e0a
# 0.0.0.0 DEV-FAS250-e0b
EDITING CONFIGURATIONS FROM HOST
To edit a configuration file from a host, the storage system must be configured with a NAS
protocol such as CIFS or NFS. An adminhost can then access the /etc directory to edit the
configuration file.
ADMINHOST
The term adminhost is used to describe an NFS or CIFS client machine that is able to view
and modify configuration files stored in the /etc directory of the storage system’s root
volume.
The storage system grants root permissions to the adminhost after the setup procedure is
complete.
CLIENT REQUIREMENTS PRIVILEGE

NFS The host name must be entered in the Mount the storage system root directory
/etc/hosts.equiv file. The setup procedure with root permissions, and then edit
automatically populates this file. configuration files. Enter storage system
commands using a remote shell program
such as RSH.
CIFS The user must be a member of the Administrators Edit configuration files by accessing the
domain. \\storagesystem\C$ share.
Console Editing
To edit files on the console:

1. Make a backup copy of the file.
2. Read the file using rdfile.
3. Write the file using wrfile.
IMPORTANT: When the wrfile command is issued, the original

file is deleted. Therefore, it is important to first use the rdfile
command. To append to a file without deleting it, use wrfile –a.
CONSOLE EDITING
The console command rdfile displays the present contents of an ASCII text file. If the file
doesn’t exist or is empty, this command returns nothing.
For example, to display the /etc/hosts file from the CLI, enter rdfile /etc/hosts.
The console command wrfile creates or re-creates a file when executed.
For example, to re-create the /etc/hosts file from the CLI, enter wrfile /etc/hosts,
and then enter the contents of the file and press Ctrl-C to commit the file. Issue the command
rdfile to verify the contents of the file.
System Configuration Using FilerView
Configuration settings are accessed through the left

navigation pane.
SYSTEM CONFIGURATION USING FILERVIEW
FilerView has a variety of different menu items that display and allow configuration of a
storage system.
AutoSupport
AUTOSUPPORT
AutoSupport Mail Host
Email Server
AUTOSUPPORT MAIL HOST
AutoSupport is a call home feature included in the Data ONTAP and NetCache software for
all NetApp systems. AutoSupport is an integrated and efficient monitoring and reporting tool
that constantly monitors the health of your system.
AutoSupport allows storage systems to send messages to the NetApp Technical Support team
and to other designated addressees when specific events occur. The AutoSupport message
contains useful information for Technical Support to identify and solve problems quickly and
proactively.
You can also subscribe to the abbreviated version of urgent AutoSupport messages through
alphanumeric pages, or you can customize the type of message alerts you want to receive.
The AutoSupport Message Matrices list all the current AutoSupport messages in order of
software version.
WHY SHOULD AUTOSUPPORT BE ENABLED?

AutoSupport allows the system to send messages directly to system administrators and
NetApp Technical Support, which has a dedicated team continually enhancing AutoSupport
analysis tools.
TURNING TRADITIONAL SUPPORT PROCESSES AROUND

NetApp automatically analyzes AutoSupport messages, immediately notifying our Technical
Support team when there is a critical alert. Technical support then initiates an investigation.
This means that you don’t have to report the problem. In some cases, status messages provide
enough information for NetApp to take corrective action right away. For example, when
NetApp receives a "Failed Disk Trigger" message, we automatically ship a replacement drive
to you (per the terms of your maintenance agreement).
STAYING AHEAD OF POTENTIAL PROBLEMS
Not all AutoSupport messages lead to immediate actions. Warning messages in the syslog can
point to suspect components. Often, this initiates corrective action that can prevent unplanned
disruption. Our AutoSupport analysis tools also monitor syslog messages for known
configuration issues. A config alert notifies our support team of a configuration issue that
could lead to system instability. Finally, being connected through AutoSupport means that
NetApp already has details about your current system configuration.
NetApp strongly recommends that AutoSupport be configured on all your systems.
AutoSupport
The autosupport daemon monitors the storage

system's operations and sends automatic
messages to technical support. Technical
support contacts you with any reported issues.
AutoSupport messages are generated:
When events occur on the storage system that
require corrective action
When you initiate a test message
When the system reboots
Once a week (usually after 12 a.m. on
Sundays)
AUTOSUPPORT
AUTOSUPPORT DAEMON
NetApp storage systems use an AutoSupport daemon to control how messages are sent to
NetApp Technical Support. The AutoSupport daemon is enabled by default on a storage
system.
HOW AUTOSUPPORT WORKS

In order to continuously monitor your system status and health, AutoSupport:
• Is automatically triggered by the kernel once a week to send information to the e-mail addresses
specified in the autosupport.to option before the messages file is backed up. In addition, the
options command can be used to invoke the AutoSupport mechanism to send this information.
• Sends a message in response to events that require corrective action from the system administrator
or NetApp Technical Support.
• Sends a message when the system reboots.
AutoSupport E-Mail Events
Events E-Mail Subject Line

Low NVRAM battery BATTERY_LOW
Disk failure DISK_FAIL!!!
Disk scrub detected checksum errors DISK_SCRUB CHECKSUM ERROR
Shutdown occurred because of overheating OVER_TEMPERATURE_SHUTDOWN!!!
Partial RPS failure occurred REBOOT
Disk shelf error occurred SHELF_FAULT
Spare disk failure occurred SPARE DISK FAILED
Weekly backup of /etc/messages occurred WEEKLY_LOG
Successful cluster takeover of partner CLUSTER TAKEOVER COMPLETE
Unsuccessful cluster takeover CLUSTER TAKEOVER FAILED
Cluster takeover of virtual filer REBOOT (CLUSTER TAKEOVER)
Cluster giveback occurred CLUSTER GIVEBACK COMPLETE
AUTOSUPPORT E-MAIL EVENTS
AutoSupport e-mails can be triggered by the following events:

• Weekly logs (/etc/messages)
• System reboots
• Low NVRAM batteries
• Disk, fan, and power supply failures
• Shelf faults
• File system growing too large
• Administrator-defined SNMP traps
To read descriptions of some of the AutoSupport messages you might receive, access the
NOW site and search for AutoSupport Message Matrices, You can view either the online
version or the version in the Data ONTAP guide.
AutoSupport E-mail Contents
The options autosupport.content

command specifies how much to send
– options autosupport.content
[Minimal|Complete]
The default is Complete
Complete AutoSupports are stored in:
– /etc/log/autosupport
AUTOSUPPORT E-MAIL CONTENTS
AutoSupport e-mails contain the following information:

• Output of system commands
• Message date and time stamp
• NetApp software version
• Storage system ID and hostname
• Software licenses enabled
• SNMP contact information and location (if configured)
• Contents of the /etc/messages file
• Contents of the /etc/serialnum file (if created)
AutoSupport messages also contain additional information specific to your storage system.
This information helps identify crucial parameters required for follow-up handling of the
triggering event.
To control the detail level of event messages and weekly reports, use the options command
to specify the value of autosupport.content as complete or minimal. Complete
AutoSupport messages are required for normal technical support. Minimal AutoSupport
messages omit sections and values that might be considered sensitive information, and reduce
the amount of information sent. However, keep in mind that choosing minimal greatly affects
the level of support NetApp is able to provide.
AutoSupport Configuration Options
AutoSupport commands:
options autosupport.support.enable
[on|off]
options autosupport.mailhost
[host1,…,host5]
options autosupport.to
[address1,…,address5]
options autosupport.from
options autosupport.content
options autosupport.noteto
options autosupport.doit [message]
options autosupport.enable [on|off]
AUTOSUPPORT CONFIGURATION OPTIONS
The commands listed above are some of the AutoSupport configuration commands available
from the console.
The following table is an abbreviated version of the AutoSupport options list. See the
command reference for a full list of options and descriptions.
EXAMPLE RESULT
options autosupport.enable off Disables the AutoSupport daemon. The default is on.
options autosupport.support.enable Disables the AutoSupport notification to NetApp. The default is on.
off This option is superseded (overridden) by the value of
autosupport.enable.
options autosupport.mailhost Specifies two mail host names: maildev1 and mailengr1. (You can
maildev1,mailengr1 enter up to five mail host names.)
Hostname is the hostname of the SMTP mail host(s) that will receive
AutoSupport e-mail messages. The default is the hostname of the
adminhost specified during setup.
options autosupport.to Specifies two recipients (jjandar and ssmith) of AutoSupport e-mail
jjandar@netapp.com, messages.
ssmith@netapp.com Address is an SMTP e-mail address. You can specify up to five
addresses. NOTE: Do not enter autosupport@netapp.com if
autosupport.support.enable is on.
options autosupport.from techsupport Defines the user, techsupport, as the sender of the notification.
Testing AutoSupport
To send an AutoSupport test message, complete

the following steps:
1. Configure AutoSupport using the options
command.
2. Run the following command on the storage
system console:
options autosupport.doit testing
The message “System Notification Sent”
appears on the console.
TESTING AUTOSUPPORT
Module Summary
In this module, you should have learned:

Connect remotely to the CLI of a FAS system
using the console and a remote host
Access FilerView to manage a storage system
Execute commands using the console, a
remote host, and FilerView
Demonstrate how to use commands to analyze
a FAS system
Configure and manage the AutoSupport
service for a FAS system
MODULE SUMMARY
Exercise
Module 3: Basic Administration
EXERCISE
Admin Security

MODULE 4: ADMINISTRATION SECURITY
Administration
Security
Module 4
ADMINISTRATION SECURITY
4-1 Data ONTAP® 7.3 Fundamentals: Administration Security
Module Objectives

Restrict administrative access
Restrict console and FilerView access
Configure a client machine as an adminhost to
manage a storage system
MODULE OBJECTIVES
Storage System Access
To access a storage system, administrative

users can log into the storage system (or
FilerView).
Multiple administrators are allowed.
Login information can be tracked the syslog
(/etc/messages file), including:
– User name
– Time of access
– Node name or address
Administrative operations are tracked in the
audit log (/etc/log/auditlog).
STORAGE SYSTEM ACCESS
To manage a storage system, you can use the default system administration account, or root.
You can also create additional administrator user accounts using the useradmin command.
Administrator accounts are beneficial because:
• You can give administrators and groups of administrators differing levels of administrative access
to your storage systems.
• You can limit an individual administrator's access to specific storage systems by giving him or her
an administrative account only on those systems.
• Having different administrative users allows you to display information about who is performing
what commands on a storage system.
The auditlog file keeps a record of all administrator operations performed on a storage system
and the administrator who performed it, as well as any operations that failed due to insufficient
capabilities.
• You can assign each administrator to one or more groups whose assigned roles (sets of
capabilities) determine what operations they are authorized to carry out on the storage system.
• If a storage system running CIFS is a member of a domain or a Windows workgroup, domainuser
accounts authenticated on the Windows domain can use any available method to access the storage
system.
THE AUDIT LOG
An audit log is a record of commands executed at the console through a telnet shell, an SSH
shell, or by using the rsh command. All commands executed in a source-file script are also
recorded in the audit log. Audit log data is stored in the /etc/log directory in the auditlog
file. Administrative HTTP operations, such as those resulting from the use of FilerView, are
also logged. The maximum size of the auditlog file is specified using the
auditlog.max_file_size option. By default, Data ONTAP is configured to save an audit
log.
Role-Based Access Control
Role-Based Access Control (RBAC) is a mechanism for managing a
set of actions (capabilities) that a user or administrator can perform
on a storage system.
A role is created.
Capabilities are granted to the role.
Groups are assigned to one or more roles.
Users are assigned to groups.
Groups Roles Capabilities
ROLE-BASED ACCESS CONTROL
Role-based access control (RBAC) specifies how users and administrators can use a
particular computing environment.
Most organizations have multiple system administrators, some of whom require more
privileges than others. By selectively granting or revoking privileges for each user, you can
customize the degree of access that each administrator has to the system.
RBAC allows you to define sets of capabilities (roles) that apply to one or more users. Users
are assigned to groups based on their job functions, and each group is granted a set of roles to
perform those functions.
Capabilities and Roles
CAPABILITIES AND ROLES
Capabilities
Capabilities are predefined privileges that

allow users to execute commands or take
other specified actions.
A role is a set of capabilities.
The following capabilities are predefined:
– Login
– CLI
– Security
– API
CAPABILITIES
A capability is a privilege granted to a role to execute commands or take other specified

actions.
Data ONTAP uses four types of capabilities:
• Login rights―These capabilities begin with login- and are used to control which access
methods an administrator is permitted to use for managing the system.
• CLI rights―These capabilities begin with cli- and are used to control which commands an
administrator may use in the Data ONTAP CLI.
• API rights―These capabilities begin with api- and are used to control which API commands
may be used. API commands are usually executed by programs not administrators. However, you
might want to restrict a specific program to certain APIs by creating a special user account for it,
or you might want to have a program authenticate as the administrator who is using the program
and then be limited by that administrator’s roles.
• Security rights―These capabilities begin with security- and are used to control an
administrator’s ability to use advanced commands or change passwords for other users.
Roles
A role is a defined set of capabilities.

Data ONTAP includes several predefined
roles.
Administrators can create additional roles or
modify existing roles.
Admin Role
Capabilities
Login capability
Security capability
CLI capability
API capability
ROLES
A role is a collection of capabilities or rights to execute certain functions. Usually, a role is

created to assign a task or tasks to a particular group of users.
Predefined Administrative Roles
Root—Grants all possible capabilities

Admin—Grants all CLI, API, login, and security
capabilities
Power—Grants the ability to:
– Invoke all cifs, exportfs, nfs, and
useradmin CLI commands
– Make all cifs and nfs API calls
– Log in using Telnet, HTTP, RSH, and SSH
sessions
Audit—Grants the ability to make snmp-get
and snmp-get-next API calls
None—Grants no administrative capabilities
PREDEFINED ADMINISTRATIVE ROLES
• Roles have assigned capabilities that can be modified.

• The useradmin role list command is used to view capabilities assigned to each role.
• To assign users to a system, you must first assign them to a group that has specified capabilities.
Groups and Users
GROUPS AND USERS
Groups
A group is:
– A collection of users
– Associated with one or more roles
Groups have defined permissions and access levels
that are defined by roles
Admin Role
GROUPS
A group is a collection of users or domain users. It is important to remember that the groups
defined in Data ONTAP are separate from other groups such as groups defined in the
Microsoft Active Directory server or an NIS environment. This is true even if the groups
defined in the Microsoft Active Directory and the groups defined in Data ONTAP have the
same name.
When creating new users or domain users, Data ONTAP requires that you specify a group.
Therefore, you should create appropriate groups before defining users or domain users.
Predefined Groups
Administrators—Grants all CLI, API, login, and

security capabilities
Power Users—Grants the ability to invoke
cifs, nfs, and useradmin CLI commands,
manage cifs and nfs API calls, and log in
using Telnet, HTTP, RSH, and SSH sessions
Backup Operators—None
Users—Grants the ability to make snmp-get
and snmp-get-next API calls
Guests—None
Everyone—None
PREDEFINED GROUPS
To create or modify a group, start by giving the group capabilities associated with one or
more predefined or customized roles.
Users
A user is:
An individual account that may or may not have
capabilities defined for the storage system
Part of a group
All administrative users have a unique login name and
password.
Admin Role
USERS
User Creation Requirements—Role
Current role definitions can be viewed using the

CLI command:
useradmin role list [role]
– Empty list Æ general information for all roles
– Specific role Æ detailed information about a
particular role
Create new role using the CLI command:
useradmin role add <rolename> –a
<capability> ,…
– Capability can be one or more of login, CLI,
security, or API capabilities
– Each capability can be refined to a specific subset
USER CREATION REQUIREMENTS—ROLE
User Creation Requirements—Group
Current group definitions can be viewed using

the CLI command:
useradmin group list [group_name]
– Empty list Æ general information for all groups
– Specific group Æ detailed information about a
particular group
Create a new group using the CLI command:
useradmin group add <groupname> -r
<role>, …
A group must be associated with one or more
roles.
USER CREATION REQUIREMENTS—GROUP
Purpose of Local Users
Local users on the storage system:

Are used for administrative console access
In CIFS:
– Provides list of authenticated users with
Microsoft® Windows® workgroup
authentications
– Provides access to users when there is no
domain controller access with Windows domain
authentications
In NFS, provides access to the storage system
PURPOSE OF LOCAL USERS
Local users are often used to delegate configuration duties to other administrators. However,
local users are also created if the system storage is configured to perform local authentication
with CIFS or NFS protocols (for example, when the storage system’s CIFS server is
configured for Windows workgroup authentication).
Security Administration
User accounts are managed from the CLI only (no
FilerView interface) using the following command:
useradmin
– This command allows you to list, add, and delete users.
– The user account is maintained in the /etc/registry
file.
User authentication is performed locally on the storage
system.
Admin Role
SECURITY ADMINISTRATION
Security Administration (Cont.)
Password control is defined by security options

in:
system> options security
Password management is defined by the CLI
command:
passwd
NOTE:
The root user ID cannot be deleted
No initial password for root
Root has full admin rights to machine without login if there are no
other user definitions or password settings
SECURITY ADMINISTRATION (CONT.)
SECURITY OPTIONS
PASSWORD RULE DESCRIPTION

OPTION
security.passwd.firstl Specifies whether new users and users logging in for the first time after
ogin.enable {on|off} another user has changed their password must change their password. The
default value for this option is off.
NOTE: If you enable this option, you must ensure that all groups have
login-telnet and cli-passwd capabilities. Users in groups that
do not have these capabilities cannot log in to the storage system.
security.passwd.lockou Specifies the number of allowable login attempts before a user account is
t.numtries num disabled. The default value for this option is 4,294,967,295.
security.passwd.rules. Specifies whether a check-for-password composition is performed when

enable {on|off} new passwords are specified. If this option is set to on, passwords are
checked against the rules specified in this table and the password is
rejected if it doesn't pass the check. If this option is set to off, the check is
not performed. The default value for this option is on. By default, this
option does not apply to root or administrator users/
security.passwd.rules. Specifies whether a check-for-password composition is performed for the
everyone {on|off} root and administrator users. If the
security.passwd.rules.enable option is set to off, this option
does not apply. The default value for this option is off.
security.passwd.rules. Specifies the number of previous passwords checked against a new
history num password to disallow repeats. The default value for this option is 0,
meaning that no repeat passwords are allowed.
SECURITY OPTIONS (CONT.)
PASSWORD RULE DESCRIPTION

OPTION
security.passwd.rules Specifies the maximum number of characters in a password.
. NOTE: This option can be set to a value greater than 16, but a maximum of
maximum max_num 16 characters are used to match the password.
Users with passwords longer than 14 characters cannot log in through

Windows interfaces, so if you are using Windows, do not set this option
higher than 14. The default value for this option is 256.
security.passwd.rules Specifies the minimum number of characters in a password. The default
. value for this option is 8.
minimum min_num
security.passwd.rules Specifies the minimum number of alphabetic characters in a password. The
. default value for this option is 2.
minimum.alphabetic
min_num
security.passwd.rules Specifies the minimum number of digit characters (numbers from 0 to 9) in a
. password. The default value for this option is 1.
minimum.digit min_num
security.passwd.rules Specifies the minimum number of symbol characters (white space and
. punctuation characters) in a password. The default value for this option is 0.
minimum.symbol
min_num
User Access
Administrative activities are logged

For security purposes, each administrative
user must be identified
Only administrative users can log in to the
storage system
The syslog file records console logins
according to the following:
– User name (up to 32 characters, not case-
sensitive)
– Time of access
– Node name and address
USER ACCESS
User Creation Requirements - User
Current user definitions can be viewed using

the CLI command:
useradmin user list [user]
– Empty list Æ general information for all users
– Specific user Æ detailed information about a
particular user
Create a new user using the CLI command:
useradmin user add <username> -g
<group>,…
– Password may be required (see security
options)
– User must be associated with one or more
groups
USER CREATION REQUIREMENTS – USER
Administration Host
Access
ADMINISTRATIVE HOST ACCESS
Administration Host
The setup command requests the name and

IP address of adminhost
– This is a UNIX/Linux host that has access to
mount /etc from the storage system
– When mounted, root on the adminhost has root
access to /etc
If provided, the adminhost is granted access to
the root volume for administrative purposes
If not provided, all NFS clients will be granted
root access to the root volume (this is not
recommended)
ADMINISTRATION HOST
The term adminhost is used to describe an NFS or CIFS client machine that has the ability to
view and modify configuration files stored in the /etc directory of the storage system’s root
volume.
When you designate a workstation as an administration host, the storage system's root file
system (/vol/vol0 by default) is accessible only to the specified workstation in the
following ways:
• If the storage system is licensed for the CIFS protocol, the root file system is accessible as a share
named, C$.
• If the storage system is licensed for the NFS protocol, the root file system is accessible by NFS
mounting.
You can designate additional administration hosts after setup by modifying the storage
system's NFS exports and CIFS shares.
ADMINISTRATION HOST PRIVILEGES

The storage system grants root permissions to the administration host after the setup
procedure is complete. The following table describes administration host privileges.
IF THE YOU CAN...

ADMINISTRATION
HOST IS...
An NFS client Mount the storage system root directory and edit configuration files from
the administration host
Enter Data ONTAP commands using a Remote Shell connection
A CIFS client Connect to the storage system as root or administrator, and then edit
configuration files from any CIFS client
Restricting Access
To improve security, you can configure the

storage system to allow logins only from
trusted hosts. This option can be configured
using:
– CLI command:
options trusted.hosts [hostname|*|-]
– FilerView
You may specify up to five clients to be given
Telnet, RSH, and FilerView privileges
RESTRICTING ACCESS
When restricting access using options trusted.hosts command:

• Host names should be entered as a comma-separated list with no spaces.
• Enter an asterisk (*) to allow access to all clients (this is the default).
• Enter a hyphen (-) to disable access to the server.
• This value is ignored for telnet if options telnet.access is set, and is ignored for
administrative HTTP if options httpd.admin.access is set.
Module Summary

Restrict administrative access control by
configuring and managing users, groups and
roles
Restrict console and FilerView access
Configure a client host as an adminhost to
manage a storage system
MODULE SUMMARY
Exercise
Module 4: Administration Security
EXERCISE
Networking

MODULE 5: NETWORKING
Networking
Module 5
NETWORKING
5-1 Data ONTAP® 7.3 Fundamentals: Networking
Module Objectives

Identify the configuration of network settings and
components in Data ONTAP
Explain the main features and uses of naming services
Explain the function of /etc/hosts, NIS, and DNS
Configure Data ONTAP for name resolution in
/etc/nsswitch.conf
Use host files to troubleshoot name resolution
Explain routing tables in Data ONTAP
Identify how a FAS system routes packets
Define and create virtual interfaces (VIFs)
Discuss the operation and method for routing in VLANs
MODULE OBJECTIVES
Interface Configuration
INTERFACE CONFIGURATION
Interface Configuration
Initial interface configuration

– Configured by the setup command
After initial setup, you can create and modify
the interface configuration using:
– CLI with the ifconfig command
– FilerView
Interface configuration is stored in the
/etc/rc file, which is read when the
storage system boots
INTERFACE CONFIGURATION
From the CLI, the ifconfig command displays and configures network interfaces for a
storage system.
The following are ifconfig command examples:
• Display network interface configurations:
ifconfig -a
• Change an interface IP address:
ifconfig interface 10.10.10.XX
• Bring down an interface:
ifconfig interface down
• Bring up an interface:
ifconfig interface up
The /etc/rc file configures the interface settings during boot. You can edit this
configuration on the storage system using the wrfile command, from FilerView, or from an
adminhost using CIFS/NFS.
Example: Using the ifconfig command in the /etc/rc file:
ifconfig interface 10.10.10.XX netmask 255.255.252.0 up
Interface Configuration (Cont.)
The storage system Network Types Letter

supports the following Ethernet e
network types:
Ethernet 10/100 Base-T Port Number Letter
1G Ethernet 1 a
2 b
10G Ethernet (Data 3 c
ONTAP 7.2 or later) 4 d
Storage systems with

multiple-port Ethernet
adapters use letters to
identify each port.
INTERFACE CONFIGURATION (CONT.)
Your storage system supports the following interface types:

• Ethernet―including quad-port Ethernet adapters
• Gigabit Ethernet (GbE)
• Asynchronous transfer mode (ATM)―Emulated LAN and FORE/IP
• Onboard network interfaces (supported on FAS250, FAS270, FAS3000/V3000, and
FAS6000/V6000 systems)
• 10 GbE TCP offload engine (TOE) network interface card (NIC)
Your storage system also supports the following virtual network interface types:
• Virtual interface (VIF)
• Virtual local area network (VLAN)
• Virtual hosting (VH)
Interface Naming Example
Interface Type Slot Port Interface Name

Ethernet 0 (onboard) 1 e0a
Ethernet 0 (onboard) 2 e0b
Ethernet 3 1 e3a
Ethernet 3 2 e3b
Ethernet 3 3 e3c
Ethernet 3 4 e3d
INTERFACE NAMING EXAMPLE
For physical interfaces, interface names are assigned automatically based on the slot where
the network adapter is installed.
VLAN interfaces are displayed in the interfaceID_and_slot_number-vlan_id format,
where slot_number is the slot where the network adapter is installed, and vlan_id is the
identifier of the VLAN that is configured on the interface. For example, e8-2, e8-3, and e8-4
are three VLAN interfaces for VLANs 2, 3, and 4, configured on interface e8.
You can assign names to vifs and emulated LAN interfaces.
Managing Interfaces: ifconfig
Network interface configuration parameters:

– IP address
– Netmask address
– Broadcast address
– Media type and speed
– Maximum Transmission Unit (MTU)
– Flow control (Gigabit Ethernet II controller only)
– Up or down state
To display current status:
– ifconfig -a
Interface configuration changes are not
permanent until entered into the /etc/rc file
MANAGING INTERFACES: IFCONFIG
INTERFACE CONFIGURATION PARAMETERS

There are seven common network interface parameters that can be configured:
• IP address
• Netmask address
• Broadcast address
• Media type and speed
• Maximum Transmission Unit (MTU)
• Flow control for the GbE II controller
• Up or down state
Changes made using the CLI are not permanent until added to the /etc/rc file using either
the CLI or FilerView.
NETWORK PARAMETER DESCRIPTIONS
• IP address―Standard format is used for IP addresses (for example, 192.168.23.10). IP addresses
are mapped to host names in the /etc/hosts file.
• Netmask and broadcast address―Standard format is used for netmask and broadcast addresses
(for example, 255.255.255.0 for netmask, and 192.168.1.255 for broadcast address).
• Media type and speed―The following media types can be configured:
[ mediatype { tp | tp–fd | 100tx | 100tx–fd | 1000fx | auto }]
• MTU―Use a smaller interface MTU value if a bridge or router on the attached network cannot
break large packets into fragments.
• Flow control for the GbE II controller―The original GbE controller supports only full duplex,
not flow control. The GbE Controller II negotiates flow control with an attached device that
supports autonegotiation. However, if autonegotiation fails on either device, the flow control
setting that was entered using the ifconfig command is used. The following flow control
settings can be configured:
[ flowcontrol { none | receive | send | full } ]
• Up or down state―The state of any interface can be configured up or down.
IFCONFIG COMMAND SYNTAX
NetApp> ifconfig
usage: ifconfig [ -a | [ <interface>
[ [ alias | -alias ] <address> ] [ up | down ]
[ netmask <mask> ] [ broadcast <address> ]
[ mtusize <size> ]
[ mediatype { tp | tp-fd | 100tx | 100tx-fd 1000fx | auto } ]
[ flowcontrol { none | receive | send | full } ]
[ trusted | untrusted ]
[ wins | -wins ]
[ [ partner { <address> | <interface> } ] | [ -partner ] ] ] ]
Managing Interfaces: FilerView
NOTE: Modifications made in FilerView are persistent in

the /etc/rc file.
MANAGING INTERFACES: FILERVIEW
FilerView provides a confident and administrator-friendly way to manage network interfaces.

In addition, FilerView offers advanced functionality such as vif and VLAN management.
Any modifications made using FilerView are persisted in the /etc/rc file and will persist
through reboot.
Managing Interfaces: FilerView (Cont.)
MANAGING INTERFACES: FILERVIEW (CONT.)
FilerView provides the same level of control over a storage system’s interfaces as the
ifconfig command in the CLI.
Managing Interfaces: CLI
To configure the current status:

ifconfig
To display permanent settings:
rdfile /etc/rc
To change permanent settings:
wrfile /etc/rc
– Command overwrites the existing file
– Existing information can be cut and pasted
– Press Control-C to save changes and exit
– To activate changes to the /etc/rc file, reboot
or issue source /etc/rc
MANAGING INTERFACES: CLI
Name Resolution
NAME RESOLUTION
Host-Name Resolution
A storage system must be able to resolve host

names to valid IP addresses.
Host-name resolution is commonly used in:
– Processing CIFS requests
– Processing NFS requests
– Authenticating RSH sessions
– Many other services
HOST-NAME RESOLUTION
MAINTAINING HOST INFORMATION

Data ONTAP uses the following methods to resolve host information on a storage system:
• /etc/hosts
• DNS
• NIS
By default, the storage appliance tries first to resolve host names locally by searching the
/etc/hosts and the /etc/nsswitch.conf files.
DNS and NIS can be configured using the setup command during installation of a storage
system. Therefore, many of the commands and files included in this lesson are executed
automatically. Usually, NIS or DNS commands are only entered manually when:
• NIS or DNS was not configured during setup
• You need to make a change to a configuration
Host-Name Resolution (Cont.)
Data ONTAP stores and maintains host information in
the following locations:
/etc/hosts file
DNS server
Network Information Service (NIS) server
In host-name resolution:
The /etc/nsswitch.conf file controls the order in
which these three locations are checked.
Data ONTAP stops checking locations when a valid IP
address is returned.
NOTE: For convenience, you can use the Host Name Resolution
Policy Wizard in FilerView.
HOST-NAME RESOLUTION (CONT.)
SPECIFYING A RESOLUTION SEARCH ORDER

The /etc/nsswitch.conf file displays the order in which a storage system searches for
resolution. For example, to resolve host names, a storage appliance uses the search order list
for hosts and (in this example) searches first using the /etc/hosts file, then NIS, and then
DNS. Each line in the /etc/nsswitch.conf file uses this format. You can change the
default search order for host-name resolution at any time by modifying this file. After a
storage system resolves the host name, the search ends.
/etc/hosts Configuration
Local IP and name resolution is provided by

/etc/hosts.
To modify /etc/hosts, use:
– The rdfile and wrfile commands in CLI
– adminhost
– FilerView
/ETC/HOSTS CONFIGURATION
USING THE /ETC/HOSTS FILE FOR HOST-NAME RESOLUTION

Because the /etc/hosts file is checked first and changes in it take effect immediately, it is
important to keep this file current. You can edit the file using a standard editing program.
When using a standard editing program, be sure to include a blank line at the end. The
following is the /etc/hosts format:
IP address hostname alias(es)
/ETC/HOSTS FILE FUNCTION

The /etc/hosts file is automatically generated during the storage system setup procedure
as part of the data installation process. It is populated at that time with IP addresses and host
names.
NOTES:
• The default IP address for the local host (storage appliance) is listed in the /etc/hosts file.
• Installed cards without IP addresses are included in the /etc/hosts file, but are commented
out.
/etc/hosts Configuration: FilerView
/ETC/HOSTS CONFIGURATION: FILERVIEW
You can also manage the /etc/hosts file using the FilerView Web application. To access
and edit the file from FilerView, from the main menu, select Manage Hosts File from the
Network node.
DNS Configuration
The DNS provides a centralized mechanism for

host-name resolution in Windows and UNIX
environments.
To configure the DNS:

In FilerView, use the Host Name Resolution
Policy Wizard
In the CLI, use:
– setup command
– options dns.*
– dns command
DNS CONFIGURATION
USING DNS FOR HOST-NAME RESOLUTION

DNS matches domain names to IP addresses and enables you to centrally maintain host
information so that you do not have to update the /etc/hosts file every time you add a new
host to the network. This is particularly helpful if you have several storage appliances on your
network.
DNS is configured using options and commands.
To make the configuration commands permanent, enter them in the /etc/rc file. The
/etc/rc file is automatically generated during the setup procedure as part of the Data
ONTAP installation process. If you choose to set up DNS at that time, the file is populated
with DNS configuration information.
Use the information command dns info to display the status of the DNS resolver, a list of
DNS servers, the state of each DNS server, the default domain configured on the storage
appliance, and a list of other domains that will be used with unqualified names for name
lookup.
EXAMPLE RESULT
options dns.domainname dns_campus2 Sets the DNS domain name to dns_campus2
options dns.enable on Enables DNS
NIS
In UNIX environments, NIS provides:
A centralized mechanism for host-name resolution
User authentication
The storage system can participate as an NIS client or

server.
To configure NIS:
In FilerView, use the Host Name Resolution Policy
Wizard
In the CLI, use:
– setup command
– options nis.*
– nis command
NIS
USING NIS FOR HOS-NAME RESOLUTION

The NIS client service provides information about security-related parameters on a network
such as hosts, user passwords, user groups, and netgroups.
NIS enables you to centrally maintain host information, so you don't have to update the
/etc/hosts file on every storage appliance on your network.
While the storage system can be an NIS client and can query NIS servers for host
information, it cannot be an NIS server. As an NIS client, the storage system can be
configured as an NIS slave using the options nis.slave.enable command. The storage
system then downloads NIS maps from the NIS master servers defined in nis.servers. The
storage system NIS slave checks the master servers every 45 minutes. Downloaded maps are
stored under /etc/yp/<NIS_domain>/. If you want to use NIS as the primary method for
host resolution, specify it ahead of the other methods in the /etc/nsswitch.conf file.
Host Name Resolution Policy Wizard:
FilerView
To ease configuration, use the FilerView Host
Name Resolution Policy Wizard:
HOST NAME RESOLUTION POLICY WIZARD: FILERVIEW
The FilerView Host Name Resolution Policy Wizard configures:

• DNS
• NIS
• Name service configuration file (/etc/nsswitch.conf)
To ensure all changes are persisted, you must click the Commit button when the wizard is
finished.
Host Resolution Policy Wizard:
FilerView (Cont.)
Choose a resolution method:
HOST NAME RESOLUTION POLICY WIZARD: FILERVIEW (CONT.)
FILERVIEW METHODS OF RESOLUTION

The Host Name Resolution Policy Wizard configures DNS and NIS, but does not configure
the /etc/hosts/ file, which is the default host-resolution mechanism. The /etc/hosts
file is a mmethod always available to resolve names to addresses.
FilerView (Cont.)
Provide DNS parameters:
HOST RESOLUTION POLICY WIZARD: FILERVIEW (CONT.)
FilerView (Cont.)
List DNS server address(es):
DNS SETTINGS
DNS server parameters can also be configured through the CLI using the setup command.
FilerView (Cont.)
Specify NIS information:
IMPORTANT: You must click Commit to persist changes.
FilerView (Cont.)
Specify NIS Group Parameters:
FilerView (Cont.)
Specify the order for the Name Service
Configuration:
FilerView (Cont.)
Commit the changes:
Route Resolution
ROUTE RESOLUTION
Route Information
A route defines the direction to a network or

host.
To display the current routing table:
In CLI, use netstat -r
system> netstat -r
Routing tables
Internet:
Destination Gateway Flags Refs
default 66.166.149.161 UGS 14
66.166.149.160/2 link#1 UC 0
66.166.149.161 0:20:6f:10:25:7a UHL
FilerView
ROUTE INFORMATION
ROUTING
A storage appliance does not function as a router for other network hosts, even if it has
multiple network interfaces.However, the storage appliance does route its own packets.
To display the defaults and explicit routes your storage appliance uses to route its own
packets, use the netstat -r command to view the current routing table. The netstat
command displays network-related data structures.
MODIFYING THE ROUTING TABLE

The route command allows you to manually manipulate the network routing table for a
specific host or network specified by destination.
To add or delete a specific host or network route in the routing table, use route.
COMMAND RESULT
route add default 10.10.10.1 1 Adds a default route through 10.10.10.1 with a metric (hop) of 1
route delete 193.20.8.173 Deletes the route destination 193.20.8.173 connecting through
193.20.4.254 193.20.4.254
The netstat Command
Use the netstat –r command to view or

change the network routing tables
Use the netstat –nr command to view or
change the network routing tables with IP
addresses (instead of name resolution)
Use the netstat –rs command to view or
display the per protocol statistics
THE NETSTAT COMMAND
The netstat command symbolically displays the contents of various network-related data
structures. There are a number of output formats, depending on the options chosen. Use the
man page to see all available options.
The route Command
Use the route -s command to show routing

tables
Use the route -f command to flush all
gateway entries in the routing table
Use the route –ns command to view
network routing tables with IP addresses
(instead of name resolution)
THE ROUTE COMMAND
The route command allows you to manually manipulate the network routing table for a
specific host or network specified by destination.
Virtual Interfaces
VIRTUAL INTERFACES
Virtual Interfaces
Virtual interfaces (VIFs) allow:

Trunking of one or more Ethernet interfaces
Increased throughput to and from the storage
system Virtual IP Ether Channel Switch
Load Balancing
VIFs can be configured as:

Single-mode trunks
Multimode trunks
VIRTUAL INTERFACES
A vif is a group of Ethernet interfaces working together as a logical unit. You can group up to
16 Ethernet interfaces into a single logical interface.
The following are some advantages of vifs over single-network interfaces:
• Higher throughput―Multiple interfaces work as one
• Fault tolerance―If one vif interface goes down, the remaining interfaces maintain the connection
to the network
• Protection against a switch port becoming a single point of failure
Single-Mode VIF
In single mode, only one

interface is active. The
other interface is on
standby. Provides failover capability x
e0 e1
SINGLE-MODE VIF
SINGLEMODE TRUNK
Vifs are also known as trunks, virtual aggregations, link aggregations, or EtherChannel
virtual interfaces.
Trunks can be single-mode or multimode. In a single-mode trunk, one interface is active
while the other interface is on standby.
NOTE: A failure signals the inactive interface to take over and maintain the connection with
the switch.
Multimode VIF
In multimode, all interfaces

are active and share a
MAC address.
Provides multiplex capability x
e0 e1 e2
MULTIMODE VIF
MULTIMODE TRUNK
In a multimode trunk, all interfaces are active, providing greater speed when multiple hosts
access the storage appliance. Because the switch determines how the load is balanced among
the interfaces, it must therefore support manually-configurable trunking.
In the figure above, three active interfaces comprise the multimode trunk. If any one of the
three interfaces fail, the storage appliance remains connected to the network.
Not all switches provide this capability. Check with your switch manufacturer for more
information.
Second-Level VIF
Switch and NIC failures are transparent to clients when

communicating to system A through the Vif_A “super”
virtual interface.
Defining a virtual interface at this level provides resilience for a Quad NIC failure.
Switch X Switch Y
Vif_XA Vif_YA
Vif_YB
Vif_XB “Super” Vif_B
Quad Quad Quad Quad
Final step: Active-Active
SECOND-LEVEL VIF
A second-level vif is a group of multimode vifs. If a primary multimode vif fails, a second-
level vifs provides a standby multimode. You can use second-level vifs on a single storage
system or in a cluster.
You can set up your storage system with two double-link multimode vifs where each vif is
connected to a different switch that is capable of link aggregation over multiple ports. You
can then set up a second-level single-mode vif that contains both of the multimode vifs.
When you configure the second-level vif using the vif create command, only one of the
two multimode vifs is brought up as the active link. If all the underlying interfaces in the
active vif fail, the second-level vif activates the link corresponding to the other vif.
In the example above, “Quad” is an Ethernet card with four Ethernet ports.
Load Balancing
Load balancing is supported for multimode VIFs only:
IP-based (default)
MAC-based
Round-robin (not recommended)
Load balancing assumes an even distribution of

IP addresses, such as the following:
e0 e1 e2 e3
× × × ×
10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4
10.10.10.5 10.10.10.6 10.10.10.7 10.10.10.8
10.10.10.9 10.10.10.10 10.10.10.11 10.10.10.12
10.10.10.13 10.10.10.14 10.10.10.15 10.10.10.16
LOAD BALANCING
Load balancing ensures that all the interfaces in a multimode vif are equally utilized for
outbound traffic. Load balancing is supported for multimode trunks only, and assumes a nice
distribution of hosts. There are three methods of load balancing using the IP-based default:
• IP-based―The outgoing interface is selected based on the storage system and client’s IP address.
• MAC-based―The outgoing interface is selected on the basis of the storage system and client’s
MAC (Media Access Control) address.
• Round robin―All the interfaces are selected on a rotating basis.
Both IP-based and MAC-based address methods use a formula to determine which interface
to use for outgoing frames. The formula uses the exclusive operator (XOR) value of the last
four bits of the source destination addresses to determine which interface to return data on.
NOTE: The round-robin method provides true load balancing, but may cause out-of-order
packet delivery and retransmissions due to overruns.
Creating a VIF from the CLI:
Single-level Example
The named virtual interface is treated as a
single interface: ifconfig vif_name
Entries created on the command line are not
permanent
system> vif create single SingVif1 e3a e3b
system> ifconfig SingVif1 172.17.200.201 netmask
255.255.255.0 mediatype 100tx-fd up
system> vif favor e3a
system> ifconfig SingVif1
SingVif1:flags=1148043<UP,BROADCAST,RUNNING,MULTICAST,TC
PCKSUM> mtu 1500
inet 172.17.200.201 netmask 0xffffff00 broadcast
172.17.200.255
ether 02:a0:98:03:28:8e (Disabled virtual interface)
CREATING A VIF FROM THE CLI: SINGLE-LEVEL EXAMPLE
You create and modify a trunk using vif commands. A trunk name must be unique, must
begin with a letter, contain no spaces, and must not exceed 15 characters. After you create the
trunk, configure it like a regular network interface using the ifconfig command.
USING FILERVIEW TO CONFIGURE A VIF

In addition to creating vifs using the CLI, you can use FilerView to create and configure any
type of vif.
STEP 1
Enter the command:
vif create single vif_name [interface_list]
where vif_name is the name of the vif
and interface_list is a list of the interfaces you want the vif to consist
of.
NOTE: You must ensure that all interfaces to be included in the vif are configured down.
You can use the ifconfig command to configure an interface down.
Example:
To create a single-mode vif with the name SingleTrunk1:
vif create single SingleTrunk1 e0 e1
STEP 2
Enter the command:
ifconfig vifname IP_address netmask mask
where vifname is the name of the vif
IP_address is the IP address for this interface
and mask is the network mask for this interface.
Example:
To configure an IP address of 10.120.5.74 and a netmask of 255.255.255.0 on the single-
mode vif SingleTrunk1 that was created in the previous example:
ifconfig SingleTrunk1 10.120.5.74 netmask 255.255.255.0
STEP 3
To change the active interface in a single-mode vif, enter the command:
vif favor interface
where interface is the name of the interface you want to be active.
Example:
To specify the interface e1 as preferred:
vif favor e1
STEP 4
To check the status of your new interface, enter the command:
ifconfig vifname
where vifname is the name of the new interface.
STEP 5
To make a new vif permanent, update the /etc/rc file by entering the command:
wrfile -a /etc/rc
ifconfig SingleTrunk1 10.120.5.74 netmask 255.255.255.0
vif favor e1
STEP 6
Verify your changes to the /etc/rc file by entering one of the following commands:
rdfile /etc/rc
source /etc/rc
Multilevel Example
system> vif create multi multiVif2 e3a e3b e3c e3d
system> ifconfig multiVif2 172.17.200.202 netmask
system> ifconfig multiVif2
multiVif2:flags=1148043<UP,BROADCAST,RUNNING,MULTICAST,
TCPCKSUM> mtu 1500
172.17.200.255
ether 02:a0:98:03:28:8e (Disabled virtual interface)
CREATING A VIF FROM THE CLI: MULTILEVEL EXAMPLE
This procedure enables you to create a static or dynamic multilevel vif on your storage
system. By default, the load-balancing method based on IP address is used for a multilevel
vif. However, you can select another method when creating the vif. Once a load-balancing
method has been assigned to a vif, it cannot be changed.
STEP 1
To create a static multimode vif, enter the command:
vif create multi vif_name -b {rr|mac|ip} [interface_list]
Or, to create a dynamic multimode vif, enter the command:
vif create lacp vif_name -b {rr|mac|ip} [interface_list]
where -b specifies one of the following load-balancing methods:
• rr―round robin
• mac―based on MAC address
• ip―based on IP address (default)
NOTE: For dynamic multimode vifs, use the ip load-balancing method.
vif_name is the name of the vif
and interface_list is a list of the interfaces that make up the vif.
Example
To create a multimode vif made up of interfaces e0, e1, e2, and e3 using MAC-based load
balancing:
vif create multi MultiTrunk1 -b mac e0 e1 e2 e3
STEP 2
Enter the command:
ifconfig vifname IP_address netmask mask
where vifname is the name of the vif
IP_address is the IP address for this interface
and mask is the network mask for this interface.
Second-Level VIF Example
system> vif create multi multiVif1 e3a e3b
system> vif create multi multiVif2 e3c e3d
system> vif create single L2vif multiVif1 multiVif2
system> ifconfig L2vif 172.17.200.206 netmask
system> ifconfig L2vif
L2vif:flags=1148043<UP,BROADCAST,RUNNING,MULTICAST,TCPC
KSUM> mtu 1500
172.17.200.255
ether 02:a0:98:03:28:8c (Disabled virtual
interface)
CREATING A VIF FROM THE CLI: SECOND-LEVEL VIF EXAMPLE
This procedure creates a second-level vif called vif_name on a single storage system with
two multimode vifs called vif_name1 and vif_name2. The vif_name1 is composed of
two physical interfaces, if1 and if2, and vif_name2 is composed of two physical
interfaces, if3 and if4.
STEP 1
To create two multimode interfaces, enter the commands:
vif create multi -b {rr|mac|ip} vif_name1 if1 if2
vif create multi -b {rr|mac|ip} vif_name2 if3 if4
where -b specifies one of the following load-balancing methods:
• rr―round robin
• mac―based on MAC address
• ip―based on IP address (default)
vif Commands
vif create [single|multi]

<vif_name> [-b [rr|ip|mac]]
[<interface_list>]
vif delete <vif_name>
[interface_list]
vif destroy <vif_name>
vif add <vif_name>
<interface_list>
vif [favor|nofavor] <interface>
vif status [<vif_name>]
vif stat vif_name [interval]
VIF COMMANDS
EXAMPLE RESULT
vif create single Creates a single-mode trunk vif on interfaces e1 and e2. Enter this
SingleTrunk e1 e2 command into the /etc/rc file to make it persistent over reboots.
vif delete MultiTrunk1 e2 Removes interfaces e2 and e3 on MultiTrunk1.

e3
vif destroy SingleTrunk1 Deletes the trunk SingleTrunk1.
vif add MultiTrunk1 e2 e3 Adds interfaces e2 and e3 to MultiTrunk1. Modify the existing vif
create command in the /etc/rc file to make it persistent over
reboots.
vif favor e0 Specifies the active interface in a single-mode trunk. If no link is
specified, the active link is randomly chosen. Enter this command into
the /etc/rc file to make it persistent over reboots.
vif status SingleTrunk1 Displays the status of the specified virtual interface. If no interface is
specified, displays the status of all virtual interfaces.
vif stat SingleTrunk1 10 Displays the number of packets received and transmitted on each
interface. You can specify the time interval (in seconds) at which the
statistics are displayed. If no number is entered, statistics are displayed
by default at two-second intervals.
Creating a VIF with FilerView
After the VIF is created, assign it an address

using ifconfig.
CREATING A VIF WITH FILERVIEW
After a vif is created using either the CLI vif command or FilerView, you must assign an
address to the vif. To configure the vif as if it were a single interface, use the ifconfig
command
Virtual LANs
VIRTUAL LANS
Virtual LANs
Virtual LANs (VLANs) provide:

Increased IP network security
Optimized packet routing
VLAN 0
VLAN 1 VLAN 2
Floor 1 0
1
2
1
Floor 2
2
VIRTUAL LANS
A virtual local area network (VLAN) is a switched network that is logically segmented by
function, project team, or applications. End stations can be grouped by department, by
project, or by security level. End stations can be geographically dispersed and still be part of
the broadcast domain in a switched network.
ADVANTAGES OF VLANS
• Ease of administration―VLANs enable a logical grouping of users who are physically
dispersed. Moving to a new location does not interrupt membership in a VLAN. Similarly,
changing job functions does not require moving the end station because it can be reconfigured into
a different VLAN.
• Confinement of broadcast domains―VLANs reduce the need for routers on the network to
contain broadcast traffic. Packet flooding is limited to the switch ports on the VLAN.
• Reduction of network traffic―Because the broadcast domains are confined to the VLAN, traffic
on the network is significantly reduced.
• Enforcement of security―End stations on one VLAN cannot communicate with end stations on
another VLAN unless a router is connected between them.
Creating a VLAN from the CLI
system> ifconfig e3b down

system> vlan create e3b 10
vlan: e3b-10 has been created
system> ifconfig e3b-10 172.17.200.201 netmask
system> ifconfig –a
e3b:flags=80908043<BROADCAST,RUNNING,MULTICAST,TCPCKSUM
,VLAN> mtu 1500
ether 00:a0:98:03:28:8f (auto-1000t-fd-up)
flowcontrol full
CREATING A VLAN FROM THE CLI
Use the vlan create and the ifconfig commands to create and configure a VLAN.
The vlan create command:

• Creates a VLAN interface
• Includes the VLAN interface in one or more VLAN groups as specified by the VLAN identifier
• Enables VLAN tagging
• Enables (optionally) GVRP on the VLAN interface
After creating the VLAN interface with the vlan command, you can configure it using the
ifconfig command.
vlan Commands
Use the following commands for VLANs:

– vlan create –g on <ifname> <vlanid …>
– vlan delete [-q] <ifname> <vlanid>
– vlan add <ifname> <vlanid [vlanid …]>
– vlan stat <ifname> <vlanid>
– vlan modify –g [on|off] <ifname>
Supported VLAN IDs are 1–4094
NOTE: VLAN ID 1 is used by a number of switch vendors.
VLANs over VIFs are supported
Use the /etc/rc file to persist configurations during
reboot
VLAN COMMANDS
A VLAN is created using the vlan create command in the CLI or in FilerView. After
creating the trunk, you can configure it like any other regular network interface using the
ifconfig command.
EXAMPLE RESULT
vlan create –g on e4 2 3 Creates three VLANs on interface e4 named e4-2, e4-3, and e4-4. The
4 -g on option enables GVRP on the VLANs. Enter this command in
the /etc/rc file to make it persistent over reboots.
vlan delete –q e8 2 Removes VLAN e8-2. If the interface was configured up, a message
appears asking you to confirm the deletion.
vlan add e8 3 Adds e8-3 to the VLAN. Enter this command in the /etc/rc file to
make it persistent over reboots.
vlan stat e4 10 Displays the number of packets received and transmitted on each
interface. You can specify the time interval (in seconds) at which the
statistics are displayed. If no number is entered, statistics are displayed
by default at two-second intervals.
vlan modify –g off e8 Interface e8 is excluded from participating with GVRP. Enter this
command in the /etc/rc file to make it persistent over reboots.
Module Summary
Use the ifconfig command to configure interfaces
Identify host-name resolution methods:
– /etc/hosts file
– DNS
– NIS
Explain how a VIF is a single virtual interface created
from multiple physical interfaces
Identify trunking modes supported on the storage
system:
– Single mode―failover
– Multimode―increased bandwidth
Explain how VLANs increase IP network security by
tagging specific packets with the appropriate VLAN ID
MODULE SUMMARY
Exercise
Module 5: Networking
EXERCISE
Physical Storage

MODULE 6: PHYSICAL STORAGE MANAGEMENT
Physical Storage
Management
Module 6
PHYSICAL STORAGE MANAGEMENT
6-1 Data ONTAP® 7.3 Fundamentals: Physical Storage Management
Module Objectives

Describe Data ONTAP RAID technology
Identify a disk in a disk shelf based on its ID
Execute commands to determine disk ID
Identify a hot-spare disk in an FAS system
Calculate usable disk space
Describe the effects of using multiple disk
types
Execute aggregate commands in Data ONTAP
Define and create an aggregate
MODULE OBJECTIVES
Disks
DISKS
Disks
All data is stored on disks

To understand how physical media is
managed in your storage system, we will
address:
– Disk types
– Disk qualification
– Disk ownership
– Spare disks
DISKS
Supported Disk Topologies
FC-AL
FAS2000 FAS3000 FAS6000

SATA
FAS2000 FAS3000 FAS6000 R200
SUPPORTED DISK TOPOLOGIES
FIBRE CHANNEL ARBITRATED LOOP

Fibre Channel-Arbitrated Loop (FC-AL) is a Fibre Channel topology that requires no switch.
NetApp uses this topology to connect supported storage controllers and disk shelves in a type
of loop.
SERIAL ATA
Serial ATA (SATA) is a successor of the Advanced Technology Attachment (ATA) standard.
NetApp uses this topology to connect supported storage controllers and disk shelves in a
high-speed serial link.
Disk Qualification
Use only NetApp Qualified Disks Modifying the Disk

Qualification Requirement
file can cause your
storage system to halt.
DISK QUALIFICATION
NetApp storage systems only support disks qualified by NetApp. Disks must be purchased
from NetApp or an approved reseller.
UNQUALIFIED DISKS
Data ONTAP automatically detects unqualified disks. If you attempt to use an unqualified
disk, Data ONTAP responds by issuing a “delay forced shutdown” warning, giving you 72
hours to remove and replace the unqualified disk before a forced system shutdown occurs.
In addition, when Data ONTAP detects an unqualified disk it takes the following actions:
• Provides notification through syslog entries, console messages, and AutoSupport
• Generates an automatic error message and delayed forced shutdown if the
/etc/qual_devices file is modified
• Marks unsupported drives as “unqualified.”
DISK QUALIFICATION
If you install a new disk drive into your disk shelf and the storage system responds with an
unqualified disk error message, you must remove the disk and replace it with a qualified disk.
To correct an unqualified disk error and avoid a forced shutdown, complete the following
steps:
1. Remove any disk drives not provided by NetApp or an authorized NetApp vendor or reseller.
2. To update your list of qualified disks, download and install the most recent
/etc/qual_devices file from http://now.netapp.com/NOW/download/tools/diskqual/.
3. If the unqualified disk error message persists after installing an up-to-date
/etc/qual_devices file, try reinstalling the/etc/qual_devices file.
4. If the reinstallation fails, remove the unqualified disk and contact NetApp Technical Support.
DISK FIRMWARE UPDATES

Disk firmware updates are included in new Data ONTAP upgrades. However, if you receive a
NetApp = Field Alert recommending that you install a new version of the disk firmware, and
you are not upgrading the operating system, you can download disk firmware separately.
Download disk-drive firmware images from the NOW site at:
http://now.netapp.com/NOW/download/tools/diskfw/.
NOTE: From the disk firmware download page on the NOW site, you can download either
an individual disk firmware image or a tarball that contains all the current disk firmware
images.
To install disk firmware images from the tarball, complete the following steps:
1. Download either the all.gz or all.zip tarball file (depending which format you choose).
2. From your client, mount (or map) to the /vol/vol0 root volume of the storage system. Next,
change directory to the /etc/disk_fw directory of the storage system.
3. If the format for the tarball file is all.zip (for Windows clients), then run an unzipping program
like WinZip to uncompress and extract disk firmware files.
If the format for the tarball file is all.gz (for UNIX clients), then run gunzip all.gz to
create a tar file named all, and then use tar xvf all to extract all of the disk firmware
images.
The /etc/disk_fw directory should now have all the current disk firmware images stored.
Disk Ownership
Disks must be assigned to (owned by) a

controller.
Software Disk Ownership Hardware Disk Ownership
Ownership is assigned Ownership is based on slot used
FAS270 R200
FAS3000 series FAS250
FAS2000 series FAS3000 series
FAS6000 series
DISK OWNERSHIP
Disk ownership can be hardware-based or software-based.
HARDWARE-BASED OWNERSHIP
In hardware-based disk ownership, disk ownership and pool membership is determined by the
slot position of the HBA or onboard port, and the shelf module port where the HBA is
connected.
SOFTWARE-BASED OWNERSHIP
In software-based disk ownership, disk ownership and pool membership is determined by the
storage system administrator. Data ONTAP might also set disk ownership and pool
membership automatically, depending on the initial configuration. Slot position and shelf
module port does not affect disk ownership.
Disk Ownership
system> sysconfig -r
Volume vol0 (online, normal) (block checksums)
Plex /vol0/plex0 (online, normal, active)
RAID group /vol0/plex0/rg0 (normal)
RAID Disk Device HA SHELF BAY CHAN Used (M...
parity 3a.16 4a 1 0 FC:A 17000/...

data 3b.17 4a 1 1 FC:A 17000/...
Disk ID = Loop_id.Device_id
DEVICE OWNERSHIP
DISK ID
Disks are numbered in all storage systems. Disk numbering allows you to:
• Interpret messages displayed on your screen such as command output or error messages
• Quickly locate a disk associated with a displayed message
To determine a disk ID, use the sysconfig –r, vol status –r, or aggr status –r
commands.
Disk Ownership: Loop_id
The loop_id is the designation

for the slot and port where an
adapter is located. In the
following illustration, the loop_id
is 3b.
3b
PROPER LY SH UT DOWN SYST EM BEF ORE OPENING C HASSIS.
DISC ONN ECT AC POWER DISC ONN ECT AC POWER
CORD BEFOR E R EMOVAL CORD BEFOR E R EMOVAL
PCI 1 PCI 3
I I
O O
PCI 2 PCI 4
Console
e0a e0b RLM e0c e0d
L 0a F C 0b L L 0c F C 0d L
I I I I
N N N N
0e LVD SCSI
K K K K
AC AC
L L L L
I I I I
N 0a F C 0b N e0a e0b RLM e0c e0d N 0c F C 0d N
Console 0e LVD SCSI
K K K K status status
DEVICE OWNERSHIP: LOOP_ID
Disks are numbered based on a combination of loop_id and device_id, represented as

Loop_ID.Device_ID, as shown in the graphic.
Loop ID is the adapter number associated with the disk, while Device ID is the logical loop
ID of the disk.
In the figure above, the disk with the ID 3a is on the loop connected to host adapter port A,
slot 3.
Disk Ownership: Device_id
Shelf ID
13 12 11 10 9 8 7 6 5 4 3 2 1 0 Bay Number
Shelf ID Bay Number Device ID

1 13–0 29–16
2 13–0 45–32
3 13–0 61–48
4 13–0 77–64
5 13–0 93–80
6 13–0 109–96
7 13–0 125–112
DEVICE OWNERSHIP: DEVICE_ID
FC LOOP IDS
The table above shows the numbering system for FC loop IDs.
For DS14 Series shelves, the following IDs are reserved (not used): 0-15, 30-31, 46-47, 62-
63, 78-79, 94-95, 110-111.
The numbering system in the table above can be summarized by the following formula:
DS14 Disk/Loop ID = DS14 Shelf ID * 16 + Bay Number
The fcstat device_map Command
Use the fcstat command to troubleshoot

disks and shelves.
Use the fcstat device_map command to
show disks and their relative physical position
map of drives on an FC loop.
THE FCSTAT DEVICE_MAP COMMAND
An FC loop is a logically closed loop from a frame transmission perspective. Consequently,

signal integrity problems caused by a component upstream will be seen as problem symptoms
by components downstream. The relative physical position of drives on a loop is not
necessarily related directly to their loop IDs (which are, in turn, determined by the drive shelf
IDs). To determine the relative physical positions of drives on a loop, use the device_map
subcommand,.
The device_map subcommand displays:
• The relative physical position of drives on the loop as if the loop was one flat space
• The mapping of devices to shelves, which allows you to quickly correlate disk IDs with shelf
tenancy
Matching Disk Speeds
When creating an aggregate or traditional

volume, Data ONTAP selects disks:
– With same speed
– That match speed of existing disks
Data ONTAP verifies that adequate spares are
available
MATCHING DISK SPEEDS
If disks with different speeds are present on a NetApp system (for example, 10,000 RPM and
15,000 RPM disks), Data ONTAP attempts to avoid mixing them in one aggregate or
traditional volume.
By default, Data ONTAP selects disks:
• With the same speed when creating an aggregate or traditional volume in response to the following
commands:
• aggr create
• vol create
• That match the speed of existing disks in the aggregate or traditional volume that requires
expansion or mirroring in response to the following commands:
• aggr add
• aggr mirror
• vol add
• vol mirror
If you use the -d option to specify a list of disks for commands that add disks, the operation
fails if disk speeds differ from each other or differ from the speed of disks already included in
the aggregate or traditional volume. The commands for which the -d option will fail in this
case are aggr create, aggr add, aggr mirror, vol create, vol add, and vol
mirror. For example, if you enter aggr create vol4 -d 9b.25 9b.26 9b.27 and two
of the disks are different speeds, the operation fails.
When using the aggr create or vol create commands, you can use the -R rpm option to
specify the type of disk used based on its speed. The –R rpm option is only necessary for
systems using different disks with different speeds. Typical values for rpm are 5400, 7200,
10,000, and 15,000. The -R option cannot be used with the -d option.
If you are going to specify a disk speed and you are not sure of its actual speed, use the
sysconfig -r command to first determine actual disk speed.
NOTE: It is possible to use the –f option to override the RPM check, but NetApp does not
recommend this practice. Using the –f option in this situation can produce an aggregate or
traditional volume that does not meet performance expectations.
Data ONTAP periodically checks to see if adequate spares are available for the storage
system. Only disks with matching speeds are considered acceptable spares. However, if a disk
fails and a spare with matching speed is not available, Data ONTAP may use a spare with a
different speed for RAID reconstruction.
NOTE: If an aggregate or traditional volume includes disks with different speeds, and
adequate spares are present, you can use the disk replace command to replace
mismatched disks. Data ONTAP uses Rapid RAID Recovery to copy these disks to more
appropriate replacements.
Using Multiple Disk Types in an Aggregate
Drives in an aggregate can be:

– Different speeds
– On the same shelf or on different
shelves
Avoid mixing drive types within an
aggregate
The spares pool is global
12
34 56
USING MULTIPLE DISK TYPES IN AN AGGREGATE
MIXING AND MATCHING DISKS

The storage system allows the use of various disk sizes, which sometimes occurs when disks
are purchased after the original equipment is set up.
However, different-sized disks require different versions of Data ONTAP and different disk
shelves. For specific information about your system, see the System Configuration Guide on
the NOW site.
You must ensure that parity and hot spare disks are as large as the largest disk in a RAID
group so they can support all the stripes on the data disks. When creating RAID groups with
disks of different sizes, Data ONTAP assigns parity to the largest disk. If you later add larger
disks to the RAID group, Data ONTAP reassigns parity to the largest of those disks.
NOTE: While mixing disk sizes in a volume is a supported configuration, this can lead to
suboptimal volume performance. NetApp recommends that all disks in a volume be the same
size.
Spare Disks
What is the purpose of spare disks?

– Increase aggregate capacity
– Replace failed disks
– Zeros disk automatically when the disk is
brought into use
It is best to zero drives in the spares pool in
advance, allowing Data ONTAP to use the
drives immediately
system> disk zero spares
SPARE DISKS
ADDING SPARES
You can add spare disks to an aggregate to increase its capacity. If the spare is larger than the
other data disks, it becomes the parity disk. However, it does not use the excess capacity
unless another disk of similar size is added. The second larger additional disk has full use of
additional capacity.
REPLACING FAILED DISKS WITH SPARES

If a disk fails, a spare disk is automatically used to replace the failed disk. If a larger disk is
selected to replace a smaller disk, the excess capacity of the larger disk is not used.
ZEROING USED DISKS

After you have assigned ownership to a disk, you can add that disk to an aggregate on the
storage system that owns it, or leave it as a spare disk on that storage system. If the disk has
been used previously in another aggregate, you should zero the disk (using the disk zero
spares command) to reduce delays when the disk is used.
Sizing
SIZING
Disk Sizing
To properly provision NetApp storage systems,

you must know how disk sizes are calculated:
All disks are right-sized
Count the size of data disks, not parity disks
NOTE: The df command does not reflect parity disks.
Use df -h to view the output in a format you
can read
DISK SIZING
CALCULATING USABLE AND PHYSICAL SPACE FOR A VOLUME

In a volume, usable space is different from physical capacity. To display the amount of free
(usable) disk space in one or all volumes on a storage system use the df command. The total
amount of disk space shown in the df output is less than the sum of available space on all
disks installed in the volume.
RAID GROUP PARITY DISK(S)

The df command does not display information about parity disks. If a volume is configured
for RAID-4 protection, it has one parity disk. If a volume is configured for RAID-DP
protection, it has two parity disks.
NOTE: Data ONTAP 6.5 and later supports RAID 4 and RAID-DP, which you can assign on
a per-volume basis.
Right-Sizing
Disk Type Disk Size Right-Sized Capacity Available Blocks

FC/SCSI 72 GB 68 GB 139,264,000
144 GB 136 GB 278,528,000
300 GB 272 GB 557,056,000
ATA/SATA 160 GB 136 GB 278,258,000
250 GB 212 GB 434,176,000
320 GB 274 GB 561,971,200
500 GB 423 GB 866,531,584
NOTE: ATA drives have only 512 bytes per sector and lose an
additional 1/9 or 12.5% due to block checksum allocation.
RIGHT-SIZING
Some disks have slightly more capacity, depending on the manufacturer and model. Disk
drives in the same size category that are made by different manufacturers can differ slightly in
size. Data ONTAP "right sizes" these disks and makes all usable disk space the same. Right-
sizing ensures that disks are compatible regardless of manufacturer.
When you add a new disk, Data ONTAP reduces the amount of space available for user data
on that disk by rounding down. This maintains compatibility across disks from different
manufacturers. This means that the available disk space displayed using an informational
command such as sysconfig is less than each disk’s rated capacity. The table above,
reprinted from the Storage Management Guide, shows how Data ONTAP rounds down
available disk space.
NOTE: Existing disks in an upgraded system are not automatically right-sized. Right-sizing
is applied only to disks that are added to the storage system. To compare physical space and
usable space, and to determine if disks are right-sized, use sysconfig -r.
FC VERSUS ATA
FC drives have 520 bytes per sector, while ATA drives have 512 bytes per sector. When data
is written to an FC disk, the checksum can be saved within the sector. However, for ATA
drives, the checksum must be reallocated. Because of this, a disk with 512 bytes per sector
has only 8/9 of the space of an equivalent disk with 520 bytes per sector, resulting in a 12.5%
loss.
Usable Disk Space
When disks are right-sized, 10% of the space

is reserved for WAFL. This reserved space is:
– Used for system and core usage to maximize
disk efficiency
– Similar to other operating systems (for example,
the UNIX FFS)
The space that remains after right-sizing is
usable disk space, which can be used for
either:
– Traditional volumes
– Aggregates with flexible volumes
USABLE DISK SPACE
Similar to the UNIX FFS (Fast File System), the storage system reserves 10% of its total disk
space for efficiency . The df command does not count this 10% as part of the file system
space.
Disk Space Allocation: Aggregates
Aggregates with a Aggregate
Space
Traditional Volume—Each
aggregate has 10%
10% WAFL Overhead
allocated for WAFL.
Traditional Volumes—Each
volume has 20% allocated
for Snapshot reserve. The
remainder is used for client
data. WAFL Aggregate 80%
Space
Snapshot Reserve—The
90%
amount of space allocated
for Snapshot reserve is
adjustable. To use this
space for data (not
Snapshot Reserve
recommended), you must
manually override the 20%
(Adjustable)
allocation used for
Snapshot copies.
DISK SPACE ALLOCATION: AGGREGATES
DISK SPACE ALLOCATION FOR TRADITIONAL VOLUMES
AGGREGATES
The size of an aggregate depends on the number and size of disks allocated to it. In an
aggregate, 10 % is allocated for WAFL.
TRADITIONAL VOLUMES
An aggregate can include only one traditional volume. A traditional volume has 20%
allocated for Snapshot reserve, with no aggregate overhead.
SNAPSHOT RESERVE
Like flexible volumes, the space used for the Snapshot reserve in a traditional volume can be
expanded into user space as required by the system. This expansion could occur, for example,
if numerous changes are made to the active file system. If necessary, the Snapshot reserve
expands into user space as Snapshot copies are made, regardless of the designated Snapshot
reserve percentage.
You can manually reallocate disk space using the snap reserve command. However,
unless you specifically readjust the user data space on a volume, it will never exceed 80% of
the usable disk space.
Disk Space Allocation: Flexible Volumes
Aggregates—Each Aggregate
Space
aggregate has 5%
allocated for Snapshot FlexVol
10% WAFL Overhead
reserve and 10% allocated Space
Plus
for WAFL. WAFL Aggregate Aggregate
Snapshot
Flexible Volumes—Each Space
Reserve
volume has 20% allocated
for Snapshot reserve. The FlexVol1x 80%
remainder is used for client
data. .snapshot 20% 95%
90%
Snapshot Reserve—The
amount of space allocated
for Snapshot reserve is FlexVol#n 80%
adjustable. To use this
space for data (not .snapshot 20%
recommended), you must
manually override the Aggregate Snapshot Reserve 5%
(Adjustable)
allocation used for
Snapshot copies.
DISK SPACE ALLOCATION: FLEXIBLE VOLUMES
AGGREGATES
The size of an aggregate depends on the number and size of disks allocated to it. Five percent
of the aggregate is allocated as Snapshot reserve for aggregate Snapshot copies, while 10 %
of the aggregate is allocated for WAFL.
FLEXIBLE VOLUMES
An aggregate can include more than one flexible volume. However, each flexible volume
allocates 20% for Snapshot reserve. To use the Snapshot reserve space for data (not
recommended), you must manually override the allocation used for Snapshot copies, allowing
the remainder to be used for client data.
SNAPSHOT RESERVE
The Snapshot reserve for aggregates does not automatically expand into the WAFL aggregate
space. When space is needed for Snapshot copies, by default, the older aggregate Snapshot is
deleted to accommodate a new Snapshot. You can adjust the Snapshot reserve size in an
aggregate using the snap reserve –A command.
In volumes, the space used for the Snapshot reserve expands into user space as required by
the system. This expansion could occur, for example, if numerous changes are made to the
active file system. If necessary, the Snapshot reserve expands into the user space as Snapshot
copies are taken, regardless of the designated Snapshot reserve percentage. You can manually
reallocate disk space using the snap reserve command.
Disk Protection
DISK PROTECTION
Disk Protection
Data ONTAP protects disks through:

– RAID
– Disk scrubbing
Data ONTAP can assist in recovering from disk
failures
DISK PROTECTION
RAID Groups
RAID groups are a collection of data disks and

parity disks
RAID groups provide protection through parity
Data ONTAP organizes disks into RAID groups
Data ONTAP supports:
– RAID 4
– RAID-DP™
RAID GROUPS
A RAID group includes several disks linked together in a storage system. While there are
different implementations of RAID, Data ONTAP supports only RAID 4 and RAID-DP. To
understand how to manage disks and volumes, it is important to first understand the concept
of RAID.
In Data ONTAP, each RAID 4 group consists of one parity disk and one or more data disks.
The storage system assigns the role of parity disk to the largest disk in the RAID group.
When a data disk fails, the storage system identifies the data on the failed disk and rebuilds a
hot spare with that data.
RAID-DP provides double-parity protection against a single- or double-disk failure within a
RAID group. The minimum number of disks in a RAID-DP group is three—one data disk,
one parity disk, and one double-parity (DP) disk.
NOTE: If a parity disk fails, it can be rebuilt from data on the data disks.
RAID 4 Technology
RAID 4 protects against data loss that results from a

single-disk failure in a RAID group
A RAID 4 group requires a minimum of two disks:
– One parity disk
– One data disk
Parity Data Data Data Data Data Data Data
RAID 4 TECHNOLOGY
RAID 4 protects against data loss due to a single-disk failure within a RAID group.
Each RAID 4 group contains the following:
• One parity disk (assigned to the largest disk in the RAID group)
• One or more data disks
Using RAID 4, if one disk block goes bad, the parity disk in that disk's RAID group is used to
recalculate the data in the failed block, and then the block is mapped to a new location on the
disk. If an entire disk fails, the parity disk prevents any data from being lost. When the failed
disk is replaced, the parity disk is used to automatically recalculate its contents. This is
sometimes referred to as row parity.
RAID-DP Technology
RAID-DP protects against data loss that results from
double-disk failures in a RAID group
A RAID-DP group requires a minimum of three disks:
– One parity disk
– One double-parity disk
– One data disk
Parity Double- Data Data Data Data Data Data

Parity
RAID-DP TECHNOLOGY
RAID-DP technology protects against data loss due to a double-disk failure within a RAID
group.
Each RAID-DP group contains the following:
• One data disk
• One parity disk
• One double-parity disk
RAID-DP employs the traditional RAID 4 horizontal row parity. However, in RAID-DP, a
diagonal parity stripe is calculated and committed to the disks when the row parity is written.
For more information about RAID-DP processes, see Technical Report 3298 at
http://www.netapp.com/library/tr/3298.pdf.
RAID Group Size
RAID-DP
NetApp Minimum Maximum Default
Platform Group Size Group Size Group Size
All storage systems (with
3 16 14
SATA disks)
All storage systems (with
3 28 16
FC disks)
RAID 4
NetApp Minimum Maximum Default
Platform Group Size Group Size Group Size
FAS270 2 14 7
All other storage systems
2 7 7
(with SATA)
All other storage systems
2 14 8
(with FC)
RAID GROUP SIZE
RAID groups can include anywhere from 2 to 28 disks, depending on the platform and RAID
type. For best performance and reliability, NetApp recommends using the default RAID
group size.
Data Reliability
RAID-level checksums enhance data

protection and reliability
Two processes:
– options raid.media_scrub
Checks for media errors only
If enabled, runs continuously in the background
– options raid.scrub (also called “disk
scrubbing”)
Checks for media errors
Corrects parity consistency
DATA RELIABILITY
Media scrubbing checks disk blocks for physical errors. Disk scrubbing checks disk blocks on
all disks in the storage system for media errors and logical parity errors.
If Data ONTAP identifies media errors or inconsistencies, it repairs them by reconstructing
the data from parity data, and then rewriting the data back to the data disk. Disk scrubbing
reduces the chance of data loss from media errors that occur during reconstruction.
RAID Checksums
Zone Checksums (ZCS)

– Eight 512-byte sectors (4,096 bytes) per block
– Every 64th block checksums the previous 63
– WAFL never uses these checksum blocks; RAID does
– Available for V-Series
Block Checksums (BCS)
– Eight 512-byte sectors (4096 bytes) per block
– Every 64th block checksums the previous 63
– Every sector checksums itself
– Are faster than ZCS
– Are the standard for FC, SCSI and V-Series disks
– 8/9ths ATA disks; every ninth sector checksums the
previous eight
RAID CHECKSUMS
Comparing Media and RAID Scrubs
A media scrub: A RAID scrub:
Is always running in the Is enabled by default
background when the storage Can be scheduled or disabled
system is not busy – Disabling is not
Looks for unreadable blocks recommended
at the lowest level (0s and 1s) Uses RAID checksums
Is unaware of the data stored Reads a block and then
in a block checks the data
Takes corrective action when If the RAID scrub finds a
it finds too many unreadable discrepancy between the
blocks on a disk (sends RAID checksum and the data
warnings or fails a disk, read, it re-creates the data
depending on findings) from parity and writes it back
to the block
Ensures that data has not
become stale by reading
every block in an aggregate,
even when users haven’t
accessed the data
COMPARING MEDIA AND RAID SCRUBS
DISK SCRUB
Storage systems use disk scrubbing to protect data from media errors or bad sectors on a disk.
Each disk in a RAID group is scanned for errors. If errors are identified, they are repaired by
reconstructing data from parity and rewriting the data. Without this process, a disk media
error could cause a multiple disk failure while running in degraded mode.
Automatic RAID scrub is enabled by default. If you prefer to control the timing of RAID
scrubs, you can turn off the automatic scrubs. You can also manually start and stop disk
scrubbing regardless of the current value (on or off) of the raid.scrub.enable option.
ERROR MESSAGE CAUSE

Inconsistent parity on volume volume_name, RAID group Inconsistent parity block
n, stripe #n. Rewriting bad parity block on volume
volume_name, RAID group n.
Rewriting bad parity block on volume volume_name, Media error on the parity disk or a data disk
RAID group n, stripe #n.
Multiple bad blocks found on volume volume_name, More than one bad block
RAID group n, stripe #n.
Scrub found n parity inconsistencies. Scrub found n media Disk scrubbing complete
errors. Disk scrubbing finished.
About Disk Scrubbing
Automatic RAID scrub:

– By default, begins at 1 a.m. on Sundays
– Schedule can be changed by an administrator
– Duration can be specified by an administrator
Manual RAID scrub overrides automatic
settings
– To scrub disks manually:
raid.scrub.enable off
And then:
aggr scrub start
– To view scrub status:
aggr scrub status aggr_name
ABOUT DISK SCRUBBING
RAID Group Options
options raid.timeout
options raid.reconstruct.perf_impact
options raid.scrub.enable
options raid.scrub.perf_impact
vol options <volname> raidtype
aggr options <aggrname> raidtype
NOTE: For a complete list of RAID options, see your product

documentation.
RAID GROUP OPTIONS
EXAMPLE RESULT
options raid.timeout 36 Changes the amount of time the system will operate in
degraded mode from the default (24 hours) to 36 hours.
options Changes the amount of system resources allocated to

raid.reconstruct.perf_impact low reconstruction of data from the default (medium) to low
(runs when nothing else is running). Can also be set to
high (runs except when CPIO is running).
options raid.scrub.enable on Enables RAID scrub to occur automatically at 1 a.m. on
Sundays.
options raid.scrub.perf_impact low Sets scrub performance to low. Can also be set to
medium or high.
vol options vol0 raidtype raid_dp Changes the RAID type of RAID groups for vol0 to
RAID-DP. Default RAID type is RAID 4.
aggr options aggr0 raidtype raid4 Changes the RAID type of RAID groups for aggr0 to
RAID 4. Default RAID type is RAID-DP.
disk Commands
disk fail diskname

disk remove diskname
disk swap
disk unswap
disk replace [start|stop]
disk zero spares
disk scrub [start|stop]
disk sanitize
DISK COMMANDS
EXAMPLE RESULT
disk fail 4a.16 Fails the file system disk, 4a.16.
disk remove 4a.17 Removes the spare disk, 4a.17.
disk swap Prepares (quiets) external SCSI bus for swap (not required for FC-AL loops).
disk unswap Undoes disk swap (not required for FC-AL loops).
disk scrub stop Stops disk scrubbing.
disk replace start Replaces disk 4a.16 with a hot spare.
4a.16
disk zero spares Zeros all unzeroed RAID spare disks.
disk sanitize start Starts removal of all disk data by overwriting disk 4a.18 several times.
4a.18
Disk Failures
Volume 1
Raid Group 0 Spares
Parity Data Data Data
Spares are global.
DISK FAILURES
If you have a disk failure, you can use the sysconfig -r command to determine which disk
has failed. You can also obtain the same information using the vol status –r or aggr
status –r commands.
Hopefully, your system is equipped with appropriate hot spare disks. In the figure above, hot
spares are part of the storage system, but are not part of a RAID group. When a disk fails in
this configuration, the storage system automatically rebuilds data or parity on an available hot
spare disk.
REPLACING DISKS
In addition to using hot spares, you can also replace a failed disk by hot swapping it, which
means that the disk is removed or installed while the storage system is running, Hot swapping
allows new disks to be added with minimal interruption to a file system.
If two disks are removed at the same time from a RAID 4 group, a double-disk failure occurs
and data loss results. If the volume uses RAID-DP, the data is protected.
If a volume contains more than one RAID 4 group, two disks in a volume can fail as long as
the disks are not in the same RAID group.
Degraded Mode
Degraded mode occurs when:
– A single disk fails in a RAID 4 group with no spares
– Two disks fail in a RAID-DP group with no spares
Degraded modes operates for 24 hours, during which
time:
– Data is still available
– Performance is less-than-optimal
Data must be recalculated from the parity until the failed disk
is replaced
CPU usage increases to calculate from parity
System shuts down after 24 hours
To change time interval, use the options
raid.timeout command
If an additional disk in the RAID group fails during
degraded mode, the result will be data loss
DEGRADED MODE
If you experience a single-disk failure in a RAID 4 group or a double-disk failure in a RAID-

DP group and have no hot spares available, the system operates in “degraded” mode for a
specified length of time (default is 24 hours). If access to the system is limited for a specified
period, such as a long weekend, you might consider setting this to a longer time interval using
the options raid.timeout command.
NOTE: Because a longer timeout interval increases the risk of a second disk failure (and
resulting data loss), consider carefully the interval for degraded mode before changing it from
the default.
While the system does not perform optimally in degraded mode, no data is lost. However, if
the failed disk is not replaced during this interval, the system shuts down.
If a second disk in a RAID 4 group fails while the system is operating in degraded mode, it
constitutes a double-disk failure and data loss results. (In a RAID-DP group, no data loss
occurs unless a third disk fails.) For this reason, failed disks and used hot-spare disks should
be replaced as soon as possible.
Replacing a Failed Disk by Hot Swapping
Hot-swapping is the process of removing or

installing a disk drive while system is running
and allows for:
– Minimal interruption
– The addition of new disks as needed
Removing two disks from a RAID 4 group:
– Double-disk failure
– Data loss will occur
Removing two disks from a RAID-DP group:
– Degraded mode
– No data loss
REPLACING A FAILED DISK BY HOT SWAPPING
Replacing Failed Disks
750 GB
1 TB 750 GB 750 GB 750 GB 750 GB
NOTE: Disk resizing occurs if a smaller disk is replaced by a

larger one.
REPLACING FAILED DISKS
When replacing a failed disk, the size of the new disk must be equal to or larger than the
usable space of the replaced disk to accommodate all the data blocks on the failed disk.
If the usable space on the replacement disk is larger than the failed disk, the replacement disk
is right-sized to the capacity of the failed disk. The extra space on the disk is not usable.
Aggregates
AGGREGATES
Aggregates
Aggregates represent physical storage:

Made up of one or more RAID groups
A RAID group includes:
– One or more data disks
– Parity disks
RAID 4 has only one parity disk
RAID-DP has two parity disks
Data is striped for parity protection
A flexible volume depends on an aggregate for
physical storage
AGGREGATES
To support the differing security, backup, performance, and data-sharing requirements of

users, physical data storage resources on your storage system can be grouped into one or
more aggregates. Aggregates provide storage for the volume or volumes they contain.
Each aggregate has its own RAID configuration, plex structure, and set of assigned disks.
When you create an aggregate without an associated traditional volume, you can use it to hold
one or more FlexVol® volumes (logical file systems that share the physical storage resources,
RAID configuration, and plex structure of the aggregate container). When you create an
aggregate with a traditional volume tightly-bound, it can contain only that volume.
A single storage system supports up to 100 aggregates (including traditional volumes).
Naming Rules for Aggregates
An aggregate name must:

– Begin with either a letter or the underscore
character (_)
– Contain only letters, digits, and underscore
characters (_)
– Contain no more than 255 characters
NAMING RULES FOR AGGREGATES
AGGREGATE NAMES
Aggregate names must follow the naming conventions shown above. The same rules apply to
naming volumes.
Adding an Aggregate
To add an aggregate using the CLI:

aggr create
To add an aggregate using FilerView, use the
Aggregate Wizard
When adding aggregates, you must have the
following information available:
– Aggregate name
– Parity (DP is default)
– RAID group size (minimum)
– Disk selection method
– Disk size
– Number of disks (including parity)
ADDING AN AGGREGATE
Creating an Aggregate Using the CLI
The following is an example of a CLI entry used

to create an aggregate:
system> aggr create aggr_name 24
Creates an aggregate called aggr_name with

24 disks
By default, this aggregate uses RAID-DP
Using the default, 4 of the 24 disks are parity
drives
CREATING AN AGGREGATE USING THE CLI
EXAMPLES: CREATING AN AGGREGATE USING THE CLI

The following command creates the aggregate newaggr, with a RAID group size of 8,
consisting of disks with disk IDs 8a.16, 8a.17, 8a.18, and 8a.19:
aggr create newaggr -r 8 -d 8a.16 8a.17 8a.18 8a.19
The following command creates the aggregate newfastaggr, with 20 disks, the default RAID
group size, and all disks with 15,000 RPM:
aggr create newfastaggr -R 15000 20
The following command creates the aggregate newFCALaggr:

aggr create newFCALaggr -T FCAL 15
NOTE: Because FC and SAS disks are considered to be the same type, if SAS disks are
present, they might be used.
Common Aggregate Commands
aggr create <aggrname> [options]
<disklist>
aggr add <aggrname> [options] <disklist>
aggr status <aggrname> [options]
aggr rename <aggrname> <new-aggrname>
aggr show_space [-b] <aggrname>
aggr offline {<aggrname> | <plexname>}
aggr online {<aggrname> | <plexname>}
aggr destroy {<aggrname> | <plexname>}
COMMON AGGREGATE COMMANDS
Aggregate commands are similar to vol commands except that they are performed on an
aggregate. In fact, many aggr commands work on traditional volumes, and many vol
commands work on aggregates. For a complete list of commands, see your product
documentation.
Creating an Aggregate Using
the FilerView Aggregate Wizard
CREATING AN AGGREGATE USING THE FILERVIEW AGGREGATE

WIZARD
Aggregate Size
In Data ONTAP prior to version 7.3:

Aggregate size is calculated using:
sysconfig –r
All disks in the aggregate (parity and data) are
included
In Data ONTAP 7.3:
Aggregate size is calculated using the size of
data disks
Only data disks in the aggregate are included
(parity disks are excluded)
AGGREGATE SIZE
CALCULATING AGGREGATE SIZE

The sysconfig command displays configuration information about your storage system.
Without any arguments, the output includes the Data ONTAP version number and a separate
line for each I/O device on the storage system.
The –r option of the sysconfig command displays RAID configuration information. The
command prints information about all aggregates, volumes, file system disks, spare disks, and
failed disks.
Module Summary

NetApp supports FC-AL and SATA disk drives
Use either FilerView or the CLI to find disk
information
Data ONTAP organizes disks into RAID groups
RAID groups consist of data disks and parity
disks
Degraded mode occurs when a single disk
fails in a RAID 4 group with no spares, or two
disks fail in a RAID-DP group with no spares
MODULE SUMMARY
Exercise
Module 6: Physical Storage
Management
EXERCISE
Logical Storage

MODULE 7: LOGICAL STORAGE MANAGEMENT
Logical Storage
Management
Module 7
LOGICAL STORAGE MANAGEMENT
7-1 Data ONTAP® 7.3 Fundamentals: Logical Storage Management
Module Objectives

Explain volume concepts in Data ONTAP
Define and create a traditional and flexible
volume
Define a FlexClone® volume
Execute vol and qtree commands
MODULE OBJECTIVES
Storage Concepts
STORAGE CONCEPTS
WAFL File System
To recap, an aggregate:
– Is a collection of disks
– Represents physical storage
A flexible volume is a collection of stored data
(including the directory) within an aggregate
WAFL keeps track of:
– The aggregate
– The flexible volumes in the aggregate
– All the data in the flexible volumes
In Data ONTAP, the file system is called Write
Anywhere File Layout (WAFL)
WAFL FILE SYSTEM
Volumes
Volumes represent logical storage

– Data ONTAP allows up to 500 volumes per
storage system
– Volumes are accessible through supported
protocols
Data ONTAP provides two types of volumes:
– Traditional
– Flexible
VOLUMES
Volumes are file systems that contain user data accessible through one or more access
protocols supported by Data ONTAP, including NFS, CIFS, HTTP, WebDAV, FTP, FCP,
and iSCSI. To maintain multiple, space-efficient, point-in-time data images for the purpose of
backup and recovery, you can create one or more Snapshot copies of the data in a volume.
Data ONTAP limits a storage system to 100 aggregates, but within those aggregates you can
create up to 500 traditional and flexible volumes.
Naming Rules for Volumes
A volume name must:

– Begin with either a letter or underscore
character (_)
– Contain only letters, digits, and underscore
characters (_)
– Contain no more than 255 characters
NAMING RULES FOR VOLUMES
Root Volumes
One root volume per storage system

Root volume /etc directory is used at boot
All volume path names begin with /vol
– The /vol path name is not a directory
– The /vol is not accessible
– You must mount each volume separately
Root volume can be either traditional or flexible
ROOT VOLUMES
The storage system contains a root volume that was created when the system was initially set
up. The default root volume name is /vol/vol0.
Storage systems with Data ONTAP 7.0 or later preinstalled have a FlexVol volume for a root
volume. Systems running earlier versions of Data ONTAP have a traditional root volume.
Root Volumes: Example
/vol Special virtual root path
/vol0 Root volume
/etc Directory (configuration information)

/users Volume
/cheryl Directory
ROOT VOLUMES: EXAMPLE
Each storage system has only one root volume, although the designated root volume can be
changed. The root volume is used to start up the storage system. It is the only volume with
root attributes, meaning that its /etc directory is used for configuration information.
Volume path names begin with /vol. For example:
/vol/vol0
where vol0 is the name of the volume
/vol/users/Cheryl
where cheryl is a directory on the users volume
NOTE: The /vol path is not a directory. It is a special virtual root path that the storage
system uses to mount other directories. You cannot mount /vol to view all of the volumes on
the storage system. You must mount each volume separately.
Traditional Volumes
TRADITIONAL VOLUMES
Traditional Volumes
A traditional volume is:

– Contained by a single, dedicated aggregate
– Independent from other aggregates
Disks are dedicated to a volume
You can change volume size by adding disks
Disks are organized into RAID groups
TRADITIONAL VOLUMES
A traditional volume is a volume contained by a single, dedicated aggregate that is tightly

coupled with the container aggregate. The only way to grow a traditional volume is to add
entire disks to the aggregate container. It is impossible to decrease the size of a traditional
volume.
All volumes created with Data ONTAP versions earlier than 7.0 are traditional volumes. If
you upgrade to Data ONTAP 7.0, your volumes and data remain unchanged, and the
commands used to manage volumes and data are still supported.
Aggregates and FlexVol Volumes
FlexVol Volumes
In FlexVol® volumes:
The Primary unit of data
storage and
management is still the
Disks Disks Disks WAFL volume
RG1 RG2 RG3
Aggregate contains the
physical storage
Aggregate
Volumes are no longer
tied to physical storage
Can be multiple FlexVol
volumes per aggregate
Storage space can be
dynamically reallocated
AGGREGATES AND FLEXVOL VOLUMES
Flexible volumes are logical data containers that can be sized, resized, managed, and moved
independently from the underlying physical storage without disrupting normal operations.
As shown in the figure above, an aggregate is defined as a pool of many disks from which
space is allocated to volumes (volumes are shown as FlexVol and FlexClone entities). From
an administrator’s perspective, volumes remain the primary unit of data management. But
transparently to the administrator, flexible volumes now refer to logical entities, not (directly)
to physical storage.
Flexible volumes are volumes that are no longer bound by the limitations of the disks on
which they reside. A FlexVol volume is simply a “pool” of storage that can be sized based on
how much data you want to store in the volume, not the physical disk capacity. You can
increase or decrease a FlexVol volume on-the-fly without any downtime. In a flexible
volume, all spindles in the aggregate are available at all times. Flexible volumes can run I/O-
bound applications must faster than traditional volumes of the same size.
Flexible volumes provide these additional benefits while preserving the familiar semantics of
volumes and the current set of volume-specific data management and space-allocation
capabilities.
How Aggregates and FlexVol Volumes
Work
Create aggregate
FlexVol 1 FlexVol 2 FlexVol 3
– RAID groups are
created as result
vol1 vol2
vol3
Create FlexVol 1
– Only metadata space is
used
– There is no preallocation
of blocks to a specific
volume
Aggregate Create FlexVol 2
RG1 RG2 RG3 – WAFL allocates
aggregate space as
RG1 RG2 RG3 data is written
Populate volumes
Aggregate
HOW AGGREGATES AND FLEXVOL VOLUMES WORK
An aggregate is a representation of physical storage space provided by a combination of

RAID groups. When a flexible volume is created, some space is used for the metadata
associated with the volume, but no other physical space in the aggregate is used. Aggregate
space is used as data is written to the flexible volume.
Metadata, also called metainformation, is data about data. In a file system, metadata is data
that describes the file system, such as the location of a file’s data blocks, and file information
such as owner, permissions, creation and modification dates, and so on.
Aggregates and FlexVol Volume
Components
FlexVol volumes are a logical
storage container that:
– Can grow or shrink nondisruptively
– Can be just a few MBs in size or as
large as (or larger than) the
aggregate
– Uses physical storage space like
qtrees
– Preserves all other volume-level
properties
Aggregates are a physical storage
pool
AGGREGATES AND FLEXVOL VOLUME COMPONENTS
FLEXIBLE VOLUMES
A flexible volume (also called a FlexVol volume) is a volume that is loosely coupled to its
container aggregate. Because the volume is managed separately from the aggregate, you can
create small FlexVol volumes (20 MB or larger), and then increase or decrease the size of
FlexVol volumes in increments as small as 4 kB.
Advantages of flexible volumes:
• You can create flexible volumes almost instantaneously. These volumes:
• Can be as small as 20 MB
• Are limited to aggregate capacity (if guaranteed)
• Can be as large as the volume capacity supported for your storage system (not guaranteed)
• You can increase and decrease a flexible volume while online, allowing you to:
• Resize without disruption
• Size in any increment (as small as 4 kB)
• Size quickly
Flexible Volumes
FLEXIBLE VOLUMES
Flexible Volumes
Flexible volumes manage the logical layer

independent of the physical layer.
Multiple flexible volumes can exist within a
single aggregate.
FLEXIBLE VOLUMES
CONSIDERATIONS FOR FLEXIBLE VOLUMES

Within an aggregate, you can create one or many flexible volumes.
FLEXIBLE VOLUME SPACE GUARANTEE

You can choose to overcommit space with flexible volumes. For more information, see
Technical Report 3348, at http://www.netapp.com/library/tr/3348.pdf.
BACKUP
You can size your flexible volumes for convenient, volume-wide data backup.
Increasing I/O Performance With FlexVol
Volumes
Regular volumes:
– Volume performance
is limited by the
number of disks in the
volume
– “Hot” volumes can’t
be helped by disks on
other volumes
FlexVol volumes:
– Spindle-sharing
makes total
aggregate
performance available
to all volumes
INCREASING I/O PERFORMANCE WITH FLEXVOL VOLUMES
Improving Space Utilization With FlexVol
Volumes
Vol 1
Vol 2 Vol 4 Traditional volumes:
Vol 3
– Free space is
scattered across
volumes
– Free space is not
Vol 1 available to other
volumes
FlexVol volumes:
Vol 2
– No pre-allocation of
Free free space
Vol 3 – Free space is
available for use by
Vol 4
other volumes or new
volumes
IMPROVING SPACE UTILIZATION WITH FLEXVOL VOLUMES
Creating a Flexible Volume
To create a flexible volume using the CLI:

vol create <volname> <aggrname>
<size>[k|m|g|t]
To create a flexible volume using FilerView,
use the Volume Wizard
When creating a flexible volume, you must
have the following information available:
– Volume name
– Aggregate name
– Language
– Space guarantee settings
CREATING A FLEXIBLE VOLUME
When you create a FlexVol volume, you must provide the following information:
• A name for the volume
• The name of the container aggregate
The size of a FlexVol volume must be at least 20 MB and no more than 16 TB (or whatever is
the largest size your system configuration supports).
In addition, you can provide the following optional FlexVol volume values:
• Language (the default language is the language of the root volume)
• Space-guarantee setting for the new volume
Creating a Flexible Volume Using the CLI
The following is an example of a CLI entry used

to create a flexible volume:
system> vol create flexvol_name aggr1 20G
This command creates a flexible volume called

flexvol_name in aggr1.
CREATING A FLEXIBLE VOLUME USING THE CLI
THE VOL COMMAND
EXAMPLE RESULT
vol create vol2 2 Creates the new volume, vol2, from spares. You can specify disks of
a certain size, enter a specific list of disks, or specify how many to
add.
vol create vol2 -n 3 Displays the command that the system will execute without actually
making any changes. In this example, vol create vol2 -d
0b.28 0b.27 0b.26 is returned.
The -n option is useful for displaying automatically selected disks,
as shown above.
vol create flexvol aggr1 Creates the new 20 GB volume, flexvol, on aggr1.
20G
vol add vol1 3 Adds three disks to the existing traditional volume, vol1.
vol status vol1 Displays the volume size, options, and so on, for vol1.
vol rename vol2 vol3 Changes the name of volume vol2 to vol3.
vol options vol3 Displays current options settings for vol3.
vol offline vol3 Removes volume vol3 from active use without restarting.
vol online vol3 Reactivates volume vol3, which was offline.

vol restrict vol3 Places volume vol3 in restricted mode.
vol destroy vol1 Turns volume vol1 (if offline) back into individual spare disks.
vol size flexvol 30G Changes the size of the flexvol volume to 30 GB.
vol size flexvol +10g Increases the size of the flexvol volume by 10 GB.
Creating a Flexible Volume Using FilerView
To create a flexible volume using FilerView:

Volumes > Add > Volume Wizard
CREATING A FLEXIBLE VOLUME USING FILERVIEW
Resizing a Flexible Volume
Use the vol size command to resize a flexible volume.
Syntax:
vol size <vol-name> [[+|-]<size>[k|m|g|t]]
Command Result
vol size flexvol 50m FlexVol volume size is changed to 50 MB
Vol size flexvol +50m FlexVol volume size is increased by 50 MB
Vol size flexvol -25m FlexVol volume size is decreased by 25 MB
RESIZING A FLEXIBLE VOLUME
FlexClone Volume Clones
Enables multiple, instant data-set clones with

no storage overhead
Provides dramatic improvement for application
test and development environments
Renders competitive methods archaic
FLEXCLONE VOLUME CLONES
FlexClone volume clones provide an efficient way to copy data for:

• Manipulation
• Projection operations
• Upgrade testing
Data ONTAP allows you to create a volume duplicate with the original volume and clone
volume sharing the same disk space for storing unchanged data.
How Volume Cloning Works
Volume cloning:
Aggregate Starts with a volume
Takes a Snapshot of the
volume
FlexVol Volume
Creates a clone (a new
volume based on the
Snapshot copy)
Parent
Snap
Modifies the original
shot volume
Modifies the cloned volume
Clone Result
Independent volume copies
are efficiently stored.
HOW VOLUME CLONING WORKS
FlexClone volumes are managed similarly to regular FlexVol volumes, with a few key
differences.
The following is a list of important facts about FlexClone volumes:
• FlexClone volumes are a point-in-time, writable copy of the parent volume. Changes made to the
parent volume after the FlexClone volume is created are not reflected in the FlexClone volume.
• You can only clone FlexVol volumes. To create a copy of a traditional volume, you must use the
vol copy command, which creates a distinct copy with its own storage.
• Before you create FlexClone volumes, you must install the FlexClone license.
• FlexClone volumes are fully functional volumes managed just like the parent volume using the
vol command.
• FlexClone volumes always exist in the same aggregate as parent volumes.
• FlexClone volumes can be cloned.
• FlexClone volumes and parent volumes share the same disk space for common data. This means
that creating a FlexClone volume is instantaneous and requires no additional disk space (until
changes are made to the clone or parent).
• A FlexClone volume is created with the same space guarantee as the parent.
• While a FlexClone volume exists, there are some operations on the parent that are not allowed.
• You can sever the connection between the parent and the clone. This is called splitting the
FlexClone volume. Splitting removes all restrictions on the parent volume and causes the
FlexClone to use its own storage.
IMPORTANT: Splitting a FlexClone volume from its parent volume deletes all existing Snapshot
copies of the FlexClone volume and disables the creation of new Snapshot copies while the
splitting operation is in progress.
• Quotas applied to a parent volume are not automatically applied to the clone.
• When a FlexClone volume is created, existing LUNs in the parent volume are also present in the
FlexClone volume, but are unmapped and offline.
Flexible Volume Clone Syntax
Use the vol clone create command to create a flexible
volume clone.
Syntax:
vol clone create <vol-name> [-s none | file |
volume] -b <parent_flexvol> [parent_snapshot>]
The following is an example of a CLI entry used to create a flexible
volume clone:
vol clone create clone1 –b flexvol1
system> vol status clone1

Volume State Status Options
clone1 online raid_dp, flex
guarantee=volume(disabled)
Clone, backed by volume 'flex1’ snapshot
clone_clone1.1'
Containing aggregate: 'aggr1'
FLEXIBLE VOLUME CLONE SYNTAX
Splitting Volumes
Volume 1 Split volumes when

Snapshot of
most of the data on a
Volume 1 volume is not shared
Replicate shared blocks
in the background
Volume 2 Result
Cloned New, permanent volume
Volume is created for forking
project data.
SPLITTING VOLUMES
Splitting a FlexClone volume from its parent removes any space optimizations currently
employed by the FlexClone volume. After the split, both the FlexClone volume and the
parent volume require the full space allocation specified by their space guarantees. After the
split, the FlexClone volume becomes a normal FlexVol volume.
When splitting clones, keep in mind the following:
• When you split a FlexClone volume from its parent, all existing Snapshot copies of the FlexClone
volume are deleted.
• During the split operation, no new Snapshot copies of the FlexClone volume can be created.
• Because the clone-splitting operation is a copy operation that could take some time to complete,
Data ONTAP provides the vol clone split stop and vol clone split status
commands to stop clone-splitting or check the status of a clone-splitting operation.
• The clone-splitting operation executes in the background and does not interfere with data access to
either the parent or the clone volume.
• If you take the FlexClone volume offline while clone-splitting is in progress, the operation is
suspended. When you bring the FlexClone volume back online, the splitting operation resumes.
• Once a FlexClone volume and its parent volume have been split, they cannot be rejoined.
vol clone split Command
The following are vol clone split command

options:
vol clone split start volname
vol clone split stop
vol clone split status [volname]
vol clone split estimate [volname]
VOL CLONE SPLIT COMMAND
HOW TO VIEW THE RESULTS OF A CLONE SPLIT COMMAND

Example:
vol clone split status:
vol clone split start clone1
Tue Oct 12 23:49:43 GMT [wafl.scan.start:info]: Starting volume clone
split on volume clone1.
Clone volume 'clone1' will be split from its parent.
Monitor system log or use 'vol clone split status' for progress.
vol clone split status
Volume 'clone1', 117193 of 364077 inodes processed (32%)
18578 blocks scanned. 18472 blocks updated.
Destroying a Volume
Destroying a volume is a two-step process:

1. Take the volume or aggregate offline:
vol offline <volname>
2. Destroy the volume using the destroy
command:
vol destroy <volname>
DESTROYING A VOLUME
There are two reasons to destroy a volume:

• You no longer need the data it contains
• You copied the data it contains elsewhere
When you destroy a traditional volume, you also destroy the container aggregate dedicated to
that volume and convert the parity disk and all data disks back into hot spares. After the
traditional volume is destroyed, you can use the disks in other aggregates, traditional
volumes, or storage systems.
When you destroy a FlexVol volume, all the disks in its container aggregate remain assigned
to that container aggregate.
Qtrees
QTREES
Qtrees
A qtree is a logically defined file system that

exists as a special subdirectory at the root of a
volume
When creating a qtree, you can:
– Partition data within a volume
– Establish special quota requirements
The maximum number of qtrees is 4,995 per
volume
Qtrees look like a directory to the client
Qtrees can be removed from the client by
removing the directory or using FilerView
QTREES
You might consider creating a qtree for the following reasons:

• You can easily create qtrees for managing and partitioning data within a volume.
• You can create a qtree to assign user- or workgroup-based usage quotas (soft or hard) and limit the
amount of storage space that a specific user or group of users can consume on the qtree to which
they have access.
CREATING QTREES
When you want to group files without creating a volume, you can create qtrees instead. When
creating qtrees, you can group files using any combination of the following criteria:
• Security style
• Oplocks setting
• Quota limit
• Backup unit
QTREES LIMITATIONS
The primary limitation of qtrees is that there is a maximum of 4,995 qtrees allowed per
volume on a storage system.
NOTE: When you enter a df command with a qtree path name on a UNIX client, the
command displays the smaller client file system limit or the storage system disk space,
making the qtree look fuller than it actually is.
Adding a Qtree
To add a qtree using the CLI:

qtree create <fullpath>
To add a qtree using FilerView:
FilerView > Volumes > Qtree > Add
ADDING A QTREE
QTREE ADVANTAGES
BACKING UP QTREES
You can back up individual qtrees to:
• Add flexibility to your backup schedules
• Modularize backups by backing up only one set of qtrees at a time
• Limit the size of each backup to one tape
Many products with NetApp software (such as SnapMirror and SnapVault) are “qtree-aware.”
When you work at the qtree level, because you are working in a smaller increment than the
entire volume, you can perform backup and recovery of files quickly.
Module Summary

Data ONTAP provides volumes for organizing
data
Traditional volumes are tightly coupled with
their aggregate and disks
Flexible volumes are loosely coupled with their
aggregate and disks
Flexible volumes enable multiple, instant data-
set clones with no storage overhead
MODULE SUMMARY
Exercise
Module 7: Logical Storage
Management
EXERCISE
CIFS

MODULE 8: CIFS
CIFS
Module 8
Data ONTAP Fundamentals
CIFS
8-1 Data ONTAP® 7.3 Fundamentals: CIFS
Module Objectives

Describe the CIFS environment
Configure the storage system to participate in
the CIFS environment
Share a resource on the storage system
Map a drive from a client to the shared
resource on the storage system
MODULE OBJECTIVES
CIFS Overview
CIFS OVERVIEW
CIFS Definition
The CIFS is a Microsoft network file-sharing

protocol that evolved from the Server Message
Block (SMB) protocol
In a CIFS environment, any application that
processes network I/O can access and
manipulate files and folders (directories) on:
– Local system
– Remote servers
CIFS supports SMB 1.0 and SMB 2.0
CIFS DEFINITION
The Common Internet File System (CIFS) is a Microsoft network file-sharing protocol that
evolved from the Server Message Block (SMB) protocol.
When using CIFS, any application that processes network I/O can access and manipulate files
and folders (directories) on remote servers similar to the way it accesses and manipulates files
and folders on the local system.
User Authentication
In a CIFS environment, the storage system

authenticates users in one of four ways:
Active Directory authentication
Microsoft® Windows NT® 4.0 domain
authentication
Windows workgroup authentication
Authentication for non-Windows workgroups
NOTE: This module focuses only on Active Directory authentication.
USER AUTHENTICATION
For information about methods of authenticating users other than Active Directory, see the
Data ONTAP CIFS Administration course.
Storage System Joining a Domain
Joining a domain Directory
Machine
name
Clients Member Domain Machine

Server Controller Accounts
STORAGE SYSTEM JOINING A DOMAIN
JOINING A STORAGE SYSTEM TO A WINDOWS DOMAIN

A Windows domain is a group of computers that share a common directory database located
on a domain controller. Each domain has a unique name, provides access to user and group
accounts, and enables centralized administration of user and group accounts.
Joining a storage system to a Windows domain provides:
• Centralized administration
• Integration into the Windows topology
• User authentication performed by the domain controllers
MEMBER SERVER
The storage system joins the Windows topology as a member server with member-server
privileges in the Active Directory environment.
User Authentication on a
Storage System in a Domain
Client B requests Authenticates Client B
User authentication
Session with Client B
Client A Client B Member Domain

Server Controller
USER AUTHENTICATION ON A STORAGE SYSTEM IN A DOMAIN
For storage systems in a domain, domain users browse the storage system for available shares
and then request access to that share.
User authentication is performed centrally on the domain controller, establishing a user
session with a storage system.
For user authentication on storage systems in a domain:
• Users must be authorized to access a share and its resources
• Data access on the storage system requires a network login to the storage system
Setting Up and
Configuring CIFS
SETTING UP AND CONFIGURING CIFS
Preparing for CIFS
To prepare a storage system to support

Windows client users, complete the following
steps:
1. License CIFS.
2. Perform the initial CIFS configuration by
running the cifs setup program.
PREPARING FOR CIFS
STEPS TO SET UP CIFS

During CIFS setup, you can perform the following tasks:
• Assign or remove WINS servers
• Configure the storage system Active Directory site information (if not already configured)
• Join the storage system to a domain or change domains
• Automatically generate /etc/passwd and /etc/group files when Network Information
Service (NIS) or Lightweight Directory Access Protocol (LDAP) is enabled
Step 1: License CIFS
The CIFS license may be preinstalled at the factory

To install a CIFS license, use either:
– Data ONTAP CLI:
license add <cifslicense>
– FilerView
STEP 1: LICENSE CIFS
USING FILERVIEW
To license CIFS from FilerView:
1. From the left navigation pane, click Filer and then click Manage Licenses.
2. Enter the CIFS license number.
3. Click Apply.
When the CIFS license is preinstalled, the cifs setup script runs immediately after the
setup script.
Step 2: Set Up CIFS
There are two ways to join a storage system to

a CIFS environment:
– Data ONTAP CLI
cifs setup
– FilerView
If the setup is successful, the CIFS server
starts automatically
STEP 2: SET UP CIFS
JOIN A DOMAIN USING THE CLI

To join a domain using the CLI, run the cifs setup command. This begins a series of
prompts that requests the information necessary to add or change a computer account for a
storage system into a Windows 2000, Windows 2003, or Windows 2008 domain.
CIFS Setup Wizard
To access the CIFS Setup Wizard:

CIFS > Configure > Setup Wizard
CIFS SETUP WIZARD
To set up CIFS using the FilerView wizard:

1. Select FilerView > CIFS > Configure > Setup Wizard.
The Setup Wizard screen is displayed.
2. Click Next.
The CIFS Setup Wizard helps you configure your storage system for CIFS access. You can
run the wizard any time to change the settings. CIFS stops and then restarts when the wizard
is finished.
CIFS Setup Wizard (Cont.)
CIFS SETUP WIZARD (CONT.)
FILER NAME
The name of the storage system appears on the Filer Name screen of the CIFS Setup Wizard.
You can add a description of the storage system here. This description is available from the
CLI by typing cifs comment.
NOTE: Older environments might use WINS instead of DNS to resolve names.
AUTHENTICATION
On the Authentication screen of the CIFS Setup Wizard, select the type of Windows
authentication your system will use.
NOTE: This module covers Windows Active Directory Domain only. For information about
other user authentication methods, see the Data ONTAP CIFS Administration course, and the
File Access and Protocols Management Guide.
When entering an administrator name on the CIFS Setup Wizard Domain screen, the
Windows Administrator must have domain privileges to create a new computer account in
Active Directory.
NOTE: If your storage system supports CIFS clients only, set the
Security style to NTFS Only. Otherwise, use the default
Multi-Protocol.
SECURITY STYLE
The Security Style screen of the CIFS Setup Wizard is where you specify the type of security
to be used as the default on the storage system.
If FilerView is used to configure CIFS, the default security style is none.
If the CLI is used to configure CIFS:
• The default security style is NTFS only if CIFS is licensed.
• The default security style is Multi-Protocol if CIFS and NFS are licensed.
NOTE: Changing the default security style does not change existing files and directories,
only newly created files and directories.
CIFS Services
cifs terminate Host1
Host1
cifs terminate [-t time] host
Host2
cifs terminate
Host3
Host4
CIFS SERVICES
STARTING AND STOPPING THE CIFS PROTOCOL

The cifs terminate command stops the CIFS service. If a single host is named, all CIFS
sessions opened by that host are terminated. If a host is not specified, all CIFS sessions are
terminated and the CIFS service is shut down.
If you run the cifs terminate command without specifying a time until shutdown and
there are users with open files, you are prompted to enter the number of minutes to delay
before terminating. If the CIFS service is terminated immediately on a host that has one or
more files open, users will not be able to save changes. You can use the -t option to warn of
an impending service shutdown. If you execute cifs terminate from rsh, you must
supply the -t option.
EXAMPLE RESULT
cifs terminate -t 10 Terminates a session in 10 minutes for the host gloriaswan. Alerts are
gloriaswan sent periodically to the affected host(s).
cifs terminate -t 0 Terminates all CIFS sessions immediately for all clients.
cifs restart Reconnects the storage system to the domain controller, and then
restarts the CIFS service.
Reconfiguring CIFS
Use the cifs terminate command to

disconnect users and stop the CIFS service
Use the cifs setup command to reconfigure
the CIFS service
The storage system automatically attempts to
restart the CIFS service with the new CIFS
configuration
RECONFIGURING CIFS
To reconfigure CIFS, you must run the cifs setup program again, and then enter new
configuration settings. You can use cifs setup to change the following CIFS settings:
• WINS server addresses
• Security style (multiprotocol or NTFS-only)
• Authentication (Windows domain, Windows workgroup, or UNIX password)
• File system used by the storage system
• Domain or workgroup to which the storage system belongs
• Storage system name
PREREQUISITES FOR RECONFIGURING CIFS

Before reconfiguring CIFS, you must meet the following prerequisites:
• The CIFS service must be terminated.
• If you want to change the storage system's domain, the storage system must be able to
communicate with the primary domain controller for the domain in which you want to install the
storage system. You cannot use the backup domain controller for installing the storage system.
• If you want to change the name of the storage system, you must create a new computer account on
the domain controller. (This is not necessary if you are using Windows 2000.)
• Your storage system and the domain controllers in the same domain must be synchronized with
the same time source. If the time on the storage system and the time on the domain controllers are
not synchronized, the following error message is displayed:
sClock skew too great
For a detailed description of how to set up time synchronization services, see the Storage
Management Guide.
CIFS Sessions
CIFS SESSIONS
Displaying CIFS Sessions
You can display the following types of CIFS

session information:
A summary of session information
Share and file information for one or all
connected users
Security information for one or all connected
users
DISPLAYING CIFS SESSIONS
You can display the following types of session information:

• A summary of session information, including storage system information, and the number of open
shares and files opened by each connected user
• Share and file information about one connected user or all connected users, including:
• Names of shares opened by a specific connected user or all connected users
• Access levels of opened files
• Security information about a specific connected user or all connected users, including the UNIX
UID, and a list of UNIX groups and Windows groups to which the user belongs.
NOTE: The number of open shares shown in the session information includes the hidden
IPC$ share.
Using the CLI for CIFS Sessions
system> cifs sessions
Server Registers as ' NetApp1 ' in Windows 2000 domain 'EDSVCS'
Filer is using en_US for DOS users
Selected domain controller \\DEVDC for authentication
========================================
PC (user) #shares #files
TPILLON2-L2K (EDSVCS\administrator - root)
1 0
system> cifs sessions -s
users
Security Information
TPILLON2-L2K (EDSVCS\administrator - root)
***************
UNIX uid = 0
user is a member of group daemon (1)
user is a member of group daemon (1)
NT membership
EDSVCS\Administrator
EDSVCS\Domain Users
EDSVCS\Domain Admins
BUILTIN\Users
BUILTIN\Administrators
User is also a member of Everyone, Network Users,
Authenticated Users
***************
USING THE CLI FOR CIFS SESSIONS
To display a summary of information about the storage system and connected users, use the
cifs sessions command without arguments. For information about a single connected
user, you can specify the user, machine name, or IP address, or use the -s option to obtain
security information about one or all connected users.
EXAMPLE RESULT
cifs sessions Displays a summary of all connected users.
cifs sessions growe Displays information about the user, files opened by the user,
and the access level of the open files.
cifs sessions growe_NT Displays information about the host, files opened by the host,
cifs sessions 192.168.33.3 and the access level of the open files.
cifs sessions –s Displays security information about all connected users.
cifs sessions –s growe_NT Displays security information about the connected machine.
Using FilerView for CIFS Sessions
USING FILERVIEW FOR CIFS SESSIONS
To obtain CIFS session information using FilerView, complete the following steps:
1. From the FilerView main menu, select CIFS > Session Report.
2. Enter a user name or PC name.
3. To view session information, click Sessions or Security.
NOTE: If you leave the name field blank and select one of the option buttons, a full session
or security report on all connected users is displayed. Current session status is displayed at the
bottom of the CIFS Session Report screen.
CIFS Shares
CIFS SHARES
Creating and Managing Shares
Shares can be created and managed using:

CLI system> cifs shares –add
webfinal /vol/vol1/webfinal
Windows Computer
Management
FilerView
CREATING AND MANAGING SHARES
SHARES
When creating CIFS shares, there is a limitation with Windows Computer Management . For
more information, see the Data ONTAP CIFS Administration course, and the File Access and
Protocols Management Guide.
The cifs shares Command
Display shares
cifs shares [share_name]
Add shares
cifs shares -add <share_name> <path>
[-comment description] [-forcegroup
name] [-maxusers n]
Change shares
cifs shares -change <share_name>
<path> [-comment description]
[-forcegroup name] [-maxusers n]
Delete shares
cifs shares -delete <share_name>
THE CIFS SHARES COMMAND
You can use the CLI or FilerView to create and modify shares.
CREATING AND ACCESSING SHARES USING THE CLI

To display one or more shares, add a share, change a share, or delete a share, use the cifs
shares command.
PARAMETERS USED WITH CIFS SHARES

The parameters used with the cifs shares command allow you to modify or display CIFS
shares information. Share settings can be changed at any time, even if the share is in use.
PARAMETER WHAT IT DOES
sharename Name of the share that CIFS users will use to access the directory on the storage system.
If the sharename already exists, this command with the add option fails.
-comment Option that precedes a description field if the comment is intended.

-forcegroup Assigns a name to the group that will have access to all files created by CIFS users in the
name UNIX environment. The group must be a predefined group in the UNIX group database.
Specifying a forcegroup is useful only if the share is in a UNIX or mixed qtree. By
default, the shares give everyone full control.
-maxusers Specifies a maximum number of simultaneous users, depending on the storage system
memory. If the number of users is not specified, the default is Unlimited.
description Describes the purpose of the share and contains only characters in the current code page.
It is required by the CIFS protocol and is displayed in the share list in Network
Neighborhood. If the description contains spaces, enclose it in single quotes.
-nocomment Specifies that there is no description.
group name The name of the group in the UNIX group database. This group will own all files created
in the share.
- Specifies that no particular UNIX group owns files that are created in the share. Files that
noforcegroup are created belong to the same group as the owner of the file.
-nomaxusers Specifies no maximum number of users who can have simultaneous access.
The cifs shares Command: Example
system> cifs shares -add pub /vol/vol0/pub -comment “new pub”

system> cifs shares
Name Mount Point Description
---- ----------- -----------
ETC$ /etc Remote Administration
BUILTIN\Administrators / Full Control
HOME /vol/vol0/home Default Share
everyone / Full Control
C$ / Remote Administration
pub /vol/vol0/pub new pub
system> cifs shares -delete pub
system> cifs shares
---- ----------- -----------
ETC$ /etc Remote Administration
HOME /vol/vol0/home Default Share
C$ / Remote Administration
THE CIFS SHARES COMMAND: EXAMPLE
Managing Share Permissions
Share permissions can be managed using:

CLI system> cifs shares –add
webfinal /vol/vol1/webfinal
Windows Computer
Management
FilerView
MANAGING SHARE PERMISSIONS
PROVIDING ACCESS TO SHARES

After you have created shares, you can use the cifs access command to set or modify the
access control list (ACL) for that share. This command grants or removes access by
specifying the share, the rights, and the user or group.
EXAMPLE RESULT
cifs access webfinal tuxedo Gives full Windows NT access to the group tuxedo on the
Full Control webfinal share.
cifs access webfinal Gives read/write access to the user engineering\jbrown on
engineering\jbrown rw the webfinal share.
The cifs access Command
Set share permission

cifs access <sharename> [-g]
[user|group] <rights>
Remove share permission
cifs access -delete <sharename>
[user|group]
THE CIFS ACCESS COMMAND
PARAMETERS USED WITH THE CIFS ACCESS COMMAND

Parameter What It Does
-g Specifies that the user is the name of the UNIX group. Use this option when you have a
UNIX group and a UNIX user, or Windows NT user or group with the same name.
user Specifies that the user or group for the ACL entry can be a Windows NT user or group (if the
storage system uses NT domain authentication), or can be the special group, everyone.
group Specifies the user or group for the ACL entry. Can be a Windows NT user or group (if the
storage system uses NT domain authentication), or can be the special group, everyone.
rights Assigns either Windows NT or UNIX-style rights. Windows NT rights are: No Access,
Read, Change, and Full Control.
-delete Removes the ACL entry for the named user on the share.
The cifs access Command: Example
system> cifs access eng engineering “Full Control”

system> cifs shares eng
---- ----------- -----------
eng /vol/vol1/eng Eng Share
EDSVCS\engineering / Full Control
system> cifs access eng jbrown Read
system> cifs shares eng

---- ----------- -----------
EDSVCS\jbrown / Read
system> cifs access –delete eng jbrown

---- ----------- -----------
THE CIFS ACCESS COMMAND: EXAMPLE
Client Access
CLIENT ACCESS
Mapping the Share
MAPPING THE SHARE
Mapping the Share (Cont.)
MAPPING THE SHARE (CONT.)
Other CIFS Administration Resources
For more information about CIFS administration, see the

Data ONTAP CIFS Administration course. This advanced
course covers:
Different CIFS user authentication methods:
– Workgroup
– Active Directory
– Windows NT 4.0 domain
– Non-Windows workgroup
Advanced configuration
Collecting CIFS statistics
CIFS performance tuning
Troubleshooting CIFS
OTHER CIFS ADMINISTRATION RESOURCES
Module Summary

CIFS is a protocol for accessing computers on a
network
The CIFS server on the storage system must be
licensed and configured
Use the cifs shares command to create, view,
modify, and delete shares
Use the cifs access command to grant permissions
to users and groups
Use the cifs sessions command to view users and
connections
Use the cifs terminate command to terminate
CIFS sessions
MODULE SUMMARY
Exercise
Module 8: CIFS
EXERCISE
NFS

MODULE 9: NFS
NFS
Module 9
NFS
9-1 Data ONTAP® 7.3 Fundamentals: NFS
Module Objectives

Explain NFS implementation in Data ONTAP
License NFS on a storage system
Explain the purpose and format of
/etc/exports
List and define the export specification options
Explain the rules for exports
Describe the use of the exportfs command
Mount an export on a UNIX host
Add an export for an adminhost
MODULE OBJECTIVES
NFS Overview
NFS OVERVIEW
NFS Overview
NFS allows network systems (clients) to share

files and directories that are stored and
administered centrally from a storage system
The following platforms usually support NFS:
– Sun Microsystems® Solaris™
– Linux
– HP-UX
– And more
NFS OVERVIEW
The Network File System (NFS) is a protocol originally developed by Sun Microsystems in
1984, allowing users on a client computer to access files over a network as easily as if the
network devices were attached to its local disks. NFS, like many other protocols, builds on
the Open Network Computing Remote Procedure Call (ONC RPC) system. The NFS protocol
is specified in RFC 1094, RC 1813, and RFC 3530.
Exported Resources Overview
SS1
vol0 flexvol1
data_files
etc eng_files
home misc_files
Network Connection
Client1 Client1
EXPORTED RESOURCES OVERVIEW
In the diagram above, SS1 contains resources that many users need such as data_files,
eng_files, and misc_files.
To use a resource, SS1 must have the resource exported and Client1 must have the resource
mounted. A user on Client1 can then change to the directory (cd) that contains the mounted
resource and access it as if it were stored locally (assuming that permissions are set
appropriately).
Setting Up and
Configuring NFS
SETTING UP AND CONFIGURING NFS
Setting up NFS
Configure NFS using either:

– The CLI
– FilerView
When setting up NFS, you must have:
– An NFS license code
– Determined if you are enabling NFS over TCP,
UDP, or both
– Determined which version of NFS to enable
SETTING UP NFS
Configuring NFS Using the CLI
To use the CLI to configure NFS on a storage

system, complete the following steps:
1. License NFS on the storage system:
license add <nfslicensecode>
Executing this command starts the rpc.mountd
and nfsd daemons.
2. Set NFS options:
options nfs
HCONFIGURING NFS USING THE CLI
When you license NFS on a storage system, it starts the daemons (rpc.mountd and nfsd)
that handle NFS RPC protocol.
The following are NFS configurable options:
• nfs.v3.enable
• nfs.v4.enable
• nfs.tcp.enable
• nfs.udp.xfersize
Configuring NFS Using FilerView
To configure NFS using FilerView:

FilerView > NFS > Configure
CONFIGURING NFS USING FILERVIEW
The Configure NFS screen in FilerView enables you to configure NFS for use on the storage
system.
The following are NFS configurable parameters:
• NFS License
• NFS Enable
• PCNFS Enabled
• PCNFS umask
• WebNFS Enable
• Client statistics
• NFS Over TCP
• NFS Version 3
• Report Maximum
Exporting Resources
EXPORTING RESOURCES
Exporting Resources
To make resources available to remote clients,

the resource must be exported.
To export a resource persistently:
– Edit the /etc/exports file with new entry
– Execute the exportfs -a command
– Use FilerView
To export a resource temporarily, use the
exportfs -i -o command
EXPORTING RESOURCES
To export resources, use one of the following methods:

• For persistence across reboots, specify the resources to export in the /etc/exports file; and
then execute the exportfs -a command to make changes effective immediately
• For temporary access, use the exportfs command to export resources not specified in the
/etc/exports file, or to export resources specified in the file but with different access
permissions
FIVE RULES FOR CREATING EXPORTS

1. You must export each volume separately. If you create, rename, or destroy a volume, the
/etc/exports file is updated automatically. This functionality can be disabled using the
options nfs.export.auto-update switch.
2. The storage system must be able to resolve host names if used in exports:
/etc/hosts, NIS, DNS
3. Access must be granted in a positive way:
• A host is excluded when it is not listed or it is preceded by a dash (-).
• If no host is specified, all hosts have access.
4. Subdirectories of parent exports can be exported with different option specifications.
5. Permissions are determined by matching the longest prefix to the access permissions in the
/etc/exports file.
Adding an Export: /etc/exports
Specifies the full path to the directory that is exported. The first option is listed following a dash.
Additional options are separated by commas.
In this example the -rw option allows host1
and host2 to mount the pubs directory. Host
names are listed separated by colons.
/vol/vol0/pubs -rw=host1:host2,root=host1
/vol/vol1 -rw=host2
/vol/vol0/home
This option gives root permissions for the

pubs directory to host1.
All hosts can mount the /vol/vol0/home directory as This option gives read-write permissions to
read-write if an option is not specified. host2 only. All other hosts have no access.
ADDING AN EXPORT: /ETC/EXPORTS
System administrators must control how NFS clients access files and directories on a storage
system. Exported resources are resources made available to hosts. NFS clients can only
mount resources that have been exported from a storage system licensed for NFS.
To export directories, add an entry for each directory to the /etc/exports file, using the
full path to the directory and options. The full path name must include /vol.
Export specifications use the following options to restrict access:
• root = list of hosts, netgroup names, and subnets
• rw = list of hosts, netgroup names, and subnets
• ro = list of hosts, netgroup names, and subnets
Test Your Knowledge
1. Allow root access to /etc/exports

/vol/vol0 by adminhost a. /vol/vol1 -rw=host2
b. /vol/vol0 -rw=adminhost,root=adminhost
2. Allow read-write access to c. /vol/vol0/home -rw=host1:host2
/vol/vol0/home by d. /vol/vol0 -ro=host2
host1 and host2
e. /vol/vol1 -rw=host1,ro=host3
f. /vol/vol1 –rw=host1,root=host3
3. Allow read-write access to
g. /vol/vol0/home –rw=host1,ro=host2
/vol/vol1 by host1 and
read-only access by host3 h. /vol/vol0 –ro=adminhost,root=adminhost
TEST YOUR KNOWLEDGE
Exporting
EXPORTING
The exportfs Command
After adding an export to /etc/exports, use

the exportfs -a command to load the exports.
system> exportfs -a
system> exportfs
/vol/flexvol/qtree -sec=sys,rw=10.254.232.12
/vol/vol0/home -sec=sys,rw,root=10.254.232.12,nosuid
system> rdfile /etc/exports

#Auto-generated by setup Mon Apr 30 08:32:21 GMT 2007
/vol/flexvol/qtree -sec=sys,rw=10.254.232.12
/vol/vol0/home -sec=sys,rw,root=10.254.232.12,nosuid
system>
THE EXPORTFS COMMAND
To specify which file system paths Data ONTAP automatically exports when NFS starts up,
add export entries to (or remove them from) the /etc/exports file. To manually export or
unexport file system paths, use the exportfs command in the storage system CLI.
EDITING THE /ETC/EXPORTS FILE

To add export entries to (or remove from) the /etc/exports file, use a text editor on an
NFS client that has root access to the storage system.
The following is an example of /etc/exports file entries:
#Auto-generated by setup Mon Mar 24 14:39:40 PDT 2008
/vol/vol0 -sec=sys,ro,rw=sunhost,root=sunhost,nosuid
/vol/vol0/home -sec=sys,rw,root=sunhost,nosuid
/vol/flexvol1 -sec=sys,rw,root=sunhost,nosuid
Adding an Export Using FilerView
ADDING AN EXPORT USING FILERVIEW
OPTION DESCRIPTION
Root Access The root option specifies that the root on the client has root permissions for the
resource when it is mounted from the storage system.
Read-Write The rw option gives read-write access to specific hosts. If no host is specified, all
Access hosts have read-write access.
Read-Only The ro option gives read-only access to specific hosts. If no host is specified, all
Access hosts have read-only access.
Anonymous User The anon option determines the UID of the root user on the client.
ID
Adding an Export Using FilerView (Cont.)
ADDING AN EXPORT USING FILERVIEW (CONT.)
EXPORT PATH
You must specify as the export path the full path name for the exported resource.
Example:
/vol/vol0
Adding an Export Using FilerView (Cont.)
ADDING AN EXPORT USING FILERVIEW (CONT.)
Managing NFS Exports
MANAGING NFS EXPORTS
When Data ONTAP receives a mount request from a client, it compares the path name in the
mount request to the path names of the exported resources contained in the /etc/exports
file. If Data ONTAP finds a match, the NFS client is allowed to mount the resource.
FilerView enables you to insert and modify export lines in the file, add options for specific
hosts to an existing export line, and delete an existing export line. After adding export lines,
you can then export all resources for client access.
The FilerView Manage NFS Exports screen enables you to manage NFS exports on the
storage system. NFS clients can only mount resources after they have been exported
(meaning that they have been made available for mounting).
You can export a resource to the following targets:
• Hosts―Hosts are individual computers.
• Netgroups―When exporting a resource, if you do not want to list names of individual hosts as
targets, you can specify a predefined netgroup as the target.
• Subnets―Exporting to a subnet has the same effect as exporting to individual hosts on the subnet
without having to list individual host names. If all hosts on the same subnet should mount the same
resource, export that resource to the subnet.
When exporting a resource, keep in mind the following:
• You must specify the complete path name for a resource to be exported.
• You cannot export /vol, which is not a path name to a file, directory, or volume. If you want to
export all volumes on the storage system, you must export each volume separately.
• Each line in the /etc/exports file can contain up to 4,096 noncommented characters. The
number of characters allowed for comments is unlimited.
• The /etc/exports file contains a list of resources that can be exported. When the storage
system is rebooted, Data ONTAP exports all resources in this file.
Temporary Exports
Use the exportfs command to create

in-memory exports:
exportfs -i -o
Example:
– exportfs -i -o ro=host1
/vol/vol0/home
NOTE: When the storage system reboots, this export will be gone.
TEMPORARY EXPORTS
THE EXPORTFS COMMAND
EXAMPLE RESULT
exportfs -a Exports all entries in the /etc/exports file.
exportfs –i –o ro=host1:host3 Exports /vol/vol0/home to host1 and host3 with

/vol/vol0/home read-only access. This is an example of a temporary
export from the CLI.
exportfs –u /vol/vol1 Unexports /vol/vol1.

exportfs -ua Unexports all exports.
exportfs -av Calls the verbose option and exports, and prints the path
name for each export in the /etc/exports file.
Common exportfs Options
Display all current exports:

exportfs
Add exports to the /etc/exports file:
exportfs -p [options] path
Reload exports from /etc/exports files:
exportfs -r
Unload all exports:
exportfs -uav
Unload a specific export:
exportfs -u [path]
Unload an export and remove it from /etc/exports
exportfs -z [path]
COMMON EXPORTFS OPTIONS
To export a file system path and add a corresponding export entry to the /etc/exports file,
enter the following command:
exportfs -p [options] path
NOTE: If you do not specify an export option, Data ONTAP automatically exports
the file system path with the rw and sec=sys export options.
To export all file system paths specified in the /etc/exports file and unexport all file
system paths not specified in the /etc/exports file, enter the following command:
exportfs –r
To unexport all file system paths without removing the corresponding export entries from the
/etc/exports file, enter the following command:
exportfs –uav
To unexport a file system path without removing the corresponding export entry from the
exportfs -u path
To unexport a file system path and remove the corresponding export entry from the
exportfs -z path
Mounting
MOUNTING
Mounting From a Client
To mount an export from a client:
1. Telnet or log in to the host.
2. Create a directory as a mountpoint for the storage appliance.
3. Mount the exported directory in the host directory you just
created.
4. Change directories to the mounted export.
5. Enter ls –l to verify that the storage appliance is mounted and
accessible.
telnet 10.32.30.20 (1)

# mkdir /system-vol2 (2)
# mount system:/vol/vol2 /system-vol2 (3)
# cd /system-vol2 (4)
NetApp1-vol2$ ls –l (5)
-rwxr-xr-x root 719634 FEB 11 2004 ,general
-rwxr-xr-x root 719634 FEB 13 2004 ,policy
MOUNTING FROM A CLIENT
Use the mount command to mount an exported NFS directory from another machine.
An alternate way to mount an NFS export is to add a line to the /etc/fstab (called
/etc/vfstab on some UNIX systems). This line must specify the NFS server host name,
the exported directory on the server, and the local machine directory where the NFS share is
to be mounted. For more information, see the NFS documentation for your client.
Other NFS Administration Resources
For more information about NFS administration,

see the Data ONTAP NFS Administration
course. This advanced course covers:
Exporting resources across domains, subnets,
and netgroups
Advanced configuration
NFS statistics gathering
NFS performance tuning
NFS troubleshooting
OTHER NFS ADMINISTRATION RESOURCES
Module Summary

NFS is a protocol used by Data ONTAP to
network computers.
The /etc/exports file defines exports.
You can configure NFS on a storage system
using the CLI or FilerView.
After you export a resource, you can mount an
exported file system on a UNIX host.
MODULE SUMMARY
Exercise
Module 9: NFS
EXERCISE
Qtrees

MODULE 10: QTREES AND SECURITY STYLES
Qtrees and Security

Styles
Module 10
QTREES AND SECURITY STYLES
10-1 Data ONTAP® 7.3 Fundamentals: Qtrees and Security Styles
Module Objectives

Describe multiprotocol configuration on a
storage system, including the
/etc/usermap.conf file
Explain the purpose of a security style
Configure a security style setting for a qtree
and a volume
Explain the difference between security styles
and access types using the CLI and FilerView
Explain, create, and manage quotas using the
CLI and FilerView
MODULE OBJECTIVES
Qtrees
QTREES
Qtrees
A qtree is a logically defined file system that

exists as a special subdirectory at the root of a
volume
When creating a qtree, you can:
– Partition data within a volume
– Establish special quota requirements
The maximum number of qtrees is 4,995 per
volume
Qtrees look like a directory to the client
Qtrees can be removed from the client by
removing the directory or using FilerView
QTREES
Qtrees are similar to flexible volumes, but have the following unique characteristics:
• Qtrees allow you to set security styles.
• Qtrees allow you to set oplocks for CIFS clients.
• Qtrees allow you setup and apply quotas.
• Qtrees are used as a backup unit for SnapMirror and SnapVault.
Qtree Advantages
Set a qtree security style without affecting the

security style of other qtrees in a volume
(discussed later)
Set CIFS oplocks, if appropriate, without
affecting the settings of projects in other qtrees
Use tree quotas to limit the disk space and
number of files available to each qtree in a
volume (discussed later)
Backup and restore qtrees
QTREE ADVANTAGES
QTREE FOR BACKUP

Backing up individual qtrees provides the following benefits:
• Adds flexibility to backup schedules
• Modularizes backups by backing up only one set of qtrees at a time
• Limits the size of each backup to one tape
Many products that use NetApp software (such as SnapMirror and SnapVault) are “qtree-
aware.” Because you are working at a smaller increment than the entire volume, working at
the qtree level allows rapid file backup and recovery.
CIFS OPLOCKS
CIFS oplocks (opportunistic locks) enable the CIFS client in certain file-sharing scenarios to
perform client-side caching of read-ahead, write-behind, and lock information. A client can
then work with a file (read or write it) without regularly reminding the server that it needs
access to the file. This improves performance by reducing network traffic. For more
information about CIFS oplocks, see the Data ONTAP CIFS Administration course.
Security Styles
Every qtree and volume has a security style

setting that determines whether files in that
qtree or volume can use Windows NT ACLs or
UNIX security
There are three security styles:
– NTFS
– UNIX
– Mixed
To change the security style using the CLI:
qtree security <fullpath>
[ntfs|unix|mixed]
SECURITY STYLES
The following describes the three qtree security styles:

• NTFS
• For CIFS clients, security is handled using Windows NTFS ACLs.
• For NFS clients, the NFS UID (user id) is mapped to a Windows SID (security identifier) and
its associated groups. These mapped credentials are used to determine file access based on the
NFTS ACL.
• UNIX
• Just like UNIX, files and directories have UNIX permissions.
• Mixed
• Both NTFS and UNIX security is allowed. A file or directory can have either Windows NT
permissions or UNIX permissions.
• The default file security style is the style most recently used to set permissions on that file.
Security Styles
Security Styles
Hosts that can
CIFS Client Access NFS Client Access
Security Style change Security/
Determined by Determined by
Permissions
UNIX permissions
unix NFS clients Windows user UNIX permissions
names mapped to
UNIX account
NFS and CIFS Depends on the last client to set security
mixed
clients settings (permissions)
Windows NT ACLs
ntfs CIFS clients Windows NT ACLs UNIX user names
mapped to
Windows account
SECURITY STYLES
MULTIPROTOCOL SECURITY ADMINISTRATION

Volumes and qtrees have security styles that allow for multiprotocol access. These security
styles are UNIX, NTFS for Windows, and mixed. In order to use the NTFS and mixed
security styles, a storage system must be configured as part of a Windows NT domain. On
any storage system licensed for CIFS and NFS, Windows and UNIX clients can access any
volume or qtree if they have access rights. What differs is security and permissions. The
security style specifies who can modify security properties and directories in a volume or
qtree. The security style also specifies the process for authenticating users.
To accommodate new users or files that require a different style, you can change the security
style of a qtree.
TYPES OF FILE ACCESS

Data ONTAP offers the following types of file access on a storage system with both CIFS
and NFS licenses:
• CIFS access to Windows files
• CIFS access to UNIX files
• NFS access to UNIX files
• NFS access to Windows files
SECURITY STYLES
• UNIX―Files and directories have the security style of UNIX permissions.
• Mixed―Both NTFS and UNIX security styles are allowed. A file or directory can have either
Windows NT permissions or UNIX permissions, and security style is determined on file-by-file
basis.
• NTFS―Files and directories have Windows NT file-level permissions over the access control lists
(ACLs).
HOSTS THAT CAN CHANGE SECURITY

• NFS clients―NFS or Windows clients can change file permissions and ownership.
• NFS and CIFS clients―Both CIFS and NFS clients can change security.
• CIFS clients only―Only CIFS clients can change file permissions and ownership.
HOW CIFS CLIENT ACCESS IS DETERMINED

• UNIX permissions―If a CIFS client requests access, the CIFS user name is mapped to a UNIX
user name and associated with a UNIX UID and group ID (GID). Access is determined by the
rights in an ACL at the share level and is limited by the UNIX permissions assigned to the file.
• Last client to set security―Both CIFS and NFS clients can change security. This can cause
confusion because the security style of a file or directory is dictated by the most recent client.
• Windows NT ACLs―Windows NT ACLs determine CIFS client access.
HOW NFS CLIENT ACCESS IS DETERMINED

• UNIX permissions―NFS accesses to UNIX files comply with UNIX security rules.
• Last client to set security―Both CIFS and NFS clients can change security. This can cause
confusion because the security style of a file or directory is dictated by the most recent client.
• Windows NT ACLs―Windows NT ACLs determine client access. If an NFS client requests
access, the NFS user name is mapped to a CIFS user name and ACLs are applied based on the user
name and associated SID.
Adding a Qtree
To add a qtree using the CLI:

qtree create <fullpath>
To add a qtree using FilerView:
FilerView > Volumes > Qtree > Add
ADDING A QTREE
CREATING QTREES USING FILERVIEW

To use FilerView to create, modify, and manage qtrees:
1. From the FilerView main menu, select Volumes > Qtrees.
2. Select Manage > Add Qtree.
3. From the Add Qtree menu, select the qtree volume, enter the qtree name, and then click Add.
You can set the security style and oplocks state when you create the qtree, or you can modify
them later by completing the following steps:
1. From the FilerView main menu, select Volumes > Qtrees.
2. From the Qtrees menu, select Manage.
3. Open the Modify menu by selecting the name of the qtree you want to change.
4. After you modify the settings, click Apply.
The new qtree is listed and the changes are updated on the FilerView screen.
Qtree Commands
system> qtree create /vol/vol2/updates
system> qtree security /vol/vol2/updates mixed
system> qtree oplocks /vol/vol2/updates disable
system> qtree create /vol/vol3/show03
system> qtree security /vol/vol3/show03 ntfs
system> qtree status
Volume Tree Style Oplocks Status

-------- -------- ----- -------- ------
vol0 unix enabled normal
vol0 mktg ntfs enabled normal
vol2 updates mixed disabled normal
vol3 ntfs enabled normal
vol3 show02 mixed enabled normal
vol3 show03 ntfs enabled normal
QTREE COMMANDS
EXAMPLE RESULT
qtree create pubs Creates the qtree, pubs. If the qtree pathname does not begin with a slash (/),
the qtree is created in the root volume.
qtree create Creates the qtree, engr, in the /vol/projects/ volume.

/vol/projects/engr
qtree security / ntfs Applies NTFS security to the files and directories in the root volume.
qtree security Applies mixed security to the files and directories in the projects volume.
/vol/projects/ mixed
qtree oplocks Enables oplocks for files and directories in the engr qtree.
/vol/projects/engr
enable
qtree oplocks Disables oplocks in the files and directories for qtree 0 in the projects
/vol/projects/ volume.
disable
Managing Qtrees
To manage qtrees using the CLI:

qtree status
To manage qtrees using FilerView:
FilerView > Volumes > Qtree > Manage
MANAGING QTREES
Multiprotocols
MULTIPROTOCOLS
Multiprotocols
NetApp storage systems support

heterogeneous environments:
– CIFS (usually associated with Windows NTFS)
– NFS (usually associated with the UNIX file
system)
Setting the security style of a volume or qtree
to:
– UNIX, does not prevent CIFS users from access
– NTFS, does not prevent NFS users from access
NOTE: The storage system’s multiprotocol feature must be properly
configured.
MULTIPROTOCOLS
NetApp storage systems support both NFS-style and CIFS-style file permissions. NFS-style
file permissions are widely used in UNIX systems, while CIFS-style file permissions are used
in Windows when communicating over networks. Because the ACL security model for CIFS
is richer than the NFS file security model used in UNIX, you cannot perform one-to-one
mapping between them. This issue has led vendors of multiprotocol file storage products to
develop nonmathematical strategies to blend the two systems and make them compatible.
This section explains the NetApp approach to this issue of incompatibility.
NAS File Access: Four Scenarios
There are four basic scenarios for NAS file

access:
1. A UNIX client accesses a UNIX file (not
multiprotocol)
2. A PC client accesses a file with an ACL (not
multiprotocol)
3. A UNIX client accesses a file with an ACL
4. A PC client accesses a file with UNIX
permissions
Because the first two scenarios are not

multiprotocol scenarios, this modules focuses
on scenarios 3 and 4.
NAS FILE ACCESS: FOUR SCENARIOS
MULTIPROTOCOL SCENARIOS
For the purpose of this section, the assumption is that all UNIX files have no ACLs. This is
not always true, as ACLs are preserved when changing qtree styles. But ACLs on files in a
UNIX qtree are ignored when performing permissions checks, so the net effect is as if no file
in a UNIX qtree ever has an ACL.
The /etc/usermap.cfg File
The /etc/usermap.cfg file maps between

Windows NT and UNIX accounts when:
The Windows NT account name does not
match the desired UNIX account name
A different UNIX account is required
A different Windows NT account is required
THE /ETC/USERMAP.CFG FILE
The /etc/usermap.cfg file allows you to map a Windows user to a UNIX user, or a
UNIX user to a Windows user.
The /etc/usermap.cfg File (Cont.)
Format for File Entries

IPqualifier: NTdomain\NTuser direction
IPqualifier: UnixUser
/etc/usermap.cfg
"Bob Garg" == bobg
mktg\Roy => nobody
engr\Tom => ""
uguest <= *
THE /ETC/USERMAP.CFG FILE (CONT.)
FORMAT FOR FILE ENTRY
IP_QUALIFIER FIELD
The IP_qualifier field contains an IP address that narrows a message. For example,
192.4.1.0/24 narrows possible matches to the 192.4.1.0 class C subnet. The IP_qualifier can
be a host name or a network name (for example, corpnet/255.255.255.0 specifies the corpnet
subnet). The IP_qualifier is an optional parameter.
NTDOMAIN\NTUSER FIELD
This field contains a user name and an optional domain name. If the Windows NT user name
is empty or specified as “” on the destination side of the map entry, the matching UNIX name
is denied access. If the storage system uses local accounts for authentication, the domain
name is the storage system name. On the source side of the map entry, using the domain name
specifies the domain in which the user resides. On the destination side of the entry, the
domain specifies the domain used for the mapped UNIX entry. If an NT user name contains
spaces, enclose the name in quotation marks.
DIRECTION FIELD
This field specifies whether the entry will map Windows to UNIX or UNIX to Windows, or
will map in both directions. The direction field uses one of three values. To indicate that
mapping is bidirectional (so that the entry maps from Windows to UNIX and from UNIX to
Windows), use = =.
NOTE: Omitting the direction field is the same as using = =.
UNIX USER FIELD

Contains a name in the UNIX password database.
The /etc/usermap.cfg File (Cont.)
Guidelines for Using Asterisks

uguest <= *
uguest => *
homeuser\* == *
*\root => administrator
*\root <= root
THE /ETC/USERMAP.CFG FILE (CONT.)
GUIDELINES FOR USING ASTERISKS

The asterisk (*) is a wildcard character. When using an asterisk in user name fields, follow
these guidelines:
• If the asterisk is on the source side, any user maps to the name specified on the destination side.
• If the destination side contains an asterisk but the source side does not, no mapping is performed.
• If both the source and destination sides contain an asterisk, the corresponding name is mapped. In
this example, all UNIX users map to corresponding names in the home users domain.
The asterisk is also used in the domain name field. When using an asterisk in the domain
name field, follow these guidelines:
• If the asterisk is on the source side, the specified name in any domain maps to the specified UNIX
name.
• If the asterisk is on the destination side, the specified UNIX name maps to a Windows name in any
trusted environment.
UNIX User Accessing an NTFS Qtree
Username lookup of UID in

/etc/passwd or NIS
/etc/usermap.cfg
Domain\user <= UNIX User
If user is mapped to “ ” Reject
Maps to user name No entry
DOMAIN_of_filer\Username
Authenticate with domain Maps to wafl.default_nt_user
Accept
Reject
Multiprotocol accept
UNIX USER ACCESSING AN NTFS QTREE
When a UNIX client requests access to a file without UNIX permissions, the ACL on the file
is used to determine if access is granted. The UID of the requester is validated in the
/etc/passwd file (or NIS or LDAP). If CIFS domain authentication is configured, the valid
user is looked-up in the /etc/usermap.cfg file, mapped to a Windows user or SID, and
then passed to the domain for authentication,. If CIFS domain authentication is configured,
but there is no entry in /etc/usermap.cfg, then the
Domain Of The Storage System\Unix name is passed to the domain for authentication. If the
user is rejected, the storage system will allow authentication for the guest user, if configured,
or the default user (sometimes referred to as the generic user). If the user authentication is
valid, then the user is granted the share- and file-level access assigned to that account.
Otherwise, the user is denied access.
Windows NT User Accessing a UNIX Qtree
domain, user, password
Guest
Authenticate with domain
Reject
Accept
/etc/usermap.cfg
Domain\user <= UNIX User
If user is mapped to “ ” Reject
Maps to user name or no entry
/etc/passwd or
Maps to wafl.default_nt_user
NIS unixuser ID
Multiprotocol accept
WINDOWS NT USER ACCESSING A UNIX QTREE
When a user on a PC client requests access to a file without an ACL, access is granted or
denied based on the UNIX permissions on the file. The NTFS SID of the requester is looked-
up on the domain controller (or local user database) to acquire a user name. The user name is
then mapped to a UNIX user name using the name-mapping feature. Using this name-
mapping feature, the user name is looked-up in the /etc/passwd file (or NIS or LDAP) to
acquire the mapped UID and GIDs. These are then compared to the UID, GID, and associated
permissions for the file, exactly as if the requester is the mapped UNIX user.
To troubleshoot authentication, you can enable the following option:
options cifs.trace_login
NOTE: This option should be disabled when not troubleshooting authentication.
Multiprotocol Security Administration
Use these guidelines to keep entries simple and

easy to understand:
Make Windows and UNIX user names the
same whenever possible. If the names are
identical, you do not need to create map
entries in the /etc/usermap.cfg file.
Avoid confusing entries that map the same
user to different user names.
Use IP qualifiers only to restrict access.
MULTIPROTOCOL SECURITY ADMINISTRATION
MAPPING
By default, Windows names map to identical user names in the UNIX space. For example,
the Windows user bob maps to the UNIX user bobg. You can use the user mapping file
/etc/usermap.cfg to map PC users to UNIX users that are named differently, and to
handle other special or generic users such as root, guest, administrator, nobody, and so on.
Quotas
QUOTAS
Quotas
Quotas are necessary to:

– Limit the amount of disk space that can be used
– Track disk space usage
– Warn of excessive usage
Quota targets
– Users
– Groups
– Qtrees
QUOTAS
Quotas are important tools for managing the use of disk space on your storage system. A
quota is a limit that is set to control or monitor the number of files or amount of disk space an
individual or group can consume. Quotas allow you to manage and track the use of disk space
by clients on your system.
A quota is used to:
• Limit the amount of disk space or the number of files that can be used
• Track the amount of disk space or number of files used, without imposing a limit
• Warn users when disk space or file usage is high
Managing Quotas in FilerView
To manage quotas in FilerView:

FilerView > Volumes > Quotas
MANAGING QUOTAS IN FILERVIEW
Adding a Quota Using
the Quota Rule Wizard
Step 1: Quota Type
ADDING A QUOTA USING THE QUOTA RULE WIZARD
QUOTA TYPE
The type of a quota limit can be a:
• User—Indicated by a UNIX or Windows ID
• Group—Indicated by UNIX GIDs
• Qtree—Represented by the qtree path name
User quotas, group quotas, and tree quotas are stored in the /etc/quotas file. You can edit
this file at any time.
Quotas are based on a Windows account name, UNIX ID, or GID in both NFS and CIFS
environments.
The CIFS system administrator must maintain the /etc/passwd file for CIFS users to obtain
UIDs (if those users are going to create UNIX files), and the /etc/group file for CIFS users
to obtain GIDs or use an NIS server to implement CIFS quotas.
Qtree quotas do not require UIDs or GIDs. If you only implement qtree quotas, it is not
necessary to maintain the /etc/passwd and /etc/group files (or NIS services).
the Quota Rule Wizard (Cont.)
Step 2: Limits
ADDING A QUOTA USING THE QUOTA RULE WIZARD (CONT.)
LIMITS
DISK COLUMN
The Disk Space Hard Limit field list the maximum disk space allocated to the quota target.
This hard limit cannot be exceeded. If the limit is reached, messages are sent to the user and
console, and SNMP traps are created.
Use the abbreviations G for gigabytes, M for megabytes, and K for kilobytes. This field
accepts either uppercase or lowercase letters. If you omit the size abbreviation, the system
assumes K (kilobytes). Do not leave this field blank. If you want to track usage without
imposing a limit, enter a dash (-).
Maximum values for the Disk Space Hard Limit is:
• 4,294,967,295 K
• 4,194,303 M
• 4,095 G
FILES COLUMN
The Files Hard Limit field specifies the maximum number of files the quota target can use.
To track usage of the number of files without imposing a quota, enter a blank or a dash (-) in
this field. You can omit abbreviations (uppercase or lowercase) and you can enter an absolute
value, such as 15000.
Maximum value for the Files Hard Limit: 4,294,967,295 K
NOTE: The value for the Files Hard Limit field must be on the same line in your quotas file
as the value for the disk field, otherwise, the Files field is ignored.
THRESHOLD COLUMN
The Threshold field specifies the limit at which write requests trigger messages to the
console. If the threshold is exceeded, the write still succeeds, but a warning is logged to the
console.
The Threshold field uses the same format as the Disk field.
Do not leave this field blank. The value following Files is always assigned to the Threshold
field. If you do not want to specify a threshold limit, enter a dash (-) here.
Maximum values for the Threshold:
• 4,294,967,295 K
• 4,194,303 M
• 4,095 G
SOFT DISK COLUMN

The Disk Space Soft Limit field specifies the disk space that can be used before a warning is
issued. If this limit is exceeded, a message is logged to the console and an SNMP trap is
generated.
When the soft disk limit returns to normal, another syslog message and SNMP trap is
generated. The Disk Space Soft Limit field has the same format as the Disk Space Hard Limit
field. If you do not want to specify a soft limit, enter a dash (-) or leave this field blank.
Maximum value for Disk Space Soft Limit: 4,294,967,295 K
NOTE: The Disk Space Soft Limit value must be on the same line as the value for the Disk
Space Hard Limit field; otherwise, soft disk limit is ignored. The sdisk limit is the NFS
equivalent of a CIFS threshold.
SOFT FILES COLUMN

The Files Soft Limit field specifies the number of files that can be used before a warning is
issued. If the soft limit is exceeded, a warning message is logged to the storage system
console and an SNMP trap is generated. When the soft files limit returns to normal, another
syslog message and SNMP trap is generated. The Files Soft Limit field has the same format
as the Files Hard Limit field. If you do not want to specify a soft files limit, enter a dash (-)
or leave the field blank.
Maximum value for Files Soft Limit: 4,294,967,295 K
the Quota Rule Wizard (Cont.)
Step 3: Commit
ADDING A QUOTA USING THE QUOTA RULE WIZARD (CONT.)
Changes in the /etc/quotas file are not persistent until you click Commit.
Turning Quotas On or Off
TURNING QUOTAS ON OR OFF
QUOTA COMMANDS
The table below lists commands you can use to manage quotas in each volume. If there is
only one volume on the system, you can omit the volume name on all of these commands.
Quota commands are persistent across reboots.
USING FILERVIEW
You can also manage quotas using FilerView. To access the Quota functions, enter the
storage system address in your browser and click the Volumes option. Select Quotas >
Manage.
USING THE QUOTA COMMANDS
EXAMPLE RESULT
quota on vol1 Activates quotas on vol1 based on the contents of the /etc/quotas
file
quota resize vol1 Activates changes on vol1 based on the contents of the /etc/quotas
file
qtree create Creates a special directory at the root of a volume for
/vol/vol2/techpubs /vol/vol2/techpubs
Qtree Statistics
To display the number of NFS/CIFS operations resulting

from user access to files in a qtree:
qtree stats
system> qtree stats
No qtrees are in use in Volume vol1
No qtrees are in use in Volume vol0
Volume Tree NFS ops CIFS ops
-------- -------- ------- -----
flexvol1 datatree1 9 262
system>
QTREE STATISTICS
To help you determine what qtrees are incurring the most traffic, the qtree stats
command enables you to display statistics about user accesses to files in the qtrees on your
system. This information can identify traffic patterns to help with qtree-based load balancing.
The storage system maintains counters for each quota tree in each of the storage system’s
volumes. These counters are not persistent.
To reset the qtree counters, use the -z flag.
The values displayed by the qtree stats command correspond to the operations on the
qtrees that have occurred since the volume (where the qtrees exist) was created, or since it
was made online on the storage system (either through a vol online command or a reboot),
or since the counters were last reset, whichever occurred most recently.
If you do not specify a name in the qtree stats command, the statistics for all qtrees on
the storage system are displayed. Otherwise, statistics for qtrees in the volume name are
displayed.
Similarly, if you do not specify a name with the -z flag, the counters are reset on all qtrees
and all volumes.
The qtree stats command displays the number of NFS and CIFS accesses on the
designated qtrees since the counters were last reset. The qtree stats counters are reset
when one of the following actions occurs:
• System is booted
• Volume containing the qtree is brought online
• Counters are explicitly reset using the qtree stats -z command
Quota Errors
“Disk quota exceeded”—Results from requests

that cause a user or group to exceed an
applicable quota
“Out of disk space” —Results from requests
that cause the number of blocks or files in a
qtree to exceed the qtree limit
Root or Windows administrator account
– Group quotas do not apply
– Tree quotas do apply
QUOTA ERRORS
EXCEEDING QUOTAS
Quotas are set to warn you that limits are being approached, allowing you to act before users
are affected.
For all quota types, Data ONTAP sends console messages when the quota is exceeded and
when it returns to normal. SNMP traps for quota events are also initiated. Additional
messages are sent to the client when hard quota limits are exceeded.
NOTE: Threshold quotas in CIFS are the same as soft quotas in NFS.
QUOTA ERROR MESSAGES

When receiving a write request, Data ONTAP checks to see if the file to be written is in a
qtree. If the write would exceed the tree quota, the following error message is sent to the
console:
tid tree_ID: tree quota exceeded on volume vol_name.
If the qtree is not full, but the write would cause either the user or group quota to be
exceeded, Data ONTAP logs one of the following errors:
uid user_ID: disk quota exceeded on volume vol_name
gid group_ID: disk quota exceeded on volume vol_name
ERROR MESSAGES RECEIVED BY CLIENTS

When hard quota limits are violated, Data ONTAP returns an out of disk space error to
the NFS write request, or a disk full error to the CIFS write request.
MESSAGES FOR NFS CLIENTS
The client OS version and application determine what messages user will see. If a UNIX
client mounts a storage system without the noquota option, every time the user logs in, the
client login program checks to see if the user has reached disk and file quotas. If a hard quota
has already been reached, the client displays a message to alert the user before displaying the
system prompt.
Not all versions of UNIX perform this quota check, and messages vary depending on version.
MESSAGES FOR CIFS CLIENTS

If a write from a CIFS client causes a hard quota to be exceeded, the message displayed to the
user depends on the operating system and the application.
An application might display the following message:
Cannot write file filename
Or, when a user tries to copy a file using the Windows Explorer in Windows 95, the
following error is displayed:
Cannot create or replace filename: cannot read from the source
file or disk.
Editing Quota Rules
To edit quota rules using FilerView:

FilerView > Volumes > Quotas > Edit Rules
EDITING QUOTA RULES
Quota Rules
New users or groups created after the default quota is

in effect will have the default value
Users or groups that do not have a specific quota
defined will have the default value
Configurable rules (/etc/quotas fields) are:
# Target Type Disk Files Thold Sdisk Sfiles
* user@/vol/vol2 50M 15K 45M - 10K

/vol/home/usr/x1 user 50M 10K 45M - -
21 group 750M 75K 700M - 9000
/vol/eng/proj tree 100M 75K 90M - -
writers group@/vol/techpub 75M 75K 70M - -
acme\cheng user@/vol/vol2 200M - 150M - -
tonyp@acme.com user - - - - -
rtaylor user@/vol/vol2 200M - 150M - -
s-1-5-32-544 user@/vol/vol2 200M - 150M - -
NOTE: Columns are separated by white spaces.
QUOTA RULES
CONTENTS OF THE /ETC/QUOTAS FILE
TARGET COLUMN
The Target column identifies what the quota will be applied against. In the example above,
there are multiple equivalent ways you can specify the target. These entries provide target
UIDs (for users) or GIDs (for groups) to the storage system of. The ID numbers must not be
0. The system checks quotas every time it receives a write request, so it is important to use a
target that won’t change over time unless you account for the change in the quotas file.
NOTE: Do not use the backslash (\) or “at” sign (@) in UNIX quota targets. Data ONTAP
interprets these characters as part of Windows names.
DEFAULT QUOTAS
You can create a default quota for users, groups, or qtrees. A default quota applies to quota
targets that are not explicitly referenced in the /etc/quotas file.
OVERRIDING DEFAULT QUOTAS

If you do not want Data ONTAP to apply a default quota to a particular target, you can create
an entry in the /etc/quotas file for that target so that the explicit quota overrides the
default quota.
Quota Report
QUOTA REPORT
THE QUOTA REPORT COMMAND

The quota report command prints the current file and space consumption for each user,
group, and qtree. Using a path argument, it displays information about all quotas that apply to
the files in the path. Space consumption and disk limits are rounded up and reported in
multiples of 4 K.
In the example above, the quota report command is used with the –u option. For targets
with multiple IDs, this report shows the first ID on the first line of each report entry. Other
IDs are shown on separate lines with one ID per line. Each ID is followed by its original
quota specifier, if any. The default is to display one ID per target.
The following are options available with the quota report command:
• -s prints soft and hard limit values for each user, group, and qtree
• -u shows the first ID on first line of each report entry for targets with multiple IDs. Other IDs are
shown on separate lines with one ID per line. Each ID is followed by its original quota specifier, if
any. The default is to display one ID per target.
• -x shows all IDs (separated by commas) on first line of each report entry for targets with multiple
IDs. The report also shows threshold column. Columns are tab delineated.
• -t prints the threshold of the quota entry. If omitted, the warning threshold is not included.
Resizing Quotas
Quota information is stored in the

/etc/quotas file
Resizing adjusts the active quotas in a specific
volume to reflect changes in the
/etc/quotas file
The values in the /etc/quotas file are
displayed in FilerView when you select:
FilerView Æ Volumes Æ Quotas Æ Edit Rules
RESIZING QUOTAS
THE QUOTA RESIZE COMMAND

The quota resize command adjusts currently active quotas to reflect changes in the
/etc/quotas file. For example, if you edit an entry in /etc/quotas to increase a quota,
executing the quota resize command causes the change to take effect. To view active
quotas, create a quota report before and after the quota resize.
Use quota resize only when quotas are already set for the volume. The quota resize
command implements additions and changes to the /etc/quotas file.
Resizing Quotas (Cont.)
For changes to take effect, you must select Resize.
RESIZING QUOTAS (CONT.)
USING FILERVIEW
You can also use FilerView to view reports showing quota usage for volumes. To access the
Reports function, enter your storage system address into your browser, and select Volumes.
Then click Quotas > Report.
Quota Information
Beginning with Data ONTAP version 7.3,

AutoSupport contains the following quota
information:
– A collection of quota statistics, including a set of
new counters that collect quota statistics
– The quota configuration file (/etc/quotas)
– The user mapping file (/etc/usermap.cfg)
Quota information is included in ASUP as
attachments
QUOTA INFORMATION
QUOTA INFORMATION IN AUTOSUPPORT

Starting with Data ONTAP 7.3, AutoSupport now includes quota information, which allows
NetApp to improve its response to quota-related support questions. Prior to the release of
Data ONTAP 7.3, if you had a quota-related support question, it was necessary for you to
gather the appropriate information and send it to NetApp support, which sometimes created a
delay of several days. With the inclusion of quota information in the latest version of Data
ONTAP AutoSupport, this information is automatically sent to NetApp. Quota information in
AutoSupport also allows NetApp to store quota statistics that are useful for analysis.
Quota information is included in AutoSupport as an attachment. The attachment name
appears in the format YYYYMMDDHHMM.N.quotas.gz. For privacy protection, the contents of
the quota files are scrambled.
The AutoSupport attachment contains three types of quota information”
• A collection of quota statistics
• The configuration file, /etc/quotas
• The user-mapping file, /etc/usermap.cfg
Module Summary

Qtrees allow administrators to create logical
file systems within a volume
Quotas are applied to qtrees
The /etc/usermap.cfg file allows Windows
users to be mapped to a UNIX account or
UNIX users to be mapped to a Windows
account
The /etc/quotas file defines qtree, volume,
and user quotas for specific users as well as
the default user
MODULE SUMMARY
Exercise
Module 10: Qtrees and Security
Styles
EXERCISE
SAN

MODULE 11: SAN
SAN
Module 11
SAN
11-1 Data ONTAP® 7.3 Fundamentals: SAN
Module Objectives

Explain the purpose of a SAN
Identify supported SAN configurations
Distinguish between FC and iSCSI protocols
Define a LUN and explain LUN attributes
Use the lun setup command and FilerView
to create iSCSI LUNs
Access and manage a LUN from a Windows
host
Define SnapDrive® and its features
MODULE OBJECTIVES
SAN Overview
SAN OVERVIEW
What is a SAN?
Storage Area Network (SAN)
iSCSI
FC Ethernet
Corporate
LAN
SAN NAS
(Blocks) (Files)
NetApp FAS
WHAT IS A SAN?
The Storage Networking Industry Association (SNIA) defines a Storage Area Network (SAN)
as “a network whose primary purpose is the transfer of data between computer systems and
storage elements and among storage elements.”
There are usually three parts to a SAN: host, fabric network, and storage system. SANs may
also be directly connected (host to storage system).
SAN Protocols
WAFL Architecture
Block Services
SAN Protocols
FCP iSCSI
Network Interfaces
FC Ethernet
Encapsulated SCSI Encapsulated SCSI
Fibre Channel Network TCP/IP Network
SAN PROTOCOLS
Network access to LUNs on a NetApp storage system can be either through an FC network or
a TCP/IP-based network. Both of these protocols carry encapsulated SCSI commands as the
data transport mechanism.
SAN Components
SAN COMPONENTS
SAN Components
Hosts
– Supported platforms are Windows, Solaris,
AIX®,HP-UX, Linux, NetWare®, VMware®
– Referred to as “initiators”
Connectivity
– Direct-attach
– Network—Network can be fabric (FCP) or IP
(iSCSI)
Storage system
– Allocates blocks to an initiator group (igroup)
– Referred to as “targets”
SAN COMPONENTS
STORAGE DEVICES
The storage devices in a SAN are the NetApp storage systems.
FABRIC OR NETWORK
Fabrics and networks provide any-to-any connectivity between servers and storage devices.
• FC fabrics use FC switches.
• Ethernet networks use standard Ethernet switches.
HOSTS
Hosts are connected to the fabric or network using:
• FC SAN—Host bus adapters (HBAs) in an FC environment
• IP SAN—Standard NICs or HBAs in an IP SAN environment
FC Components
Host bus adapter (HBA)

Storage systems and hosts have HBAs with
one or more ports.
The HBA is identified by a Worldwide Node
Name (WWNN).
Each port on the HBA is identified by a
Worldwide Port Name (WWPN), which is used
to create igroups.
HBA WWNN
20:00:00:2b:34:26:a6:54
HBA WWPN
21:00:00:2b:34:26:a6:54
22:00:00:2b:34:26:a6:54
FC COMPONENTS
HOW IS AN FC SAN IMPLEMENTED?

An FC SAN requires HBAs (supplied by vendors such as Emulex®) to connect to each other
or to FC switches. Each FCP node is represented by a WWNN and a WWPN. The WWPNs
are used to create igroups. LUNs are mapped to these igroups. This allows the host (whose
WWPN is in a specific igroup) to access LUNs that are mapped to the igroup.
The FC specification for naming nodes and ports on nodes is loosely followed. Each device is
given a globally unique WWNN and an associated WWPN for each port on the node.
WWNNs and WWPNs are made up of 16 hexadecimal digits grouped together in twos, with a
colon separating each pair (for example, 21:00:00:2b:34:26:a6:54).
The FC WWN (worldwide name) specification states that the first four digits of a node should
be 1N:NN, where 1 defines it as a node, and the next three numbers (N:NN) are reserved for
WWPN port definition.
The first four digits of a port should be 2N:NN, where the 2 defines it as a port, and the next
three numbers (N:NN) are reserved for WWPN port definition.
In the example above, 21:00 represents Port 1 (Port 2 is 22:00). Port 1 could also have been
represented as 20:01 (or 20:02 for Port 2). HBA vendors follow naming conventions
loosely, and, in many cases, they use 20:00 for the node and 21:00 for the port.
iSCSI Components
A host is configured with one of the following:

– Software initiators with a standard NIC
– TCP Offload Engine (TOE) with a software
initiator
– iSCSI HBA
A host initiator is identified by a WWNN, such
as the following:
– iqn.1998-02.com.netapp:sn12345678
– eui.1234567812345678
A storage system is configured with either:
– iSCSI HBA
– Standard NIC
B
ISCSI COMPONENTS
HOW IS AN ISCSI SAN IMPLEMENTED?

The naming convention for nodes in iSCSI is the same as in FC. There are two formats for
node names: iqn and eui. These node names are used to create igroups. LUNs are mapped
to the igroups. Hosts that have node names in an igroup can see LUNs mapped to that igroup.
You can implement iSCSI on a host using one of the following methods:
• Initiator software that uses the host’s standard Ethernet interfaces
• An iSCSI HBA
• TOE adapter that offloads TCP/IP processing (iSCSI protocol processing is performed by host
software)
Storage controllers are connected to the network through standard Ethernet interfaces or
through target HBAs.
Nodes are identified in IP SAN environments by a node identifier using the following
formats:
• iqn.1998-02.com.netapp:sn12345678
• eui.1234567812345678
The host node names are used to create igroups, which control host access to LUNs.
Initiator/Target Relationship
Host (Initiator) Fabric/Network Controller (Target)
FC HBAs
Windows or UNIX Storage System
FC FC SAN Services
Application
Driver SCSI over FC Driver
iSCSI HBAs WAFL

File SCSI iSCSI
System Driver Driver
RAID
SCSI over TCP/IP
(iSCSI)
iSCSI TCP TCP
Driver /IP /IP
SCSI over TCP/IP
(iSCSI)
Ethernet NICs Data ONTAP
SCSI Adapters FC or SATA

LUN Attached
Direct-Attached Storage
INITIATOR/TARGET RELATIONSHIP
An initiator is a host in a SAN. The initiator communicates directly with a target, or over a
network. The network can be either IP-based with iSCSI, or a fabric with FCP. The controller
or target receives calls from the initiator and allows it access to LUNs.
LUN Overview
A LUN (Logical Unit Number) is:

A logical representation of storage
Configured as a single disk
Appears as a local disk on the host
Centrally stored, but managed by a host at the
block level

B
LUN OVERVIEW
Block-based storage is defined by logical unit numbers (LUNs). A LUN is a logical

representation of a physical unit of storage.
A LUN is a collection, or part of a collection, of physical or virtual disks that are configured
as a single disk. LUNs appear as local disks that can be formatted and managed by the host.
LUNs are managed at the block level, so Data ONTAP does not interpret the data.
Setting Up a SAN
SETTING UP A SAN
Setting Up a SAN
To set up a SAN:
1. License the appropriate SAN protocol on the
storage system.
2. Create a volume or qtree where the LUN will
reside (apply quotas when appropriate).
3. Verify the SAN protocol driver is on.
4. Configure the host initiator.
5. Create the LUN and igroup, and then
associate the igroup to the LUN.
SETTING UP A SAN
Review Questions
How do you license the appropriate SAN

protocol on the storage system?
How do you create a volume or qtree for a
LUN?
REVIEW QUESTIONS
Managing FCP or iSCSI
After licensing, the FCP or iSCSI drivers can

be activated
To manage the FCP or iSCSI protocols:
– Using the CLI
FCP
fcp [subcommand]
Example: fcp status
iSCSI
iscsi [subcommand]
Examples: iscsi start or iscsi status
– Using FilerView
MANAGING FCP OR ISCSI
After protocols are licensed, you must start the services. For FCP, this requires a reboot. For
iSCSI, you can issue the iscsi start command.
You can administrate FCP and iSCSI from both the CLI and from FilerView.
Configuring the Initiator
Only the initiator(s) identified in the LUN igroup

can access the LUN through the protocol
specified (FCP or iSCSI)
There are different methods for setting up the
initiator depending on:
– Host operating system
– SAN protocol used (FCP or iSCSI)
– Method of connection (HBA or software initiator)
CONFIGURING THE INITIATOR
This module focuses on Windows platforms using the iSCSI Software Initiator from
Microsoft. For more information about configuring iSCSI and FCP LUNs on other platforms,
see the Data ONTAP SAN Administration course.
iSCSI Software Initiator
ISCSI SOFTWARE INITIATOR
CONFIGURING MICROSOFT ISCSI SOFTWARE INITIATOR

To configure the iSCSI Software Initiator:
2. Install the Microsoft iSCSI Software Initiator.
3. In the Discovery tab, specify the storage system’s IP address as a target portal.
iSCSI Software Initiator (Cont.)
ISCSI SOFTWARE INITIATOR (CONT.)
CONFIGURING MICROSOFT ISCSI SOFTWARE INITIATOR (CONT.)
4. The storage system WWNN is displayed in the target table.

5. Select the WWNN and click Log On.
iSCSI Software Initiator (Cont.)
ISCSI SOFTWARE INITIATOR (CONT.)
CONFIGURING MICROSOFT ISCSI SOFTWARE INITIATOR (CONT.)
6. In the Log On to Target window, if you select “Automatically restore this connection when the
system reboots,” then the connection appears in the Persistent Targets tab.
Creating LUNs
Create LUNs using one of the following methods:

The CLI:
– lun create
– lun setup
FilerView
SnapDrive (covered later in this module)
CREATING LUNS
METHODS FOR CREATING LUNS

You can create a LUN using one of the following methods:
1. Use the lun create command on the storage system.
a. This command only creates a LUN.
b. When using this command, you must complete the following additional configuration
steps:
i. Create initiator groups using the igroup screate command.
ii. Map the LUN to an initiator group using the lun map command.
iii. Add portset (FCP).
2 Use the lun setup command on the storage system. This command is a wizard that walks you
through creating and mapping the LUN and igroup.
3 Use FilerView on a client host.
4 Use SnapDrive on a client host.
The lun setup Command
system> lun setup

This setup will take you through the steps needed to create LUNs
and to make them accessible by initiators. You can type ^C (Control-C)
at any time to abort the setup and no unconfirmed changes will be made
to the system.
Do you want to create a LUN? [y]: y
Multiprotocol type of LUN (image/solaris/windows/hpux/aix/linux) [image]: windows
A LUN path must be absolute. A LUN can only reside in a volume or
qtree root. For example, to create a LUN with name "lun0" in the
qtree root /vol/vol1/q0, specify the path as "/vol/vol1/q0/lun0".
Enter LUN path: /vol/winvol/tree1/lun0
A LUN can be created with or without space reservations being enabled.
Space reservation guarantees that data writes to that LUN will never
fail.
Do you want the LUN to be space reserved? [y]: y
Size for a LUN is specified in bytes. You can use single-character
multiplier suffixes: b(sectors), k(KB), m(MB), g(GB) or t(TB).
Enter LUN size: 12g
You can add a comment string to describe the contents of the LUN.
Please type a string (without quotes), or hit ENTER if you don't
want to supply a comment.
Enter comment string: Windows LUN
THE LUN SETUP COMMAND
CREATING AN ISCSI LUN FOR WINDOWS
When creating an iSCSI LUN for Windows, the LUN will have the following attributes:
OPERATING SYSTEM WINDOWS

Path /vol/winvol/tree1/lun0
Space Reservation Yes (Y)
Size 12 gigabyte (12g)
igroup Type iSCSI
Node Name iqn.1991-05.com.microsoft:slu2-
win.edsvcs.netapp.com
OS for Initiator Group Windows
LUN ID 0
The lun setup Command (Cont.)
The LUN will be accessible to an initiator group. You can use an

existing group name, or supply a new name to create a new initiator
group. Enter '?' to see existing initiator group names.
Name of initiator group: ?
Existing initiator groups:
Name of initiator group: salesigroup
Type of initiator group salesigroup (FCP/iSCSI) [FCP]: iscsi
An iSCSI initiator group is a collection of initiator node names.Each
node name can begin with either 'eui.' or 'iqn.' and should be in the
following formats: eui.{EUI-64 address} or iqn.yyyy-mm.{reversed domain
name}:{any string}
Eg: iqn.2001-04.com.acme:storage.tape.sys1.xyz or eui.02004567A425678D
You can separate node names by commas. Enter '?' to display a list of
connected initiators. Hit ENTER when you are done adding node names to
this group.
Enter comma separated nodenames: ?
Initiators connected on adapter iswta:
iSCSI Initiator Name Group
iqn.1991-05.com.microsoft:slu2-win.edsvcs.netapp.com
Adapter iswtb is running on behalf of the partner.

Enter comma separated nodenames: iqn.1991-05.com.microsoft:slu2-win.edsvcs.netapp.com
Enter comma separated nodenames:
THE LUN SETUP COMMAND (CONT.)
The lun setup Command (Cont.)
The initiator group has an associated OS type. The following are

currently supported: solaris, windows, hpux, aix, linux or default.
OS type of initiator group "salesigroup" [windows]: windows
The LUN will be accessible to all the initiators in the
initiator group. Enter '?' to display LUNs already in use
by one or more initiators in group "salesigroup".
LUN ID at which initiator group "salesigroup" sees "/vol/winvol/tree1/lun0"[0]: 0
LUN Path : /vol/winvol/tree1/lun0
OS Type : windows
Size : 12.0g (12889013760)
Comment : Windows LUN
Initiator Group : salesigroup
Initiator Group Type : iSCSI
Initiator Group Members : iqn.1991-05.com.microsoft:slu2-win.edsvcs.netapp.com
Mapped to LUN-ID : 0
Do you want to accept this configuration? [y]: y
Do you want to create another LUN? [n]: n
NetApp1> lun show -m
LUN path Mapped to LUN ID
-------------------------------------------------------------
/vol/winvol/tree1/lun0 salesigroup 0
system>
THE LUN SETUP COMMAND (CONT.)
Creating a LUN Using FilerView
CREATING A LUN USING FILERVIEW
To create a LUN using the FilerView LUN Wizard, complete the following steps:
1 In the FilerView left navigation pane, click LUNs > Wizard.
2. To open the Specify LUN Parameters window, click Next.
3. Follow the Wizard instructions and enter all requested information.
4. To open the Commit Changes window, click Next.
5. If the information displayed is correct, click Commit.
Accessing a LUN
ACCESSING A LUN
Accessing a LUN
ACCESSING A LUN
After creating a LUN with the lun setup command, use Windows Disk Management on the
host to prepare the LUN for use. The new LUN should be visible as a local disk. If it is not,
click the Action button in the toolbar, and then click Rescan Disks.
Disk Management will:
1 Write the disk signature
2 Partition the disk
3 Format the disk
Accessing a LUN (Cont.)
ACCESSING A LUN (CONT.)
To open the Create Partition Wizard, right-click the bar that represents the unallocated disk
space, and then select Create Partition. Or, from the Action dropdown menu in the Computer
Management window, you can click All Tasks > Create Partition.
Select either a Primary or Extended partition.
Create a Primary partition no larger than the maximum size available. Choose the partition
size and drive letter.
Accept the default drive assignment or use the drop-down list to select a different drive.
Partition the drive using the settings shown, but change the Volume Label to an appropriate
Windows volume name that represents the LUN you are creating.
Review the settings specified and then click Finish.
Verify that the LUN appears as a local drive in Disk Management. If it appears as a local
drive, you can then copy files to the new disk and treat it like any other local disk.
SnapDrive
SNAPDRIVE
SnapDrive
SnapDrive ensures consistent LUN Snapshots

and is available:
– From NetApp to manage a LUN from a host
– For the Windows, Solaris, Linux, AIX, and HP-
UX platforms
SnapDrive can create an iSCSI LUN on the
storage system and automatically attach it to
the client host
NOTE: If SnapDrive is used to create a LUN, you must use
SnapDrive to manage that LUN. Do not use the CLI to delete,
rename, or otherwise manage a LUN created by SnapDrive.
SNAPDRIVE
SnapDrive is management software for Windows 2000, Windows 2003, and Windows 2008
systems that provides virtual-disk and Snapshot management on the client side. Use
SnapDrive to create FCP or iSCSI LUNs on a Windows host.
SnapDrive includes three main components:
1. Windows 2000 service
2. Microsoft Management Console (MMC) plug-in
3. CLI
SnapDrive includes the same features of the lun setup command on the storage system, but
also includes the ability to add LUNs to the Windows host and integrates use of LUNs into
other NetApp applications such as SnapManager.
SnapDrive for Windows
SNAPDRIVE FOR WINDOWS
SnapDrive for Windows provides an interface for Windows to interact with LUNs directly.
SnapDrive also:
• Enables online storage configuration, LUN expansion, and streamlined management
• Integrates Snapshot technology to create point-in-time images of data stored in LUNs
Other SAN Administration Resources
For more information about SAN administration, see the
SAN Administration on Data ONTAP 7.3 course.
This advanced course covers:
Creating FCP and iSCSI LUNs from the CLI
Creating FCP and iSCSI LUNs from SnapDrive with
Windows
Creating FCP and iSCSI LUNs from SnapDrive with
Solaris
Configuring Solaris hosts for FCP and iSCSI
Configuring Windows hosts for FCP and iSCSI
Configuring other hosts, such as Linux, HP-UX, and
AIX
SAN in a clustered storage system environment
SAN performance tuning
SAN troubleshooting
OTHER SAN ADMINISTRATION RESOURCES
Module Summary

A SAN is a Storage Area Network
A LUN is a Logical Unit Number
The lun setup command and FilerView are
common ways to create LUNs
iSCSI is a simple but effective protocol to
connect to a LUN
To access a LUN from a Windows host, use
Disk Management
SnapDrive creates a LUN and connects to that
LUN quickly and securely
MODULE SUMMARY
Exercise
Module 11: SAN
EXERCISE
Snapshot Copies

MODULE 12: SNAPSHOT COPIES
Snapshot Copies
Module 12
SNAPSHOT COPIES
12-1 Data ONTAP® 7.3 Fundamentals: Snapshot Copies
Module Objectives

Describe the function of Snapshot copies
Explain the benefits of Snapshot copies
Identify and execute Snapshot commands
Create and delete a Snapshot copy
Configure and modify Snapshot options
Explain the importance of the .snapshot directory
Describe disk space consumed by a Snapshot for
volumes and aggregates
Schedule a Snapshot copy through FilerView
Configure and manage the Snapshot reserve
MODULE OBJECTIVES
Overview
OVERVIEW
Snapshot Technology
A Snapshot copy is a read-only image of a

volume at a point in time
The benefits of Snapshot technology are:
– Nearly instantaneous application data backups
– Fast recovery of data lost due to:
Accidental data deletion
Accidental data corruption
Snapshot technology is the foundation for:
– SnapRestore® SnapManager®
– SnapDrive® SnapMirror®
– FlexClone® SnapVault®
SNAPSHOT TECHNOLOGY
The Snapshot technology is a key element in the implementation of the WAFL (Write
Anywhere File Layout) file system.
• A Snapshot copy is a read-only, space-efficient, point-in-time image of data in a volume or
aggregate
• A Snapshot copy is only a “picture” of the file system and does not contain any data file content
• Snapshot copies are used for backup and error recovery
Data ONTAP automatically creates and deletes Snapshot copies of data in volumes to support
commands related to Snapshot technology.
Snapshot and WAFL
Snapshot technology is a core feature of the

storage system’s WAFL file system
Every file in WAFL has at least one inode that
organizes its data
Each volume can contain up to 255 Snapshot
copies
SNAPSHOT AND WAFL
Inodes
An inode is a data structure that is used to

represent file system objects such as files and
directories
An inode is 192 bytes that describes a file’s
attributes and includes the following:
– Type of file (regular file, directory, link, and so
on)
– Size
– Owner, group, permissions
– Pointer to xinode (ACLs)
– Complete file data if the file is 64 bytes or less
– Pointers to data blocks
INODES
WAFL FILES AND INODES

WAFL inodes are similar to Berkeley Fast File System (FFS) inodes. The Veritas and
Microsoft file systems are based on the Berkeley FFS, which force writes to preallocated
locations. The primary difference between WAFL and the Berkeley FFS is in the way WAFL
writes contiguous data and metadata blocks to the next available block, instead of to
predefined locations.
ROOT INODES
The most important metadata file is the inode file, which contains the inodes that describe all
other files in the file system. The inode that describes the inode file itself is the root inode.
The root inode is a fixed-disk location.
Snapshot Copies and Inodes
Snapshot copies are a copy of the root inode

of a volume
The inodes of a Snapshot copy are read-only
When the Snapshot inode is created:
– It points to exactly the same disk blocks as the
root inode
– Brand new Snapshot copies consume only the
space for the inode itself
SNAPSHOT COPIES AND INODES
A Snapshot copy is a frozen, read-only image of a traditional volume, a FlexVol volume, or

an aggregate that reflects the state of the file system at the time the Snapshot copy was
created. Snapshot copies are your first line of defense for backing up and restoring data. You
can configure the Snapshot copy schedule.
Managing Inodes
To verify the amount of inodes:

df -i
To increase the maximum:
maxfiles
MANAGING INODES
LEVEL 4 INODES
For file sizes between 64 GB and 8 TB, the single-indirect blocks in Level 3 inodes become
double-indirect blocks. These double-indirect blocks reference 1,024 single-indirect blocks,
which then reference up to 1024 4 kB data blocks.
DF -I
The df -i command displays the amount of inodes in a volume. For more information about
this command, see the manual pages.
MAXFILES
The maxfiles command increases the number of inodes designated in a volume. For more
information about this command, see the manual pages.
How Snapshot Works
Active Data
File X
Disk Blocks A B C
HOW SNAPSHOT WORKS
Before a Snapshot copy is created, there is a file system tree pointing to data blocks that
contain content. When the Snapshot copy is created, a copy of the file structure metadata is
created. The Snapshot copy points to the same data blocks.
How Snapshot Works (Cont.)
Active Data Snapshot
File X File X
Disk Blocks A B C Blocks are “frozen” on disk
Consistent point-in-time copy

Ready to use (read-only)
Consumes no space*
* With the exception of 4 kB replicated root inode block that defines the Snapshot
HOW SNAPSHOT WORKS (CONT.)
There is no significant impact on disk space when a Snapshot copy is created. Because the
file structure takes up little space, and no data blocks must be copied to disk, a new Snapshot
copy consumes almost no additional disk space. In this case, the phrase “Consumes no space”
really means no appreciable space. The so-called “top-level root inode,” which is necessary
to define the Snapshot copy, is 4 kB.
File/LUN: X File/LUN: X
Disk Blocks A B C C’
Client sends
new data for New
block C Data
Snapshot copies begin to use space when data is deleted or modified. WAFL writes the new
data to a new block (C’) on the disk and changes the root structure for the active file system
to point to the new block.
Meanwhile, the Snapshot copy still references the original block C. As long as there is a
Snapshot copy referencing a data block, the block remains unavailable for other uses. This
means that Snapshot copies start to consume disk space only as the file system changes after a
Snapshot copy is created.
File X File X
Active version of X is now composed of blocks A, B, C’

Snapshot version of X remains composed of blocks A, B, C
Atomically moves active data to new consistent state
Creating Snapshot
Copies
CREATING SNAPSHOT COPIES
Taking a Snapshot Copy
Administrators can take Snapshot copies of:

– Aggregates
Aggregate default for Snapshot reserve is 5% of aggregate
Restoring an aggregate Snapshot copy restores all volumes
within that aggregate
– Volumes
Volume default for Snapshot reserve is 20% of volume
Administrators can restore the entire volume or one or more
files
To change the amount of Snapshot reserve:
snap reserve [ -A | -V ] [volume_name]
[percent]
TAKING A SNAPSHOT COPY
VOLUMES
Snapshot copies for traditional and flexible volumes are stored in special subdirectories that
can be made accessible to Windows and UNIX clients so that users can access and recover
their own files without assistance. The maximum number of Snapshot copies per volume is
255.
AGGREGATES
In an aggregate, 5% of space is reserved for Snapshot copies. In normal, day-to-day
operations, aggregate Snapshot copies are not actively managed by a system administrator.
For example, Data ONTAP automatically creates Snapshot copies of aggregates to support
commands related to the SnapMirror software, which provides volume-level mirroring.
NOTE: Even if the Snapshot reserve is 0%, you can still create Snapshot copies. If there is no
Snapshot reserve, Snapshot copies take their blocks from the active file system.
Snapshot Reserve
Aggregates Aggregate Space
Each aggregate has 5% allocated for

Snapshot reserve and 10% allocated WAFL Overhead
for WAFL.
Volume Space
Flexible Volumes
Each volume has 20% allocated for
Snapshot reserve. The remainder is Active File 80%
used for client data. System
Snapshot Reserve snap reserve 20%

The amount of space allocated for
Snapshot reserve is adjustable. To
use this space for data (not
recommended), you must manually
override the allocation used for
Snapshot copies.
Snap Reserve 5%
SNAPSHOT RESERVE
HOW DISK SPACE IS ALLOCATED FOR TRADITIONAL VOLUMES
AGGREGATES
The size of an aggregate depends on the number and size of disks allocated to it. Ten percent
of the aggregate is allocated for WAFL. Five percent of the aggregate is allocated for the
Snapshot reserve.
FLEXIBLE VOLUMES
By default, a flexible volume has 20% of its space allocated for the Snapshot reserve. More
than one flexible volume can exist in an aggregate. Each flexible volume, however, has 20%
allocated for Snapshot reserve. To use the Snapshot reserve space for data (not
recommended), you must manually override the allocation for Snapshot copies. The
remainder of space can be used for client data.
SNAPSHOT RESERVE
The Snapshot reserve for an aggregate does not automatically expand into the WAFL
aggregate space. When space is needed the Snapshot copies, by default, older, aggregate
Snapshot copies are replaced by new Snapshot copies. The Snapshot aggregate reserve size is
adjustable using the snap reserve –A command.
On volumes, the Snapshot reserve space is expanded into user space as required by the
system (for example, if numerous changes are made to the active file system). If necessary, as
new Snapshot copies are created, the Snapshot reserve expands into user space regardless of
the designated Snapshot reserve amount. You can manually reallocate disk space using the
snap reserve command.
Creating Snapshot Copies
Snapshot copies can be:

– Scheduled
– Manual
To manually create Snapshot copies, use
either:
– The CLI:
snap create [ -A | -V ] [volname]
[snapshotname]
– FilerView
To rename Snapshot copies:
snap rename [ -A | -V ] [volname]
[oldfilename] [newfilename]
CREATING SNAPSHOT COPIES
SNAPSHOT COMMANDS
In the snap command, the option A is used for aggregates and the option V is used for
volumes. If neither A nor V is specified, volume is the default.
The following table lists the commands used to create and manage Snapshot copies. If you
omit the volume name from any of these commands, the command will apply to the root
volume.
EXAMPLE RESULT
snap create engineering test Creates the Snapshot copy, test, in the engineering
volume.
snap list engineering Lists all available Snapshot copies in the engineering
volume.
snap delete engineering test Deletes the Snapshot copy test in the engineering
volume.
snap delete –a vol2 Deletes all Snapshot copies in vol2.
snap rename engineering nightly.0 Renames the Snapshot copy from nightly.0 to firstnight.0
firstnight.0 in the engineering volume.
snap reserve vol2 25 Changes the Snapshot reserve to 25 % on vol2.
snap sched vol2 0 2 6 @ 8, 12, 16, Sets the automatic schedule on vol2 to save the following
20 weekly Snapshot copies: 0 weekly, 2 nightly, and 6
hourly at 8 a.m., 12 p.m., 4 p.m., and 8 p.m.
Restoring Snapshot
Copies
RESTORING SNAPSHOT COPIES
Recovering Data
When recovering data, you have two options:

– Copy the data from a Snapshot copy
– Use SnapRestore
To copy data from a Snapshot copy:
– Locate the Snapshot copy
– Recover the copy from .snapshot directory
To overwrite, copy to the original location
For a new, writeable version, copy to a new
location
RECOVERING DATA
USING SNAPSHOT COPIES TO RECOVER DATA

To recover data, you can:
• Restore a file from a Snapshot copy
• Use SnapRestore (license required)
To restore a file from a Snapshot copy:

1. Locate the Snapshot copy that contains the correct version of the file.
2. Restore the file from the .snapshot directory.
• To overwrite existing data, copy to the original location.
• To restore a writeable version, copy to a new location.
Snapshot Options
Disable automatic Snapshot copies:

vol options volname nosnap [on|off]
Make the .snapshot directory invisible to clients, and
turn off access to the .snapshot directory:
vol options volname nosnapdir [on|off]
Make the ~snapshot directory visible to CIFS clients:
options cifs.show_snapshot [on|off]
Make the .snapshot directory visible to NFS clients:
options nfs.hide_snapshot [on|off]
SNAPSHOT OPTIONS
The following table lists the options available for controlling the creation of Snapshot copies
and access to those copies and Snapshot directories on a volume:
• Disable automatic Snapshot copies. Setting the nosnap option to on disables automatic Snapshot
creation. You can still create Snapshot copies manually at any time.
• Make the .snapshot directory invisible to clients and turn off access to the .snapshot
directory. Setting the nosnapdir option to on disables access to the Snapshot directory that is
present at client mountpoints and the root of CIFS directories, and makes the Snapshot directories
invisible. (NFS uses .snapshot for directories, while CIFS uses ~snapshot.) By default, the
nosnapdir option is off (directories are visible).
• Make the ~snapshot directory visible to CIFS clients by completing the following steps:
1 Turn the cifs.show_snapshot option on.
2 Turn the nosnapdir option off for each volume that you want directories to be visible.
NOTE: You must also ensure that Show Hidden Files and Folders is enabled on your
Windows system.
SNAPSHOT OPTIONS
EXAMPLE RESULT
vol options vol2 nosnap on Disables automatic Snapshot copies for vol2.
vol options vol2 nosnapdir on Makes the .snapshot (or ~snapshot) directory invisible
to clients.
options cifs.show_snapshot on Makes the ~snapshot directory visible to CIFS clients.
SHOWING SNAPSHOT DIRECTORIES USING FILERVIEW

To make Snapshot directories visible, you can also use FilerView to change CIFS
configuration settings.
The .snapshot Directory
/
mnt etc usr var
system
vol0
.snapshot Directory
nightly.0 Directory nightly.1 Directory
Files on vol0 Files on vol0

(as of previous midnight) (as of night-before-last)
THE .SNAPSHOT DIRECTORY
The .snapshot directory is at the root of a volume.

In the figure above, the directory structure is shown for an NFS client mounting vol0 to the
mountpoint /mnt/system.
Snapshot View from a UNIX Client
# pwd
/system/.snapshot
# ls -l
total 240
drwxrwxrwx 9 root other 12288 Jan 29 16:19 hourly.0
drwxrwxrwx 9 root other 12288 Jan 29 16:19 nightly.0
drwxrwxrwx 9 root other 12288 Jan 29 16:19 nightly.1
drwxrwxrwx 9 root other 12288 Jan 29 16:19 weekly.1
drwxrwxrwx 9 root other 12288 Jan 29 16:19 weekly.2
#
SNAPSHOT VIEW FROM A UNIX CLIENT
SNAPSHOT DIRECTORIES
Every volume in your file system contains a special Snapshot subdirectory that allows you to
access earlier versions of the file system to recover lost or damaged files.
VIEWING SNAPSHOT COPIES FROM A UNIX CLIENT

The Snapshot subdirectory appears to NFS clients as .snapshot. The .snapshot
directories are usually hidden and are not displayed in directory listings.
To view a .snapshot directory, complete the following steps:
1. On the storage appliance, log in as root and ensure that the nosnapdir option is set to off.
2. To view hidden directories, from the NFS mountpoint, enter the ls command with the -a (all)
option.
When listing the client Snapshot directories, the date/time stamp is usually the same for all
directories. To find the actual date/time of each Snapshot, use the snap list command on
the storage system.
Snapshot View from a Windows Client
Snapshot copies are visible to

Windows clients that have File
Manager configured to display
“hidden files.”
SNAPSHOT VIEW FROM A WINDOWS CLIENT
Snapshot directories are hidden on Windows clients. To view them, you must first configure
the File Manager to display hidden files, then navigate to the root of the CIFS share and find
the directory folder.
The subdirectory for Snapshot copies appears to CIFS clients as ~snapshot. Files displayed
here are those files created automatically for specified intervals. Manually created Snapshot
copies would also be listed here.
RESTORING A FILE
To restore a file from the ~snapshot directory, rename or move the original file, then copy
the file from the ~snapshot directory to the original directory.
Scheduling Snapshot
Copies
SCHEDULING SNAPSHOT COPIES
Scheduling Snapshot Copies
Default schedule:
– Once nightly, Monday through Saturday, at
midnight (12 a.m.)
– Four hourly at 8 a.m., 12 p.m., 4 p.m., and 8
p.m.
Retains:
– Two most recent nightly
– Six most recent hourly
First in, First out:
– Oldest nightly Snapshot copy
– Oldest hourly Snapshot copy
SCHEDULING SNAPSHOT COPIES
Snapshot Schedule
Function Function
Entering the command with no arguments Entering the command with just a volume
prints the current Snapshot schedule for all name argument prints the schedule for the
volumes in the system. specified volume.
Function
Snapshot Command Syntax
The values in these positions specify how
snap sched [volume_name [weeks [days [ hours[@list]]]]] many Snapshot copies will be saved for each
interval (weekly, daily, and hourly). In the
Example: snap sched vol2 0 2 6@8,12,16,20 example, the zero means that no weekly
Snapshot copy will be made or saved.
Function
The hourly variable has an optional list
attached to it. Enter values here to specify
which times Snapshot copies are taken.
If you don’t enter a list, the default is hourly.
The Snapshot schedule above keeps the following Snapshot copies for vol2:
No weekly Snapshot copies
Two nightly Snapshot copies
Six hourly Snapshot copies taken at 8 a.m., 12 p.m., 4 p.m., and 8 p.m.
SNAPSHOT SCHEDULE
THE SNAP SCHED COMMAND

The snap sched command sets a schedule to automatically create Snapshot copies and
specifies how many of each type are stored. When the limit is reached, the oldest Snapshot
copy for each interval is deleted and replaced by a new Snapshot copy.
The figure above shows a default schedule specifying that Snapshot copies will be taken at 8
a.m., 12 noon, 16:00, and 20:00 (the latter two on the 24-hour clock), and that the two most
recent daily Snapshot copies and the six most recent hourly Snapshot copies will be kept.
Snapshot copies are like a picture of a volume. The only difference between a weekly
Snapshot copy and a nightly or hourly copy is the time at which the Snapshot copy was
created and any data that was changed between the Snapshot copies.
Using FilerView to
Schedule Snapshot Copies
USING FILERVIEW TO SCHEDULE SNAPSHOT COPIES
The Snapshot copy feature is turned on by default and uses a preset schedule until it is
changed by an administrator using the snap sched command, or the FilerView graphical
interface.
To modify the schedule for an existing Snapshot copy using FilerView:

1. From the FilerView left navigation pane, select Volumes > Snapshots > Configure.
2. Enter the new Snapshot copy schedule information.
3. To activate the schedule, click Apply.
To create a brand new Snapshot copy using FilerView:

1. From the FilerView left navigation pane, select Volumes > Snapshots > Add.
2. Select a volume and insert a new Snapshot copy name.
3. To create the new Snapshot copy, click Add.
To view a list of current Snapshot copies using FilerView:
From the FilerView left navigation pane, select Volumes > Snapshots > Manage.
To manually delete individual Snapshot copies from a volume using FilerView:

1. From the FilerView left navigation pane, select Volumes > Snapshots > Manage.
2. Click the check box next to the Snapshot copy you want to delete.
3. Click Delete.
4. To verify the deletion, click OK.
Space Usage
SPACE USAGE
Using the CLI to Monitor Space Used
To monitor space used for Snapshot copies, use:

– From the CLI:
snap list
– FilerView
To determine how much space you will get back:
– snap reclaimable
– snap delta
To delete:
– A particular Snapshot copy:
snap delete [ -A | -V ] [volumename]
[snapshotname]
– All Snapshot copies:
snap delete [ -A | -V ] -a [volumename]
USING THE CLI TO MONITOR SPACE USED
The snap list Command
%Used Snapshot List Example
The % used column shows the relationship
between accumulated Snapshot copies and
the total disk space consumed by the active system> snap list
file system. Values in parentheses show the Volume vol0
contribution of this individual Snapshot copy. working...
%used %total date name
------- ------ ------------ --------
%Total 0% (0%) 0% (0%) Apr 20 12:00 hourly.0
The % total column shows the relationship
between accumulated Snapshot copies and
17% (20%) 1% (1%) Apr 20 10:00 hourly.1
the total disk space consumed by the 33% (20%) 2% (1%) Apr 20 08:00 hourly.2
volume.
Values in parentheses show the contribution
of this individual Snapshot copy.
Date
The date column shows the date and time
the
Snapshot copy was taken. Time is indicated
on the 24-hour clock, and in this example
reflects the hours set in the automatic
Snapshot schedule.
Name
Scheduled Snapshot copies are
automatically
renumbered as new ones are taken so that
the most recent is always “.0.” This also
ensures that the file with the highest number
is always the oldest.
THE SNAP LIST COMMAND
The snap list command displays a single line of information for each Snapshot copy in a
volume. In the Snapshot List Example in the figure above, a list of Snapshot copies is
displayed for the engineering volume.
The following is a description of each column in the list:
• %used—Shows the relationship between accumulated Snapshot copies and the total disk space
consumed by the active file system. Values in parentheses show the contribution of this individual
Snapshot copy.
• %total—Shows the relationship between accumulated Snapshot copies in the total disk space
consumed by the volume. Values in parentheses show the contribution of this individual Snapshot
copy.
• date—Shows the date and time the Snapshot copy was taken. Time is indicated on the 24-hour
clock, and in this example, reflects the hours set in the automatic Snapshot copy schedule.
• name—Lists the names of each of the saved Snapshot copies. Scheduled Snapshot copies are
automatically renumbered as new ones are created so that the most recent copy is always .0. This
also ensures that the file with the highest number (in this case, hourly.2) is always the oldest
Snapshot copy.
EXAMPLES: SNAP LIST

The following examples demonstrate how the %used values in snap list command output
relate to the size of Snapshot copies, and how to determine which Snapshot copies to delete to
reclaim the most space.
EXAMPLE 1: NO CHANGES HAVE BEEN MADE TO THE VOLUME SINCE THE CREATION OF
SNAPSHOT COPIES
The NetApp storage system /vol/vol0 has used 100 MB. No data has changed since the
Snapshot was taken. The snap list command output shows:
NetApp> snap list
Volume vol0
working...
---------- ---------- -------- --------
0% ( 0%) 0% ( 0%) Apr 20 08:00 hourly.0
The space used by the hourly.0 snapshot is 0%. No changes have been made to the files in
/vol/vol0, so no blocks have changed between the Snapshot copy and the active file
system.
EXAMPLE 2: CHANGES HAVE BEEN MADE TO THE VOLUME SINCE THE CREATION OF
SNAPSHOT COPIES
At 9:30 a.m., a 20-MB file is deleted and a new 20 MB file is created. At 10 a.m., a new
hourly Snapshot copy is taken. The snap list command output now shows:
NetApp> snap list
Volume vol0
working...
-------- -------- --------- --------
0% ( 0%) 0% ( 0%) Apr 20 10:00 hourly.0
20% ( 20%) 1% ( 1%) Apr 20 08:00 hourly.1
The hourly.1 Snapshot copy now consumes space because it holds the blocks for the 20-
MB file that was deleted from the active file system. The hourly.0 Snapshot copy
consumes no space because no changes were made to the volume after this Snapshot copy
was created.
EXAMPLE 3: CHANGES HAVE BEEN MADE TO THE VOLUME BETWEEN THE SNAPSHOT
CREATIONS
At 11:30 a.m., the 20-MB file created at 9:30 a.m. was deleted. At 12 noon, the hourly.0
Snapshot is created. The snap list command output now shows:
NetApp> snap list
Volume vol0
working...
---------- ---------- ---------- --------
0% ( 0%) 0% ( 0%) Apr 20 12:00 hourly.0
17% ( 20%) 1% ( 1%) Apr 20 10:00 hourly.1
33% ( 20%) 2% ( 1%) Apr 20 08:00 hourly.2
In this list, hourly.2 and hourly.1 both contain 20 MB of data that no longer exists in the
active file system (AFS). However, each file references different blocks on the system’s
disks.
The space used by the Snapshot copies is:

• Percentage of space used by hourly.1 = 20%
• 20 MB held in hourly.1 x 100%
• 20 MB in hourly.1 + 80 MB in vol0 AFS
• Space held by hourly.2 = 20%
• 20 MB in hourly.2 + 80 MB in vol0 AFS
• Cumulative space used by hourly.2 = 33%
• 20 MB in hourly.2 + 20 MB in hourly.1 + 80 MB in vol0 AFS
The snap reclaimable and snap delta
Commands
snap reclaimable
system> snap reclaimable vol0 hourly.0 nightly.0
Processing (Press Ctrl-C to exit) ...........................
snap reclaimable: Approximately 47108 Kbytes would be freed.
snap delta (Provides the rate of change)

system> snap delta vol0
Volume vol0
working...
From Snapshot To kB changed Time Rate(kB/hour)
-------------------------------------------------------
--nightly.0 AFS 46932 0d 23:00 3911.000
nightly.1 nightly.0 16952 1d 00:00 4237.705

nightly.2 nightly.1 16952 1d 00:00 4237.705
THE SNAP RECLAIMABLE AND SNAP DELTA COMMANDS
NEW SNAP COMMANDS
THE SNAP RECLAIMABLE COMMAND

If your storage system is running Data ONTAP 7.0 or later, the snap reclaimable
command provides an easy method to determine the amount of space that can be freed by
deleting a Snapshot copy. This command can be run against a single Snapshot copy or
multiple Snapshot copies. The snap reclaimable command can take some time to run,
because it is calculating blocks unique to the Snapshot copy (or copies) queried.
For example, a snap list command shows the following Snapshot copies on vol0:
NetApp> snap list
Volume vol0
---------- -------- ---------- --------
4% ( 4%) 0% ( 0%) Apr 20 08:00 hourly.0
5% ( 0%) 0% ( 0%) Apr 20 00:00 nightly.0
You can run the snap reclaimable command to determine how much space you can save
by deleting these Snapshot copies:
NetApp> snap reclaimable vol0 hourly.0 nightly.0
Processing (Press Ctrl-C to exit)
..................................................
snap reclaimable: Approximately 47,108 kB would be freed.
THE SNAP DELTA COMMAND
If your storage system is running Data ONTAP 7.0 or later, the snap delta command
provides an easy method to determine the rate of data change between Snapshot copies on a
volume. This command can be run for a single Snapshot copy, multiple Snapshot copies, or
all volumes on the storage system.
A possible application for this command could be in planning SnapMirror updates. For
example, if you are planning to implement SnapMirror and need to know the approximate
rate of change between Snapshot copy intervals (to estimate the size of the SnapMirror
transfers), the snap delta command can be used to display this rate:
NetApp> snap list
Volume vol0
working...
-------- -------- ------------ --------
4% ( 4%) 0% ( 0%) Apr 20 00:00 nightly.0
5% ( 1%) 0% ( 0%) Apr 19 00:00 nightly.1
5% ( 0%) 0% ( 0%) Apr 18 00:00 nightly.2
NetApp> snap delta vol0
Volume vol0
working...
From Snapshot To kB changed Time Rate (kB/hour)
---------- ------ ---------- -------- ---------
nightly.0 AFS 46,932 0d 23:00 3,911.000
nightly.1 nightly.0 16,952 1d 00:00 4,237.705
nightly.2 nightly.1 16,952 1d 00:00 4,237.705
In this example, the rate of change is about 16,952 kB per day, assuming that one Snapshot
per day is created.
The snap autodelete Command
Allows the user to define a policy to

automatically delete Snapshot copies when
The volume is nearly full.
Command Syntax:
snap autodelete <vol-name> [on | off | show | reset
help] |
snap autodelete <vol-name> <option> <value>...
Supported options and corresponding values:

commitment try, disrupt
trigger volume, snap_reserve, space_reserve
target_free_space 1-100
delete_order oldest_first, newest_first
defer_delete scheduled, user_created, prefix, none
prefix <string>
THE SNAP AUTODELETE COMMAND
The snap autodelete command provides a way to automatically manage Snapshot copies.
EXAMPLES
To enable autodelete on volume vol1:
snap autodelete vol1 on
To disable autodelete on vol1:

snap autodelete vol1 off
To display the current autodelete setting for vol1:

snap autodelete vol1 show
To reset all the autodelete options to the default for vol1:

snap autodelete vol1 reset
The snap autodelete Command:
commitment Option
What Snapshot copies can autodelete remove?
The user can protect certain kinds of Snapshot copies
from deletion
The commitment option defines:
– try
Deletes Snapshot copies that are not being used by any
data mover, recovery, or clones. (NOT LOCKED)
– disrupt
Deletes snapshot copies locked by applications that move
data (such as SnapMirror), dump data, and restore data
(mirror and dumps are aborted).
THE SNAP AUTODELETE COMMAND: COMMITMENT OPTION
commitment Option (Cont.)
prefix <string>
THE SNAP AUTODELETE COMMAND: COMMITMENT OPTION (CONT.)
trigger Option
When does snap autodelete occur?
When the “trigger” criteria is near full:
volume
The volume is nearly full (98%)
snap_reserve
The reserve is nearly full
space_reserve
The space reserved is nearly full (useful for
volumes with fractional_reserve < 100)
THE SNAP AUTODELETE COMMAND: TRIGGER OPTION
trigger Option (Cont.)
prefix <string>
THE SNAP AUTODELETE COMMAND: TRIGGER OPTION (CONT.)
target_free_space Option
When does snap autodelete stop?
When the free space in the trigger criteria
reaches a user-specified percentage, snap
autodelete stops
– This percentage is controlled by the value of
target_free_space
– The default percentage is 80%
prefix <string>
THE SNAP AUTODELETE COMMAND: TARGET_FREE_SPACE OPTION
order Options
In what order are Snapshot copies deleted?
The delete_order option defines the age
order. If the value is set to:
– oldest_first
Delete oldest snapshots first
– newest_first
Delete newest snapshots first
prefix <string>
THE SNAP AUTODELETE COMMAND: ORDER OPTIONS
order Options (Cont.)
Snapshot copies are deleted in the following
order:
The defer_delete option defines the order for
deletion
If the value is set to:
– scheduled
Delete the scheduled Snapshot copies last (identified by the
scheduled Snapshot naming convention)
– user_created
Delete the administrator-created Snapshot copies last
– prefix
Delete the Snapshot copies with names matching the prefix
String last
THE SNAP AUTODELETE COMMAND: ORDER OPTIONS (CONT.)
prefix <string>
In what order are Snapshot copies deleted?
The prefix option value pair is only
considered when defer_delete is set to
prefix. Otherwise, it is ignored.
prefix <string>
Using FilerView to Monitor Space Used
USING FILERVIEW TO MONITOR SPACE USED
Module Summary

The function and benefits of Snapshot copies
How to create and delete Snapshot copies
How to schedule a Snapshot copy using the
CLI and FilerView
How disk space is consumed by a Snapshot
copy for volumes and aggregates
MODULE SUMMARY
Exercise
Module 12: Snapshot Copies
EXERCISE
Writes Reads

MODULE 13: WRITE AND READ REQUEST PROCESSING
Write and Read

Request Processing
Module 13
WRITE AND READ REQUEST PROCESSING
13-1 Data ONTAP® 7.3 Fundamentals: Write and Read Request Processing
Module Objectives

Describe how data is written from and read to
a WAFL file system on a volume
Describe the WAFL file system, including
consistency points, RAID management, and
storage levels
Describe how RAID is used to protect disk data
Describe how the WAFL file system processes
write and read requests
MODULE OBJECTIVES
Data ONTAP Simplified
Client Data ONTAP
Network
Client

Client
Client
NVRAM
Physical Disks
Memory
Client
DATA ONTAP SIMPLIFIED
Data ONTAP is the operating system that all NetApp storage systems use. Data ONTAP,
which simplifies storage management and helps ensure business continuity, is built on three
fundamental elements that provide speed, reliability, and safety for NetApp storage systems:
• Real-time mechanism for process execution
• WAFL file system with NVRAM support
• RAID manager
DATA FLOW
Client systems interact with Data ONTAP through the OS networking layer, with the protocol
layer providing appropriate protocol interfaces. Read and write requests are processed by the
WAFL layer and its associated memory. NVRAM is used to create a backup copy of the
WAFL buffers to prevent data loss. The WAFL determines where data is read from or written
to, and forwards this information to the RAID manager. The RAID manager calculates the
parity value required to protect the stored data.
With the WAFL data placement and RAID information computed, the storage layer writes the
blocks to the appropriate disks, and then Data ONTAP determines the new consistency point.
Write Requests
WRITE REQUESTS
Write Requests
Write requests are received by Data ONTAP

through multiple interface protocols:
– CIFS
– NFS
– FCP
– iSCSI
– HTTP
– WebDAV
Write requests are buffered into:
– System memory
– NVRAM
WRITE REQUESTS
Write Request Data Flow: Write Buffer
Network
Network Protocols NVLOG N
Stack NVLOG V
Memory Buffer NVLOG R
SAN NVLOG A
RS-232 Service NVLOG M
NVRAM Full
SAN Host NFS
HBA Service WAFL
CIFS
UNIX NIC Service
RAID
Client
Storage
Windows
Client
WRITE REQUEST DATA FLOW: WRITE BUFFER
WRITE REQUEST PROCESSING

Write requests are received from clients. Each write request is stored in a memory buffer. A
copy of each write request is stored in the NVRAM. The WAFL acknowledges receipt as
requests once the requests are stored both in memory and battery-backed NVRAM.
Consistency Point
A completely self-consistent image of the file

system. Although dynamic, if the file system
were frozen momentarily to capture its
structure–that is a consistency point
A consistency point occurs when designated
data is written to a disk and a new root inode is
determined
A consistency point occurs for multiple
reasons, including the following:
– One bank of the NVRAM card is full
– 10 seconds have elapsed
CONSISTENCY POINT
TRIGGERING A CONSISTENCY POINT

A consistency point (CP) is a completely self-consistent image of the entire file system. A CP
is accomplished after data has been written to the disk and a new root inode is determined.
Although there are multiple events that trigger CPs, two primary triggers occur when:
• One bank of NVRAM is full
• 10 seconds have elapsed
Consistency Point (Cont.)
During a consistency point, Data ONTAP

flushes writes to disk
– Always writes to new data blocks
– The volume is always consistent on disk
When Data ONTAP flushes memory to disk:
– It updates the file system “atomically,” meaning
that the entire write must be completed or the
entire write is rolled back
– This includes all metadata
– After checking, the NVRAM is cleared
CONSISTENCY POINT (CONT.)
At least once every 10 seconds, the WAFL generates a CP (an internal Snapshot copy) so that
disks contain a completely self-consistent version of the file system. When the storage system
boots, the WAFL always uses the most recent CP on the disks. This means you don’t have to
spend time checking the file system, even after power loss or hardware failure. The storage
system boots in a minute or two, with most of the boot time devoted to spinning up disk
drives and checking system memory.
The storage system uses battery-backed NVRAM to avoid losing data write requests that
might have occurred after the most recent CP. During a normal system shutdown, the storage
system turns off protocol services, flushes all cached operations to disk. and turns off the
NVRAM. When the storage system restarts after a power loss or hardware failure, it replays
into system RAM any protocol requests stored in NVRAM that are not on the disk.
To view the CP types that the storage system is currently using, use the sysstat –x 1 option.
CPs triggered by the timer, a Snapshot copy, or internal synchronization are normal. Other
types of CPs can occur from time to time.
ATOMIC OPERATIONS
An atomic operation in computer science refers to a set of operations that can be combined so
that they appear to the rest of the system to be a single operation, with only two possible
outcomes: success or failure.
To accomplish an atomic operation, the following conditions must be met:
1. Until the entire set of operations is complete, no other process can be “aware” of the changes being
made.
2. If any one operation fails, then the entire set of operations fail and the system state is restored to its
state prior to the start of any operations.
Source: http://en.wikipedia.org/wiki/Atomic_operation
Write Request Data Flow: WAFL to RAID
Network
Stack NVLOG V
SAN NVLOG A
NVRAM Full
SAN Host NFS
HBA Service WAFL
CIFS
UNIX NIC Service
RAID
Client
Storage
Windows
Client
WRITE REQUEST DATA FLOW: WAFL TO RAID
WAFL
The WAFL provides shorter response times to write requests by saving a copy of write
requests in system memory and battery-backed NVRAM, and then immediately sends
acknowledgments. This process is different from traditional servers that must write requests
to the disk before acknowledging them. The WAFL delays writing data to the disk, which
provides more time to collect multiple write requests and determine how to optimize storing
data across multiple disks in a RAID group. Because NVRAM is battery-backed, you don’t
have to worry about losing data.
The following are some key facts about WAFL:
• There is no fixed location for data except the superblock.
• Metadata is stored in files.
• Everything is a file.
• Always free to optimize layout.
By combining batch writes, the WAFL:

• Allows Data ONTAP to convert multiple small file writes into one sequential disk write
• Distributes data across all disks in a large array (meaning no overloaded disk drives, or hot spots)
Consistency Point: WAFL to RAID
The RAID layer calculates the parity of the

data:
– To protect it from one or more disk failures
– To protect stripes of data
If a data disk fails, the missing information can
be calculated from parity
The storage system can be configured as
either:
– RAID 4—Allows one disk failure in the RAID
group
– RAID-DP—Allows up to two disk failures in the
RAID group
CONSISTENCY POINT: WAFL TO RAID
RAID 4 AND RAID-DP PROTECTION

WAFL then hands off data to the RAID subsystem, which calculates parity and then passes
the data and parity to the storage layer, where the data is committed to the disks. RAID uses
parity to reconstruct broken disks. Parity scrubs, which proactively identify and solve
problems, are performed at the RAID level using checksum data.
Write Request Data Flow: RAID to Storage
Network
Stack NVLOG V
SAN NVLOG A
NVRAM Full
SAN Host NFS
HBA Service WAFL
CIFS
UNIX NIC Service
RAID
Client
4k
Storage
Windows
Client
WRITE REQUEST DATA FLOW: RAID TO STORAGE
RAID LAYER
Storage drivers move data between system memory and the storage adapters, and ultimately
to the disks. The disk driver component reassembles writes into larger I/Os and also monitors
which disks have failed. The SCSI driver creates the appropriate SCSI commands to sync
with the reads and writes it receives.
Consistency Point: RAID to Storage
Storage layer commits the data and parity to

the physical disks
Two atomic checksums are calculated to verify
that the data is written consistently on the disks
The root inode is updated to point to the new
file inodes on the disk
The NVRAM is flushed and made available
The consistency point now is complete
CONSISTENCY POINT: RAID TO STORAGE
Write Request Data Flow: Storage Writes
Network
Stack NVLOG V
SAN NVLOG A
NVRAM Full
SAN Host NFS
HBA Service WAFL
CIFS
UNIX NIC Service
RAID
Client
Storage
Windows
Client
WRITE REQUEST DATA FLOW: STORAGE WRITES
STORAGE LAYER
The storage layer transfers data to physical disks. After data is written to the disks, a new root
inode is updated, a CP is created, and the NVRAM bank is cleared.
NVRAM
Data ONTAP writes from system memory

– NVRAM is never used for normal write
operations
– NVRAM is backed up with a battery
If a system failure occurs before the
completion of a consistency point, the data is
written from NVRAM when the system is
brought back online (or by the partner machine
in an active-active environment)
NVRAM
The NVRAM is viewed as a log of write requests.

When a write request is received:
• The request is logged to NVRAM. During normal processing, NVRAM is not read. It is simply a
log of requests for action (including any necessary data such as the contents of a write request).
• The request is acted upon. The main memory of the storage system is used for processing requests.
Buffers are read from the network and from the disk, and then processed according to the
directions received as CIFS or NFS requests. If the same action needs to be repeated, NVRAM
holds the necessary instructions.
The NVRAM is normally cleared after a CP is created and is never read back. However, if the
storage system crashes, the data from NVRAM is processed as if the storage system was
receiving those same requests a second time. Because WAFL does not have an opportunity to
atomically update the file system when a crash occurs, the storage system responds to the
NVRAM request in the same way it would have if the request had been received again
through the network.
Read Requests
READ REQUESTS
Read Requests
Every time a read request is received, WAFL

does one of the following:
– Reads the data from the system memory, also
known as “cache”
– Reads the data from the disks
The cache is populated by:
– Data recently written to disk
– Data recently read from disk
READ REQUESTS
READ CACHE
Data ONTAP includes several built-in, read-ahead algorithms. These algorithms are based on
patterns of usage, which helps ensure the read-ahead cache is used efficiently.
FIVE STEPS IN A READ

The following process occurs when a read request is received:
1. The network layer receives an incoming read request (read requests are not logged to NVRAM).
2. If the requested data is located in cache, it is returned immediately to the requesting client.
3. If the requested data is not located in cache, WAFL initiates a read request from the disk.
4. Requested blocks and intelligently chosen read-ahead data is sent to cache.
5. The requested data is sent to the requesting client.
NOTE: In the read process, cache is used to refer to system memory.
Read Request Data Flow: Cache
Network
Stack NVLOG V
SAN NVLOG A
NVRAM Full
SAN Host NFS
HBA Service WAFL
CIFS
UNIX NIC Service
RAID
Client
Storage
Windows
Client
READ REQUEST DATA FLOW: CACHE
READ REQUESTS FROM CACHE

When a read request is received from a client, the WAFL determines whether to read data
from the disk or respond to the request using the cache buffers. The cache may include data
that was recently written to or read from the disk.
Read Request Data Flow: Read from Disk
Network
Stack NVLOG V
SAN NVLOG A
NVRAM Full
SAN Host NFS
HBA Service WAFL
CIFS
UNIX NIC Service
RAID
Client
Storage
Windows
Client
READ REQUEST DATA FLOW: READ FROM DISK
READ REQUEST FROM DISK

Read requests that can be satisfied from the read cache are retrieved from the disk. The read
cache is then updated with new disk information for subsequent read requests.
Module Summary

WAFL plans and manages storage
RAID protects data
The storage layer manages data transfer to
and from disk
MODULE SUMMARY
Exercise
Module 13: Write and Read Request
Processing
EXERCISE
Data Collection

MODULE 14: SYSTEM DATA COLLECTION
System Data
Collection
Module 14
SYSTEM DATA COLLECTION
14-1 Data ONTAP® 7.3 Fundamentals: System Data Collection
Module Objectives

Use the sysstat, stats, statit, and
options commands
Describe the factors that affect RAID
performance
Execute commands to collect data about write
throughput
Execute commands to verify the operation of
hardware, software, and network components
Identify commands and options used to obtain
configuration and status
MODULE OBJECTIVES
System Health
Performance problems can originate from

multiple sources. To avoid some of these
problems, check or monitor the following:
Disk configuration
– Disk status
– Write performance
– Read performance
RAID configuration
Connectivity configuration
Performance measures
SYSTEM HEALTH
CHECKING THE SYSTEM

Good performance results from hardware, software, and communication protocols working
together at optimal limits. The failure, or underperformance, of one element in the system can
negatively impact others. For this reason, it is important to monitor your system and use the
NetApp command tools available to adjust the system accordingly, which reduces latency,
improves data throughput, and achieves optimal performance.
Disk Status
DISK STATUS
Disk Status
Monitor disks:
– shelfchk
– led_on diskid and led_off diskid
Storage Health Monitor:
– Simple storage system management service
– Automatically initiates during system boot
– Provides background monitoring of individual
disk performance
– Detects impending disk problems before they
actually occur
– disk shm_stats
DISK STATUS
VERIFYING FC SHELF CONNECTIONS

To confirm proper connection between the storage appliance and the FC shelves, use the
shelfchk command. The shelfchk command verifies that the host adaptors on the storage
appliance are communicating with the disk shelves. The command prompts you to verify
whether specified LEDs are on or off. Because you must be able to see the LEDs, enter the
command from a nearby console.
CHECKING DISK LED FUNCTION

To verify that LEDs are working on all disks, run the led_on and led_off tests. To use
these commands, you must be operating in advanced mode.
NOTE: The led_on and led_off tests can also be used to identify the address where disks
are located.
To verify that LEDs are working on all disks, complete the following steps:
1. To set command privileges to advanced, enter priv set advanced.
2. To turn on LEDs on a specific disk, enter led_on [device_name].
3. Locate the disk on the shelf and verify that the LEDs are lit.
4. To turn off the device LEDs, enter led_off [device_name].
5. To return command privileges back to the basic administration mode, enter priv set admin.
STORAGE HEALTH MONITOR
The Storage Health Monitor (SHM) is a simple storage system management service that is
automatically initiated during system startup. It provides background monitoring of individual
disk performance.
Instead of detecting problems when a disk failure occurs, the SHM detects impending disk
problems before they occur, giving you the opportunity to replace the disk before any client
data problems occur.
SHM messages are written to two text files in the /etc directory and can then be reported
through SNMP, AutoSupport, and syslog, depending on what error metrics you specify.
The SHM provides three message levels:
• Urgent (current problem)
• Non-urgent (potential problem)
• Informational (general status information)
Syslog Messages
shm: disk has reported a predicted
failure (PFA) event: disk XX,
serial_number XXXX
shm: link failure detected, upstream
from disk: id XX, serial_number XXXXX
shm: disk I/O completion times too long:
disk XX, serial number XXXXX
shm: possible link errors on disk: id
XX, serial number XXXXX
shm: disk returns excessive recovered
errors: disk XX, serial number XXXXX
shm: intermittent instability on the
loop that is attached to Fibre Channel
adapter: id XXX, name XXXXX
SYSLOG MESSAGES
shm: disk has reported a predicted failure (PFA) event: disk XX,
serial_number XXXX
Description: The disk's internal error processing and logging algorithm computation
results are exceeding an internally set threshold. The disk will likely fail in a matter
of hours.
Category: Urgent
Action required: Replace the disk
shm: link failure detected, upstream from disk: id XX, serial_number
XXXXX
Description: An FC disk (or cable, if disks are in different disk shelves) might be
malfunctioning, causing an open loop condition. This results in a sync loss of more
than 100 milliseconds for a downstream disk that reported it as a link failure.
Category: Urgent
Action required: Shut down the storage appliance. Use disk scrub on each disk, and
replace the disks and cable one at a time to determine which component is
malfunctioning. Replace the malfunctioning disk or cable.
shm: disk I/O completion times too long: disk XX, serial number XXXXX
Description: Either the disk is old and slow, or it is internally recovering errors and
taking too long to complete an I/O. This message also indicates that there are too
many I/O timeouts and retries on a disk. The disk could also be frequently returning
the Command Aborted status. All these issues can produce a low data-throughput rate
for this specific disk and a reduction in overall system performance.
Category: Non-urgent
Action required: The disk is prone to failure and should be replaced.
shm: possible link errors on disk: id XX, serial number XXXXX
Description: One of a group of four FC disks in a disk shelf (or any connecting
cable) might be malfunctioning. This results in a large number of invalid CRC frames
and data under-runs on the loop. The invalid CRC and under-run count has crossed
the specified threshold several times.
Action required: Shut down the storage appliance and remove the disks and cables
one at a time to determine which component is malfunctioning. Replace the
malfunctioning disk or cable.
shm: disk returns excessive recovered errors: disk XX, serial number
XXXXX
Description: Either the disk has found media or hardware errors (unrecovered
errors), or it has internally recovered a large number of errors. The disk might also be
returning a Command Aborted status. The errors returned have exceeded the bit error
rate specified by the disk vendor.
Action required: The disk is failure prone; you should replace it.
shm: intermittent instability on the loop that is attached to Fibre
Channel adapter: id XXX, name XXXXX
Description: An FC adapter, attached disk shelf, disk, cable, or connector might have
caused instability on the FC-AL loop, which resulted in I/O completion rates below a
set threshold.
Category: Informational
Action required: None
Write Performance
WRITE PERFORMANCE
Write Performance Commands
Use the following commands to research write

performance:
Command Function
sysstat Displays current statistics
statit Displays disk utilization
stats Displays performance data
WRITE PERFORMANCE COMMANDS
COMMANDS FOR RESEARCHING WRITE PERFORMANCE

When planning a drive configuration that optimizes write performance, you must make
choices based on thorough knowledge of current system performance, user needs, and
resource constraints.
Write Performance: sysstat Command
system> sysstat -c 10 -s 5
CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache
in out read write read write age
2% 0 0 0 0 0 9 23 0 0 >60
0% 0 0 0 0 0 0 0 0 0 >60
5% 0 0 0 0 0 21 27 0 0 >60
1% 0 0 0 0 0 0 0 0 0 >60
5% 0 0 0 0 0 20 28 0 0 >60
1% 0 0 0 0 0 0 0 0 0 >60
4% 0 0 0 0 0 21 26 0 0 >60
1% 0 0 0 0 0 0 0 0 0 >60
5% 0 0 0 0 0 22 27 0 0 >60
0% 0 0 0 0 0 0 0 0 0 >60
--
Summary Statistics (10 samples 5.0 secs/sample)
CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache
in out read write read write age
Min
0% 0 0 0 0 0 0 0 0 0 >60
Avg
2% 0 0 0 0 0 9 13 0 0 >60
Max
5% 0 0 0 0 0 22 28 0 0 >60
system*>
WRITE PERFORMANCE: SYSSTAT COMMAND
USING THE SYSSTAT COMMAND TO CHECK CPU STATUS

The best command for viewing system utilization is sysstat [interval], where
interval is the incremental interval in seconds (the default is every 15 seconds). The
sysstat command is a little like a speedometer for your storage system, allowing you to
view real-time activity per second.
The statistics displayed by the sysstat command should help you answer questions such as:
• Is the system usage steady or does it fluctuate?
• Is the CPU percentage high without corresponding input/output activity?
INTERPRETING SYSSTAT RESULTS

The following is a description of sysstat command results:
• CPU—Displays an average of the busiest CPUs
NOTE: The sysstat –M command displays statistics for each CPU in a multiprocessor system.
• NFS—Number of NFS operations per second
• CIFS—Number of CIFS operations per second
• HTTP—Number of HTTP operations per second
• Net kB/s in and out—The kilobytes per second of data requested from the network as a read or
write
This is the network traffic displayed in kB/s, which tells you how much network traffic the storage
appliance is handling, how constant that traffic is, and if the system is exceeding its network traffic
limitations.
• Disk kB/s reads and writes—Shows disk activity
Disk reads occur if data is not cached. Disk writes should occur ideally every 10 seconds.
• Cache age—Displays the age, in minutes, of the oldest read-only blocks in the buffer cache (not
information relevant to diagnosing performance)
The stats Command:
System Performance
The stats command displays statistical data about
the storage system and is capable of displaying
statistics on every aspect of the storage system
Statistics returned using the stats command are
based on the following hierarchy:
– Objects—Any entity in the system is an object (physical
or logical, including volumes, aggregates, qtrees, disks,
and NICs)
– Instances—An object such as a volume called nfsflex,
or an aggregate called aggr1, or a disk identified as
0b.17
– Counters—The counters associated with particular
objects and instances
THE STATS COMMAND: SYSTEM PERFORMANCE
Data ONTAP has a layer built into its architecture that collects data from several of its
subsystems. The stats command provides access (through the CLI or scripts) to a set of
predefined data-collection tools in Data ONTAP known as counters. These counters provide
you with information about your storage system, either instantaneously or over a period of
time. You can use the stats command and other tools such as the Microsoft Windows utility
(perfmon) to gather statistics from this layer.
OBJECTS, INSTANCES, AND COUNTERS

The stats counters are grouped by the objects for which they provide data. These objects
include:
• Physical entities such as a system, processor or disk
• Logical entities such as a volume or aggregate
• Protocols such as iSCSI or FCP
• Other modules on the storage system
For a complete list of the stat objects, use the stats list objects command.
Each object can have zero or more instances on your storage system, depending on your
system configuration. Each object instance has its own name. For example, a system with two
processors has the instance names processor0 and processor1.
Counters have an associated privilege mode. If you are not operating with sufficient
privileges for specific counters, the counters are not recognized as valid.
The stats Command:
Examples of Objects and Instances
Examples of objects:
– aggregate
– Volume
– Qtree
– Disk
– Cifs
– Nfs
– LUN
Examples of instances:
– /vol/vol0, /vol/nfstree, 0b.18
– /vol/flex1/lun_test
– cifs_ops, cifs_latency, cifs_read_ops
THE STATS COMMAND: EXAMPLES OF OBJECTS AND INSTANCES
Use the stats command list and show options to view current objects and instances. The
following are some examples of stat commands for objects and instances:
stats list objects
Displays the names of objects active in the system for which data is available.
stats list instances
Displays the list of active instance names for a specific object.
stats list counters | [ object_name ]
Displays a list of all counters associated with an object.
stats explain counters [ object_name [ counter_name ] ]
Displays an explanation for specific counter(s) in a specific object, or all counters in
all objects if no object_name or counter_name is provided.
stats show
Shows all or selected statistics in various formats.
For more information about the stats command, see your manual.
The stats Command (Cont.)
The stats command can be executed in one of

three ways, based on the frequency of displays:
Once—Current counter values are displayed
stats show
Repeating—Counter values are displayed at a
fixed interval
stats show –i 1
Period—Counter values are gathered over a
single period of time and then displayed
stats start then stats stop
THE STATS COMMAND (CONT.)
VIEWING CURRENT COUNTER VALUES

To view information about the system state from the CLI, use the stats show command in
singleton mode.
The following table shows some examples of using the stats show command to view
system state information.
To view Use command
Statistics from all counters for all instances of a > stats show system
specified object (in this case, system)
Statistics from all counters for all instances of a > stats show processor:processor0
specified object (in this case, processor0)
All current statistics for the volume vol0 > stats show volume:vol0
For more information about counters, see Chapter 8 of the Performance Advisor
Administration Guide.
GATHERING COUNTER VALUES OVER A PERIOD OF TIME
In addition to using the stat command to view the current system state, you can also use it
to gather system information for a single period of time.
The following table shows some examples of using the stats command to gather counter
values over a period of time.
Description Command
Start collecting system information > stats start –I
processor:processor0
Display interim results without stopping the > stats show –I processor:processor0
background stats command
Stop collecting system information and output the > stats stop -I processor:processor0
final results
The stats Command (Cont.)
Use stats list counters to see what is available
The statistics available through the stats
infrastructure are available using other tools such as
perfmom, perfstat and Operations Manager
The following are examples of stats commands:
system> stats show cifs:cifs:cifs_latency
cifs:cifs:cifs_latency:1.92m
system> stats show volume:vol0:write_latency

volume:vol0:write_latency:171.50us
THE STATS COMMAND (CONT.)
STATS LIST COMMANDS
The following are some examples of stats list commands:
stats list counters

Displays the list of all counters associated with an object. If -p is specified, the
counters used by the preset are listed. If neither -p nor object_name is specified,
then all counters for all objects are listed.
stats list objects
Displays the names of objects active in the system for which data is available. If -p is
specified, the objects used by the preset are listed.
stats list instances
Displays the list of active instance names for a particular object. If -p is specified, the
instances used by the preset are listed. If neither -p nor object_name is specified,
then all instances for all objects are listed.
Client-Side Tools: Windows Command
The Windows perfmon
utility:
Connects to the
storage system from
Windows
Requires CIFS to be
licensed and running
on the storage system
Receives output from
the stats command
and graphs the data
NOTE: To view the Add

Counters screen, in the
Performance window, click
the plus sign (+).
CLIENT-SIDE TOOLS: WINDOWS COMMAND
The perfmon performance monitoring tool is integrated into the Microsoft Windows
operating system. If you use storage systems in a Windows environment, you can use
perfmon to access many of the counters and objects available through the Data ONTAP
stats command.
USING PERFMON TO ACCESS SYSTEM PERFORMANCE STATISTICS

To use perfmon to access storage system performance statistics, you must specify the name
or IP address of the storage system as the counter source. The lists of performance objects and
counters reflect the objects and counters available from Data ONTAP.
NOTE: The default sample rate for perfmon is once per second. Depending on which
counters you choose to monitor, that sample rate could cause a small performance
degradation on the storage system. If you want to use perfmon to monitor storage system
performance, we recommend that you change the sample rate to once per 10 seconds. You
can change the sample rate using the System Monitor Properties.
Read Performance
READ PERFORMANCE
Read Performance
Data ONTAP is optimized for write

performance
Read performance could decrease over time
NOTE: Efficient use of cache can offset some disk performance
issues.
Optimization:
– To measure optimization:
reallocate measure [vol | file]
– To resolve optimization:
reallocate start <pathname>
READ PERFORMANCE
The WAFL is optimized for write performance. To enhance performance, WAFL does the
following:
• Writes adjacent blocks in files that are adjacent on the disk (whenever possible). As the file system
grows, blocks may not be written on an immediately adjacent disk, but the blocks will still be
close together.
• Reserves 10% of the disk space to increase the probability of blocks being available at or near
optimal locations.
• Handles interleaved writes much better than other file systems because WAFL does not
immediately write-allocate data. By holding the write data in system memory until a CP is
generated, WAFL can write-allocate a lot of data from a particular file into contiguous blocks.
• Minimizes the impact of write performance with the “write anywhere" allocation scheme, which
minimizes disk-seeks for writes.
The write optimizations can lead to decreased file and LUN read performance as the file
system ages because files are written to the best place on the disks for write performance. As
the file system expands and WAFL has fewer options for writing blocks, it may have to write
blocks that are not immediately adjacent on the disk. Using flexible volumes and the
autosize volume option can help prevent problems. In addition, WAFL uses built-in,
multiple-read cache algorithms to offset any potential performance degradation.
RAID Configuration
RAID CONFIGURATION
RAID Groups
/vol0 /vol1 /vol2
rg0 rg0 rg0
rg1
RAID GROUPS
RELATIONSHIP BETWEEN VOLUMES AND RAID GROUPS

• Each aggregate has at least one RAID group, and each RAID group belongs to only one aggregate.
• When a new aggregate is created, a new RAID group is also created with two parity disks and at
least one data disk.
• When disks are added that exceed the specified or maximum RAID group size, new RAID groups
are automatically created for an aggregate.
• You can increase or decrease RAID group size using the aggr options aggr_name
raidsize option.
RAID Group Size and Composition
The following are some examples of poor RAID

configuration choices:
Unnecessarily using multiple RAID groups
Using mixed disk sizes
Configuring RAID groups with wide variations
in capacity
Configuring RAID groups with only one or two
data disks
Configuring RAID groups with a number of
disks larger than the default
RAID GROUP SIZE AND COMPOSITION
DETERMINING RAID GROUP SIZE AND COMPOSITION

When initially configuring the storage system, it is important to properly size the number of
drives and RAID groups. While write performance can benefit from more drives, any change
might be masked by the effect of NVRAM and the efficient manner in which WAFL manages
write operations. Configuring multiple RAID groups in a volume should not impact
performance. However, improper configuration can significantly impact performance.
For best results when configuring RAID, use the default RAID group and then follow the
guidelines in the Technical Report 3437, Storage Best Practices and Resiliency Guide at
http://www.netapp.com/us/library/technical-reports/tr-3437.html.
Initial RAID Group Configuration
Limit the number of disks in a RAID group to

the recommended numbers
Ensure that each RAID group in an aggregate
has approximately the same capacity
Ensure that each RAID group in an aggregate
has at least three data disks
Use disks of the same size within a RAID
group to optimize write performance
Use RAID-DP to protect against disk failures
INITIAL RAID GROUP CONFIGURATION
Adding Disks to Existing RAID Groups
Add RAID groups when the applied load is

stressing the drives in the current array
Add RAID groups and disks before the file
system or aggregate is 80% to 90% full
Add disks in groups
Plan data expansion so that no fewer than
three data disks are used for any RAID group
ADDING DISKS TO EXISTING RAID GROUPS
RECOMMENDATIONS FOR ADDING DISKS TO EXISTING RAID GROUPS
RAID GROUP SIZES

The maximum RAID group size is 28 (26 data disks and two parity disks when using RAID-
DP). When creating an aggregate, if you do not specify a RAID group size, the system uses
the default.
CONSIDERATIONS FOR SIZING RAID GROUPS

Configuring an optimum RAID group size for an aggregate requires some trade-offs. You
must decide what is the most important feature of the aggregate you are configuring—speed
of recovery, assurance against data loss, or maximization of data storage space.
In most cases, the default RAID group size is the best size for your RAID groups. However,
you can change the maximum size of those groups.
Monitoring
Connectivity
MONITORING CONNECTIVITY
Connectivity
Use the following to monitor connectivity:
MAC
– ifconfig
– ifstat
– arp
TCP/IP
– /etc/rc and /etc/hosts
– ping
– netstat -r
Protocols
– nfsstat
– cifs stat
– nbtstat
CONNECTIVITY
MONITORING CONNECTIVITY ISSUES AT THE MAC LEVEL

Connectivity problems can arise with functions at the MAC, TCP/IP, and protocol layers. At
the MAC level, you can use the commands in the following table to view various connectivity
statistics and settings.
Sample Command Result
ifstat –a Displays status information for all interfaces. To view status information about
ifstat ns1 a specific interface, enter ifstat [interface_name]for each interface
(ifstat ns1).
If the numbers for collisions, CRCs, or runt frames are high, this could indicate
a problem with the media type or card.
arp Displays the contents of the address resolution table (hostname/IPaddress) so it
can be modified. This command can also help to identify duplicate MAC
addresses.
arp –a Displays all current contents of the table.
arp -d Deletes or flushes a bad MAC address from the ARP table.
arp –s Adds a new entry.
Performance Measures
PERFORMANCE MEASURES
Measuring NFS Performance
options nfs.per_client_stats.enable [on|off]
Recommended to disable when not using nfsstat –l
This display shows The output includes server name and address, mount
the breakdown on flags, current read and write sizes, retransmissions count,
this mountpoint of and timers used for dynamic retransmission.
lookups, reads,
writes, and all
operations. The
Data ONTAP NFS Output - Command: nfsstat -l
average deviation /n/homesystem from homesystem.corp.com:/home
and the settings for Flags:vers=2,proto=udp,auth=unix,hard,intr,dynamic
retransmissions of ,rsize=8192
each type also are wsize=8192,retrans=5
displayed.
Lookups: sttr=7(17ms), dev=4(20ms),
cur=2(40ms)
Round trip response Reads: sttr=12(30ms), dev=4(20ms),
times for specific cur=3(40ms)
NFS operations are Writes: sttr=21(52ms), dev=5(25ms),
displayed. cur=5(100ms)
All: sttr=7(7ms), dev=4(20ms),
cur=2(40ms)
MEASURING NFS PERFORMANCE
You can track the performance of each NFS server by routinely collecting statistics in the
background across all subnets. One of the most important ways to measure performance is to
capture response times for each NFS operation such as writes, reads, lookups, and get
attributes, so the data can be analyzed by the server and the file system.
You can obtain statistics for NFS operations by server (where the storage system is the NFS
server) by enabling the per-client stats option and running nfsstat -l. Once you
establish site-specific baseline measurements, you can compare your system’s performance
against optimum benchmark configurations, or against its own performance at different times.
Any changes from the baseline can indicate problems that require further analysis.
To measure NFS performance, use the sysstat and nfsstat commands.
• To display real-time NFS operations every second on your console, enter sysstat 1, or you
can view the output using FilerView.
• To focus the output on counters related to response times on Solaris NFS clients, run nfsstat -
m.
• To reset statistics and counters to zero, use nfsstat -z.
Measuring CIFS Performance
This number is the total number of This column represents

operations since smb_hist millisecond (ms) time stamps
statistics were last reset. for operations.
Analyzing smb_hist output

CIFS request time processing: (46457) - milliseconds units
0ms 1ms 2ms 3ms 4ms 5ms 6ms 7ms
13175 17752 5111 664 451 478 570 568
<16ms <24ms <32ms <40ms <48ms <56ms <64ms unused
4039 2309 569 165 61 21 10 0
Every other row displays the number of The time interval window lies halfway between
operations that took place in the interval in the values for adjacent columns. In this
the row above it. In this example, 13,715 example, 165 operations occurred in the 36-ms
operations happened in less than .5 ms. to 44-ms windows.
MEASURING CIFS PERFORMANCE
To measure CIFS performance, you can use the sysstat and smb_hist commands.
To display CIFS operations per second on the console, enter the sysstat 1 command, or
use FilerView.
To view CIFS throughput statistics, complete the following steps:
Click the CLI window to step through the process.
1. Set the command privileges to advanced.
2. To zero the counters, enter smb_hist –z.
3. Wait long enough to get a good sample.
4. To view CIFS statistics generated since the reset, enter smb_hist.
5. Review first section of output.
In the example in the figure above, the first part of the smb_hist output shows there were
13,175 operations that occurred in less than .5 milliseconds (ms), 17,752 operations that
occurred in the window between 0.5 ms and 1.5 ms, and 5,111 operations that occurred in the
window between 1.5 ms and 2.5 ms, and so on. In normal situations, as the interval window
gets larger, the number of operations that take that long decreases to zero.
Obtaining Statistics
The statit command:

Is an advanced-mode command used for more
detailed analysis of system performance
Gathers per-second statistics averaged over
the length of time it is running in the
background
Shows statistics representing all physical and
some logical objects on the storage system
Most of the data collected represents rates at
which things are happening
OBTAINING STATISTICS
Using the statit Command
to Obtain Statistics
To obtain statistics using the statit command,
complete the following steps:
1. To enter advanced privilege mode, enter:
priv set advanced
2. To begin collecting statistics, enter:
statit –b.
3. After 30 seconds (or as necessary to end statistics
collection and include NFS statistics), enter:
statit –e –n
4. To return to normal admin privilege mode, enter:
priv set admin
USING THE STATIT COMMAND TO OBTAIN STATISTICS
To run the statit command from a client with an rsh issue:

rsh storage_system “priv set advanced; statit –b”
Wait 30 to 60 seconds for statistics to be collected. The statit command runtime is
determined by many factors based on what events need to be captured. If you are establishing
a baseline, then 30 seconds might be enough. If you are running a benchmark test that takes
five minutes, then you should run the statit command for at least five minutes. The
statit command averages results over the time period that it runs. Therefore, if you run the
statit command for a longer period of time, it will “smooth out” the statistics collected.
After collecting statistics for a period of time, enter the command:
rsh storage_system -; root:passwd “priv set advanced; statit –e”
Analyze the results.
Obtaining Statistics
The report generated is divided into the following
statistics sections:
CPU
Multiprocessor
CSMP domain switches
Miscellaneous
WAFL
RAID
Network interface
Disk
Aggregate
Spares and other disks
FCP
iSCSI
Tape
OBTAINING STATISTICS
CPU Statistics
CPU Statistics
506.934263 time (seconds) 100 %
275.044317 system time 54 %
23.412966 rupt time 5 % (7022 rupts x 0 usec/rupt
251.466451 non-rupt system time 50 %
271.837944 idle time 44 %
439.543653 time in CP 92 % 100 %
21.837230 rupt time in CP 5 % (132 rupts x 0 sec/rupt)
CPU STATISTICS
The first section of the statistics report provides CPU statistics.
In the example in the figure above:

275.044317 system time 54 %:
Shows the percentage of time the CPUs were busy.
23.412966 rupt time 5 % (7022 rupts x 0 usec/rupt):
Shows the number of interrupts received when the CPU ran at interrupt level.
271.837944 idle time 44 %:
Shows the percentage of time the CPUs executed the idle loop.
439.543653 time in CP 92 % 100 %:
Shows the percentage of time the system was in a consistency point, flushing data to
disk.
Multiprocessor Statistics
Multiprocessor Statistics (per second)
cpu0 cpu1 total
sk switches 1378.09 46.82 1424.91
hard switches 1175.27 29.15 1204.42
domain switches 103.89 16.08 119.96
CP rupts 0.00 0.00 0.00
nonCP rupts 100.00 0.00 100.00
nonCP rupt usec 0.00 0.00 0.00
Idle 1000000.00 1000000.00 2000000.00
kahuna 0.00 0.00 0.00
network 0.00 0.00 0.00
storage 0.00 0.00 0.00
exempt 0.00 0.00 0.00
raid 0.00 0.00 0.00
target 0.00 0.00 0.00
netcache 0.00 0.00 0.00
netcache2 0.00 0.00 0.00
MULTIPROCESSOR STATISTICS
The second section of the report includes multiprocessor statistics for multiple CPUs.
Miscellaneous Statistics
Miscellaneous Statistics (per second)

1893.73 hard context switches
0.00 NFS operations
0.00 CIFS operations
0.00 HTTP operations
0.00 NetCache URLs
0.00 streaming packets
0.00 network KB received
0.00 network KB transmitted
18.16 disk KB read
61.30 disk KB written
0.28 NVRAM KB written
0.00 nolog KB written
0.00 WAFL® bufs given to clients
0.00 checksum cache hits ( 0%)
0.00 no checksum - partial buffer
0.00 DAFS operations
0.00 FCP operations
0.00 iSCSI operations
MISCELLANEOUS STATISTICS
The miscellaneous section of the statistics report includes rates (or counts) for many
operations. The statistics from this section most commonly viewed are:
• NFS, CIFS, and HTTP operations
• Network KB transmitted and received
• Disk KB read and written
• FCP and iSCSI operations
WAFL Rates
WAFL Statistics (per second) 0.00 blocks over-written
5.96 name cache hits ( 62%) 0.28 wafl_timer generated CP
3.69 name cache misses ( 38%) 0.00 snapshot generated CP
19.30 inode cache hits ( 100%) 0.00 wafl_avail_bufs generated CP
0.00 inode cache misses ( 0%) 0.00 dirty_blk_cnt generated CP
55.06 buf cache hits ( 100%) 0.00 full NV-log generated CP
0.00 buf cache misses ( 0%) 0.00 back-to-back CP
0.00 blocks read 0.00 flush generated CP
0.00 blocks read-ahead 0.00 sync generated CP
0.00 chains read-ahead 0.00 wafl_avail_vbufs generated CP
0.00 blocks speculative read-ahead 55.06 non-restart messages
5.11 blocks written 0.00 IOWAIT suspends
0.57 stripes written 604852 buffers
WAFL RATES
The WAFL section of the statistics report displays WAFL rates (or counts). The statistics
from this section most commonly viewed are:
• All cache hits and misses
• Inode cache hits and misses
• Per second rates for all the CP types
All cache hits and misses and inode cache hits and misses provide information about read
performance. Generally, it is considered good to have more hits than misses. However, there
are many factors to consider when analyzing these numbers, such as the fact that a file that is
only read once does not reside in cache. This would be true for most backup applications.
Network Interface Statistics
Network Interface Statistics (per second)

iface side bytes packets multicasts errors collisions
e0 recv 171.69 2.55 0.00 0.00 0.00
xmit 115.22 1.42 0.00 0.00 0.00
e9 recv 0.00 0.00 0.00 0.00 0.00
xmit 0.00 0.00 0.00 0.00 0.00
e6 recv 0.00 0.00 0.00 0.00 0.00
xmit 0.00 0.00 0.00 0.00 0.00
vh recv 0.00 0.00 0.00 0.00 0.00
xmit 0.00 0.00 0.00 0.00 0.00
NETWORK INTERFACE STATISTICS
The Network Interface section of the statistics report provides network interface statistics,
including rates for:
• Packets and bytes transmitted and received
• Transmit and receive errors
• Collisions
Disk Statistics
Disk Statistics (per second)
ut% is the percent of time the disk was busy.
xfers is the number of data transfer commands issued per second.
xfers = ureads + writes + cpreads + greads + gwrites
chain is the average number of 4K blocks per command.

usecs is the average disk round trip time per 4K block.
disk ut% xfers ureads--chain-usecs writes--chain-usecs cpreads-chain-usecs
/vol0/plex0/rg0:
8a.16 5 3.69 0.57 1.00 94500 ...
8a.21 4 3.12 0.57 1.00 39500 ...
DISK STATISTICS
The Disk section of the statistics report provides statistics for each drive. Some of the column
headings are defined at the top of the screen.
Beginning with the fourth column of data, the report uses hyphens in the column headings to
group related information. For example, user reads and the associated chain and round-trip
times are linked in the heading ureads--chain—usecs.
The following list defines some of the column headings on the Disk statistics report:
• disk—Indicates which drives are included in the statistics.
• ut%—Shows the drive utilization averaged per second, as in the percent of elapsed time that the
driver had a request outstanding.
Utilization rates of more than 80% might suggest an I/O bottleneck.
• xfers—Shows the total number of transfers, or reads and writes averaged per second. Most
drives are capable of 50 to 100 input operations per second (IOPS).
Aggregate, Spares, and Disk Statistics
Aggregate statistics:
Minimum 0 0.00 0.00 0.00 0.00 0.00 0.00
Mean 1 0.28 0.00 0.28 0.00 0.00 0.00
Maximum 5 3.69 0.57 3.12 0.00 0.00 0.00
Spares and other disks:

8b.16 2 1.70 1.70 1.00 10167 0.00 .... . 0.00 .... . 0.00 .... . 0.00 ..
8b.17 0 0.00 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... .
8b.18 0 0.00 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... . 0.00 .... .
AGGREGATE, SPARES, AND DISK STATISTICS
This section of the report displays aggregate, spares, and other disk statistics.
FCP, iSCSI, and Tape Operations
FCP Statistics (per second)

0.00 FCP Bytes recv 0.00 FCP Bytes sent
0.00 FCP ops
iSCSI Statistics (per second)

0.00 iSCSI Bytes recv 0.00 iSCSI Bytes xmit
0.00 iSCSI ops
Interrupt Statistics (per second)

2000.15 Clock 3.97 Fast Enet
47.68 FCAL 4.54 int_22
3.41 FCAL 2059.75 total
FCP, ISCSI, AND TAPE OPERATIONS
The last three sections of the report display statistics for FCP, iSCSI, and tape operations.
Other Resources: Data Collection and
Performance
For more information about data collection and performance, see the
Fundamentals of Performance Analysis course.
This advanced course shows you how to:
Analyze data using recommended methodology to correlate
performance data into performance analysis information
Monitor performance using performance tools and establish a
baseline of expected throughput and response times for storage
systems under planned and increasing workloads
Perform capacity planning by monitoring performance and
comparing baseline information over time to determine when a
storage system will reach maximum capacity
Perform tuning for optimal performance for protocols such as
CIFS, NFS and SAN (including locating resources with tuning
guidelines for database scenarios)
Perform bottleneck analysis
OTHER RESOURCES: DATA COLLECTION AND PERFORMANCE
Module Summary

sysstat provides storage system statistics
statit provides low-level statistics on the
storage system averaged over the length of
time that the command runs
stats provides many statistics
To gauge system performance:
– Check disk configuration
– Monitor connectivity
– Check storage system configuration
MODULE SUMMARY
Exercise
Module 14: System Data Collection
EXERCISE
FlexShare

MODULE 15: FLEXSHARE
FlexShare
Module 15
FLEXSHARE
15-1 Data ONTAP® 7.3 Fundamentals: FlexShare
Module Objectives

Describe and use FlexShare to tune and
improve performance
Monitor FlexShare performance changes
Describe specific cases that could benefit from
quality of service (QOS) improvements using
FlexShare
MODULE OBJECTIVES
FlexShare
FlexShare facilitates increased storage resource

control in the following ways:
Volume priorities
Hints of cache buffers
No license required
FLEXSHARE
FlexShare is a tool provided by Data ONTAP that enables you to use priorities and hints to
increase your control over how your storage system resources are used based on the
following:
• Priorities are assigned to volumes to assign relative priorities between the following:
• Different volumes
For example, you could specify that operations on /vol/db are more important than
operations on /vol1/test.
• Client data accesses and system operations
For example, you could specify that client accesses are more important than SnapMirror
operations.
• Hints are used to affect the way cache buffers are handled for a particular volume
FlexShare Application Scenarios
Scenario 1―A mission-critical database is on the
– same storage system as user home directories
– Use FlexShare to ensure that database accesses
are assigned a higher priority than accesses to
home directories
Scenario 2―System operations are negatively
impacting client accesses
– Use FlexShare to ensure that client accesses are
assigned a higher priority than system operations
Scenario 3―Volumes have different caching
requirements
– A database log volume that does not need to be
– cached after writing
– Use the cache buffer policy hint to help Data
ONTAP determine how to manage the cache buffers
for volumes with different caching requirements
FLEXSHARE APPLICATION SCENARIOS
WHEN TO USE FLEXSHARE

If your storage system consistently provides the performance required for your environment,
then you do not need FlexShare. If, however, your storage system sometimes does not deliver
sufficient performance to some of its users, you can use FlexShare to increase your control
over storage system resources and ensure that those resources are being used most effectively
for your environment.
The following sample scenarios describe how FlexShare can be used to set priorities for the
use of system resources:
• You have different applications on the same storage system. For example, if you have a
mission-critical database on the same storage system as user home directories, you can use
FlexShare to ensure that database accesses are assigned a higher priority than accesses to home
directories.
• You want to reduce the impact of system operations such as SnapMirror on client data
accesses. You can use FlexShare to ensure that client accesses are assigned a higher priority than
system operations.
• You have volumes with different caching requirements. For example, if you have a database
log volume that does not need to be cached after writing, or a heavily accessed volume that must
remain cached as much as possible, you can use the cache buffer policy hint to help Data ONTAP
determine how to manage the cache buffers for those volumes.
FlexShare Characteristics
No performance guarantees
Priority levels are relative
Both nodes in an active-active configuration
Must have the priority feature enabled
FLEXSHARE CHARACTERISTICS
NO PERFORMANCE GUARANTEES
FlexShare enables you to construct a priority policy that helps Data ONTAP manage system
resources optimally for your application environment, but does not guarantee performance.
PRIORITY LEVELS ARE RELATIVE

When you set a priority level on a volume or operation, you are not giving that volume or
operation an absolute priority level. Instead, you are providing a hint to Data ONTAP about
how to set priorities for accesses to that volume (or operations of that type) relative to other
accesses or operations. For example, if you set the priority level on each of your volumes to
the highest level, it will not improve the performance of your system. In fact, doing so would
not produce any change in performance.
USING FLEXSHARE IN AN ACTIVE-ACTIVE CONFIGURATION

If you use FlexShare in active-active configuration storage systems, you must ensure that
FlexShare is enabled or disabled on both nodes. Otherwise, a takeover could cause
unexpected results.
After a takeover occurs, the FlexShare priorities you set for volumes on the node that was
taken over are still operational, and the takeover node creates a new priority policy by
merging the policies configured on each individual node. For this reason, make sure that the
priorities you configure on each node work well together.
Effects of Volume Operations on FlexShare
Priorities
Volume Operation Effect on FlexShare Settings
Deletion FlexShare settings removed
Rename FlexShare settings unchanged
FlexClone Volume Creation Parent volume settings unchanged
FlexShare settings for new FlexClone
volume unset (as for a newly created
volume)
Copy Source volume settings unchanged
FlexShare settings for destination
volume unset (as for a newly created
volume)
Offline or Online FlexShare settings preserved
EFFECTS OF VOLUME OPERATIONS ON FLEXSHARE PRIORITIES
Global I/O Concurrency Option
FlexShare limits concurrent I/O based on the

following criteria:
– Volume priority
– Disk type
The default for most applications is the correct
value
Change concurrent I/O for nonstandard disks
or loads
GLOBAL I/O CONCURRENCY OPTION
Disks have a maximum number of concurrent I/O operations they can support, which varies
according to disk type. FlexShare limits the number of concurrent I/O operations per volume
based on multiple values, including volume priority and disk type.
For most customers, the default io_concurrency value is correct and should not be
changed. If you have nonstandard disks or loads, your system performance could be improved
by changing the value of the io_concurrency option.
NOTE: Because the io_concurrency option effects the entire system, use caution when
changing its value, and monitor system performance to ensure that this option actually does
improve performance.
For more information about FlexShare, see the na_priority(1) man page or the NOW site at
http://now.netapp.com/NOW.
Assigning Priorities to Volume Data
Access
To assign priorities to volume data access:
1. Ensure that FlexShare is enabled:
priority on
2. Specify the priority for a volume:
priority set volume vol_name
level=priority_level
3. (Optional) Verify the priority level:
priority show volume [-v] vol_name
ASSIGNING PRIORITIES TO VOLUME DATA ACCESS
USING FLEXSHARE TO ASSIGN VOLUME DATA ACCESS PRIORITIES
ASSIGNING PRIORITY TO A VOLUME RELATIVE TO OTHER VOLUMES

You can use FlexShare to assign a relative priority to a volume, which causes accesses to that
volume to be assigned a priority that is higher or lower than that of other volumes on the
storage system.
NOTE: For best results, when you set the priority for any one volume, set the priority for all
volumes on the system.
To assign a priority to a volume relative to other volumes, complete the following steps:
1. Ensure that FlexShare is enabled for your storage system by entering the following command:
priority on
2. Specify the priority for the volume by entering the following command:
priority set volume vol_name level=priority_level
where vol_name is the name of the volume for which you want to set the priority, and
priority_level is one of the following values: VeryHigh, High, Medium, Low, and
VeryLow.
Example: The following command sets the priority level for the dbvol volume as high as
possible. This causes accesses to the dbvol volume to receive higher priority than accesses to
volumes with a lower priority.
system> priority set volume dbvol level=VeryHigh
3. You can optionally verify the priority level of the volume by entering the following command:
Assign Priorities to System and User
Operations
To assign priorities to system and user
operations:
1. Ensure that FlexShare is enabled:
priority on
2. Specify the priority:
priority set volume vol_name system
3. (Optional) Verify the volume priority levels:
priority show volume -v vol_name
ASSIGN PRIORITIES TO SYSTEM AND USER OPERATIONS
ASSIGNING PRIORITY TO SYSTEM OPERATIONS RELATIVE TO USER OPERATIONS

If system operations (for example, SnapMirror transfers or backup operations) are negatively
affecting user accesses to the storage system, you can use FlexShare to assign a priority to
system operations that is lower than user operations for any volume.
NOTE: Synchronous SnapMirror updates are not considered system operations because they
are performed from NVRAM when the primary operation is initiated.This means that
synchronous SnapMirror updates are affected by the target volume priority, but not the
relative priority of system operations for that volume.
PROCEDURE
To assign a priority to system operations relative to user operations for a specific volume,
complete the following steps:
1. Ensure that FlexShare is enabled for your storage system by entering the following
command:
priority on
2. Specify the priority for system operations for the volume by entering the following
command:
priority set volume vol_name system=priority_level
where vol_name is the name of the volume for which you want to set the priority of
system operations, and priority_level is one of the following values: VeryHigh,
High, Medium, Low, Very Low, or a number from 1 to 100.
The number indicates the priority of system operations. When both user and system
operations are requested, the system operations will be selected over the user operations
[1-100] percent of the time, and the other percentage user operations will be selected.
NOTE: Setting the priority of system operations to 30 does not mean that 30 percent of
storage system resources are devoted to system operations. Rather, when both user and
system operations are requested, the system operations will be selected over the user
operations 30 percent of the time, and the other 70 percent of the time the user operation
is selected.
3. You can optionally verify the priority levels of the volume by entering the following
command:
Buffer Cache Policy
Settings:
– Keep
– Reuse
– Default
Setting policy:
– Priority on
– Priority set volume vol_name
cache=policy
BUFFER CACHE POLICY
You can use FlexShare to give Data ONTAP a hint about how to manage the buffer cache of
a volume.
NOTE: While this capability provides direction in the form of a hint to Data ONTAP,
ultimately Data ONTAP determines how a buffer is reused based on multiple factors,
including the hint.
The following table lists possible values for the buffer cache policy:
Value Description
keep This value instructs Data ONTAP to wait as long as possible before reusing the cache
buffers. This value can improve performance for a volume that is accessed frequently and
has a high incidence of multiple accesses to the same cache buffers.
reuse This value instructs Data ONTAP to make buffers for this volume available for reuse
quickly. You can use this value for volumes that are written but rarely read, such as database
log volumes, or volumes that have a data set so large that keeping the cache buffers probably
won’t increase the hit rate.
default This value instructs Data ONTAP to use the default system cache buffer policy for this
volume.
SETTING THE VOLUME BUFFER CACHE POLICY
You can use FlexShare to influence how Data ONTAP determines when to reuse buffers. To
set the buffer cache policy for a specific volume, complete the following steps.
1. If you haven’t already done so, ensure that FlexShare is enabled for your storage system
by entering the following command:
priority on
2. Specify the cache buffer policy for the volume by entering the following command:
priority set volume vol_name cache=policy
Example: The following command sets the cache buffer policy for the testvol1 volume
to keep, which instructs Data ONTAP not to reuse buffers for this volume when
possible.
priority set volume testvol1 cache=keep
3. You can optionally verify priority levels of the volume by entering the following
command:
Removing or Disabling FlexShare Policies
To temporarily disable FlexShare priority:

system> priority set volume [volname]
service=off
To remove FlexShare priority:
system> priority delete volume
[volname]
REMOVING OR DISABLING FLEXSHARE POLICIES
REMOVING A FLEXSHARE PRIORITY FROM A VOLUME

You can temporarily disable a FlexShare priority for a particular volume, or you can remove
the priority completely.
TEMPORARILY DISABLING A FLEXSHARE PRIORITY

To temporarily disable a FlexShare priority for a specific volume, you can set the service
option for that volume to off, which puts the volume back into the default queue.
Example: The following command temporarily disables a FlexShare priority for the
testvol1 volume:
system> priority set volume testvol1 service=off
REMOVING A FLEXSHARE PRIORITY

To completely remove FlexShare priority settings from a specific volume, you can use the
priority delete command, which puts the volume back into the default queue.
Example: The following command completely removes FlexShare priority settings for the
testvol1 volume:
system> priority delete volume testvol1
Default Volume Priority
To specify or modify the default volume priority:

priority set default option=value
[option=value]
DEFAULT VOLUME PRIORITY
MODIFYING THE DEFAULT PRIORITY

If you have not assigned a priority to a volume, then that volume is assigned the default
priority for your storage system. The default value is Medium.
NOTE: The default priority is also used for all aggregate operations. Changing the default
priority to VeryHigh or VeryLow could have unintended consequences.
To change the default volume priority, enter the following command:
priority set default option=value [option=value]
where option is either a level or a system, and the possible values for these options are
the same as for assigning priorities for a specific volume.
Example: The following command sets the default priority level for volumes to Medium,
while setting the default system operations priority to Low.
priority set default level=Medium system=Low
Module Summary

Describe and use FlexShare to tune and
improve performance
Monitor FlexShare performance changes
Describe specific cases that could benefit from
quality of service (QOS) using FlexShare
MODULE SUMMARY
Exercise
Module 15: FlexShare
EXERCISE
NDMP

MODULE 16: NDMP FUNDAMENTALS
NDMP
Fundamentals
Module 16
NDMP FUNDAMENTALS
16-1 Data ONTAP® 7.3 Fundamentals: NDMP Fundamentals
Module Objectives

Describe Network Data Management Protocol
(NDMP) concepts and models
Enable and configure NDMP on storage
systems
Describe NDMP dump and restore phases
Display and analyze NDMP events logs
Understand and optimize NDMP performance
Use ndmpcopy to process full and incremental
backups
Find additional NDMP tools and information
MODULE OBJECTIVES
INTRODUCTION
This module describes how to use Network Data Management Protocol (NDMP) services on
your storage system to enable network-based backup and recovery using NDMP-enabled
commercial backup applications. It also explains how to monitor NDMP services running on
the storage system and to use ndmpcopy to migrate data efficiently within or between storage
systems.
NDMP Overview
NDMP OVERVIEW
NDMP Overview
NDMP is an open standard that allows backup

applications to control native backup and
recovery functions on NetApp storage systems
and other NDMP servers.
NDMP-compliant backup applications interact
with the ndmpd process on the storage system.
NDMP requests from backup applications
prompt the storage system to invoke native
dump and restore commands to initiate
backups and restores.
NDMP OVERVIEW
The NDMP is an open standard for centralized control of data management across the
enterprise. NDMP enables backup software vendors to provide support for NetApp storage
systems without having to port client code.
An NDMP-compliant solution separates the flow of backup and restore control information
from the flow of data to and from the backup media. These solutions invoke the Data ONTAP
operating system’s native dump, and restore to back up data from, and restore data to, a
NetApp storage system.
NDMP also provides low-level control of tape devices and media changers.
Using data protection services through backup applications that support NDMP offers a
number of advantages:
• Provides sophisticated scheduling of data protection operations across multiple storage systems.
• Provides media management and tape inventory management services to eliminate or minimize
manual tape handling during data protection operations.
• Supports data catalogue services that simplify the process of locating specific recovery data. Direct
Access Recovery optimizes the access of specific data from large backup tape sets.
• Supports multiple topology configurations, allowing efficient sharing of secondary storage
resources (tape library) through the use of three-way network data connections.
NDMP Support Matrix
Partner Data ONTAP Data ONTAP Data ONTAP Data ONTAP Data ONTAP
6.2 6.3 6.4 6.5 7.0
Atempo® Time Navigator™ 3.6 3.6 3.7 TBD TBD
BakBone® NetVault® 6.5.2 6.5.2 7.0 7.0, 7.1 7.1.1
CommVault® Galaxy® 4.1 4.1 4.2 TBD 5.9
BrightStor® ARCserve® 9 9 9 TBD 11.1
HP® Data Protector 5.0 5.0 5.0, 5.1 TBD 5.5
Legato® NetWorker™ 6.2 6.1.3, 6.2 6.1.3, 6.2, TBD 7.2
7.0
Syncsort® Backup Express 2.1.4, 2.1.5 2.1.4, 2.1.5 2.1.5 TBD 2.3
IBM® Tivoli® Storage Manager 5.0, 5.1 5.0, 5.1 5.2 TBD 5.3
Veritas® NetBackup™ 3.4, 3.4.1, 4.5 4.5, 5.0 4.5, 5.0 4.5, 5.0, 5.1
4.5 (Data (Data
ONTAP 6.3.3 ONTAP 6.4.2
or later only) or later only)
NDMP SUPPORT MATRIX
THIRD-PARTY NDMP SOLUTIONS

Solutions based on NDMP can centrally manage and control backup and recovery of highly
distributed data while minimizing network traffic. These products can direct a NetApp
storage system to back itself up to a locally attached tape drive without sending the backup
data over the network. NDMP-based solutions are designed to assure data protection and
efficient restoration in the event of data loss. These solutions include many control and
management features—such as discovery, configuration, scheduling, media management,
tape library control, and user interface—not available using the native dump and restore
commands for NetApp storage systems.
In 1996, NetApp partnered with Intelliguard to create NDMP. Since then, the two companies
have promoted the industry standardization of NDMP.
In the compatibility matrix in the figure above, key backup vendors and their NDMP
solutions are listed. To obtain a complete list of third-party NDMP backup applications and
software versions, see the online documentation on the NOW site.
NDMP third-party solutions provide:
• Central management and control of highly distributed data
• Local backup of NetApp storage systems (without sending data over the network)
• Control of robotics in tape libraries
• Data protection in a mixed server environment with UNIX, Windows NT, and NetApp storage
systems
• Investment protection with established backup strategies
Gigabit Ethernet Tape to SAN
Client Client Client Client Client
UNIX NT Backup
Application Application Ethernet LAN Application Application Host
Server Server Server Server Server
Gigabit Ethernet
Tape SAN
Spectra Logic Quantum|ATL
GIGABIT ETHERNET TAPE TO SAN
NetApp delivers both certified FC fabric Tape-to-SAN backup solutions and Gigabit Ethernet
(GbE) Tape-to-SAN solutions. These solutions are made possible through our joint
partnerships with industry leaders in the fields of tape automation, fabric switches, and
backup software. They offer significant benefits for enterprise customers over tape devices
attached (through SCSI) directly to NetApp storage systems. Specifically, these two Tape-to-
SAN solutions offer the following benefits:
• Tape sharing and amortization of tape resources
• Extended distances from data to centralized tape backup libraries
• Minimized impact of backups on servers on the network
• Tape drive hot-swapping
• Dynamic tape configuration changes without shutting down the NetApp storage system
The GbE Tape-to-SAN configurations allow multiple NetApp storage systems to
concurrently transfer data over GbE to one or more tape libraries that support NDMP. This
architecture allows each drive inside the tape library to be seen as a shared resource and an
NDMP server. A clear advantage of this configuration is the demonstrated interoperability of
Ethernet-based components.
Fibre Channel Tape to SAN
Client Client Client Client Client
UNIX NT Backup
Application Application Ethernet LAN Application Application Host
Server Server Server Server Server
Fibre Channel
Tape SAN
Spectra Logic StorageTek Quantum|ATL ADIC IBM
FIBRE CHANNEL TAPE TO SAN
Together with a third-party NDMP-based data protection solution that supports technology
known as dynamic drive sharing, both FC and GbE Tape-to-SAN solutions enable you to
dynamically allocate tape drives in a larger library to NetApp storage systems as needed for
backup or recovery operations. This eliminates the need to dedicate expensive tape devices to
each system.
These solutions help provide essential elements to enterprise customers seeking to maximize
the availability of their NetApp storage. You can replace or upgrade tape devices with no
impact on the system's ability to serve data to clients. Drives can be dynamically added or
removed without requiring any downtime.
For information about certified backup solutions, see the NOW site.
NDMP Terminology and Components
NDMP client
– The backup application is the NDMP client
– NDMP clients submit requests to an NDMP
server, and then receive replies and status back
from the NDMP server
NDMP server
– A process or service that runs on the NetApp
storage system
– The NDMP server processes requests from
NDMP clients, and then returns reply and status
information back to the NDMP client
NDMP TERMINOLOGY AND COMPONENTS
In the following definitions, the primary storage is the system that performs the NDMP Data
Service and the secondary system is the one that performs the NDMP Tape Service.
• Data Management Application (DMA)—Also called the backup application. The DMA controls
the NDMP session. Veritas NetBackup and Legato Networker are examples of backup
applications.
• NDMP Service—Provides Data Service, Tape Service, and SCSI Service.
• Control Connection—Bidirectional TCP/IP connection that carries external data representation
standard (XDR) encoded NDMP messages between the DMA and the NDMP server. The Control
Connection is analogous to an NDMP session on the storage system.
• Data Connection—Establishes a connection between the two NDMP systems that carry the data
stream; either internal to the NetApp storage system (local) or TCP/IP (remote).
• Data Service—NDMP service that transfers data between the primary storage system (where the
data on disks resides) and the Data Connection.
• Tape Service—NDMP service that transfers data between the secondary storage and the Data
Connection, allowing the DMA to manipulate and access secondary storage.
Typical NDMP Backup Session
DMA Host Control Messages
Data Connection
DMA Payload Data
Notifications, file history, log messages
Content
Index
TCP/IP TCP/IP
IP Network
NDMP NDMP
Data Tape
Service Service
TCP/IP, IPC
Primary Secondary
Storage Storage
System System
TYPICAL NDMP BACKUP SESSION
The figure above represents a storage system (primary) to storage system (secondary) to tape
data protection topology, where the backup operation is driven by a DMA host (NDMP
client).
The DMA opens connections to, and activates NDMP services in, both storage systems.
Control messages to the services configure the services and create a data connection between
them. More control messages initiate and start the backup; the data service creates the
payload (backup image) and writes it to the data connection, where the tape service receives
it.
Log messages and notifications are sent from the services to the DMA.
CONTROL CONNECTION
• XDR encoded
• DMA-server exchanges
• Well known, registered TCP port (10,000)
• DMA “manages” servers through request/reply control exchanges
• Server-initiated log and notification posts (short, unidirectional)
• Server-initiated file history transfers (bulk data, unidirectional)
DATA CONNECTIONS
• Opaque byte stream with no XDR encoding
• Server-server exchanges
• DMA “manages” data connection between peer servers
• Non-reserved TCP ports are assigned by “listening” server
• Server-initiated backup-stream transfers (bulk data, unidirectional)
NDMP Connection Information
NDMP uses a TCP/IP connection to a

dedicated port
NDMP does not require CIFS, NFS, HTTP,
FCP, or iSCSI protocol license
Storage system listens for NDMP requests on
port 10000 when ndmpd is enabled
All messages are encoded using external data
representation (XDR) standard (see RFC 1014
for more information)
NDMP CONNECTION INFORMATION
NDMP Tape Backup
Topologies
NDMP TAPE BACKUP TOPOLOGIES
NDMP Tape Backup Topologies
Storage system to local tape (direct-attached)

Storage system to network-attached tape
library
Storage system to storage system to tape
Storage system to server to tape
Server to storage system to tape
NDMP TAPE BACKUP TOPOLOGIES
NDMP supports a number of topologies and configurations between backup applications and
storage systems or other NDMP servers providing data (file systems) and tape services.
The NDMP protocol specification allows the following backup configurations:
• Local backup from a NetApp storage system to a direct-attached tape device
• Three-way backup from a NetApp storage system to a network-attached tape library
• Three-way backup from a NetApp storage system through the network to another NetApp storage
system with a local tape device
• Backup from a NetApp storage system through the network to a UNIX or Windows NT backup
server with a local tape device
• Backup from a UNIX or Windows NT server through the network to a NetApp storage system
with a local tape device
Storage System to Local Tape (Direct-
Attached)
The storage system to local tape topology
provides the best performance.
The distance between the storage system and
tape limited by SCSI/FC
SCSI-attached tape drives are dedicated to a
single storage system
Backup Server NDMP Server
File History
LAN Boundary NDMP Control
Backup Data
Data
STORAGE SYSTEM TO LOCAL TAPE (DIRECT-ATTACHED)
In the simplest configuration, a backup application backs up data from a storage system to a
tape subsystem attached to the storage system. The NDMP control connection exists across
the network boundary. The NDMP data connection that exists within the storage system
between the data and tape services is called an NDMP local configuration.
Storage System to Network-Attached Tape
Library
Dynamic drive sharing without additional
software
No distance limit between source storage
system and tape library
Performance is dependant on network
architecture and storage system resources
Backup Server Data
File History
NDMP Control
Backup Data
STORAGE SYSTEM TO NETWORK-ATTACHED TAPE LIBRARY
NDMP-enabled tape libraries provide a variation of the three-way configuration. In this case,
the tape library attaches directly to the TCP/IP network, and then communicates with the
backup application and the storage system through an internal NDMP server.
Storage System to Storage System to Tape
Tape devices shared between multiple storage

systems
system and tape
Performance is dependant on network
architecture
Backup Server Data
File History
NDMP Control
Backup Data
STORAGE SYSTEM TO STORAGE SYSTEM TO TAPE
A backup application can also back up data from a storage system to a tape library (a media
changer with one or more tape drives) attached to another storage system. In this case, the
NDMP data connection between the data and tape services is provided by a TCP/IP network
connection. This configuration is referred to as an NDMP three-way storage-system-to-
storage-system.
Storage System to Server to Tape
Tape device shared across all backups

system and disk
Performance is dependant on network and
server architecture
File History
NDMP Control
Backup Data
Data
STORAGE SYSTEM TO SERVER TO TAPE
The storage-system-to-server configuration allows storage system data to be backed up to a

tape library attached to the backup application host, or to another data server system.
Server to Storage System to Tape
Tape devices attached to the storage system

are used for all backups
No distance limit between source system and
tape
Performance is dependant on network, server
architecture, and storage system resources
File History
NDMP Control
Backup Data
Data
SERVER TO STORAGE SYSTEM TO TAPE
The server-to-storage-system configuration allows server data to be backed up to a tape

library attached to a storage system.
Using Tape Devices with NDMP
Can be attached through NetApp storage appliance
Backup Server NDMP Server Tape Drive

NDMP Control Connection Tape Drive
Robot
Can be attached through backup server

Backup Server NDMP Server Tape Drive
NDMP Control Connection Tape Drive
Robot
NOTE: When sharing a tape device with backup

server, alwaysattach/configure the device through
the backup server.
USING TAPE DEVICES WITH NDMP
When using NDMP, the storage system can read from or write to the following devices:
• Stand-alone tape drives or tapes in a tape library that is attached to the storage system
• Tape drives or tape libraries attached to the workstation that runs the backup application
• Tape drives or tape libraries attached to a workstation or storage system on your network
• NDMP-enabled tape libraries attached to your network
NOTE: To use NDMP to manage your tape library, you must set the tape stacker autoload
setting to off. Otherwise, the system won’t allow media-changer operations to be controlled
by the NDMP backup application.
NAMING CONVENTIONS FOR TAPE LIBRARIES

The following names are used to refer to tape libraries: mcn or /dev/mcn; sptn or /dev/sptn.
Tape libraries can also be aliased to worldwide names (WWNs).
• To view the tape libraries that are recognized by the system, use sysconfig –m.
• To display the names currently assigned to libraries on the storage system, use storage
show mc.
• To display the aliases of tape drives, use storage show tape.
For more information about tape aliasing and tape commands, see the Data ONTAP Data
Protection Tape Backup and Recovery Guide on the NOW site.
Enabling and
Configuring NDMP
ENABLING AND CONFIGURING NDMP
Enabling and Configuring NDMP
NDMP is disabled by default. To enable:
ndmpd on or options ndmpd.enable on
The version must match the version configured on the
NDMP backup application. To configure:
ndmpd version { 2 | 3| 4}
By default, there is no host access control configured. To
configure:
ndmpd.access
Configuring NDMP authorization methods:
ndmpd.authtype
– Combination of challenge, plaintext, or both
– SnapVault and SnapMirror management requires challenge
ENABLING AND CONFIGURING NDMP
To enable a storage system for basic management by an NDMP backup application, you must
enable the storage system’s NDMP support, and specify the configured NDMP version of the
backup application, host IP address, and authentication method.
To prepare a storage system for NDMP management, complete the following steps.
1. Enable the NDMP service:
system>options ndmpd.enable on
When disabling ndmpd, the storage system continues processing all requests for sessions already
established, but rejects new sessions.
2. Specify the NDMP version to support on the storage system. This version must match the version
configured on the NDMP backup application server:
system>ndmpd version {2|3|4}
Data ONTAP supports NDMP versions 2, 3, and 4 (4 is the default value).
The storage system and the backup application must agree on a version of NDMP to be used for
each NDMP session. When the backup application connects to the storage system, the storage
system sends the default version back. The application can choose to use that default version and
continue with the session. However, if the backup application uses an earlier version, it begins
version negotiation, asking if each version is supported, to which the storage system responds with
a yes or no.
Because some backup applications do not support version negotiation, the ndmpd version
command controls the maximum and default NDMP version allowed. If you know your backup
application does not support NDMP version 4, and does not negotiate versions, you can use this
command to define the maximum version Data ONTAP supports so that the application can
operate correctly.
3. If you want to specify a restricted set of NDMP backup-application hosts that can connect to the
storage system, set the following option:
system>options ndmpd.access {all|legacy|host[!]=hosts|if
[!]=interfaces}
Where:
• all is the default value, which permits NDMP sessions with any host
• legacy restores previous values in effect before a Data ONTAP version upgrade; in the
case of Data ONTAP 6.2, the legacy value is equal to all\
• host=hosts allows a specified host or a comma-separated list of hosts to run NDMP
sessions on this storage system; the hosts can be specified by either host name or IP address
• host!=hosts, blocks a specified host or comma-separated list of hosts from running
NDMP sessions on this storage system; the hosts can be specified by either host name or IP
address
• if=interfaces, allows NDMP sessions through a specified interface or comma-
separated list of interfaces on this storage system
• if!=interfaces, blocks NDMP sessions through a specified interface or comma-
separated list of interfaces on this storage system
4. Specify the authentication method through which users are allowed to start NDMP sessions with
the storage system. This setting must include an authentication type supported by the NDMP
backup application:
system>options ndmpd.authtype
{challenge|plaintext|challenge,plaintext}
The challenge authentication method is generally the preferred, and more secure,
authentication method. Challenge is the default type.
With the plaintext authentication method, the login password is transmitted as clear text.
Enabling and Configuring NDMP (Cont.)
Creating local account:
useradmin useradd <backupuser>
Setting the NDMP password length:
By default, Data ONTAP generates a 16-character
password. If DMA does not support this, reduce the
password length to 8 characters. To set the password
length:
ndmpd.password_length { 8 | 16 }
Generating an encoded NDMP password:
ndmpd password <backupuser>
Enabling the NDMP connection log:
ndmpd.connectlog.enabled { off | on }
Including or excluding files with ctime changed from
incremental dumps:
ndmpd.ignore_ctime.enabled { on | off }
ENABLING AND CONFIGURING NDMP (CONT.)
5. If you have operators without root privileges on the storage system that will be carrying out tape-
backup operations through the NDMP backup application, then add a new backup user to the
Backup Operators useradmin group list:
system>useradmin user add backupuser -g “Backup Operators”
6. Specify an 8- or 16-character NDMP password length (the default value is 16):
system>options ndmpd.password_length
7. Generate an NDMP password for the new user:
System>ndmpd password backupuser
NOTE: If you change the password to your regular storage system account, repeat this procedure
to obtain your new system-generated, NDMP-specific password.
8. Enable logging of NDMP connection attempts with the storage system:
system>options ndmpd.connectlog.enabled on
This enables Data ONTAP to log NDMP connection attempts in the /etc/messages file.
These entries can help you determine if and when authorized or unauthorized users are attempting
to start NDMP sessions. The default for this option is off.
Log entries for attempted NDMP connections or operations include the following fields:
• Time
• Thread
• NDMP request and action (allow or refuse)
• NDMP version
• Session ID
• Source IP (address where the NDMP request originated)
• Destination IP (address of the storage system receiving the NDMP request)
• Source port (port through which the NDMP request was transmitted)
• Storage system port through which the NDMP request was received
Example:
Friday Aug 25:16:45:17GMT ndmpd.access allowed fosr version =4,
sessid=34,
from src ip = 172.29.19.40, dst ip =172.29.19.95, src port =
63793, dst port = 10000.
9. Include or exclude files with the ctime changed from incremental dumps according to your
backup requirements:
system>options ndmpd.ignore_ctime.enabled { on | off }
When this option is on, users can exclude files with the ctime changed from system storage
incremental dumps, because other processes (like virus scanning) often alter the ctime of files.
When this option is off, backup on the storage system includes all files with a change or modified
time later than the last dump in the previous level dump.
NDMP Status and Session Information
Displaying NDMP status and session

information
– To determine if a session is operating as
expected:
ndmpd status [session]
– To debug an NDMP session if there are
problems:
ndmpd probe [session]
Terminating NDMP sessions
– To terminate a specific session:
ndmpd kill session#
– To terminate all NDMP sessions:
ndmpd killall
NDMP STATUS AND SESSION INFORMATION
DISPLAYING NDMP SESSION INFORMATION

To display NDMP session information, use the following command:
system>ndmpd status [session]
where session is the specific session number you want the status of, from 0 to 99.
To display the status of all current sessions, leave session blank.
In the following example, the command displays information about session 4:
system>ndmpd status 4
ndmpd ON.
Session: 4
Active
version: 3
Operating on behalf of primary host.
tape device: not open
mover state: Idle
data state: Idle
data operation: None
To display detailed NDMP session information, use the following command:
system>ndmpd probe [session]
In the following example, the command displays detailed status information for session 4:
system>ndmpd probe 4
ndmpd ON.
Session: 4
isActive: TRUE
protocol version: 3
effHost: Local
authorized: FALSE
client addr: 10.10.10.12.47154
spt.device_id: none
spt.ha: -1
spt.scsi_id: -1
spt.scsi_lun: -1
tape.device: rst0a
tape.mode: Read/Write
mover.state: Active
mover.mode: Read
mover.pauseReason N/A
mover.haltReason N/A
mover.recordSize: 10240
mover.recordNum: 315620
mover.dataWritten: 3231948800
mover.seekPosition: 0
mover.bytesLeftToRead: 0
mover.windowOffset: 0
mover.windowLength: -1
mover.position: 0
mover.connect.addr_type:LOCAL
data.operation: Backup
data.state: Active
data.haltReason: N/A
data.connect.addr_type: LOCAL
data.bytesProcessed: 3231989760
TERMINATING NDMP SESSIONS
To terminate a specific session:
system>ndmpd kill session#
where session # is the specific NDMP session you want to terminate, from 0 to 99
To terminate all NDMP sessions:
system>ndmpd killall
These kill commands allow no responding sessions to be cleared without the need for a
reboot, because the ndmpd off command waits until all sessions are inactive before turning
off the NDMP service.
NDMP Dump and Restore Format
The Data ONTAP dump adheres to the Solaris ufsdump
format.
Dump format:
– Phase I and II: Build the map of files and directories, and
collect file history and attribute information
– Phase III: Dump data to tape, specifically directory
entries
– Phase IV: Dump files
– Phase V: Dump ACLs
Restore format:
– Phase I: Restore directories
– Phase II: Restore files
NDMP DUMP AND RESTORE FORMAT
Data ONTAP dump adheres to the Solaris ufsdump format.

Before taking a look at the NDMP dump and restore format, it is important to understand the
following terms:
• Every file on a file system has an identifier associated with it, called the inode. A file system
typically has inodes preallocated on it.
• The inode file is a special file on the file system that contains a list of all the inodes and their
details.
• The inode map is an array that has as many elements as it has number of inodes on the volume.
The inode number serves as the index for its corresponding entry in the array. A value of 1 in any
entry indicates that the corresponding file will be present in a particular backup.
• An offset map is an array that has as many elements as it has number of inodes on the volume. The
inode number serves as the index for its corresponding entry in the array. If an inode exists in a
backup, its corresponding entry contains the physical address on tape that marks the beginning of
the file data in the backup image.
PHASES AND SUBPHASES OF A DUMP OPERATION

Phase I generates the list of files that need to be backed up. The output of this phase is the
inode map. The inode to be backed up has its corresponding entry set to 1. The inode that is
not to be backed up has its entry set to 0.
Phase II is essentially a no-op for level 0 backups. It does nothing except rewrite the inode
map generated in Phase I to the tape.
Phase III writes the entire directory structure for what is being backed up to the tape. Phase
III includes two subphases:
• Phase IIIa is the early ACLs phase. This phase dumps ACLs for the data set to the tape. This step
could take more time if a lot of files in the data set have ACLs.
• Phase IIIb was introduced in Data ONTAP 6.4. This phase is executed only for NDMP backups
that have File History turned on. The output of this phase is the offset map. For each file on any
given backup, the offset map contains the physical address on the tape that marks the beginning of
the file in the backup image.
Phase IV dumps the actual file data on tape. This phase operates in the inode order. A smaller
inode number is guaranteed to be found before a larger inode number.
Phase V is a duplicate of Phase IIIa. This is what traditionally existed in the NetApp native
dump, and this phase is retained for backward compatibility.
PHASES IN A RESTORE OPERATION

Phase I: Restore directories.
Phase II: Restore files.
Dump and Restore Event Logs
Event logging is off by default

To enable event logging:
backup.log.enable { off | on }
Event log files
– Stored in the /etc/log/backup log file
– Rotated once a week
– Saved for up to six weeks
Event log message format
To change the log message format:
type timestamp identifier event
(event_info)
DUMP AND RESTORE EVENT LOGS
Data ONTAP automatically logs significant events and the times at which they occur during
dump and restore operations. You might want to view event log files to verify if a backup was
successful, to gather statistics on backup operations, or to use information contained in past
event-log files to help diagnose problems with dump and restore operations.
Event logging is turned off by default. To enable event logging:
system>options backup.log.enable on
All dump and restore events are recorded in a log file backup in the /etc/log/ directory.
Once a week, log files are rotated. The /etc/log/backup file is copied to
/etc/log/backup.0, the /etc/log/backup.0 file is copied to /etc/log/backup.1,
and so on. The system saves the log files for up to six weeks. This means you can have up to
seven message files (/etc/log/backup.0 through /etc/log/backup.5, plus the current
/etc/log/backup file).
EVENT LOG MESSAGE FORMAT

For each event, a message is written to the backup log file in the following format:
type timestamp identifier event (event_info)
Example:
dmp Fri Aug 25 18:54:56 PDT /vol/vol0/home(5) Start (level 0,
NDMP)
Each log message begins with one of the type indicators:
Type Meaning
Log Logging event
Dmp Dump event
rst Restore event
The timestamp field shows the date and time of the event.
The identifier field for a dump event includes the dump path and the unique ID for the
dump. The identifier field for a restore event uses only the restore destination path name
as a unique identifier. Logging-related event messages do not include an identifier field.
START AND STOP LOGGING EVENTS

The event field of a message that begins with log contains one of the following events:
• Start_Logging: Indicates the beginning of logging, or that logging has been turned back on
after being disabled
• Stop_Logging: Indicates that logging has been turned off
DUMP EVENTS
The event field for a dump event contains an event type followed by event-specific
information in parentheses. The following table describes events, their meanings, and the
related event information that might be recorded for a dump operation.
Event Meaning Event Information
Start A dump or NDMP dump begins Dump level and the type of dump
Restart A dump restarts Dump level
End Dumps completed successfully Amount of data processed
Abort The operation aborts Amount of data processed
Options Specified options are listed All options and their associated values,
including NDMP options
Tape_open The tape is open for read/write The new tape device name
Tape_close The tape is closed for read/write The tape device name
Phase_change Dump is entering a new processing phase The new phase name
Error Dump encounters an unexpected event Error message
Snapshot A snapshot is created or located The name and time of the snapshot
Base_dump A base dump entry in the etc/dumpdates The level and time of the base dump
file has been located (for incremental dumps only)
The log file for a dump operation begins with either a Start or Restart event and ends
with either an End or Abort event.
The following is an example of the output for a dump operation:
dmp Fri Aug 25 01:11:22 GMT /vol/vol0/(1) Start (Level 0
dmp Fri Aug 25 01:11:22 GMT /vol/vol0/(1) Options (b=63,
B=1000000,u)
dmp Fri Aug 25 01:11:22 GMT /vol/vol0/(1) Snapshot
(snapshot_for_backup.6, Sep 20 01:11:21 GMT)
dmp Aug 25 01:11:22 GMT /vol/vol0/(1) Tape_open (nrst0a)
dmp Aug 25 01:11:22 GMT /vol/vol0/(1) Phase_change (I)
dmp Aug 25 01:11:24 GMT /vol/vol0/(1) Phase_change (II)
dmp Aug 25 01:11:24 GMT /vol/vol0/(1) Phase_change (III)
dmp Aug 25 01:11:26 GMT /vol/vol0/(1) Phase_change (IV)
dmp Aug 25 01:14:19 GMT /vol/vol0/(1) Tape_close (nrst0a)
dmp Aug 25 01:14:20 GMT /vol/vol0/(1) Tape_open (nrst0a)
dmp Aug 25 01:14:54 GMT /vol/vol0/(1) Phase_change (V)
dmp Aug 25 01:14:54 GMT /vol/vol0/(1) Tape_close (nrst0a)
dmp Aug 25 01:14:54 GMT /vol/vol0/(1) End (1224 MB)
RESTORE EVENTS
The event field for a restore event contains an event type followed by event-specific
information in parentheses. The following table describes the events, their meanings, and the
related event information that might be recorded for a restore operation.
Event Meaning Event Information
Start A restore or NDMP restore begins Restore level and the type of restore
Restart A restore restarts Restore level
End Restore completed successfully Number of files and amount of data processed
Abort The operation aborts Number of files and amount of data processed
Options Specified options are listed All options and their associated values, including
NDMP options
Tape_open The tape is open for read/write The new tape device name
Tape_close The tape is closed for read/write The tape device name
Phase_change Dump is entering a new The new phase name
processing phase
Error Restore encounters an unexpected Error message
event
The log file for a restore operation begins with either a Start or Restart event and ends
with either an End or Abort event.
The following is an example of the output for a restore operation:

rst Fri Aug 25 02:24:22 GMT /vol/rst_vol/ Start (level 0)
rst Fri Aug 25 02:24:22 GMT /vol/rst_vol/ Options (r)
rst Fri Aug 25 02:24:22 GMT /vol/rst_vol/ Tape_open (nrst0a)
rst Fri Aug 25 02:24:23 GMT /vol/rst_vol/ Phase_change (Dirs)
rst Fri Aug 25 02:24:24 GMT /vol/rst_vol/ Phase_change (Files)
rst Fri Aug 25 02:39:33 GMT /vol/rst_vol/ Tape_close (nrst0a)
rst Fri Aug 25 02:39:33 GMT /vol/rst_vol/ Tape_open (nrst0a)
rst Fri Aug 25 02:44:22 GMT /vol/rst_vol/ End (3516 files, 1224
MB)
The following is an example of the output for an aborted restore operation:
rst Fri Aug 25 02:13:54 GMT /rst_vol/ Start (Level 0)
rst Fri Aug 25 02:13:54 GMT /rst_vol/ Options (r)
rst Fri Aug 25 02:13:54 GMT /rst_vol/ Tape_open (nrst0a)
rst Fri Aug 25 02:13:55 GMT /rst_vol/ Phase_change (Dirs)
rst Fri Aug 25 02:13:56 GMT /rst_vol/ Phase_change (Files)
rst Fri Aug 25 02:23:40 GMT /vol/rst_vol/ Error (Interrupted)
rst Fri Aug 25 2:23:40 GMT /vol/rst_vol/ Abort (3516 files,
598MB)
Using the ndmpcopy Command to
Copy Data
The ndmpcopy command:
– Used to transfer data between storage systems
that support NDMP v3 or v4
– Can carry out full and incremental transfers
– Limits incremental transfers to a maximum of
two levels (one full and up to two incremental)
– Applies NetApp to NetApp only
– Syntax:
ndmpcopy
[options]source_hostname:source_path
destination_hostname:destination_path
USING THE NDMPCOPY COMMAND TO COPY DATA
The ndmpcopy command enables you to transfer file system data between storage systems
that support NDMP v3 or v4, and the UNIX file system (UFS) dump format.
Using the ndmpcopy command, you can carry out both full and incremental data transfers.
However, incremental transfers are limited to a maximum of two levels (one full and no more
than two incremental). You can transfer full or partial volumes, qtrees, or directories, but not
individual files.
To copy data within a storage system or between storage systems using ndmpcopy, use the
following command from the source or the destination system, or from a storage system that
is not the source or the destination:
system>ndmpcopy [options] source_hostname:source_path
destination_hostname:destination_path
where source_hostname and destination_hostname can be host names or IP
addresses. If destination_path does not specify a volume (or specifies a
nonexistent volume), the root volume is used.
The following table lists available options for the ndmpcopy command.
Option Description
-sa Source authorization specifies the user name and password for connecting to the
username:[password] source storage system.
-da Destination authorization specifies the user name and password for connecting
username:[password] to the destination storage system.
-st Sets the source authentication type to be used when connecting to the source
{challenge|text} storage system.
-dt Sets the destination authentication type to be used when connecting to the
{challenge|text} destination storage system. By default, challenge is the authentication type
used. The text authentication type exchanges the user name and password in
clear text. The challenge authentication type exchanges the user name and
password in encrypted form.
-l level Sets the dump level used for the transfer to the specified value of the level.
Valid values for the dump level are 0, 1, and 2, where 0 indicates a full transfer,
and 1 or 2 indicates an incremental transfer. The default is 0.
-d Enables ndmpcopy debug log messages (which appear in the root volume
/etc/log directory) to be generated. The ndmpcopy debug log file
names are in the form ndmpcopy.yyyymmdd.
-f Enables forced mode. This mode enables overwriting system files in the /etc
directory on the root volume.
-h Prints the help message.
NDMP Online
Documentation
NDMP ONLINE DOCUMENTATION
NetApp strongly recommends you read the following documents to gain a complete
understanding of NDMP and its integration with other partner backup solutions. All of these
references are available on the NOW site.
TECHNICAL REPORTS
TR-3066: Data Protection Strategies for Network Appliances Storage Systems
NDMP SPECIFICATIONS
http://www.ndmp.org
MANUAL
Data Protection Tape Backup and Recovery Guide for Data ONTAP (latest release
recommended)
Exercise
Module 16: NDMP Fundamentals
EXERCISE
Active-Active

MODULE 17: ACTIVE-ACTIVE CONTROLLER CONFIGURATION
Active-Active
Controller
Configuration
Module 17
ACTIVE-ACTIVE CONTROLLER CONFIGURATION
17-1 Data ONTAP® 7.3 Fundamentals: Active-Active Controller Configuration
Module Objectives

Describe active-active controller configuration
Explain how the active-active configuration
works
Describe software requirements for active-
active configurations
List three modes of operation for active-active
configurations
Describe the effects on client connections of
failover and giveback operations
Describe best practices for active-active
controller configurations
MODULE OBJECTIVES
Active-Active Controller Configuration
Consists of two identical storage controllers

with each:
– Connected to its own disks shelves
– Connected to the other’s disk shelves
– Storing and saving data independently during
normal operations
If a storage controller fails, the surviving
partner serves the data of failed controller
ACTIVE-ACTIVE CONTROLLER CONFIGURATION
An active-active configuration is two storage systems (nodes) whose controllers are

connected to each other either directly or through switches.
The nodes are connected to each other through a cluster adapter or NVRAM adapter, which
allows one node to serve data to the disks on its failed partner node. Each node continually
monitors its partner, mirroring data for the partner’s NVRAM.
Active-Active is for High Availability
Configuring storage systems in an active-active

controller configuration provides the following
high-availability benefits:
Fault tolerance
Nondisruptive software upgrades
Nondisruptive hardware maintenance
ACTIVE-ACTIVE IS FOR HIGH AVAILABILITY
BENEFITS OF ACTIVE-ACTIVE CONFIGURATIONS

Active-active configurations provide fault tolerance and the ability to perform nondisruptive
upgrades and maintenance.
Active-active configurations provide the following benefits:
• Fault tolerance—When one node fails or becomes impaired, a takeover occurs and the partner
node continues to serve the data of the failed node.
• Nondisruptive software upgrades—When you halt one node and allow takeover, the partner
node continues to serve data for the halted node, allowing you to upgrade the halted node.
• For more information about nondisruptive software upgrades, see the Data ONTAP Upgrade
Guide.
• Nondisruptive hardware maintenance—When you halt one node and allow takeover, the
partner node continues to serve data for the halted node, allowing you to replace or repair
hardware on the halted node.
Configuration Characteristics
Connected through a cluster interconnect

Uses two or more loops
Each own their spare disks
Each have two mailbox disks on the root
volume
CONFIGURATION CHARACTERISTICS
CHARACTERISTICS OF NODES IN AN ACTIVE-ACTIVE CONFIGURATION

Nodes in an active-active configuration have a number of common characteristics, regardless
of what type of active-active configuration. These characteristics include:
• The nodes are connected to each other through a separate cluster interconnect consisting of
adapters and cables, through which they do the following:
• Continually verify that the other node is functioning
• Mirror log data for the partner’s NVRAM
• Synchronize the partner node’s time
• The nodes use two or more loops in which:
• Each node manages its own disks
• Each node in takeover mode manages its partner’s disks
• NOTE: For systems using software-based disk ownership, disk ownership is established by
Data ONTAP or an administrator, rather than the location of the disk on a disk shelf. For more
information about disk ownership, see the Data ONTAP Storage Management Guide.
• The nodes own their spare disks and do not share them with the other node
• The nodes each have two mailbox disks on the root volume (four mailbox disks if the root
volume is mirrored using SyncMirror) that are used to perform the following tasks:
• Maintain consistency between the pair of nodes
• Continually verify that the partner node is running or whether it has performed a takeover
• Store configuration information not specific to any particular node
• The nodes can reside on the same Windows domain or on different domains
Types of Active-Active Configurations
Standard active-active―Local node connected

to partner node
SyncMirror―Standard active-active
configuration plus synchronously written
mirrors of volumes called “plexes”
MetroCluster―An extended version of
SyncMirror for surviving site outages
– Distance between partners can be up to 100 km
– Uses specific Brocade switch models
TYPES OF ACTIVE-ACTIVE CONFIGURATIONS
STANDARD
In a standard active-active configuration, Data ONTAP ensures that each node monitors the
functioning of its partner through a heartbeat signal sent between the nodes. The NVRAM
data from one node is mirrored by its partner and each node can take over the partner’s disks
if the partner node fails. Also, the nodes synchronize each other’s time.
ACTIVE-ACTIVE WITH SYNCMIRROR

Mirroring data protects it from the following problems that could cause data loss:
• The failure or loss of two or more disks in a RAID 4 aggregate
• The failure or loss of three or more disks in a RAID-DP aggregate
In addition, the failure of an FC-AL adapter, loop, or disk shelf module does not require a
failover in a mirrored, active-active configuration.
Similar to standard active-active configurations, if either node in a mirrored active-active
configuration becomes impaired or cannot access its data, the other node automatically serves
the impaired node’s data until the problem is corrected.
METROCLUSTER
MetroCluster provides the same advantages of mirroring as mirrored active-active
configurations, with the additional ability to initiate failover if an entire site becomes lost or
unavailable.
If there is a failure or loss of two or more disks in a RAID 4 aggregate, or three or more disks
in a RAID-DP aggregate, your data is protected.
The failure of an FC-AL adapter, loop, or ESH2 module does not require a failover.
In addition, a MetroCluster enables you use a single command to initiate a failover if an entire
site becomes lost or unavailable. If a disaster occurs at one of the node locations and destroys
your data there, your data not only survives on the other node, but can also be served by that
node while you address the issue or rebuild the configuration.
Requirements for Standard Active-Active
Architecture compatibility
Storage capacity
Disk and disk shelf compatibility
Cluster interconnect adapters and cables
installed
Nodes attached to the same networks
Same software licensed and enabled
REQUIREMENTS FOR STANDARD ACTIVE-ACTIVE
SETUP REQUIREMENTS AND RESTRICTIONS FOR STANDARD ACTIVE-ACTIVE

CONFIGURATIONS
STORAGE CAPACITY
The number of disks in a standard active-active configuration must not exceed the maximum
configuration capacity. In addition, the total amount of storage attached to each node must not
exceed the capacity of a single node.
To determine your maximum configuration capacity, see the System Configuration Guide at
http://now.netapp.com/NOW/knowledge/docs/hardware/hardware_index.shtml.
NOTE: When a failover occurs, the takeover node temporarily serves data from all the
storage in the active-active configuration. When the single-node capacity limit is less than the
total active-active configuration capacity limit, the total disk space in a cluster can be greater
than the single-node capacity limit. It is acceptable for the takeover node to temporarily serve
more than the single-node capacity would normally allow, as long as it does not own more
than the single-node capacity.
DISKS AND DISK-SHELF COMPATIBILITY

• Both FC and SATA storage is supported in standard active-active configurations, as long as the
two storage types are not mixed on the same loop.
• If needed, a node can have only FC storage and the partner node can have only SATA storage.
• Cluster interconnect adapters and cables must be installed.
• Nodes must be attached to the same network and the NICs must be configured correctly.
• System features such as CIFS, NFS, or SyncMirror must be licensed and enabled on both
nodes.
NOTE: If a takeover occurs, the takeover node can only provide the functionality for the licenses
installed on it. If the takeover node does not have a license that was being used by the partner node to
serve data, your active-active configuration loses functionality after a takeover.
Standard Active-Active Configuration
Network
Active-Active Configuration
Interconnect
FC-AL FC-AL
A Loops A Loops
FC-AL
B Loops
STANDARD ACTIVE-ACTIVE CONFIGURATION
CONFIGURATION VARIATIONS
The following list describes some configuration variations that are supported for standard
active-active configurations:
• Asymmetrical configurations—One node has more storage than the other. This configuration
is supported as long as neither node exceeds the maximum capacity limit.
• Active/passive configurations—The passive node has only a root volume, while the active
node has all the remaining storage, and services all data requests during normal operation. The
passive node responds to data requests only if it has taken over the active node.
• Shared loops or stacks—If your standard active-active configuration is using software-based
disk ownership, you can share a loop or stack between the two nodes. This is particularly useful
for active/passive configurations.
• Multipath Storage—Provides a redundant connection from each node to each disk. This
configuration can prevent some types of failovers.
Enabling the License
1. License
Example:
license add abcedfg
2. Reboot
Example:
reboot
3. Enable the service on one of the two systems
Example:
cf enable
4. Check the status
Example:
cf status
ENABLING THE LICENSE
To add the license, enter the following command on both node consoles for each required
license:
license add xxxxxx
where xxxxx is the license code you received for the feature
To reboot both nodes, enter the following command:
reboot
To enable the license, enter the following command on the local node console:
cf enable
To verify that controller failover is enabled, enter the following command on each node
console:
cf status
Setting Matching Node Options
To set matching node options:

1. View and note the values of the options for
local and partner nodes.
2. Verify that the options settings are the same.
3. Correct any mismatched options.
SETTING MATCHING NODE OPTIONS
Because some Data ONTAP options must be the same on both the local and partner nodes,
you should use the options command to check these options on each node, and change them
as necessary.
To set matching node options, complete the following steps:
• Display and record options values on local and partner nodes using the following command on
each console:
• options
• The current option settings for the node are displayed on the console. The output displayed is
similar to the following:
• options autosupport.doit DONT
• options autosupport.enable on
• Verify that the options are set to the same value for both nodes. The comments are as follows:
• Value might be overwritten in takeover
• Same value required in local+partner
• Same value in local+partner recommended
• Correct any mismatched options using the following command:
• options option_name option_value
Parameters That Must Be the Same
Parameter Setting for

Date date, rdate
NDMP NDMP (on or off)
Published route table route
Route routed (on or off)
Time zone timezone
PARAMETERS THAT MUST BE THE SAME
The parameters listed in the figure above must be the same on both nodes so that takeover is
smooth and data is correctly transferred between the nodes.
Three Modes of Operation
In active-active controller configurations, there

are three modes of operation:
1. Normal
2. Takeover
3. Giveback
THREE MODES OF OPERATION
The following are descriptions of the three modes of operation:

• 1. Normal—This is the state of a storage system in an active-active configuration when there is
no takeover.
• 2. Takeover—Corresponds to a condition used to interact with a storage system after it has
taken over its partner.
• 3. Giveback—The return of identity from the emulated storage system to the failed storage
system, resulting in a return to normal operation. Giveback mode is the reverse of Takeover
mode.
How Partners Communicate
In an active-active controller configuration,

partners communicate through the interconnect
cable with a heartbeat.
System state is written to disk in a “Mailbox”
Data not committed to disk is written to the
local and partner NVRAM
If the heartbeat is not received by the partner
node, takeover can occur
HOW PARTNERS COMMUNICATE
To ensure that both nodes in an active-active controller configuration maintain the correct and
current status of the partner node, heartbeat information and node status are stored on each
node in the mailbox disks. The mailbox disks are a redundant set of disks used in
coordinating takeover or giveback operations. If one node stops functioning, the surviving
partner node uses the information on the mailbox disks to perform takeover processing, which
creates a virtual storage system. In the event of an interconnect failure, the mailbox heartbeat
information prevents an unnecessary failover from occurring. Moreover, if cluster
configuration information that is stored on the mailbox disks is out of sync during boot, the
active-active controller nodes automatically resolve the situation. The FAS system failover
process is extremely robust, preventing split-brain issues from occurring.
Active-Active Controllers and NVRAM
Each node reserves half NVRAM During Normal Mode

of the total NVRAM for Storage System 1 Storage System 2
the partner’s data
Storage Storage
During takeover, the System 1 System 2
NVLOG NVLOG
surviving partner
combines the split
NVRAM
Storage Storage
System 2 System 1
NVLOG NVLOG
(mirror) (mirror)
ACTIVE-ACTIVE CONTROLLERS AND NVRAM
NVRAM
Data ONTAP uses the WAFL file system to manage data processing and NVRAM to
guarantee data consistency before committing writes to disks. If the storage controller
experiences a power failure, the most current data is protected by the NVRAM, and file
system integrity is maintained.
In the active-active controller environment, each node reserves half of the total NVRAM size
for the partner node’s data to ensure that exactly the same data exists in NVRAM on both
storage controllers. Therefore, only half of the NVRAM in the active-active controller is
dedicated to the local node. If failover occurs, when the surviving node takes over the failed
node, all WAFL checkpoints stored in NVRAM are flushed to disk. The surviving node then
combines the split NVRAM. After the surviving node restores disk control and data
processing to the recovered failed node, all NVRAM data belonging to the partner node is
flushed to disk during the giveback operation.
HOW THE INTERCONNECT WORKS

The interconnect adapters are a critical component in the active-active controller
configuration. Data ONTAP uses these adapters to transfer system data between the partner
nodes, which maintains data synchronization in the NVRAM on both controllers. Other
critical information is also exchanged through the interconnect adapters, including the
heartbeat signal, system time, and details about temporary disk unavailability due to pending
disk-firmware updates.
When Does a Takeover Occur?
In an active-active configuration, a takeover occurs
when:
A node undergoes a software or system failure that
leads to a panic
A node undergoes a system failure (for example, a
loss of power) and cannot reboot
There is a mismatch between the disks that one node
recognizes and the disks that the other node
recognizes
One or more network interfaces configured to support
failover becomes unavailable
A node cannot send heartbeat messages to its partner
A node is halted using -f
A takeover is manually initiated
WHEN DOES A TAKEOVER OCCUR?
In an active-active configuration, a takeover occurs when:

• A node experiences a software or system failure that leads to a panic.
• A node experiences a system failure (for example, a loss of power) and cannot reboot.
• NOTE: If the storage for a node loses power at the same time, a standard takeover is not
possible. For MetroClusters in this situation, you can initiate a forced takeover.
• There is a mismatch between the disks that one node sees and the disks that the other node sees.
• One or more network interfaces that are configured to support failover become unavailable.
• A node cannot send heartbeat messages to its partner. This could happen if the node experiences
a hardware or software failure that does not result in a panic, but still prevents it from
functioning correctly.
• You halt one of the nodes without using the -f flag.
• You initiate a takeover manually.
What Happens When a Takeover Occurs
Network
Interconnect
Partner assumes the

identity of the failed node
FC-AL FC-AL
A Loops A Loops
FC-AL
B Loops Partner accesses the
failed node’s disks and
serves its data to clients
WHAT HAPPENS WHEN A TAKEOVER OCCURS
When a takeover occurs, the functioning partner node takes over the functions and disk drives
of the failed node by creating an emulated storage system that:
• Assumes the identity of the failed node
• Accesses the failed node’s disks and serves its data to clients
The partner node maintains its own identity and its own primary functions, but also handles
the added functionality of the failed node through the emulated node.
During a Takeover
Surviving partner has two identities, with each

identity able to access appropriate volumes
and networks only
You can access the failed node using rsh and
telnet commands
DURING A TAKEOVER
When a takeover occurs, the surviving partner has two identities: its own and that of its
partner. These identities exist simultaneously on the same storage system. Each identity can
access only the appropriate volumes and networks. You can send commands or log in to
either storage system by using the rsh command, allowing remote scripts that invoke
storage system commands through a remote-shell connection to continue normal operations.
ACCESS WITH RSH

Commands sent to the failed node through a remote shell connection are serviced by the
partner node, as are rsh command requests.
ACCESS WITH TELNET

If you log in to a failed node through a telnet session, a message is displayed alerting you that
your storage system has failed and to log in to the partner node. If you are logged in to the
partner node, you can access the failed node or its resources from the partner node using the
partner command.
During a Giveback
The giveback command terminates the

emulated node on the partner: cf giveback
The failed node resumes normal operation
(including serving data)
The active-active configuration resumes
normal operation
DURING A GIVEBACK
After a partner node is repaired and operating normally, you can use the cf giveback
command to return operations to the partner.
When the failed node is functioning again, the following events can occur:
• You initiate a cf giveback command that terminates the emulated node on the partner.
• The failed node resumes normal operation, serving its own data.
• The active-active configuration resumes normal operation, with each node ready to take over for
its partner if the partner fails.
Active-Active Commands
cf enable | disable
cf takeover
cf partner
cf giveback
cf status
aggr status -r
halt –f
partner
ACTIVE-ACTIVE COMMANDS
• To manually initiate a takeover, use the cf takeover command.

• To display the name of a partner node, use the cf partner command.
• To return control to a partner that has been taken over, use the cf giveback command.
• To determine whether the controller failover feature is enabled and the partner node in an active-
active configuration is up, use the cf status command.
• To display information about the disks on both the local and partner nodes, use the sysconfig
or the aggr status commands.
• To halt a node and prevent its partner from taking over, use the halt –f command.
Failover Effects On Client Connections
For clients or applications using stateless

connection protocols, I/O requests are
suspended during the takeover/giveback
period
Connections can resume when the
takeover/giveback process is complete
For CIFS and NFS v4, sessions are lost
Stateful clients and applications may—and
usually do—attempt to re-establish the session
FAILOVER EFFECTS ON CLIENT CONNECTIONS
Client disruption, although minimal, can still occur in the active-active controller
environment during the takeover and giveback processes.
When one node in an active-active configuration encounters an error and stops processing
data, its partner detects the failed (or failing) status of the partner and takes over all data
processing from that controller. If the partner is confirmed down, the surviving storage
controller then initiates the failover process to assume control of all services from the failed
storage controller. This period is referred to as takeover time for clients.
After the failed storage controller is repaired, you can return all services to the repaired
storage controller by issuing the cf giveback command on the surviving storage controller
serving all clients. This command triggers the giveback process, and the repaired storage
controller boots when the giveback operation is complete. This process is referred to as
giveback time for clients.
Therefore, the takeover and giveback period for clients equals the sum of the takeover time
plus the giveback time, as represented in the following equations:
• Takeover time = time to detect controller error (mailbox disks not responding) and initiate
takeover + time required for takeover to complete (synchronize the WAFL logs).
• Giveback time = time required to release partner’s disks + time to replay the WAFL log + time
to start all services (NFS/NIS/CIFS, and so on) and process export rules
• Total time = takeover time + giveback time.
NOTE: For clients or applications using stateless connection protocols, I/O requests are
suspended during the takeover and giveback periods, but resume when the takeover and
giveback processes are complete. For CIFS, sessions are lost, but the application could—and
generally does—attempt to re-establish the session.
The amount of time required for takeover and giveback is critical. With newer versions of
Data ONTAP, this time has been decreasing. In some instances, if the network is unstable or
the storage controller is configured incorrectly, total time can be very long.
Best Practices for Active-Active
Configurations
Test failover and giveback operations before
placing active-active controllers into production
Monitor:
– Performance of network
– Performance of disks and storage shelves
– CPU utilization of each controller to ensure it
does not exceed 50%
Enable AutoSupport
BEST PRACTICES FOR ACTIVE-ACTIVE CONFIGURATIONS
Thoroughly test newly installed active-active controllers before moving them into
production.
General best practices require comprehensive testing of all mission-critical systems before
introducing them into a production environment. Active-active controller testing should
include not only takeover and giveback, or functional testing, but performance evaluation as
well. Extensive testing validates planning.
Monitor network connectivity and stability.
Unstable networks not only affect total takeover and giveback times, they adversely affect all
devices on the network in various ways. NetApp storage controllers are typically connected to
the network to serve data, so if the network is unstable, the first symptom is degradation of
storage-controller performance and availability. Client service requests are retransmitted
many times before reaching the storage controller, appearing to the client as slow responses
from the storage controller. In a worst-case scenario, an unstable network can cause
communication to time-out, and the storage controller appears to be unavailable.
During takeover and giveback operations in the active-active controller environment, storage
controllers attempt to connect to numerous types of servers on the network, including
Windows domain controllers, DNS, NIS, LDAP, and application servers. If these systems are
unavailable or the network is unstable, the storage controller continues to retry establishing
communications, which delays takeover or giveback times.
Module Summary

Describe active-active controller configuration
Explain how the active-active configuration
works
Describe software requirements for active-
active configurations
List three modes of operation for active-active
configurations
Describe the effects on client connections of
failover and giveback operations
Describe best practices for active-active
controller configurations
MODULE SUMMARY
Exercise
Module 17: Active-Active Controller
Configuration
EXERCISE
Final Words

MODULE 18: FINAL WORDS
Final Words
Module 18
FINAL WORDS
18-1 Data ONTAP® 7.3 Fundamentals: Final Words
Module Objectives

Recall major areas in this course
Identify available resources
MODULE OBJECTIVES
Unified Storage
iSCSI NFS
CIFS Corporate
FC Ethernet LAN
SAN NAS
(Blocks) (Files)
NetApp
FAS
UNIFIED STORAGE
Console Access
system> version
system> sysconfig -v
System ID: 0084166726 (NetApp1)
System Serial Number: 3003908 (NetApp1)
slot 0: System Board 599 MHz (TSANTSA D0)
Model Name: FAS250
Part Number: 110-00016
Revision: D0
Serial Number: 280646
Firmware release: CFE 1.2.0 system> license
Processors: 2
Processor revision: B2 nfs site ABCDEFG
Processor type: 1250 cifs site BCDEFGH
Memory Size: 510 MB http site CDEFGHI
NVMEM Size: 64 MB of Main Memory Used
cluster not licensed
snapmirror not licensed
snaprestore not licensed
CONSOLE ACCESS
FilerView
http://<system name or ipaddress>/na_admin
FILERVIEW
AutoSupport
Email Server
AUTOSUPPORT
Role-Based Access Control
Role-Based Access Control (RBAC) is a mechanism for managing a
set of actions (capabilities) that a user or administrator can perform
on a storage system.
A role is created.
Capabilities are granted to the role.
Groups are assigned to one or more roles.
Users are assigned to groups.
Groups Roles Capabilities
ROLE-BASED ACCESS CONTROL
Disks and Data Protection
Volume 1
Raid Group 0 Spares
Parity Data Data Data
Spares are global.
DISKS AND DATA PROTECTION
Aggregates
Represent the physical storage

Made up of one or more RAID groups
A RAID group:
– One or more data disks
– Parity disks
RAID 4 has only one parity disk
RAID-DP has two parity disks
Data is striped for parity protection
Volumes are allocated space from an
aggregate
AGGREGATES
How They Work:
Aggregates and FlexVol Volumes
Create RAID groups
FlexVol 1 FlexVol 2 FlexVol 3
Create aggregate
vol1 vol2 Create FlexVol 1
vol3
– Only metadata space
used
– No preallocation of
blocks to a specific
volume
Aggregate Create FlexVol 2
RG1 RG2 RG3 – WAFL allocates space
from aggregate as data
RG1 RG2 RG3 is written
Aggregate
Populate volumes
HOW THEY WORK: AGGREGATES AND FLEXVOL VOLUMES
How Snapshot Works
File X File X
Active version of X is now composed of blocks A, B, C’

Snapshot version of X remains composed of blocks A, B, C
Atomically moves active data to new consistent state
HOW SNAPSHOT WORKS
NFS
SS1
vol0 flexvol1
data_files
etc eng_files
home misc_files
Network Connection
Client1 Client1
NFS
CIFS
Client B requests Authenticates Client B

User authentication
Session with Client B
Client A Client B Member Domain

Server Controller
CIFS
SAN Protocols
WAFL Architecture
Block Services
SAN Protocols
FCP iSCSI
Network Interfaces
FC Ethernet
Encapsulated SCSI Encapsulated SCSI
Fibre Channel Network TCP/IP Network
SAN PROTOCOLS
Data ONTAP Simplified
Client Data ONTAP
Network
Client

Client
Client
NVRAM
Physical Disks
Memory
Client
DATA ONTAP SIMPLIFIED
FlexShare
FlexShare facilitates increased storage resource

control in the following ways:
Volume priorities
Hints of cache buffers
No license required
FLEXSHARE
Standard Active-Active Configuration
Network
Interconnect
FC-AL FC-AL
A Loops A Loops
FC-AL
B Loops
STANDARD ACTIVE-ACTIVE CONFIGURATION
Additional Data ONTAP Resources
Education
– Data ONTAP CIFS Administration
– Data ONTAP NFS Administration
– Data ONTAP SAN Administration Basics
– Data Protection and Retention
– Fundamentals of Performance Analysis
Web sites
– NOW
– NetApp (www.netapp.com)
ADDITIONAL DATA ONTAP RESOURCES
Thank You!
Please fill out an evaluation.

Data ONTAP 7.3 Fundamentals Student Guide

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Data ONTAP 7.3 Fundamentals Student Guide

Încărcat de

Drepturi de autor:

Formate disponibile

NetApp University

Data ONTAP 7.3 Fundamentals

NetApp University - Do Not Distribute

Data ONTAP® 7.3 Fundamentals

NetApp University - Do Not Distribute

RESTRICTED RIGHTS LEGEND

2 Data ONTAP® 7.3 Fundamentals: Welcome

3 Data ONTAP® 7.3 Fundamentals: Welcome

4 Data ONTAP® 7.3 Fundamentals: Welcome

NetApp University - Do Not Distribute

DATA ONTAP® 7.3 FUNDAMENTALS

5 Data ONTAP® 7.3 Fundamentals: Welcome

© 2008 NetApp. All rights reserved. 2

6 Data ONTAP® 7.3 Fundamentals: Welcome

© 2008 NetApp. All rights reserved. 3

7 Data ONTAP® 7.3 Fundamentals: Welcome

By the end of this course, you should be able to:

© 2008 NetApp. All rights reserved. 4

8 Data ONTAP® 7.3 Fundamentals: Welcome

 Explain features of the WAFL® (Write Anywhere File

© 2008 NetApp. All rights reserved. 5

COURSE OBJECTIVES (CONT.)

9 Data ONTAP® 7.3 Fundamentals: Welcome

© 2008 NetApp. All rights reserved. 6

10 Data ONTAP® 7.3 Fundamentals: Welcome

© 2008 NetApp. All rights reserved. 7

COURSE AGENDA (CONT.)

11 Data ONTAP® 7.3 Fundamentals: Welcome

© 2008 NetApp. All rights reserved. 8

COURSE AGENDA (CONT.)

12 Data ONTAP® 7.3 Fundamentals: Welcome

 NOWTM (NetApp on the Web) Site

 NetApp University Support

© 2008 NetApp. All rights reserved. 9

13 Data ONTAP® 7.3 Fundamentals: Welcome

Command names, daemon names, and option

© 2008 NetApp. All rights reserved. 10

14 Data ONTAP® 7.3 Fundamentals: Welcome

NetApp University - Do Not Distribute

NetApp University - Do Not Distribute

1-1 Data ONTAP® 7.3 Fundamentals: Overview

By the end of this module, you should be able to:

1-2 Data ONTAP® 7.3 Fundamentals: Overview

© 2008 NetApp. All rights reserved. 4

1-3 Data ONTAP® 7.3 Fundamentals: Overview

 The primary function of a storage system is to

© 2008 NetApp. All rights reserved. 5

1-4 Data ONTAP® 7.3 Fundamentals: Overview

© 2008 NetApp. All rights reserved. 6

1-5 Data ONTAP® 7.3 Fundamentals: Overview

FAS3000 Series & FAS200 Series & NearStore® on FAS V-Series

© 2008 NetApp. All rights reserved. 7

NETAPP DATA ONTAP 7G PRODUCTS

1-6 Data ONTAP® 7.3 Fundamentals: Overview

“Not restricted to Data ONTAP 7G environments” means:

NETAPP STORAGE SUITE:

NetApp CommandCentral™ Storage (CCStorage) by Symantec® provides a centralized

1-7 Data ONTAP® 7.3 Fundamentals: Overview

NETAPP STORAGE SUITE:

NetApp Operations Manager (formerly DataFabric® Manager) delivers comprehensive

Protection Manager is an intuitive and innovative backup and replication-management

Provisioning Manager improves the productivity of storage administrators by automating

1-8 Data ONTAP® 7.3 Fundamentals: Overview

SAS or SATA drives configurable internally

Explain features of the WAFL® (Write Anywhere File

NOWTM (NetApp on the Web) Site

NetApp University Support

Command names, daemon names, and option

The primary function of a storage system is to