Industries · eResearch & Academia

Five institutions, one cluster, nobody in charge of everybody.

Fair-share across organisations that do not report to each other is the constraint we design around first. Buying the hardware is comparatively simple. Deciding whose job runs when Deakin, a CRC and a Category 1 grant all want the same GPU partition in November is the part that decides whether the facility is trusted.

The constraint we design around first

The hard problem is governance, not hardware.

A shared facility fails politically long before it fails technically. Partners withdraw when they cannot see what they received for their contribution. The scheduler configuration is therefore a governance document that happens to be machine-readable.

Diagram — contributing institutions, allocation committee, scheduler accounts and reporting outputs, showing where each decision is enforced, 1200×900
The question to settle first. When the facility is oversubscribed in the last month of a grant round, who decides, against what rule, and can a partner who loses see why. Answer that and most of the technical design follows.

Why shared facilities come apart

We have been brought in to repair three recurring failures. A partner cannot reconcile their contribution against their usage. A large group has quietly consumed the shared pool through job-array volume. Or the scheduler was tuned for throughput, so short interactive work — the kind students and instrument pipelines depend on — never gets a slot.

Peers, not a hierarchy
No single institution can direct the others. Rules must be agreed in advance because there is no authority to appeal to afterwards.
Contribution in kind
One partner puts in capital, another puts in floor space, power and staff. The allocation model has to convert both into comparable entitlement.
Grant time, not calendar time
Demand is driven by funding rounds, thesis submission and conference deadlines. Peaks are predictable, which means they can be planned for.
Unequal expertise
The same queue serves a tuned MPI code and an unoptimised script. Fair-share on raw core-hours quietly penalises the disciplines with less software support.
Audit is certain
Grant reviews, institutional audit and partner reporting will all ask for usage figures. If they have to be reconstructed, they will be disputed.

We start an engagement by writing the allocation rules in plain English with the partners in the room, then implementing exactly those rules. Configuration that does not match a document somebody signed is how trust erodes.

Allocation & accounting

Fair-share is a mechanism, not a policy.

Slurm will implement almost any allocation model you can describe. It will not tell you which one is fair. That decision belongs to the partners, and most of the dissatisfaction we see comes from mechanisms deployed without it.

Allocation mechanisms and what each one actually controls. Most facilities need several in combination; the failure mode column is where each one bites in practice.
Mechanism What it controls Failure mode when used alone
Fair-share tree Relative priority between accounts, decayed over a configured half-life An idle partner accrues priority and then floods the queue, stalling everyone for days
Hard resource quotas An absolute ceiling on core-hours, GPU-hours or storage per project Capacity sits idle while a project that would use it has exhausted its quota
Quality of service tiers Priority, limits and preemption behaviour by class of work Tiers proliferate until nobody, including the operators, can predict scheduling
Reservations Guaranteed access for a course, a campaign or an instrument run Reserved-but-unused nodes become the facility's largest source of waste
Preemptible backfill Opportunistic use of otherwise idle capacity at low priority Useless to any code without checkpointing, which is most code by default
Trackable resource weighting Charging that reflects memory, GPU and licence consumption, not just cores Weights set once at commissioning and never revisited as hardware generations mix
Allocation committee Discretionary award of large or unusual requests against stated criteria Becomes the only path that works, so routine access depends on a meeting

Accounting that survives an audit and a grant review

01

Record at job granularity, retain for the life of the claim

Slurm's accounting database holds the evidence, so it is configured as a system of record: replicated, backed up, and retained beyond the longest grant reporting obligation. Purging accounting data to save space has ended more than one reconciliation argument badly.

02

One number, derivable by anyone

Partner reports are generated from the accounting database by a documented query, not assembled in a spreadsheet. A partner who disputes a figure can be handed the query and the raw rows, which usually ends the dispute in minutes rather than weeks.

03

Attribute to the grant, not only the user

Jobs carry a project code that maps to a funded activity, so usage can be reported against the grant that paid for it. Identifiers such as ORCID for people and DOIs for output data sets let a reviewer trace compute through to publication.

04

Publish utilisation, including the awkward months

Utilisation, queue wait by partner and reservation waste are reported on a fixed cycle whether the numbers flatter the facility or not. Selective reporting is discovered eventually, and costs more credibility than a bad quarter ever does.

Where we will argue with you. Charging purely on core-hours is the most common model and the least defensible on a mixed CPU and GPU estate. A GPU node hour can cost an order of magnitude more to supply than a CPU node hour. If the charging weights do not reflect that, the facility subsidises whoever asks for accelerators and penalises everyone else.

Federated identity & access

The account has to outlive the enrolment and not the employment.

Researchers arrive with an identity issued by their home institution and leave when that institution says so. A shared facility that maintains its own user database inherits every joiner, mover and leaver problem of every partner at once.

Diagram — home institution identity provider through AAF and eduGAIN to the facility service provider, showing attribute release and group mapping, 1200×900
Authentication
Delegated to the home institution through SAML or OIDC. We never hold a researcher's primary credential.
Authorisation
Held by the facility. Federation tells us who someone is; the project and allocation model decide what they may run.
Attributes
Release is negotiated per partner and often minimal. Design for the attributes you will actually receive, not the ones the specification allows.
Persistence
Data, DOIs and audit trails outlast an affiliation. Internal identifiers are stable even when a federated identity disappears.

What we build on

Australian research federation through the AAF, with international reach via eduGAIN, covers most of the population. The remainder — industry partners, honorary appointments, international collaborators without a federated home, and students on short placements — is where the design effort actually goes.

  • Shibboleth or OIDC service provider integration, with AAF and eduGAIN metadata
  • ORCID captured at registration so compute can be tied to published output
  • A documented path for collaborators with no federated identity, with sponsorship and an expiry date
  • Group and project mapping driven by the allocation model, reviewed on a schedule
  • Multi-factor enforcement for administrative and data-egress paths, and for interactive shell access
  • Browser-based access for users who should not need to learn a scheduler to run a notebook

The leaver problem, stated honestly

Federation revokes authentication promptly and tells the facility nothing about why. A researcher who moves institutions can lose access to their own in-flight work overnight. We handle that with a defined grace period, project ownership that sits with the project rather than the person, and a documented handover step at close-out.

Climate, weather & earth systems

Three workloads that look alike and stress nothing alike.

Earth-system work is usually described as one thing. In IO terms it is at least three, and a cluster tuned for one of them will disappoint on the other two. Sizing starts by asking which of these dominates.

One long job, tightly coupled

Atmosphere, ocean, ice and land components exchange state every model step. Performance is set by the slowest link in the halo exchange, so interconnect latency and consistent routing matter more than aggregate bandwidth. A single degraded cable can cost a fortnight of throughput without triggering an alarm.

Sensitive to
MPI collective latency, interconnect topology, node placement, jitter from other tenants
IO shape
Periodic synchronised writes of restart and history files. Bursty, wide, and coordinated across every rank
What we tune
Topology-aware placement, collective algorithm selection, Lustre or BeeGFS stripe alignment to the write pattern, restart cadence against queue limits
Reliability requirement
Checkpoint and restart that actually works, because these runs outlive any sane wall-clock limit

Codes in this class — models in the ACCESS family, WRF for regional atmosphere, MOM for ocean, CICE for sea ice — have well-understood scaling characteristics. We benchmark yours at your resolution rather than quoting a published curve from a different machine.

Diagram — coupled model component exchange and synchronised restart write pattern across ranks, 1200×900

Research data management

FAIR is an infrastructure requirement, not a paperwork exercise.

Findable, accessible, interoperable and reusable are all decided by choices made during the run — identifiers, metadata capture, file layout, retention. Retrofitting them at publication is where the cost and the frustration live.

The data lifecycle we build for

Plan before allocation is granted

A project's data management plan states expected volume, sensitivity, retention and destination repository. We ask for it at allocation time because those four facts determine which storage tiers the project should touch at all.

Capture metadata at the point of creation

Instrument settings, model configuration, software versions and parameters are written alongside the output by the workflow. Nobody reconstructs this accurately two years later, and reviewers increasingly ask.

Identify everything that will be cited

DOIs for data sets, ORCID for people, and persistent internal identifiers for projects and runs. Minting happens through your institutional repository or national service; our part is making the identifier travel with the data.

Separate working data from the record

Scratch is fast, expensive and deliberately impermanent, with an enforced expiry the users know about. The retained record lives on a different tier with different guarantees, integrity scrubbing and a tested restore path.

Make the result reproducible by someone else

Container images by digest, the workflow at a tagged revision, input checksums and the exact software environment are archived with the outputs. Reproducibility that depends on one person's home directory is not reproducibility.

Retain, hand over or destroy on schedule

Retention obligations under funder and institutional policy commonly run many years past the project. We implement the schedule, evidence each action, and include snapshots and backups, which are where undocumented copies survive.

An honest limit. We can build storage that makes FAIR practice straightforward and cheap to comply with. We cannot make a research group describe their data. Facilities that succeed at this pair the infrastructure with people whose job is to help — which is a budget line, not a platform feature.

Procurement & the funding cycle

Capital arrives in a lump. The facility has to last seven years.

Research infrastructure funding is granted once, spent quickly, and then operated from an ongoing budget that was estimated before anyone knew what the workload would be. This shapes every sensible design decision.

Spending the whole grant on nodes is how a facility ends up with a full machine room and no power budget in year four.
Design principle eResearch practice, Cloud Natives

What we hold back from the capital spend

A grant that buys the maximum number of nodes at day one produces a facility that cannot be extended, cannot absorb a new accelerator generation, and has no margin for the spares and staff the next six years require. We size to leave headroom in power, cooling, rack space and network ports.

Year 0
Commission a smaller system than the budget allows. Hold reserve for a mid-life expansion once the real workload mix is known.
Years 1 to 2
Measure everything. Utilisation, queue wait, job shapes and storage growth become the evidence for the next funding round.
Years 3 to 4
Expand into the reserved headroom with current-generation hardware, rather than replacing a whole estate at once.
Years 5 to 7
Oldest nodes move to opportunistic and teaching use. Support and spares strategy matters more than peak capability.
Throughout
Power and cooling costs are modelled and reported, because they are the operating expense most often absent from the original business case.

People are part of the infrastructure

A tuned cluster with no research software engineering support delivers a fraction of its capability, because most research code is written by domain specialists under deadline. We include training, documentation written for the actual user population, and retained engineering time for code optimisation in the operating model. It is the highest-return line in the budget and the first one cut.

  • Onboarding for users who have never seen a scheduler, taught against your own cluster
  • Profiling and optimisation clinics for groups whose codes dominate utilisation
  • Documentation maintained as configuration changes, not written once at handover
  • Retained engineering hours the facility can direct where the queue is hurting

Sensitive research data

Open by default, except where it must not be.

Most research data should be as open as possible. A minority carries obligations that open infrastructure cannot satisfy, and a shared multi-institution facility is precisely where those obligations get missed.

Export controls and dual-use research

Australia's defence trade control framework, and the Defence and Strategic Goods List it references, can apply to research and to the supply of technology, including in some circumstances to sharing it with a foreign national inside Australia. Whether a given project is caught is a legal question for your research office, not for us.

What we build for it
Separated project environments with nationality-aware access control, no shared scratch, and egress that is logged and reviewable.
Why it is hard here
Shared facilities are built for openness. Retrofitting a controlled project onto an open cluster usually means a distinct environment, not a tighter permission.
Where our advice stops
We do not assess whether a project falls under export control, and no infrastructure vendor should offer to.

Indigenous data sovereignty and the CARE principles

Data about Aboriginal and Torres Strait Islander peoples, lands, languages and cultural knowledge carries governance obligations that FAIR does not address. The CARE principles — collective benefit, authority to control, responsibility and ethics — sit alongside FAIR, and in this context authority to control is the one that changes architecture.

Community authority
Access decisions rest with the relevant community or its nominated body. The platform has to be able to delegate an access decision outside the institution.
Conditional and revocable access
Permission may be granted for a purpose and later withdrawn. Access that cannot be withdrawn, including from copies and derivatives, does not meet the requirement.
Provenance and labelling
Cultural context and use conditions travel with the data as metadata, so a future user encounters them before the data.
Location and custody
Some collections should be held under community custody rather than institutional custody. That is an architecture decision, and it is available.

We are infrastructure engineers, and we take direction on these matters from the communities concerned and from the researchers accountable to them. Our commitment is that the platform will not be the reason a governance decision cannot be honoured.

Diagram — open shared cluster beside a separated controlled project environment, showing distinct scratch, identity path and reviewed egress, 1200×900
Ask us for this in writing. Any claim about our assessment status, cleared personnel or prior controlled-project experience belongs in a tender response with details you can check, not on a web page. Treat a badge as unverified until you have done so.

Questions we get asked

Usually by the person who has to chair the allocation committee.

These come up in every shared-facility conversation. Where the answer is uncomfortable, the discomfort is the useful part.

Let's Talk

Bring us the partner agreement and last year's accounting export. The design falls out of those two.

We will profile your real job mix, draft an allocation model your partners can read, and give you a seven-year cost picture that includes power, spares and the people. If the answer is that you need less hardware than you planned, we will say so.

Research & academia enquiries
hello@cloudnatives.example
Direct line
+61 0 0000 0000
Existing facilities — 24/7 NOC
+61 0 0000 0001

Australian owned and staffed. We are comfortable presenting to an allocation committee rather than a procurement panel.