High-Performance Computing su AWS: come scegliere il miglior servizio di storage

L’High-Performance Computing (HPC) ha prodotto risultati davvero degni di nota negli ultimi anni, assumendo un’enorme importanza a livello globale: dalla fluidodinamica alla forma delle proteine ​​e all'analisi funzionale, dalla genomica alla chimica quantistica computazionale. 

Anche se l'HPC ha iniziato a svilupparsi molto prima del cloud computing, questo grazie ad enormi supercomputer a partire dagli anni '90, l'ascesa di quest’ultimo ha fortemente democratizzato l'HPC. 

Ad esempio, un ricercatore che studia un nuovo materiale non ha più bisogno di inviare una proposal ad un centro di calcolo per ottenere le proprietà elettroniche del suo nuovo materiale fortemente correlato, ma può semplicemente avviare 200 istanze spot sul suo account AWS, eseguire il carico di lavoro, scaricare il risultati e infine spegnere il cluster. 

Tutto questo per pochi dollari. 

Prendendo le distanze dal lungo e frustrante processo di revisione delle proposal, necessario per accedere a un supercomputer, lo scienziato può ora ottenere gli stessi risultati in una frazione del tempo, con il minimo sforzo, e agire più rapidamente sui risultati: se un nuovo esperimento dovesse scoprire una composizione leggermente diversa, con proprietà migliori rispetto al campione originale, il ricercatore può semplicemente rieseguire l'analisi durante la notte senza alcun sovraccarico aggiuntivo.

Avere a disposizione la potenza di calcolo di cui si necessita, esattamente quando se ne ha bisogno e pagare solo per ciò che si usa effettivamente, ha un enorme valore in queste situazioni.

Configurare un workload HPC basato sul Cloud, sebbene notevolmente più semplice rispetto alla sua controparte on-premise, è tutt'altro che un compito banale. Tuttavia, una volta completata la configurazione di un cluster in grado di eseguire l'attività in questione, la sua configurazione può essere facilmente salvata e replicata utilizzando metodologie di Infrastructure as Code (es. Cloudformation).

Ogni workload di HPC su AWS può essere suddiviso in due componenti separate e specifiche: Archiviazione e Calcolo. 

Questo articolo si concentrerà principalmente sulla parte di Archiviazione e vedrà come S3 può risolvere la maggior parte dei problemi. In un prossimo articolo ci concentreremo invece sulla creazione di un cluster HPC reale.

Soluzioni di storage in AWS

Lo storage dei dati è un problema fondamentale per l’HPC: in un cluster HPC on-premise, probabilmente la scelta più ovvia sarebbe un file system distribuito come Lustre o una soluzione basata su SAN come OCFS2 (o entrambe), ma su AWS si hanno molte più opzioni ed è possibile combinarle per ottenere i migliori risultati per il proprio carico di lavoro. 

Di seguito è riportato un elenco delle opzioni di archiviazione che possono essere utilizzate in un cluster HPC su AWS:

S3 - Simple Storage Service

Adatto all’archiviazione di oggetti per gli scopi più svariati, molto potente e con molte funzioni interessanti. S3 è il secondo servizio AWS più vecchio (dopo SQS) e ora ha quasi 15 anni ed è molto maturo. 

Alcune delle funzionalità più utili sono:

Notifica basata su eventi: puoi ricevere notifiche quando un oggetto viene scritto o modificato / eliminato. Si integra facilmente con SQS.

Replica del bucket: è possibile utilizzare questa funzionalità per duplicare il contenuto del bucket S3 in altre regioni e / o account AWS per scopi di backup e segregazione delle applicazioni.

Classi di archiviazione: quando si carica un file è possibile scegliere la classe di archiviazione. 

1. Standard storage è adatta per applicazioni “write seldom - read many”. 

2. Infrequent access è più adatta per applicazioni con richieste di lettura non eccessive: l'archiviazione per accessi poco frequenti costa la metà dell'archiviazione standard, ma si paga il doppio per una richiesta API GET. 

Tiering intelligente: lasciare che AWS determini il livello più consono per un file archiviato tramite il suo modello di accesso e lo sposti di conseguenza nella classe di archiviazione più conveniente.

Lifecycle policies: l'utilizzo dei dati varia nel tempo. È possibile impostare transizioni per spostare i file più vecchi in classi di archiviazione meno costose. I file molto vecchi possono anche essere spostati automaticamente in AWS Glacier, per l'archiviazione a freddo. Si può anche decidere di eliminare ("far scadere") un file quando diventa troppo vecchio!

EBS - Elastic Block Storage

Block store a singola istanza general-purpose, basato su rete. È uno storage a istanza singola fornito di una vasta gamma di tipi di volume, ciascuno con diversi scopi e impostazioni disponibili. 

Ad esempio, i dischi ad uso generico (GP) possono essere utilizzati per ospitare la root directory di una instanza EC2, mentre i dischi con provisioning IOPS (io1, io2), più costosi, sono particolarmente adatti all'archiviazione dei dati per i motori di database. 

Un'opzione di “mounting” di istanze multiple è disponibile per i dischi io1-2, ma dovrebbe essere usata con attenzione e solo se il filesystem è un file system che riconosce i cluster, ad esempio OCFS2, o se il disco è montato in sola lettura.

Instance ephemeral Storage  

Some tipi di istanza AWS EC2 che offrono scratch SSD fisiche collegate. I dati in questi dischi sono temporanei e vengono persi quando un'istanza si arresta. Questi tipi di istanze sono molto utili.

EFS - Elastic File Storage 

Storage compatibile con NFSv4. È una soluzione molto flessibile poiché la sua capacità di archiviazione si ridimensiona automaticamente, ed è persino possibile spostare i file a cui si accede raramente, in un'opzione di archiviazione di tipo “infrequent access” con un prezzo di archiviazione identico a S3. 

Quando si utilizza EFS si dovrebbe sempre pianificare in anticipo le prestazioni necessarie, infatti, è possibile creare due diversi tipi di dischi: Bursting e Provisioned IOPS. 

I sistemi di file burst possono essere una scelta valida per applicazioni che hanno un utilizzo ridotto del disco e con picchi di utilizzo occasionali, mentre l'opzione Provisioned IOPS, molto più costosa, dovrebbe essere impiegata per le applicazioni che richiedono prestazioni costanti e hanno un utilizzo significativo del disco.

FSX per Lustre 

Una versione cloud-native del popolare file system Linux Luster Cluster; questo file system distribuito è molto utile, qualora sia necessario trasferire su AWS un carico di lavoro che già utilizza Lustre su un cluster locale. 

Tuttavia, per quanto possa essere valido, FSX Lustre presenta alcuni difetti: il file system è piuttosto costoso (in particolare per l'archiviazione persistente) e la dimensione minima piuttosto grande (> 1 TB).  

Inoltre, Lustre può essere implementato in una sola availability zone, quindi se il cluster si estende su più availability zone si verificano rallentamenti significativi e costi di trasferimento dei dati elevati. 

Nonostante questi compromessi, inevitabili per portare il file system su AWS, Lustre presenta anche alcuni vantaggi significativi: prezzi migliori su larga scala e in genere inferiori rispetto a EFS, e prestazioni estremamente elevate fino a centinaia di migliaia di IOPS.

In generale, un workload HPC può utilizzare un sottoinsieme combinato di tutte queste soluzioni di archiviazione e decidere di volta in volta quale utilizzare. 

Analisi del workload

Nella maggior parte dei flussi di lavoro, diversi passaggi risultano piuttosto banali e simili tra loro, anche per applicazioni molto diverse. 

Di seguito, faremo riferimento all'infrastruttura di un workload di analisi dati di genomica in HPC, tipica del mondo reale, che abbiamo recentemente creato; molti dei passaggi di questo flusso di lavoro si adattano molto bene a un tipo di archiviazione specifico, quindi non è necessario analizzarlo eccessivamente; perciò, ecco cosa funziona meglio nella maggior parte degli scenari:

App per l’input / output utente 

Molti workflow di analisi devono ricevere dati di input molto grandi e produrre output di analisi altrettanto grandi, da condividere poi con gli utenti finali. Per questo passaggio la scelta di archiviazione ideale risulta S3. 

Gli oggetti possono essere caricati direttamente su S3 dalle applicazioni rivolte ai clienti, quindi non è necessario caricare i file nell'applicazione di backend prima di passarli a S3. 

Nel nostro caso, i file genomici vengono caricati direttamente su S3 dal browser utilizzando l’SDK AWS per Javascript mentre le credenziali AWS, necessarie per farlo, sono fornite da un distributore automatico di credenziali implementato nel back-end dell'applicazione web. 

L'output dell'analisi può anche essere scaricato da S3 utilizzando un URL pre-firmato.

Directory principali dei Nodi

La scelta del tipo di archiviazione per le directory root è banale: l'unica scelta supportata in AWS è EBS!

Codice e librerie

Il codice delle proprie applicazioni è il cuore di una soluzione HPC ed il motivo principale per cui si decide di configurarne una! 

Ma dove andrebbe memorizzato per renderlo disponibile a tutti i nodi del cluster? La soluzione più ovvia è semplicemente memorizzarlo su un volume EFS montato su tutti i nodi. Sfortunatamente, questa è spesso una pessima idea: EFS è un volume NFS e quindi ha diversi problemi di prestazioni quando si lavora con un gran numero di piccoli file, situazione molto comune nelle librerie software. 

Una soluzione migliore è utilizzare semplicemente un volume EBS dedicato: si può installare la propria app utilizzando una soluzione come Ansible e per poi utilizzarla per installare e aggiornare il software su tutti i nodi. 

Inoltre, è sempre possibile creare una nuova AMI per i nodi, ogni volta che viene rilasciata una nuova versione dell'applicazione, se il proprio cluster è pensato per essere scalabile, in modo che ogni nuovo nodo parta con la versione più recente della propria applicazione. 

Se si desidera una soluzione di distribuzione più semplice e il pacchetto di codice è piccolo (non più di qualche GB come regola pratica), si può semplicemente archiviarlo su S3 e scaricarlo quando viene avviata una nuova istanza del Cluster.

Tuttavia, qualora le applicazioni:

1.  siano relativamente compatte, 
2. vengano eseguite principalmente in RAM (ad es. script python),
3.  non richiedano un numero enorme di file lib, 

la distribuzione del codice utilizzando EFS potrebbe funzionare particolarmente bene, facendo risparmiare una buona parte di lavoro di configurazione per la creazione di un pipeline per le AMI personalizzata. 

Quest’ultimo caso di archiviazione è meno lineare rispetto ai precedenti, a dimostrazione che gli scenari del mondo reale dovrebbero essere sempre analizzati con cura e test delle prestazioni eseguiti frequentemente.

Asset Statici

Gli asset statici sono un'ampia categoria di artefatti utilizzati dalle applicazioni HPC per eseguire calcoli. Esempi di file statici sono le descrizioni dei geni genomici e le rappresentazioni APW precalcolate nella chimica quantistica. 

Questi file possono variare notevolmente in dimensioni che vanno da pochi MB a diversi TB, ed hanno molte cose in comune:

1. Raramente cambiano nel tempo 
2. Sono di sola lettura (scrivi una volta ne leggi molti)
3. Sono necessari a tutti i nodi del cluster

La posizione più "naturale" dove salvare questi file è solitamente S3, ma le cose spesso si rivelano molto più complicate di quanto sembri. 

Memorizzare questi artefatti su S3, sebbene in linea di principio sempre preferibile, ha senso solo se si controlla completamente il modello di accesso agli artefatti (si è scritto per intero il codice), o se la libreria che si sta usando considera esplicitamente i file in S3 (quasi sempre non è il caso). 

Qualora fosse necessario utilizzare una libreria di terze parti per accedere agli artefatti, potrebbe essere mandatorio averli in uno storage a blocchi, perché molto spesso queste librerie sono create per leggere i file da un file system di tipo block storage. 

Ciò che viene subito in mente è utilizzare EFS, ma questo di solito non è praticabile, se le istanze hanno bisogno di leggere un gran numero di file in un tempo molto breve: se più nodi lo fanno contemporaneamente, probabilmente si andrà a saturare il throughput EFS. 

Sebbene si possa considerare anche Lustre, spesso è più conveniente, soprattutto per i cluster multi AZ, archiviare semplicemente i file in un disco EBS dedicato per ogni nodo. 

I nuovi dischi GP3 sono economici e forniscono prestazioni abbastanza buone. Questo disco aggiuntivo dovrebbe essere agganciato all'AMI del cluster di nodi e di conseguenza aggiornato con lo stesso flusso già proposto per il codice dell'applicazione.

Tuttavia, un'altra soluzione intelligente per i file system di sola lettura consiste nell'utilizzare S3 come archiviazione a blocchi. Per fare ciò, è possibile sfruttare soluzioni esistenti come s3backer o scrivere la propria soluzione personalizzata. Le prestazioni, per i bucket S3 nella stessa regione del cluster, sono sorprendentemente buone e spesso rivaleggiano con EBS.

Scratch a nodo singolo 

Per lo scratch a nodo singolo, si può solo scegliere tra lo storage dell'istanza e EBS. L'archiviazione su istanza è di gran lunga la soluzione più veloce, tuttavia se si decide di ridimensionare il proprio cluster utilizzando l'istanza spot, la scalabilità del cluster sarà notevolmente limitata dal numero di istanze di tipo d disponibili (ad es. M5d.large). Inoltre, si dovrà formattare lo storage dell'istanza utilizzando i dati dell'utente all'avvio di quest’ultima. 

Va sempre tenuto presente che ogni istanza di tipo d di AWS presenta uno storage SSD diverso e non può essere modificato (tabella completa qui). Per alcuni carichi di lavoro, in cui la dimensione dello scratch può variare notevolmente, uno storage EFS dedicato all'istanza può anche diventare una soluzione conveniente.

Cross Node Scratch

Lo scratch cross nodo può risultare in un “pasticcio” molto costoso e il suo utilizzo dovrebbe essere ridotto al minimo indispensabile. La soluzione migliore è sempre quella di memorizzare i dati su S3, ma come spiegato prima, spesso questa soluzione non è possibile. Le uniche alternative praticabili sono Lustre ed EFS, tuttavia, EFS è conveniente solo per file di piccole dimensioni, per lo scratch condiviso ad alto throughput invece, Lustre vince agevolmente, sia per costo che per velocità.

Conclusione

In questo articolo, abbiamo descritto le diverse opzioni di archiviazione disponibili per lo storage cluster in AWS e analizzato come utilizzarle. Abbiamo imparato che, in caso di dubbio, S3 è molto probabilmente la scelta giusta.

Cosa ne pensi? Quale servizio ritieni sia il migliore in questo contesto? Se hai commenti o suggerimenti, non esitare a scriverci nella nostra sezione di commenti.

E se sei interessato all'argomento non perdere il prossimo articolo sulla creazione di un Cluster HPC reale!