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.

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 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 CR created above^, 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 you created above
  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