Marcio Cunha

Implementation of a High-Performance Computing Cluster with InfiniBand and Slurm Workload Manager on Local Hardware

Learn how to design, assemble, and configure a high-performance computing cluster using low-latency InfiniBand networks and the Slurm workload manager on local servers. This guide details hardware decisions, network configuration, and parallel job submission.

Marcio Cunha5 min
Also available in:PortuguêsEspañol
Summary
  • InfiniBand networks drastically reduce communication latency between nodes by offloading network processing directly to hardware.
  • The Slurm queue manager intelligently distributes heavy calculations considering physical topology and available memory.
  • Proper configuration of switches and subnets prevents critical bottlenecks during large-scale scientific simulations.
  • Shared storage via NFS or Lustre ensures all nodes access the same data simultaneously without corruption.
  • Stress tests with dedicated tools validate cluster stability before submitting production workloads.

Introduction to Local Hardware for High-Performance Computing

Building a high-performance computing cluster, commonly known as HPC, within your own infrastructure requires balancing raw processing expectations, cooling capacity, and energy costs. In practice, this means linking several ordinary computers or dedicated servers using ultra-high-speed cables so they work together as if they were a single giant machine. When dealing with complex fluid dynamics simulations, artificial intelligence, or weather forecasting, no single isolated computer has enough memory or processing speed to finish the job in a reasonable timeframe. The goal of this architecture is to slice the mathematical problem into hundreds of smaller pieces, dispatch each piece to a different server, and seamlessly assemble the results at the end.

For this union to work without computers sitting idle waiting for others to finish, physical component selection determines project success or failure. Processors with dozens of cores, motherboards with multiple memory channels, and redundant power supplies form the backbone of each compute node. However, the component that usually separates an expensive pile of computers from a truly efficient cluster is the communication network. If computers take too long to talk to each other, waiting time exceeds actual calculation time, completely negating the advantage of using multiple machines.

The InfiniBand Network Architecture and Bottleneck Elimination

In traditional computer networks based on twisted-pair cables and the Ethernet protocol, every message sent from one server to another must pass through multiple software layers inside the operating system, generating noticeable delay. To solve this problem in scientific environments, we use InfiniBand, a specialized network technology that transfers data directly between the memory of one computer and the memory of another without burdening the central processor. In practice, this is like replacing a traffic-light-filled road with an exclusive bullet train line directly connecting the living rooms of two distant houses.

The core component of this fast network is the host channel adapter, known as HCA, installed in each server and connected to a dedicated InfiniBand switch using high-density fiber optic or copper cables. This physical arrangement delivers bandwidths easily exceeding tens of gigabits per second, with latencies measured in fractions of microseconds. By eliminating traditional software interrupts, InfiniBand allows parallel applications to synchronize their calculation states almost instantaneously. This feature is vital for simulations where one node cannot advance to the next time step without receiving the exact particle positions calculated by its neighboring node.

Network Subsystem Configuration and Subnets

Physical deployment of InfiniBand requires configuring the subnet manager, an essential software called OpenSM running in the background to map all connected devices and assign efficient traffic routes. Without this active manager, servers simply cannot see each other across the high-speed cables. Below, we present a practical example of commands executed in the Linux terminal to install and start the OpenSM subsystem on a dedicated management node:

sudo apt-get update && sudo apt-get install -y infiniband-diags opensm ibverbs-utils
sudo systemctl enable opensm
sudo systemctl start opensm
ibstat

After starting the subnet manager, the ibstat command verifies that the local HCA adapter is active and operating at the maximum speed supported by the hardware. It is fundamental to inspect the output of this command to confirm that the physical link state indicates 'Active' and that the transfer rate matches the installed standard, such as FDR or EDR. Otherwise, cable seating issues or optical transceiver failures can limit the cluster to much lower speeds, compromising the entire investment in specialized hardware.

Installation and Configuration of the Slurm Workload Manager

With the high-speed network operating seamlessly, the next step involves installing Slurm, an open-source queue manager and job scheduler widely used worldwide. In practice, Slurm acts like the manager of a highly busy factory: it receives processing requests submitted by researchers, checks which servers are free, organizes the waiting queue by priority order, and allocates the necessary computational resources. Without an intelligent scheduler, users would manually contend for server usage, causing memory conflicts and wasting idle time.

Installing Slurm involves configuring three main entities: the primary controller managing global cluster state, daemons running on each compute node to monitor local hardware, and the unified configuration file slurm.conf. Below is a simplified excerpt of the slurm.conf configuration file defining the basic topology of nodes and processing partitions:

ClusterName=hpc-local
ControlMachine=master-node
SlurmUser=slurm
SlurmdUser=root
AccountingStorageType=accounting_storage/none
NodeName=compute-[01-04] CPUs=32 RealMemory=131072 State=UNKNOWN
PartitionName=debug Nodes=compute-[01-04] Default=YES MaxTime=INFINITE State=UP

In this file, we define four compute nodes named compute-01 through compute-04, each equipped with 32 processing cores and 128 gigabytes of RAM. The partition named debug allows users to submit quick tests to verify if their parallel codes are working before submitting long simulations that consume hours of continuous processing. Communication between the main controller and compute nodes occurs via predefined TCP ports, requiring the local firewall to permit these control connections.

Efficient management of shared memory and disk space complements the cluster infrastructure. Because nodes need to read massive input files and write partial results simultaneously, a distributed file system based on NFS or Lustre must be configured on the same high-speed network. This prevents a single server's local hard drive from becoming the major performance bottleneck of the entire operation. Validating the operation of the entire ecosystem with test jobs ensures long-term stability and maximum productivity for the engineering and research team.

Final Considerations and Continuous Cluster Operation

Maintaining a high-performance computing cluster operating on local hardware requires constant monitoring of temperature, electrical consumption, and network cable integrity. The combination of InfiniBand networks and the Slurm manager delivers a robust platform capable of competing with large corporate data center infrastructures, provided preventive maintenance is rigorous. With the architecture properly sized and configured, researchers and engineers gain total autonomy to execute complex simulations quickly, securely, and highly scalably.