Differenze tra le versioni di "AIE:Guida Utenti"

Da ISTI S2I2S Wiki.
Jump to navigation Jump to search
 
(Una versione intermedia di un altro utente non mostrate)
Riga 1: Riga 1:
<p style="border: 1px solid red; background-color: pink; padding: 12px 24px"> <b>DRAFT:</b> Questa pagina è una bozza.</p>
+
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):
 +
<syntaxhighlight lang="bash">
 +
ssh <username>@edge-nd1.isti.cnr.it
 +
</syntaxhighlight>
 +
 
 +
'''Si richiede:'''
 +
 
 +
#di '''<u>UTILIZZARE</u>''' la directory <code>~/raid/</code> per workdirs, datasets e altri elementi di occupazione massiccia di spazio disco. '''<u>Lo spazio su <code>/</code> dove sono montate le homes è limitato!</u>'''
 +
#di '''<u>NON</u>''' lanciare e tenere attivi job e/o servizi interattivi (es. jupyter notebooks, server http/flask, etc.). '''<u>I processi che non seguono questo standard possono essere killati in qualsiasi momento.</u>'''
 +
#di '''<u>NON</u>''' occupare l'interezza delle risorse per tempi prolungati, '''<u>siano GPUs, CPUs, RAM o spazio disco!</u>. Gli amministratori si riservano di applicare limiti e quote agli utenti indisciplinati.'''
 +
 
 +
==Utilizzo di containers Podman==
 +
 
 +
'''È disponibile l'utilizzo del software di containerizzazione [https://podman.io/docs Podman]''' con accesso alle GPU. Ecco un esempio di utilizzo:
 +
 
 +
#Creo una workdir per un nuovo progetto sui dischi veloci (dentro <code>~/raid/</code>):<syntaxhighlight lang="bash">
 +
mkdir ~/raid/my-project
 +
cd ~/raid/my-project
 +
</syntaxhighlight>
 +
#Creo un file <code>Dockerfile</code> scegliendo un'immagine di partenza (<code>FROM</code>) e installando i miei requisiti software (<code>RUN</code>).<syntaxhighlight lang="bash">
 +
cat << EOF > Dockerfile
 +
FROM nvcr.io/nvidia/pytorch:22.09-py3
 +
RUN pip install transformers
 +
EOF
 +
</syntaxhighlight>
 +
#Costruisco la mia immagine:<syntaxhighlight lang="bash">
 +
podman build -t my-project:latest - < Dockerfile
 +
</syntaxhighlight>
 +
#Creo uno script bash <code>drun.sh</code> per lanciare comandi dentro dei container nati dalla mia immagine. Questo è il contenuto di <code>drun.sh</code>:<syntaxhighlight lang="bash">
 +
#!/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 \
 +
    $@
 +
   
 +
   
 +
</syntaxhighlight>dove:
 +
#*<code>--interactive --tty</code>: opzioni necessarie per processi interattivi (e.g., bash),
 +
#*<code>--rm</code>: rimuove il container alla terminazione del processo (i container saranno effimeri, se ne creerà uno nuovo ad ogni invocazione),
 +
#*<code>--userns keep-id</code>: mantiene gli stessi UID e GID dell'host (stesso utente, stessi permessi),
 +
#*<code>--runtime nvidia</code>: rende disponibili le GPU e stack software NVIDIA,
 +
#*<code>-e NVIDIA_VISIBLE_DEVICES=nvidia.com/gpu=0</code>: rende la prima e la terza GPU visibili al container (per i valori ammissibili, eseguire <code>nvidia-ctk cdi list</code>; separare più valori da virgola per selezionare più GPU)
 +
#*<code>--volume $PWD:$PWD</code>: monta la cartella corrente nel container allo stesso path (qualsiasi modifica all'interno di questa cartella è condivisa tra host e container),
 +
#*<code>--workdir $PWD</code>: cambia la cartella di lavoro alla cartella corrente nel container,
 +
#*<code>my-project:latest</code>: utilizza questa immagine come base del container,
 +
#*<code>$@</code>: variabile bash che viene sostituita con tutti gli argomenti passati a questo script.
 +
#Preparo del codice da lanciare. Ad esempio, due script python:<syntaxhighlight lang="bash">
 +
# 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
 +
</syntaxhighlight>
 +
#Lancio dei job nei containers.<syntaxhighlight lang="bash">
 +
# mi assicuro che drun.sh sia eseguibile
 +
chmod +x drun.sh
  
Guida per gli utenti del Cluster di calcolo e NVIDIA DGX in AI@Edge.
+
# lancio script python
 +
./drun.sh python count_gpus.py
 +
./drun.sh python test.py
  
==Architettura Cluster==
+
# lancio una bash nel container
AI@Edge mette a disposizione:
+
./drun.sh bash
 +
</syntaxhighlight>
 +
#'''NB:''' con questa configurazione, ogni modifica fatta all'infuori della cartella corrente <code>~/raid/my-project</code> non verrà mantenuta alla chiusura del container. Nel caso serva cambiare l'ambiente (installare/rimuovere pacchetti o software, etc.) si suggerisce di cambiare il <code>Dockerfile</code> 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 <code>podman build</code> a partire dal <code>Dockerfile</code>).
  
 +
=Cluster di Calcolo=
 +
<p style="border: 1px solid red; background-color: pink; padding: 12px 24px"> <b>DRAFT:</b> La seguente sezione è una bozza.</p>
  
===Cluster di Calcolo===
 
 
E' costituito da:  
 
E' costituito da:  
  
Riga 53: Riga 130:
 
'''TODO''': 4 nodi con XX caratteristiche, frontend che con SLURM comanda sotto nodi, lista mountpoints/paths di interesse (dati e software)
 
'''TODO''': 4 nodi con XX caratteristiche, frontend che con SLURM comanda sotto nodi, lista mountpoints/paths di interesse (dati e software)
  
===NVIDIA DGX A100===
 
'''TODO''' caratteristiche DGX, lista mountpoints e path di interesse
 
  
 
==Richiesta Creazione Utente sul Cluster ==
 
==Richiesta Creazione Utente sul Cluster ==
Riga 75: Riga 150:
 
La documentazione ufficiale e' disponibile ai seguenti link:<br />
 
La documentazione ufficiale e' disponibile ai seguenti link:<br />
 
https://slurm.schedmd.com/documentation.html<br />
 
https://slurm.schedmd.com/documentation.html<br />
https://slurm.schedmd.com/tutorials.html<br />
+
https://slurm.schedmd.com/tutorials.html
 
 
A questo punto è possibile vedere le risorse disponibili sul cluster tramite il comando <code>sinfo</code> che ritornerà la lista delle partizioni, i rispettivi limiti di tempo e i relativi nodi associati.
 
  
'''TODO''' Si richiede risorse con SLURM<syntaxhighlight lang="bash">
+
A questo punto è possibile vedere le risorse disponibili sul cluster tramite il comando <code>sinfo</code> che ritornerà la lista delle partizioni, i rispettivi limiti di tempo e i relativi nodi associati. L'output del comando è il seguente:<syntaxhighlight lang="bash">
srun/sbatch ...
+
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]
 
</syntaxhighlight>
 
</syntaxhighlight>
  
 +
Come è possibile vedere, a disposizione dell'utente sono presenti due partizioni:
  
Per un tutorial e alcuni esempi di utilizzo si può vedere la wiki: https://gitlab.com/w895/centro_calcolo_isti/-/wikis/home
+
* 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.
==Accesso e Utilizzo NVIDIA DGX A100==
 
  
 +
'''N.B.:''' Per le attività di calcolo, '''sempre''' utilizzare una di queste partizioni, <u>'''mai''' svolgere operazioni di calcolo sul nodo di frontend.</u>
  
 +
=== Run di un job ===
 +
Il run di job può avvenire secondo due modalità:
  
Si accede alla DGX via ssh con certificato preinstallato (nessuna password viene richiesta):
+
* modalità interattiva;
 +
* modalità batch.
  
<syntaxhighlight lang="bash">
+
==== Modalità interattiva ====
ssh <username>@edge-nd1.isti.cnr.it
+
Si può aprire una sessione interattiva di Bash con il seguente comando:<syntaxhighlight lang="slurm">
 +
srun -n1 -p short --pty /bin/bash
 
</syntaxhighlight>
 
</syntaxhighlight>
  
'''È fortemente consigliato''' l'utilizzo di [https://www.docker.com/ Docker]  ([https://training.play-with-docker.com/ops-stage1/ qui]un tutorial) per creare l'ambiente con il software necessario e lanciare processi. Vedi la sezione [[AIE:Guida Utenti#Esempio di workflow|Esempio di workflow]] per una guida di esempio all'utilizzo consigliato.
 
  
 
+
Per un tutorial e alcuni esempi di utilizzo si può vedere la wiki: https://gitlab.com/w895/centro_calcolo_isti/-/wikis/home
'''Si richiede:'''
 
 
 
#di taggare le proprie immagini docker con nomi nel formato <code><username>/<nome_immagine></code> (es: <code>fabiocarrara/my-project:latest</code>). '''<u>Le immagini che non seguono questo standard possono essere cancellate periodicamente per recuperare spazio.</u>'''
 
#di '''<u>NON</u>''' lanciare e tenere attivi job e/o servizi interattivi (es. jupyter notebooks, server http/flask, etc.). '''<u>I processi che non seguono questo standard possono essere killati in qualsiasi momento.</u>'''
 
#di aggiungere ad ogni invocazione di <code>docker run</code> le opzioni <code>--user</code> e <code>--cpus</code> come segue:<syntaxhighlight lang="bash">
 
docker run \
 
    ...
 
    --user $(id -u):$(id -g) \
 
    --cpus <X> \  # sostituire <X> con un numero di CPU consono al numero di GPU utilizzate
 
    ...
 
</syntaxhighlight>L'opzione <code>--user</code> è necessaria per evitare che i processi girino come utente <code>root</code>. '''<u>I processi che non seguono questo standard e girano come <code>root</code> possono essere killati in qualsiasi momento.</u>'''  L'opzione <code>--cpus</code> è fortemente consigliata per evitare di occupare erroneamente l'interezza delle CPU. Una euristica per specificare <code><X></code> è scegliere un valore compreso tra <code>8*nGPUs</code> e <code>24*nGPUs</code> dove <code>nGPUs</code> indica il numero di GPU richieste.
 
 
 
===Esempio di workflow===
 
 
 
#Creo una workdir per un nuovo progetto sui dischi non-SSD (dentro <code>~/raid/</code>):<syntaxhighlight lang="bash">
 
mkdir ~/raid/my-project
 
cd ~/raid/my-project
 
</syntaxhighlight>
 
#Creo un file <code>Dockerfile</code> scegliendo un'immagine di partenza (<code>FROM</code>) e installando i miei requisiti software (<code>RUN</code>).<syntaxhighlight lang="bash">
 
cat << EOF > Dockerfile
 
FROM nvcr.io/nvidia/pytorch:22.09-py3
 
RUN pip install transformers
 
EOF
 
</syntaxhighlight>
 
#Costruisco la mia immagine:<syntaxhighlight lang="bash">
 
# sostituire <username> con il proprio nome utente
 
docker build -t <username>/my-project:latest - < Dockerfile
 
</syntaxhighlight>
 
#Creo uno script bash <code>drun.sh</code> per lanciare comandi dentro dei container nati dalla mia immagine. Questo è il contenuto di <code>drun.sh</code>:<syntaxhighlight lang="bash">
 
#!/bin/bash
 
 
 
docker run \
 
    --interactive --tty \
 
    --rm \
 
    --user $(id -u):$(id -g) \
 
    --cpus 32 \
 
    --gpus '"device=0,2"' \
 
    --volume $PWD:$PWD \
 
    --workdir $PWD \
 
    <username>/my-project:latest \
 
    $@
 
   
 
   
 
</syntaxhighlight>dove:
 
#*<code>--interactive --tty</code>: opzioni necessarie per processi interattivi (e.g., bash),
 
#*<code>--rm</code>: rimuove il container alla terminazione del processo (i container saranno effimeri, se ne creerà uno nuovo ad ogni invocazione),
 
#*<code>--user $(id -u):$(id -g)</code>: esegue il processo con uid:gid dell'utente sull'host,
 
#*<code>--cpus 32</code>: limita l'utilizzo a 32 CPU,
 
#*<code>--gpus '"device=0,2"'</code>: rende la prima e la terza GPU visibili al container,
 
#*<code>--volume $PWD:$PWD</code>: monta la cartella corrente nel container allo stesso path (qualsiasi modifica all'interno di questa cartella è condivisa tra host e container),
 
#*<code>--workdir $PWD</code>: cambia la cartella di lavoro alla cartella corrente nel container,
 
#*<code><username>/my-project:latest</code>: utilizza questa immagine come base del container,
 
#*<code>$@</code>: variabile bash che viene sostituita con tutti gli argomenti passati a questo script.
 
#Preparo del codice da lanciare. Ad esempio, due script python:<syntaxhighlight lang="bash">
 
# 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
 
</syntaxhighlight>
 
#Lancio dei job nei containers.<syntaxhighlight lang="bash">
 
# 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
 
</syntaxhighlight>
 
#'''NB:''' con questa configurazione, ogni modifica fatta all'infuori della cartella corrente <code>~/raid/my-project</code> non verrà mantenuta alla chiusura del container. Nel caso serva cambiare l'ambiente (installare/rimuovere pacchetti o software, etc.) si suggerisce di cambiare il <code>Dockerfile</code> 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 <code>docker build</code> a partire dal <code>Dockerfile</code>).
 

Versione attuale delle 12:29, 11 dic 2024

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