DOCSEARCHbyAlgolia
Submit Docs

Slurm-web Documentation

repository·main·Indexed 20 days ago

https://github.com/rackslab/slurm-web

An open-source web-based dashboard for managing and monitoring Slurm-based HPC clusters. Version 7.0.0 provides tools for job management, resource monitoring (including GPU utilization), cluster hierarchy visualization, and support for LDAP, OIDC (Keycloak, Authentik), and RBAC. The system includes an agent and gateway architecture with optional Redis caching and Prometheus integration for historical metrics.

Tokens
59.1K
Snippets
210
Records
293
Agent score
69%

What's inside Slurm-web

  1. Overview of Slurm-web features

    main

    Slurm-web is an open-source web dashboard designed for Slurm-based HPC (High-Performance Computing) clusters. It provides a graphical user interface to monitor job status, resource utilization, and cluster topology.

    Key features include:

    • Job Management: Interactive charts, instant filtering/sorting, live status updates, and colored status badges.
    • Resource Monitoring: GPU utilization monitoring and node status visualization using racking topology.
    • Cluster Hierarchy: Visualization of account trees, Quality of Service (QOS), and advanced reservations.
    • Authentication & Security: Support for LDAP (including Active Directory), SSO via OpenID Connect (OIDC) (e.g., Keycloak, Authentik), and advanced RBAC (Role-Based Access Control).
    • Extensibility & Integration: Multi-cluster support, Prometheus integration for time-series metrics, and custom UI branding (colors, logos, favicons).
    • User Experience: Dark mode support and responsive design for all devices.

  2. Monitor HPC clusters with Slurm-web

    main

    Slurm-web provides a comprehensive web interface for monitoring Slurm-managed HPC clusters. Key capabilities include:

    • Dashboard: High-level metrics for quick cluster status insights.
    • Multi-Cluster Support: Deploy on a central server to monitor multiple clusters from a single interface, allowing for easy switching and status comparison.
    • Job Monitoring: Visualize job statuses using colored badges, apply filters (state, user, account, QOS, partition), and sort by various criteria (priority, ID, etc.).
    • Live Updates: Track specific jobs with real-time progress updates and near real-time data fetching without page reloads.
    • Resource Visualization:
      • Nodes: Interactive graphical representation of racks (via RacksDB integration) with hoverable node details.
      • Cores: Granular view of CPU core allocation rates and availability per node.
      • GPUs: Real-time monitoring of GPU availability and allocation, optimized for AI/ML workflows.
    • Account & Policy Management: Visualize account hierarchies (parent/child relationships), inspect resource limits, view advanced reservations, and monitor QOS (Quality of Service) parameters and limits.

  3. Get started with Slurm-web

    main
    Slurm-web is an open-source web dashboard designed for Slurm-based High Performance Computing (HPC) clusters. It provides a graphical user interface (GUI) to monitor HPC supercomputer status, track jobs, and view advanced visualizations directly in a web browser across various devices. It acts as a visual layer on top of the Slurm workload manager.

  4. Configure RacksDB for advanced graphical representations

    main

    Slurm-web can use RacksDB to generate advanced interactive graphical representations of datacenter racks and compute nodes.

    To use RacksDB, ensure the following requirements are met in your database:

    1. The infrastructure name must match the cluster name previously declared in your agent configuration file.
    2. All compute nodes declared in your Slurm configuration must have the _compute_ tag assigned.

    You can customize the tag name used for RacksDB by declaring it in the [racksdb] section of your agent.ini configuration file.

    [racksdb]
tags=blade

  5. Use named volumes instead of bind mounts

    main

    Instead of host bind mounts, you can use Docker/Podman named volumes for persistent data. The internal container paths remain unchanged.

    Example for secrets:

    1. Create the volume: {runtime-cmd} volume create slurmweb-secrets
    2. Mount it in your run command: -v slurmweb-secrets:/var/lib/slurm-web

    If using named volumes for configuration, populate the volume with agent.ini and gateway.ini first. For secrets like slurmrestd.key, use a one-shot run command to copy the key into the volume before starting the main services.

    # Create a named volume for secrets
{runtime-cmd} volume create slurmweb-secrets

# Use it in a run command
{runtime-cmd} run -v slurmweb-secrets:/var/lib/slurm-web ...

  6. How LDAP authentication and group lookup works

    main

    When a user logs in via LDAP, the Slurm-web gateway validates credentials and retrieves group memberships to issue a JWT.

    Group Membership Layouts

    Slurm-web supports two primary LDAP layouts:

    1. RFC 2307 (NIS): Groups are typically posixGroup entries. Members are identified by memberUid (the login name). The user's primary group is identified by the gidNumber on the user entry.
    2. RFC 2307 bis: Groups often use groupOfNames. Members are identified by the member attribute (the full user DN).

    By default, the gateway searches under group_base for groups matching memberUid=<login>, member=<user DN>, or the user's primary gidNumber.

  7. Understand the Slurm-web component architecture

    main

    Slurm-web is composed of three primary logical components that work together to provide a web interface for Slurm:

    • agent: The core backend component. It sends requests to the Slurm slurmrestd service (which exposes the REST API for slurmctld and slurmdbd). It is responsible for enforcing authorizations (via an RBAC policy) and provides a caching layer over Slurm.
    • gateway: The entry point for users. It performs user authentication (LDAP or OIDC) and acts as a reverse proxy for the agents.
    • frontend: The representation layer for the UI. It is served by the gateway application and executed in the user's web browser.

    Note: For simplicity, the gateway and frontend are bundled together in the slurm-web-gateway system package and container image.

  8. Understand the limitations of the default production HTTP server

    main

    By default, Slurm-web is served using native Python HTTP services. While this setup is convenient for evaluation and testing, it is not recommended for production environments due to the following security and architectural limitations:

    • No TLS/SSL: Network communications are not secured with TLS.
    • No Production Web Server: The service is not integrated behind a robust production-grade HTTP server (like Nginx, Apache, or Caddy).

    For secure, production-ready deployments, you must use a WSGI-based setup behind a reverse proxy.

  9. Configure Slurmrestd access modes

    main

    Slurm-web connects to the Slurm slurmrestd service using different combinations of socket types, authentication methods, and token management modes.

    Socket Types

    • Unix socket: Requires the Slurm-web agent to be colocated with the slurmrestd service on the same host.
    • TCP/IP socket: Allows the Slurm-web agent and slurmrestd service to be hosted on separate hosts.

    Authentication Methods

    • local (deprecated): Uses the UID/GID of the client process. Warning: This method is deprecated and not supported in Slurm ≥ 25.05 because it requires running slurmrestd as the _slurm_ system user. Use jwt instead.
    • jwt: Uses tokens provided in HTTP request headers.

    JWT Token Management Modes

    • auto: The Slurm-web agent uses a copy of the Slurm JWT signing key to automatically generate short-lived tokens as needed.
    • static: An administrator manually generates a long-lived token and provides it in the agent configuration.

  11. Communication protocols and security in Slurm-web

    main

    Slurm-web uses several protocols to secure communication between components:

    • Client to Gateway: HTTP over TCP/IP. This can be secured with SSL/TLS (HTTPS) on port TCP/443 using a production HTTP server.
    • Gateway to Agent: After initial authentication (LDAP/OIDC), components communicate using JSON Web Tokens (JWT). Slurm-web uses its own dedicated JWT realm and signing key.
    • Agent to Slurm (slurmrestd):
      • TCP/IP socket: Supports rest_auth/jwt authentication (tokens signed by Slurm's JWT signing key).
      • Unix socket: Supports rest_auth/jwt and the (deprecated) rest_auth/local method (which uses client process UID/GID).

    Important Requirement: When using JWT authentication between the Slurm-web agent and the Slurm slurmrestd service, the auth/jwt authentication type must be enabled in both the main Slurm and slurmdbd configurations.