Använda kluster för storskalig teknisk databehandling i molnet

den här lösningen ger vägledning för att utföra storskalig teknisk databehandling på Google Cloud. Många tekniska datorprogram kräverstort antal enskilda beräkningsnoder, kopplade ihop till ett kluster och koordinering av beräkning och dataåtkomst över noderna.

de begrepp och tekniker som ligger till grund för klusterberäkning har utvecklats under de senaste decennierna och är nu mogna och vanliga. Att migrera programvaranstack till Google Cloud kan lägga till några rynkor, men erbjuder också ett antalmöjligheter att minska kostnaderna och lindra befintliga flaskhalsar i dagens högpresterande datormiljöer. Den här guiden ger en översikt över tekniken, utmaningarna och den nuvarande grödan av lösningar för att köra datorkluster på Google Cloud.

Cluster computing aggregerar och samordnar en samling maskiner för att arbeta tillsammans för att lösa en uppgift. Kluster har vanligtvis en enda huvudnod (ibland kallad en huvudnod), ett antal beräkningsnoder och möjligtnågra andra specialnoder. Huvudnoden är hjärnan i systemet och äransvarig för:

• registrera beräkningsnoder i systemet.
• övervakning av noderna.
• allokera jobb till särskilda noder.

användare skickar in jobb, som består av många uppgifter, där en uppgift ärgrundläggande arbetsenhet. Vissa appar kräver att alla uppgifter i ett jobb körs för närvarande och låter uppgifter kommunicera för att implementera en parallell algoritm;vissa jobb har en komplex uppsättning aktivitetsberoenden så att vissa uppgifter måste köras före andra; och vissa uppgifter kan kräva särskilda nodekonfigurationer när det gäller minne, processorer eller annan speciell hårdvara som ska köras. Uppgifter är körbara filer som läser indata från lagring, bearbetar data för att producera ett resultat och sedan skriver de slutliga resultaten tillbaka till lagring.

det finns två huvudtyper av arbetsbelastningar för klusterberäkning:

• High-performance computing (HPC) — en typ av databehandling som använder manyworker noder, tätt kopplade och exekverar samtidigt för att utföra atask. Dessa maskiner behöver vanligtvis låg nätverksfördröjning för att kommuniceraeffektivt. Exempel på appar i detta utrymme inkluderar vädermodellering, beräkningsvätskedynamik (CFD), stressmodellering inom teknik ochelektronikdesign.

• high — throughput computing (HTC) – en typ av datoranvändning där appshave flera uppgifter som behandlas oberoende av varandra withouta behov för de enskilda compute noder för att kommunicera. Ibland kallas dessaarbetsbelastningar pinsamt parallella eller batcharbetsbelastningar. Typicalexempel inkluderar media rendering, omkodning, genomik, andparticle-fysik-händelse simulering och bearbetning. Om du behöver bearbeta många enskilda filer är det förmodligen en HTC-arbetsbelastning.

Cluster computing software stack

en cluster computing software stack består av:

• Systemhanteringsprogramvara som tillhandahåller och bygger kluster.
• schemaläggare som orkestrerar jobbkörning.
• slutanvändarprogram.

följande avsnitt diskuterar systemhanteringsprogram och schemaläggare.

Systemhanteringsprogramvara

du kan köra klusterprogramvara antingen direkt på hårdvaran, med lokala kluster eller i virtualiserade miljöer, som med cloudenvironments. Orkestrera flera noder i ett kluster för hand är timeconsuming och felbenägen. Du kan använda specialiserad programvara för klusterhantering för att tillhandahålla och konfigurera flera noder och resurser, tillsammans, på ett peatabelt och deterministiskt sätt.

den öppna sourceElastiCluster programvara från University of Zurich ger en cloud-native strategi tocluster management, med stöd för provisioning noder, genom usingCompute Engine, och konfiguration av noder med hjälp av en uppsättning Ansibleplaybooks. ElastiCluster bestämmelser noderna och installerar en bas softwarestack, inklusive NFS för filservering, NIS användarkontohantering, och aJob scheduler för att utföra användar apps. ElastiCluster stöder en mängd olika scheman, och du kan använda den ur lådan eller anpassa den för att möta behoven hos små till medelstora lag.

om du använder andra konfigurationshanteringssystem för att hantera dina HPC-kluster, till exempel Chef, Puppet eller Terraform, kan du utnyttja dessa investeringar när du migrerar till Google Cloud med hjälp av tillgängliga verktygoch plugins.

Google Cloud tillhandahåller inbyggda tjänster för provisioning och deployingmulti-node mjukvarusystem. Cloud Deployment Manager kan du provisiona uppsättning molnresurser inklusive Compute Engine, Compute Enginemanaged instansgrupper och molnlagring. Den htcondor handledning visar hur du använder Cloud Deployment Manager och hanterade instansgrupper toprovision och konfigurera ett kluster.

Job schedulers

när klustret är i drift kallas programvaran som hanterar uppgiften executionand node allocation en job scheduler (kallas ibland en workloadmanager eller queue manager). Ofta kommer en klusterhanterare med eninbyggd jobbschemaläggare. Jobbschemaläggare ger en mängd olika funktioner för att hjälpa tillhantera jobb och uppgifter, till exempel:

• stöd för jobbprioriteringar mellan användare och grupper, vilket hjälper till att tillhandahålla policybaserad jobbschemaläggning.
• stöd för misslyckade uppgifter genom att köa och omplanera uppgifter.
• hänsyn till aktivitetsberoenden och resursbehov för aktivitetsallokering.
• skala klusterstorleken beroende på antalet jobb i kön.

det finns en mängd populära kommersiella och Open source arbetsbelastning Chefer.Exempel ärhtcondor från University of Wisconsin,Slurm från SchedMD,Univa Grid Engine och LSF Symphony från IBM. Var och en har sina styrkor.

HTCondor är byggd med en delad-ingenting filosofi och usedacross delade resurser för att opportunistiskt schemalägga jobb på annars idleresources. Det ger sin egen datarörelse och kräver därför inga sharedfile-system. Som ett resultat skalar HTCondor till hundratusentals kärnor ochdu kan använda den över flera zoner och regioner. HTCondor har använts förhybrid arbetsbelastningar, där arbetet delas eller delas mellan lokala ochcloud-baserade system. Men som namnet antyder är det inriktat påhög genomströmningsjobb, inte tätt kopplade, parallella jobb.

Slurm och Univa Grid Engine ger en mer traditionell HPC-klustermiljö, som stöder både hög genomströmning och högpresterande parallella appar. Debåde antar ett delat filsystem över noderna, vilket eliminerar behovet avflytta data. Båda ger en bekväm och bekant användarmiljö för att utveckla appar eftersom de ofta är samma verktyg som används lokalt.Dessa traditionella jobbschemaläggare är tillräckliga för små till medelstora kluster,men när klusterstorleken ökar blir belastningen på filservern thebottleneck för prestanda. Parallella och distribuerade filsystem (se nästa avsnitt) kanhjälp med detta problem när det är i hög skala. Alternativt, där filåtkomst med låg latens inte krävs, kan du utnyttja molnlagring, vilket gerparallell objektåtkomst genom att använda API eller genomgcsfuse,därposix-kompatibilitet krävs.

slutligen innehåller Google Cloud en enkel tjänst för schemaläggning av adockerbaserad uppgift på Compute Engine för arbetsbelastningar med hög kapacitet: theCloud Life SciencesPipelines API.Den här tjänsten kräver att du delar upp jobbet i aktiviteter,hanterar beroenden mellan aktiviteter och hanterar aktivitetens livscykel. Thedsub open source-projektet ger ett kommandoradsverktyg för att starta batch jobb andsupports molnet Life Sciences Pipelines API.

Lagring

de flesta HPC-applikationer kräver enfillagringslösning som stöder POSIX API. För mindre kluster tillhandahåller FileStore en Google-hanterad NFS-baserad fillagringstjänst. För större kluster kan dock applikation I / O bli en prestandaflaskhals.Skala ut och parallella filsystem, till exempelelastifile (förvärvad av Google),Luster,orQuobyte,hjälper till att skala till stora kluster (eller till och med I/O-tunga mindre kluster).

alternativt, där filåtkomst med låg latens inte krävs, kan du utnyttja molnlagring, vilket gerparallell objektåtkomst genom att använda API eller throughgcsfuse,där POSIX-kompatibilitet krävs.

möjligheter för klusterberäkning i molnet

det finns många anledningar att köra beräkna kluster i molnet:

• Time-To-lösning. Att starta ett produktionskvalitetskluster i molnettar bara några minuter, från ett litet 10-nodskluster med hundratals tillgängliga kärnor, till storskaliga kluster med hundra tusen eller merbutiker. Däremot kan det ta månader att bygga nya kluster på plats. Även när lokala kluster är tillgängliga har de vanligtvis högt utnyttjande och långa kötider —ibland timmar eller dagar — innan jobb är planerade att köras. Istället kan du bygga dina egna kluster i molnet, använda dem för dina arbetsbelastningar och avsluta klusterna när din analys är klar.

• lägre total ägandekostnad. Google Cloud minskar inte bara timeto-lösningen,men kan också minska den totala kostnaden per körning genom att utnyttja preemptible VMs, långsiktiga användningsrabatter och dynamisk skalning. Du kan lägga till noder när jobsare queued och ta bort dem när det inte behövs.

• stöd för samarbete. I många situationer är beräkningsanalysenutvecklad i samarbete med olika människor över flera organisationer. Google Cloud tillhandahåller verktyg för projektnivåidentitet och åtkomsthantering för att tillåta kontrollerad åtkomst till data och analysverktyg. Auktoriserade användare kan få tillgång till samma appar, data och kluster för att säkerställa att alla är på samma sida utan att behöva kopiera data, Hantera versioner eller synccluster-konfigurationer.

• Task-skräddarsydda resurser. Eftersom kostnaden för ett jobb bara beror på de totala kärntimmarna, snarare än antalet instanser, kör kluster i molnet tillåter varje lag eller grupp att ha sitt eget dedikerade kluster. Detta tillvägagångssätt kan lindra en annan viktig smärtpunkt för att utveckla politik kring användning av flera grupper. Du kan sedan anpassa varje dedikerat molnkluster för att ställa in det för målappen. Lokala kluster tenderar att bestå av en resurs som passar alla i en storlek som delas över de olika grupperna och apparna. I en sådan miljö tenderar policyer för delning mellan grupperna att vara komplexa att ställa in och underhålla.

• Integration. Innan de kan köra stora beräkningsjobb gör forskare betydande arbete för att förbereda datamängderna. Efter att ha flyttat till molnet kan dessa forskare utnyttja de stora dataverktygen som finns tillgängliga i molnet. Utgångarna för beräkningssystemen måste också analyseras. Verktyg sombigquery och Datalab kan ge betydande fördelaröver de som finns i lokala system.

arkitektoniska överväganden

medan de fördelar som hittills beskrivits är övertygande, finns det ändåvissa tekniska utmaningar som ofta hindrar migrationsprojekt.

• data rörelse. Datamängderna som behandlas av ett klusters datanoder måste vanligtvis iscensättas i molnet innan jobben körs.Hantering av datarörelsen kan vara komplex, beroende på volymen avdata och hur den hanteras. Verktyg somavere kan hjälpa till genom att tillhandahålla ett molncachningslager som automatiskt flyttar data när det behövs, men för många appar måste datauppsättningarna iscensättas manuellt.

• Tillgång Till Data. Många HPC-appar kräver delad åtkomst till en uppsättningfiler och kataloger. Hur denna åtkomst tillhandahålls kan påverka appens prestanda avsevärt. Du kan utnyttja delad data lagrad inCloud-lagring, i NFS-servrar somfilestore, eller använda parallella filsystem, som diskuteras i avsnittet lagring.

• säkerhet. För data som är känsliga måste du se till atttillgången alltid är auktoriserad och data krypteras på lämpligt sätt i vilooch i transit. Medan molnlagring krypterar data i vila och i transit, kan du tillämpa ett extra lager av kontroll och hantera nycklar antingen inCloud Key Management Service eller på egen hand. Nycklarna måste hämtas eller installeras på computenodes innan du kör jobbet.

• inter-nod latens. För tätt kopplade HPC-appar kan prestanda vara känslig för Inter-nod-latensen mellan noder i klustret.Eftersom Google Cloud tillhandahåller noder med storlekar upp till 64 kärnor kan dukör 64-vägs parallella jobb utan att korsa noder. I de flesta fall fungerar jobb avrunt 1000 kärnor eller mindre ganska bra på icke-specialiseradnätverkshårdvara.

• hantering av Programvarulicens. Många kommersiella appar kräver alicense server, ibland känd som en nyckelserver. Vissa appar kommer med en inbyggd eller rekommenderad licensserver och andra kan vara kompatibla med befintliga licensservererbjudanden. Vissa jobbschemaläggare kan hjälpa till medlicenshantering och stoppa jobb från att köra tills en licens är tillgänglig.

rekommenderade arkitekturer och bästa praxis

teknisk databehandling ger många verktyg och metoder för olikaomständigheter. Med så många alternativ kan det vara svårt att komma igång.Oavsett valet av klusterhanteringsprogramvara och schemaläggare finns detett antal bästa metoder du kan följa när du kör på Google Cloud.

• utnyttja preemptible VMs när det är möjligt. Preemptible VMs är precis somregelbundna VMs på Compute Engine, men prissatta upp till 80% mindre än vanliga VMs, med förbehållet att de kan återvinnas med lite varsel.För arbetsbelastningar med hög genomströmning upptäcker dina jobbschemaläggare förlusten av noden och behandlar den som ett nodfel och omplanerar alla uppgifter som körs på den noden på en annan resurs. Medan något arbete som utförts på de förlorade noderna kan gå vilse, är sannolikheten för nodförlust tillräckligt låg för att det lägre priset är värt chansen. Den förväntade förlustgraden är 5% till 15%. PreemptibleVMs är begränsade till högst 24 timmars användning innan de återvinns.
• utnyttja kostnaden och bandbredden för molnlagring istället för att köra ditt eget parallella filsystem. Molnlagring ger stark konsistens och skalbar parallell prestanda med låg total kostnad.Medan den första byte-latensen är hög vid ungefär 100 ms, är appar som kangenomsnittlig molnlagring istället för att köra en parallell filserver pådatormotor mer kostnadseffektiva. Den tillgängliga bandbreddenmellan molnlagring och beräkningsnoderna är tillräcklig för manyapps, vissa kunder har rapporterat ihållande aggregerad bandbredd på över 23 GB/s.
• Bygg en enda app eller en gruppkluster. Traditionella kluster delas över flera användare, grupper och appar, vilket kan resultera i långa kötider för jobb och ineffektiv resursanvändning av appar. OnGoogle Cloud, överväg att skapa flera kluster för varje grupp eller projekt och använda kluster som är optimerade för vissa appar som körs på dem. Oavsett om du kör ett kluster i två timmar, eller två kluster för en timme vardera, är den totala kostnaden densamma, men det senare mönstret kan minskakö-väntetider och förbättra appens prestanda.

medan varje implementering är unik, ger följande avsnitt några allmänna rekommendationer för tre vanliga fall.

oberoende forskare som vill bearbeta sina data

enskilda forskare försöker vanligtvis köra sin app över sina data och komma till färdigställande så fort som möjligt. De kan vara experter i theirapp, men de vill inte vara experter på klusteradministration eller förvaltning.

om du kör arbetsbelastningar med hög genomströmning kan du överväga att använda cloud Life SciencesPipelines API.Pipelines API kräver att du lägger din app i en Docker-containeroch placera dina inmatningsfiler i en molnlagringshink. Efter det isdone kan du använda kommandoradsverktyget gcloud för att starta appen igenvar och en av filerna i molnlagringshinken. Du kan placera resultaten i en annan molnlagringshink.

här är ett exempel på ett kommando för att utföra en uppgift som usesSAMtools för att generera en Bam indexfil från en indata 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

där

• representerar appens ID i Pipelines API.
• representerar ditt molnlagringsskopnamn.
• representerar namnet på din katalog.

det finns inget kluster att tillhandahålla eller hantera. Uppgifterna körs helt enkelt tillslutförandet i en VM som tillhandahålls och hanteras av Pipelines API. Detta är kostnadseffektivt eftersom beräkna Motorräkningar per sekund av användningen.

små till medelstora kluster för ett enda projekt eller team

i ett projekt eller team kan medlemmarna ha tillgång till ett kluster som drivs av acentral team för användare i hela företaget, eller kan ha tillgång till stora resurser på ett HPC-center utanför anläggningen. I båda situationerna hanteras clusters professionellt och nås med standardverktyg. Till exempel kan användare använda ssh för att ansluta till en huvudnod och använda Grid Enginesubmit skript för att skicka jobb för körning.

ett tillvägagångssätt för ett sådant team är att använda ElastiCluster för att definiera en clusterenvironment som liknar deras lokala system. De kan anpassa thecluster genom att välja en Compute Engine maskintyp som är bäst suitedfor deras app, och anpassa startskript för att installera softwaredependencies för deras app. Indata kan fortfarande iscensättas tillmolnlagring, och du kan installeragcsfuse på beräkningsnoderna för att montera indata.

dessa detaljer registreras i ElastiCluster konfigurationsfilen, och whencomputation behövs, Ett kluster tas upp med hjälp av kommandoradsverktyget, forexample:

% elasticluster start astrocluster1

klustret, som i konfigurationsfilen heter astrocluster1, tillhandahålls och konfigureras som angivet. Definitionerna i en konfigurationsfil areflexible och stödja olika nodtyper för huvud och beräkna noder, beräkna Enginepersistent diskar för scratch utrymme, preemptible VM för att sänka kostnaden för highthroughput arbetsbelastningar, och GPU för accelererad Drift. Ett exempel på en basicconfiguration för ett Slurm-baserat kluster med 10 beräkningsnoder och 1 huvudnode med 32-kärniga virtuella maskiner baserade på CentOS skulle se ut som följer:

 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 

slutligen, när inga fler jobb körs i systemet, kan du stoppa klustret:

% elasticluster stop astrocluster1

för större arbetsbelastningar kan du:

• se till att anpassa klustermaskintyperna för att ytterligare minska kostnaderna.
• Lägg till en extern parallell fil för att öka prestanda i skala.
• Lägg till automatisk skalningsfunktioner för att lägga till och ta bort ytterligare noder baserat på ködjupet.

HPC center lägga burst kapacitet till befintliga kluster

centrala HPC centers har enorm kapacitet för beräkna, men eftersom de används av många grupper i hela företaget eller organisationen, HPC centers tenderar att haveconsistent hög utnyttjande och lång kö väntetider. De köps typiskt med en viss produktionskapacitet i åtanke, och när oförutsedda arbetsbelastningar skickas in i mixen kan de sakta ner framstegen avsevärt.

i dessa situationer kan du spränga in i Google Cloud-miljön genom att lägga till beräkningsnoder tillfälligt i klustret. Klustret blir en hybrid, med huvudnoden och vissa beräkningsnoder som körs lokalt och andra datanoder som körs på Google Cloud. När jobbköerna har tömts, ytterligare noder kan släppas.

sprängning till molnet är bekvämt av ett par anledningar:

• den upprätthåller en konsekvent användarmiljö för jobb inlämning andmanagement. Användare vet inte eller bryr sig om ytterligare noder läggs till.
• det gör det möjligt för IT-chefer att definiera policyer för när de ska brista, för attkontrollkostnader.

den största utmaningen är att tillhandahålla en konsekvent data-och filnamnrymd föranvändarjobb över lokala och Google Cloud-noder. TheGoogle Cloud-noder kanske inte har tillgång till samma interna filsystem som de lokala noderna. I den här situationen, jobb som refererardessa filer kommer inte att köras.

Om Google Cloud-noderna är konfigurerade med interna filåtkomsttillstånd, kommer jobb att köras, men kanske inte fungerar på samma sätt och kan skapa ytterligare nätverksbandbredd och utgångsavgifter. Dessutom kan parallella jobb som är uppdelade över lokala och molnnoder inte heller fungera bra med den extra latensen mellan de olika delarna av appen.

för hög genomströmning jobb, med hjälp av HTCondor att brista i molnresurser kringgå många av dessa utmaningar. HTCondor stöder dynamisk provisioning medglideinwms.När jobb skickas in i en jobbkö kan de utlösa noder som visas och läggs till i klustret. När de läggs till överför condor Scheduler indatafilerna till den angivna noden och använder de ytterligare noderna för att utföra uppgifterna och tömma kön.

Läs mer om klusterberäkningsanvändningsfall på Google Cloud:

• Google Cloud, HEPCloud, och sondera naturens natur
• 220,000 kärnor och räkna: MIT math professor bryter rekord för largestever Compute Engine jobb

Läs mer om:

• filservrar på Compute Engine
• cloud Deployment Manager dokumentation

Kom igång med ditt kluster:

• Batch-bearbetning med Compute Engine Autoscaler
• skapa ett htcondor-kluster med hjälp av cloud Deployment Manager-mallar

exempelprojekt på GitHub:

• dsub exempel: enkla batch jobb med Docker
• ElastiCluster exempel

• Pipelines API exempel

• testa andra Google Cloud-funktioner själv. Ta en titt på ourtutorials.