Utilizzo dei cluster per il computing tecnico su larga scala nel cloud

Questa soluzione fornisce indicazioni per l'esecuzione di computing tecnico su larga scala su Google Cloud. Molte app di calcolo tecnico richiedono un numero elevato di singoli nodi di computing, connessi tra loro in un cluster e coordinano l'accesso al calcolo e ai dati tra i nodi.

I concetti e le tecnologie alla base del computing su cluster si sono sviluppati negli ultimi decenni e sono ormai maturi e di uso comune. La migrazione dello stack di software in Google Cloud può aggiungere alcune pieghe, ma offre anche una serie di opportunità per ridurre i costi e ridurre i colli di bottiglia esistenti negli ambienti di calcolo ad alte prestazioni di oggi. Questa guida fornisce una panoramica delle tecnologie, delle sfide e dell'attuale ritaglio di soluzioni per l'esecuzione di cluster di calcolo su Google Cloud.

Il cluster computing aggrega e coordina una raccolta di macchine per lavorare insieme per risolvere un'attività. I cluster in genere hanno un singolo nodo head (a volte chiamato nodo master), un certo numero di nodi di calcolo ed eventualmente alcuni altri nodi speciali. Il nodo head è il cervello del sistema ed è responsabile di:

  • Registrazione dei nodi di computing nel sistema.
  • Monitoraggio dei nodi.
  • Allocazione di job a nodi specifici.
Un cluster è composto da un nodo head e da un insieme di nodi di computing.
Figura 1. Un cluster è composto da un nodo head e da un set di nodi di calcolo. Gli utenti interagiscono con il nodo head, che coordina le coordinate verso i nodi di computing.

Gli utenti inviano job, composti da molte attività, in cui un'attività è l'unità di base del lavoro, Alcune app richiedono l'esecuzione contemporanea di tutte le attività di un job e consentono alle attività di comunicare per implementare un algoritmo parallelo; inoltre, alcuni job hanno un insieme complesso di dipendenze, in modo che determinate attività debbano essere eseguite prima di altre e altre potrebbero richiedere configurazioni del nodo specifiche in termini di memoria, CPU o altro hardware specifico su cui eseguire. Le attività sono file eseguibili che leggono i dati di input dall'archiviazione, elaborano i dati per produrre un risultato e poi scrivono di nuovo i risultati finali nell'archivio.

Esistono due tipi principali di carichi di lavoro di cluster computing:

  • Computing ad alte prestazioni (HPC): un tipo di computing che utilizza molti nodi worker, strettamente collegati ed eseguiti in contemporanea per eseguire un'attività. Queste macchine in genere richiedono una bassa latenza di rete per comunicare in modo efficace. Alcuni esempi di app in questo settore sono la modellazione del meteo, la dinamica dei fluidi computazionali, la modellazione dello stress nell'ingegneria e la progettazione elettronica.

  • Computing ad alta velocità effettiva (HTC): un tipo di computing in cui le app hanno più attività elaborate separatamente l'una dall'altra senza la necessità di comunicare i singoli nodi di computing. Questi carichi di lavoro sono chiamati carichi di lavoro parallelamente paralleli o in serie. Gli esempi tipici includono rendering multimediale, transcodifica, genomica e simulazione ed elaborazione di eventi particelle-fisica. Se devi elaborare molti file singoli, probabilmente è un carico di lavoro HTC.

Stack software per cluster di elaborazione

Uno stack software di cluster computing è composto da:

  • Software di gestione del sistema che esegue il provisioning e la creazione dei cluster.
  • Scheduler che orchestrano l'esecuzione dei job.
  • App dell'utente finale.

Le sezioni seguenti illustrano software di gestione del sistema e scheduler.

Software di gestione del sistema

Puoi eseguire il software di clustering direttamente sull'hardware bare-metal, come con i cluster on-premise, o in ambienti virtualizzati, come negli ambienti cloud. L'orchestrazione manuale di più nodi in un cluster richiede molto tempo ed è soggetta a errori. Puoi utilizzare un software di gestione del cluster specializzato per eseguire il provisioning e la configurazione di più nodi e risorse, insieme, in modo ripetibile e deterministico.

Il software open source ElastiCluster dell'Università di Zurigo offre un approccio cloud-native alla gestione dei cluster, con supporto per il provisioning dei nodi, utilizzando Compute Engine e la configurazione dei nodi tramite un set di playbook Ansible. ElastiCluster esegue il provisioning dei nodi e installa uno stack software di base, inclusi NFS per la pubblicazione di file, la gestione degli account utente NIS e uno scheduler di job per l'esecuzione di app utente. ElastiCluster supporta una varietà di scheduler e puoi utilizzarlo immediatamente o personalizzarlo per soddisfare le esigenze dei team di piccole e medie dimensioni.

Se utilizzi altri sistemi di gestione della configurazione per gestire i cluster HPC, come Chef, Puppet o Terraform, puoi sfruttare tali investimenti mentre esegui la migrazione a Google Cloud utilizzando gli strumenti e i plug-in disponibili.

Google Cloud fornisce servizi nativi per il provisioning e il deployment di sistemi software multinodo. Cloud Deployment Manager consente di eseguire il provisioning di un set di risorse cloud tra cui Compute Engine, gruppi di istanze gestite di Compute Engine e Cloud Storage. Il tutorial di HTCondor mostra come utilizzare Cloud Deployment Manager e i gruppi di istanze gestite per eseguire il provisioning e configurare un cluster.

Pianificazione job

Quando il cluster è operativo, il software che gestisce l'esecuzione delle attività e l'allocazione dei nodi viene chiamato scheduler del job (a volte chiamato gestore dei carichi di lavoro o gestore della coda). Spesso, un programma di gestione dei cluster è dotato di uno scheduler integrato. Gli scheduler dei job offrono diverse funzionalità per aiutarti a gestire i job e le attività, ad esempio:

  • Supporto per le priorità dei job tra utenti e gruppi, che consente di fornire una pianificazione dei job basata su criteri.
  • Supporto per le attività non riuscite accodando e ripianificando le attività.
  • Considerazione delle dipendenze delle attività e delle esigenze di risorse per l'allocazione delle attività.
  • Scalabilità delle dimensioni del cluster in base al numero di job in coda.

I gestori dei carichi di lavoro commerciali e open source sono numerosi. Alcuni esempi includono HTCondor di University of Wisconsin, Slurm-GCP di SchedMD, Altair Grid Engine e IBM Spectrum LSF. Ognuno ha i suoi punti di forza.

HTCondor si basa sulla filosofia shared-noth e viene utilizzato tra le risorse condivise per pianificare opportunità di lavoro su risorse altrimenti inattive. Offri il proprio spostamento di dati e, di conseguenza, non richiede alcun file system condiviso. Di conseguenza, HTCondor scala a centinaia di migliaia di core e può essere utilizzato in più zone e aree geografiche. È stato utilizzato HTCondor per i carichi di lavoro ibridi, in cui il lavoro viene condiviso o suddiviso tra sistemi on-premise e basati su cloud. Tuttavia, come suggerisce il nome, è incentrato sui job ad alta velocità effettiva, non sui job paralleli strettamente collegati.

Slurm e Altair Grid Engine offrono un ambiente cluster HPC più tradizionale, che supporta app parallele ad alta velocità effettiva e prestazioni elevate. Entrambi presuppongono un file system condiviso tra i nodi, eliminando la necessità di spostare i dati. Entrambi offrono un ambiente utente pratico e familiare per lo sviluppo di app, perché spesso sono gli stessi strumenti utilizzati on-premise. Questi scheduler di job tradizionali sono sufficienti per cluster di piccole e medie dimensioni, ma all'aumentare delle dimensioni del cluster, il carico sul file server diventa il collo di bottiglia per le prestazioni. I file system paralleli e distribuiti (vedi la sezione successiva) possono risolvere questo problema quando sono utilizzati su larga scala. In alternativa, in cui non è richiesto l'accesso a file a bassa latenza, puoi utilizzare Cloud Storage, che fornisce l'accesso parallelo agli oggetti tramite l'API o tramite gcsfuse, dove è richiesta la compatibilità POSIX.

Infine, Google Cloud include un semplice servizio per pianificare un'attività basata su Docker su Compute Engine per carichi di lavoro ad alta velocità effettiva: l'API Pipeline di Cloud Life Sciences. Questo servizio richiede la scomposizione del job in attività, la gestione delle dipendenze tra le attività e il ciclo di vita delle attività. Il progetto open source dsub fornisce uno strumento a riga di comando per lanciare i job batch e supporta l'API Cloud Life Sciences Pipelines.

Archiviazione

La maggior parte delle applicazioni HPC richiede una soluzione di archiviazione di file che supporta l'API POSIX. Per i cluster più piccoli, FileStore offre un servizio di archiviazione di file gestito da Google e basato su NFS. Per i cluster più grandi, tuttavia, l'I/O dell'applicazione può diventare un collo di bottiglia. Scale-out e file system paralleli, ad esempio Filestore High Scale, Lustre o Quobyte, per aiutarti a scalare in cluster di grandi dimensioni (o anche nei cluster più piccoli con I/O molto pesanti).

In alternativa, quando l'accesso ai file a bassa latenza non è obbligatorio, puoi utilizzare Cloud Storage, che fornisce un accesso parallelo agli oggetti tramite l'API o tramite gcsfuse se è richiesta la compatibilità di POSIX.

Opportunità di clustering nel cloud

Ci sono molti motivi per eseguire i cluster di calcolo nel cloud:

  • Tempo di soluzione. Il lancio di un cluster di qualità produzione nel cloud richiede solo pochi minuti, da un piccolo cluster a 10 nodi con centinaia di core disponibili a cluster su larga scala con centinaia di migliaia di core. Al contrario, la creazione di nuovi cluster on-premise può richiedere mesi per essere pronta per essere operativa. Anche quando i cluster on-premise sono disponibili, hanno in genere un utilizzo elevato e tempi di attesa lunghi in coda, a volte ore o giorni, prima che i job siano pianificati per l'esecuzione. In alternativa, puoi creare i tuoi cluster nel cloud, utilizzarli per i tuoi carichi di lavoro e terminare i cluster al termine dell'analisi.

  • Costo totale di proprietà inferiore. Google Cloud non solo riduce i tempi di soluzione, ma può anche ridurre il costo totale di esecuzione sfruttando le VM Spot, gli sconti per l'utilizzo a lungo termine e la scalabilità dinamica. Puoi aggiungere nodi quando i job sono in coda e rimuoverli quando non sono necessari.

  • Supporto alla collaborazione. In molte situazioni, l'analisi del computing viene sviluppata in collaborazione con persone diverse in più organizzazioni. Google Cloud fornisce strumenti di gestione dell'identità e dell'accesso a livello di progetto per consentire l'accesso controllato ai dati e a strumenti di analisi. Gli utenti autorizzati possono accedere alle stesse app, agli stessi dati e agli stessi cluster per garantire che tutti siano aggiornati, senza dover copiare dati, gestire versioni o sincronizzare configurazioni del cluster.

  • Risorse su misura. Poiché il costo di un job dipende solo dalle ore core totali, piuttosto che dalle istanze del numero, l'esecuzione dei cluster nel cloud consente a ciascun team o gruppo di avere il proprio cluster dedicato. Questo approccio può ridurre il principale problema di sviluppo dei criteri relativi all'utilizzo in più gruppi. Puoi quindi personalizzare ciascun cluster cloud dedicato per adattarlo all'app di destinazione. I cluster on-premise tendono a comprendere una risorsa che viene utilizzata per tutte le dimensioni e condivisa tra i vari gruppi e le app. In un ambiente di questo tipo, i criteri per la condivisione tra i gruppi tendono a essere complessi da configurare e gestire.

  • Integrazione. Prima di eseguire job di calcolo di grandi dimensioni, i ricercatori svolgono un lavoro significativo per preparare i set di dati. Dopo il passaggio al cloud, questi ricercatori possono utilizzare gli strumenti per i big data disponibili nel cloud. Anche gli output dei sistemi di computing devono essere analizzati. Strumenti come BigQuery e Datalab possono offrire vantaggi significativi rispetto a quelli disponibili nei sistemi on-premise.

I cluster locali on-premise sono condivisi tra utenti e gruppi e supportano molte esigenze diverse relative alle app.
Figura 2.I cluster locali on-premise sono condivisi tra utenti e gruppi e supportano molte esigenze relative alle app. Al contrario, quando passano a Google Cloud, gli utenti possono personalizzare le proprietà del cluster in base alle esigenze dell'app per ridurre i costi e aumentare le prestazioni.

Considerazioni architettoniche

I vantaggi descritti finora sono convincenti, ma ci sono comunque alcune sfide tecniche che spesso ostacolano i progetti di migrazione.

  • Spostamento dei dati. In genere, i set di dati elaborati dai nodi di calcolo di un cluster devono essere archiviati sul cloud prima di essere eseguiti. La gestione dello spostamento dei dati può essere complessa, a seconda del volume dei dati e di come vengono gestiti.

  • Accesso ai dati. Molte app HPC richiedono l'accesso condiviso a un insieme di file e directory. La modalità di accesso può influire notevolmente sulle prestazioni dell'app. Puoi utilizzare i dati condivisi archiviati in Cloud Storage, su server NFS come FileStore o utilizzando file system paralleli, come descritto nella sezione Archiviazione.

  • Sicurezza. Per i dati sensibili, devi assicurarti che l'accesso sia sempre autorizzato e che i dati siano criptati correttamente quando sono inattivi e in transito. Cloud Storage cripta i dati inattivi e in transito, ma puoi applicare un ulteriore livello di controllo e gestione delle chiavi in Cloud Key Management Service o in modo autonomo. Le chiavi devono essere recuperate o installate sui nodi di calcolo prima di eseguire il job.

  • Latenza tra nodi. Per le app HPC strettamente collegate, le prestazioni potrebbero essere sensibili alla latenza tra i nodi tra i cluster nel cluster. Poiché Google Cloud fornisce nodi con dimensioni fino a 64 core, puoi eseguire job paralleli a 64 vie senza attraversare i nodi. Nella maggior parte dei casi, i job con circa 1000 core o meno offrono prestazioni ragionevoli su hardware di rete non specializzato.

  • Gestione licenza software. Molte app commerciali richiedono un server delle licenze, a volte noto come server chiavi. Alcune app sono dotate di un server di licenze integrato o consigliato, mentre altre potrebbero essere compatibili con le offerte di server di licenze esistenti. Alcuni scheduler possono aiutarti a gestire le licenze e impedirne l'esecuzione fino a rendere disponibile una licenza.

L'informatica tecnica offre molti strumenti e approcci per circostanze diverse. Con così tante opzioni, potrebbe essere difficile iniziare. Indipendentemente dalla scelta del software di gestione dei cluster e dello scheduler, puoi eseguire una serie di best practice su Google Cloud.

  • Sfrutta le VM Spot ogni volta che è possibile. Le VM Spot sono come le normali VM su Compute Engine, ma hanno un prezzo fino all'80% inferiore rispetto alle VM normali, con la necessità di specificarle con un preavviso. Per i carichi di lavoro ad alta velocità effettiva, gli scheduler dei job rilevano la perdita del nodo e la considerano come un errore del nodo e ripianificano le attività in esecuzione su quel nodo su una risorsa diversa. Anche se qualsiasi lavoro svolto su quei nodi persi potrebbe andare perduto, la probabilità di perdita di nodi è sufficientemente bassa da valere la possibilità di un prezzo più basso. Il tasso di perdita previsto è compreso tra 5% e 15%. Le VM spot sono limitate a un massimo di 24 ore di utilizzo prima di essere recuperate.
  • Sfrutta i costi e la larghezza di banda di Cloud Storage anziché eseguire il tuo file system parallelo. Cloud Storage fornisce elevata coerenza e prestazioni parallele scalabili con un costo complessivo basso. Anche se la latenza del primo byte è di circa 100 ms, le app in grado di utilizzare Cloud Storage invece di eseguire un file server parallelo su Compute Engine sono più convenienti. La larghezza di banda disponibile tra Cloud Storage e i nodi di computing è sufficiente per molte app, alcuni clienti hanno segnalato una larghezza di banda aggregata prolungata di oltre 23 GB/s.
  • Crea un cluster per app singola o gruppo singolo. I cluster tradizionali sono condivisi tra più utenti, gruppi e app, il che può comportare tempi di attesa lunghi per i job e un utilizzo inefficiente delle risorse da parte delle app. Su Google Cloud, valuta la possibilità di creare più cluster per ogni gruppo o progetto e di utilizzare cluster ottimizzati per app che vengono eseguite su di essi. Sia che esegui un cluster per due ore o due cluster per un'ora ciascuno, il costo complessivo è lo stesso, ma il secondo pattern può ridurre i tempi di attesa di coda e migliorare le prestazioni dell'app.

Ogni implementazione è univoca, ma le seguenti sezioni forniscono alcuni consigli generali per tre casi comuni.

Ricercatore indipendente che vuole elaborare i propri dati

I singoli ricercatori cercano in genere di eseguire la loro app in tutti i loro dati e di raggiungere il completamento il più rapidamente possibile. Potrebbero essere esperti della loro app, ma non vogliono essere esperti in amministrazione o gestione dei cluster.

Se esegui carichi di lavoro ad alta velocità effettiva, puoi utilizzare l'API Cloud Life Sciences. L'API Pipelines richiede di inserire la tua app in un container Docker e di inserire i tuoi file di input in un bucket Cloud Storage. Successivamente, puoi utilizzare l'interfaccia a riga di comando di Google Cloud per lanciare l'app a fronte di tutti i file nel bucket di Cloud Storage. Puoi inserire i risultati in un altro bucket Cloud Storage.

Ecco un esempio di comando per eseguire un'attività che utilizza SAMtools per generare un file di indice BAM da un file BAM di input:

gcloud alpha genomics pipelines run --pipeline_id [PIPELINE_ID] \
--logging gs://[YOUR_BUCKET/YOUR_DIRECTORY]/logs \
--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \
--outputs outputFile=gs://[YOUR_BUCKET]/[YOUR_DIRECTORY]/output/NA12878_chr22.bam.bai

Dove

  • [PIPELINE_ID] rappresenta l'ID dell'app nell'API Pipelines.
  • [YOUR_BUCKET] rappresenta il nome del bucket Cloud Storage.
  • [YOUR_DIRECTORY] rappresenta il nome della directory.

Non è presente alcun cluster di cui eseguire il provisioning o la gestione. Le attività vengono semplicemente eseguite fino al completamento in una VM di cui è stato eseguito il provisioning e la gestione da parte dell'API Pipelines. Questo è efficiente in termini di costi perché Compute Engine fattura al secondo di utilizzo.

Cluster di piccole e medie dimensioni per un singolo progetto o team

In un progetto o in un team, i membri potrebbero avere accesso a un cluster gestito da un team centrale per gli utenti di tutta l'azienda o avere accesso a risorse su larga scala in un centro HPC esterno al sito. In entrambe le situazioni, i cluster vengono gestiti professionalmente e accessibili con strumenti standard. Ad esempio, gli utenti potrebbero utilizzare ssh per connettersi a un nodo head e utilizzare script Grid Engine submit per inviare job per l'esecuzione.

Uno degli approcci per tale team è utilizzare ElastiCluster per definire un ambiente cluster simile ai suoi sistemi on-premise. Possono personalizzare il cluster selezionando un tipo di macchina Compute Engine più adatto alla propria app e personalizzando gli script di avvio per installare le dipendenze software per l'app. I dati di input possono comunque essere archiviati in Cloud Storage e puoi installare gcsfuse sui nodi di computing per montare i dati di input.

Questi dettagli vengono registrati nel file di configurazione ElastiCluster. Quando è necessario il calcolo, viene visualizzato un cluster utilizzando lo strumento a riga di comando, ad esempio:

% elasticluster start astrocluster1

Viene eseguito il provisioning e la configurazione del cluster, denominato nel file di configurazione come astrocluster1, come specificato. Le definizioni in un file di configurazione sono flessibili e supportano diversi tipi di nodi per i nodi head e Compute, dischi permanenti di Compute Engine per lo spazio temporaneo, le Spot VM per ridurre il costo dei carichi di lavoro ad alta velocità effettiva e le GPU per un funzionamento accelerato. Un esempio di configurazione di base per un cluster basato su Slurm con 10 nodi di computing e 1 nodo head che utilizzano macchine virtuali a 32 core basate su CentOS avrebbe il seguente aspetto:

[cluster/astrocluster1]
 cloud=google
 login=google
 setup=ansible-slurm
 security_group=default
 image_id=centos-7-v20170327
 flavor=n1-standard-32
 frontend_nodes=1
 compute_nodes=10
 ssh_to=frontend
 boot_disk_size=50
 

Infine, quando nel sistema non sono in esecuzione più job, puoi arrestare il cluster:

% elasticluster stop astrocluster1

Per i carichi di lavoro più grandi, puoi:

  • Cerca di personalizzare i tipi di macchine del cluster per ridurre ulteriormente i costi.
  • Aggiungi un filer parallelo esterno per aumentare le prestazioni su larga scala.
  • Aggiungi funzionalità di scalabilità automatica per aggiungere e rimuovere nodi aggiuntivi in base alla profondità di coda.

Centro HPC che aggiunge capacità di burst ai cluster esistenti

I centri HPC centrali hanno un'enorme capacità di calcolo, ma poiché sono utilizzati da molti gruppi all'interno dell'azienda o dell'organizzazione, i centri HPC tendono ad avere un utilizzo costantemente elevato e tempi di attesa in coda lunghi. Sono generalmente acquistati con una particolare capacità di produzione e, quando vengono inviati carichi di lavoro imprevisti, possono rallentare notevolmente i progressi.

In queste situazioni, puoi eseguire il burst nell'ambiente Google Cloud aggiungendo temporaneamente nodi di computing al cluster. Il cluster diventa un modello ibrido, con il nodo head e alcuni nodi di computing in esecuzione on-premise, e altri nodi di computing in esecuzione su Google Cloud. Quando le code di job sono state svuotate, è possibile rilasciare nodi aggiuntivi.

Il passaggio al cloud è pratico per un paio di motivi:

  • Gestisce un ambiente utente coerente per l'invio e la gestione dei job. Gli utenti non sanno o si preoccupano dell'aggiunta di nodi aggiuntivi.
  • Consente ai responsabili IT di definire criteri per il burst al fine di controllare i costi.

La sfida maggiore è fornire uno spazio dei nomi di dati e file coerente per i job utente sui nodi on-premise e su Google Cloud. I nodi Google Cloud potrebbero non avere accesso agli stessi file system interni dei nodi on-premise. In questa situazione, i job che fanno riferimento a questi file non verranno eseguiti.

Se i nodi Google Cloud sono configurati con autorizzazioni di accesso ai file interne, i job verranno eseguiti, ma potrebbero non funzionare allo stesso modo e creare costi di larghezza di banda di rete e addebiti aggiuntivi per il traffico in uscita. Inoltre, i job paralleli suddivisi tra nodi on-premise e nodi cloud potrebbero non funzionare bene con la latenza aggiunta tra le diverse parti dell'app.

Per i job ad alta velocità effettiva, l'utilizzo di HTCondor per scavalcare le risorse cloud ha evitato molte di queste sfide. HTCondor supporta il provisioning dinamico tramite GlideInWMS. Quando i job vengono inviati in coda di job, possono attivare il provisioning dei nodi e l'aggiunta al cluster. Una volta aggiunti, lo scheduler condor trasferisce i file di input al nodo designato e utilizza tali nodi aggiuntivi per eseguire le attività e svuotare la coda.

Passaggi successivi

Scopri di più sui casi d'uso di cluster computing su Google Cloud:

Scopri di più su:

Per iniziare a utilizzare il cluster:

Progetti di esempio su GitHub: