Merge pull request #297352 from wmgries/consistent-media-tiers-1

denrea · web-flow · commit 0d62afc44048 · 2025-03-31T14:37:17.000-07:00
Clean up nfs-performance
diff --git a/articles/storage/files/nfs-large-directories.md b/articles/storage/files/nfs-large-directories.md
@@ -95,7 +95,7 @@ The following graph compares the total time it takes to finish different operati
 :::image type="content" source="media/nfs-large-directories/default-mount-versus-actimeo.png" alt-text="Graph comparing the time to finish different operations with default mount versus setting an actimeo value of 30 for a workload with 1 million files." border="false":::
 
 ### NFS nconnect
-NFS nconnect is a client-side mount option for NFS file shares that allows you to use multiple TCP connections between the client and your NFS file share. We recommend the optimal setting of `nconnect=4` to reduce latency and improve performance. The nconnect feature can be especially useful for workloads that use asynchronous or synchronous I/O from multiple threads. [Learn more](nfs-performance.md#nconnect).
+NFS nconnect is a client-side mount option for NFS file shares that allows you to use multiple TCP connections between the client and your NFS file share. We recommend the optimal setting of `nconnect=4` to reduce latency and improve performance. The nconnect feature can be especially useful for workloads that use asynchronous or synchronous I/O from multiple threads. [Learn more](nfs-performance.md#nfs-nconnect).
 
 ## Commands and operations
 
diff --git a/articles/storage/files/nfs-performance.md b/articles/storage/files/nfs-performance.md
@@ -14,12 +14,18 @@ ms.author: kendownie
 This article explains how you can improve performance for network file system (NFS) Azure file shares.
 
 ## Applies to
-
-| File share type | SMB | NFS |
-|-|:-:|:-:|
-| Standard file shares (GPv2), LRS/ZRS | ![No, this article doesn't apply to standard SMB Azure file shares LRS/ZRS.](../media/icons/no-icon.png) | ![NFS shares are only available in premium Azure file shares.](../media/icons/no-icon.png) |
-| Standard file shares (GPv2), GRS/GZRS | ![No, this article doesn't apply to standard SMB Azure file shares GRS/GZRS.](../media/icons/no-icon.png) | ![NFS is only available in premium Azure file shares.](../media/icons/no-icon.png) |
-| Premium file shares (FileStorage), LRS/ZRS | ![No, this article doesn't apply to premium SMB Azure file shares.](../media/icons/no-icon.png) | ![Yes, this article applies to premium NFS Azure file shares.](../media/icons/yes-icon.png) |
+| Management model | Billing model | Media tier | Redundancy | SMB | NFS |
+|-|-|-|-|:-:|:-:|
+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Local (LRS) | ![No](../media/icons/no-icon.png) | ![No](../media/icons/no-icon.png) |
+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Zone (ZRS) | ![No](../media/icons/no-icon.png) | ![No](../media/icons/no-icon.png) |
+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Geo (GRS) | ![No](../media/icons/no-icon.png) | ![No](../media/icons/no-icon.png) |
+| Microsoft.Storage | Provisioned v2 | HDD (standard) | GeoZone (GZRS) | ![No](../media/icons/no-icon.png) | ![No](../media/icons/no-icon.png) |
+| Microsoft.Storage | Provisioned v1 | SSD (premium) | Local (LRS) | ![No](../media/icons/no-icon.png) | ![Yes](../media/icons/yes-icon.png) |
+| Microsoft.Storage | Provisioned v1 | SSD (premium) | Zone (ZRS) | ![No](../media/icons/no-icon.png) | ![Yes](../media/icons/yes-icon.png) |
+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Local (LRS) | ![No](../media/icons/no-icon.png) | ![No](../media/icons/no-icon.png) |
+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Zone (ZRS) | ![No](../media/icons/no-icon.png) | ![No](../media/icons/no-icon.png) |
+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Geo (GRS) | ![No](../media/icons/no-icon.png) | ![No](../media/icons/no-icon.png) |
+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | GeoZone (GZRS) | ![No](../media/icons/no-icon.png) | ![No](../media/icons/no-icon.png) |
 
 ## Increase read-ahead size to improve read throughput
 
@@ -46,41 +52,39 @@ To change this value, set the read-ahead size by adding a rule in udev, a Linux
    sudo udevadm control --reload
    ```
 
-## `Nconnect`
-
-`Nconnect` is a client-side Linux mount option that increases performance at scale by allowing you to use more Transmission Control Protocol (TCP) connections between the client and the Azure Premium Files service for NFSv4.1.
+## NFS nconnect
+NFS nconnect is a client-side mount option for NFS file shares that allows you to use multiple TCP connections between the client and your NFS file share. 
 
-### Benefits of `nconnect`
+### Benefits
 
-With `nconnect`, you can increase performance at scale using fewer client machines to reduce total cost of ownership (TCO). `Nconnect` increases performance by using multiple TCP channels on one or more NICs, using single or multiple clients. Without `nconnect`, you'd need roughly 20 client machines in order to achieve the bandwidth scale limits (10 GiB/s) offered by the largest premium Azure file share provisioning size.  With `nconnect`, you can achieve those limits using only 6-7 clients, reducing compute costs by nearly 70% while providing significant improvements in I/O operations per second (IOPS) and throughput at scale. See the following table.
+With nconnect, you can increase performance at scale using fewer client machines to reduce total cost of ownership (TCO). The nconnect feature increases performance by using multiple TCP channels on one or more NICs, using single or multiple clients. Without nconnect, you'd need roughly 20 client machines in order to achieve the bandwidth scale limits (10 GiB / sec) offered by the largest SSD file share provisioning size. With nconnect, you can achieve those limits using only 6-7 clients, reducing compute costs by nearly 70% while providing significant improvements in I/O operations per second (IOPS) and throughput at scale. See the following table.
 
 | **Metric (operation)** | **I/O size**  | **Performance improvement** |
-|------------------------|---------------|-----------------------------|
-| IOPS (write)           | 64K, 1024K    | 3x                          |
-| IOPS (read)            | All I/O sizes | 2-4x                        |
-| Throughput (write)     | 64K, 1024K    | 3x                          |
-| Throughput (read)      | All I/O sizes | 2-4x                        |
+|-|-|-|
+| IOPS (write) | 64 KiB, 1,024 KiB | 3x |
+| IOPS (read) | All I/O sizes | 2-4x |
+| Throughput (write) | 64 KiB, 1,024 KiB | 3x |
+| Throughput (read) | All I/O sizes | 2-4x |
 
 ### Prerequisites
 
-- The latest Linux distributions fully support `nconnect`. For older Linux distributions, ensure that the Linux kernel version is 5.3 or higher.
+- The latest Linux distributions fully support nconnect. For older Linux distributions, ensure that the Linux kernel version is 5.3 or higher.
 - Per-mount configuration is only supported when a single file share is used per storage account over a private endpoint.
 
-### Performance impact of `nconnect`
+### Performance impact
 
-We achieved the following performance results when using the `nconnect` mount option with NFS Azure file shares on Linux clients at scale. For more information on how we achieved these results, see [performance test configuration](#performance-test-configuration).
+We achieved the following performance results when using the nconnect mount option with NFS Azure file shares on Linux clients at scale. For more information on how we achieved these results, see [performance test configuration](#performance-test-configuration).
 
 :::image type="content" source="media/nfs-performance/nconnect-iops-improvement.png" alt-text="Screenshot showing average improvement in IOPS when using nconnect with NFS Azure file shares." border="false":::
 
 :::image type="content" source="media/nfs-performance/nconnect-throughput-improvement.png" alt-text="Screenshot showing average improvement in throughput when using nconnect with NFS Azure file shares." border="false":::
 
-### Recommendations for `nconnect`
-
+### Recommendations
 Follow these recommendations to get the best results from `nconnect`.
 
 #### Set `nconnect=4`
 
-While Azure Files supports setting `nconnect` up to the maximum setting of 16, we recommend configuring the mount options with the optimal setting of `nconnect=4`. Currently, there are no gains beyond four channels for the Azure Files implementation of `nconnect`. In fact, exceeding four channels to a single Azure file share from a single client might adversely affect performance due to TCP network saturation.
+While Azure Files supports setting nconnect up to the maximum setting of 16, we recommend configuring the mount options with the optimal setting of nconnect=4. Currently, there are no gains beyond four channels for the Azure Files implementation of nconnect. In fact, exceeding four channels to a single Azure file share from a single client might adversely affect performance due to TCP network saturation.
 
 #### Size virtual machines carefully
 
@@ -90,18 +94,18 @@ Depending on your workload requirements, it's important to correctly size the cl
 
 Queue depth is the number of pending I/O requests that a storage resource can service. We don't recommend exceeding the optimal queue depth of 64 because you won't see any more performance gains. For more information, see [Queue depth](understand-performance.md#queue-depth).
 
-### `Nconnect` per-mount configuration
+### Per mount configuration
 
-If a workload requires mounting multiple shares with one or more storage accounts with different `nconnect` settings from a single client, we can't guarantee that those settings will persist when mounting over the public endpoint. Per-mount configuration is only supported when a single Azure file share is used per storage account over the private endpoint as described in Scenario 1.
+If a workload requires mounting multiple shares with one or more storage accounts with different nconnect settings from a single client, we can't guarantee that those settings persist when mounting over the public endpoint. Per mount configuration is only supported when a single Azure file share is used per storage account over the private endpoint as described in Scenario 1.
 
-#### Scenario 1: `nconnect` per-mount configuration over private endpoint with multiple storage accounts (supported)
+#### Scenario 1: per mount configuration over private endpoint with multiple storage accounts (supported)
 
 - StorageAccount.file.core.windows.net = 10.10.10.10
 - StorageAccount2.file.core.windows.net = 10.10.10.11
   - `Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4`
   - `Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1`
 
-#### Scenario 2: `nconnect` per-mount configuration over public endpoint (not supported)
+#### Scenario 2: per mount configuration over public endpoint (not supported)
 
 - StorageAccount.file.core.windows.net = 52.239.238.8
 - StorageAccount2.file.core.windows.net = 52.239.238.7
@@ -110,9 +114,9 @@ If a workload requires mounting multiple shares with one or more storage account
   - `Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1`
 
 > [!NOTE]
-> Even if the storage account resolves to a different IP address, we can't guarantee that address will persist because public endpoints aren't static addresses.
+> Even if the storage account resolves to a different IP address, we can't guarantee that address persist because public endpoints aren't static addresses.
 
-#### Scenario 3: `nconnect` per-mount configuration over private endpoint with multiple shares on single storage account (not supported)
+#### Scenario 3: per mount configuration over private endpoint with multiple shares on single storage account (not supported)
 
 - StorageAccount.file.core.windows.net = 10.10.10.10
   - `Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4`
@@ -125,7 +129,7 @@ We used the following resources and benchmarking tools to achieve and measure th
 
 - **Single client:** Azure VM ([DSv4-Series](/azure/virtual-machines/dv4-dsv4-series#dsv4-series)) with single NIC
 - **OS:** Linux (Ubuntu 20.40)
-- **NFS storage:** Azure Files premium file share (provisioned 30 TiB, set `nconnect=4`)
+- **NFS storage:** SSD file share (provisioned 30 TiB, set `nconnect=4`)
 
 | **Size**        | **vCPU**  | **Memory** | **Temp storage (SSD)** | **Max data disks** | **Max NICs** | **Expected network bandwidth** |
 |-----------------|-----------|------------|------------------------|--------------------|--------------|--------------------------------|
@@ -153,41 +157,41 @@ fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_b
 
 #### High throughput: 100% reads
 
-**64k I/O size - random read - 64 queue depth**
+**64 KiB I/O size - random read - 64 queue depth**
 
 ```bash
 fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300
 ```
 
-**1024k I/O size - 100% random read - 64 queue depth**
+**1,024 KiB I/O size - 100% random read - 64 queue depth**
 
 ```bash
 fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300
 ```
 
 #### High IOPS: 100% writes
 
-**4k I/O size - 100% random write - 64 queue depth**
+**4 KiB I/O size - 100% random write - 64 queue depth**
 
 ```bash
 fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300
 ```
 
-**8k I/O size - 100% random write - 64 queue depth**
+**8 KiB I/O size - 100% random write - 64 queue depth**
 
 ```bash
 fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300
 ```
 
 #### High throughput: 100% writes
 
-**64k I/O size  - 100% random write - 64 queue depth**
+**64 KiB I/O size  - 100% random write - 64 queue depth**
 
 ```bash
 fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300
 ```
 
-**1024k I/O size  - 100% random write - 64 queue depth**
+**1024 KiB I/O size  - 100% random write - 64 queue depth**
 
 ```bash
 fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300
diff --git a/articles/storage/files/storage-files-how-to-mount-nfs-shares.md b/articles/storage/files/storage-files-how-to-mount-nfs-shares.md
@@ -69,7 +69,7 @@ You can mount the share using the Azure portal. You can also create a record in
 
 ### Mount an NFS share using the Azure portal
 
-You can use the `nconnect` Linux mount option to improve performance for NFS Azure file shares at scale. For more information, see [Improve NFS Azure file share performance](nfs-performance.md#nconnect).
+You can use the `nconnect` Linux mount option to improve performance for NFS Azure file shares at scale. For more information, see [Improve NFS Azure file share performance](nfs-performance.md#nfs-nconnect).
 
 1. Once the file share is created, select the share and select **Connect from Linux**.
 1. Enter the mount path you'd like to use, then copy the script.
diff --git a/articles/storage/files/storage-files-migration-nfs.md b/articles/storage/files/storage-files-migration-nfs.md
@@ -26,7 +26,7 @@ This article covers the basic aspects of migrating from Linux file servers to NF
 
 ## Prerequisites
 
-You'll need at least one NFS Azure file share mounted to a Linux virtual machine (VM). To create one, see [Create an NFS Azure file share and mount it on a Linux VM](storage-files-quick-create-use-linux.md). We recommend mounting the share with nconnect to use multiple TCP connections. For more information, see [Improve NFS Azure file share performance](nfs-performance.md#nconnect).
+You'll need at least one NFS Azure file share mounted to a Linux virtual machine (VM). To create one, see [Create an NFS Azure file share and mount it on a Linux VM](storage-files-quick-create-use-linux.md). We recommend mounting the share with nconnect to use multiple TCP connections. For more information, see [Improve NFS Azure file share performance](nfs-performance.md#nfs-nconnect).
 
 ## Migration tools
 
diff --git a/articles/storage/files/storage-snapshots-files.md b/articles/storage/files/storage-snapshots-files.md
@@ -368,7 +368,7 @@ az storage share list --account-name <storage-account-name> --include-snapshots
 
 To mount an NFS Azure file share snapshot to a Linux VM (NFS client) and restore files, follow these steps.
 
-1. Run the following command in a console. See [Mount options](storage-files-how-to-mount-nfs-shares.md#mount-options) for other recommended mount options. To improve copy performance, mount the snapshot with [nconnect](nfs-performance.md#nconnect) to use multiple TCP channels.
+1. Run the following command in a console. See [Mount options](storage-files-how-to-mount-nfs-shares.md#mount-options) for other recommended mount options. To improve copy performance, mount the snapshot with [nconnect](nfs-performance.md#nfs-nconnect) to use multiple TCP channels.
    
    ```bash
    sudo mount -o vers=4,minorversion=1,proto=tcp,sec=sys $server:/nfs4account/share /media/nfs
