Azure NetApp Files for NFS Workloads

Azure NetApp Files (ANF) is a fully managed, high-performance file storage service built on NetApp's ONTAP storage operating system. It provides NFSv3, NFSv4.1, and SMB (CIFS) protocols, making it suitable for a wide range of enterprise workloads including HPC, SAP, databases, and VDI. ANF is designed for low latency (sub-millisecond) and high throughput, leveraging NetApp's proprietary WAFL (Write Anywhere File Layout) file system. It is a first-party Azure service, meaning it is natively integrated with Azure networking and identity.

Azure offers multiple file storage options: Azure Files (SMB only, with NFS preview but limited performance), Azure Blob Storage (object storage, not a file system), and Azure NetApp Files (enterprise NAS). ANF fills the gap for workloads that require: - POSIX compliance (permissions, locking, ownership) – critical for Linux-based workloads. - Sub-millisecond latency – required by databases like SAP HANA, Oracle, and MySQL. - High throughput and IOPS – for HPC, media rendering, and EDA. - Native NFS support (v3 and v4.1) – for on-premises lift-and-shift migrations. - Snapshots, clones, and replication – for data protection and DR.

ANF is deployed as a capacity pool within a NetApp account. The capacity pool is a logical boundary that defines the service level (performance tier) and total provisioned capacity. Within a capacity pool, you create volumes, which are the actual file shares exposed via NFS or SMB. Each volume is served by a highly available pair of NetApp controllers running ONTAP. The controllers are dedicated to your capacity pool, not shared with other tenants, ensuring consistent performance (no noisy neighbor).

Key Components and Architecture: - NetApp Account: Top-level container for ANF resources. Must be created in a region that supports ANF. - Capacity Pool: Defines the service level (Standard, Premium, Ultra) and total provisioned capacity (TiB). The service level determines the maximum throughput and IOPS per TiB. - Volume: A logical file share with its own mount path, export policies, and snapshot policies. Volumes are created within a capacity pool and consume capacity from it. - Virtual Network (VNet): ANF volumes are deployed into a delegated subnet (called NetApp subnet) within your VNet. This subnet must be at least /26 (64 IPs) and cannot have any other resources. The volume receives an IP address from the subnet and is accessible from any resource in the VNet (or peered networks). - Export Policy: Controls NFS access at the volume level. You define allowed IP ranges (CIDR) and access rules (read/write, root squash, security style). - Snapshots: NetApp snapshots are point-in-time, read-only copies of the volume. They are space-efficient (copy-on-write) and can be used for quick recovery. You can schedule snapshots with policies (hourly, daily, weekly). - Cross-Region Replication: ANF supports asynchronous replication to another region for disaster recovery. Replication is volume-level and uses NetApp SnapMirror technology.

Performance Tiers and Throughput: ANF offers three service levels, each with a guaranteed throughput per TiB of provisioned capacity: - Standard: 16 MB/s per TiB (up to 4,500 MB/s per volume with larger capacity) - Premium: 64 MB/s per TiB (up to 4,500 MB/s per volume) - Ultra: 128 MB/s per TiB (up to 4,500 MB/s per volume)

IOPS is roughly proportional to throughput, with typical values of 1,000 IOPS per MB/s for sequential workloads. For random workloads, IOPS is higher but latency increases. The maximum volume size is 100 TiB, and the maximum capacity pool size is 500 TiB.

Networking and Security: ANF volumes are accessible only from within the VNet (or via peered networks, ExpressRoute, VPN). They are not exposed to the internet. NFS traffic is unencrypted by default, but you can enable Kerberos encryption for NFSv4.1 (requires domain join). For SMB, encryption is supported via SMB 3.0. Access control is managed via export policies (IP-based) and, for NFSv4.1, via Kerberos or AAD DS integration.

Configuration and Verification Commands: To create an ANF volume, you typically use the Azure portal, CLI, or PowerShell. Example CLI commands:

# Create a NetApp account
az netappfiles account create -g myResourceGroup -n myNetAppAccount -l eastus

# Create a capacity pool (Standard, 4 TiB)
az netappfiles pool create -g myResourceGroup -a myNetAppAccount -n myPool -l eastus --service-level Standard --size 4

# Create an NFSv3 volume (100 GiB)
az netappfiles volume create -g myResourceGroup -a myNetAppAccount -p myPool -n myVolume -l eastus --file-path myVolume --usage-threshold 100 --vnet myVnet --subnet myNetAppSubnet --protocol-types NFSv3

To verify the volume mount path:

az netappfiles volume show -g myResourceGroup -a myNetAppAccount -p myPool -n myVolume --query mountTargets

Interaction with Related Technologies: - Azure Backup: ANF snapshots can be used for instant recovery, but for long-term backup, you can use Azure Backup for ANF (which leverages snapshots and offloads them to Azure Blob Storage). - Azure Site Recovery: You can replicate ANF volumes to another region using ANF cross-region replication, not ASR. - Azure VMware Solution: ANF is a supported datastore for AVS, providing NFS-based storage for VMware workloads. - HPC and SAP: ANF is certified for SAP HANA (NFS) and is commonly used with Azure HPC clusters (e.g., CycleCloud, Slurm).

A global manufacturing company runs SAP S/4HANA on Azure. They need low-latency, high-throughput NFS storage for the HANA data and log volumes. They choose Azure NetApp Files Premium tier because it provides 64 MB/s per TiB, which meets their 400 MB/s throughput requirement for a 6 TiB HANA system. They create two volumes: one for data (4 TiB) and one for log (2 TiB). They use NFSv4.1 for better locking and security. The volumes are placed in a delegated subnet within the same VNet as the HANA VMs. They configure export policies to allow only the HANA VM subnet. They also enable cross-region replication to a secondary region for disaster recovery, with an RPO of 15 minutes. The migration from on-premises was a simple lift-and-shift because ANF supports the same NFS protocol as their existing NetApp storage. The key challenge was sizing the capacity pool correctly: they initially over-provisioned the pool (10 TiB) to allow for growth, but then they realized the throughput was limited by the pool size. They had to increase the pool to 12 TiB to get the needed throughput.

A hedge fund runs Monte Carlo simulations on Azure HPC clusters. They need a parallel file system that can handle thousands of concurrent reads/writes with sub-millisecond latency. They deploy Azure NetApp Files Ultra tier volumes (128 MB/s/TiB) and create multiple volumes for different data sets. They use NFSv3 because their application stack is older and does not support NFSv4.1. They mount volumes on each compute node using the hard and intr options to handle network interruptions. The performance is critical: they benchmarked ANF against Azure Files NFS and found ANF consistently lower latency by 2-3 ms. They also use ANF snapshots to create checkpoints of simulation data every hour, allowing rollback if a job fails. The biggest issue they faced was network bandwidth: the delegated subnet was only /28, which limited the number of mount targets. They had to resize the subnet to /26 to accommodate more IP addresses.

A large enterprise deploys Windows Virtual Desktop (now Azure Virtual Desktop) and uses FSLogix profile containers. They need a highly available, low-latency SMB share for user profiles. They choose Azure NetApp Files with SMB protocol. They create a capacity pool with Premium tier and a volume for FSLogix profiles. They join the ANF volume to an Active Directory domain (via Azure AD DS or on-premises AD) to support Kerberos authentication. They configure export policies to allow only the AVD session hosts. The volume is sized at 10 TiB for 5,000 users. They use ANF snapshots for point-in-time recovery of user profiles. A common misconfiguration is forgetting to set the security style to NTFS for SMB volumes; if left as UNIX, Windows clients cannot access the files. Also, they learned that ANF does not support SMB Multichannel, so they had to ensure the network path was not a bottleneck.