Guida di primo accesso ed utilizzo

L’architettura del cluster ibrido del Data Center IBiSCo (Infrastruttura per BIg data e Scientific COmputing) può essere rappresentata a livelli (Figura 1).
Al livello inferiore vi è l’hardware, caratterizzato da nodi di calcolo e di archiviazione; in quello superiore il livello applicazione, che permette agli utenti di sottomettere i propri task.
L’insieme delle librerie CUDA e MPI, in grado di far comunicare i due livelli tra loro, e del file system distribuito Lustre, che offre un paradigma ad alte prestazioni di accesso alle risorse, costituisce il livello intermedio dell’architettura.
Per garantire le corrette condizioni di lavoro del cluster è stato necessario utilizzare una rete ad alte prestazioni; si è scelta la tecnologia InfiniBand.

Figura 1: Diagramma a livelli del cluster

Il cluster si compone di 36 nodi e 2 switch, fisicamente collocati in 4 rack del Data Center, che svolgono due funzioni: di calcolo e di archiviazione. A supporto del calcolo vi sono 128 GPU, distribuite tra 32 nodi (4 GPU per nodo); a supporto dell’archiviazione 320 Terabyte, distribuiti tra 4 nodi (80 Terabyte per nodo).
Come accentato, per garantire l'accesso alle risorse e la comunicazione a banda larga e a bassa latenza tra i nodi si è scelto di utilizzare InfiniBand. Tale tecnologia fornisce il Remote Direct Memory Access (RDMA) che consente di accedere da un sistema locale a una posizione di memoria remota (memoria principale o memoria GPU di un nodo remoto) in maniera diretta senza coinvolgere le CPU nelle operazioni, riducendo così la latenza nel trasferimento dei messaggi.
La peculiarità del cluster risiede nella sua eterogeneità, data dalla coesistenza di due tecnologie: InfiniBand e Ethernet. Nonostante i vantaggi di InfiniBand, Ethernet non può essere eliminato dal momento che risulta essenziale per le operazioni di manutenzione, per il monitoraggio dell’infrastruttura e per garantire l’accesso alle risorse esterne al cluster.

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.

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. I nodi possono essere suddivisi in 3 sotto cluster. Nella tabella 1 di seguito si riportano le specifiche hardware peculiari di ciascun sotto cluster.

Tabella 1: Specifiche Hardware

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.
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.

Figura2

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 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. 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 2×100 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.
Per garantire efficienza ai flussi di lavoro applicativi eterogenei abbiamo implementato due reti InfiniBand dedicate, una per le comunicazioni tra processi e una per l'accesso ai dati, utilizzando uno switch Mellanox SB7800 InfiniBand indipendente per ciascuna rete.

Per consentire un utilizzo efficiente delle tecnologie descritte è necessario fornire un livello software che supporti la comunicazione tra i livelli.
Il Message Passing Interface (MPI) è un paradigma di programmazione ampiamente utilizzato nelle applicazioni parallele che offre meccanismi per la comunicazione tra processi. Questa comunicazione può avvenire in diverse forme: punto-punto, unilaterale o collettiva. Lo standard MPI si è evoluto introducendo il supporto per comunicazioni CUDA-aware in contesti eterogenei abilitati per GPU, consentendo così una comunicazione ottimizzata tra host e GPU. Per questo motivo le moderne distribuzioni MPI forniscono librerie MPI CUDA-aware con il framework Unified Communication X (UCX). Il middleware installato sul nostro cluster si basa su una combinazione delle seguenti tecnologie:

• OpenFabrics Enterprise Distribution (OFED) per i driver e le librerie necessarie alle NIC Mellanox InfiniBand.
• CUDA Toolkit per driver, librerie e ambiente di sviluppo necessari per sfruttare le GPU NVIDIA.
• L'implementazione CUDA-Aware di MPI OpenMPI attraverso il framework UCX.
• Un file system distribuito Lustre per accedere alle risorse di archiviazione con un paradigma ad alte prestazioni.

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.

Tabella 2: Specifiche Software

Come affermato in precedenza, nel calcolo ad alte prestazioni un aspetto chiave è la consegna efficiente dei dati da e verso i nodi di calcolo. Mentre la tecnologia InfiniBand può colmare il divario tra CPU, memoria e latenze I/O, i componenti di archiviazione potrebbero rappresentare un collo di bottiglia per l'intero carico di lavoro. L'implementazione adottata nel nostro cluster ibrido si basa sull'utilizzo di Lustre, un file system parallelo e distribuito ad alte prestazioni. Elevate prestazioni sono garantite dalla flessibilità di Lustre nel supportare molteplici tecnologie di storage, da quella comune basata su Ethernet e TCP/IP a quella ad alta velocità e bassa latenza come InfiniBand, RDMA e RoCE. Nell'architettura di Lustre, tutti i nodi di calcolo nel cluster sono client, mentre tutti i dati vengono archiviati su Object Storage Target in esecuzione sui nodi di archiviazione. Le comunicazioni sono gestite da un Management Service (MGS) e tutti i metadati sono archiviati su Metadata Target (MDT).
Nell'architettura Lustre implementata (vedi Figura 3) sia Management Service che Metadata Service (MDS) sono configurati su uno storage node con Metadata Targets (MDT) archiviato su un array SSD RAID-10 a 4 dischi. Gli altri 3 nodi di archiviazione ospitano gli OST per i due file system esposti a Lustre, uno per le home directory degli utenti e uno per l'area scratch dei lavori. In particolare, l’home filesystem è caratterizzato da grandi esigenze di spazio su disco e tolleranza ai guasti, quindi è composto da 6 MDT archiviati su un array di HDD SAS RAID-5 a 3 dischi da 30 TB ciascuno; l'area scratch invece è caratterizzata da tempi di accesso al disco rapidi senza necessità di ridondanza, quindi è composta da 6 MDT archiviati su dischi SSD da 1,8TB.

Figura 3: L'implementazione dell'architettura Lustre

Attualmente bisogna rivolgersi ai referenti di ente o istituto ai quali fornire alcune informazioni di identificazione che saranno rigirate agli amministratori di sistema. Gli amministratori inviano al richiedente poi le credenziali (nome utente e password provvisoria).

ATTENZIONE: la password è PROVVISORIA, va cambiata al primo accesso.

Per cambiarla usare da linea di comando il comando yppasswd, adatto a creare (o cambiare) una password valida non sul solo sistema di ingresso, ma su tutte le risorse del sistema HPC (Network password in un Network Information Service - NIS)

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 accesso da sistemi unix-like:

$ ssh ibiscohpc-ui.scope.unina.it -l <USERNAME>

Per accedere da sistemi windows si può usare il software putty, reperibile gratuitamente al sito https://www.putty.org/, oppure, da Windows 10 in poi, usando da finestra di comandi (CMD.exe o Powershell.exe) il software Openssh già installato in Windows (eventualmente non attivo, va semplicemente attivato nelle optional features)

Per usare le risorse del cluster è installato nel sistema il gestore di risorse SLURM. Documentazione approfondita su esso è disponibile al link https://slurm.schedmd.com/.

SLURM è un sistema software open source per la gestione di cluster; è altamente scalabile, offre meccanismi di fault-tolerance e di scheduling di jobs.

Le componenti principali di SLURM sono:

• nodi - nodi di calcolo;
• partizioni - raggruppamenti logici di nodi;
• jobs - allocazione di risorse assegnate ad un utente per un determinato ammontare di tempo;
• job steps - insieme di attività (solitamente parallele) all'interno di un job.

Le partizioni possono essere considerate come job queues ognuna delle quali definisce vincoli sulla dimensione dei job, limiti temporali, permessi di utilizzo di risorse da parte degli utenti, ecc.

Gestione centralizzata attraverso un demone, slurmctld, per il monitoraggio di risorse e jobs. Ogni nodo è gestito da un demone slurmd che si occupa di gestire richieste di attività.

Alcuni strumenti a disposizione dell'utente sono:

• srun - avviare job;
• sbatch - sottomettere script batch;
• salloc - richiedere l’allocazione di risorse (nodi), con eventuali vincoli (ad es, numero di processori per nodo);
• scancel - terminare job in coda o in esecuzione;
• sinfo - conoscere informazioni sullo stato del sistema;
• squeue - conoscere lo stato dei jobs;
• sacct - ottenere informazioni sui jobs.
• …

Un elenco completo dei comandi disponibili si trova nel man (disponibile anche online all’indirizzo https://slurm.schedmd.com/man_index.html): man <cmd>

sinfo - Conoscere e verificare lo stato delle risorse (partizioni esistenti, relativi nodi, …) e stato generale del sistema:

Esempio: $ sinfo

Output:

  PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
  hpc*      up     infinite   32     idle  ibiscohpc-wn[01-32]

L'output riporta le informazioni sulle partizioni, nell'esempio:

• una partizione denominata “hpc” (* indica che è la partizione di default);
• la partizione è disponibile (stato up);
• non sono impostati limiti di tempo sulla partizione;
• la partizione è composta da 32 nodi;
• lo stato è idle;
• 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)

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>

Gli utenti della risorsa hanno attualmente a loro disposizione la possibilità di usare i seguenti file systems

/lustre/home/ file system condiviso fra nodi e UI realizzato mediante tecnologia Lustre dove risiedono le home degli utenti

/lustre/scratch file system condiviso fra nodi realizzato mediante tecnologia Lustre da usare come area scratch

/home/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/.

L'elenco software è dinamico, aggiornato man mano che altri pacchetti sw vengono installati

…

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

. /nfsexports/intel/oneapi/setvars.sh 

• Ver 20.10 - disponibile nella directory /nfsexports/SOFTWARE/nvidia/hpc_sdk/

• Ver 4.1.orc5 - configurata per essere CUDA-AWARE, disponibile nella directory /usr/mpi/gcc/openmpi-4.1.0rc5/

• Ver 1.6.1 - interprete disponibile nella directory /nfsexports/SOFTWARE/julia-1.6.1

• ver 3.3.10 - compilata con i compilatori Intel disponibile nella directory /nfsexports/SOFTWARE/fftw-3.3.10

• - disponibile nella directory /nfsexports/SOFTWARE/anaconda3.OK/

• Ver R2020b - disponibile nella directory /nfsexports/SOFTWARE/MATLAB/R2020b/bin

• Ver 7.0 - disponibile nella directory /nfsexports/SOFTWARE/qe-7.0

• Ver 7.0 - disponibile nella directory /nfsexports/SOFTWARE/OpenFOAM-7.0/

• Ver 5.0 - disponibile nella stessa directory di OpenFOAM