Skip to content

Commit 303ef82

Browse files
committed
replace images
1 parent 036d7d9 commit 303ef82

File tree

5 files changed

+18
-18
lines changed

5 files changed

+18
-18
lines changed
-19.9 KB
Loading
-41.1 KB
Loading
-37.7 KB
Loading
-26.4 KB
Loading

articles/azure-netapp-files/volume-hard-quota-guidelines.md

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -5,15 +5,15 @@ services: azure-netapp-files
55
author: b-hchen
66
ms.service: azure-netapp-files
77
ms.topic: conceptual
8-
ms.date: 09/30/2022
8+
ms.date: 11/26/2024
99
ms.author: anfdocs
1010
---
1111
# What changing to volume hard quota means for your Azure NetApp Files service
1212

1313
From the beginning of the service, Azure NetApp Files has been using a capacity-pool provisioning and automatic growth mechanism. Azure NetApp Files volumes are thinly provisioned on an underlying, customer-provisioned capacity pool of a selected tier and size. Volume sizes (quotas) are used to provide performance and capacity, and the quotas can be adjusted on-the-fly at any time. This behavior means that, currently, the volume quota is a performance lever used to control bandwidth to the volume. Currently, underlaying capacity pools automatically grow when the capacity fills up.
1414

1515
> [!IMPORTANT]
16-
> The Azure NetApp Files behavior of volume and capacity pool provisioning will change to a *manual* and *controllable* mechanism. **Starting from April 30, 2021 (updated), volume sizes (quota) will manage bandwidth performance, as well as provisioned capacity, and underlying capacity pools will no longer grow automatically.**
16+
> The Azure NetApp Files behavior of volume and capacity pool provisioning is a *manual* and *controllable* mechanism. **From April 30, 2021, volume sizes (quota) manage bandwidth performance, as well as provisioned capacity. Underlying capacity pools don't grow automatically.**
1717
1818
## Reasons for the change to volume hard quota
1919

@@ -26,7 +26,7 @@ Many customers have requested direct control over provisioned capacity. They wan
2626

2727
## What is the volume hard quota change
2828

29-
With the volume hard quota change, Azure NetApp Files volumes are no longer thinly provisioned at (the maximum) 100 TiB. The volumes will be provisioned at the actual configured size (quota). Also, the underlying capacity pools will no longer automatically grow upon reaching full-capacity consumption. This change will reflect the behavior like Azure managed disks, which are also provisioned as-is, without automatic capacity increase.
29+
With the volume hard quota change, Azure NetApp Files volumes are no longer thinly provisioned at (the maximum) 100 TiB. The volumes are provisioned at the actual configured size (quota). Also, the underlying capacity pools no longer automatically grow upon reaching full-capacity consumption. This change reflects the behavior like Azure managed disks, which are also provisioned as-is, without automatic capacity increase.
3030

3131
For example, consider an Azure NetApp Files volume configured at 1-TiB size (quota) on a 4-TiB Ultra service level capacity pool. An application is continuously writing data to the volume.
3232

@@ -40,23 +40,23 @@ The *initial* behavior:
4040
The *changed* behavior:
4141
* Expected bandwidth: 128 MiB/s
4242
* Total usable (and client visible) capacity: 1 TiB
43-
You will not be able to write more data on the volume beyond this size.
43+
You're not able to write more data on the volume beyond this size.
4444
* Capacity pool: Remains 4 TiB in size and doesn't automatically grow.
4545
* Volume quota change: Changes performance (bandwidth) and client visible or usable capacity of the volume.
4646

47-
You need to proactively monitor the utilization of Azure NetApp Files volumes and capacity pools. You need to purposely change the volume and pool utilization for close-to-full consumption. Azure NetApp Files will continue to allow for [on-the-fly volume and capacity pool resize operations](azure-netapp-files-resize-capacity-pools-or-volumes.md).
47+
You need to proactively monitor the utilization of Azure NetApp Files volumes and capacity pools. You need to purposely change the volume and pool utilization for close-to-full consumption. Azure NetApp Files continues to allow for [on-the-fly volume and capacity pool resize operations](azure-netapp-files-resize-capacity-pools-or-volumes.md).
4848

4949
## How to operationalize the volume hard quota change
5050

5151
This section provides guidance on how to operationalize the change to volume hard quota for a smooth transition. It also provides insights for handling currently provisioned volumes and capacity pools, ongoing monitoring, and alerting and capacity management options.
5252

5353
### Currently provisioned volumes and capacity pools
5454

55-
Because of the volume hard quota change, you should change your operating model. The provisioned volumes and capacity pools will require ongoing capacity management. Because the changed behavior will happen instantly, the Azure NetApp Files team recommends a series of one-time corrective measures for existing, previously provisioned volumes and capacity pools, as described in this section.
55+
Because of the volume hard quota change, you should change your operating model. The provisioned volumes and capacity pools require ongoing capacity management. Because the changed behavior happen instantly, the Azure NetApp Files team recommends a series of one-time corrective measures for existing, previously provisioned volumes and capacity pools, as described in this section.
5656

5757
#### One-time corrective or preventative measures recommendations
5858

59-
The volume hard quota change will result in changes in provisioned and available capacity for previously provisioned volumes and pools. As a result, some capacity allocation challenges might happen. To avoid short-term out-of-space situations for customers, the Azure NetApp Files team recommends the following, one-time corrective/preventative measures:
59+
The volume hard quota change resulted in changes in provisioned and available capacity for previously provisioned volumes and pools. As a result, some capacity allocation challenges might happen. To avoid short-term out-of-space situations for customers, the Azure NetApp Files team recommends the following, one-time corrective/preventative measures:
6060

6161
* **Provisioned volume sizes**:
6262
Resize every provisioned volume to have appropriate buffer based on change rate and alerting or resize turnaround time (for example, 20% based on typical workload considerations), with a maximum of 100 TiB (which is the regular [volume size limit](azure-netapp-files-resource-limits.md#resource-limits). This new volume size, including buffer capacity, should be based on the following factors:
@@ -79,7 +79,7 @@ You can monitor capacity utilization at various levels.
7979

8080
#### VM-level monitoring
8181

82-
The highest level of monitoring (closest to the application) is from within the application virtual machine. You will observe a change in behavior in capacity reporting from within the VM client OS.
82+
The highest level of monitoring (closest to the application) is from within the application virtual machine. This results in an observable change in behavior in capacity reporting from within the VM client OS.
8383

8484
In the following two scenarios, consider an Azure NetApp Files volume configured at 1-TiB size (quota) on a 4-TiB, Ultra service-level capacity pool.
8585

@@ -105,7 +105,7 @@ The following example shows the `dir` command output:
105105

106106
##### Linux
107107

108-
Linux clients can check the used and available capacity of a volume by using the [`df` command](https://linux.die.net/man/1/df). The `-h` option will show the size, used space, and available space in human-readable format, using M, G, and T unit sizes.
108+
Linux clients can check the used and available capacity of a volume by using the [`df` command](https://linux.die.net/man/1/df). The `-h` option shows the size, used space, and available space in human-readable format, using M, G, and T unit sizes.
109109

110110
The following example shows volume capacity reporting in Linux *before* the changed behavior:
111111

@@ -130,13 +130,13 @@ You can configure the following key alerting settings:
130130

131131
* **Capacity Pool % Full Threshold** - This setting determines the consumed threshold that triggers an alert for capacity pools. A value of 90 would cause an alert to be triggered when the capacity pool reaches 90% consumed.
132132
* **Volume % Full Threshold** - This setting determines the consumed threshold that triggers an alert for volumes. A value of 80 would cause an alert to be triggered when the volume reaches 80% consumed.
133-
* **Existing Action Group for Capacity Notifications** - This setting is the action group that will be triggered for capacity-based alerting. This setting should be pre-created by you. The action group can send email, SMS, or other formats.
133+
* **Existing Action Group for Capacity Notifications** - This setting is the action group triggered for capacity-based alerting. This setting should be pre-created by you. The action group can send email, SMS, or other formats.
134134

135135
The following illustration shows the alert configuration:
136136

137137
![Illustration that shows alert configuration by using ANFCapacityManager.](./media/volume-hard-quota-guidelines/hard-quota-anfcapacitymanager-configuration.png)
138138

139-
After installing ANFCapacityManager, you can expect the following behavior: When an Azure NetApp Files capacity pool or volume is created, modified, or deleted, the Logic App will automatically create, modify, or delete a capacity-based Metric Alert rule with the name `ANF_Pool_poolname` or `ANF_Volume_poolname_volname`.
139+
After installing ANFCapacityManager, you can expect the following behavior: When an Azure NetApp Files capacity pool or volume is created, modified, or deleted, the Logic App automatically creates, modifies, or deletes a capacity-based Metric Alert rule with the name `ANF_Pool_poolname` or `ANF_Volume_poolname_volname`.
140140

141141
### Manage capacity
142142

@@ -180,7 +180,7 @@ To manage Azure NetApp Files resources using Azure CLI, you can open the Azure p
180180

181181
[ ![Screenshot that shows how to access Cloud Shell link.](./media/volume-hard-quota-guidelines/hard-quota-update-cloud-shell-link.png) ](./media/volume-hard-quota-guidelines/hard-quota-update-cloud-shell-link.png#lightbox)
182182

183-
This action will open the Azure Cloud Shell:
183+
This action opens the Azure Cloud Shell:
184184

185185
[ ![Screenshot that shows Cloud Shell window.](./media/volume-hard-quota-guidelines/hard-quota-update-cloud-shell-window.png) ](./media/volume-hard-quota-guidelines/hard-quota-update-cloud-shell-window.png#lightbox)
186186

@@ -216,12 +216,12 @@ See [Develop for Azure NetApp Files with REST API using PowerShell](develop-rest
216216

217217
ANFCapacityManager is an Azure Logic App that manages capacity-based alert rules. It automatically increases volume sizes to prevent your Azure NetApp Files volumes from running out of space. In addition to sending alerts, it can enable the automatic increase of volume and capacity pool sizes to prevent your Azure NetApp Files volumes from running out of space:
218218

219-
* Optionally, when an Azure NetApp Files Volume reaches the specified percent consumed threshold, the volume quota (size) will be increased by the percent specified between 10-100.
220-
* If increasing the volume size exceeds the capacity of the containing capacity pool, the capacity pool size will also be increased to accommodate the new volume size.
219+
* Optionally, when an Azure NetApp Files Volume reaches the specified percent consumed threshold, the volume quota (size) increases by the percent specified between 10-100.
220+
* If increasing the volume size exceeds the capacity of the containing capacity pool, the capacity pool size also increases to accommodate the new volume size.
221221

222222
You can configure the following key capacity management setting:
223223

224-
* **AutoGrow Percent Increase** - Percent of the existing volume size to automatically grow a volume if it reaches the specified **% Full Threshold**. A value of 0 (zero) will disable the AutoGrow feature. A value between 10 and 100 is recommended.
224+
* **AutoGrow Percent Increase** - Percent of the existing volume size to automatically grow a volume if it reaches the specified **% Full Threshold**. A value of 0 (zero) disables the AutoGrow feature. A value between 10 and 100 is recommended.
225225

226226
![Screenshot that shows Set Volume Auto Growth Percent window.](./media/volume-hard-quota-guidelines/hard-quota-volume-anfcapacitymanager-auto-grow-percent.png)
227227

@@ -236,17 +236,17 @@ Yes, the consumed snapshot capacity counts towards the provisioned space in the
236236
* Resize the volume as described in this article.
237237
* Remove older snapshots to free up space in the hosting volume.
238238

239-
### Does this change mean the volume auto-grow behavior will disappear from Azure NetApp Files?
239+
### Does this change mean the volume auto-grow behavior disappears from Azure NetApp Files?
240240

241-
A common misconception is that Azure NetApp Files *volumes* would automatically grow upon filling up. Volumes were thinly provisioned with a size of 100 TiB, regardless of the actual set quota, while the underlaying *capacity pool* would automatically grow with 1-TiB increments. This change will address the (visible and usable) *volume* size to the set quota, and *capacity pools* will no longer automatically grow. This change results in commonly desired accurate client-side space and capacity reporting. It avoids "runaway" capacity consumption.
241+
A common misconception is that Azure NetApp Files *volumes* would automatically grow upon filling up. Volumes were thinly provisioned with a size of 100 TiB, regardless of the actual set quota, while the underlaying *capacity pool* would automatically grow with 1-TiB increments. This change addresses the (visible and usable) *volume* size to the set quota, and *capacity pools* thus no longer automatically grow. This change results in commonly desired accurate client-side space and capacity reporting. It avoids "runaway" capacity consumption.
242242

243243
### Does this change have any effect on volumes replicated with cross-region-replication (preview)?
244244

245245
The hard volume quota isn't enforced on replication destination volumes.
246246

247247
### Does this change have any effect on metrics currently available in Azure Monitor?
248248

249-
Portal metrics and Azure Monitor statistics will accurately reflect the new allocation and utilization model.
249+
Portal metrics and Azure Monitor statistics accurately reflect the new allocation and utilization model.
250250

251251
### Does this change have any effect on the resource limits for Azure NetApp Files?
252252

0 commit comments

Comments
 (0)