Skip to main content
A newer release of this product is available.

Azure NetApp Files backend configuration options and examples

Contributors netapp-aruldeepa
PDFs

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.

Note Astra Trident does not support Manual QoS capacity pools.

Azure NetApp Files backends provide these configuration options.

Parameter Description Default

version

Always 1

storageDriverName

Name of the storage driver

"azure-netapp-files"

backendName

Custom name or the storage backend

Driver name + "_" + random characters

subscriptionID

The subscription ID from your Azure subscription

Optional when managed identities is enabled on an AKS cluster.

tenantID

The tenant ID from an App Registration

Optional when managed identities is enabled on an AKS cluster.

clientID

The client ID from an App Registration

Optional when managed identities is enabled on an AKS cluster.

clientSecret

The client secret from an App Registration

Optional when managed identities is enabled on an AKS cluster.

serviceLevel

One of Standard, Premium, or Ultra

"" (random)

location

Name of the Azure location where the new volumes will be created

Optional when managed identities is enabled on an AKS cluster.

resourceGroups

List of resource groups for filtering discovered resources

"[]" (no filter)

netappAccounts

List of NetApp accounts for filtering discovered resources

"[]" (no filter)

capacityPools

List of capacity pools for filtering discovered resources

"[]" (no filter, random)

virtualNetwork

Name of a virtual network with a delegated subnet

""

subnet

Name of a subnet delegated to Microsoft.Netapp/volumes

""

networkFeatures

Set of VNet features for a volume, may be Basic or Standard.

Network Features is not available in all regions and might have to be enabled in a subscription. Specifying networkFeatures when the functionality is not enabled causes volume provisioning to fail.

""

nfsMountOptions

Fine-grained control of NFS mount options.

Ignored for SMB volumes.

To mount volumes using NFS version 4.1, include nfsvers=4 in the comma-delimited mount options list to choose NFS v4.1.

Mount options set in a storage class definition override mount options set in backend configuration.

"nfsvers=3"

limitVolumeSize

Fail provisioning if the requested volume size is above this value

"" (not enforced by default)

debugTraceFlags

Debug flags to use when troubleshooting. Example, \{"api": false, "method": true, "discovery": true}. Do not use this unless you are troubleshooting and require a detailed log dump.

null

nasType

Configure NFS or SMB volumes creation.

Options are nfs, smb or null. Setting to null defaults to NFS volumes.

nfs
Note 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

exportRule

Export rules for new volumes.

exportRule must be a comma-separated list of any combination of IPv4 addresses or IPv4 subnets in CIDR notation.

Ignored for SMB volumes.

"0.0.0.0/0"

snapshotDir

Controls visibility of the .snapshot directory

"false"

size

The default size of new volumes

"100G"

unixPermissions

The unix permissions of new volumes (4 octal digits).

Ignored for SMB volumes.

"" (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
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}
Note 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.