Contact Us 1-800-596-4880

Shared Filesystem Prerequisites

Before you install Anypoint Platform Private Cloud Edition (Anypoint Platform PCE), your infrastructure team must review each of the following sections and verify that your environment meets the stated requirements. If needed, contact your MuleSoft representative for assistance to ensure your shared filesystem is configured correctly.

Anypoint Platform PCE requires a ReadWriteMany (RWX) shared filesystem for the platform. Starting with Anypoint Platform PCE 4.3.0, you can provide this filesystem using either of the following storage modes:

  • NFS mode — Bind the platform to an existing NFS server through a pre-installed CSI driver. Use this mode when your organization already operates an NFS server (for example, AWS EFS, NetApp, Isilon, or a self-managed NFS server) that you want the platform to consume.

  • StorageClass mode — Provide a single RWX-capable Kubernetes StorageClass and let Anypoint Platform PCE dynamically provision the shared volumes. Use this mode when your cluster has an RWX-capable CSI driver such as CephFS available and you prefer not to operate an external NFS server.

You choose the mode at installation time by setting the corresponding fields in the platformConfiguration section of your input.yaml file. The two modes are mutually exclusive.

The installer rejects changes to the storage mode on an existing cluster. Switching between NFS and StorageClass mode after installation orphans the data stored on the previous volumes. Choose the mode carefully before installing.

CSI Driver Requirement (NFS Mode)

When using NFS mode, a pre-installed Container Storage Interface (CSI) driver is a mandatory requirement. Anypoint Platform PCE uses the Kubernetes CSI driver to mount NFS volumes into pods, replacing the previous method that relied on host binaries.

Some key benefits:

  • Enhanced support for environments where custom tools cannot be installed on host nodes.

  • Direct support for Amazon EKS users who can only use the Amazon EFS CSI Driver.

The CSI driver requirement applies only to NFS mode. In StorageClass mode, the RWX-capable StorageClass handles provisioning through its own CSI driver.

Configure the CSI Driver

In the platformConfiguration section of your input.yaml file, specify the CSI driver name:

platformConfiguration:
  fileSystemCsiDriverName: "" # CSI driver name (e.g., nfs.csi.k8s.io, efs.csi.aws.com)

EFS CSI Driver Configuration

When using the Amazon EFS CSI Driver (for example, for Amazon EKS with EFS installations), provide four individual CSI volume handles. These volume handles must point to four access points that all target the same directory in the EFS:

platformConfiguration:
  fileSystemCsiDriverName: "efs.csi.aws.com"
  fileSystemWcCsiVolumeHandle: ""             # CSI volume handle for wc filesystem
  fileSystem01CsiVolumeHandle: ""             # CSI volume handle for 01 filesystem
  fileSystemBareCsiVolumeHandle: ""           # CSI volume handle for bare filesystem
  fileSystemBackupRestoreCsiVolumeHandle: ""  # CSI volume handle for backup-restore filesystem

Each volume handle value follows the format <file-system-id>::<access-point-id>, for example: fs-0835b0d1eb7588eb1::fsap-03f6c68563ceb5acf.

When using the EFS CSI Driver, you do not need to provide fileSystemDNS or fileSystemPath values.

StorageClass Mode

Starting with Anypoint Platform PCE 4.3.0, you can host the platform shared filesystem on any Kubernetes StorageClass that supports ReadWriteMany access mode, without operating an external NFS server. The StorageClass must be backed by an RWX-compliant CSI driver, for example CephFS (ocs-storagecluster-cephfs) on OpenShift Data Foundation.

When you set fileSystemStorageClass in platformConfiguration, the installer provisions the platform’s shared volumes and the backup-restore volume as dynamically created PersistentVolumeClaim resources against the specified StorageClass. In this mode, the following NFS-mode fields are not used:

  • fileSystemCsiDriverName

  • fileSystemDNS, fileSystemPath

  • fileSystemWcCsiVolumeHandle, fileSystem01CsiVolumeHandle, fileSystemBareCsiVolumeHandle, fileSystemBackupRestoreCsiVolumeHandle

Configure StorageClass Mode

In the platformConfiguration section of your input.yaml file, specify the RWX-capable StorageClass:

platformConfiguration:
  fileSystemStorageClass: "" # e.g. ocs-storagecluster-cephfs

StorageClass Requirements

The StorageClass you provide must:

  • Support the ReadWriteMany (RWX) access mode.

  • Be backed by an RWX-compliant CSI driver (for example, CephFS).

  • Be available and default-usable in the cluster where you install Anypoint Platform PCE.

For backup retention, use a StorageClass with reclaimPolicy: Retain for the backup-restore volume. With reclaimPolicy: Delete, deleting the PersistentVolumeClaim also destroys the underlying storage and any historical backup tarballs stored on it.

Verify NFS Server Setup

The following sections apply only when installing in NFS mode. If you are using StorageClass mode, skip to Installing Anypoint Platform PCE.

Anypoint Platform PCE version 2.0 and later requires a Network File System (NFS) server and an available NFS endpoint. Your NFS server must meet the following requirements:

  • Must be running on a filesystem that has at least 250 GB available.

  • Must be using NFS 4.x.

  • Can be backed by a network-attached storage (NAS) system.

  • Must have port 2049 enabled for TCP.

  • Configure your network so that all of the PCE nodes can access the NFS server. The direct NFS client is Kubernetes 1.9 and requires conformance with NFS version 4.

NFS 4.x does not use the portmapper service.

Verify Required Port Is Open

The NFS server requires port 2049 to be open for TCP.

On each node, use netcat or a similar utility to verify that the required port is open. Netcat is a computer networking utility used to read and write to network connections using TCP.

On each node, run: nc -zv <host_name> 2049

By default, the netcat tool is not included with Anypoint Platform PCE. If you receive a command not found error, you can download and install netcat or a similar utility.

When the responses from netcat are successful, you receive a response similar to the following example:

[ec2-user@ip-10-1-1-97 ~]$ nc -zv <nfs_host_name> 2049
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.1.0.155:2049.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Verify NFS Server Is Mounted

On each node, mount the NFS server in a temporary directory.

  1. Switch to root:
    sudo su

  2. To mount the NFS in a temporary directory, run the following commands and replace both the <nfs-server> and the <nfs-path> with your own values:
    mkdir -p /mnt/home
    mount -t nfs4 -o proto=tcp,port=2049 <nfs-server>:<path> /mnt/home/
    If the mount fails, you do not have the required permissions.

Verify NFS Performance

Perform careful analysis of your environment, both from the client and server point of view for optimal NFS performance. This involves:

  • Testing the performance and latency of your NFS server. Specifically, these operations will transfer data from the client (Anypoint Platform PCE environment) to the NFS server and measure how long each transfer takes.

  • Using the command time dd if=/dev/zero of=/mnt/home/<nameOfFile> bs=<blockSize> count=<amountOfBlocks> to test NFS server performance while transferring files and specifying the following parameters:

    • Names <nameOfFile>

    • Block size and number of blocks in the transfer: <blockSize> and <amountOfBlocks>, respectively.

  • Validating how Anypoint Platform PCE handles NFS file transfers. Perform read and write operations with both large (128MB) and small (80KB) files.

Perform all tests on each node.

Test Writing and Reading Large Files on the NFS Server

Perform the following read and write tests using large files:

  • File size: 128 MB

  • Block size: 4 KB

  • Number of blocks: 32768

While the tests are running, different files are generated (one file per test).

  1. Create a directory in which to mount the NFS server:

    sudo su
    mkdir -p /mnt/home
  2. Mount the NFS server:

    mount -t nfs4 -o proto=tcp,port=2049 <nfs-server>:<path> /mnt/home/
  3. Perform writes (five files of 128 MB each) on the NFS server:

    time for i in {1..5}; do dd if=/dev/zero of=/mnt/home/greatfile$i.test bs=4k count=32768; done

    The command output is similar to the following:

    [root@ip-10-1-1-97 ec2-user]# time for i in {1..5}; do dd if=/dev/zero of=/mnt/home/greatfile$i.test bs=4k count=32768; done
    32768+0 records in
    32768+0 records out
    134217728 bytes (134 MB) copied, 2.12805 s, 63.1 MB/s
    .
    .
    .
    real 0m8.378s
    user 0m0.034s
    sys 0m0.792s

    The real parameter in the test output should be less than 15 seconds.

Validate Read Performance

  1. Unmount the NFS server:

    umount /mnt/home
  2. Remount the NFS server:

    mount -t nfs4 -o proto=tcp,port=2049 <nfs-server>:<path> /mnt/home/
  3. Perform reads from the NFS server by running the following command:

    time for i in {1..5}; do dd if=/mnt/home/greatfile$i.test of=/dev/null bs=4k; done

    The real parameter in the test output should be less than 15 seconds.

Clear the Caches

Unmount the NFS server to clear out any caches:

umount /mnt/home

Test Writing and Reading Small Files on the NFS Server

Test small files as you did large files but with these sizes:

  • File size: 80 KB

  • Block size: 4 KB

  • Number of blocks: 20

Before starting the test, verify that the /mnt/home directory from the previous test is created.

  1. Mount the NFS server:

    mount -t nfs4 -o proto=tcp,port=2049 <nfs-server>:<path> /mnt/home/
  2. Perform writes (five files of 80 KB each) on the NFS server:

    time for i in {1..30}; do dd if=/dev/zero of=/mnt/home/smallfile$i.test bs=4k count=20; done

    The real parameter in the test output should be around 2 seconds.

Validate Read Performance

  1. Unmount the NFS server:

    umount <nfs-server>
  2. Remount the NFS server:

    mount -t nfs4 -o proto=tcp,port=2049 <nfs-server>:<path> /mnt/home/
  3. Perform reads from the NFS server:

    time for i in {1..30}; do dd if=/mnt/home/smallfile$i.test of=/dev/null bs=4k; done

    The important parameter in the test output is the real parameter, which should be around 2 seconds.

Delete the Test Files

When you finish the performance testing, delete the test files.

  1. Remove all generated files by running:

    rm -f /mnt/home/*.test
  2. Unmount the NFS server:

    umount /mnt/home

Override NFS Mount Options

In NFS mode, Anypoint Platform PCE sets the noresvport NFS mount option by default, which is strongly recommended for AWS and other cloud environments. If this default conflicts with your environment requirements, you can override the NFS mount options by providing a comma-separated string in the platformConfiguration section of your input.yaml file:

platformConfiguration:
  fileSystemBareMountOptionsOverride: ""
  fileSystemWcMountOptionsOverride: ""
  fileSystem01MountOptionsOverride: ""

For example, to remove the noresvport option, provide a string with your custom mount options:

nfsvers=4.0,retrans=2,rsize=1048576,soft,sync,timeo=600,wsize=1048576
These fields are optional. If not specified, the default mount options are used.