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

Configure an Azure NetApp Files backend

Contributors
PDFs

Learn about how to configure Azure NetApp Files (ANF) as the backend for your Astra Trident installation using the sample configurations provided.

Note The Azure NetApp Files service does not support volumes less than 100 GB. Astra Trident automatically creates 100-GB volumes if a smaller volume is requested.
What you'll need

To configure and use an Azure NetApp Files backend, you need the following:

  • subscriptionID from an Azure subscription with Azure NetApp Files enabled.

  • tenantID, clientID, and clientSecret from an App Registration in Azure Active Directory with sufficient permissions to the Azure NetApp Files service. The App Registration should use the Owner or Contributor role that is predefined by Azure.

    Tip To learn more about Azure built-in roles, see the Azure documentation.

  • The Azure location that contains at least one delegated subnet.

  • If you are using Azure NetApp Files for the first time or in a new location, some initial configuration is required. See the quickstart guide.

About this task

Based on the backend configuration (subnet, virtual network, service level, and location), Trident creates ANF volumes on capacity pools that are available in the requested location and match the requested service level and subnet.

Note Astra Trident 21.04.0 and earlier do not support Manual QoS capacity pools.

Backend configuration options

See the following table for the backend 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

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 where the new volumes will be created

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

"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}. Do not use this unless you are troubleshooting and require a detailed log dump.

null
Warning Modifying the capacityPools field in an existing backend such that it reduces the number of capacity pools used for provisioning results in orphaned volumes, which are provisioned on the capacity pool/pools that are not part of the capacityPools list anymore. Cloning operations on these orphaned volumes will fail.
Warning If you encounter a “No capacity pools found” error when attempting to create a PVC, it is likely your app registration doesn’t have the required permissions and resources (subnet, virtual network, capacity pool) associated. Astra Trident will log the Azure resources it discovered when the backend is created when debug is enabled. Be sure to check if an appropriate role is being used.
Note If you want to mount the volumes by using NFS version 4.1, you can include nfsvers=4 in the comma-delimited mount options list to choose NFS v4.1. Any mount options set in a storage class overrides the mount options set in a backend configuration file.

You can control how each volume is provisioned by default by specifying the following options in a special section of the configuration file. 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.

Note For all the volumes created on an ANF backend, Astra Trident copies all the labels present on a storage pool to the storage volume at the time it is provisioned. Storage administrators can define labels per storage pool and group all the volumes created in a storage pool. This provides a convenient way of differentiating volumes based on a set of customizable labels that are provided in the backend configuration.

Example 1: 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 ANF in every location worldwide, and places new volumes on one of them randomly.

This configuration is ideal when you are just getting started with ANF 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"
}

Example 2: Single location and specific service level configuration

This backend configuration places volumes in Azure's eastus location in a Premium capacity pool. Astra Trident
automatically discovers all of the subnets delegated to ANF 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": "Premium"
    }

Example 3: 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": "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 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.

    {
        "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",
            }
        ]
    }

The following StorageClass definitions refer to the storage pools above. By using the parameters.selector field, you can specify for each StorageClass the visrtual 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

What's next?

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.