Azure NetApp Files

Azure NetApp Files (ANF) is a fully managed, high-performance file storage service built on NetApp's on-premises technology. It provides NFSv3, NFSv4.1, and SMB 3.0 volumes that can be mounted from Azure Virtual Machines (VMs), on-premises clients via ExpressRoute or VPN, or other Azure services. ANF is designed for workloads that require low latency (sub-millisecond), high IOPS, and consistent performance, such as SAP HANA, Oracle databases, high-performance computing (HPC), and virtual desktop infrastructure (VDI).

ANF is deployed within an Azure Virtual Network (VNet) using a delegated subnet. This delegated subnet is dedicated to ANF and must be at least /28 (16 IPs) but ideally /26 (64 IPs) to allow for scaling. The ANF service provisions a NetApp storage controller (the 'NetApp appliance') in the delegated subnet, which handles all I/O operations. The controller uses the WAFL (Write Anywhere File Layout) file system, which is the same technology used in on-premises NetApp arrays.

- Delegated Subnet: Must be created in the same VNet as the client VMs. The subnet cannot have any other resources. Minimum size /28, recommended /26. The subnet must be delegated to Microsoft.NetApp/volumes. - Capacity Pool: Minimum 4 TiB, maximum 500 TiB. You can have multiple pools in a NetApp account. The pool's service tier determines per-TiB performance: - Standard: 16 MiB/s per TiB, 1,600 IOPS per TiB - Premium: 64 MiB/s per TiB, 4,000 IOPS per TiB - Ultra: 128 MiB/s per TiB, 8,000 IOPS per TiB - Volume Quota: The size of the volume determines its allocated performance. For example, a 4-TiB volume in a Premium pool gets 256 MiB/s (4 * 64) and 16,000 IOPS. Performance scales linearly with volume size up to the pool's aggregate limit. - Throughput Limit: A single volume can achieve up to 4.5 GiB/s of throughput (Ultra tier, large volumes). The maximum IOPS per volume is 450,000. - Latency: Typically sub-millisecond for reads and writes in Premium and Ultra tiers. - Export Policies: Control which clients can mount a volume and with what permissions (read-only or read-write). Rules are based on IP addresses or CIDR ranges. - Snapshot Policies: Can be scheduled hourly, daily, weekly, or monthly. Maximum of 255 snapshots per volume. - CRR: Requires a NetApp account in the source and destination regions. Replication is configured at the volume level. The destination volume must be in a different region and in a different capacity pool.

To create an ANF volume, you can use the Azure portal, Azure CLI, or PowerShell. Below are CLI examples:

# Create a NetApp account
az netappfiles account create --resource-group myRG --account-name myNetAppAccount --location eastus

# Create a capacity pool
az netappfiles pool create --resource-group myRG --account-name myNetAppAccount --pool-name myPool --size 4 --service-level Premium --location eastus

# Create a delegated subnet
az network vnet subnet create --resource-group myRG --vnet-name myVNet --name anf-subnet --address-prefixes 10.0.1.0/26 --delegation Microsoft.NetApp/volumes

# Create an NFSv3 volume
az netappfiles volume create --resource-group myRG --account-name myNetAppAccount --pool-name myPool --volume-name myVolume --location eastus --service-level Premium --usage-threshold 1024 --vnet myVNet --subnet anf-subnet --protocol-types NFSv3

# List volumes
az netappfiles volume list --resource-group myRG --account-name myNetAppAccount --pool-name myPool

# Create a snapshot
az netappfiles snapshot create --resource-group myRG --account-name myNetAppAccount --pool-name myPool --volume-name myVolume --snapshot-name mySnapshot --location eastus

To verify mount from a Linux VM:

sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp <mount-ip>:/<volume-name> /mnt/anf

A large enterprise runs SAP S/4HANA on Azure for its ERP system. The SAP HANA database requires extremely low latency (sub-millisecond) and high IOPS (up to 100,000 IOPS) for transaction logs and data files. The company initially used Azure Premium SSDs attached to VMs, but managing disk caching and scaling was complex. They migrated to Azure NetApp Files using the Ultra service tier. They created a 4-TiB capacity pool and a 2-TiB volume for the HANA data, and a separate 500-GiB volume for logs. The volumes were mounted via NFSv4.1 with Kerberos for security. The solution provided consistent sub-0.5 ms latency and 128 MiB/s per TiB throughput. They configured hourly snapshots for point-in-time recovery and cross-region replication to a secondary region for disaster recovery with a 5-minute RPO. The main challenge was ensuring the delegated subnet had enough IP addresses (they used a /26) and that the ExpressRoute circuit had sufficient bandwidth. Misconfiguration of export policies initially caused access issues for some application servers.

A financial services company deployed Windows Virtual Desktop (now Azure Virtual Desktop) for 5,000 remote employees. They needed a centralized storage solution for user profiles using FSLogix profile containers. The profiles required SMB shares with low latency to ensure fast logon times. They chose Azure NetApp Files with the Premium tier because it provides consistent performance and supports SMB 3.0 with multichannel. They created a 4-TiB capacity pool and multiple volumes, each serving a group of users. They configured scheduled snapshots to protect against accidental deletion and corruption. They also enabled Azure NetApp Files backup for long-term retention. The primary issue was that the delegated subnet had to be in the same VNet as the session hosts, which required careful network planning. Initially, they used a /28 subnet, but as they scaled, they ran out of IP addresses and had to create a new capacity pool with a larger subnet. The lesson: always use a /26 or larger for production.

A research organization runs genomic sequencing workloads that require massive parallel file access. They use Azure NetApp Files with the Ultra tier to provide up to 4.5 GiB/s throughput per volume. They created a large 50-TiB volume shared across hundreds of compute nodes via NFSv3. They used export policies to restrict access to a specific IP range of the compute cluster. They also set up cross-region replication to replicate results to a different region for collaboration. The main performance consideration was that the compute VMs needed to be on the same Azure region and ideally in the same availability zone to minimize latency. They also used Azure NetApp Files' ability to adjust volume quota dynamically without downtime to increase performance during peak processing. Misconfiguration of the rsize/wsize mount options initially caused poor throughput; after tuning to 65536, performance improved significantly.