Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
wiki:guida_di_utilizzo [2022/03/07 16:39] cnr-guest [Preparazione e sottomissione di job] |
wiki:guida_di_utilizzo [2022/05/13 13:29] (current) scopeadmin |
== Architettura del nodo di archiviazione == | == Architettura del nodo di archiviazione == |
| |
Il cluster conta 4 nodi Dell R740 dedicati all’archiviazione, ognuno dei quali offre 16 HHD SAS da 16 TB e 8 SSD SATA da 1.9 TB. Ogni nodo è munito di due porte EDR InfiniBand, una delle quali è connessa allo switch InfiniBand Mellanox dedicato all’archiviazione, che garantisce una connessione a 100 Gb/s verso tutti i nodi di calcolo.\\ Un sistema di archiviazione separato da 3 PB è disponibile via Ethernet e viene utilizzato come repository in cui gli utenti possono spostare i dati da e verso i sistemi di archiviazione collegati a InfiniBand quando hanno bisogno di grandi quantità di dati nell'arco di tempo del loro job. Per quanto riguarda la rete Ethernet, ogni nodo conta 2 porte a 25 Gb/s per il collegamento verso il core switch del Data Center. | Il cluster conta 4 nodi Dell R740 dedicati all’archiviazione, ognuno dei quali offre 16 HHD SAS da 16 TB e 8 SSD SATA da 1.9 TB. Ogni nodo è munito di due porte EDR InfiniBand, una delle quali è connessa allo switch InfiniBand Mellanox dedicato all’archiviazione, che garantisce una connessione a 100 Gb/s verso tutti i nodi di calcolo.\\ Mentre i nodi citati sono dedicati alle aree home e scratch degli utenti, sarà poi disponibile un sistema di archiviazione separato da 3 PB. Esso sarà accessibile via Ethernet e potrà essere utilizzato come repository in cui gli utenti potranno spostare i dati da e verso i sistemi di archiviazione collegati a InfiniBand quando avranno bisogno di grandi quantità di dati nell'arco di tempo del loro job. Per quanto riguarda la rete Ethernet, ogni nodo è dotato di 2 porte a 25 Gb/s per il collegamento verso il core switch del Data Center. |
== Architettura del nodo di calcolo== | == Architettura del nodo di calcolo== |
| |
I nodi di calcolo del cluster sono 32 Dell C4140, ognuno dotato di 4 GPU NVIDIA V100, 2 porte Ethernet a 10 Gb/s ognuna, 2 porte InfiniBand a 100 Gb/s ognuna, 2 CPU Intel Gen 2 Xeon Gold e 2 dischi SATA a stato solido da 480 GB. | I nodi di calcolo del cluster sono 32 Dell C4140, ognuno dotato di 4 GPU NVIDIA V100, 2 porte Ethernet a 10 Gb/s ognuna, 2 porte InfiniBand a 100 Gb/s ognuna, 2 CPU Intel Gen 2 Xeon Gold e 2 dischi SATA a stato solido da 480 GB. In ogni nodo sono installati 22 moduli di memoria RAM da 64 GB, per un totale di 1.375 TiB (1408 GB). Ogni GPU è dotata di 32 GB. |
Le specifiche hardware dei nodi, suddivisibili in 3 sotto cluster, sono riportate nella Tabella 1 di seguito. | I nodi possono essere suddivisi in 3 sotto cluster. Nella tabella 1 di seguito si riportano le specifiche hardware peculiari di ciascun sotto cluster. |
| |
| |
| |
Uno degli obiettivi del cluster è quello di rendere l'infrastruttura scalabile in base ai requisiti dell'applicazione. I server C4140 sono disponibili sia con canali di comunicazione PCIe 3.0 che NVLink 2.0, consentendo comunicazioni GPU-CPU e GPU-GPU rispettivamente su PCIe o NVLink. \\ | Uno degli obiettivi del cluster è quello di rendere l'infrastruttura scalabile in base ai requisiti dell'applicazione. I server C4140 sono disponibili sia con canali di comunicazione PCIe 3.0 che NVLink 2.0, consentendo comunicazioni GPU-CPU e GPU-GPU rispettivamente su PCIe o NVLink. \\ |
Quando l'applicazione necessita esclusivamente di CPU, il parallelismo è garantito dalla presenza delle due CPU disponibili su ogni nodo C4140. Quando l'applicazione richiede il parallelismo delle GPU, è consigliato utilizzare un sistema di interconnessione più efficiente rispetto al più comune bus PCIe. Rispetto a PCIe 3.0, NVLink 2.0 utilizza una connessione punto-punto che offre vantaggi in termini di prestazioni di comunicazione. Mentre il throughput massimo del collegamento bus PCIe 3.0 è di 16 GB/s, NVLink raggiunge i 25 GB/s ma essendo un'architettura punto-punto la larghezza di banda bidirezionale totale è di 50 GB/s. Nel nostro caso specifico, ogni GPU V100 è dotata di 2 collegamenti a tutte le altre GPU per un totale di 6 collegamenti fino a 300 GB/s come larghezza di banda bidirezionale aggregata (vedi Figura 2). Quando le applicazioni richiedono un parallelismo di più di 4 GPU è necessario fornire una tecnologia di comunicazione tra nodi efficiente, come InfiniBand. \\ | Quando l'applicazione necessita esclusivamente di CPU, il parallelismo è garantito dalla presenza delle due CPU disponibili su ogni nodo C4140. Quando l'applicazione richiede il parallelismo delle GPU, è consigliato utilizzare un sistema di interconnessione più efficiente rispetto al più comune bus PCIe. Rispetto a PCIe 3.0, NVLink 2.0 utilizza una connessione punto-punto che offre vantaggi in termini di prestazioni di comunicazione. Mentre il throughput massimo del collegamento bus PCIe 3.0 è di 16 GB/s, NVLink raggiunge i 25 GB/s, ma, essendo un'architettura punto-punto, la larghezza di banda bidirezionale totale è di 50 GB/s. Nel nostro caso specifico, ogni GPU V100 è dotata di 2 collegamenti a tutte le altre GPU per un totale di 6 collegamenti fino a 300 GB/s come larghezza di banda bidirezionale aggregata (vedi Figura 2). Quando le applicazioni richiedono un parallelismo di più di 4 GPU è necessario fornire una tecnologia di comunicazione tra nodi efficiente, come InfiniBand. \\ |
La sezione successiva descrive il middleware necessario per abilitare tali modelli di comunicazione. La tecnologia InfiniBand RDMA garantisce che i dati non vengano copiati tra i livelli di rete ma trasferiti direttamente ai buffer delle NIC; le applicazioni possono accedere direttamente alla memoria remota, senza coinvolgimento della CPU, garantendo una latenza estremamente bassa, nell'ordine di grandezza delle centinaia di nanosecondi. | La sezione successiva descrive il middleware necessario per abilitare tali modelli di comunicazione. La tecnologia InfiniBand RDMA garantisce che i dati non vengano copiati tra i livelli di rete ma trasferiti direttamente ai buffer delle NIC; le applicazioni possono accedere direttamente alla memoria remota, senza coinvolgimento della CPU, garantendo una latenza estremamente bassa, nell'ordine di grandezza delle centinaia di nanosecondi. |
| |
| |
La combinazione dei paradigmi High-Throughput Computing (HTC) e High-Performance Computing (HPC) è un aspetto importante per la rete di un cluster efficiente. \\ | La combinazione dei paradigmi High-Throughput Computing (HTC) e High-Performance Computing (HPC) è un aspetto importante per la rete di un cluster efficiente. \\ |
Sebbene la tecnologia InfiniBand fornisca basse latenze, non tutte le applicazioni traggono vantaggio da una rete così ad alte prestazioni poiché il loro flusso di lavoro non potrebbe essere basato su intercomunicazioni di processi intensivi. Pertanto è meglio utilizzare anche lo standard di rete Ethernet e consentire all'applicazione di utilizzare la migliore tecnologia di cui c’è bisogno. Per ottenere tale versatilità, il nostro cluster implementa una rete ibrida InfinBand-Ethernet. \\ | Sebbene la tecnologia InfiniBand fornisca basse latenze, non tutte le applicazioni traggono vantaggio da una rete così ad alte prestazioni poiché il loro flusso di lavoro potrebbe non essere basato su intercomunicazione intensiva tra processi. Pertanto è meglio utilizzare anche lo standard di rete Ethernet e consentire all'applicazione di utilizzare la migliore tecnologia di cui c’è bisogno. Per ottenere tale versatilità, il nostro cluster implementa una rete ibrida InfinBand-Ethernet. \\ |
È indispensabile che il traffico di rete sia garantito anche in caso di guasto di un dispositivo di rete, per questo motivo tutte le connessioni sono duplicate su due switch diversi con meccanismo di failover automatico. | È indispensabile che il traffico di rete sia garantito anche in caso di guasto di un dispositivo di rete, per questo motivo tutte le connessioni sono duplicate su due switch diversi con meccanismo di failover automatico. |
Infine è assicurata efficienza dall'utilizzo del protocollo LAG su Ethernet, raddoppiando così la banda di trasferimento quando entrambi gli switch sono operativi. In dettaglio, la nostra infrastruttura fornisce più switch Ethernet Huawei CE-8861-4C-EI collegati con collegamenti stack da 2x100 Gb/s in una topologia ad anello. Quindi abbiamo utilizzato il protocollo Link Aggregation Group multi-chassis (mLAG) per consentire l'aggregazione delle due porte da 25 Gb/s. \\ | Infine è assicurata efficienza dall'utilizzo del protocollo LAG su Ethernet, raddoppiando così la banda di trasferimento quando entrambi gli switch sono operativi. In dettaglio, la nostra infrastruttura fornisce più switch Ethernet Huawei CE-8861-4C-EI collegati con collegamenti stack da 2x100 Gb/s in una topologia ad anello. Quindi abbiamo utilizzato il protocollo Link Aggregation Group multi-chassis (mLAG) per consentire l'aggregazione delle due porte da 25 Gb/s. \\ |
== The process communication sub-layer == | == The process communication sub-layer == |
| |
Lo spostamento dei dati tra i processi continua a essere un aspetto critico per sfruttare tutto il potenziale di una GPU. Le moderne GPU forniscono alcuni meccanismi di copia dei dati che possono facilitare e migliorare le prestazioni delle comunicazioni tra processi GPU. A questo proposito, NVIDIA ha introdotto le tecnologie CUDA Inter-Process Copy (IPC) e GPUDirect Remote Direct Memory Access (RDMA) per le comunicazioni di processo GPU intra e inter nodo. NVIDIA ha stretto una partnership con Mellanox per rendere disponibile questa soluzione per i cluster basati su InfiniBand. Un'altra tecnologia degna di nota è NVIDIA gdrcopy, che consente comunicazioni inter-nodo GPU-to-GPU ottimizzate per messaggi di piccole dimensioni, superando il notevole sovraccarico introdotto nello scambio di messaggi di sincronizzazione tramite il protocollo rendevous per messaggi di piccole dimensioni. Per unire le suddette tecnologie con le librerie di comunicazione (es. OpenMPI) viene fornito il framework UCX. Questo framework è guidato dall'UCF Consortium (Unified Communication Framework) che è una collaborazione tra industrie, laboratori e università per creare framework di comunicazione di livello produttivo e standard aperti per applicazioni incentrate sui dati e ad alte prestazioni. UCX si dichiara un framework di comunicazione ottimizzato per reti moderne, ad alta larghezza di banda e a bassa latenza. Espone una serie di primitive di comunicazione astratte che utilizzano automaticamente le migliori risorse hardware disponibili e scarica sul cluster in esecuzione. Le tecnologie supportate includono RDMA (sia InfiniBand che RoCE), TCP, GPU, memoria condivisa e operazioni atomiche di rete. Inoltre, UCX implementa alcune best practice per il trasferimento di messaggi di tutte le dimensioni, basate sull'esperienza acquisita durante l'esecuzione dell'applicazione sui più grandi datacenter e supercomputer del mondo. \\ | Lo spostamento dei dati tra i processi continua a essere un aspetto critico per sfruttare tutto il potenziale di una GPU. Le moderne GPU forniscono alcuni meccanismi di copia dei dati che possono facilitare e migliorare le prestazioni delle comunicazioni tra processi GPU. A questo proposito, NVIDIA ha introdotto le tecnologie CUDA Inter-Process Copy (IPC) e GPUDirect Remote Direct Memory Access (RDMA) per le comunicazioni di processo GPU intra e inter nodo. NVIDIA ha stretto una partnership con Mellanox per rendere disponibile questa soluzione per i cluster basati su InfiniBand. Un'altra tecnologia degna di nota è NVIDIA gdrcopy, che consente comunicazioni inter-nodo GPU-to-GPU ottimizzate per messaggi di piccole dimensioni, superando il notevole sovraccarico introdotto nello scambio di messaggi di sincronizzazione tramite il protocollo rendevous per messaggi di piccole dimensioni. Per unire le suddette tecnologie con le librerie di comunicazione (es. OpenMPI) viene fornito il framework UCX. Questo framework è guidato dall'UCF Consortium (Unified Communication Framework) che è una collaborazione tra industrie, laboratori e università per creare framework di comunicazione di livello produttivo e standard aperti per applicazioni incentrate sui dati e ad alte prestazioni. UCX si dichiara un framework di comunicazione ottimizzato per reti moderne, ad alta larghezza di banda e a bassa latenza. Esso espone una serie di primitive di comunicazione astratte che utilizzano automaticamente le migliori risorse hardware disponibili al momento dell'esecuzione. Le tecnologie supportate includono RDMA (sia InfiniBand che RoCE), TCP, GPU, memoria condivisa e operazioni atomiche di rete. Inoltre, UCX implementa alcune best practice per il trasferimento di messaggi di tutte le dimensioni, basate sull'esperienza acquisita durante l'esecuzione dell'applicazione sui più grandi datacenter e supercomputer del mondo. \\ |
Nella Tabella 2 sono elencate le caratteristiche software dei nodi nei cluster. | Nella Tabella 2 sono elencate le caratteristiche software dei nodi nei cluster. |
| |
Per accedere al sistema (in particolare al suo front-end o UI - User Interface) bisogna collegarsi tramite protocollo SSH all'host ibiscohpc-ui.scope.unina.it. L'accesso per ora è solo in modalità emulazione di terminale non grafico. L'account dell'UI comunque è valido per tutte le risorse del cluster. | Per accedere al sistema (in particolare al suo front-end o UI - User Interface) bisogna collegarsi tramite protocollo SSH all'host ibiscohpc-ui.scope.unina.it. L'accesso per ora è solo in modalità emulazione di terminale non grafico. L'account dell'UI comunque è valido per tutte le risorse del cluster. |
| |
Esempio di acesso da sistemi unix-like: | Esempio di accesso da sistemi unix-like: |
| |
''$ ssh ibiscohpc-ui.scope.unina.it -l <USERNAME>'' | ''$ ssh ibiscohpc-ui.scope.unina.it -l <USERNAME>'' |
== Informazione su sistema e risorse == | == Informazione su sistema e risorse == |
| |
''sinfo'' - Conoscere e verificare lo stato delle risorse (partizioni esistenti, relativi nodi, ...) e stato generale del sistema: | ''**sinfo**'' - Conoscere e verificare lo stato delle risorse (partizioni esistenti, relativi nodi, ...) e stato generale del sistema: |
| |
Comando: ''$ sinfo'' | Esempio: ''$ sinfo'' |
| |
Output: | Output: |
* lo stato è idle; | * lo stato è idle; |
* i nodi disponibili sono denominati ''ibiscohpc-wn01'', ''ibiscohpc-wn02'', ..., ''ibiscohpc-wn32''. | * i nodi disponibili sono denominati ''ibiscohpc-wn01'', ''ibiscohpc-wn02'', ..., ''ibiscohpc-wn32''. |
| |
| ''**squeue**'' - Conoscere lo stato della coda di jobs: |
| |
| Esempio: ''$ squeue'' |
| |
| Output: |
| JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) |
| 4815 hpc sleep cnr-isas R 0:04 |
| |
| L'output mostra, per ogni job: |
| * identificativo del job; |
| * nome della partizione su cui è stato lanciato il job; |
| * nome del job; |
| * nome utente che ha lanciato il job; |
| * stato del job (running); |
| * tempo di esecuzione del job. |
| |
| ''**scontrol**'' - informazioni più dettagliate su job e risorse |
| |
| Esempio (info dettagliate sul nodo ''ibiscohpc-wn02''): ''$ scontrol show node ibiscohpc-wn02'' |
| |
| Output: |
| NodeName=ibiscohpc-wn02 Arch=x86_64 CoresPerSocket=24 |
| CPUAlloc=0 CPUTot=96 CPULoad=0.01 |
| AvailableFeatures=HyperThread |
| ActiveFeatures=HyperThread |
| Gres=gpu:tesla:4(S:0) |
| NodeAddr=ibiscohpc-wn02 NodeHostName=ibiscohpc-wn02 Version=20.11.5 |
| OS=Linux 3.10.0-957.1.3.el7.x86_64 #1 SMP Mon Nov 26 12:36:06 CST 2018 |
| RealMemory=1546503 AllocMem=0 FreeMem=1528903 Sockets=2 Boards=1 |
| State=IDLE ThreadsPerCore=2 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A |
| Partitions=hpc |
| BootTime=2022-02-01T16:24:43 SlurmdStartTime=2022-02-01T16:25:25 |
| CfgTRES=cpu=96,mem=1546503M,billing=96 |
| AllocTRES= |
| CapWatts=n/a |
| CurrentWatts=0 AveWatts=0 |
| ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s |
| Comment=(null) |
| |
| == Preparazione e sottomissione di job == |
| |
| ''**srun**'' - controllo dell’esecuzione di un job parallelo sul cluster gestito da Slurm. Se necessario, srun alloca le risorse per l’esecuzione del job. |
| |
| Alcuni parametri utili di srun sono: |
| |
| ''-c'', ''--cpus-per-task=<ncpus>'' |
| |
| * numero di CPUs allocate per processo. Di default viene utilizzata una CPU per processo. |
| |
| ''-l'', ''--label'' |
| |
| * mostra in testa alle righe, sullo stdout, il numero del task cui l’output si riferisce. |
| |
| ''-N'', ''--nodes=<minnodes>[-maxnodes]'' |
| |
| * numero minimo (''minnodes'') da allocare per il job ed eventuale numero massimo (maxnodes) di nodi. |
| * Se il parametro non viene specificato, vengono allocati i nodi necessari a soddisfare i requisiti specificati dai parametri ''-n'' e ''-c''. |
| * Se i valori sono al di fuori dal range consentito per la partizione associata, il job viene posto in uno stato ''PENDING''. Ciò consente una possibile esecuzione in un secondo momento, quando viene eventualmente modificato il limite della partizione. |
| |
| ''-n'', ''--ntasks=<number>'' |
| |
| * numero di task da eseguire. ''srun'' alloca le risorse necessarie in base al numero di task richiesti (di default, viene richiesto un nodo per ogni task ma, tramite l’opzione ''--cpus-per-task'', questo comportamento può essere modificato). |
| |
| Esempio, accedere in maniera interattiva ad un nodo, dalla UI: |
| $ salloc srun --pty /bin/bash |
| Esempio, per sottomettere un job batch, dalla UI: |
| $ echo -e '#!/bin/sh\nhostname' | sbatch |
| |
| Esempio, per sottomettere un job interattivo MPI con <N> tasks, dalla UI: |
| $ srun -n <N> <EXEFILE> |
==== File system disponibili ==== | ==== File system disponibili ==== |
| |
''/home/scratch'' | ''/home/scratch'' |
file system locale a ciascun nodo da usare come area scratch | file system locale a ciascun nodo da usare come area scratch |
| |
| Documentazione approfondita su Lustre è reperibile in rete, al link: ''https://www.lustre.org/''. |
| |
==== Software disponibile ==== | ==== Software disponibile ==== |
| |
=== COMPILATORI === | L'elenco software è dinamico, aggiornato man mano che altri pacchetti sw vengono installati |
| |
== INTEL : compilatori e librerie == | === utilities generali per l'uso del sistema === |
Per utilizzare la suite Intel di compilatori e librerie, bisogna utilizzare (interattivamente o all'interno | |
di qualunque script in cui essi siano necessari) il comando | ... |
| |
| |
| === sw generale per sviluppo (compilatori, librerie, etc) === |
| |
| == Intel OneAPI (suite compilatori, librerie, etc forniti da Intel) == |
| Per utilizzare la suite Intel di compilatori e librerie, bisogna utilizzare (interattivamente o all'interno di qualunque script in cui essi siano necessari) il comando |
| |
<code>. /nfsexports/intel/oneapi/setvars.sh </code> | <code>. /nfsexports/intel/oneapi/setvars.sh </code> |
| |
| == NVIDIA HPC SDK (suite compilatori, librerie, etc forniti da NVIDIA) == |
| |
| * //**Ver 20.10**// - disponibile nella directory '' /nfsexports/SOFTWARE/nvidia/hpc_sdk/ '' |
| |
| == OpenMPI == |
| * //**Ver 4.1.orc5**// - configurata per essere CUDA-AWARE, disponibile nella directory ''/usr/mpi/gcc/openmpi-4.1.0rc5/ '' |
| |
| |
| == Linguaggio Julia == |
| |
| * //**Ver 1.6.1**// - interprete disponibile nella directory '' /nfsexports/SOFTWARE/julia-1.6.1 '' |
| |
| == Librerie FFTW == |
| |
| * //**ver 3.3.10**// - compilata con i compilatori Intel disponibile nella directory '' /nfsexports/SOFTWARE/fftw-3.3.10 '' |
| |
| == Ambiente Anaconda 3 == |
| |
| * - disponibile nella directory '' /nfsexports/SOFTWARE/anaconda3.OK/ '' |
| |
| === pacchetti sw completi per specifiche applicazioni === |
| |
| == Matlab == |
| |
| * //**Ver R2020b**// - disponibile nella directory '' /nfsexports/SOFTWARE/MATLAB/R2020b/bin '' |
| |
| == Quantum ESPRESSO == |
| |
| * //**Ver 7.0**// - disponibile nella directory '' /nfsexports/SOFTWARE/qe-7.0 '' |
| |
| == OpenFOAM == |
| * //**Ver 7.0**// - disponibile nella directory '' /nfsexports/SOFTWARE/OpenFOAM-7.0/ '' |
| |
| == Rheotool == |
| * //**Ver 5.0**// - disponibile nella stessa directory di OpenFOAM |
| |
| |
| |