NFS saturated at 4GB/s, replaced by a parallel filesystem that holds 38GB/s
Parallel filesystem (BeeGFS / Lustre class)
Where they started
Simulation jobs read and wrote large mesh files over NFS. Throughput plateaued at around 4GB/s regardless of how many clients were added.
The problem, precisely
Adding clients made the NFS server the bottleneck rather than increasing throughput, so the cluster could not be scaled by buying compute.
What we did
Read the storage fabric as a bandwidth problem rather than a capacity problem, deployed a parallel filesystem with per-server metadata and storage targets, then tuned for the specific I/O size of the simulation workload.
Delivered
- Parallel filesystem with metadata and storage targets distributed across six servers
- Dedicated storage fabric separated from the management network, MTU and RDMA tuned
- Stripe pattern per directory tuned to the simulation workload I/O size
- Client-side mount options documented, including the ones that matter for read-heavy jobs
- Failure test: one storage target lost mid-job, with the observed client behaviour recorded
Technologies used
Measured result
Every number below was measured and reported to the customer. Where we do not have a measured figure, the entry is a fact rather than a percentage — we would rather be precise than impressive.
- 4 → 38 GB/s aggregate read throughput
- 64 compute clients served concurrently
- 1 storage target failure survived, job continued
- 0 compute nodes added to reach the new throughput
When throughput stops scaling with clients, you have a server-side problem. Parallel filesystems exist precisely because one NFS server has one spine.