Use case · HPC & scientific compute
HPC clusters
An HPC cluster links many compute nodes to solve large parallel problems — simulations, modelling, scientific computing. It is defined as much by fast, low-latency interconnect between nodes as by the cores themselves, plus high-throughput storage and job scheduling. Bare metal suits HPC for its full performance, and EU hosting keeps research data sovereign.
Key points
- An HPC cluster links many compute nodes to work together on large parallel problems.
- Fast, low-latency interconnect between nodes is as defining as the cores themselves.
- Tightly-coupled jobs pass messages between nodes, so slow interconnect stalls them.
- HPC needs high-throughput shared storage and a scheduler to run jobs across the cluster.
- Bare metal suits HPC because virtualisation overhead costs performance that HPC cannot spare.
What is an HPC cluster, and what does it need?
High-performance computing, or HPC, tackles problems too large for a single machine by linking many compute nodes into a cluster that works on them together. HPC is the domain of large simulations, scientific and engineering modelling, numerical computation, and similar workloads that need far more compute than one server provides. An HPC cluster brings together many nodes — each a capable computer in its own right — and coordinates them to attack a single large problem in parallel, so that the combined power of the cluster solves what no single node could in reasonable time.
Building an HPC cluster means providing more than a pile of servers. The nodes must be able to communicate quickly, because many HPC problems require the nodes to exchange data constantly as they compute; the cluster needs storage that can feed large datasets to many nodes at once; and it needs a way to schedule jobs across the shared nodes. So HPC infrastructure is defined by its compute nodes, the interconnect between them, high-throughput storage, and job scheduling, working together as a coordinated system. Getting the balance right across these is what distinguishes a real HPC cluster from a collection of unconnected servers.
Compute: many cores across many nodes
The compute in an HPC cluster comes from many processing cores spread across many nodes, aggregated to a scale far beyond a single machine. Modern server processors offer high core counts — AMD EPYC processors, for instance, provide many cores per socket — and an HPC node packs substantial compute, while a cluster of many such nodes multiplies that across the whole system. The total core count of a cluster can be enormous, which is what lets HPC handle problems that decompose into large numbers of parallel computations, each core doing its share.
Some HPC workloads are CPU-bound and run across large numbers of CPU cores, while others are accelerated by GPUs, which suit the parallel mathematics of certain scientific and engineering problems as they do for deep learning. Many HPC clusters therefore combine high-core-count CPU nodes with GPU nodes, matched to the workloads they run. Specifying HPC compute means choosing processors and node configurations suited to the problems — high core counts where the work is CPU-parallel, GPUs where it benefits from them — and providing enough nodes to reach the scale the problems demand. The compute is the raw capability, which the rest of the cluster exists to connect and feed.
Interconnect: the defining constraint for HPC
What most distinguishes HPC from merely having many servers is the interconnect between nodes, because many HPC problems require the nodes to communicate constantly as they compute. In a tightly-coupled parallel computation, each node works on part of the problem but must exchange intermediate results with others frequently, so the speed and latency of the communication between nodes directly limits how fast the whole computation runs. If the interconnect is slow or high-latency, the nodes spend time waiting on one another rather than computing, and the cluster fails to deliver the performance its raw compute suggests.
This is why HPC clusters use high-performance, low-latency interconnect between nodes, rather than ordinary networking. Interconnect technologies built for HPC provide the high bandwidth and, critically, the low latency that tightly-coupled workloads need, so that nodes can exchange data fast enough to keep computing rather than waiting. For HPC, the interconnect is not a secondary detail but a defining part of the cluster — a cluster with fast nodes and slow interconnect will underperform on the coupled workloads HPC is built for. When we build HPC infrastructure, the interconnect is specified as carefully as the compute, because for HPC it determines whether the nodes actually work together well.
Parallel processing and how HPC jobs run
HPC workloads run by dividing a problem across the cluster's nodes and cores, which then compute in parallel and coordinate their work. A common model uses message passing, where the parts of a job running on different nodes exchange messages to share data and synchronise, coordinating the distributed computation. This is how a single large problem is spread across many nodes: it is decomposed into parts, each node computes its part, and the nodes communicate to combine their work into the overall result. The efficiency of this depends on how well the problem parallelises and how fast the nodes can communicate.
Because coordination between nodes is intrinsic to these workloads, HPC performance depends on both the compute and the communication, which is why interconnect matters so much. A job that parallelises well across nodes, on a cluster with fast interconnect, scales up to use many nodes effectively; one hampered by slow communication scales poorly, gaining little from added nodes. Understanding how HPC jobs run — decomposed across nodes that compute in parallel and coordinate — clarifies why an HPC cluster is a tightly integrated system rather than independent servers, and why its interconnect and compute must be balanced for the coupled, parallel work it does.
High-performance storage for HPC
HPC workloads often involve large datasets that many nodes must read from and write to, so HPC clusters need storage that can deliver high throughput to many nodes at once. A simulation may read large input data and write large results; many nodes may access shared data simultaneously; and if the storage cannot keep up, the nodes wait on it, wasting compute. HPC therefore uses high-throughput, often parallel, storage designed to serve many nodes concurrently at the rates the compute demands, so that data access does not bottleneck the cluster.
Providing this means storage sized and architected for the cluster's data needs, not ordinary single-server storage. Parallel and shared storage systems let many nodes access data at high aggregate throughput, feeding the cluster's compute; capacity must suit the large datasets HPC works with; and the storage has to be accessible across the cluster's nodes. As with interconnect, underprovisioning storage undercuts the compute, so HPC storage is a first-class part of the cluster's design. When we build HPC infrastructure, the storage is specified for the throughput and capacity the workloads need, so that the cluster's nodes are fed rather than left waiting on data.
Job scheduling on an HPC cluster
An HPC cluster is a shared resource that runs many jobs, often from many users, so it needs a scheduler to manage which jobs run on which nodes and when. HPC work is typically submitted as jobs to a batch scheduler, which queues them and allocates the cluster's nodes to them according to their needs and the cluster's policies, so that the shared cluster is used efficiently and fairly. The scheduler is central to how an HPC cluster operates, turning a set of nodes into a managed resource that serves a stream of computational jobs.
This scheduling lets an HPC cluster be used well by many users and jobs, allocating its nodes to the work that needs them and keeping the expensive cluster busy. Jobs wait in a queue when the cluster is full and run when nodes are free, with the scheduler enforcing fair sharing and priorities. Providing an HPC cluster therefore includes providing for this scheduling — the batch scheduler that coordinates jobs across the nodes — since without it, coordinating many jobs on a shared cluster would be unmanageable. When we host HPC infrastructure, the scheduling that makes the cluster a usable shared resource is part of what the cluster provides.
Why bare metal suits HPC
HPC is a workload where bare metal — dedicated physical servers without a virtualisation layer — is strongly preferred, because HPC extracts maximum performance from hardware and virtualisation overhead costs performance HPC cannot spare. Running on virtualised infrastructure adds a layer between the workload and the hardware, which imposes some overhead and can interfere with the fine control over hardware and the predictable performance that tightly-coupled HPC workloads depend on. For HPC, where the goal is to get the fullest performance from the compute and interconnect, that overhead and unpredictability are real costs.
On bare metal, HPC workloads run directly on the hardware, obtaining its full performance and the direct access to compute and interconnect that HPC needs. This is why HPC has traditionally run on dedicated bare-metal clusters: the workloads are performance-critical and tightly coupled, and bare metal gives them the unmediated hardware access and predictable performance that virtualisation would compromise. We host HPC on dedicated bare-metal servers for exactly this reason, so that the cluster delivers the full performance of its hardware to the demanding, coupled workloads HPC runs. For HPC, the case for bare metal is particularly strong, and it is the foundation on which we build HPC clusters.
Cost, sovereignty, and research data
HPC clusters represent substantial infrastructure, and their economics reward sustained use: a cluster kept busy with a steady stream of jobs is cost-effective, while one mostly idle is expensive for what it delivers. Because HPC clusters are typically shared among many users and jobs through scheduling, they tend to be kept well-utilised, which suits dedicated infrastructure at a fixed cost — the cluster is busy, and dedicated hardware serves that steady, heavy use economically. For the sustained, shared use typical of HPC, dedicated bare-metal clusters are usually the economical choice over on-demand rates for continuous heavy compute.
Sovereignty matters for HPC because much of it serves research and computation on sensitive or valuable data. Scientific, engineering, and research computation may involve confidential, proprietary, or regulated data, and where the HPC runs governs that data. VV Internet Hosting is incorporated in the Netherlands, within the EU, so HPC hosted with us runs under European jurisdiction and outside the direct reach of the US CLOUD Act. For research and computation on sensitive data — as much HPC is — keeping the cluster and its data in the EU keeps them under European law, which matters to institutions and organisations for whom the sovereignty of their research data and computation is a real concern.
Where VV Internet Hosting fits — and where it does not
We host dedicated bare-metal HPC clusters: high-core-count CPU nodes and GPU nodes where suited, connected by fast low-latency interconnect for tightly-coupled work, with high-throughput storage and job scheduling to run jobs across the cluster — in EU datacenters under European jurisdiction. This suits sustained HPC and research computing, where dedicated bare metal delivers the full performance HPC needs and keeps it economical, and where the data involved makes European sovereignty matter. For that, we are a strong fit, and we will size the nodes, interconnect, and storage to the workloads the cluster will run.
We are clear about our limits. If your HPC need is occasional — a burst of computation now and then rather than sustained use — on-demand HPC capacity may suit better than a dedicated cluster kept for intermittent use, and we will say so. If you need a national supercomputing facility's scale, or a hyperscaler's managed HPC services and their proprietary ecosystem, that is a different kind of provider than we are. We are for dedicated, sovereignty-aware, bare-metal HPC infrastructure on hardware you control, suited to sustained research and computation — which serves many organisations and institutions well, though not every HPC need. If it matches yours, we can build the cluster; if not, we will point you toward what fits.
Questions
HPC clusters, answered plainly
Common questions about hosting for HPC clusters.
What makes an HPC cluster different from just many servers?
The interconnect. Many HPC problems require the nodes to communicate constantly as they compute, so the speed and latency of the connection between nodes directly limits how fast the whole computation runs. HPC clusters use high-performance, low-latency interconnect for this — a cluster with fast nodes but slow interconnect underperforms on the tightly-coupled workloads HPC is built for.
Why does HPC prefer bare metal?
HPC extracts maximum performance from hardware, and virtualisation adds a layer between the workload and the hardware that imposes overhead and can interfere with the fine hardware control and predictable performance tightly-coupled HPC needs. On bare metal, HPC workloads run directly on the hardware, getting its full performance — which is why HPC has traditionally run on dedicated bare-metal clusters.
Is a dedicated HPC cluster or on-demand capacity better?
It depends on how sustained the use is. HPC clusters shared among many jobs through scheduling tend to be kept busy, which suits dedicated bare-metal infrastructure at a fixed cost — economical for steady, heavy compute. Occasional HPC needs, a burst of computation now and then, may suit on-demand capacity better than a cluster kept for intermittent use.
Planning HPC clusters infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.