Setup NetApp Volumes

Domino Volumes for NetApp ONTAP provides a centralized data storage solution that integrates Domino with external NetApp-backed infrastructure. It enables cross-project data sharing, improves I/O performance, eliminates redundancy, and supports snapshot-based recovery.

Volumes reside within ONTAP filesystems, which bind a Domino dataplane and storage class to a named storage container. This architecture supports multi-account scaling, provides precise visibility into storage allocation, and enables retention-aware deletion through cold storage offloading.

This guide provides step-by-step instructions for manually configuring NetApp Volumes in a Domino deployment, intended for administrators managing infrastructure in AWS environments.

Prerequisites

Before you can begin working with NetApp Volumes, you’ll need to verify that you have these prerequisites in place:

ComponentDescription

Domino

Have a Domino deployed and configured.

ONTAP filesystem

Have a supported ONTAP filesystem. This is where the volumes will be made and how they will interact with your underlying infrastructure.

Trident

Installed and working with your file system.

  • For Domino 6.2.0 and 6.2.1: Trident 25.10 and above is supported.

  • For Domino 6.2.2 and above: Trident 26.02 and above is supported.

Communication

Verified that Domino and ONTAP can talk to each other.

Storage Configuration

Root system file name: This is the base of the filesystem where all other volumes are mounted.

Feature Flag

Verify that the feature flag EnableDominoNetAppVolumes is set to true.

Step 1: Kubernetes configuration for Domino

There are a couple of steps you’ll need to take to configure Kubernetes for Domino.

  • Role and RoleBinding: A Kubernetes Role and RoleBinding are required to enable the microservice to authenticate and communicate with Trident.

  • Network policy: You’ll also need a network policy to allow the right Kubernetes resources to communicate with Trident.

Create Role and RoleBinding

You can use these examples as-is to create and apply your Role and RoleBinding:

Create Role

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: data-plane-agent
  namespace: trident
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]

Apply the Role:

vim <my_role>.yaml  # copy/paste the contents above
kubectl apply -f <my_role>.yaml

Create RoleBinding

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: data-plane-agent
  namespace: trident
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: data-plane-agent
subjects:
  - kind: ServiceAccount
    name: data-plane-agent
    namespace: domino-compute

Apply the RoleBinding:

vim <my_role_binding>.yaml  # copy/paste the contents above
kubectl apply -f <my_role_binding>.yaml

Create a Network Policy

Use this example as a template for your NetworkPolicy resource:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: trident-operator
  namespace: trident
spec:
  podSelector:
    matchLabels:
      app: controller.csi.trident.netapp.io
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from: []
      ports:
        - protocol: TCP
          port: 8443
        - protocol: TCP
          port: 8001
  egress:
    - to: []

Apply the Policy:

vim <my_network_policy>.yaml  # copy/paste the contents above

kubectl apply -f <my_network_policy>.yaml

Step 2: Configure the Trident backend

The TridentBackendConfig (TBC) custom resource tells Trident how to connect to your specific FSx for NetApp ONTAP filesystem.

Create the TridentBackendConfig

  1. Create the YAML file: Create a file named trident-backend.yaml. Copy the YAML below, replacing the placeholder values with the details from your Terraform output:

    • svm: The name of the SVM.

    • fsxFilesystemID: The id of the filesystem.

    • apiRegion: The AWS region where your FSx filesystem is deployed.

    • credentials.name: The creds_secret_arn for the SVM.

      apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nas
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: tbc-ontap-nas
  svm: "<your-svm-name>"
  aws:
    fsxFilesystemID: "<your-fsx-filesystem-id>"
    apiRegion: "<your-aws-region>"
  credentials:
    name: "<your-creds-secret-arn>"
    type: awsarn

  2. Apply the Configuration:

    kubectl apply -f trident-backend.yaml

  3. Verify the Backend: Check that the backend is bound and online.

    kubectl -n trident get tbc,tbe

    Example output:

    NAME                    BACKEND NAME    BACKEND UUID                           PHASE   STATUS
backend-tbc-ontap-nas   tbc-ontap-nas   xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   Bound   Success

NAME        BACKEND         BACKEND UUID
tbe-xxxxx   tbc-ontap-nas   xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Create a Storage Class

A StorageClass allows users to dynamically provision volumes on the backend you just configured.

  1. Create storage-class.yaml:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-gold
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
reclaimPolicy: Delete
allowVolumeExpansion: true

  2. Apply the StorageClass:

    kubectl apply -f storage-class.yaml

Step 3: Create Root PVC

When you created a filesystem in Amazon FSx or NetApp Cloud ONTAP, it included a special root volume at the path /. This is the base of the filesystem where all other volumes are mounted.

To make it usable in Domino, you’ll need to create a Kubernetes PersistentVolumeClaim (PVC) that maps to this root volume. The example below shows how to define that PVC using an import:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fsx-imported-volume                                                     # Arbitrary name
  namespace: domino-compute                                                     # Should always be the compute namespace
  labels:
    dominodatalab.com/netapp-storage: "true"                                    # IMPORTANT. This is needed so the Root PVC can be found during Filesystem creation (in the next step)
  annotations:
    trident.netapp.io/importBackendUUID: "c9c51153-a02d-4f67-b3ca-6e11c8e80ee2" # This can be found by inspecting the tridentbackendconfig custom resource in the cluster, under the status.backendInfo.backendUUID field
    trident.netapp.io/importOriginalName: demo_root                             # Name of the root volume in your Filesystem. Can be found in AWS FSx UI (The name is usually <deployment_id>_svm_root)
    trident.netapp.io/notManaged: "false"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 953Mi
  storageClassName: democlass                                                   # Use the storage class of the trident storage class in the cluster
  volumeMode: Filesystem

Apply Root PVC:

vim <root_pvc>.yaml <paste template and change values> kubectl apply -f <root_pvc>.yaml

Verify status:

kubectl get pvc <root_pvc> -n domino-compute

Make sure the returned message indicates STATUS - Success.

Your Domino deployment is now fully configured to use NetApp Volumes for scalable, managed storage.

Next Steps