ONTAP (AFF/FAS/Select/Cloud)

To create and use an ONTAP backend, you will need:

Choosing a driver

Driver Protocol
ontap-nas NFS
ontap-nas-economy NFS
ontap-san iSCSI

The ontap-nas and ontap-san drivers create an ONTAP FlexVol for each volume. ONTAP supports up to 1000 FlexVols per cluster node with a cluster maximum of 12,000 FlexVols. If your persistent volume requirements fit within that limitation, those drivers are the preferred solution due to the granular data management capabilities they afford.

If you need more persistent volumes than may be accommodated by the FlexVol limits, choose the ontap-nas-economy driver, which creates volumes as ONTAP Qtrees within a pool of automatically managed FlexVols. Qtrees offer far greater scaling, up to 100,000 per cluster node and 2,400,000 per cluster, at the expense of granular data management features.

Remember that you can also run more than one driver, and create storage classes that point to one or the other. For example, you could configure a Gold class that uses the ontap-nas driver and a Bronze class that uses the ontap-nas-economy one.

Preparation

For all ONTAP backends, Trident requires at least one aggregate assigned to the SVM.

ontap-nas and ontap-nas-economy

All of your Kubernetes worker nodes must have the appropriate NFS tools installed. See the worker configuration guide for more details.

Trident uses NFS export policies to control access to the volumes that it provisions. It uses the default export policy unless a different export policy name is specified in the configuration.

While Trident associates new volumes (or qtrees) with the configured export policy, it does not create or otherwise manage export policies themselves. The export policy must exist before the storage backend is added to Trident, and it needs to be configured to allow access to every worker node in the Kubernetes cluster.

If the export policy is locked down to specific hosts, it will need to be updated when new nodes are added to the cluster, and that access should be removed when nodes are removed as well.

ontap-san

All of your Kubernetes worker nodes must have the appropriate iSCSI tools installed. See the worker configuration guide for more details.

Trident uses igroups to control access to the volumes (LUNs) that it provisions. It expects to find an igroup called trident unless a different igroup name is specified in the configuration.

While Trident associates new LUNs with the configured igroup, it does not create or otherwise manage igroups themselves. The igroup must exist before the storage backend is added to Trident, and it needs to contain the iSCSI IQNs from every worker node in the Kubernetes cluster.

The igroup needs to be updated when new nodes are added to the cluster, and they should be removed when nodes are removed as well.

Backend configuration options

Parameter Description Default
version Always 1  
storageDriverName “ontap-nas”, “ontap-nas-economy” or “ontap-san”  
managementLIF IP address of a cluster or SVM management LIF “10.0.0.1”
dataLIF IP address of protocol LIF Derived by the SVM unless specified
svm Storage virtual machine to use Derived if an SVM managementLIF is specified
username Username to connect to the cluster/SVM  
password Password to connect to the cluster/SVM  
storagePrefix Prefix used when provisioning new volumes in the SVM “trident”

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
spaceReserve Space reservation mode; “none” (thin) or “volume” (thick) “none”
snapshotPolicy Snapshot policy to use “none”
splitOnClone Split a clone from its parent upon creation false
encryption Enable NetApp volume encryption false
unixPermissions ontap-nas* only: mode for new volumes “777”
snapshotDir ontap-nas* only: access to the .snapshot directory false
exportPolicy ontap-nas* only: export policy to use “default”
securityStyle ontap-nas* only: security style for new volumes “unix”

Example configuration

NFS Example for ontap-nas driver

{
    "version": 1,
    "storageDriverName": "ontap-nas",
    "managementLIF": "10.0.0.1",
    "dataLIF": "10.0.0.2",
    "svm": "svm_nfs",
    "username": "vsadmin",
    "password": "netapp123",
    "defaults": {
      "spaceReserve": "volume",
      "exportPolicy": "myk8scluster"
    }
}

NFS Example for ontap-nas-economy driver

{
    "version": 1,
    "storageDriverName": "ontap-nas-economy",
    "managementLIF": "10.0.0.1",
    "dataLIF": "10.0.0.2",
    "svm": "svm_nfs",
    "username": "vsadmin",
    "password": "netapp123"
}

iSCSI Example for ontap-san driver

{
    "version": 1,
    "storageDriverName": "ontap-san",
    "managementLIF": "10.0.0.1",
    "dataLIF": "10.0.0.3",
    "svm": "svm_iscsi",
    "username": "vsadmin",
    "password": "netapp123"
}

User permissions

Trident expects to be run as either an ONTAP or SVM administrator, typically using the admin cluster user or a vsadmin SVM user, or a user with a different name that has the same role.

While it is possible to create a more restrictive role within ONTAP that a Trident driver can use, we don’t recommend it. Most new releases of Trident will call additional APIs that would have to be accounted for, making upgrades difficult and error-prone.