Architecture

Components

This diagram represents all Slurm-web components with their respective roles and integration with Slurm workload manager:

Slurm-web architecture with components roles [ SVG]

Slurm-web is based on 3 components:

agent: Sends requests to Slurm slurmrestd service which exposes a REST API for slurmctld and slurmdbd daemons. The agent is also in charge of the authorizations enforcement and acts as a caching layer over Slurm.
gateway: Performs user authentication and acts as a reserve proxy for the agents.
frontend: The representation layer for the user interface. It is actually served by the gateway application and executed on client side in web browsers.

The gateway and frontend components are bundled together in the Slurm-web gateway system package and container image for simplicity. See Deployment section for more details.

Integration

In addition to Slurm workload manager, Slurm-web interacts with some other external services and data sources:

Slurm-web integration with external components [ SVG]

The gateway component authenticates users with either:

LDAP — enterprise directories such as OpenLDAP, FreeIPA, and Active Directory, including legacy NIS and RFC 2307 bis schemas for groups.
OIDC — single sign-on (SSO) with OpenID Connect identity providers such as Keycloak or Authentik.

The agent component reads the RBAC autorization policy from a plain INI file with permissions associated to roles and LDAP groups.

Optionally, the agent can also:

Extract cluster racking topology from RacksDB database to generate interactive graphical representation of nodes status in the racks.
Connect to Redis in-memory key/value database to save cached data from Slurm.
Integrate with Prometheus (or compatible) by exporting various Slurm metrics for storage in timeseries database. The agent can then query this database to get historical values of these metrics.

Protocols

Protocols and authentication realms involved in communications between Slurm-web and Slurm components are represented in this diagram:

Protocols in communication between Slurm-web components [ SVG]

All communications from the clients web browsers to Slurm-web agent component are performed with HTTP over TCP/IP network protocols. These network communications can be secured with SSL/TLS (aka. HTTPS) over standard port TCP/443 with a production HTTP server. After initial authentication at the gateway with LDAP or OIDC, users are authenticated between these components with JSON Web Token (JWT). Slurm-web has its own JWT realm, with its dedicated JWT signing key, to secure communication between its components.

Slurm slurmrestd supports incoming HTTP requests on:

TCP/IP socket, with rest_auth/jwt authentication and tokens signed by Slurm JWT signing key.
Unix socket, with two authentication methods: rest_auth/jwt and rest_auth/local (deprecated) in which slurmrestd authenticates users with client process UID/GID.

Slurm-web agent supports all these combinations of sockets and authentication methods. Please refer to slurmrestd access configuration page for more details.

Slurm components communicates with specific binary RPC protocol over TCP/IP sockets, secured by either Munge or Slurm internal mechanism. When JWT authentication is used between Slurm-web agent and Slurm slurmrestd service, the auth/jwt alternative authentication type must also be enabled in main Slurm and slurmdbd configuration.

Multi-clusters Distribution

Slurm-web is designed to support natively multiple HPC clusters with a central dashboard. In this configuration, the components are distributed as represented in this diagram:

Slurm-web distribution on multiple clusters [ SVG]

In this configuration, the agent component must be deployed on all clusters collocated with Slurm slurmrestd daemon. An agent interacts with only one Slurm cluster.

The gateway can be deployed on a central server. It distributes the requests to the agents deployed on the clusters.

Deployment

Slurm-web is distributed as system packages and as OCI container images for the agent and gateway components. This section describes where these components run in common deployment topologies. The same component split applies with both system packages and container images.

Single cluster — collocated with Slurm

All Slurm-web components run on the same host as Slurm services (slurmrestd, slurmctld and slurmdbd), typically the admin node of the cluster:

slurm web deployment mono cluster collocated

Slurm-web deployment on a single cluster [ SVG]

In this architecture, deploy the agent and gateway Slurm-web components on the Slurm controller host.

This is the simplest deployment topology and is recommended for small clusters.

The frontend component is included with the gateway component, both in the slurm-web-gateway package and in the slurm-web-gateway image. There is no separate frontend deployment artifact.

Single cluster — separate server

Slurm-web components are deployed on a dedicated host (bare-metal, virtual machine, or container host). Multiple deployment topologies are possible: Slurm-web can be separated from Slurm services, collocated with slurmrestd only, or the Slurm-web components themselves (agent and gateway) can run on separate hosts.

slurm web deployment mono cluster separated

Slurm-web deployment on a single cluster with separate server [ SVG]

When slurmrestd is not collocated with Slurm-web, slurmrestd must be configured to listen on a TCP/IP socket (ie. not on Unix socket). Please refer to slurmrestd access configuration page for more details.

Multiple clusters

Each cluster has its own agent collocated with its slurmrestd service. The central gateway routes user traffic to the appropriate agent:

Slurm-web deployment on multiple clusters [ SVG]

On each cluster, deploy one agent component. On the central Slurm-web host, deploy the gateway component.

The gateway must be configured with all agents’ URLs and serves the single frontend for all clusters. Please refer to gateway configuration page for more details.
As in single cluster deployment topology, the agent component and Slurm services can be collocated on the same host or separated.

Slurm REST API versions

Slurm-web 7.0.0 is officially tested and supported with Slurm REST API versions from v0.0.41 to v0.0.45. These versions of Slurm REST API are available in Slurm major versions 24.05, 24.11, 25.05, 25.11 and 26.05.

This table represents all Slurm REST API versions supported by the latest Slurm releases:

REST API versions by Slurm releases
Slurm releases	Supported API versions
Slurm releases	Latest	Compatible		Deprecated
26.05	0.0.45	0.0.44	0.0.43	0.0.42
25.11	0.0.44	0.0.43	0.0.42	0.0.41
25.05	0.0.43	0.0.42	0.0.41	0.0.40
24.11	0.0.42	0.0.41		0.0.40
24.05	0.0.41	0.0.40		0.0.39
23.11	0.0.40	0.0.39		0.0.38