Quando si parla di un “super computer”, si pensa spesso a un unico PC gigantesco. Nei sistemi moderni, invece, la potenza nasce generalmente da un cluster: tante macchine collegate in rete e gestite insieme.

La parola inglese cluster significa “gruppo”. In questo caso indica un insieme di computer, chiamati nodi, ciascuno dotato delle proprie risorse di calcolo. Collegando e coordinando i nodi, queste risorse possono essere gestite come se facessero parte di un’unica grande macchina: il sistema le assegna in modo trasparente a molti lavori e programmi diversi oppure le combina per affrontare elaborazioni particolarmente impegnative, come complesse analisi scientifiche.

Tra i vari servizi offerti da ReCaS Bari c’è proprio la fornitura di un’infrastruttura di calcolo: computer, rete, spazio per i dati e strumenti di gestione sui quali i ricercatori possono eseguire i propri programmi. Ma perché affidare un lavoro al data center, anziché avviarlo sul proprio PC?

Una simulazione può durare giorni. Un’analisi può richiedere più memoria di quella disponibile sul proprio PC. Oppure può essere necessario ripetere lo stesso esperimento migliaia di volte, cambiando ogni volta i dati di partenza.

Il problema non è soltanto la velocità. Chi fa ricerca ha bisogno di risorse adatte, di tempo per usarle e di un modo comodo per organizzare il lavoro.

Naturalmente le risorse non sono infinite: se molte persone ne hanno bisogno nello stesso momento, occorre decidere quali lavori avviare, dove e con quale priorità. È qui che entra in gioco il batch system.

Un batch system è un sistema software al quale si affidano lavori da eseguire senza doverli seguire passo dopo passo. Riceve le richieste, le organizza in coda e ne gestisce l’esecuzione sulle risorse disponibili.

Ogni lavoro sottomesso al cluster prende il nome di job. Il ricercatore prepara il programma, i dati da elaborare e le istruzioni per avviarlo; indica anche le risorse necessarie, per esempio quanti processori e quanta memoria servono e, dove richiesto, per quanto tempo.

Questa regia evita che ciascuno tenti di usare le stesse macchine senza coordinarsi e aiuta a sfruttare l’infrastruttura in modo ordinato. Un job può anche usare un solo processore: il batch system è utile per organizzare il lavoro, non soltanto per fare calcoli paralleli.

Esistono diversi software per questo compito: HTCondor, usato a ReCaS, e Slurm sono due esempi.

Tra le possibilità offerte da un cluster c’è anche il calcolo parallelo: svolgere più parti di un lavoro nello stesso momento. Il modo di farlo dipende da quanto queste parti hanno bisogno l’una dell’altra.

Nel primo caso è come avere molte attività autonome; nel secondo, una squadra i cui componenti devono aggiornarsi mentre lavorano. Le sigle HTC e HPC descrivono soprattutto obiettivi diversi, non due categorie completamente separate: un centro può ospitare entrambe le modalità. Anche i job paralleli che comunicano possono essere gestiti da un batch system.

Prima di passare a un esempio concreto, resta una domanda pratica: quanto di questa organizzazione deve gestire chi vuole semplicemente eseguire un programma?

L’organizzazione di un cluster può sembrare complessa. Uno dei punti di forza del batch system è proprio rendere gran parte di questa gestione trasparente per l’utente: non occorre scegliere personalmente la macchina né sorvegliarne l’esecuzione.

Si consideri un esempio. Si supponga di voler avviare sul proprio PC un programma di analisi scritto in Python, un linguaggio di programmazione. Il programma in questione può essere eseguito con il seguente comando:

Supponendo di voler eseguire la stessa analisi su un batch system, si opera invece tramite un submit file, o file di sottomissione: un semplice file di testo che descrive il programma da eseguire, dove salvarne i risultati — l’output — e quali risorse assegnargli. Il contenuto può essere rappresentato così:

Oltre al comando, vengono richiesti 10 GB di memoria, un’unità di elaborazione della CPU e tre GPU, cioè acceleratori adatti a determinati calcoli. Sono quantità di esempio: ogni programma richiede risorse diverse e deve essere progettato per sfruttarle. Chiedere tre GPU non rende automaticamente più veloce un programma che non le usa.

Una volta sottomesso il file, il sistema mette il job in coda. Quando trova una macchina compatibile con una porzione di risorse libera — spesso chiamata slot — gli assegna quanto richiesto e avvia il programma, rispettando le priorità del cluster. Se le risorse non sono disponibili, il lavoro rimane in attesa.

Il testo che il programma avrebbe stampato sullo schermo viene raccolto nel file calcolo.out. Gli eventuali altri risultati, come immagini o tabelle, vengono salvati secondo le istruzioni del programma. L’utente può quindi recuperare l’output senza dover conoscere in anticipo la macchina che ha eseguito il calcolo.

Resta necessario preparare il programma e i dati e assicurarsi che siano disponibili nell’ambiente di esecuzione. La scelta delle risorse libere e l’avvio del job vengono invece gestiti dal sistema. L’esempio di π permette di osservare questo meccanismo con un compito semplice e facilmente divisibile.

Si immagini di lanciare cento milioni di palline in un quadrato e contare quante cadono dentro una figura disegnata al suo interno. Il compito è semplice; ripeterlo cento milioni di volte è un altro discorso.

La sfida riguarda un numero familiare: π, il pi greco, circa 3,14159… È il rapporto tra la lunghezza di una circonferenza e il suo diametro. In questo esperimento se ne ricava una stima usando punti casuali: le “palline” sono soltanto coppie di numeri generate dai computer.

Per capire il principio alla base di questa simulazione, basta pensare al lancio di una moneta equilibrata: testa e croce hanno entrambe una probabilità del 50%. Eppure, lanciandola dieci volte, non è affatto garantito ottenere cinque teste e cinque croci. Su pochi tentativi, il caso può produrre uno squilibrio evidente.

Continuando con tanti lanci indipendenti, la percentuale di teste tende ad avvicinarsi al 50%, così come quella di croci. È il principio della legge dei grandi numeri: al crescere del numero di prove, le frequenze osservate tendono alle probabilità teoriche.

Questo modo di procedere — rappresentare un problema attraverso un modello teorico, simulare un grandissimo numero di casi casuali e osservare il risultato complessivo — prende il nome di metodo Monte Carlo. Permette di stimare o verificare numericamente un risultato previsto dal modello, sfruttando la statistica anziché risolvere direttamente ogni passaggio del problema. Il nome richiama il celebre casinò di Monte Carlo e i suoi giochi d’azzardo: qui, però, il caso diventa uno strumento di calcolo. Simulare un modello consente quindi di studiarne le conseguenze anche quando ricavarle con un calcolo diretto sarebbe molto difficile; verificare che rappresenti bene la realtà rimane un passaggio distinto.

Per π si userà lo stesso principio: al posto dei lanci di moneta, si simuleranno punti casuali nel quadrato. La frazione che cade nella figura permetterà di stimare π. Come per la percentuale di teste, servono moltissime prove per ottenere una stima precisa: ecco perché questo esperimento prevede cento milioni di punti.

Chiaramente, esistono modi molto più efficienti per calcolare le cifre di π. Questo esempio è stato scelto perché rende visibile un’idea utile anche in problemi scientifici ben più complessi: tante prove indipendenti possono essere distribuite tra tante macchine ed eseguite contemporaneamente.

Si consideri un quadrato di lato 1 metro. Nell’angolo in basso a sinistra si colloca il centro di un cerchio di raggio 1 metro: dentro al quadrato ne entra esattamente un quarto. Il raggio è la distanza dal centro al bordo del cerchio.

L’area misura quanta superficie occupa una figura. Se le lunghezze sono espresse in metri, l’area si misura in metri quadrati (m²). I valori dell’esempio si ricavano dalle seguenti formule:

Il rapporto tra le due aree è dunque [(π / 4) m²] / [1 m²] = π / 4. Le unità di misura si semplificano: si ottiene un numero che indica quale frazione del quadrato è occupata dal quarto di cerchio.

Si generano poi punti casuali distribuiti uniformemente nel quadrato, senza favorire il centro, i bordi o altre zone. “Uniformemente” significa che due regioni di uguale area hanno la stessa probabilità di essere colpite; una regione grande il doppio ha una probabilità doppia. Non basta, quindi, generare punti casuali in un modo qualsiasi: conta anche come vengono distribuiti.

Di conseguenza, la probabilità che un punto cada nel quarto di cerchio è proprio la frazione di superficie che esso occupa: π / 4. Con tanti punti indipendenti, la proporzione di quelli interni tende a questa probabilità, proprio come la percentuale di teste tende al 50% nell’esempio della moneta. Moltiplicando per 4, si ottiene quindi una stima di π:

Il computer riconosce i punti interni usando le loro coordinate, x e y, cioè le distanze orizzontale e verticale dall’angolo. Per il teorema di Pitagora il punto è dentro, o sul bordo, se x² + y² ≤ raggio². In questo esempio il limite è (1 m)² = 1 m². Nel programma si usano direttamente i valori numerici delle coordinate in metri, da 0 a 1: il controllo diventa x² + y² ≤ 1.

Alla luce di quanto visto, e come mostra il grafico, all’aumentare del numero di punti la stima di π tende, in media, a diventare più precisa.

Ogni punto può essere generato e controllato senza aspettare gli altri. È una situazione ideale per il calcolo parallelo: più macchine possono lavorare nello stesso momento su parti diverse del problema.

In questo esempio si affidano al batch system dieci job, da eseguire su dieci macchine del cluster ReCaS. Ciascuno genera dieci milioni di punti con una sequenza casuale indipendente e conta quanti sono interni al quarto di cerchio. È l’esempio di lavori indipendenti descritto prima: non devono scambiarsi dati mentre calcolano.

Ogni macchina può mostrare un proprio valore approssimato di π. Il risultato finale, però, tiene conto di tutti i cento milioni di punti, anziché selezionare la macchina che ha avuto più fortuna. Sommando i conteggi, il metodo resta corretto anche se i lavori contengono numeri diversi di punti.

Dividere il lavoro può ridurre il tempo di attesa, ma dieci macchine non significano automaticamente un tempo dieci volte più breve. Ci sono attese in coda, avvio dei programmi e raccolta dei risultati; inoltre le macchine possono avere velocità differenti. Il vantaggio dipende da quanto lavoro può davvero essere svolto contemporaneamente.

L’obiettivo resta comunque ottenere il risultato in meno tempo. In un caso facilmente divisibile come questo, con dieci macchine di prestazioni simili che lavorano contemporaneamente, il tempo del solo calcolo può avvicinarsi a un decimo di quello necessario su una sola macchina. È un riferimento ideale, non una garanzia sul tempo totale trascorso dall’invio dei job alla consegna del risultato.

Per un esempio che richiede pochi minuti, il vantaggio può sembrare modesto. Alcuni calcoli scientifici, invece, richiederebbero anni di esecuzione continua su un PC domestico. Macchine più potenti possono ridurre quell’attesa a mesi o settimane; se il problema si presta a essere suddiviso e sono disponibili risorse sufficienti, il calcolo parallelo può abbatterla ulteriormente, fino ad arrivare all’ordine di qualche giorno o qualche ora.

Stimare π con delle “palline” è un esempio volutamente semplice: non serve a scoprire un numero sconosciuto, né è il modo più efficiente per calcolarlo. Serve a rendere comprensibile come un problema possa essere affidato a un’infrastruttura di calcolo e distribuito tra più macchine.

Al posto delle palline possono esserci simulazioni di fenomeni fisici, analisi di dati sperimentali o molti tentativi di uno stesso modello. Non tutti i problemi si dividono con la stessa facilità, ma l’obiettivo rimane quello: mettere la capacità di calcolo al servizio di una domanda scientifica.

Proprio per questo, un cluster può essere utilizzato contemporaneamente da decine di gruppi di ricerca diversi: chi studia la fisica delle particelle, chi lavora nella fisica medica, chi simula il comportamento dei fluidi, chi sviluppa previsioni meteorologiche e ambientali, chi si occupa di applicazioni biomediche o di problemi ingegneristici. Cambiano i programmi, i dati e le domande, ma l’infrastruttura e l’approccio non cambiano.

Il punto di forza di un batch system, e di un centro di calcolo come ReCaS, è mettere a disposizione una piattaforma condivisa sulla quale eseguire programmi molto diversi, senza dover costruire e gestire ogni volta un’infrastruttura dedicata. Nel rispetto delle risorse disponibili e delle regole di accesso, ogni gruppo porta il proprio lavoro; il sistema ne organizza l’esecuzione insieme a quella degli altri.

In sintesi, il centro di calcolo mette risorse condivise al servizio di problemi scientifici diversi, mentre il batch system ne organizza l’utilizzo in modo efficiente.