Tutorial: gestisci account e pianificazione dei job su un cluster

Se ti interessano i cluster di addestramento Vertex AI, contatta il tuo rappresentante di vendita per l'accesso.

Questa guida mostra come utilizzare le funzionalità di accounting e Quality of Service (QOS) di Slurm per gestire in modo efficace un singolo cluster di addestramento condiviso da più team con priorità ed esigenze di risorse diverse.

L'obiettivo

Al termine di questo tutorial, avrai un framework per la gestione delle risorse del cluster in grado di:

  • Applica i limiti delle risorse per team.
  • Assegna priorità ai lavori e anticipali in base all'urgenza.
  • Fornisci una contabilizzazione chiara del consumo di risorse.
  • Massimizza l'utilizzo del cluster mantenendo l'equità.

Prerequisiti

  • Un cluster di addestramento in esecuzione con contabilità, preemptive e priorità configurate per gestire gli account, pianificare e assegnare priorità ai job.

  • Orchestrate

  • Impostazioni Slurm avanzate

  • sudo sul nodo di accesso del cluster per eseguire i comandi dell'amministratore.

Concetti principali: i componenti di base della contabilità Slurm

Slurm utilizza una gerarchia chiara e flessibile per gestire le risorse. Comprendere questi quattro componenti di base è fondamentale.

Componente Esempio Finalità
Account Un team o un progetto L'unità principale per raggruppare gli utenti e impostare i limiti complessivi delle risorse (ad esempio, team_ace può utilizzare un massimo di 10 nodi).
Utente Un singolo ricercatore La persona che invia un job. Ogni utente deve appartenere a un account predefinito.
Partizione Una coda hardware Un raggruppamento logico di nodi. Per la massima flessibilità, ti consigliamo una singola partizione contenente tutti i nodi.
QOS Un libro di regole Un insieme denominato di regole che definiscono i limiti dei job (ad esempio, "i job in questo QOS possono utilizzare solo 2 nodi") e la priorità di pianificazione.

Con questo modello, puoi impostare una quota di alto livello per un intero account e applicare un limite più granulare, per job, utilizzando un QOS.

Le buyer persona: amministratore e ricercatore

Con questo sistema interagiscono due ruoli distinti: l'amministratore del cluster e il ricercatore.

Amministratore cluster

  • Strumento principale: sacctmgr (gestore account Slurm)
  • Il tuo compito è creare la "struttura" di account, utenti e regole QOS. In genere si tratta di un'attività di configurazione una tantum, da aggiornare in base alle necessità.
  • Attività chiave: crea account, assegna utenti agli account, definisci i manuali delle regole QOS e collegali tra loro.

Ricercatore

  • Strumenti principali: sbatch, squeue, sinfo
  • Il suo lavoro: inviare e monitorare i job di ricerca.
  • La magia: quando un ricercatore invia un job, Slurm controlla automaticamente le regole associate al suo account e alla qualità del servizio. Se il job viola un limite, Slurm lo rifiuta con un messaggio di errore chiaro.

Il tutorial: una procedura dettagliata progressiva

Il seguente tutorial mette in pratica questi concetti attraverso una serie di scenari progressivi. Per questa procedura dettagliata, assumi il ruolo di amministratore del cluster. Il tuo compito è configurare un account, team_ace, e un utente, user_alice. Gli scenari iniziano senza limiti e aggiungono progressivamente livelli di controllo.

Parte 1: configurazione iniziale (senza limiti)

Crea l'account e associa l'utente.

  • L'obiettivo è creare la gerarchia di base per team_ace e user_alice.
  • Il metodo: utilizza sacctmgr per aggiungere un account e poi aggiungi un utente associato a quell'account.
# --- (Run as Admin) ---

# 1. Create the 'team_ace' account
sudo sacctmgr add account team_ace Description="The Ace Team"

# 2. Create the 'user_alice' user and map them to their default account
# (Note: 'user_alice' must already exist as a Linux user on the node)
sudo sacctmgr add user user_alice Account=team_ace

# 3. Show the hierarchy we just built to confirm
sacctmgr show associations where account=team_ace

Risultato: in qualità di utente user_alice, ora puoi inviare un job di grandi dimensioni. Poiché non esistono limiti, un job di 7 nodi viene accettato ed eseguito immediatamente (supponendo che 7 nodi siano inattivi).

Parte 2: aggiungi limiti a livello di gruppo a un account

Successivamente, applica un limite di risorse all'account team_ace, limitando l'intero team a un massimo di 6 nodi e 4 job totali.

  • L'obiettivo: impostare un limite totale di risorse per un intero team.

  • Il metodo: applichiamo questo limite all'account team_ace utilizzando GrpJobs (Group Jobs) e GrpTRES (Group Trackable Resources, in questo caso node=6).

# --- (Run as Admin) ---

# 1. Add group-level job and node limits to the 'team_ace' account
sudo sacctmgr modify account where name=team_ace set GrpJobs=4 GrpTRES=node=6

# 2. View the limits to confirm the change
sacctmgr show association where account=team_ace

Risultati: per verificare che i nuovi limiti funzionino, esegui i seguenti test come user_alice:

  1. Limite di nodi: l'invio di un job a 7 nodi ora non va a buon fine. Il job viene messo nello stato in attesa (PD) con il motivo (AssocGrpNodeLimit).
  2. Limite di job: l'invio di 5 job a nodo singolo comporta l'esecuzione di 4 job (R) e il quinto job in attesa (PD) con il motivo (AssocGrpJobsLimit).

I limiti a livello di account funzionano perfettamente.

Parte 3: aggiungi un limite per job con QoS

Il limite dei gruppi a livello di account è efficace per limitare l'utilizzo totale delle risorse di un team. Tuttavia, non impedisce a un utente di inviare un singolo job che consuma l'intera quota del team. Per controllare le dimensioni dei job individuali, il passaggio successivo consiste nell'utilizzare una qualità del servizio (QoS).

  • Obiettivo: limitare la dimensione massima di qualsiasi singolo job inviato dal team.
  • Il metodo: creeremo una qualità del servizio (QoS) denominata qos1 con una regola MaxTRESPerJob=node=2. Successivamente, questa diventerà la QOS predefinita per l'intero account team_ace.
# --- (Run as Admin) ---

# 1. Create a QOS with a per-job limit of 2 nodes
sudo sacctmgr add qos qos1 MaxTRESPerJob=node=2

# 2. Allow the 'team_ace' account to use this QOS
sudo sacctmgr modify account where account=team_ace set QOS=qos1

# 3. Set 'qos1' as the DEFAULT QOS for all users in this account
sudo sacctmgr modify account where account=team_ace set DefaultQOS=qos1

Risultato: ora, se user_alice invia un job a 3 nodi, il job viene inserito in uno stato in attesa con il motivo (QOSMaxNodePerJobLimit). L'utente rientra ancora nella quota dell'account totale (6 nodi), ma ha violato la regola QoS per job.

Parte 4: aggiungi un override specifico per l'utente

Cosa succede se user_alice è uno stagista e deve essere limitato a lavori ancora più piccoli, senza influire sul resto del team?

  • Obiettivo: applicare un limite più restrittivo a un singolo utente.
  • Il metodo: creeremo un nuovo QOS (qos_intern) più restrittivo e lo applicheremo come predefinito specificamente per user_alice. Questa azione sostituisce la qualità del servizio predefinita dell'account.

# --- (Run as Admin) ---

# 1. Create a more restrictive QOS with a 1-node limit
sudo sacctmgr add qos qos_intern MaxTRESPerJob=node=1

# 2. Allow the account to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_intern

# 3. Apply 'qos_intern' as the default QOS for the specific user association
sudo sacctmgr modify user where name=user_alice account=team_ace set DefaultQOS=qos_intern

Risultato: se user_alice tenta di inviare il job a 2 nodi precedentemente consentito in qos1, l'operazione non va a buon fine (QOSMaxNodePerJobLimit). La regola più specifica a livello di utente ha sostituito correttamente la regola generale a livello di account.

Parte 5: configura la priorità e la preemption

Infine, configura la priorità e la preemption dei job per garantire che i job critici possano essere eseguiti immediatamente, anche se il cluster è pieno.

  • L'obiettivo è creare un QOS "urgente" ad alta priorità che possa mettere in pausa o annullare un job a priorità inferiore per liberare risorse.
  • Il metodo:

    1. Crea un nuovo qos_urgent con un valore Priority elevato.
    2. Comunica a qos_urgent che può Preempt i job in esecuzione in qos1.
    3. Configura qos1 in modo che REQUEUE i relativi job quando vengono interrotti.

# --- (Run as Admin) ---

# 1. Create a new 'qos_urgent' with a high priority that can preempt 'qos1'
sudo sacctmgr add qos qos_urgent Priority=1000 Preempt=qos1

# 2. Configure 'qos1' to requeue preempted jobs after a 10-second grace period
sudo sacctmgr modify qos where name=qos1 set PreemptMode=REQUEUE GraceTime=10

# 3. Allow the 'team_ace' account and 'user_alice' to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_urgent
sudo sacctmgr modify user where name=user_alice account=team_ace set QOS+=qos_urgent

# 4. For this scenario, remove the group limits so preemption is easier to trigger
sudo sacctmgr modify account where name=team_ace set GrpJobs=-1 GrpTRES=node=-1

Risultato:

  1. In un terminale, user_alice invia un job a lunga esecuzione con il valore predefinito qos1. Inizia a essere eseguito (R).
  2. In un secondo terminale, user_alice invia un job di grandi dimensioni utilizzando QOS urgente (sbatch --qos=qos_urgent ...).
  3. Nel giro di pochi secondi, lo stato del primo job cambia da in esecuzione (R) a in attesa (PD) con il motivo (Preempted). Il job urgente inizia quindi a essere eseguito.

Operazione riuscita. Hai configurato un sistema in cui il lavoro ad alta priorità sostituisce automaticamente quello a bassa priorità.

Riepilogo e passaggi successivi

Seguendo questo tutorial, hai imparato a utilizzare le funzionalità di contabilità gerarchica di Slurm per ottenere un controllo granulare su un cluster condiviso. Ora puoi:

  • Imposta limiti globali: utilizza gli account per impostare le quote totali delle risorse per interi team.
  • Applica regole per job: utilizza QOS per controllare le dimensioni e la priorità dei singoli job.
  • Crea override specifici: applica una QOS diversa a un utente per un controllo granulare.
  • Garanzia di priorità: configura la preemption per garantire che i workload critici possano essere sempre eseguiti.

Questo modello a livelli offre un modo flessibile ed efficace per gestire le risorse del cluster in modo equo ed efficiente. Per configurazioni ancora più avanzate, consulta la documentazione ufficiale di Slurm.