RosettaCloud™ HPC
Clusters without a cluster team
Size the cluster
to the science.
A fixed cluster is a guess about next year, and it is wrong in both directions: too small when the deadline arrives, idle for the months either side. Run the work on capacity that grows with the queue and disappears when it drains.
What it changes
The queue stops being the bottleneck
Capacity follows demand instead of a number somebody committed to three years ago.
No cluster team required
The scheduler, the network and the storage are built for you. Nobody on staff has to know how.
Idle time stops being expensive
The cluster shrinks when the queue drains, so the weeks between campaigns cost close to nothing.
Results without moving the data
Visualisation and post-processing run on the cluster, in a browser, next to the files they need.
Your scheduler.
Your image. Your jobs.
The point of moving is more capacity, not a new way of working. Nobody rewrites a submission script and nobody rebuilds an environment that already took years to get right.
The scheduler they know
Chosen by you, installed and configured for you. Jobs are submitted the same way they were last week.
The software stack you have
Bring your own image rather than reproducing a decade of accumulated setup on somebody else’s template.
The file systems you use
Shared storage managed for you, or brought from the estate you already run, so jobs find their data where they expect it.
Pick the tools.
Not the setup.
A cluster reachable only over a terminal is a cluster only some of your people can use. Choose the applications you want when you describe the cluster, and they are running on it the moment it exists.
Notebooks and a desktop
Jupyter, RStudio, a terminal or a full graphical desktop, opened in a browser against the cluster rather than over a connection somebody has to set up first.
Several of them at once
You are not picking one. Choose the set the work needs and move between them, all against the same cluster.
Two people in one session
A collaborative RStudio session takes more than one person, so working through a failing job becomes a conversation rather than an exchange of screenshots.
Your own tools alongside them
Your container images, startup scripts and environment, so an in-house tool arrives with the standard ones instead of being installed afterwards.
Nothing is installed by hand, and nothing has to be installed again when the cluster is replaced next month.
It comes up connected
Most of the time between having a cluster and using one goes on the work between the pieces. That part is done for you, identically on every cloud.
Storage is already mounted
Attach the storage a cluster needs and it is there at its path when the cluster comes up. Nobody edits a mount table, copies data in, or explains to the next person where the files went.
There are no keys to hand out
Cloud keys are held by the platform, not by the people using it. Nobody is emailed a private key, nobody stores one on a laptop, and there is nothing to rotate or to leak.
Certificates are issued and attached
A service that should be reachable over HTTPS comes up that way, without a certificate request, a renewal reminder, or an expiry nobody noticed until it broke.
It has a name, not an address
DNS records are created on the domains you have mapped, so people reach the cluster by a name that means something and keeps working when the machine behind it changes.
And you can share it while it is running
A live cluster is shared with a colleague, a group or a whole organisation the way a document is. They get access to the thing itself, not a copy of it and not a rebuild of it, and that access ends when the share does.
See how sharing works →A cluster is the easiest thing
in the cloud to leave running
It is also among the most expensive, which is why the money question decides whether a group moves at all.
Refused, not reported
A cluster launched beyond budget fails at the cloud’s own API. The overspend does not happen, so nobody has to explain it.
Spare capacity where it fits
Batch work that can be requeued runs on spot, which is exactly the workload spot was designed for.
Every hour has an owner
Cost lands on the person and the grant that ran the job, so the funder’s question is answered from a report.
The same arrangement works for the group that submits one job a month and the group that never stops.
Your accounts, your rates,
your credits
Clusters are built in your own cloud accounts and billed to you by the provider. Whatever you have already negotiated still applies, research credit programmes keep working, and no data leaves your estate to reach us.
Common questions
Do we need someone who can run an HPC cluster?
No. The cluster is described once and built for you, including the network if you do not bring one. Researchers submit jobs to the scheduler exactly as they always have, and nobody has to become a cluster administrator to make that possible.
What do we pay for between jobs?
Very little. Compute grows with the queue and drains back down when the work is done, so an idle cluster is a small one. Batch work that tolerates interruption can run on spare capacity, where an interruption costs minutes rather than the run.
Will our existing jobs and software work?
Yes. You choose the scheduler, and you can bring the image your group has spent years building rather than rebuilding it. Submission scripts, modules and shared file systems work the way they do today.
Who is billed, and what stops a cluster overrunning?
It runs in your own cloud account and your provider bills you directly at your own rates. Cost is attributed to the person and project that launched it, and a cluster that would take the account over budget is refused at the cloud API rather than discovered on the invoice.