Edit

General performance considerations for Azure NetApp Files

Important

This article addresses performance considerations for regular volumes only. For large volumes, see Requirements and considerations for large volumes.

The combination of the quota assigned to the volume and the selected service level determines the throughput limit for a volume with automatic QoS. For volumes with manual QoS, the throughput limit can be defined individually. When you make performance plans about Azure NetApp Files, you need to understand several considerations.

Note

Azure NetApp Files is built on NetApp's bare metal with ONTAP storage OS running inside the Azure datacenter. Azure NetApp Files is a PaaS and does not present the storage efficiencies to the customer, it's transparent and self-managed.

Quota and throughput

Throughput limits are a combination of read and write speed. The throughput limit is only one determinant of the actual performance to be realized.

Typical storage performance considerations contribute to the total performance delivered. The considerations include read and write mix, the transfer size, random or sequential patterns, and many other factors.

Metrics are reported as aggregates of multiple data points collected during a five-minute interval. For more information about metrics aggregation, see Azure Monitor Metrics aggregation and display explained.

The maximum empirical volume throughput observed in testing is 4,500 MiB/s. At the Premium storage tier, an automatic QoS volume quota of 70.31 TiB provisions a throughput limit high enough to achieve this performance level.

For automatic QoS volumes, if you're considering assigning volume quota amounts beyond 70.31 TiB, additional quota may be assigned to a volume for storing more data. However, the added quota doesn't result in a further increase in actual throughput.

The same empirical throughput ceiling applies to volumes with manual QoS. The maximum throughput you should assign to a regular volume is 4,500 MiB/s.

Automatic QoS volume quota and throughput

Learn about quota management and throughput for volumes with the automatic QoS type.

Overprovisioning the volume quota

If a workload’s performance is throughput-limit bound, it's possible to overprovision the automatic QoS volume quota to set a higher throughput level and achieve higher performance.

For example, if an automatic QoS volume in the Premium storage tier has only 500 GiB of data but requires 128 MiB/s of throughput, you can set the quota to 2 TiB so the throughput level is set accordingly (64 MiB/s per TB * 2 TiB = 128 MiB/s).

If you consistently overprovision a volume for achieving a higher throughput, consider using the manual QoS volumes or using a higher service level instead. In this example, you can achieve the same throughput limit with half the automatic QoS volume quota by using the Ultra storage tier instead (128 MiB/s per TiB * 1 TiB = 128 MiB/s).

Dynamically increasing or decreasing volume quota

If your performance requirements are temporary or if you have increased performance needs for a fixed period of time, you can dynamically increase or decrease volume quota to instantaneously adjust the throughput limit. Note the following considerations:

  • Volume quota can be increased or decreased without any need to pause IO, and access to the volume is not interrupted or impacted.

    You can adjust the quota during an active I/O transaction against a volume. Volume quota can never be decreased below the amount of logical data stored in the volume.

  • When volume quota is changed, the corresponding change in throughput limit is nearly instantaneous.

    The change does not interrupt or impact the volume access or I/O.

  • Adjusting volume quota might require a change in capacity pool size.

    The capacity pool size can be adjusted dynamically and without impacting volume availability or I/O.

Manual QoS volume quota and throughput

If you use manual QoS volumes, you don’t have to overprovision the volume quota to achieve a higher throughput because the throughput can be assigned to each volume independently. However, you still need to ensure that the capacity pool is pre-provisioned with sufficient throughput for your performance needs. The throughput of a capacity pool is provisioned according to its size and service level. See Service levels for Azure NetApp Files for more details.

Monitoring volumes for performance

Azure NetApp Files volumes can be monitored using available Performance metrics.

Screenshot providing information about the performance of volumes.

As the graph shows, latency typically stays low and predictable as throughput increases. When a volume approaches its configured QoS throughput limit, latency starts to increase. After the volume throughput limit is reached, the system queues extra I/O requests and latency can rise rapidly while throughput stays capped. This behavior is expected and is a strong indicator that the volume exhausted its available performance headroom rather than experiencing a storage service issue.

To verify this condition, monitor the Throughput limit reached metric. Non-zero values indicate that the volume reached its throughput ceiling. Increasing the volume QoS setting (manual QoS), increasing volume size (automatic QoS), or moving to a higher service level increases the allowable throughput and can reduce latency caused by throughput throttling.

For a comprehensive workflow to identify and isolate latency caused by throughput throttling, cool-tier data retrieval, client-side bottlenecks, network-path issues, and other factors, see Troubleshoot latency issues on Azure NetApp Files volumes.

For more recommendations, see Performance FAQs for Azure NetApp Files.

Volume placement and throughput considerations

For high-throughput workloads, performance planning should consider not only volume-level throughput limits but also workload demand.

Azure NetApp Files volumes are delivered through a shared infrastructure platform with resource allocations designed to deliver predictable performance and scale. When multiple volumes supporting the same application are deployed together, their combined activity can increase demand on shared service resources. This scenario is more likely with sustained, throughput-intensive workloads such as Oracle, SAP HANA, and other large database platforms.

To reduce the risk of backend resource concentration and to optimize workload distribution across the service:

  • Use application volume groups for supported workloads.
  • Use zonal deployment patterns where low latency and predictable placement are required.
  • Monitor volume throughput, latency, and the throughput limit reached metric where applicable.

Application volume groups help improve placement, optimization, and predictability for supported workloads by organizing related volumes by using application-aware deployment rules following best practices.

Next steps