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
slurmrestd
service which exposes a REST API forslurmctld
andslurmdbd
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.
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 entreprise 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. The component also extracts cluster racking topology from RacksDB database to generate graphical representation of nodes status in the racks.
Optionally, the agent can connect to Redis in-memory key/value database to save cached data from Slurm. It can also 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 used for communication 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).
Communications between agent component and Slurm slurmrestd
daemon are
performed with HTTP protocol over a Unix socket. For security reasons
slurmrestd
checks the agent runs with the same UID/GID as itself with its
rest_auth/local
plugin.
Slurm slurmrestd supports incoming connections on TCP/IP sockets with
rest_auth/jwt plugin but this configuration is not yet supported by Slurm-web.
This is currently a limitation in Slurm-web that might change in the future (see
#313).
|
Slurm components communicates with specific binary RPC protocol over TCP/IP sockets, secured by either Munge or Slurm internal mechanism.
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.
Slurm REST API versions
Slurm-web 4.0.0 is officially tested and supported with Slurm REST API v0.0.40. This version of Slurm REST API is available in Slurm 23.11, 24.05 and 24.11.
This table represents all Slurm REST API versions supported by the latest Slurm releases:
Slurm releases |
Supported API versions |
||
Latest |
Compatible |
Deprecated |
|
23.02 |
0.0.39 |
0.0.38 |
0.0.37 |
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 |