I help administer a bioinformatics lab's multi-node HPC cluster with shared NAS storage. I'm building a shadow-pricing model that estimates what each workload would cost on Google Cloud. SlurmDB provides the job records, and I currently map requested resources to the least expensive GCP instance that satisfies them, then query the pricing API for a per-job compute estimate.
That covers the basic compute cost, but it leaves out items such as instance startup time, persistent storage, network egress, and other cloud-specific charges. I'm considering a broader monitoring and cost-mapping layer that combines system usage with Slurm accounting, but I'd prefer to use an existing FinOps or cost-modeling framework rather than build and maintain everything myself.
Has anyone implemented a practical way to translate holistic HPC usage—including compute, storage, and networking—into estimated cloud costs? In particular, I'm interested in measuring storage and network usage by user or Slurm account without repeatedly scanning the entire NAS.
2 Answers
You can approximate the cloud compute side with Slurm billing weights, but storage and data transfer make the model much less tidy. Map each node type to a representative GCP SKU, then add separate rates for allocated or consumed storage, snapshots, and network transfer. Keep those categories separate instead of trying to force everything into a single Slurm weight.
For storage, filesystem quotas or periodic usage accounting are usually less expensive than traversing the NAS on every update. For networking, collect interface or switch-level byte counters and attribute them where your infrastructure allows; accurately assigning egress to individual users can be difficult unless traffic passes through a gateway or accounting layer. It may be more practical to report network costs by host, project, or Slurm account rather than promise perfect per-job attribution.
For the compute portion, Slurm’s `sacct` and `sreport` may already be enough. Define billing weights for each node or partition type, then use those reports to produce consistent usage totals. It won’t exactly reproduce a cloud invoice, but it gives you a simple and maintainable internal cost model.
That handles compute well, but I’m mainly stuck on persistent storage and networking. I’d like to connect per-user storage and egress estimates to the Slurm accounts without adding a full custom monitoring system.
A useful compromise is to make compute costs precise and label storage and networking as estimates. Track daily or hourly deltas from filesystem quotas and network counters, then allocate shared costs across accounts. That avoids building a daemon around every file-transfer tool while still showing the major cost drivers.