Skip to main content

Integrate Amazon FSx for NetApp ONTAP

Contributors juliantap netapp-aruldeepa

You can integrate your Amazon FSx for NetApp ONTAP file system with Astra Trident to ensure Kubernetes clusters running in Amazon Elastic Kubernetes Service (EKS) can provision block and file persistent volumes backed by ONTAP.

Requirements

In addition to Astra Trident requirements, to integrate FSx for ONTAP with Astra Trident, you need:

  • An existing Amazon EKS cluster or self-managed Kubernetes cluster with kubectl installed.

  • An existing Amazon FSx for NetApp ONTAP file system and storage virtual machine (SVM) that is reachable from your cluster's worker nodes.

  • Worker nodes that are prepared for NFS or iSCSI.

    Note Ensure you follow the node preparation steps required for Amazon Linux and Ubuntu Amazon Machine Images (AMIs) depending on your EKS AMI type.

  • Astra Trident supports SMB volumes mounted to pods running on Windows nodes only. Refer to Prepare to provision SMB volumes for details.

ONTAP SAN and NAS driver integration

Warning If you are configuring for SMB volumes, you must read Prepare to provision SMB volumes before creating the backend.
Steps

  1. Deploy Astra Trident using one of the deployment methods.

  2. Collect your SVM management LIF DNS name. For example, using the AWS CLI, find the DNSName entry under Endpoints → Management after running the following command:

    aws fsx describe-storage-virtual-machines --region <file system region>

  3. Create and install certificates for NAS backend authentication or SAN backend authentication.

    Note You can log in to your file system (for example to install certificates) using SSH from anywhere that can reach your file system. Use the fsxadmin user, the password you configured when you created your file system, and the management DNS name from aws fsx describe-file-systems.

  4. Create a backend file using your certificates and the DNS name of your management LIF, as shown in the sample below:

    YAML
    version: 1
storageDriverName: ontap-san
backendName: customBackendName
managementLIF: svm-XXXXXXXXXXXXXXXXX.fs-XXXXXXXXXXXXXXXXX.fsx.us-east-2.aws.internal
svm: svm01
clientCertificate: ZXR0ZXJwYXB...ICMgJ3BhcGVyc2
clientPrivateKey: vciwKIyAgZG...0cnksIGRlc2NyaX
trustedCACertificate: zcyBbaG...b3Igb3duIGNsYXNz
    JSON
    {
  "version": 1,
  "storageDriverName": "ontap-san",
  "backendName": "customBackendName",
  "managementLIF": "svm-XXXXXXXXXXXXXXXXX.fs-XXXXXXXXXXXXXXXXX.fsx.us-east-2.aws.internal",
  "svm": "svm01",
  "clientCertificate": "ZXR0ZXJwYXB...ICMgJ3BhcGVyc2",
  "clientPrivateKey": "vciwKIyAgZG...0cnksIGRlc2NyaX",
  "trustedCACertificate": "zcyBbaG...b3Igb3duIGNsYXNz"
 }

    Alternatively, you can create a backend file using the SVM credentials (username and password) stored in AWS Secret Manager as shown in this example:

    YAML
    apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nas
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: tbc-ontap-nas
  svm: svm-name
  aws:
    fsxFilesystemID: fs-xxxxxxxxxx
  managementLIF:
  credentials:
    name: "arn:aws:secretsmanager:us-west-2:xxxxxxxx:secret:secret-name"
    type: awsarn
    JSON
    {
  "apiVersion": "trident.netapp.io/v1",
  "kind": "TridentBackendConfig",
  "metadata": {
    "name": "backend-tbc-ontap-nas"
  },
  "spec": {
    "version": 1,
    "storageDriverName": "ontap-nas",
    "backendName": "tbc-ontap-nas",
    "svm": "svm-name",
    "aws": {
      "fsxFilesystemID": "fs-xxxxxxxxxx"
    },
    "managementLIF": null,
    "credentials": {
      "name": "arn:aws:secretsmanager:us-west-2:xxxxxxxx:secret:secret-name",
      "type": "awsarn"
    }
  }
}

    For information about creating backends, see these links:

Prepare to provision SMB volumes

You can provision SMB volumes using the ontap-nas driver. Before you complete ONTAP SAN and NAS driver integration complete the following steps.

Before you begin

Before you can provision SMB volumes using the ontap-nas driver, you must have the following.

  • A Kubernetes cluster with a Linux controller node and at least one Windows worker node running Windows Server 2019. Astra Trident supports SMB volumes mounted to pods running on Windows nodes only.

  • At least one Astra Trident secret containing your Active Directory credentials. To generate secret smbcreds:

    kubectl create secret generic smbcreds --from-literal username=user --from-literal password='password'

  • A CSI proxy configured as a Windows service. To configure a csi-proxy, refer to GitHub: CSI Proxy or GitHub: CSI Proxy for Windows for Kubernetes nodes running on Windows.

Steps

  1. Create SMB shares. You can create the SMB admin shares in one of two ways either using the Microsoft Management Console Shared Folders snap-in or using the ONTAP CLI. To create the SMB shares using the ONTAP CLI:

    1. If necessary, create the directory path structure for the share.

      The vserver cifs share create command checks the path specified in the -path option during share creation. If the specified path does not exist, the command fails.

    2. Create an SMB share associated with the specified SVM:

      vserver cifs share create -vserver vserver_name -share-name share_name -path path [-share-properties share_properties,...] [other_attributes] [-comment text]

    3. Verify that the share was created:

      vserver cifs share show -share-name share_name
      Note Refer to Create an SMB share for full details.

  2. When creating the backend, you must configure the following to specify SMB volumes. For all FSx for ONTAP backend configuration options, refer to FSx for ONTAP configuration options and examples.

    Parameter Description Example

    smbShare

    You can specify one of the following: the name of an SMB share created using the Microsoft Management Console or ONTAP CLI or a name to allow Astra Trident to create the SMB share.

    This parameter is required for Amazon FSx for ONTAP backends.

    smb-share

    nasType

    Must set to smb. If null, defaults to nfs.

    smb

    securityStyle

    Security style for new volumes.

    Must be set to ntfs or mixed for SMB volumes.

    ntfs or mixed for SMB volumes

    unixPermissions

    Mode for new volumes. Must be left empty for SMB volumes.

    ""