Utilizzo di cluster per il calcolo tecnico su larga scala nel cloud

Questa soluzione fornisce indicazioni per l’esecuzione di calcoli tecnici su larga scalasu Google Cloud. Molte app di calcolo tecnico richiedonograndi numeri di singoli nodi di calcolo, collegati tra loro in un cluster e che coordinano il calcolo e l’accesso ai dati attraverso i nodi.

I concetti e le tecnologie alla base del cluster computing si sono sviluppati negli ultimi decenni e sono ora maturi e mainstream. La migrazione del softwarestack a Google Cloud può aggiungere alcune rughe, ma offre anche una serie di opportunità per ridurre i costi e alleviare i colli di bottiglia esistenti negli ambienti di calcolo ad alte prestazioni di oggi. Questa guida fornisce una panoramica di thetechnologies, le sfide, e l’attuale raccolto di soluzioni per l’esecuzione di cluster computazionali su Google Cloud.

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

• Registrazione dei nodi di calcolo nel sistema.
• Monitoraggio dei nodi.
• Assegnazione di lavori a nodi particolari.

Gli utenti inviano lavori, che sono composti da molte attività, in cui un’attività è l’unità di lavoro di base. Alcune applicazioni richiedono tutte le attività in un processo per runconcurrently e lasciare che i compiti di comunicare per implementare un algoritmo in parallelo;alcuni lavori sono un insieme complesso di attività di dipendenze, che particolare tasksmust essere eseguito prima di altri; e alcune attività potrebbe richiedere particolare nodeconfigurations in termini di memoria, Cpu, o per altre particolari hardware whichto eseguire. Le attività sono eseguibili che leggono i dati di input dall’archiviazione, elaborano i dati per produrre un risultato e quindi scrivono i risultati finali nell’archiviazione.

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

• High-performance Computing (HPC) – Un tipo di calcolo che utilizza nodi manyworker, strettamente accoppiati, ed eseguendo contemporaneamente per realizzare atask. Queste macchine in genere necessitano di una bassa latenza di rete per comunicare in modo efficace. Le app di esempio in questo spazio includono la modellazione meteorologica, la fluidodinamica computazionale (CFD), la modellazione dello stress in ingegneria e la progettazione elettronica.

• High-throughput computing (HTC) – Un tipo di calcolo in cui appshave più attività che vengono elaborati indipendentemente l’uno dall’altro withouta bisogno per i singoli nodi di calcolo per comunicare. A volte questi carichi di lavoro sono chiamati imbarazzanti carichi di lavoro paralleli o batch. Typicalexamples includono media rendering, transcodifica, genomica, andparticle-physics-event simulation and processing. Se è necessario elaborare un sacco di singoli file, è probabilmente un carico di lavoro HTC.

Stack software di calcolo cluster

Uno stack software di calcolo cluster è composto da:

• Software di gestione del sistema che fornisce e costruisce cluster.
• Scheduler che orchestrano l’esecuzione del lavoro.
• App per utenti finali.

Le sezioni seguenti trattano il software di gestione del sistema e gli scheduler.

Software di gestione del sistema

È possibile eseguire il software di clustering direttamente sull’hardware bare-metal, comecon cluster locali, o in ambienti virtualizzati, come con cloudenvironments. Orchestrare più nodi in un cluster a mano è timeconsuming e soggetto a errori. È possibile utilizzare software di gestione cluster specializzati per il provisioning e la configurazione di più nodi e risorse, insieme, in modo comprensibile e deterministico.

Il software open sourceElastiCluster dell’Università di Zurigo fornisce un approccio nativo al cloud per la gestione dei cluster, con supporto per il provisioning dei nodi, utilizzando il motore di calcolo e la configurazione dei nodi utilizzando un set di Ansibleplaybooks. ElastiCluster esegue il provisioning dei nodi e installa un softwarestack di base, incluso NFS per la pubblicazione di file, NIS user account management e ajob scheduler per l’esecuzione di app utente. ElastiCluster supporta una varietà ofschedulers, e si può utilizzare fuori dalla scatola o personalizzarlo per soddisfare le needsof piccole e medie squadre.

Se si utilizzano altri sistemi di gestione della configurazione per gestire i cluster HPC, come Chef, Puppet o Terraform, è possibile sfruttare tali investimenti durante la migrazione a Google Cloud utilizzando gli strumenti e i plugin disponibili.

Google Cloud fornisce servizi nativi per il provisioning e la distribuzione di sistemi software multi-nodo. Cloud Deployment Manager consente di fornire un set di risorse cloud, tra cui Compute Engine, Compute Enginemanaged Instance groups e Cloud Storage. Il tutorial Htcondor mostra come utilizzare Cloud Deployment Manager e gruppi di istanze gestite per fornire e configurare un cluster.

Job schedulers

Dopo che il cluster è operativo, il software che gestisce l’esecuzione delle attività e l’allocazione dei nodi viene chiamato job scheduler (a volte chiamato workloadmanager o queue manager). Spesso, un gestore di cluster viene fornito con un pianificatore di lavori integrato. Gli scheduler dei lavori forniscono una varietà di funzionalità per aiutaregestire lavori e attività, ad esempio:

• Supporto per le priorità di lavoro tra utenti e gruppi, che aiuta la pianificazione del lavoro basata su providepolicy.
• Supporto per attività non riuscite mediante accodamento e riprogrammazione delle attività.
• Considerazione delle dipendenze delle attività e delle necessità di risorse per l’allocazione delle attività.
• Ridimensionamento delle dimensioni del cluster in base al numero di lavori nella coda.

Ci sono una varietà di gestori di carico di lavoro commerciali e open source popolari.Gli esempi includono HTCONDOR dell’Università del Wisconsin, Slurm di SchedMD,Univa Grid Engine e LSF Symphony di IBM. Ognuno ha i suoi punti di forza.

HTCondor è costruito con una filosofia shared-nothing e viene utilizzato attraverso risorse condivise per pianificare opportunisticamente i lavori su altrimenti idleresources. Esso fornisce il proprio movimento dei dati e, pertanto, non richiede sistemi sharedfile. Di conseguenza, HTCondor scala a centinaia di migliaia di core e puoi usarlo su più zone e regioni. HTCondor è stato utilizzato per carichi di lavoro ibridi, in cui il lavoro è condiviso o diviso tra sistemi on-premise e basati su cloud. Tuttavia, come suggerisce il nome, si concentra su lavori ad alta produttività, non strettamente accoppiati, lavori paralleli.

Slurm e Univa Grid Engine forniscono un ambiente cluster HPC più tradizionale, supportando app parallele ad alto throughput e ad alte prestazioni. Essi presuppongono un file system condiviso tra i nodi, che elimina la necessità di spostare i dati. Entrambi forniscono un ambiente utente conveniente e familiare per lo sviluppo di app perché spesso sono gli stessi strumenti utilizzati in locale.Questi scheduler di lavoro tradizionali sono sufficienti per cluster di piccole e medie dimensioni, ma all’aumentare della dimensione del cluster, il carico sul file server diventa thebottleneck per le prestazioni. I file system paralleli e distribuiti (vedere la sezione successiva) possonoaiutare con questo problema quando su larga scala. In alternativa, dove non è richiesto fileaccess a bassa latenza, è possibile sfruttare l’archiviazione cloud, che fornisce l’accesso a oggetti parallel utilizzando l’API o throughgcsfuse,dove è richiesta la compatibilità con Osix.

Infine, Google Cloud include un semplice servizio per la pianificazione di attività basate su aDocker su Compute Engine per carichi di lavoro ad alto throughput: l’API CLOUD Life SciencesPipelines.Questo servizio richiede di scomporre il lavoro in attività, gestire le dipendenze tra le attività e gestire il ciclo di vita dell’attività. Thedsub progetto open source fornisce uno strumento da riga di comando per avviare lavori batch andsupports il Cloud Life Sciences Pipelines API.

Storage

La maggior parte delle applicazioni HPC richiede una soluzione di storage afile che supporti l’API POSIX. Per i cluster più piccoli,FileStore fornisce un servizio di archiviazione file basato su NFS gestito da Google. Per cluster più grandi, tuttavia, l’I/O dell’applicazione può diventare un collo di bottiglia delle prestazioni.I file system scale-out e paralleli,come Elastifile (acquisito da Google), Lustre,orQuobyte, aiutano a scalare cluster di grandi dimensioni (o anche I/O-cluster più piccoli).

In alternativa, dove non è richiesto fileaccess a bassa latenza, è possibile sfruttare l’archiviazione cloud, che fornisce l’accesso a oggetti parallel utilizzando l’API o throughgcsfuse,dove è richiesta la compatibilità POSIX.

Opportunità per il cluster computing nel cloud

Ci sono molte ragioni per eseguire cluster di calcolo nel cloud:

• Tempo per la soluzione. Il lancio di un cluster di qualità produttiva nel cloud richiede solo pochi minuti, da un piccolo cluster a 10 nodi con centinaia di core disponibili, a cluster su larga scala con centomila o più core. Al contrario, la costruzione di nuovi cluster on-premise può richiedere mesi per esserepronto per il funzionamento. Anche quando i cluster locali sono disponibili, in genere hanno un utilizzo elevato e lunghi tempi di attesa della coda, a volte ore o giorni, prima che i lavori vengano pianificati per l’esecuzione. Invece, è possibile costruire i propri cluster nel cloud, utilizzarli per i carichi di lavoro e terminare i cluster quando l’analisi è completa.

• Riduzione del costo totale di proprietà. Google Cloud non solo riduce la soluzione timeto, ma può anche ridurre il costo totale per esecuzione sfruttando VM preemptible,sconti sull’uso a lungo termine e scalabilità dinamica. È possibile aggiungere nodi quando i lavorisono in coda e rimuoverli quando non necessari.

• Supporto per la collaborazione. In molte situazioni, l’analisi di calcolo è sviluppata in collaborazione con persone diverse in più organizzazioni. Google Cloud fornisce strumenti di gestione dell’identità e degli accessi a livello di progetto per consentire l’accesso controllato a dati e strumenti analitici. Gli utenti autorizzati possono accedere alle stesse app, dati e cluster per garantire che tutti siano sulla stessa pagina senza dover copiare dati, gestire versioni o configurazioni di sincronizzazione.

• Risorse su misura per le attività. Poiché il costo di un lavoro dipende solo dalle ore core totali, piuttosto che dalle istanze numeriche, l’esecuzione di cluster nel cloud consente a ciascun team o gruppo di disporre di un proprio cluster dedicato. Questo approccio può alleviare un altro importante punto dolente dello sviluppo di politiche intorno all’uso multi-gruppo. È quindi possibile personalizzare ogni cluster cloud dedicato per sintonizzarlo per l’app di destinazione. I cluster locali tendono a comprendere una risorsa unica condivisa tra i vari gruppi e app. In tale contesto, le politiche di condivisione tra i gruppi tendono ad essere complesse da impostare e mantenere.

• Integrazione. Prima di poter eseguire lavori di elaborazione di grandi dimensioni, i ricercatori lavorano in modo significativo per preparare i set di dati. Dopo essersi trasferiti nel cloud, questi ricercatori possono sfruttare gli strumenti di Big data disponibili nel cloud. Anche le uscite dei sistemi di calcolo devono essere analizzate. Strumenti come BigQuery e Datalab possono fornire vantaggi significativi rispetto a quelli disponibili nei sistemi on-premise.

Considerazioni architettoniche

Mentre i vantaggi descritti finora sono convincenti, ci sono tuttavia alcune sfide tecniche che spesso ostacolano i progetti di migrazione.

• Movimento dei dati. I set di dati elaborati dai computenodes di un cluster in genere devono essere posizionati nel cloud prima di eseguire i processi.Gestire il movimento dei dati può essere complesso, a seconda del volume dei dati e di come viene gestito. Strumenti come asAvere possono aiutare fornendo un livello di cache cloud che sposta automaticamente i dati quando necessario, ma per molte app i set di dati devono essere messi in scena manualmente.

• Accesso ai dati. Molte applicazioni HPC richiedono l’accesso condiviso a un set difile e directory. Il modo in cui viene fornito questo accesso può influire in modo significativole prestazioni dell’app. È possibile sfruttare i dati condivisi memorizzati nell’archiviazione ad alta voce, nei server NFS come Filestore o utilizzando file system paralleli, come discusso nella sezione Storage.

• Sicurezza. Per i dati sensibili, è necessario assicurarsi che l’accesso sia sempre autorizzato e che i dati siano crittografati in modo appropriato a riposo e in transito. Mentre Cloud Storage crittografa i dati a riposo e in transito, youcan applicare un ulteriore livello di controllo e gestire le chiavi sia inCloud Servizio di gestione delle chiavi,o da soli. Le chiavi devono essere recuperate o installate nei computenodes prima di eseguire il lavoro.

• Latenza tra nodi. Per le app HPC strettamente accoppiate, performancemight è sensibile alla latenza tra nodi tra nodi nel cluster.Poiché Google Cloud fornisce nodi con dimensioni fino a 64 core, è possibile eseguire lavori paralleli a 64 vie senza attraversare nodi. Nella maggior parte dei casi, i lavori di circa 1000 core o più piccoli eseguono ragionevolmente bene su hardware di rete non specializzato.

• Gestione delle licenze software. Molte applicazioni commerciali richiedono alicense server, a volte noto come un server chiave. Alcune app sono dotate di un server di licenza integrato o consigliato e altre potrebbero essere compatibili con le offerte di server di licenza esistenti. Alcuni pianificatori di lavoro possono aiutare con la gestione delle licenze e impedire l’esecuzione dei lavori fino a quando non è disponibile una licenza.

Architetture consigliate e best practice

Il calcolo tecnico fornisce molti strumenti e approcci per diverse circostanze. Con così tante opzioni, si potrebbe trovare difficile per iniziare.Indipendentemente dalla scelta del software di gestione cluster e scheduler, c’è un numero di best practice che puoi seguire quando esegui su Google Cloud.

• Sfrutta le VM preemptible quando possibile. Le VM Preemptible sono proprio come le VM regolari su Compute Engine, ma con un prezzo fino all ‘ 80% inferiore alle VM regolari, con l’avvertenza che possono essere recuperate con poco preavviso.Per carichi di lavoro ad alto throughput, gli scheduler di lavoro rilevano la perdita del nodo e lo trattano come un errore del nodo e riprogrammano qualsiasi attività in esecuzione su quel nodo su una risorsa diversa. Mentre tutto il lavoro fatto su quelli nodesmight perso è perso, la probabilità di perdita di nodo è abbastanza bassa che il lowerprice vale la probabilità. Il tasso di perdita atteso è compreso tra il 5% e il 15%. PreemptibleVMs sono limitati ad un massimo di 24 ore di utilizzo prima di essere recuperato.
• Sfrutta il costo e la larghezza di banda dello storage cloud invece di eseguire il tuo file system parallelo. Cloud Storage providesstrong coerenza e scalabile prestazioni parallele con basso costo complessivo.Mentre la latenza del primo byte è elevata a circa 100 ms, le app che possono utilizzare l’archiviazione cloud invece di eseguire un motore di calcolo di file server parallelo sono più convenienti. La larghezza di banda disponibile tra lo storage cloud e i nodi di calcolo è sufficiente per molte app, alcuni clienti hanno segnalato una larghezza di banda aggregata sostenuta di oltre 23 GB / s.
• Crea un cluster a singola app o a singolo gruppo. I cluster tradizionali sono condivisi tra più utenti, gruppi e app, il che può comportare lunghi tempi di attesa per i lavori e un utilizzo inefficiente delle risorse da parte delle app. OnGoogle Cloud, considerare la creazione di più cluster per ogni gruppo orproject, e l’utilizzo di cluster che sono ottimizzati per particolari applicazioni che runon loro. Se si esegue un cluster per due ore o due cluster per un ora ciascuno, il costo complessivo è lo stesso, ma quest’ultimo modello può ridurre i tempi di attesa e migliorare le prestazioni dell’app.

Mentre ogni implementazione è unica, le sezioni seguenti forniscono alcune raccomandazioni generali per tre casi comuni.

Ricercatore indipendente che cerca di elaborare i propri dati

I singoli ricercatori in genere cercano di eseguire la loro app attraverso i loro dati e arrivare al completamento il più velocemente possibile. Potrebbero essere esperti in theirapp, ma non vogliono essere esperti nell’amministrazione del cluster o nella gestione.

Se si eseguono carichi di lavoro ad alto throughput, è possibile considerare l’utilizzo dell’API CLOUD Life SciencesPipelines.L’API Pipelines richiede di inserire la tua app in un contenitore Docker e posizionare i file di input in un bucket di archiviazione cloud. Dopo di che isdone, è possibile utilizzare lo strumento da riga di comando gcloud per avviare l’app againsteach dei file nel bucket di archiviazione cloud. È possibile inserire theresults in un altro secchio di Cloud Storage.

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

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

Dove

• rappresenta l’ID della tua app nell’API Pipelines.
• rappresenta il nome del bucket di archiviazione cloud.
• rappresenta il nome della directory.

Non esiste un cluster da eseguire il provisioning o la gestione. Le attività vengono semplicemente eseguite fino al completamento in una VM che viene fornita e gestita dall’API Pipelines. Questo costo è efficiente perché calcola le fatture del motore al secondo di utilizzo.

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

In un progetto o team, i membri potrebbero avere accesso a un cluster gestito da acentral team per gli utenti in tutta la loro azienda, o potrebbero avere accesso a risorse di grande scala in un centro HPC off – site. In entrambe le situazioni, theclusters sono gestiti professionalmente e accessibili utilizzando strumenti standard. Ad esempio, gli utenti potrebbero utilizzare ssh per connettersi a un nodo head e utilizzare gli script Grid Enginesubmit per inviare i lavori per l’esecuzione.

Un approccio per tale team consiste nell’utilizzare ElastiCluster per definire un clusterenvironment simile ai loro sistemi locali. Essi possono personalizzare thecluster selezionando un tipo di macchina Compute Engine che è meglio suitedfor loro app, e personalizzare gli script di avvio per installare il softwaredependencies per la loro app. I dati di input possono ancora essere messi in scena nell’archiviazione CLOUD ed è possibile installaregcsfuse sui nodi di calcolo per montare i dati di input.

Questi dettagli sono registrati nel file di configurazione ElastiCluster e, quando è necessaria la computazione, viene visualizzato un cluster utilizzando lo strumento da riga di comando, ad esempio:

% elasticluster start astrocluster1

Il cluster, denominato nel file di configurazione come astrocluster1, viene fornito e configurato come specificato. Le definizioni in un file di configurazione sono flessibili e supportano diversi tipi di nodi per nodi head e compute, dischi Compute Enginepersistent per spazio zero, VM preemptible per ridurre i costi per carichi di lavoro highthroughput e GPU per operazioni accelerate. Un esempio di configurazione di base per un cluster basato su Slurm con 10 nodi di calcolo e 1 nodo principale utilizzando macchine virtuali a 32 core basate su CentOS sarebbe il seguente:

 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 non sono più in esecuzione lavori nel sistema, è possibile interrompere il cluster:

% elasticluster stop astrocluster1

Per carichi di lavoro più grandi, è possibile:

• Cercare di personalizzare i tipi di macchine cluster per ridurre ulteriormente i costi.
• Aggiungere un filer parallelo esterno per aumentare le prestazioni su larga scala.
• Aggiungi funzionalità di ridimensionamento automatico per aggiungere e rimuovere nodi aggiuntivi in base alla profondità della query.

HPC center aggiunta di capacità di burst ai cluster esistenti

I centri HPC centrali hanno una straordinaria capacità di calcolo, ma poiché sono utilizzati da molti gruppi in tutta l’azienda o l’organizzazione, i centri HPC tendono ad avere un utilizzo elevato e lunghi tempi di attesa della coda. Essi sono typicallypurchased con una particolare capacità di produzione in mente, e quando imprevedibile carichi di lavoro sono presentati nel mix, essi possono rallentare il progresso in modo significativo.

In queste situazioni, è possibile entrare nell’ambiente Google Cloud aggiungendo temporaneamente i nodi di calcolo al cluster. Il cluster diventa un ibrido, con il nodo principale e alcuni nodi di calcolo in esecuzione on-premise e altri computenodes in esecuzione su Google Cloud. Quando le code di lavoro sono state scaricate, i nodi aggiuntivi possono essere rilasciati.

Scoppiare nel cloud è conveniente per un paio di motivi:

• Mantiene un ambiente utente coerente per l’invio e la gestione dei lavori. Gli utenti non sanno o si preoccupano se vengono aggiunti nodi aggiuntivi.
• Consente ai responsabili IT di definire le politiche per quando scoppiare, al fine di controllare i costi.

La sfida più grande è fornire uno spazio dei nomi di dati e file coerente per i lavori utente attraverso i nodi on-premise e Google Cloud. I nodi Cloud di Google potrebbero non avere accesso agli stessi sistemi di file interni dei nodi locali. In questa situazione, i lavori che fanno riferimentoquesti file non verranno eseguiti.

Se i nodi di Google Cloud sono configurati con accesspermissions di file interni, i lavori verranno eseguiti, ma potrebbero non funzionare allo stesso modo e potrebbero creare ulteriori costi di larghezza di banda di rete e di uscita. Inoltre, i lavori paralleli suddivisi tra nodi on-premise e cloud potrebbero anche non funzionare bene con la latenza aggiunta tra le diverse parti dell’app.

Per i lavori ad alto throughput, utilizzando HTCondor per scoppiare in risorse cloud eludere molte di queste sfide. HTCondor supporta il provisioning dinamico usingGlideInWMS.Quando i lavori vengono inviati nella coda di un lavoro, possono attivare i nodi che vengono sottoposti a verifica e aggiunti al cluster. Quando vengono aggiunti, condor schedulertrasferisce i file di input al nodo designato e utilizza quei nodi aggiuntiviper eseguire le attività e svuotare la coda.

Maggiori informazioni sui casi d’uso del cluster computing su Google Cloud:

• Google Cloud, HEPCloud, e sondare la natura della natura
• 220.000 core e conteggio: professore di matematica del MIT rompe record per largestever Lavoro motore di calcolo

Per saperne di più:

• File server su Compute Engine
• Cloud Deployment Manager documentazione

iniziare con il cluster:

• l’elaborazione in Batch con Compute Engine Autoscaler
• Creazione di un HTCondor cluster utilizzando il Cloud Deployment Manager template

esempi di progetti su GitHub:

• dsub esempio: Semplici processi batch con Mobile
• ElastiCluster esempio

• Condotte API esempi

• Provare Google Cloud caratteristiche per te. Dai un’occhiata ai nostri articoli.