Brug af klynger til storskala teknisk databehandling i skyen

denne løsning giver vejledning til udførelse af storskala teknisk beregningpå Google Cloud. Mange tekniske computerapps kræverstore antal individuelle computernoder, der er forbundet sammen i en klynge og koordinerer beregning og dataadgang på tværs af knudepunkterne.

de begreber og teknologier, der ligger til grund for cluster computing, har udviklet sig i løbet af de sidste par årtier og er nu modne og mainstream. Migrering af programmelstakken til Google Cloud kan tilføje et par rynker, men tilbyder også en række muligheder for at reducere omkostningerne og lindre eksisterende flaskehalse i nutidens højtydende computermiljøer. Denne vejledning giver et overblik over teknologier, udfordringerne og den aktuelle afgrøde af løsninger til at køre computerklynger på Google Cloud.

Cluster computing aggregater og koordinerer en samling af maskiner til at arbejdesammen for at løse en opgave. Klynger har typisk en enkelt hovedknude (undertiden kaldet en masternode), et antal computernoder og muligtet par andre specialknudepunkter. Hovednoden er hjernen i systemet og eransvarlig for:

• registrering compute noder i systemet.
• overvågning af knuderne.
• tildeling af job til bestemte noder.

brugere indsender job, der er sammensat af mange opgaver, hvor en opgave ergrundlæggende arbejdsenhed. Nogle apps kræver, at alle opgaver i et job kører i øjeblikket og lader opgaver kommunikere for at implementere en parallel algoritme;nogle job har et komplekst sæt opgaveafhængigheder, således at bestemte opgaver skal køres før andre; og nogle opgaver kan kræve særlige nodekonfigurationer med hensyn til hukommelse, CPU ‘ er eller andet bestemt udstyr, som skal køres på. Opgaver er eksekverbare, der læser inputdata fra lager, behandler thedata for at producere et resultat og derefter skriver de endelige resultater tilbage til lager.

der er to hovedtyper af cluster computing arbejdsbyrder:

• High-performance computing (HPC) — en type computing, der bruger mangearbejdernoder, tæt koblet og udfører samtidigt for at udføre atask. Disse maskiner har typisk brug for lav netværksforsinkelse for at kommunikereeffektivt. Eksempler på apps i dette rum inkluderer vejrmodellering, Computational fluid dynamics (CFD), stressmodellering inden for teknik ogelektronik design.

• high-throughput computing (HTC) – en type computing, hvor appshar flere opgaver, der behandles uafhængigt af hinanden uden behov for de enkelte computernoder til at kommunikere. Nogle gange kaldes dissearbejdsbelastninger pinligt parallelle eller batcharbejdsbelastninger. Typiskeeksempler inkluderer mediegengivelse, omkodning, genomik ogpartikel-fysik-hændelsessimulering og-behandling. Hvis du har brug for at behandle en masse individuelle filer, er det sandsynligvis en HTC-arbejdsbyrde.

Cluster computing stack

en cluster computing stack består af:

• Systemstyringsprogram, der sørger for og bygger klynger.
• planlæggere, der orkestrerer jobudførelse.
• slutbruger apps.

de følgende afsnit diskuterer systemstyringsprogrammer og planlæggere.

systemstyringsprogram

du kan køre clustering-programmer enten direkte på det blotte metaludstyr, som med lokale klynger eller i virtualiserede miljøer, som med cloudenvironments. Orkestrering af flere noder i en klynge for hånd er tidsforbrugende og fejlbehæftet. Du kan bruge specialiserede cluster-management programmel til levering og konfigurere flere noder og ressourcer sammen på en gentagelig og deterministisk måde.

open sourceElastiCluster-programmet giver en cloud-native tilgang til clusterstyring med understøttelse af klargøringsnoder ved hjælp af computermotor og konfiguration af noder ved hjælp af et sæt Ansibleplaybooks. ElastiCluster sørger for noderne og installerer en base-programmel, herunder NFS til filvisning, NIS-brugerkontostyring og ajob scheduler til udførelse af brugerapps. ElastiCluster understøtter en række forskellige schedulers, og du kan bruge den ud af kassen eller tilpasse den til at imødekomme behovene hos små til mellemstore hold.

hvis du bruger andre konfigurationsstyringssystemer til at administrere dine HPC-klynger, såsom Chef, Puppet eller Terraform, kan du udnytte disse investeringer, når du migrerer til Google Cloud ved hjælp af de tilgængelige værktøjer og plugins.

Google Cloud leverer native tjenester til klargøring og implementering af multi-node-systemer. Cloud Deployment Manager kan du provisiona sæt af cloud-ressourcer, herunder Compute Enginemanaged instance grupper, og Cloud Storage. TheHTCondor tutorial viser dig, hvordan du bruger Cloud Deployment Manager og managed instance grupper tilprovision og konfigurere en klynge.

Jobplanlæggere

når klyngen er i drift, kaldes det program, der administrerer opgavens udførelseog nodetildeling, en jobplanlægger (undertiden kaldet en arbejdsloadmanager eller køadministrator). Ofte kommer en klyngechef med enindbygget jobplanlægger. Jobplanlæggere giver en række muligheder for at hjælpeledelse af job og opgaver, såsom:

• støtte til jobprioriteter på tværs af brugere og grupper, hvilket hjælper med at levere politikbaseret jobplanlægning.
• støtte til mislykkede opgaver ved at stå i kø og omlægge opgaver.
• overvejelse af opgaveafhængigheder og ressourcebehov for opgavetildeling.
• skalering af klyngestørrelsen afhængigt af antallet af job i køen.

der er en række populære kommercielle og open source arbejdsbyrde ledere.Som eksempel kan nævnes LSF Symphony fra IBM,Slurm fra SchedMD,Univa Grid Engine og LSF Symphony fra IBM. Hver har sine styrker.

HTCondor er bygget med en delt-intet filosofi og bruges på tværs af delte ressourcer til opportunistisk at planlægge job på ellers idleresources. Det giver sin egen data bevægelse og kræver derfor ingen sharedfile systemer. Som følge heraf skalerer HTCondor til hundredtusindvis af kerner ogDu kan bruge den på tværs af flere områder og regioner. HTCondor er blevet brugt til hybride arbejdsbelastninger, hvor arbejdet deles eller deles mellem lokale og cloudbaserede systemer. Men som navnet antyder, er det fokuseret påhøjt gennemløbsjob, ikke tæt koblede, parallelle job.

Slurm og Univa Grid Engine giver et mere traditionelt HPC-klyngemiljø,der understøtter både høj kapacitet og højtydende parallelle apps. De antager begge et delt filsystem på tværs af knudepunkterne, hvilket eliminerer behovet for at flytte dataene. Begge giver et praktisk og velkendt brugermiljø tiludvikling af apps, fordi de ofte er de samme værktøjer, der bruges lokalt.Disse traditionelle jobplanlæggere er tilstrækkelige til små til mellemstore klynger,men når klyngestørrelsen øges, bliver belastningen på filserveren thebottleneck for ydeevne. Parallelle og distribuerede filsystemer (se næste afsnit) kanhjælpe med dette problem, når det er i høj skala. Alternativt, hvor filadgang med lav latenstid ikke er påkrævet, kan du udnytte Cloud Storage, som giverparallel objektadgang ved hjælp af API eller throughgcsfuse,hvor der kræves kompatibilitetskompatibilitet.

endelig inkluderer Google Cloud en simpel service til planlægning af aDocker-baseret opgave på Compute Engine til arbejdsbelastninger med høj kapacitet: theCloud Life SciencesPipelines API.Denne Tjeneste kræver,at du opdeler jobbet i opgaver, administrerer afhængigheder på tværs af opgaver og administrerer opgavens livscyklus. Thedsub open source project giver et kommandolinjeværktøj til at starte batchjob ogunderstøtter cloud Life Sciences Pipelines API.

opbevaring

de fleste HPC-applikationer kræver enfilopbevaringsløsning, der understøtter API ‘ en. For mindre klynger leverer FileStore en Google-administreret NFS-baseret fillagringstjeneste. For større klynger kan applikation I / O imidlertid blive en præstationsflaskehals.Scale-out og parallelle filsystemer, sådanelastifile (erhvervet af Google),glans,orkobyte,hjælper skalering til store klynger (eller endda i/O-tunge mindre klynger).

alternativt, hvor filadgang med lav latenstid ikke er påkrævet, kan du udnytte skylagring, som giver parallel objektadgang ved hjælp af API eller throughgcsfuse,hvor der kræves Posis-Kompatibilitet.

muligheder for cluster computing i skyen

der er mange grunde til at køre compute clusters i skyen:

• Time-to-løsning. Lancering af en produktionskvalitetsklynge i skyentager kun et par minutter, fra en lille 10-node klynge med hundredvis aftilgængelige kerner, til store klynger med hundrede tusinde eller merekorer. I modsætning hertil kan det tage måneder at bygge nye klynger på stedet. Selv når lokale klynger er tilgængelige, de har typisk høj udnyttelse og lange kø ventetider —nogle gange timer eller dage — før job er planlagt til at køre. I stedet kan du opbygge dine egne klynger i skyen, bruge dem til dine arbejdsbelastninger og afslutte klyngerne, når din analyse er afsluttet.

• lavere samlede ejeromkostninger. Google Cloud reducerer ikke kun timeto-løsningen,men kan også reducere de samlede omkostninger pr.kørsel ved at udnytte forudsigelige VM ‘ er, rabatter på lang sigt og dynamisk skalering. Du kan tilføje noder, når Jober i kø og fjerne dem, når det ikke er nødvendigt.

• støtte til samarbejde. I mange situationer udvikles beregningsanalysen i samarbejde med forskellige mennesker på tværs af flere organisationer. Google Cloud leverer værktøjer til projektniveauidentitet og adgangsstyring for at give kontrolleret adgang til data og analytiske værktøjer. Autoriserede brugere kan få adgang til de samme apps, data og klynger for at sikre, at alle er på samme side uden at skulle kopiere data, administrere versioner eller synkronisere konfigurationer.

• opgave-skræddersyede ressourcer. Da omkostningerne ved et job kun afhænger af de samlede kernetimer i stedet for antallet af forekomster, giver kørsel af klynger i skyen hvert team eller gruppe mulighed for at have deres egen dedikerede klynge. Denne tilgang kan lindre et andet stort smertepunkt ved at udvikle politikker omkring brug af flere grupper. Du kan derefter tilpasse hver dedikeret skyklynge for at indstille den til målappen. Lokale klynger har tendens til at bestå af en ressource, der passer til alle, der deles på tværs af de forskellige grupper og apps. I et sådant miljø har politikker for deling på tværs af grupperne tendens til at være komplekse at oprette og vedligeholde.

• Integration. Før de kan køre store beregningsjob, gør forskernevæsentligt arbejde med at forberede datasættene. Efter at have flyttet til skyen, disseforskere kan udnytte de store dataværktøjer, der er tilgængelige i skyen. Detudgange af beregningssystemerne skal også analyseres. Værktøjer somforespørgsel og Datalab kan give betydelige fordele i forhold til dem, der findes i lokale systemer.

arkitektoniske overvejelser

mens de hidtil beskrevne fordele er overbevisende, er der ikke desto mindrenogle tekniske udfordringer, der ofte hæmmer migrationsprojekter.

• data bevægelse. Datasættene, der behandles af en klynges computernoder, skal typisk iscenesættes til skyen, inden de kører jobene.Håndtering af databevægelsen kan være kompleks, afhængigt af volumen afdata og hvordan det styres. Værktøjer som f.eksavere kan hjælpe ved at levere et cloud-caching-lag, der automatisk flytter data, når det er nødvendigt, men for mange apps skal datasætene iscenesættes manuelt.

• Adgang Til Data. Mange HPC apps kræver delt adgang til et sæt affiler og mapper. Hvordan denne adgang gives, kan i væsentlig grad påvirkeapp ydeevne. Du kan udnytte delte data, der er gemt ihøjlagring,i NFS-servere som f.eksfilestore, eller ved hjælp af parallelle filsystemer, som diskuteret i afsnittet Opbevaring.

• sikkerhed. For data, der er følsomme, skal du sørge for at sikre, atadgang altid er autoriseret, og data er korrekt krypteret ved restand i transit. Mens Cloud Storage krypterer data i hvile og i transit, kan du anvende et ekstra lag af kontrol og administrere nøgler enten inCloud Key Management Service eller alene. Tasterne skal hentes eller installeres på computenodes før du kører jobbet.

• inter-node latency. For tæt koblede HPC-apps, performancemight være følsom over for inter-node latency mellem noder i klyngen.Fordi Google Cloud giver noder med størrelser op til 64 kerner, kan duKør 64-vejs parallelle job uden at krydse noder. I de fleste tilfælde fungerer job på omkring 1000 kerner eller mindre rimeligt godt på ikke-specialiseretnetværksudstyr.

• licensstyring. Mange kommercielle apps kræver alicense server, undertiden kendt som en nøgleserver. Nogle apps kommer med en indbygget eller anbefalet licensserver, og andre kan være kompatible med eksisterende licensservertilbud. Nogle jobplanlæggere kan hjælpe medlicensstyring og stoppe job fra at køre, indtil en licens er tilgængelig.

anbefalede arkitekturer og bedste praksis

teknisk computing giver mange værktøjer og tilgange til forskelligeomstændigheder. Med så mange muligheder kan det være svært at komme i gang.Uanset valg af klyngestyringsprogram og planlægning er deren række bedste fremgangsmåder, du kan følge, når du kører på Google Cloud.

• gearing preemptible VM ‘ er når det er muligt. Preemptible VM ‘er er ligesomregulære VM’ er på Compute Engine, men prissat op til 80% mindre endregelmæssige VM ‘ er, med det forbehold, at de kan genvindes med lidt varsel.For arbejdsbelastninger med høj kapacitet registrerer dine jobplanlæggere tabet af noden og behandler det som en nodefejl og omlægger alle opgaver, der kører på den node på en anden ressource. Mens ethvert arbejde udført på de tabte knuderkunne gå tabt, sandsynligheden for knudetab er lav nok til, at den laveste pris er værd at chancen. Den forventede tabsprocent er 5% til 15%. PreemptibleVMs er begrænset til maksimalt 24 timers brug, før de genvindes.
• Udnyt omkostningerne og båndbredden ved skylagring i stedet for at køre dit eget parallelle filsystem. Cloud Storage giverstærk konsistens og skalerbar parallel ydeevne med lave samlede omkostninger.100 ms, er apps, der canleverage Cloud Storage i stedet for at køre en parallel filserver onCompute Engine, mere omkostningseffektive. Den tilgængelige båndbredde mellem skylagring og computernoder er tilstrækkelig til mange apps, nogle kunder har rapporteret vedvarende samlet båndbredde påover 23 GB/s.
• Byg en enkelt-app eller en-gruppe klynge. Traditionelle klynger deles på tværs af flere brugere, grupper og apps, hvilket kan resultere i lange køtider for job og ineffektiv ressourceforbrug af apps. OnGoogle Cloud, overvej at oprette flere klynger for hver gruppe eller projekt, og brug klynger, der er optimeret til bestemte apps, der kører på dem. Uanset om du kører en klynge i to timer eller to klynger for en time hver, er de samlede omkostninger de samme, men sidstnævnte mønster kan reducere kø-ventetider og forbedre appens ydeevne.

mens hver implementering er unik, giver de følgende afsnit nogle generelle anbefalinger til tre almindelige tilfælde.

uafhængig forsker, der ønsker at behandle deres data

individuelle forskere søger typisk at køre deres app på tværs af deres data og komme til færdiggørelse så hurtigt som muligt. De kan være eksperter i deresapp, men de ønsker ikke at være eksperter i klyngeadministration eller ledelse.

hvis du kører arbejdsbelastninger med høj kapacitet, kan du overveje at bruge THECLOUD Life SciencesPipelines API.Pipelines API kræver, at du sætter din app i en Docker-containerog placerer dine inputfiler i en Skyopbevaringsspand. Derefter kan du bruge kommandolinjeværktøjet gcloud til at starte appen modhver af filerne i Cloud Storage bucket. Du kan placere resultaterne i en anden Skyopbevaringsspand.

her er et eksempel på en kommando til at udføre en opgave, der brugersamtools til at 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

• repræsenterer din apps ID i pipelines API.
• repræsenterer dit Cloud Storage bucket navn.
• repræsenterer navnet på din mappe.

der er ingen klynge at levere eller styre. Opgaverne kører simpelthen indtilafslutning i en VM, der klargøres og administreres af Pipelines API. Dette er omkostningseffektivt, fordi beregne Motorregninger pr.

lille til mellemstor klynge for et enkelt projekt eller team

i et projekt eller et team kan medlemmerne have adgang til en klynge, der drives af acentral team for brugere i hele deres virksomhed, eller de kan have adgang til store ressourcer på et HPC – Center uden for stedet. I begge situationer styres og tilgås clusters professionelt ved hjælp af standardværktøjer. For eksempel kan brugere bruge ssh til at oprette forbindelse til en hovednode og bruge Grid Enginesubmit scripts til at indsende job til udførelse.

en tilgang for et sådant team er at bruge ElastiCluster til at definere et klyngemiljø, der ligner deres lokale systemer. De kan tilpasse thecluster ved at vælge en Compute Engine maskine type, der er bedst egnet til deres app, og tilpasse Start scripts til at installere programmel afhængigheder for deres app. Inputdata kan stadig iscenesættes tilcloud-lagring, og du kan installeregcsfuse på computernoderne for at montere inputdataene.

disse detaljer registreres i ElastiCluster-konfigurationsfilen, og når der er behov for beregning, bliver en klynge bragt op ved hjælp af kommandolinjeværktøjet, for eksempel:

% elasticluster start astrocluster1

klyngen, der er navngivet i konfigurationsfilen som astrocluster1, er klargjort og konfigureret som angivet. Definitionerne i en konfigurationsfil er fleksible og understøtter forskellige knudetyper til hoved-og computernoder,beregner Motorbestandige diske til ridseplads, præemptible VM ‘er for at sænke omkostningerne til highthroughput-arbejdsbelastninger og GPU’ er til accelereret drift. Et eksempel på en basicconfiguration for en Slurm – baseret klynge med 10 compute noder og 1 hoved nodeusing 32-core virtuelle maskiner baseret på CentOS ville se ud 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 

endelig, når der ikke kører flere job i systemet, kan du stoppe klyngen:

% elasticluster stop astrocluster1

for større arbejdsbyrder kan du:

• se for at tilpasse klyngemaskintyperne for yderligere at reducere omkostningerne.
• Tilføj en ekstern parallel filer for at øge ydeevnen i skala.
• Tilføj automatisk skaleringsfunktioner for at tilføje og fjerne yderligere noder baseret på køens dybde.

HPC center tilføjelse af burstkapacitet til eksisterende klynger

centrale HPC-Centre har en enorm kapacitet til beregning, men fordi de bruges af mange grupper på tværs af virksomheden eller organisationen, har HPC-Centre en tendens til at have konsekvent høj udnyttelse og lange kø ventetider. De er typisk købt med en bestemt produktionskapacitet i tankerne, og når uforudsete arbejdsbelastninger indsendes i blandingen, kan de bremse fremskridtene betydeligt.

i disse situationer kan du briste ind i Google Cloud-miljøet vedtilføjelse af computernoder midlertidigt til klyngen. Klyngen bliver en hybrid, hvor hovednoden og nogle computernoder kører lokalt, og andre computenodes kører på Google Cloud. Når jobkøerne er drænet, kanyderligere noder frigives.

Bursting til skyen er praktisk af et par grunde:

• det opretholder en konsekvent bruger miljø for job indsendelse ogledelse. Brugere ved ikke eller er ligeglade med, om der tilføjes yderligere noder.
• det giver IT-ledere mulighed for at definere politikker for, hvornår de skal briste, for at kontrollere omkostningerne.

den største udfordring er at give et ensartet data-og filnavneområde tilbrugerjob på tværs af lokale og Google Cloud-noder. TheGoogle Cloud-noder har muligvis ikke adgang til de samme interne filsystemer som de lokale noder. I denne situation, job, der referencerdisse filer vil undlade at køre.

Hvis Google Cloud-knudepunkterne er konfigureret med interne filadgangstilladelser, kører job, men fungerer muligvis ikke på samme måde ogmå oprette yderligere netværksbåndbredde og udgangsafgifter. Derudover kan parallelle job, der er opdelt på tværs af lokale og cloud-noder, heller ikke fungere godt med den ekstra latenstid mellem de forskellige dele af appen.

til high-throughput job, ved hjælp af HTCondor at briste i cloud ressourcer sidestepsmange af disse udfordringer. HTCondor understøtter dynamisk provisionering ved hjælp af glideinvms.Når job indsendes i en jobkø, kan de udløse noder, der er provisioned og tilføjet til klyngen. Når de tilføjes, overfører condor-planlæggeren inputfilerne til den udpegede node og bruger disse ekstra noderat udføre opgaverne og dræne køen.

Læs mere om cluster computing use cases på Google Cloud:

• Google Cloud, HEPCloud og sondering af naturens natur
• 220.000 kerner og tælling: mit math professor bryder rekord for largestever Compute Engine job

Læs mere om:

• filservere på Compute Engine
• cloud Deployment Manager dokumentation

kom i gang med din klynge:

• batchbehandling med Compute Engine Autoscaler
• oprettelse af en htcondor klynge ved hjælp af cloud Deployment Manager skabeloner

eksempel projekter på GitHub:

• dsub eksempel: Simple batch job med Docker
• ElastiCluster eksempel

• pipelines API eksempler

• prøv andre Google Cloud-funktioner til dig selv. Tag et kig på voresselvstudier.