NFS saturates long before the network does
A single NFS server becomes the ceiling, and adding clients makes it worse. The network has headroom that the file service cannot use.
Solutions · Media & entertainment
Media & entertainment
Render and transcode farms starved by storage, with peaks that double overnight.
What makes this sector awkward
Artists and render jobs are only as fast as the storage behind them. Load is spiky and high, files are enormous, and the deadline is usually a release date rather than a quarter. The storage fabric is usually the real ceiling, and it is usually the last thing anybody suspects.
Parallel filesystem for high-bandwidth reads, a storage fabric sized for the real peak rather than the average, a scheduler that packs jobs properly, and burst capacity that does not require a new rack.
Four situations we see constantly
If two or three of these describe your environment, the audit is worth the money. If all four do, it is overdue.
The array gets blamed for slow writes
Latency is attributed to storage hardware when the queue depth and path selection are set for a general-purpose workload rather than a sequential one.
Queue times double during crunch
The scheduler packs jobs by count rather than by resource, so a handful of jobs hold the whole cluster while producing almost nothing.
Burst capacity means a purchase order
Peak weeks are handled by buying machines that then sit idle for the rest of the year.
Four phases, each useful on its own
Sequenced so that stopping after any phase leaves you better off rather than stranded mid-migration.
- 01
Find the real ceiling
Separate the file service, the fabric and the array in the measurements. Three components blamed collectively is how the wrong one gets replaced.
You end up withA throughput baseline per layer, with the binding constraint identified rather than assumed.
- 02
Replace the file service ceiling
Move high-bandwidth reads onto a parallel filesystem or a properly striped layout, sized for the observed peak instead of the quarterly average.
You end up withMeasured read throughput against the render baseline, with the previous ceiling documented.
- 03
Tune the fabric for sequential load
Set queue depths and multipath selection for throughput rather than for general-purpose random IO, then verify against the array's own preference.
You end up withISL and path latency baselined per fabric, with path selection matched to the workload.
- 04
Make scheduling match the workload
Rework packing and priority so render jobs get the resources they claim, and interactive artist sessions do not queue behind batch work.
You end up withPeak handling that does not require manual intervention or a human deciding who matters today.
The capability behind it
Each discipline has its own page with the technology stack, the acceptance criteria and an explicit scope boundary.
Distributed Storage Cluster Consulting & Operations
Ceph, BeeGFS and MinIO clusters designed around your real failure domains, benchmarked with fio, and proven to survive a disk, a node, and a rack going away.
Ceph (Squid / Reef) · Cephadm + Orchestrator · Rook-Ceph 1.17 · Ceph RGW (S3)Storage Area Network & Fabric Engineering — Fibre Channel, iSCSI and NVMe-oF
Dual-fabric SANs with zoning a human can read, multipathing proven by actually pulling a path, and NVMe-oF over lossless Ethernet that does not drop a frame under load.
Cisco MDS (NX-OS 9.x) · Brocade / Broadcom FOS 9.x · 32G / 64G FC · VSANsHPC & AI/GPU Cluster Services — Slurm, Kubernetes and Inference
Your GPUs are expensive and mostly idle. We fix the part that wastes them: the scheduler, the fabric, the storage feeding them, and the way jobs queue.
Slurm (SchedMD / NVIDIA builds) · Slinky (Slurm in Kubernetes) · OpenPBS / PBS Pro · IBM Spectrum LSFFile Service and Shared Storage Cluster Services
The file services your users actually touch every day, made redundant without changing a single path or permission they are used to.
clustered Samba · CTDB · public addresses + failover · SMB3 encryptionHow this looks in practice
Media production · EU
A licensing renewal the board would not sign, turned into 140 VMs on open source
4 · waves, zero unplanned downtime
Read the engagement → Regional healthcare group · USFour nodes to eleven, with the storage rebalancing planned rather than survived
82% → 54% · cluster utilisation after expansion
Read the engagement → Public research university · EUA private cloud that tenants can self-serve, built to a failure-domain map
6 · tenants migrated off departmental islands
Read the engagement →Every case in this library is a representative engagement, written from our delivery patterns and marked as such. We do not present unnamed work as a named customer.
What we measure in this sector
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- Measured read throughput against the render baseline
- ISL and path latency baselined per fabric
- Peak handled without manual intervention
- Interactive session latency held through batch peaks
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Out of scope
Creative application support and plugin troubleshooting
We handle the infrastructure under the tools. Application crashes and plugin conflicts belong with the tool vendor.
- Requires partner
Cabling, optics and physical build-out
We design and verify the fabric. Running cable and terminating fibre is a specialist trade we bring in rather than pretend to do.
- Out of scope
The content itself — media management, archive catalogues, transcoding pipelines
We provide the storage and the throughput. Asset management software is its own discipline with its own vendors.
- Included
Storage architecture, fabric tuning, scheduler configuration
Including the peak-load testing and the baselines you keep afterwards.
Media & entertainment specifics
Do we have to replace the array?
Usually not. We have found the array to be the binding constraint less often than the file service or the fabric. The audit exists to answer that question with numbers before you spend anything.
Can you work around our release calendar?
Yes, and that drives the sequencing rather than the other way round. Migrations are planned in waves that fit between deliveries, with each wave independently reversible.
Is a parallel filesystem worth it at our scale?
Depends on concurrent read bandwidth rather than capacity. If reads are concentrated and bandwidth-hungry, yes. If the workload is mostly sequential writes of independent frames, a well-tuned scale-out option is often cheaper. We will tell you which one you are.
The engineering transfers, the constraints do not
Financial services & fintech Regulated, audited, and unforgiving of downtime. Every change needs evidence. Healthcare & life sciences Imaging volumes grow faster than budgets, and patient data has strict handling rules. AI startups & ML teams Expensive accelerators, unstable multi-node training, and no proof of where the time goes. SaaS & internet platforms Multi-tenant isolation, unpredictable growth, and a cloud bill that scales faster than revenue. Research & higher education Slurm on one side, Kubernetes on the other, and a budget committee in the middle. Manufacturing & edge fleets Dozens of small sites, intermittent connectivity, and nobody on site who can debug a node.
Want this looked at against your media & entertainment environment?
Thirty minutes, no slides. Bring the awkward constraint — that is usually the interesting part.