Azure NetApp Files Configuration¶
Note
The Azure NetApp Files service does not support volumes less than 100 GB in size. To make it easier to deploy applications, Trident automatically creates 100 GB volumes if a smaller volume is requested.
Preparation¶
To configure and use an Azure NetApp Files backend, you will need:
subscriptionID
from an Azure subscription with Azure NetApp Files enabledtenantID
,clientID
, andclientSecret
from an App Registration in Azure Active Directory with sufficient permissions to the Azure NetApp Files service- Azure
location
that contains at least one delegated subnet
If you’re using Azure NetApp Files for the first time or in a new location, some initial configuration is required that the quickstart guide will walk you through.
Backend configuration options¶
Parameter | Description | Default |
---|---|---|
version | Always 1 | |
storageDriverName | “azure-netapp-files” | |
backendName | Custom name for the storage backend | Driver name + “_” + random characters |
subscriptionID | The subscription ID from your Azure subscription | |
tenantID | The tenant ID from an App Registration | |
clientID | The client ID from an App Registration | |
clientSecret | The client secret from an App Registration | |
serviceLevel | One of “Standard”, “Premium” or “Ultra” | “” (random) |
location | Name of the Azure location new volumes will be created in | “” (random) |
virtualNetwork | Name of a virtual network with a delegated subnet | “” (random) |
subnet | Name of a subnet delegated to Microsoft.Netapp/volumes |
“” (random) |
nfsMountOptions | Fine-grained control of NFS mount options | “-o nfsvers=3” |
limitVolumeSize | Fail provisioning if requested volume size is above this value | “” (not enforced by default) |
You can control how each volume is provisioned by default using these options in a special section of the configuration. For an example, see the configuration examples below.
Parameter | Description | Default |
---|---|---|
exportRule | The export rule(s) for new volumes | “0.0.0.0/0” |
size | The default size of new volumes | “100G” |
The exportRule
value must be a comma-separated list of any combination of IPv4 addresses or IPv4 subnets in CIDR
notation.
Example Configurations¶
Example 1 - Minimal backend configuration for azure-netapp-files
This is the absolute minimum backend configuration. With this Trident will discover all of your NetApp accounts, capacity pools, and subnets delegated to ANF in every location worldwide, and place new volumes on one of them randomly.
This configuration is useful when you’re just getting started with ANF and trying things out, but in practice you’re going to want to provide additional scoping for the volumes you provision in order to make sure that they have the characteristics you want and end up on a network that’s close to the compute that’s using it. See the subsequent examples for more details.
{
"version": 1,
"storageDriverName": "azure-netapp-files",
"subscriptionID": "9f87c765-4774-fake-ae98-a721add45451",
"tenantID": "68e4f836-edc1-fake-bff9-b2d865ee56cf",
"clientID": "dd043f63-bf8e-fake-8076-8de91e5713aa",
"clientSecret": "SECRET"
}
Example 2 - Single location and specific service level for azure-netapp-files
This backend configuration will place volumes in Azure’s “eastus” location in a “Premium” capacity pool. Trident automatically discovers all of the subnets delegated to ANF in that location and will place a new volume on one of them randomly.
{
"version": 1,
"storageDriverName": "azure-netapp-files",
"subscriptionID": "9f87c765-4774-fake-ae98-a721add45451",
"tenantID": "68e4f836-edc1-fake-bff9-b2d865ee56cf",
"clientID": "dd043f63-bf8e-fake-8076-8de91e5713aa",
"clientSecret": "SECRET",
"location": "eastus",
"serviceLevel": "Premium"
}
Example 3 - Advanced configuration for azure-netapp-files
This backend configuration further reduces the scope of volume placement to a single subnet, and also modifies some volume provisioning defaults.
{
"version": 1,
"storageDriverName": "azure-netapp-files",
"subscriptionID": "9f87c765-4774-fake-ae98-a721add45451",
"tenantID": "68e4f836-edc1-fake-bff9-b2d865ee56cf",
"clientID": "dd043f63-bf8e-fake-8076-8de91e5713aa",
"clientSecret": "SECRET",
"location": "eastus",
"serviceLevel": "Premium",
"virtualNetwork": "my-virtual-network",
"subnet": "my-subnet",
"nfsMountOptions": "vers=3,proto=tcp,timeo=600",
"limitVolumeSize": "500Gi",
"defaults": {
"exportRule": "10.0.0.0/24,10.0.1.0/24,10.0.2.100",
"size": "200Gi"
}
}
Example 4 - Virtual storage pools with azure-netapp-files
This backend configuration defines multiple pools of storage in a single file. This is useful when you have multiple capacity pools supporting different service levels and you want to create storage classes in Kubernetes that represent those.
This is just scratching the surface of the power of virtual storage pools and their labels.
{
"version": 1,
"storageDriverName": "azure-netapp-files",
"subscriptionID": "9f87c765-4774-fake-ae98-a721add45451",
"tenantID": "68e4f836-edc1-fake-bff9-b2d865ee56cf",
"clientID": "dd043f63-bf8e-fake-8076-8de91e5713aa",
"clientSecret": "SECRET",
"nfsMountOptions": "vers=3,proto=tcp,timeo=600",
"labels": {
"cloud": "azure"
},
"location": "eastus",
"storage": [
{
"labels": {
"performance": "gold"
},
"serviceLevel": "Ultra"
},
{
"labels": {
"performance": "silver"
},
"serviceLevel": "Premium"
},
{
"labels": {
"performance": "bronze"
},
"serviceLevel": "Standard",
}
]
}