AIE:Guida Utenti

Guida per gli utenti del Cluster di calcolo e NVIDIA DGX in AI@Edge.

NVIDIA DGX A100

Si accede alla DGX via ssh con certificato preinstallato (nessuna password viene richiesta):

ssh <username>@edge-nd1.isti.cnr.it

Si richiede:

1. di UTILIZZARE la directory ~/raid/ per workdirs, datasets e altri elementi di occupazione massiccia di spazio disco. Lo spazio su / dove sono montate le homes è limitato!
2. di NON lanciare e tenere attivi job e/o servizi interattivi (es. jupyter notebooks, server http/flask, etc.). I processi che non seguono questo standard possono essere killati in qualsiasi momento.
3. di NON occupare l'interezza delle risorse per tempi prolungati, siano GPUs, CPUs, RAM o spazio disco!. Gli amministratori si riservano di applicare limiti e quote agli utenti indisciplinati.

Utilizzo di containers Podman

È disponibile l'utilizzo del software di containerizzazione Podman con accesso alle GPU. Ecco un esempio di utilizzo:

1. Creo una workdir per un nuovo progetto sui dischi veloci (dentro ~/raid/):

   mkdir ~/raid/my-project
   cd ~/raid/my-project
   

2. Creo un file Dockerfile scegliendo un'immagine di partenza (FROM) e installando i miei requisiti software (RUN).

   cat << EOF > Dockerfile
   FROM nvcr.io/nvidia/pytorch:22.09-py3
   RUN pip install transformers
   EOF
   

3. Costruisco la mia immagine:

   podman build -t my-project:latest - < Dockerfile
   

4. Creo uno script bash drun.sh per lanciare comandi dentro dei container nati dalla mia immagine. Questo è il contenuto di drun.sh:

   #!/bin/bash
   
   podman run \
       --interactive --tty \
       --rm \
       --userns keep-id \
       --runtime nvidia \
       -e NVIDIA_VISIBLE_DEVICES=nvidia.com/gpu=0,nvidia.com/gpu=2 \
       --volume $PWD:$PWD \
       --workdir $PWD \
       my-project:latest \
       $@
   

   dove:
   • --interactive --tty: opzioni necessarie per processi interattivi (e.g., bash),
   • --rm: rimuove il container alla terminazione del processo (i container saranno effimeri, se ne creerà uno nuovo ad ogni invocazione),
   • --userns keep-id: mantiene gli stessi UID e GID dell'host (stesso utente, stessi permessi),
   • --runtime nvidia: rende disponibili le GPU e stack software NVIDIA,
   • -e NVIDIA_VISIBLE_DEVICES=nvidia.com/gpu=0: rende la prima e la terza GPU visibili al container (per i valori ammissibili, eseguire nvidia-ctk cdi list; separare più valori da virgola per selezionare più GPU)
   • --volume $PWD:$PWD: monta la cartella corrente nel container allo stesso path (qualsiasi modifica all'interno di questa cartella è condivisa tra host e container),
   • --workdir $PWD: cambia la cartella di lavoro alla cartella corrente nel container,
   • my-project:latest: utilizza questa immagine come base del container,
   • $@: variabile bash che viene sostituita con tutti gli argomenti passati a questo script.
5. Preparo del codice da lanciare. Ad esempio, due script python:

   # due script di esempio da lanciare
   cat << EOF > count_gpus.py
   import torch
   num_of_gpus = torch.cuda.device_count()
   print(num_of_gpus)
   EOF
   
   cat << EOF > test.py
   import transformers
   print(transformers.__version__)
   EOF
   

6. Lancio dei job nei containers.

   # mi assicuro che drun.sh sia eseguibile
   chmod +x drun.sh
   
   # lancio script python
   ./drun.sh python count_gpus.py
   ./drun.sh python test.py
   
   # lancio una bash nel container
   ./drun.sh bash
   

7. NB: con questa configurazione, ogni modifica fatta all'infuori della cartella corrente ~/raid/my-project non verrà mantenuta alla chiusura del container. Nel caso serva cambiare l'ambiente (installare/rimuovere pacchetti o software, etc.) si suggerisce di cambiare il Dockerfile e rieseguire la creazione dell'immagine (punto 3). Questo workflow ha il vantaggio di rendere più facilmente riproducibile la creazione dell'ambiente di sviluppo/lancio e robusto a incidenti (se erroneamente viene cancellata l'immagine docker che stavo usando, mi basta ricostruirla con un podman build a partire dal Dockerfile).

Cluster di Calcolo

DRAFT: La seguente sezione è una bozza.

E' costituito da:

• Un nodo frontend;
• Quattro nodi di calcolo identici;
• Un nodo di storage.

Il nodo frontend ha le seguenti caratteristiche:

CPU: 1 x AMD EPYC 7352 (24 cores, 48 threads)

System memory: 128GB

Storage: 4HDD in RAID 5

   /           200GB

   /home       500GB (contiene le home degli utenti ed e' esportata via NFS sul frontend e sui nodi di calcolo)

   /opt/share  9.8TB (contiene software condiviso ed e' esportata via NFS sul frontend e sui nodi di calcolo)

Ciascun nodo di calcolo ha le seguenti caratteristiche:

CPU: 2 x AMD EPYC 7413 (48 cores, no HT)

System memory: 512GB

GPU: 1 x NVIDIA A100 GPU

Storage: 440GB

Il nodo di storage dispone di

   2 SSD in RAID1 per il sistema operativo;

   4 SSD in RAID5 5.2TB dedicati al folder /datafast (esportata via NFS sul frontend e sui nodi di calcolo)

   8 HDD in RAID5 63.7TB dedicati al folder /data (esportata via NFS sul frontend e sui nodi di calcolo)

  

TODO: 4 nodi con XX caratteristiche, frontend che con SLURM comanda sotto nodi, lista mountpoints/paths di interesse (dati e software)

Richiesta Creazione Utente sul Cluster

TODO Chi può accedere al momento.

TODO elenco amministratori per laboratiorio. Contattare tizio, caio e fornire le seguenti info...

Accesso e Utilizzo Cluster di calcolo

Una volta ottenuto l'utente si accede al cluster tramite ssh tramite il comando:

TODO Si accede al frontend

ssh <username>@edge-mst1.isti.cnr.it

Verrà richiesta la password (il cursore del terminale non si muove quando si inserisce la password).

N.B.: Se si tratta del primo accesso è caldamente consigliato il cambio della password. Per farlo utilizzare il comando: passwd, verrà chiesto di inserire la password vecchia e, successivamente, la password nuova (due volte).

E' obbligatorio l'utilizzo di slurm per lanciare jobs sul cluster. La documentazione ufficiale e' disponibile ai seguenti link:
https://slurm.schedmd.com/documentation.html
https://slurm.schedmd.com/tutorials.html

A questo punto è possibile vedere le risorse disponibili sul cluster tramite il comando sinfo che ritornerà la lista delle partizioni, i rispettivi limiti di tempo e i relativi nodi associati. L'output del comando è il seguente:

PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
debug        up   infinite      4   idle gn[01-04]
short        up    1:30:00      1   idle gn01
long*        up 3-00:00:00      4   idle gn[01-04]

Come è possibile vedere, a disposizione dell'utente sono presenti due partizioni:

• short: utilizzabile per job "brevi", un job lanciato su questa partizione verrà, infatti, chiuso dopo 1:30 ore dall'inizio del run;
• long: utilizzabile per job più lunghi, ha un tempo limite di 3 giorni.

N.B.: Per le attività di calcolo, sempre utilizzare una di queste partizioni, mai svolgere operazioni di calcolo sul nodo di frontend.

Run di un job

Il run di job può avvenire secondo due modalità:

• modalità interattiva;
• modalità batch.

Modalità interattiva

Si può aprire una sessione interattiva di Bash con il seguente comando:

srun -n1 -p short --pty /bin/bash

Per un tutorial e alcuni esempi di utilizzo si può vedere la wiki: https://gitlab.com/w895/centro_calcolo_isti/-/wikis/home