NS0-701 key terms

A set of up to many nodes that present a single administrative and namespace view. Nodes share configuration, peer over an internal network, and fail over storage and LIFs to partners, simplifying management and availability.

A dedicated high-speed private network linking cluster nodes. It carries heartbeat, cluster membership, configuration replication, and non-local traffic, so its health and low latency are critical to cluster stability and takeover behavior.

A logical server inside a cluster that owns its own namespace, volumes, LIFs, protocols, and security style. Clients mount an SVM, not the cluster, and each SVM is isolated from others.

An IP address bound to a port or interface group, with roles such as data, cluster management, node management, intercluster, or SAN. LIFs move between ports and nodes without changing client-visible addressing.

The SVM-scoped LIF that serves client data traffic for NFS, CIFS, iSCSI, or NVMe. It can be hosted on several ports and fail over automatically, so clients should reach it by DNS name.

A cluster-scoped LIF used only for replication traffic between clusters, such as SnapMirror and SnapVault transfers. It must be reachable by peers and is typically placed on dedicated high-bandwidth ports.

A named set of ports and broadcast domains that constrains where a data LIF may run. It defines the candidate home ports for failover, keeping traffic on networks reachable by the clients that use it.

A grouping of cluster ports that share a Layer 2 network and subnet. ONTAP uses broadcast domains to place LIFs and to decide which ports are valid targets when a LIF needs to move.

A RAID-protected pool of physical disks or disk partitions from which volumes are carved. Aggregates provide the redundancy and spare capacity layer, and their RAID type and disk count affect performance and rebuild behavior.

A double-parity RAID layout that survives two simultaneous disk failures within a RAID group. It is the common default for large drives because rebuild times are long and single parity would leave data unprotected.

An unassigned disk reserved to replace a failed member automatically or to support aggregate expansion. ONTAP tracks spare counts per disk type and size, and low spares raise risk during rebuilds.

A flexible logical container inside an aggregate that holds files in a namespace and carries its own settings, snapshots, quotas, and efficiency policies. Volumes can be thin provisioned and moved without disrupting clients.

A scale-out volume made of multiple constituent volumes spread across nodes. It increases capacity and throughput for large namespaces and parallel workloads, while presenting one namespace and one mount point.

A standard ONTAP volume contained within one aggregate on one node. It is the traditional unit for shares, exports, and SnapMirror relationships, and it can grow or shrink within aggregate limits.

A junction is a mount point that links a volume into an SVM's namespace. Junctions let administrators assemble many volumes into one directory tree that clients browse transparently.

A read-only, space-efficient point-in-time image of a volume. Snapshots preserve blocks as they change, enabling quick restores and serving as the source for replication and backup relationships.

A schedule that defines how many hourly, daily, weekly, or monthly Snapshot copies a volume keeps and when they run. Applying a policy automates rotation so old copies are deleted as new ones are created.

A replication technology that copies Snapshot copies of a volume or SVM to a remote cluster to create a mirror for disaster recovery. The destination is typically read-only until a planned or emergency failover.

A replication relationship that copies selected Snapshot copies to a destination and retains many versions over time. It supports long-term backup and recovery of older data rather than a current mirror.

A trusted relationship between two clusters that lets them exchange replication and other intercluster traffic. Peering requires intercluster LIFs, network reachability, and an authenticated peer relationship before transfers can start.

A relationship between SVMs on peered clusters that authorizes replication between specific SVMs. It is a prerequisite for SnapMirror and SnapVault relationships that are scoped to those SVMs.

A service that sends ONTAP backups to object storage in a public cloud, managed through BlueXP. It provides an offsite copy without requiring a second ONTAP cluster at the destination.

The permission model of an SVM volume: UNIX, NTFS, or mixed. It determines whether NFS-style or Windows ACL permissions are authoritative for files, and mixed mode resolves conflicts by comparing both.

An SVM-scoped set of rules that grants or denies NFS client access based on client address, protocol, and access type such as read-only or read-write. A volume must be associated with a policy to be exported.

A named SMB share on an SVM that Windows clients connect to. Access depends on share permissions, NTFS ACLs, and the SVM's authentication configuration, and shares are managed separately from NFS exports.

Joining an SVM to a Windows domain so SMB clients can authenticate with domain credentials and resolve users and groups. It requires DNS, time synchronization, and a privileged account for the join.

ONTAP's authorization model that grants users roles defining which commands and objects they may use. Roles are scoped by privilege level and can be limited to an SVM or the whole cluster.

A login requirement that combines a password with a second factor such as a time-based code or hardware token. ONTAP supports it for administrative access to reduce the risk of credential theft.

A record of security-relevant events such as file access, login attempts, and configuration changes. ONTAP can write file access auditing to a designated volume for compliance review and investigation.

A named set of throughput limits or ceilings applied to workloads such as volumes or SVMs. It controls maximum IOPS and bandwidth, and can use adaptive limits to protect performance for critical workloads.

A measure of how much work a resource can handle, reported alongside utilization and used to explain bottlenecks. High utilization with low capacity indicates a saturated component even when latency looks acceptable.

An ONTAP feature that periodically sends configuration, health, and event reports to NetApp and to configured recipients. It helps support diagnose issues and can alert administrators about failures proactively.

High-availability behavior where a node's storage and LIFs move to its HA partner after a failure, then return when the node recovers. Takeover preserves service continuity; giveback restores normal ownership.

The process of moving a cluster to a newer software release, typically through an automated validation and rolling upgrade. It checks component compatibility, updates nodes one at a time, and can be paused or reverted.

The web-based graphical interface for administering a cluster, covering volumes, shares, LIFs, protection, and health. It exposes many common tasks without CLI commands and shows dashboards for capacity and performance.

A cloud-based management platform for discovering, monitoring, and protecting ONTAP systems and cloud storage. It hosts services such as cloud backup, tiering, and classification across on-premises and cloud environments.

A replication relationship that copies ONTAP volumes to object storage in a cloud provider while preserving Snapshot format. It supports restoring data back to ONTAP and is managed through BlueXP.

ONTAP exposes a RESTful API plus SDKs and Ansible modules so administrators can automate provisioning, protection, and monitoring. Automation reduces manual error and enables repeatable, versioned cluster configuration.