Half the cluster is idle while jobs queue
Allocation is by count rather than by resource, so a few narrow jobs hold capacity that cannot be used by anything else.
Solutions · Research & education
Research & higher education
Slurm on one side, Kubernetes on the other, and a budget committee in the middle.
What makes this sector awkward
Two populations with incompatible expectations, funding that arrives in cycles, and equipment that must stay useful for years while the workloads on it change every semester. Fairness is a political property as much as a technical one.
A cluster that serves both scheduler worlds, provisioned from code, with fair-share policy the researchers accept because they were shown the numbers behind it.
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.
Nobody agrees on what fair means
Long-running research jobs and short teaching workloads compete in one queue, and the argument is settled politically each time it comes up.
Hardware sitting past its software support window
Nodes that work fine in isolation but cannot receive security updates any more.
Rebuilding a node is a week of work
Provisioning is manual enough that adding capacity is a project rather than an afternoon.
Four phases, each useful on its own
Sequenced so that stopping after any phase leaves you better off rather than stranded mid-migration.
- 01
Instrument before allocating
Collect real utilisation per user and per job. Arguments about fair share go differently when they are about measured usage.
You end up withA utilisation and queue-time picture by group, which is usually more persuasive than any policy document.
- 02
Set policy with the users in the room
Define partitions, QOS and fair share against measured usage and against who funds the cluster, then publish expected wait times.
You end up withA fair-share policy the research groups have agreed to, with the reasoning written down.
- 03
Make provisioning boring
Move node bring-up into code so adding capacity is routine and rebuilds do not depend on one person's memory.
You end up withNode bring-up measured in minutes, reproducible by anyone with repository access.
- 04
Serve both scheduler worlds
Run Slurm and Kubernetes against the same infrastructure where that is sensible, with a clear rule for which workload belongs where.
You end up withOne estate, two schedulers, and a documented boundary rather than an accidental one.
The capability behind it
Each discipline has its own page with the technology stack, the acceptance criteria and an explicit scope boundary.
HPC & 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 LSFBare Metal Linux Cluster Deployment
Twenty machines arrive. In fifteen minutes each they are identical, provisioned from Git, and ready to join a cluster — with nobody logging in by hand.
PXE / iPXE · Debian Preseed · Kickstart · MAASDistributed 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)Managed Kubernetes & Container Platform Services
A cluster you can upgrade without holding your breath, whose etcd backup you have actually restored, and which you could rebuild from code in under an hour.
upstream kubeadm 1.31–1.34 · Kubespray · RKE2 · K3sHow this looks in practice
Research institute · North America
Forty machines, one Git repository, no one logging in by hand
12 min · per-node bring-up, measured on all 40
Read the engagement → B2B SaaS · North AmericaA cluster nobody dared upgrade, rebuilt so upgrades became routine
49 min · measured control-plane upgrade, zero dropped requests
Read the engagement → Logistics technology · EUThree major versions crossed, one workload restarted on purpose
3 · major hops completed in planned windows
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.
- Node bring-up measured in minutes, reproducible from the repository
- Queue time reported per research group
- Fair-share policy documented and defensible with data
- Fleet inside a supported software window
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
Grant writing, funding strategy and institutional procurement policy
We can supply the technical narrative and the numbers. The institutional and funding work is yours.
- Requires partner
Research application support and scientific software debugging
We keep the platform and the scheduler healthy. Application-specific support usually belongs with the group that wrote the code.
- Out of scope
Making policy decisions about who gets priority
We provide the measurements and the mechanisms. Which group outranks which is a decision your institution makes, and should make openly.
- Included
Cluster build, provisioning automation, scheduler tuning and storage
Including the utilisation reporting that makes the policy conversation evidence-based.
Research & education specifics
Can you work with equipment that is already out of warranty?
Yes, with a caveat we will state in writing: unsupported hardware cannot receive security fixes. We will keep it running and be explicit about what the risk actually is, rather than quietly accepting it.
Will you take sides between Slurm and Kubernetes advocates on campus?
We will give both camps the same measurement. Which workloads belong where is usually obvious once utilisation and job shape are visible, and the argument tends to resolve itself.
Our funding is cyclical. Can you work in phases?
That is the normal pattern for this sector. We scope work so each phase is independently useful, and so stopping after any phase leaves you better off rather than mid-migration.
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. Media & entertainment Render and transcode farms starved by storage, with peaks that double overnight. 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. Manufacturing & edge fleets Dozens of small sites, intermittent connectivity, and nobody on site who can debug a node.
Want this looked at against your research & education environment?
Thirty minutes, no slides. Bring the awkward constraint — that is usually the interesting part.