L\u2019High-Performance Computing (HPC) ha prodotto risultati davvero degni di nota negli ultimi anni, assumendo un\u2019enorme importanza a livello globale: dalla fluidodinamica alla forma delle proteine \u200b\u200be all’analisi funzionale, dalla genomica alla chimica quantistica computazionale. <\/p>\n\n\n\n
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\u2019ultimo ha fortemente democratizzato l’HPC. <\/p>\n\n\n\n
Ad esempio, un ricercatore che studia un nuovo materiale non ha pi\u00f9 bisogno di inviare una proposal ad un centro di calcolo per ottenere le propriet\u00e0 elettroniche del suo nuovo materiale fortemente correlato, ma pu\u00f2 semplicemente avviare 200 istanze spot sul suo account AWS, eseguire il carico di lavoro, scaricare il risultati e infine spegnere il cluster. <\/p>\n\n\n\n
Tutto questo per pochi dollari. <\/p>\n\n\n\n
Prendendo le distanze dal lungo e frustrante processo di revisione delle proposal, necessario per accedere a un supercomputer, lo scienziato pu\u00f2 ora ottenere gli stessi risultati in una frazione del tempo, con il minimo sforzo, e agire pi\u00f9 rapidamente sui risultati: se un nuovo esperimento dovesse scoprire una composizione leggermente diversa, con propriet\u00e0 migliori rispetto al campione originale, il ricercatore pu\u00f2 semplicemente rieseguire l’analisi durante la notte senza alcun sovraccarico aggiuntivo.<\/p>\n\n\n\n
Avere a disposizione la potenza di calcolo di cui si necessita, esattamente quando se ne ha bisogno e pagare solo per ci\u00f2 che si usa effettivamente, ha un enorme valore in queste situazioni.<\/p>\n\n\n\n
Configurare un workload HPC basato sul Cloud, sebbene notevolmente pi\u00f9 semplice rispetto alla sua controparte on-premise, \u00e8 tutt’altro che un compito banale. Tuttavia, una volta completata la configurazione di un cluster in grado di eseguire l’attivit\u00e0 in questione, la sua configurazione pu\u00f2 essere facilmente salvata e replicata utilizzando metodologie di Infrastructure as Code (es. Cloudformation).<\/p>\n\n\n\n
Ogni workload di HPC su AWS pu\u00f2 essere suddiviso in due componenti separate e specifiche: Archiviazione<\/strong> e Calcolo<\/strong>. <\/p>\n\n\n\n Questo articolo si concentrer\u00e0 principalmente sulla parte di Archiviazione e vedr\u00e0 come S3 pu\u00f2 risolvere la maggior parte dei problemi. In un prossimo articolo ci concentreremo invece sulla creazione di un cluster HPC reale.<\/p>\n\n\n\n Lo storage dei dati \u00e8 un problema fondamentale per l\u2019HPC: in un cluster HPC on-premise, probabilmente la scelta pi\u00f9 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\u00f9 opzioni ed \u00e8 possibile combinarle per ottenere i migliori risultati per il proprio carico di lavoro. <\/p>\n\n\n\n Di seguito \u00e8 riportato un elenco delle opzioni di archiviazione che possono essere utilizzate in un cluster HPC su AWS:<\/p>\n\n\n\n S3 – Simple Storage Service<\/strong><\/p>\n\n\n\n Adatto all\u2019archiviazione di oggetti per gli scopi pi\u00f9 svariati, molto potente e con molte funzioni interessanti. S3 \u00e8 il secondo servizio AWS pi\u00f9 vecchio (dopo SQS) e ora ha quasi 15 anni ed \u00e8 molto maturo<\/strong>. <\/p>\n\n\n\n Alcune delle funzionalit\u00e0 pi\u00f9 utili sono:<\/p>\n\n\n\n Notifica basata su eventi<\/strong>: puoi ricevere notifiche quando un oggetto viene scritto o modificato \/ eliminato. Si integra facilmente con SQS.<\/p>\n\n\n\n Replica del bucket<\/strong>: \u00e8 possibile utilizzare questa funzionalit\u00e0 per duplicare il contenuto del bucket S3 in altre regioni e \/ o account AWS per scopi di backup e segregazione delle applicazioni.<\/p>\n\n\n\n Classi di archiviazione<\/strong>: quando si carica un file \u00e8 possibile scegliere la classe di archiviazione. <\/p>\n\n\n\n Tiering intelligente<\/strong>: lasciare che AWS determini il livello pi\u00f9 consono per un file archiviato tramite il suo modello di accesso e lo sposti di conseguenza nella classe di archiviazione pi\u00f9 conveniente.<\/p>\n\n\n\n Lifecycle policies<\/strong>: l’utilizzo dei dati varia nel tempo. \u00c8 possibile impostare transizioni per spostare i file pi\u00f9 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\u00f2 anche decidere di eliminare (“far scadere”) un file quando diventa troppo vecchio!<\/p>\n\n\n\n EBS – Elastic Block Storage<\/strong><\/p>\n\n\n\n Block store a singola istanza general-purpose, basato su rete. \u00c8 uno storage a istanza singola fornito di una vasta gamma di tipi di volume, ciascuno con diversi scopi e impostazioni disponibili. <\/p>\n\n\n\n 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\u00f9 costosi, sono particolarmente adatti all’archiviazione dei dati per i motori di database. <\/p>\n\n\n\n Un’opzione di \u201cmounting\u201d di istanze multiple \u00e8 disponibile per i dischi io1-2, ma dovrebbe essere usata con attenzione e solo se il filesystem \u00e8 un file system che riconosce i cluster, ad esempio OCFS2, o se il disco \u00e8 montato in sola lettura.<\/strong><\/p>\n\n\n\n Instance ephemeral Storage <\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n EFS – Elastic File Storage <\/strong><\/p>\n\n\n\n Storage compatibile con NFSv4. \u00c8 una soluzione molto flessibile poich\u00e9 la sua capacit\u00e0 di archiviazione si ridimensiona automaticamente, ed \u00e8 persino possibile spostare i file a cui si accede raramente, in un’opzione di archiviazione di tipo \u201cinfrequent access\u201d con un prezzo di archiviazione identico a S3. <\/p>\n\n\n\n Quando si utilizza EFS si dovrebbe sempre pianificare in anticipo le prestazioni necessarie, infatti, \u00e8 possibile creare due diversi tipi di dischi: Bursting<\/strong> e Provisioned IOPS<\/strong>. <\/p>\n\n\n\n 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\u00f9 costosa, dovrebbe essere impiegata per le applicazioni che richiedono prestazioni costanti e hanno un utilizzo significativo del disco.<\/p>\n\n\n\n FSX per Lustre<\/strong> <\/p>\n\n\n\n Una versione cloud-native del popolare file system Linux Luster Cluster; questo file system distribuito \u00e8 molto utile, qualora sia necessario trasferire su AWS un carico di lavoro che gi\u00e0 utilizza Lustre su un cluster locale. <\/p>\n\n\n\n Tuttavia, per quanto possa essere valido, FSX Lustre presenta alcuni difetti: il file system \u00e8 piuttosto costoso (in particolare per l’archiviazione persistente) e la dimensione minima piuttosto grande (> 1 TB). <\/p>\n\n\n\n Inoltre, Lustre pu\u00f2 essere implementato in una sola availability zone, quindi se il cluster si estende su pi\u00f9 availability zone si verificano rallentamenti significativi e costi di trasferimento dei dati elevati. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n In generale, un workload HPC pu\u00f2 utilizzare un sottoinsieme combinato di tutte queste soluzioni di archiviazione e decidere di volta in volta quale utilizzare. <\/p>\n\n\n\n Nella maggior parte dei flussi di lavoro, diversi passaggi risultano piuttosto banali e simili tra loro, anche per applicazioni molto diverse. <\/p>\n\n\n\n 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 \u00e8 necessario analizzarlo eccessivamente; perci\u00f2, ecco cosa funziona meglio nella maggior parte degli scenari:<\/p>\n\n\n\n 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. <\/strong><\/p>\n\n\n\n Gli oggetti possono essere caricati direttamente su S3 dalle applicazioni rivolte ai clienti, quindi non \u00e8 necessario caricare i file nell’applicazione di backend prima di passarli a S3. <\/p>\n\n\n\n Nel nostro caso, i file genomici vengono caricati direttamente su S3 dal browser utilizzando l\u2019SDK 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. <\/p>\n\n\n\n L’output dell’analisi pu\u00f2 anche essere scaricato da S3 utilizzando un URL pre-firmato.<\/p>\n\n\n\n La scelta <\/strong>del <\/strong>tipo di archiviazione per le directory root \u00e8 banale: l’unica scelta supportata in AWS \u00e8 EBS!<\/p>\n\n\n\n Il codice delle proprie applicazioni \u00e8 il cuore di una soluzione HPC ed il motivo principale per cui si decide di configurarne una! <\/p>\n\n\n\n Ma dove andrebbe memorizzato per renderlo disponibile a tutti i nodi del cluster? La soluzione pi\u00f9 ovvia \u00e8 semplicemente memorizzarlo su un volume EFS montato su tutti i nodi. Sfortunatamente, questa \u00e8 spesso una pessima idea: EFS \u00e8 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. <\/p>\n\n\n\n Una soluzione migliore \u00e8 utilizzare semplicemente un volume EBS dedicato: si pu\u00f2 installare la propria app utilizzando una soluzione come Ansible e per poi utilizzarla per installare e aggiornare il software su tutti i nodi. <\/p>\n\n\n\n Inoltre, \u00e8 sempre possibile creare una nuova AMI per i nodi, ogni volta che viene rilasciata una nuova versione dell’applicazione, se il proprio cluster \u00e8 pensato per essere scalabile, in modo che ogni nuovo nodo parta con la versione pi\u00f9 recente della propria applicazione. <\/p>\n\n\n\n Se si desidera una soluzione di distribuzione pi\u00f9 semplice e il pacchetto di codice \u00e8 piccolo (non pi\u00f9 di qualche GB come regola pratica), si pu\u00f2 semplicemente archiviarlo su S3 e scaricarlo quando viene avviata una nuova istanza del Cluster.<\/p>\n\n\n\n Tuttavia, qualora le applicazioni:<\/p>\n\n\n\n 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. <\/p>\n\n\n\n Quest\u2019ultimo caso di archiviazione \u00e8 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.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n Questi file possono variare notevolmente in dimensioni che vanno da pochi MB a diversi TB, ed hanno molte cose in comune:<\/p>\n\n\n\n La posizione pi\u00f9 “naturale” dove salvare questi file \u00e8 solitamente S3, ma le cose spesso si rivelano molto pi\u00f9 complicate di quanto sembri. <\/p>\n\n\n\n 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 \u00e8 scritto per intero il codice), o se la libreria che si sta usando considera esplicitamente i file in S3 (quasi sempre non \u00e8 il caso). <\/p>\n\n\n\n Qualora fosse necessario utilizzare una libreria di terze parti per accedere agli artefatti, potrebbe essere mandatorio averli in uno storage a blocchi, perch\u00e9 molto spesso queste librerie sono create per leggere i file da un file system di tipo block storage. <\/p>\n\n\n\n Ci\u00f2 che viene subito in mente \u00e8 utilizzare EFS, ma questo di solito non \u00e8 praticabile, se le istanze hanno bisogno di leggere un gran numero di file in un tempo molto breve: se pi\u00f9 nodi lo fanno contemporaneamente, probabilmente si andr\u00e0 a saturare il throughput EFS. <\/p>\n\n\n\n Sebbene si possa considerare anche Lustre, spesso \u00e8 pi\u00f9 conveniente, soprattutto per i cluster multi AZ, archiviare semplicemente i file in un disco EBS dedicato per ogni nodo. <\/p>\n\n\n\n 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\u00e0 proposto per il codice dell’applicazione.<\/p>\n\n\n\n Tuttavia, un’altra soluzione intelligente per i file system di sola lettura consiste nell’utilizzare S3 come archiviazione a blocchi. Per fare ci\u00f2, \u00e8 possibile sfruttare soluzioni esistenti come s3backer<\/a> 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.<\/p>\n\n\n\nSoluzioni di storage in AWS<\/h2>\n\n\n\n
Analisi del workload<\/h2>\n\n\n\n
App per l\u2019input \/ output utente <\/strong><\/h3>\n\n\n\n
Directory principali dei Nodi<\/strong><\/h3>\n\n\n\n
Codice e librerie<\/strong><\/h3>\n\n\n\n
Asset Statici<\/strong><\/h3>\n\n\n\n
Scratch a nodo singolo <\/strong><\/h3>\n\n\n\n