Important Considerations

Review the following before planning your TLS deployment.

All-or-nothing enforcement. TLS is either required cluster-wide or forbidden cluster-wide. There is no mixed mode. All connected backend storage servers, Hammerspace cluster nodes, and clients must have TLS enabled when TLS is turned on. TLS can later be disabled.

Backup servers must also be TLS-enabled. When TLS is required, every external NFS storage server and every backup server the cluster touches must also be TLS-enabled. A non-TLS backup target fails once the cluster policy is set to require TLS, with the following error:

This is a hard failure, not a degraded mode: when the cluster policy requires TLS, mounting a non-TLS backup target is denied. Identify and remediate any non-TLS backup servers before enabling TLS.

Enabling TLS is disruptive. Enabling or disabling TLS requires a planned maintenance window. The change first reconfigures and restarts the metadata server on the Anvil, then reconfigures each Anvil and DSX node. While it runs, NFS I/O over existing mounts can fail with access denied by server. The process temporarily takes the cluster, clients, and backend storage volumes offline for normal data operations. After TLS is enabled, all NFS clients must be remounted.

RDMA is not available while TLS is required. TLS for NFS runs over TCP only. If clients mount over NFS/RDMA, plan to move them to TCP before you enable TLS.

Certificate management is shared. Hammerspace automatically generates an internal root Certificate Authority (CA) and issues signed X.509 certificates to each cluster node. The customer’s certificate authority (CA) remains responsible for the full lifecycle of externally-managed certificates, including monitoring expiration, issuing new certificates, and handling revocation. Hammerspace does not alert you before any certificate expires and does not renew certificates automatically, including the node certificates it issues, which are valid for 365 days. Check the expiration dates before you enable TLS. See Certificate Lifetimes and Expiration.

Referral shares are not supported. TLS cannot be enabled on clusters that have NFS referral shares configured.

Performance overhead. In testing with a metadata-intensive workload, enabling TLS did not reduce throughput until the cluster approached saturation, and then reduced it by roughly 2–17%. Clients measured more round-trip time per NFS operation at every load: about 4% more at light load, rising to about 8% near saturation. Near saturation, most operation types took 9–20% longer (for example, GETATTR 17%, OPEN 9%, READDIR 20%), while LOOKUP and COMMIT were unaffected. The cost is per-operation processing overhead on the Anvil, not encryption. Large-file throughput with TLS has not been measured. Size your cluster with this saturation overhead in mind.

SMB and S3 client access is unaffected. From the client’s perspective, TLS applies to NFS data paths only — SMB and S3 are configured independently, and clients using those protocols are functionally unaffected by whether NFS TLS is enabled or disabled. Internally, however, the data and metadata that the SMB and S3 services exchange with the cluster’s portals travel over NFS and are therefore subject to the cluster’s NFS TLS policy; that internal path carries the same performance overhead and is affected by any TLS misconfiguration.

Third-party storage support is limited. In Hammerspace 5.3, NFS over TLS has been validated with Linux NFS servers only. Before you plan a deployment that uses other backend storage, confirm NFS over TLS support with the storage vendor. When TLS is required, backend storage that cannot complete a mutual TLS handshake becomes unavailable. See Reference: Supported Third-Party Backend Storage.

Private key storage. Node private keys are stored unencrypted on the local drive to allow automated startup. These files are protected by the node’s filesystem permissions.