Bruke klynger for storskala teknisk databehandling i skyen

denne løsningen gir veiledning for å utføre storskala teknisk databehandling på Google Cloud. Mange tekniske databehandlingsapper krever et stort antall individuelle databehandlingsnoder, koblet sammen i en klynge, og koordinerer beregning og datatilgang på tvers av nodene.

konseptene og teknologiene som ligger til grunn for cluster computing har utviklet seg de siste tiårene, og er nå modne og vanlige. Migrering av softwarestack Til Google Cloud kan legge til noen rynker, men tilbyr også en rekke muligheter til å redusere kostnadene og lindre eksisterende flaskehalser i dagens høytytende databehandlingsmiljøer. Denne veiledningen gir en oversikt overteknologier, utfordringene og dagens utvalg av løsninger for kjøringcomputational clusters På Google Cloud.

Cluster computing samler og koordinerer en samling av maskiner for å arbeide sammen for å løse en oppgave. Klynger har vanligvis en enkelt hodenode (noen ganger kalt en hovednode), et antall beregningsnoder og muligens noen få andre spesialitetsnoder. Hodet node er hjernen til systemet og er ansvarlig for:

• Registrere beregningsnoder i systemet.
• Overvåking av nodene.
• Tildele jobber til bestemte noder.

Brukere sender inn jobber, som består av mange oppgaver, der en oppgave er den grunnleggende arbeidsenheten. Noen apper krever at alle oppgaver i en jobb kjøres samtidig og lar oppgaver kommunisere for å implementere en parallell algoritme; noen jobber har et komplekst sett med aktivitetsavhengigheter slik at bestemte oppgaver må kjøres før andre; og noen oppgaver kan kreve spesielle nodekonfigurasjoner når det gjelder minne, Cpuer eller annen bestemt maskinvare som kan kjøres. Oppgaver er kjørbare som leser inndata fra lagring, behandler dataene for å produsere et resultat, og deretter skriver de endelige resultatene tilbake til lagring.

det finnes to hovedtyper av cluster computing-arbeidsbelastninger:

• high-performance computing (HPC) – en type databehandling som bruker manyworker noder, tett koblet, og utfører samtidig for å oppnå atask. Disse maskinene trenger vanligvis lav nettverksforsinkelse for å kommunisereeffektivt. Eksempler på apper i dette rommet inkluderer værmodellering, computational fluid dynamics (CFD), stressmodellering i ingeniørfag, ogelektronikkdesign.

• HIGH-throughput computing (HTC) – en type databehandling der appshar flere oppgaver som behandles uavhengig av hverandre utenet behov for de enkelte databehandlingsnoder å kommunisere. Noen ganger er disseworkloads kalles pinlig parallell eller batch arbeidsbelastninger. Typicalexamples inkluderer mediegjengivelse, transkoding, genomikk og partikkelfysikk-hendelsessimulering og prosessering. Hvis du trenger å behandle mange individuelle filer, er det sannsynligvis EN HTC arbeidsbelastning.

Cluster computing software stack

en cluster computing software stack består av:

• Systemadministrasjonsprogramvare som forsyner og bygger klynger.
• Planleggere som organiserer jobbutførelse.
• Sluttbrukerapper.

følgende avsnitt diskuterer systemadministrasjonsprogramvare og planleggere.

system management software

du kan kjøre clustering programvare enten direkte på bare metall maskinvare, aswith lokale klynger, eller i virtualiserte miljøer, som med cloudenvironments. Orkestrering av flere noder i en klynge for hånd er tidsbruk og utsatt for feil. Du kan bruke spesialisert klyngehåndteringsprogramvarefor å klargjøre og konfigurere flere noder og ressurser, sammen, på arepeatable og deterministic måte.

open sourceElastiCluster-programvaren fra University Of Zurich gir en sky-innfødt tilnærming til cluster management, med støtte for klargjøring av noder, ved å bruke compute Engine, og konfigurasjon av noder ved å bruke Et sett Med Ansibleplaybooks. ElastiCluster avsetninger nodene og installerer en base softwarestack, inkludert NFS for fil servering, nis brukerkontoadministrasjon, OG ajob scheduler for å utføre bruker apps. ElastiCluster støtter en rekke ofschedulers, og du kan bruke den ut av boksen eller tilpasse den for å møte behovene til små til mellomstore lag.

hvis du bruker andre konfigurasjonsbehandlingssystemer til å administrere hpc-klynger, For eksempel Chef, Puppet eller Terraform, kan du utnytte disse investeringene når du overfører Til Google Cloud ved å bruke de tilgjengelige verktøyene og programtilleggene.

Google Cloud tilbyr innebygde tjenester for klargjøring og distribusjon av programvaresystemer med flere noder. Cloud Deployment Manager lar deg klargjøre et sett med skyressurser, inkludert Compute Engine, Compute Enginemanaged instansgrupper og Skylagring. TheHTCondor tutorial viser deg hvordan du bruker Cloud Deployment Manager og administrerte instansgrupper toprovision og konfigurere en klynge.

Jobbplanleggere

etter at klyngen er i drift, kalles programvaren som administrerer oppgaveutførelsen og nodetildeling, en jobbplanlegger (noen ganger kalt en workloadmanager eller købehandling). Ofte kommer en klyngebehandling med en innebygd jobbplanlegger. Jobb planleggere gir en rekke funksjoner for å hjelpehåndtere jobber og oppgaver, for eksempel:

• Støtte for jobbprioriteringer på tvers av brukere og grupper, noe som bidrar til å gipolicy-basert jobbplanlegging.
• Støtte for mislykkede oppgaver ved kø og omlegging av oppgaver.
• Behandling av aktivitetsavhengigheter og ressursbehov for aktivitetstildeling.
• Skalere klyngestørrelsen avhengig av antall jobber i køen.

det finnes en rekke populære kommersielle og åpen kildekode arbeidsmengde ledere.Eksempler inkluderer htcondor Fra University Of Wisconsin,Slurm Fra SchedMD,Univa Grid Engine, Og LSF Symphony fra IBM. Hver har sine styrker.

HTCondor er bygget med en delt-ingenting filosofi og brukes over delte ressurser til opportunistisk planlegge jobber på ellers idleresources. Det gir sin egen data bevegelse og derfor krever ingen sharedfile systemer. Som et resultat Skalerer HTCondor til hundretusener av kjerner ogdu kan bruke den på tvers av flere soner og regioner. HTCondor har blitt brukt tilhybrid arbeidsbelastninger, hvor arbeidet deles eller deles mellom lokale og skybaserte systemer. Men som navnet antyder, er det fokusert påhøy gjennomstrømningsjobber, ikke tett koblet, parallelle jobber.

Slurm og Univa Grid Engine gir et mer tradisjonelt hpc-klyngemiljø, som støtter både høy gjennomstrømning og høy ytelse parallelle apper. De begge antar et delt filsystem over nodene, noe som eliminerer behovet for å flytte dataene. Begge gir et praktisk og kjent brukermiljø fordeveloping apps fordi de ofte er de samme verktøyene som brukes lokalt.Disse tradisjonelle jobb planleggere er tilstrekkelig for små til mellomstore klynger, men som klyngestørrelsen øker, belastningen på filserveren blir thebottleneck for ytelse. Parallelle og distribuerte filsystemer (se neste avsnitt) kanhjelp med dette problemet når det er i høy skala. Alternativt, der lav latens fileaccess ikke er nødvendig, kan du utnytte Sky Lagring, som girparallel objekt tilgang ved HJELP AV API eller throughgcsfuse, wherePOSIX kompatibilitet er nødvendig.

Endelig Inkluderer Google Cloud en enkel tjeneste for planlegging av aDocker – basert oppgave på Databehandlingsmotor for arbeidsbelastninger med høy gjennomstrømming: clouds Life SciencesPipelines API.Denne tjenesten krever at du dekomponerer jobben i aktiviteter, behandler avhengigheter på tvers av aktiviteter og administrerer aktivitetens livssyklus. Thedsub open source project gir et kommandolinjeverktøy for å starte batchjobber og støtter Cloud Life Sciences Pipelines API.

Lagring

de FLESTE hpc-programmer krever afile lagringsløsning som støtter POSIX API. For mindre klynger Gir FileStore En Google-administrert NFS-basert fillagringstjeneste. For større klynger kan imidlertid program I / O bli en flaskehals for ytelse.Skalere ut og parallelle filsystemer,for eksempelelastifile (kjøpt Av Google), Glans,orQuobyte, hjelper skalering til store klynger (eller til og med i/O-tunge mindre klynger).

Alternativt, der lav latens fileaccess ikke er nødvendig, kan du utnytte Sky Lagring, som girparallel objekt tilgang ved HJELP AV API eller throughgcsfuse, DER POSIX kompatibilitet er nødvendig.

Muligheter for cluster computing i skyen

det er mange grunner til å kjøre databehandlingsklynger i skyen:

• Tid-til-løsning. Lansering av en produksjonskvalitetsklynge i skyen tar bare noen få minutter, fra en liten 10-node-klynge med hundrevis av tilgjengelige kjerner, til store klynger med hundre tusen eller morecores. I motsetning til dette kan det ta måneder å bygge nye klynger lokalt. Selv når lokale klynger er tilgjengelige, har de vanligvis høy utnyttelse og lang ventetid i kø — noen ganger timer eller dager-før jobber er planlagt å kjøre. I stedet kan dubygg dine egne klynger i skyen, bruk dem til arbeidsbelastningene dine, og avslutt klyngene når analysen er fullført.

• Lavere totale eierkostnader. Google Cloud reduserer ikke bare timeto-løsningen, men kan også redusere den totale kostnaden per kjøring ved å utnytte mulige Virtuelle Maskiner, rabatter på langsiktig bruk og dynamisk skalering. Du kan legge til noder når jobsare kø og fjerne dem når det ikke trengs.

• Støtte til samarbeid. I mange situasjoner er beregningsanalysen utviklet i samarbeid med forskjellige personer på tvers av flereorganisasjoner. Google Cloud tilbyr verktøy for prosjektnivåidentitet og tilgangsadministrasjon for å tillate kontrollert tilgang til data-og analyseverktøy. Autoriserte brukere kan få tilgang til de samme appene, dataene og klyngene for å sikre at alle er på samme side uten å måtte kopiere data, administrere versjoner eller synccluster-konfigurasjoner.

• Oppgavetilpassede ressurser. Fordi kostnaden for en jobb bare avhenger av de totale kjernetimene, i stedet for antall forekomster, gjør det mulig for hvert team eller gruppe å ha sin egen dedikerte klynge å kjøre klynger i skyen. Denne tilnærmingen kan lindre et annet stort smertepunkt for å utvikle politikk rundt bruk av flere grupper. Du kan deretter tilpasse hver dedikert sky-klynge for å stille den inn for mål-appen. Lokale klynger har en tendens til å bestå av en ressurs som passer til alle, delt på tvers av de ulike gruppene og appene. I et slikt miljø har politikk for deling på tvers av gruppene en tendens til å være komplisert å sette opp og vedlikeholde.

• Integrasjon. Før de kan kjøre store databehandlingsjobber, doserer forskere betydelig arbeid for å forberede datasettene. Etter å ha flyttet til skyen, kan disse forskerne utnytte de store dataverktøyene som er tilgjengelige i skyen. Utgangene til beregningssystemene må også analyseres. Verktøy som bigquery og Datalab kan gi betydelige fordeler over de som er tilgjengelige i lokale systemer.

Arkitektoniske betraktninger

mens fordelene som er beskrevet så langt er overbevisende, er det neverthel nogle tekniske utfordringer som ofte hemmer migrasjonsprosjekter.

• data bevegelse. Datasettene som behandles av en klynge computenodes vanligvis må være trinnvis til skyen før du kjører jobbene.Styring av databevegelsen kan være komplisert, avhengig av volumet avdata og hvordan det styres. Verktøy som asAvere kan hjelpe ved å gi et sky-caching lag som automatisk flytter data når det trengs, men for mange apps datasettene må iscenesettes manuelt.

• Datatilgang. Mange hpc-apper krever delt tilgang til et sett avfiler og kataloger. Hvordan denne tilgangen er gitt kan påvirke betydeligapp ytelse. Du kan utnytte delte data lagret inCloud Storage, I nfs-servere som asFileStore, eller ved hjelp av parallelle filsystemer, som diskutert i theStorage-delen.

• Sikkerhet. For data som er sensitive, må du sørge for at tilgang alltid er autorisert og data er riktig kryptert ved restand i transitt. Mens Skylagring krypterer data i hvile og i transitt, kan du bruke et ekstra lag med kontroll og administrere nøkler, enten inklud Nøkkeladministrasjonstjeneste eller på egen hånd. Nøklene må hentes eller installeres på computenodes før du kjører jobben.

• inter-node latens. For tett koblet HPC apps, performancemight være følsom for inter-node latens mellom noder i klyngen.Fordi Google Cloud gir noder med størrelser på opptil 64 kjerner, kan du kjøre 64-veis parallelle jobber uten å krysse noder. I de fleste tilfeller fungerer jobber avaround 1000 kjerner eller mindre rimelig bra på ikke-spesialisert nettverksmaskinvare.

• Programvare lisens ledelse. Mange kommersielle apper krever alicense server, noen ganger kjent som en nøkkelserver. Noen apps comewith en innebygd eller anbefalt lisens server og andre kan være compatiblewith eksisterende lisens-server tilbud. Noen jobbplanleggere kan hjelpe medlisensbehandling og stoppe jobber fra å kjøre til en lisens er tilgjengelig.

Anbefalte arkitekturer og beste praksis

Teknisk databehandling gir mange verktøy og tilnærminger for forskjelligeomstendigheter. Med så mange alternativer, kan du finne det vanskelig å komme i gang.Uavhengig av valg av cluster management software og scheduler, er detetantall beste praksis du kan følge når du kjører På Google Cloud.

• Utnytte preemptible Vm-er når det er mulig. Preemptible VMs er akkurat somvanlige VMs På Compute Engine, men priset opp til 80% mindre ennvanlige VMs, med det forbeholdet at de kan gjenvinnes med lite varsel.For arbeidsbelastninger med høy gjennomstrømning oppdager jobbplanleggere tapet av noden og behandler det som en nodefeil og omplaner eventuelle oppgaver som kjører på den noden på en annen ressurs. Mens noe arbeid gjort pa de tapte nodermight ga tapt, er sannsynligheten for nodetap lav nok til at den nedre prisen er verdt sjansen. Forventet tapsrate er 5% til 15%. PreemptibleVMs er begrenset til maksimalt 24 timers bruk før de gjenvinnes.
• Utnytt kostnadene og båndbredden Til Skylagring i stedet for å kjøre ditt eget parallelle filsystem. Cloud Storage girsterk konsistens og skalerbar parallell ytelse med lav totalkostnad.Mens den første byte-latensen er høy på omtrent 100 ms, er apper som kan gjennomsnittlig Skylagring i stedet for å kjøre en parallell filserver onCompute-Motor, mer kostnadseffektive. Tilgjengelig bandwidthmellom Sky Lagring og beregne noder er tilstrekkelig for manyapps, noen kunder har rapportert vedvarende samlet båndbredde over 23 GB / s.
• Bygge en enkelt-app eller single-gruppe klynge. Tradisjonelle klynger deles på tvers av flere brukere, grupper og apper, noe som kan føre til lange køtider for jobber og ineffektiv ressursbruk av apper. OnGoogle Cloud, vurder å lage flere klynger for hver gruppe eller prosjekt, og bruk klynger som er optimalisert for bestemte apper som kjører dem. Enten du kjører en klynge i to timer, eller to klynger for en time hver, er den totale kostnaden den samme, men sistnevnte mønster kan redusere ventetider og forbedre appytelsen.

selv om hver implementering er unik, gir følgende avsnitt noen generelle anbefalinger for tre vanlige tilfeller.

Uavhengig forsker som ønsker å behandle sine data

Individuelle forskere vanligvis søker å kjøre sin app over sine data og få til ferdigstillelse så fort som mulig. De kan være eksperter i theirapp, men de ønsker ikke å være eksperter i cluster administrasjon ormanagement.

hvis du kjører arbeidsbelastninger med høy gjennomstrømming, kan du vurdere å bruke cloud Life SciencesPipelines API.Pipelines API krever at du legger appen din i En Docker-beholder og plasserer inndatafilene dine i En Skylagrings bøtte. Etter det isdone, kan du bruke kommandolinjeverktøyet gcloud for å starte appen mothver av filene i Skylagringsbøtten. Du kan plassereresultater i en Annen Skylagrings bøtte.

her er et eksempel på en kommando for å utføre en oppgave som brukersamtools til å generere EN bam-indeksfil fra en input BAM-fil:

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

Hvor

• representerer appens ID i Pipelines API.
• representerer Ditt Skylagrings bøtte navn.
• representerer navnet på katalogen din.

det er ingen klynge å klargjøre eller administrere. Oppgavene bare kjøre untilcompletion i EN VM som klargjøres OG administreres Av Pipelines API. Dette iscost effektiv fordi Beregne Motorregninger per sekund av bruk.

små og mellomstore klynger for et enkelt prosjekt eller en gruppe

i et prosjekt eller en gruppe kan medlemmene ha tilgang til en klynge som drives av acentral-teamet for brukere i hele firmaet, eller de kan ha tilgang til store ressurser på et EKSTERNT HPC-senter. I begge situasjoner er clusters profesjonelt administrert og tilgjengelig ved hjelp av standardverktøy. For eksempel kan brukere bruke ssh til å koble til en hodenode og bruke Grid Enginesubmit skript for å sende jobber for kjøring.

en tilnærming for et slikt lag er å bruke ElastiCluster til å definere et klyngemiljø som ligner på deres lokale systemer. De kan tilpasse cluster ved å velge En Compute Engine maskintype som passer best for deres app, og tilpasse oppstartsskriptene for å installere softwaredependencies for deres app. Input data kan fortsatt være iscenesatt til cloud Storage, og du kan installeregcsfuse på databehandlingsnodene for å montere input data.

disse detaljene registreres I ElastiCluster-konfigurasjonsfilen, og når computation er nødvendig, blir en klynge hentet opp ved hjelp av kommandolinjeverktøyet, foreksempel:

% elasticluster start astrocluster1

klyngen, navngitt i konfigurasjonsfilen som astrocluster1, klargjøres og konfigureres som angitt. Definisjonene i en konfigurasjonsfil er fleksible og støtter forskjellige nodetyper for hode-og beregningsnoder, Beregne Motorvedvarende disker for skrapeplass, preemptible Vm-er for å redusere kostnadene for arbeidsbelastninger med høy hastighet og Gpu-er for akselerert drift. Et eksempel på en basicconfiguration for En Slurm – basert klynge med 10 beregningsnoder og 1 hode nodeusing 32-core virtuelle maskiner basert På CentOS ville se ut som følger:

 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 

Til Slutt, når det ikke kjører flere jobber i systemet, kan du stoppe klyngen:

% elasticluster stop astrocluster1

for større arbeidsbelastninger kan du:

• Se for å tilpasse klyngemaskintypene for å redusere kostnadene ytterligere.
• Legg til en ekstern parallell filer for å øke ytelsen i skala.
• Legg automatisk skalering evner til å legge til og fjerne flere noder basert på thequeue dybde.

HPC center legge burst kapasitet til eksisterende klynger

Sentrale HPC-sentre har enorm kapasitet for databehandling, men fordi DE brukes av mange grupper på tvers av selskapet eller organisasjonen, HPC-sentre har en tendens til å ha konsekvent høy utnyttelse og lang kø ventetider. De er typisk kjøpt med en bestemt produksjonskapasitet i tankene, og når uforutsette arbeidsbelastninger sendes inn i blandingen, kan de redusere fremdriften betydelig.

I disse situasjonene kan Du briste Inn I Google Cloud-miljøet ved å legge til beregningsnoder midlertidig til klyngen. Klyngen blir en hybrid, med hodenoden og noen databehandlingsnoder som kjører lokalt, og andre datamaskinnoder som kjører På Google Cloud. Når jobbkøene er tømt, kan tilleggsnoder frigis.

Bursting til skyen er praktisk av et par grunner:

• det opprettholder en konsekvent brukermiljø for jobb innsending andmanagement. Brukere vet ikke eller bryr seg om flere noder er lagt til.
• it-ledere kan definere retningslinjer for når de skal sprekke, for å kontrollere kostnadene.

den største utfordringen er å gi et konsistent data-og filnavnerom for brukerjobber på tvers av lokale og Google Cloud-noder. TheGoogle Cloud-noder har kanskje ikke tilgang til de samme internalfile-systemene som de lokale nodene. I dette tilfellet jobber som referencethese filene vil ikke kjøre.

Hvis Google Cloud-nodene er konfigurert med interne filtilgangstillatelser, vil jobber kjøre, men kan ikke utføre på samme måte, og det kan skape ekstra nettverksbåndbredde og utgående kostnader. I tillegg kan parallelle jobber som er delt på tvers av lokale og skynoder, ikke fungere godt med den ekstra ventetiden mellom de ulike delene av appen.

for høy gjennomstrømmingsjobber, bruker HTCondor til å briste inn i skyressurser sidestepsmange av disse utfordringene. HTCondor støtter dynamisk provisioning usingGlideInWMS.Når jobber sendes inn i en jobbkø, kan de utløse noder beingprovisioned og legges til i klyngen. Når de legges til, condor scheduleroverfører input filer til den angitte noden og bruker de ekstra nodeso utføre oppgavene og tappe køen.

Les mer om bruk av cluster computing på Google Cloud:

• Google Cloud, HEPCloud og probing the nature of nature
• 220 000 kjerner og telling: mit math professor bryter rekord for largestever Compute Engine jobb

Les mer om:

• Filservere På Databehandlingsmotor
• Dokumentasjon For Cloud Deployment Manager

Kom i gang med klyngen:

• Batchbehandling Med Compute Engine Autoscaler
• Opprette En HTCondor-klynge ved Hjelp Av Cloud Deployment Manager-maler

Eksempelprosjekter på GitHub:

• dsub eksempel: Enkle batch jobber Med Docker
• ElastiCluster eksempel

• Pipelines API eksempler

• Prøv ut Andre Google Cloud-funksjoner for deg selv. Ta en titt på ourtutorials.