Architecture
Components
This diagram represents all Slurm-web components with their respective roles and integration with Slurm workload manager:
Slurm-web is based on 3 components:
-
agent: Sends requests to Slurm
slurmrestdservice which exposes a REST API forslurmctldandslurmdbddaemons. 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 actually bundled together in the Slurm-web gateway package for simplicity reason. See Deployment section for more details. |
Integration
In addition to Slurm workload manager, Slurm-web interacts with some other external services and data sources:
The gateway component authenticates users with an enterprise LDAP directory. Slurm-web supports all major LDAP services implementation such as OpenLDAP, FreeIPA and Active Directory with legacy NIS and RFC 2307 bis schemas.
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:
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 with LDAP directory, 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/jwtauthentication and tokens signed by Slurm JWT signing key. -
Unix socket, with two authentication methods:
rest_auth/jwtandrest_auth/local(deprecated) in whichslurmrestdauthenticates 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:
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 installed on a central server. It distributes the requests to the agents deployed on the clusters.
Deployment
This section lists which Slurm-web packages must be installed on which servers for common deployment topologies. Package names below refer to distribution packages available via the supported repositories.
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:
In this architecture, install the following Slurm-web packages on the Slurm controller host:
-
slurm-web-agent -
slurm-web-gateway
This is the simplest deployment topology and is recommended for small clusters.
The frontend component is included in the slurm-web-gateway package,
there is no need to install a separate frontend package.
|
Single cluster — separate server
Slurm-web components are installed on a dedicated host (bare-metal or virtual
machine). Multiple deployment topologies are possible: Slurm-web can be
separated from Slurm services, or collocated with slurmrestd only, or
Slurm-web components can be even separated themselves (agent and gateway).
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:
On each cluster, install the slurm-web-agent package. On the central Slurm-web
host, install the slurm-web-gateway package.
|
Slurm REST API versions
Slurm-web 5.1.0 is officially tested and supported with Slurm REST API v0.0.41. This version of Slurm REST API is available in Slurm 24.05, 24.11 and 25.05.
This table represents all Slurm REST API versions supported by the latest Slurm releases:
Slurm releases |
Supported API versions |
||
Latest |
Compatible |
Deprecated |
|
23.11 |
0.0.40 |
0.0.39 |
0.0.38 |
24.05 |
0.0.41 |
0.0.40 |
0.0.39 |
24.11 |
0.0.42 |
0.0.41 |
0.0.40 |
25.05 |
0.0.43 |
0.0.42 |
0.0.41 |