Azure NetApp Files backend configuration options and examples
Learn about NFS and SMB backend configuration options for Azure NetApp Files and review configuration examples.
Backend configuration options
Astra Trident uses your backend configuration (subnet, virtual network, service level, and location), to create Azure NetApp Files volumes on capacity pools that are available in the requested location and match the requested service level and subnet.
Astra Trident does not support Manual QoS capacity pools. |
Azure NetApp Files backends provide these configuration options.
Parameter | Description | Default |
---|---|---|
|
Always 1 |
|
|
Name of the storage driver |
"azure-netapp-files" |
|
Custom name or the storage backend |
Driver name + "_" + random characters |
|
The subscription ID from your Azure subscription |
|
|
The tenant ID from an App Registration |
|
|
The client ID from an App Registration |
|
|
The client secret from an App Registration |
|
|
One of |
"" (random) |
|
Name of the Azure location where the new volumes will be created |
|
|
List of resource groups for filtering discovered resources |
"[]" (no filter) |
|
List of NetApp accounts for filtering discovered resources |
"[]" (no filter) |
|
List of capacity pools for filtering discovered resources |
"[]" (no filter, random) |
|
Name of a virtual network with a delegated subnet |
"" |
|
Name of a subnet delegated to |
"" |
|
Set of VNet features for a volume, may be |
"" |
|
Fine-grained control of NFS mount options. |
"nfsvers=3" |
|
Fail provisioning if the requested volume size is above this value |
"" (not enforced by default) |
|
Debug flags to use when troubleshooting. Example, |
null |
|
Configure NFS or SMB volumes creation. |
|
For more information on Network Features, refer to Configure network features for an Azure NetApp Files volume. |
Required permissions and resources
If you receive a “No capacity pools found” error when creating a PVC, it is likely your app registration doesn't have the required permissions and resources (subnet, virtual network, capacity pool) associated. If debug is enabled, Astra Trident will log the Azure resources discovered when the backend is created. Verify an appropriate role is being used.
The values for resourceGroups
, netappAccounts
, capacityPools
, virtualNetwork
, and subnet
can be specified using short or fully-qualified names. Fully-qualified names are recommended in most situations as short names can match multiple resources with the same name.
The resourceGroups
, netappAccounts
, and capacityPools
values are filters that restrict the set of discovered resources to those available to this storage backend and may be specified in any combination. Fully-qualified names follow this format:
Type | Format |
---|---|
Resource group |
<resource group> |
NetApp account |
<resource group>/<netapp account> |
Capacity pool |
<resource group>/<netapp account>/<capacity pool> |
Virtual network |
<resource group>/<virtual network> |
Subnet |
<resource group>/<virtual network>/<subnet> |
Volume provisioning
You can control default volume provisioning by specifying the following options in a special section of the configuration file. Refer to Example configurations for details.
Parameter | Description | Default |
---|---|---|
|
Export rules for new volumes. |
"0.0.0.0/0" |
|
Controls visibility of the .snapshot directory |
"false" |
|
The default size of new volumes |
"100G" |
|
The unix permissions of new volumes (4 octal digits). |
"" (preview feature, requires whitelisting in subscription) |
Example configurations
The following examples show basic configurations that leave most parameters to default. This is the easiest way to define a backend.
Minimal configuration
This is the absolute minimum backend configuration. With this configuration, Astra Trident discovers all of your NetApp accounts, capacity pools, and subnets delegated to Azure NetApp Files in the configured location, and places new volumes on one of those pools and subnets randomly. Because nasType
is omitted, the nfs
default applies and the backend will provision for NFS volumes.
This configuration is ideal when you are just getting started with Azure NetApp Files and trying things out, but in practice you are going to want to provide additional scoping for the volumes you provision.
--- 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
Managed identities for AKS
This backend configuration omits subscriptionID
, tenantID
, clientID
, and clientSecret
, which are optional when using managed identities.
apiVersion: trident.netapp.io/v1 kind: TridentBackendConfig metadata: name: backend-tbc-anf-1 namespace: trident spec: version: 1 storageDriverName: azure-netapp-files capacityPools: ["ultra-pool"] resourceGroups: ["aks-ami-eastus-rg"] netappAccounts: ["smb-na"] virtualNetwork: eastus-prod-vnet subnet: eastus-anf-subnet
Cloud identity for AKS
This backend configuration omits tenantID
, clientID
, and clientSecret
, which are optional when using a cloud identity.
apiVersion: trident.netapp.io/v1 kind: TridentBackendConfig metadata: name: backend-tbc-anf-1 namespace: trident spec: version: 1 storageDriverName: azure-netapp-files capacityPools: ["ultra-pool"] resourceGroups: ["aks-ami-eastus-rg"] netappAccounts: ["smb-na"] virtualNetwork: eastus-prod-vnet subnet: eastus-anf-subnet location: eastus subscriptionID: 9f87c765-4774-fake-ae98-a721add45451
Specific service level configuration with capacity pool filters
This backend configuration places volumes in Azure's eastus
location in an Ultra
capacity pool. Astra Trident automatically discovers all of the subnets delegated to Azure NetApp Files in that location and places 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: Ultra capacityPools: - application-group-1/account-1/ultra-1 - application-group-1/account-1/ultra-2
Advanced configuration
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: Ultra capacityPools: - application-group-1/account-1/ultra-1 - application-group-1/account-1/ultra-2 virtualNetwork: my-virtual-network subnet: my-subnet networkFeatures: Standard 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 snapshotDir: 'true' size: 200Gi unixPermissions: '0777'
Virtual pool configuration
This backend configuration defines multiple storage pools 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. Virtual pool labels were used to differentiate the pools based on performance
.
--- 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 resourceGroups: - application-group-1 networkFeatures: Basic nfsMountOptions: vers=3,proto=tcp,timeo=600 labels: cloud: azure storage: - labels: performance: gold serviceLevel: Ultra capacityPools: - ultra-1 - ultra-2 networkFeatures: Standard - labels: performance: silver serviceLevel: Premium capacityPools: - premium-1 - labels: performance: bronze serviceLevel: Standard capacityPools: - standard-1 - standard-2
Storage Class definitions
The following StorageClass
definitions refer to the storage pools above.
Example definitions using parameter.selector
field
Using parameter.selector
you can specify for each StorageClass
the virtual pool that is used to host a volume. The volume will have the aspects defined in the chosen pool.
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gold provisioner: csi.trident.netapp.io parameters: selector: "performance=gold" allowVolumeExpansion: true --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: silver provisioner: csi.trident.netapp.io parameters: selector: "performance=silver" allowVolumeExpansion: true --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: bronze provisioner: csi.trident.netapp.io parameters: selector: "performance=bronze" allowVolumeExpansion: true
Example definitions for SMB volumes
Using nasType
, node-stage-secret-name
, and node-stage-secret-namespace
, you can specify an SMB volume and provide the required Active Directory credentials.
Basic configuration on default namespace
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: anf-sc-smb provisioner: csi.trident.netapp.io parameters: backendType: "azure-netapp-files" trident.netapp.io/nasType: "smb" csi.storage.k8s.io/node-stage-secret-name: "smbcreds" csi.storage.k8s.io/node-stage-secret-namespace: "default"
Using different secrets per namespace
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: anf-sc-smb provisioner: csi.trident.netapp.io parameters: backendType: "azure-netapp-files" trident.netapp.io/nasType: "smb" csi.storage.k8s.io/node-stage-secret-name: "smbcreds" csi.storage.k8s.io/node-stage-secret-namespace: ${pvc.namespace}
Using different secrets per volume
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: anf-sc-smb provisioner: csi.trident.netapp.io parameters: backendType: "azure-netapp-files" trident.netapp.io/nasType: "smb" csi.storage.k8s.io/node-stage-secret-name: ${pvc.name} csi.storage.k8s.io/node-stage-secret-namespace: ${pvc.namespace}
nasType: smb filters for pools which support SMB volumes. nasType: nfs or nasType: null filters for NFS pools.
|
Create the backend
After you create the backend configuration file, run the following command:
tridentctl create backend -f <backend-file>
If the backend creation fails, something is wrong with the backend configuration. You can view the logs to determine the cause by running the following command:
tridentctl logs
After you identify and correct the problem with the configuration file, you can run the create command again.