News
Contenuti per la community dell'HPC e gli appassionati di innovazione: tutorial, news e press release per utenti, ingegneri e amministratori
- Tutte le news
- Aerospace & Defence
- Artificial Intelligence
- Blog
- Cloud Platform
- Collaborazioni
- HPC
- Kubernetes Cluster
- Press
- Progetti Europei
- Ultime news
- Varie E4
- Video
Potente e flessibile: abbattere le moderne barriere di adozione dell’HPC
Il calcolo basato sui dati cambia lo scopo dell’HPC.
La storia del calcolo ad alte prestazioni (HPC) risale agli anni ’40, quando furono costruiti i primi computer elettronici: il termine “Supercomputing” è riportato per la prima volta nel 1944 [1]. Lo sviluppo dell’HPC, inizialmente guidato dalla ricerca atomica, ha permesso di creare modelli numerici complessi in ambito scientifico e ingegneristico, dando vita alla Scienza computazionale: un terzo paradigma (accanto all’osservazione e agli esperimenti e alla formalizzazione matematica) in cui modelli numerici approssimati a partire da leggi matematiche di base, forniscono una controparte per la sperimentazione diretta. Da allora, l’HPC si è evoluto in un insieme di tecniche e tecnologie che comprendono architetture di CPU, connessioni dedicate (a bassa latenza), filesystem paralleli, strumenti e librerie di programmazione specializzati e molto altro ancora.
L’HPC è stato inizialmente utile in campi come la fisica delle alte energie, la fluidodinamica e la chimica computazionale, in cui è stato possibile sviluppare modelli computazionali bottom-up. I carichi di lavoro si basavano su lunghe fasi di produzione con fasi di pre- e post-elaborazione relativamente meno importanti. Uno dei componenti software centrali di qualsiasi cluster HPC era il job scheduler [2], che codificava le politiche di priorità e assegnava le risorse agli utenti [3].
Per quasi due decenni, tuttavia, questo paradigma è stato progressivamente eroso da nuovi sviluppi scientifici: altre discipline, in particolare la biologia, hanno iniziato ad avere problemi di calcolo che non si adattavano più a una workstation di laboratorio [4]. Insieme alle simulazioni “del primo principio”, le attività di pulizia e analisi dei dati sono diventate troppo grandi per le singole macchine [6]. Un esempio di “cosmologia data driven” è il Mini Array ASTRI di Tenerife [7] per il quale E4 sta costruendo l’infrastruttura HPC.
La genomica, la modellazione climatica che utilizza i dati provenienti dai satelliti e dai sensori terrestri e l’astrofisica condividono tutte una caratteristica distintiva: sono data driven e i cambiamenti che hanno imposto al mondo HPC sono quelli in cui la pulizia, la trasformazione e la visualizzazione dei dati sono importanti quanto la pura elaborazione dei numeri, ma richiedono un ecosistema hardware e software diverso [8]. In effetti, questo tipo di ricerca basata sui dati è quello che è stato definito il quarto paradigma. Se si tiene conto della diversità degli strumenti e delle librerie adottate dalle diverse comunità (anche quando si occupano di problemi correlati), la visione di un cluster HPC stabile che offra lo stesso ambiente di base a tutti gli utenti diventa troppo limitata. Un aspetto è il ruolo crescente del calcolo interattivo e della visualizzazione, che modifica le caratteristiche desiderate del componente software centrale dell’HPC, lo scheduler dei lavori. In precedenza, esso poteva mirare semplicemente ad allocare i lavori in lotti per ottenere la massima occupazione delle risorse, dato che tutte le fasi interattive potevano essere eseguite al di fuori dell’ambiente HPC [9]. Questo non è più il caso quando si devono spostare enormi insiemi di dati; quindi, le politiche di allocazione degli strumenti hanno dovuto cambiare consentendo un’occupazione non massima e le politiche di accesso e sicurezza hanno dovuto essere modificate per consentire l’uso di interfacce grafiche; l’uso di notebook browser è diventato un requisito standard per l’HPC. In effetti, questa visione è già stata adottata da diversi importanti centri HPC del mondo ed è alla base delle decisioni prese dalla nostra società sorella di rilasciare le proprie soluzioni di calcolo interattivo.
L’ascesa del Deep Learning (DL), dell’Intelligenza Artificiale (AI) e dei Large Language Models (LLM) e le loro applicazioni commerciali nell’ultimo decennio hanno accelerato tutte queste tendenze. In effetti, l’IA è oggi il principale campo di applicazione dell’HPC: ad esempio, il GPT-3 (per il quale sono disponibili più confronti pubblici) si è basato su 𝑃 =175 miliardi di parametri. È stato stimato che ci vorrebbero 34 giorni (utilizzando una dimensione di batch di 1536) per addestrare il modello utilizzando 𝑛 = 1024 GPU A100. Anche i grandi modelli climatici o le simulazioni di fisica molecolare possono essere eseguiti con una frazione di tutta questa potenza. D’altra parte, le applicazioni di Machine Learning strettamente definite non sono che una frazione dell’intero ecosistema hardware/software necessario per la distribuzione e l’utilizzo di un sistema di IA. In altre parole, se fino a pochi anni fa le esigenze di flessibilità e riconfigurazione su richiesta per l’HPC avevano un impatto sulla ricerca di base e sull’ingegneria, oggi sono una necessità per abilitare una tecnologia critica in tutti i settori industriali.
C’è un’altra condizione che sta cambiando e rendendo più difficile per un “HPC monolitico” soddisfare le esigenze degli utenti, ovvero la sicurezza e l’isolamento. Nella vecchia visione, un cluster HPC doveva essere protetto da intrusioni esterne e usi impropri, ma, all’interno di un recinto interno, la sicurezza non era un argomento principale, soprattutto nelle istituzioni accademiche. L’ascesa dell’IA e delle scienze sociali computazionali e l’ulteriore evoluzione della biologia hanno però cambiato le cose. In Europa, i ricercatori che si occupano di questo tipo di informazioni, in base al Regolamento generale sulla protezione dei dati (GDPR) e al Regolamento Europeo sull’IA, devono rispettare restrizioni specifiche che possono arrivare fino all’isolamento (quasi) totale delle risorse che utilizzano.
Infine, è necessario fare delle considerazioni sul consumo e sull’efficienza energetica. Negli ultimi 20 anni, il Power Usage Effectiveness (PUE) [10], la metrica che misura il sovraccarico energetico dovuto al raffreddamento e al mantenimento dell’infrastruttura, è sceso da 2,5 a 1,5 per i principali centri HPC di tutto il mondo. Ciò significa che, per ogni watt di potenza effettiva dei server, ora abbiamo bisogno di 0,5 W aggiuntivi nel data center. Questo calo dimostra l’impegno profuso nella creazione di infrastrutture HPC efficienti. Al di là dei ragionevoli scopi ecologici [11], gli sconvolgimenti geopolitici degli ultimi anni (che sono destinati a rimanere, come sostengono alcuni analisti) [12], che hanno dato origine a costi energetici elevati e fluttuanti, hanno aumentato la pressione sull’efficienza energetica. La capacità di tracciare la bolletta energetica effettiva di diversi tipi di carichi di lavoro e di ripristinare la “consapevolezza energetica” in un sistema HPC è considerata un fattore abilitante per l’exascale [13].
In conclusione, possiamo fare un’analogia ecologica e considerare i seguenti fattori come fattori limitanti, le forze più importanti che guidano l’evoluzione dell’HPC nel prossimo decennio:
- I nuovi campi scientifici emersi alla fine del secolo scorso richiedono non solo una modellazione dal basso verso l’alto a partire da principi primi, ma anche un calcolo e una visualizzazione interattivi, prestazioni ad alto rendimento e una maggiore quantità di diversità nell’ambiente.
- L’estensione dell’HPC alle applicazioni di intelligenza artificiale per la scienza e l’economia, con la crescente attenzione alla protezione dei dati e ai privilegi degli utenti, crea la necessità di aumentare l’isolamento e la sicurezza all’interno dell’infrastruttura HPC.
- L’aumento dei costi e delle fluttuazioni dell’energia, unito alle mutevoli richieste degli utenti, crea la necessità di un sistema di gestione dell’energia in grado di adattarsi agli shock esterni.
Un HPC riconfigurabile
Come è possibile soddisfare queste esigenze? Come è possibile passare da un HPC “monolitico” a un HPC “modulare” in grado di soddisfare le modifiche alla sua configurazione? La risposta sta nella capacità di descrivere qualsiasi requisito architetturale in modo astratto e standardizzato, nell’essere in grado di utilizzare strumenti in grado di applicare queste modifiche in modo automatizzato e nell’aggiungere sufficienti livelli di astrazione in modo da poter apportare modifiche senza alterare quelle fisiche e fondamentali. Per rispondere ai punti indicati nell’analogia ecologica, l’HPC dovrebbe:
- Consentire diversi tipi di carichi di lavoro, dal momento che la maggior parte delle discipline ora fonde compiti incentrati sui dati e sul calcolo per risolvere i problemi scientifici: ad esempio, la Computer Aided Drug Discovery utilizza la chimica quantistica (incentrata sul calcolo) e la chemioinformatica (incentrata sui dati) per problemi come l’esplorazione del Chemical Space.
- L’era dominata dall’AI e la protezione dei dati: da un lato l’AI è solo un altro tipo di carico di lavoro che comprende molti passaggi intensivi e non intensivi della CPU/GPU, quindi abbiamo già “risolto” (come esperimento di pensiero) questo aspetto. D’altro canto, la possibilità di ridefinire host, storage e rete consente, ad esempio, di isolare temporaneamente alcuni nodi per contenere dati sensibili per la durata di un progetto e poi reinserirli nei pool generali.
- È facile intuire che, rispetto a un’infrastruttura statica, una riconfigurabile sarebbe meno incline al sovradimensionamento e più rapida nell’adattarsi a nuove esigenze. Inoltre, sarebbe più facile modificare le inefficienze evidenziate dai sistemi di monitoraggio, rendendola più efficiente dal punto di vista energetico.
Tuttavia, la flessibilità cresce (più che linearmente?) con la complessità. Quali sono le tecnologie abilitanti che permettono di ottenere questa flessibilità e al tempo stesso di domare la complessità? Se il problema sta nel permettere agli utenti HPC di creare ambienti diversi per soddisfare le loro diverse esigenze, allora gli strumenti giusti sono quelli che permettono di gestire l’isolamento di diverse elaborazioni sullo stesso ferro (isolandole), di riconfigurare lo stesso ferro su richiesta (dato che gli utenti HPC vorranno spremere il massimo delle prestazioni) e quindi, dal punto di vista applicativo, di eseguire insieme carichi di lavoro ad alta intensità di dati o ad alta intensità di calcolo; e di fare queste cose adottando politiche di sicurezza ed energetiche diverse.
Fortunatamente, la maggior parte delle tecnologie necessarie a soddisfare queste esigenze sono state sviluppate nel corso dell’evoluzione dell’infrastruttura IT negli ultimi 15 anni e rilasciate come open source. Anche se il loro uso è ormai diffuso, vale la pena di fare un rapido riepilogo. I primi da citare sono i container, che hanno avuto un impatto significativo sullo sviluppo del software rivoluzionando la creazione e la distribuzione delle applicazioni. Un contenitore software è un modulo eseguibile con tutte le sue dipendenze, tra cui codice, runtime, strumenti di sistema e librerie. La storia della tecnologia dei container risale agli anni ’60 con lo sviluppo della virtualizzazione. Nel 2006, gli ingegneri di Google introdussero i contenitori di processi, in seguito rinominati gruppi di controllo (cgroup), che furono fusi nel kernel Linux nel 2008, portando alla creazione di Linux Containers (LXC). In seguito, nello stesso anno, è emerso come progetto open-source, trasformando la popolarità dei container. I container, tuttavia, non possono da soli garantire la disponibilità del 99,999% di qualsiasi servizio, che è diventata uno standard per la disponibilità dei servizi. La ridondanza e la gestione dei problemi durante il ciclo di vita di un container devono essere gestite con un ulteriore livello di astrazione. Kubernetes è nato da un progetto interno di Google chiamato Borg nel 2014. Orchestrando i container, consente un utilizzo efficiente delle risorse in base alla domanda e automatizza la distribuzione, il ridimensionamento e la gestione delle applicazioni su cluster di host. C’è ancora un fattore: per sfruttarlo appieno bisogna essere in grado di riconfigurare, su richiesta, tutti i componenti come rete, storage, ecc. ma farlo coinvolgendo sempre tutti i componenti fino al ferro vero e proprio sarebbe poco pratico se non del tutto impossibile. Pertanto, è necessario disporre di livelli aggiuntivi, sottostanti, che consentano di mantenere l’architettura fisica il più semplice possibile, pur essendo in grado di applicare tutte le modifiche software defined necessarie, ossia di adottare (anche on premise) un’infrastruttura cloud. A questo scopo, entra in gioco un altro gigantesco progetto open-source (o meglio un insieme di progetti indipendenti ma strettamente correlati), ovvero OpenStack. OpenStack è una piattaforma di cloud computing open-source che fornisce infrastrutture come servizio (IaaS). È stata fondata nel 2010 da Rackspace Hosting e dalla NASA. OpenStack mira a offrire servizi cloud scalabili e flessibili per cloud pubblici e privati. Nel corso degli anni ha guadagnato una notevole popolarità per la sua capacità di gestire in modo efficiente grandi pool di risorse di calcolo, storage e rete. Tuttavia, gli strumenti sono integrati da mentalità e filosofie di lavoro; così come l’evoluzione della scienza e dell’ingegneria ha spinto alcuni sviluppatori di applicazioni scientifiche a concentrarsi sulle interrogazioni dei database piuttosto che sulle prestazioni dei flop, l’evoluzione concomitante dell’infrastruttura HPC ne è lo specchio, con l’adozione di pratiche DevOps anche al di fuori dei grandi centri di calcolo.
In conclusione, dovremmo puntare (laddove non ce l’abbiamo) a un HPC riconfigurabile, in cui non si abbia più un unico cluster con code o ambienti personalizzabili (variabili di impostazione), ma la possibilità di distribuire cluster diversi per scopi diversi e spostare dinamicamente le risorse fisiche tra di essi, implementando politiche dedicate per ciascuno. A meno che non siano dedicate a un unico scopo, le infrastrutture HPC devono trovare un compromesso tra capacità, ossia la possibilità di ospitare lavori di grandi dimensioni con uno scaling significativo, e capacità, ossia la possibilità di ospitare molti lavori diversi con durata, dimensioni e prerequisiti diversi; anche le installazioni dedicate agli studi in un unico dominio, come l’HPCF dell’ECWMF, non sono limitate all’esecuzione di gigantesche esecuzioni parallele. Per i sistemi costruiti per supportare una varietà di studi (tra cui tutti i principali sistemi dell’UE e la maggior parte delle istituzioni accademiche) questo aspetto è ancora più rilevante. c’è ancora un’ultima considerazione da fare per considerare i vantaggi dell’HPC riconfigurabile: la ricerca scientifica si basa sulla riproducibilità; e le simulazioni sono solo una sorta di esperimenti numerici che, a parità di condizioni, dovrebbero essere riproducibili. Non sorprende che, nell’era del data driven, molte riviste richiedano agli autori di caricare i propri dati e di accettare specifiche linee guida [14]: poter isolare diversi pool di risorse e permettere agli utenti di “portare la propria infrastruttura” sotto forma di container facilita enormemente la riproduzione degli esperimenti numerici, poiché la “strumentazione” e i “reagenti” sono esplicitamente riproducibili. La riduzione dei confini tra utenti scientifici e sviluppatori e amministratori di sistema (permettendo loro di condividere una quantità considerevole dello stesso set di strumenti) aumenta la riproducibilità e il controllo sull’intero processo, consentendo di ottenere risultati migliori in tempi più rapidi.
In E4 Computer Engineering e nella nostra consociata, E4 Analytics, stiamo cercando di abbracciare pienamente la visione di un HPC riconfigurabile con la capacità di prosperare sotto le limitazioni descritte sopra. Nei post precedenti abbiamo descritto le nostre soluzioni per carichi di lavoro interattivi e basati sui dati. Il calcolo interattivo, tuttavia, non è che il livello superiore di astrazione. Nei prossimi post illustreremo quelli sottostanti e sveleremo completamente i nostri sforzi verso un HPC riconfigurabile.
Fonti:
[1] https://en.wikipedia.org/wiki/High-performance_computing
[2] https://hpc-wiki.info/hpc/Scheduling_Basics
[3] https://science.osti.gov/-/media/ascr/pdf/program-documents/docs/HPCBP-SL.pdf
[4] https://doi.org/10.1371/journal.pbio.1002195
[5] https://doi.org/10.1016/j.jheap.2022.05.001
[6] https://www.smithsonianmag.com/science-nature/next-big-discovery-astronomy-scientists-probably-found-it-years-ago-they-dont-know-it-yet-180969073/
[7] https://doi.org/10.1016/j.jheap.2022.05.001
[8] 10.1109/MCSE.2023.3282517, https://doi.org/10.1007/s42514-022-00109-9
[9] https://www.fenix-ri.eu/
[10] https://en.wikipedia.org/wiki/Power_usage_effectiveness
[11] https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/european-green-deal_en
[12] https://www.weforum.org/publications/global-risks-report-2024/digest/
[13] https://antarex.fe.up.pt/book/ExaMon.pdf, https://github.com/GreenScheduler/cats
[14] https://www.go-fair.org/fair-principles/