Merge pull request #285430 from b-ahibbard/cool-access-performance

Cool access performance

Author: Stacyrch140

articles/azure-netapp-files/TOC.yml

@@ -111,6 +111,8 @@
       href: performance-large-volumes-linux.md
     - name: Performance impact of Kerberos on NFSv4.1
       href: performance-impact-kerberos.md
+    - name: Performance considerations for cool access 
+      href: performance-considerations-cool-access.md
     - name: Oracle database performance on Azure NetApp Files single volumes
       href: performance-oracle-single-volumes.md
     - name: Oracle database performance on Azure NetApp Files multiple volumes

articles/azure-netapp-files/azure-netapp-files-service-levels.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-hchen
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 08/20/2024
+ms.date: 09/05/2024
 ms.author: anfdocs
 ---
 # Service levels for Azure NetApp Files
@@ -25,7 +25,7 @@ Azure NetApp Files supports three service levels: *Ultra*, *Premium*, and *Stand
     The Ultra service level provides up to 128 MiB/s of throughput per 1 TiB of capacity provisioned. 
 
 * Storage with cool access:      
-    Cool access storage is available with the Standard, Premium, and Ultra service levels. The throughput experience for any of these service levels with cool access is the same for cool access as it is for data in the hot tier. It may differ when data that resides in the cool tier is accessed. For more information, see [Azure NetApp Files storage with cool access](cool-access-introduction.md#effects-of-cool-access-on-data). 
+    Cool access storage is available with the Standard, Premium, and Ultra service levels. The throughput experience for any of these service levels with cool access is the same for cool access as it is for data in the hot tier. It may differ when data that resides in the cool tier is accessed. For more information, see [Azure NetApp Files storage with cool access](cool-access-introduction.md) and [Performance considerations for storage with cool access](performance-considerations-cool-access.md). 
 
 ## Throughput limits
 

articles/azure-netapp-files/cool-access-introduction.md

@@ -79,83 +79,6 @@ Azure NetApp Files storage with cool access is supported for the following regio
 * West US 2
 * West US 3
 
-## Effects of cool access on data
-
-This section describes a large-duration, large-dataset warming test. It shows an example scenario of a dataset where 100% of the data is in the cool tier and how it warms over time.   
-
-Typical randomly accessed data starts as part of a working set (read, modify, and write). As data loses relevance, it becomes "cool" and is eventually tiered off to the cool tier.  
-
-Cool data might become hot again. It’s not typical for the entire working set to start as cold, but some scenarios do exist, for example, audits, year-end processing, quarter-end processing, lawsuits, and end-of-year licensure reviews.  
-
-This scenario provides insight to the warming performance behavior of a 100% cooled dataset. The insight applies whether it's a small percentage or the entire dataset.
-
-### 4k random-read test
-
-This section describes a 4k random-read test across 160 files totaling 10 TB of data.   
-
-#### Setup 
-
-**Capacity pool size:** 100-TB capacity pool <br>
-**Volume allocated capacity:** 100-TB volumes <br>
-**Working Dataset:** 10 TB <br>
-**Service Level:** Standard storage with cool access <br>
-**Volume Count/Size:** 1 <br>
-**Client Count:** Four standard 8-s clients <br>
-**OS:** RHEL 8.3 <br>
-**Mount Option:** `rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg,hard`
-
-#### Methodology
-
-This test was set up via FIO to run a 4k random-read test across 160 files that total 10 TB of data. FIO was configured to randomly read each block across the entire working dataset. (It can read any block any number of times as part of the test instead of touching each block once). This script was called once every 5 minutes and then a data point collected on performance. When blocks are randomly read, they're moved to the hot tier.
-
-This test had a large dataset and ran several days starting the worst-case most-aged data (all caches dumped). The time component of the X axis has been removed because the total time to rewarm varies due to the dataset size. This curve could be in days, hours, minutes, or even seconds depending on the dataset. 
-
-#### Results
-
-The following chart shows a test that ran over 2.5 days on the 10-TB working dataset that has been 100% cooled and the buffers cleared (absolute worst-case aged data). 
-
-:::image type="content" source="./media/cool-access-introduction/cool-access-test-chart.png" alt-text="Diagram that shows cool access read IOPS warming cooled tier, long duration, and 10-TB working set. The y-axis is titled IOPS, ranging from 0 to 140,000 in increments of 20,000. The x-axis is titled Behavior Over Time. A line charting Read IOPs is roughly flat until the right-most third of the x-axis where growth is exponential." lightbox="./media/cool-access-introduction/cool-access-test-chart.png"::: 
-
-### 64k sequential-read test
-
-#### Setup 
-
-**Capacity pool size:** 100-TB capacity pool <br>
-**Volume allocated capacity:** 100-TB volumes <br>
-**Working Dataset:** 10 TB <br>
-**Service Level:** Standard storage with cool access <br>
-**Volume Count/Size:** 1 <br>
-**Client Count:** One large client <br>
-**OS:** RHEL 8.3 <br>
-**Mount Option:** `rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg,hard` <br>
-
-#### Methodology
-
-Sequentially read blocks aren't rewarmed to the hot tier. However, small dataset sizes might see performance improvements because of caching (no performance change guarantees). 
- 
-This test provides the following data points: 
-* 100% hot tier dataset 
-* 100% cool tier dataset 
-
-This test ran for 30 minutes to obtain a stable performance number.  
-
-#### Results
-
-The following table summarizes the test results: 
-
-| 64-k sequential | Read throughput | 
-|-|-|
-| Hot data | 1,683 MB/s |
-| Cool data | 899 MB/s |
-
-### Test conclusions 
-
-Data read from the cool tier experiences a performance hit. If you size your time to cool off correctly, then you might not experience a performance hit at all. You might have little cool tier access, and a 30-day window is perfect for keeping warm data warm.
-
-You should avoid a situation that churns blocks between the hot tier and the cool tier. For instance, you set a workload for data to cool seven days, and you randomly read a large percentage of the dataset every 11 days.
-
-In summary, if your working set is predictable, you can save cost by moving infrequently accessed data blocks to the cool tier. The 7 to 30 day wait range before cooling provides a large window for working sets that are rarely accessed after they're dormant or don't require the hot-tier speeds when they're accessed.
-
 ## Metrics 
 
 Cool access offers [performance metrics](azure-netapp-files-metrics.md#cool-access-metrics) to understand usage patterns on a per volume basis: 
@@ -335,3 +258,4 @@ Your first twelve-month savings:
 
 * [Manage Azure NetApp Files storage with cool access](manage-cool-access.md)
 * [Metrics for Azure NetApp Files](azure-netapp-files-metrics.md)
+* [Performance considerations for Azure NetApp Files storage with cool access](performance-considerations-cool-access.md)

articles/azure-netapp-files/manage-cool-access.md

@@ -126,13 +126,13 @@ Azure NetApp Files storage with cool access can be enabled during the creation o
 
         * *Cool access is **enabled***:  
             * If no value is set for cool access retrieval policy:  
-                The retrieval policy will be set to `Default`, and cold data will be retrieved to the hot tier only when performing random reads. Sequential reads will be served directly from the cool tier.
+                The retrieval policy  set to `Default`. Cool data is only retrieved to the hot tier only when performing random reads. Sequential reads are served directly from the cool tier.
             * If cool access retrieval policy is set to `Default`:   
-                Cold data will be retrieved only by performing random reads.
+                Cold data is retrieved only by performing random reads.
             * If cool access retrieval policy is set to `On-Read`:   
-                Cold data will be retrieved by performing both sequential and random reads.
+                Cold data is retrieved by performing both sequential and random reads.
             * If cool access retrieval policy is set to `Never`:   
-                Cold data is served directly from the cool tier and not be retrieved to the hot tier.
+                Cold data is served directly from the cool tier and not retrieved to the hot tier.
         * *Cool access is **disabled**:*     
             * You can set a cool access retrieval policy if cool access is disabled only if there's existing data on the cool tier. 
             * Once you disable the cool access setting on the volume, the cool access retrieval policy remains the same.    
@@ -151,7 +151,7 @@ In a cool-access enabled capacity pool, you can enable an existing volume to sup
 1. Right-click the volume for which you want to enable the cool access. 
 1. In the **Edit** window that appears, set the following options for the volume: 
     * **Enable Cool Access**  
-        This option specifies whether the volume will support cool access. 
+        This option specifies whether the volume supports cool access. 
     * **Coolness Period**  
         This option specifies the period (in days) after which infrequently accessed data blocks (cold data blocks) are moved to the Azure storage account. The default value is 31 days. The supported values are between 2 and 183 days. 
     * **Cool Access Retrieval Policy**   
@@ -185,3 +185,4 @@ Based on the client read/write patterns, you can modify the cool access configur
 
 ## Next steps
 * [Azure NetApp Files storage with cool access](cool-access-introduction.md)
+* [Performance considerations for Azure NetApp Files storage with cool access](performance-considerations-cool-access.md)