Het gebruik van clusters voor grootschalige technische computing in de cloud

deze oplossing biedt richtlijnen voor het uitvoeren van grootschalige technische computingop Google Cloud. Veel technische computing-apps vereisen grote aantallen individuele rekenknooppunten,met elkaar verbonden in een cluster, en het coördineren van berekening en toegang tot gegevens over de knooppunten.

de concepten en technologieën die ten grondslag liggen aan clustercomputing hebben zich de afgelopen decennia ontwikkeld en zijn nu volwassen en mainstream. Het migreren van de software naar Google Cloud kan een paar rimpels toevoegen, maar biedt ook een aantal mogelijkheden om de kosten te verlagen en bestaande knelpunten in de huidige high-performance computing-omgevingen te verlichten. Deze gids geeft een overzicht van de technologieën, de uitdagingen en de huidige oogst van oplossingen voor het uitvoeren van computerclusters op Google Cloud.

Clustercomputing aggregeert en coördineert een verzameling machines om samen te werken om een taak op te lossen. Clusters hebben meestal een enkele head node(soms een master node genoemd), een aantal berekenen knooppunten, en mogelijk enkele andere speciale knooppunten. De kopknoop is de hersenen van het systeem en is verantwoordelijk voor:

• het registreren van compute nodes in het systeem.
• controle van de knooppunten.
• toewijzing van taken aan bepaalde knooppunten.

gebruikers dienen taken in, die uit vele taken bestaan, waarbij een taak de basiseenheid van het werk is. Sommige apps vereisen dat alle taken in een taak gelijktijdig worden uitgevoerd en taken laten communiceren om een parallel algoritme te implementeren;sommige taken hebben een complexe set van taakafhankelijkheden, zodat bepaalde taken voorafgaand aan anderen moeten worden uitgevoerd; en sommige taken kunnen specifieke geenconfiguraties vereisen in termen van geheugen, CPU ‘ s of andere specifieke hardware waarop moet worden uitgevoerd. Taken zijn uitvoerbare bestanden die invoergegevens uit opslag lezen, de gegevens verwerken om een resultaat te produceren en vervolgens de eindresultaten terugschrijven naar opslag.

er zijn twee hoofdtypen cluster computing workloads:

• High-performance computing (HPC) – een type computing dat veelworker nodes gebruikt, strak gekoppeld, en tegelijkertijd uitvoeren om atask te bereiken. Deze machines hebben meestal een lage netwerk latency nodig om effectief te kunnen communiceren. Voorbeelden van apps in deze ruimte zijn weermodellering,computationele vloeistofdynamica (CFD), stressmodellering in engineering en elektronica-ontwerp.

• High-throughput computing (HTC) — Een soort computing waarbij apps meerdere taken hebben die onafhankelijk van elkaar worden verwerkt zonder dat de individuele rekenknooppunten moeten communiceren. Soms worden deze workloads beschamend parallel of batch workloads genoemd. Typischeexamples omvatten Media rendering, transcoding, genomica, andparticle-physics-event simulation and processing. Als je nodig hebt om veel individuele bestanden te verwerken, het is waarschijnlijk een HTC workload.

Cluster computing software stack

een cluster computing software stack bestaat uit:

• System-management software die voorziet in en bouwt clusters.
• Schedulers die taakuitvoering orkestreren.
• apps voor eindgebruikers.

in de volgende paragrafen wordt ingegaan op software voor systeembeheer en planners.

Systeembeheersoftware

u kunt clustering-software direct op de bare-metal hardware uitvoeren, zoals met on-premise clusters, of in gevirtualiseerde omgevingen, zoals met cloudenmilieu ‘ s. Het met de hand orkestreren van meerdere knooppunten in een cluster is tijdbesparend en foutgevoelig. U kunt gespecialiseerde software voor Clusterbeheer gebruiken om meerdere knooppunten en bronnen samen te configureren, op een opneembare en deterministische manier.

de open sourceElastiCluster-software van de Universiteit van Zürich biedt een cloud-native aanpak voor het beheer van clusters, met ondersteuning voor provisioning nodes, door gebruik te maken van computer Engine, en configuratie van nodes door gebruik te maken van een set van Ansibleplaybooks. ElastiCluster voorziet in de knooppunten en installeert een basissoftwarepakket, inclusief NFS voor het serveren van bestanden, NIS-Gebruikersaccountbeheer en een jobplanner voor het uitvoeren van gebruikersapps. ElastiCluster ondersteunt een verscheidenheid aan schedulers, en u kunt het uit de doos gebruiken of aanpassen aan de behoeften van kleine tot middelgrote teams.

Als u andere configuratiebeheersystemen gebruikt om uw HPC-clusters te beheren, zoals Chef, Puppet of Terraform, kunt u deze investeringen gebruiken tijdens de migratie naar Google Cloud met behulp van de beschikbare tools en plugins.

Google Cloud biedt native services voor het provisioneren en implementeren van multi-node softwaresystemen. Cloud Deployment Manager kunt u provisiona set van cloud resources, waaronder Compute Engine, Compute Enginemanaged instance groepen, en Cloud Storage. De tutorial htcondor laat u zien hoe u groepen voor Cloudimplementatiebeheer en beheerde instanties kunt gebruiken om een cluster te verstrekken en te configureren.

Taakplanners

nadat het cluster operationeel is, wordt de software die de taakuitvoerings-en knooppunttoewijzing beheert, een taakplanner genoemd (soms workloadmanager of wachtrijmanager genoemd). Vaak wordt een Clustermanager geleverd met een ingebouwde Taakplanner. Job schedulers bieden een verscheidenheid aan mogelijkheden om taken en taken te beheren, zoals:

• ondersteuning voor taakprioriteiten tussen gebruikers en groepen, waardoor beleidsgebaseerde taakplanning wordt geboden.
• ondersteuning voor mislukte taken door taken in de wachtrij te plaatsen en te herschikken.
• rekening houden met taakafhankelijkheden en resourcebehoeften voor taaktoewijzing.
• schalen van de clustergrootte afhankelijk van het aantal taken in de wachtrij.

er zijn verschillende populaire commerciële en open source workload managers.Voorbeelden hiervan zijn dehtcondor van de Universiteit van Wisconsin, Slurm van SchedMD, Univa Grid Engine en LSF Symphony van IBM. Elk heeft zijn sterke punten.

HTCondor is gebouwd met een shared-nothing-filosofie en wordt over gedeelde bronnen gebruikt om taken opportunistisch te plannen op anders niet-gebruikte bronnen. Het biedt zijn eigen gegevensbeweging en vereist daarom geen sharedfile-systemen. Als gevolg daarvan, HTCondor schaalt naar honderdduizenden kernen en u kunt het gebruiken in meerdere zones en regio ‘ s. HTCondor is gebruikt voor hybridworkloads, waarbij het werk wordt gedeeld of verdeeld tussen on-premises encloud-gebaseerde systemen. Zoals de naam al aangeeft, is het echter gericht op banen met een hoge productie, niet nauw gekoppelde, parallelle banen.

Slurm en Univa Grid Engine bieden een meer traditionele HPC-clusteromgeving en ondersteunen zowel high-throughput als high-performance Parallelle apps. Ze gaan uit van een gedeeld bestandssysteem over de knooppunten, wat de noodzaak om de gegevens te verwijderen elimineert. Beide bieden een handige en vertrouwde gebruikersomgeving voor hetontwikkelen van apps, omdat ze vaak dezelfde tools zijn die op locatie worden gebruikt.Deze traditionele taakplanners zijn voldoende voor kleine tot middelgrote clusters,maar naarmate de clustergrootte toeneemt, wordt de belasting op de bestandsserver de bottleneck voor prestaties. Parallelle en gedistribueerde bestandssystemen (zie volgende paragraaf) kunnen helpen met dit probleem wanneer op grote schaal. Als alternatief, waar low-latency bestandentoegang niet vereist is, kunt u gebruikmaken van cloudopslag,die parallelle objecttoegang biedt met behulp van de API of via gcsfuse, waar POSIX Compatibiliteit vereist is.

ten slotte bevat Google Cloud een eenvoudige service voor het plannen van adocker-gebaseerde taak op Compute Engine voor high-throughput workloads: de cloud Life SciencesPipelines API.Voor deze service moet u de taak ontbinden in taken,afhankelijkheden tussen taken beheren en de levenscyclus van taken beheren. Het DSub open source project biedt een command-line tool om batch banen te starten en ondersteunt de cloud Life Sciences Pipelines API.

opslag

de meeste HPC-toepassingen vereisen een bestandsopslagoplossing die de POSIX-API ondersteunt. Voor kleinere clusters biedt FileStore een op Google beheerde NFS-gebaseerde bestandsopslagdienst. Voor grotere clusters kan application I/O echter een performance bottleneck worden.Scale-out en parallelle bestandssystemen, zoalselastifile (overgenomen door Google), Lustre,orQuobyte, helpen schalen naar grote clusters (of zelfs I/O-zware kleinere clusters).

als bestandstoegang met lage latentie niet vereist is, kunt u ook gebruikmaken van cloudopslag,die parallelle objecttoegang biedt met behulp van de API of via gcsfuse, waar POSIX-Compatibiliteit vereist is.

kansen voor cluster computing in de cloud

er zijn veel redenen om compute clusters in de cloud uit te voeren:

• tijd-tot-oplossing. De lancering van een cluster van productiekwaliteit in de cloud duurt slechts enkele minuten, van een kleine cluster van 10 knooppunten met honderden beschikbare kernen tot grootschalige clusters met honderdduizend of meer winkels. De bouw van nieuwe clusters ter plaatse kan echter maanden duren voordat ze operationeel zijn. Zelfs wanneer on-Premise clusters beschikbaar zijn, hebben ze meestal een hoog gebruik en lange wachttijden in de wachtrij —soms uren of dagen — voordat taken worden gepland. In plaats daarvan kunt u uw eigen clusters in de cloud bouwen, ze gebruiken voor uw workloads en de clusters definiëren wanneer uw analyse voltooid is.

• lagere total cost of ownership. Google Cloud reduceert niet alleen de tijd voor de oplossing,maar kan ook de totale kosten per run verlagen door gebruik te maken van voorkeurs-VM ‘ s, kortingen voor langdurig gebruik en dynamische schaalvergroting. U kunt knooppunten toevoegen wanneer taken in de wachtrij staan en deze verwijderen wanneer dit niet nodig is.

• ondersteuning voor samenwerking. In veel situaties is de rekenanalyse ontwikkeld in samenwerking met verschillende mensen over multipleorganisaties. Google Cloud biedt tools voor projectniveauditentity en access management om gecontroleerde toegang tot gegevens en analytische tools mogelijk te maken. Geautoriseerde gebruikers kunnen toegang krijgen tot dezelfde apps, gegevens en clusters om ervoor te zorgen dat iedereen op dezelfde pagina is zonder gegevens te hoeven kopiëren, versies te beheren of syncclusterconfiguraties.

• op de taak toegesneden middelen. Omdat de kosten van een taak alleen afhangen van de totale kernuren, in plaats van het aantal exemplaren, kan elk team of groep met clusters in de cloud hun eigen speciale cluster hebben. Deze aanpak kan een ander belangrijk pijnpunt van het ontwikkelen van beleid rond multi-group gebruik verlichten. U kunt vervolgens elke dedicated cloudcluster aanpassen om deze af te stemmen op de doelapp. On-premise clusters hebben de neiging om te bestaan uit een one-size-fits-all resource gedeeld over de verschillende groepen en apps. In een dergelijke omgeving is het opzetten en onderhouden van beleid voor delen tussen de groepen vaak complex.

• integratie. Voordat ze grote computertaken kunnen uitvoeren, doen onderzoekers belangrijk werk om de datasets voor te bereiden. Na de overstap naar de cloud kunnen deze onderzoekers gebruikmaken van de big data-tools die beschikbaar zijn in de cloud. Ook de output van de rekensystemen moet worden geanalyseerd. Tools zoals BigQuery en Datalab kunnen aanzienlijke voordelen bieden ten opzichte van die beschikbaar zijn in on-premises systemen.

architectonische overwegingen

hoewel de tot nu toe beschreven voordelen overtuigend zijn, zijn er niettemin enkele technische uitdagingen die migratieprojecten vaak belemmeren.

• dataverkeer. De datasets die door de computenodes van een cluster worden verwerkt, moeten doorgaans in de cloud worden gestaged voordat de taken worden uitgevoerd.Het beheren van de gegevensbeweging kan complex zijn, afhankelijk van het volume van de data en hoe het wordt beheerd. Tools zoals avere kunnen helpen door een laag cloudcaching te bieden die automatisch gegevens verplaatst wanneer dat nodig is, maar voor veel apps moeten de datasets handmatig worden gestaged.

• Toegang Tot Gegevens. Veel HPC apps vereisen gedeelde toegang tot een set offiles en directory ‘ s. Hoe deze toegang wordt verstrekt, kan de prestaties van app aanzienlijk beïnvloeden. U kunt gebruikmaken van gedeelde gegevens die zijn opgeslagen inloud-opslag, in NFS-servers zoals filestore, of met behulp van parallelle bestandssystemen, zoals besproken in de sectie ‘opslagruimte’.

• beveiliging. Voor gegevens die gevoelig zijn, moet u ervoor zorgen dat de toegang altijd is geautoriseerd en gegevens op de juiste wijze worden versleuteld tijdens restand in transit. Terwijl cloudopslag gegevens versleutelt in rust en tijdens het transport, kunt u een extra laag van controle en beheer van sleutels toepassen,hetzij inloud Key Management Service, of op uw eigen. De sleutels moeten worden opgehaald of geïnstalleerd op de computenodes voordat de taak wordt uitgevoerd.

• Inter-node latentie. Voor nauw gekoppelde HPC-apps kan de prestatie gevoelig zijn voor de latentie tussen knooppunten in het cluster.Omdat Google Cloud nodes tot 64 cores biedt, kunt u parallelle taken met 64-wegs uitvoeren zonder knooppunten te doorkruisen. In de meeste gevallen presteren banen van ongeveer 1000 cores of kleiner redelijk goed op niet-gespecialiseerde netwerkhardware.

• Software licentiebeheer. Veel commerciële apps vereisen alicense server, ook wel bekend als een key server. Sommige apps komen met een ingebouwde of aanbevolen licentieserver en andere kunnen compatibel zijn met bestaande licentie-server-aanbiedingen. Sommige taakplanners kunnen helpen bij het beheer van licenties en taken stoppen totdat er een licentie beschikbaar is.

aanbevolen architecturen en beste praktijken

Technical computing biedt vele hulpmiddelen en benaderingen voor verschillende omstandigheden. Met zo veel opties, je zou het moeilijk vinden om te beginnen.Ongeacht de keuze van cluster management software en planner, er Gebied aantal best practices die u kunt volgen bij het uitvoeren op Google Cloud.

• leverage preemptible VM ‘ s waar mogelijk. Preemptible VM ‘s zijn net alsegular VM’ s op Rekenmotor, maar geprijsd tot 80% minder danregular VM ‘ s, met het voorbehoud dat ze kunnen worden teruggewonnen met weinig kennisgeving.Voor workloads met hoge doorvoer detecteren uw taakplanners het verlies van het knooppunt en behandelen het als een knooppuntfout en herschikken ze alle taken die op dat knooppunt op een andere bron worden uitgevoerd. Terwijl alle werkzaamheden aan die verloren nodesmight verloren gaan, de kans op knooppunt verlies is laag genoeg dat de lagere prijs is de kans waard. Het verwachte verliespercentage bedraagt 5% tot 15%. PreemptibleVMs zijn beperkt tot maximaal 24 uur gebruik voordat ze worden teruggewonnen.
• maak gebruik van de kosten en bandbreedte van cloudopslag in plaats van uw eigen parallelle bestandssysteem. Cloudopslag biedt sterke consistentie en schaalbare parallelle prestaties met lage totale kosten.Terwijl de First-byte latency is hoog op ongeveer 100 ms, apps die kunnen leverage Cloud Storage in plaats van het uitvoeren van een parallelle file server onCompute Engine zijn meer kosteneffectief. De beschikbare bandbreedte tussen cloudopslag en de rekenknooppunten is voldoende voor veel apps, sommige klanten hebben een aanhoudende totale bandbreedte van meer dan 23 GB/s gemeld.
• Bouw een single-app of single-group cluster. Traditionele clusters zijn verdeeld over meerdere gebruikers, groepen en apps, wat kan leiden tot lange wachtrijtijden voor banen en inefficiënt resourcegebruik door apps. OnGoogle Cloud, overwegen het creëren van meerdere clusters voor elke groep of project, en het gebruik van clusters die zijn geoptimaliseerd voor bepaalde apps die draaien op hen. Of u nu een cluster voor twee uur, of twee clusters voor een uur elk, de totale kosten zijn hetzelfde, maar het laatste patroon kan verminderenqueue-wachttijden, en het verbeteren van de prestaties van de app.

hoewel elke uitvoering uniek is, geven de volgende paragrafen enkele algemene aanbevelingen voor drie gemeenschappelijke gevallen.

onafhankelijke onderzoeker die hun gegevens wil verwerken

individuele onderzoekers proberen doorgaans hun app over hun gegevens te laten lopen en zo snel mogelijk te voltooien. Ze kunnen experts zijn in hun irapp, maar ze willen geen experts zijn in Clusterbeheer of Management.

als u workloads met hoge doorvoer uitvoert, kunt u overwegen de cloud Life SciencesPipelines API te gebruiken.De Pipelines API vereist dat u uw app in een Docker container te zetten en plaats uw invoerbestanden in een Cloud Storage emmer. Na dat isdone, kunt u de gcloud command-line tool gebruiken om de app te starten tegen elk van de bestanden in de Cloud Storage bucket. U kunt de resultaten in een andere cloud opslag emmer plaatsen.

hier is een voorbeeld van een commando om een taak uit te voeren die amtools gebruikt om een BAM index bestand te genereren uit een input BAM bestand:

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

waarbij

• vertegenwoordigt de ID van uw app in de Pipelines API.
• staat voor de naam van uw Cloud Storage bucket.
• vertegenwoordigt de naam van uw map.

er is geen cluster om aan te bieden of te beheren. De taken lopen gewoon totvoltooiing in een VM die wordt voorzien en beheerd door de Pipelines API. Dit iscost efficiënt omdat berekenen Motor rekeningen per seconde van het gebruik.

kleine tot middelgrote cluster voor een enkel project of team

in een project of team hebben de leden mogelijk toegang tot een cluster dat door een centraal team wordt beheerd voor gebruikers in hun hele bedrijf, of hebben ze mogelijk toegang tot grootschalige resources in een HPC-centrum buiten het bedrijf. In beide situaties worden de clusters professioneel beheerd en benaderd met behulp van standaardtools. Bijvoorbeeld, gebruikers gebruiken ssh om verbinding te maken met een head node en gebruiken Grid Enginesubmit scripts om taken voor uitvoering in te dienen.

een aanpak voor een dergelijk team is het gebruik van ElastiCluster om een clusteromgeving te definiëren die vergelijkbaar is met hun on-premise systemen. Ze kunnen de cluster aan te passen door het selecteren van een berekenen Motor machine type dat het best geschikt is voor hun app, en pas de opstartscripts om de software te installeren afhankelijkheden voor hun app. Invoergegevens kunnen nog steeds worden gestaged naar cloudopslag, en u kuntgcsfuse installeren op de compute nodes om de invoergegevens aan te koppelen.

deze gegevens worden opgeslagen in het ElastiCluster configuratiebestand, en wanneer computer nodig is, wordt een cluster geopend met behulp van het opdrachtregelprogramma, forexample:

% elasticluster start astrocluster1

het cluster, genoemd in het configuratiebestand als astrocluster1, is provisioned en geconfigureerd zoals opgegeven. De definities in een configuratiebestand zijn flexibel en ondersteunen verschillende knooppunttypen voor head en compute nodes,Bereken Enginepersistente schijven voor krasruimte, preemptible VM ‘s om de kosten voor high throughput workloads te verlagen, en GPU’ s voor versnelde werking. Een voorbeeld van een basisconfiguratie voor een slurm-gebaseerde cluster met 10 rekenknooppunten en 1 head node gebruikend 32-core virtuele machines gebaseerd op CentOS zou er als volgt uitzien:

 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 

als er ten slotte geen taken meer worden uitgevoerd in het systeem, kunt u het cluster stoppen:

% elasticluster stop astrocluster1

voor grotere workloads kunt u:

• kijk om de cluster machine types aan te passen om de kosten verder te verlagen.
• voeg een externe parallelle filer toe om de prestaties op schaal te verhogen.
• voeg automatische schaling mogelijkheden toe om extra knooppunten toe te voegen en te verwijderen op basis van de queue diepte.

HPC-centrum dat burst-capaciteit toevoegt aan bestaande clusters

Centrale HPC-centra hebben een enorme rekencapaciteit, maar omdat ze door veel groepen in het bedrijf of de organisatie worden gebruikt, hebben HPC-centra doorgaans een hoog gebruik en lange wachttijden voor wachtrijen. Ze worden doorgaans aangekocht met een bepaalde productiecapaciteit in het achterhoofd, en wanneer onvoorzienbare werklasten in de mix worden ingebracht, kunnen ze de vooruitgang aanzienlijk vertragen.

in deze situaties kunt u de Google-cloudomgeving binnendringen door rekenknooppunten tijdelijk aan het cluster toe te voegen. Het cluster wordt een hybride, met het head-knooppunt en sommige compute-knooppunten die on-premises worden uitgevoerd, en andere computenodes die op Google Cloud worden uitgevoerd. Wanneer de taakwachtrijen zijn leeggehaald, kunnen de extra knooppunten worden vrijgegeven.

barsten in de cloud is handig om een paar redenen:

• het onderhoudt een consistente gebruikersomgeving voor het indienen en beheren van taken. Gebruikers weten niet of zorg als extra knooppunten worden toegevoegd.
• IT-managers kunnen het beleid bepalen voor wanneer ze barsten, om de kosten te controleren.

de grootste uitdaging is het leveren van een consistente gegevens-en bestandsnaamruimte voor gebruikerstaken in de on-premises en Google Cloud nodes. De Google Cloud nodes hebben mogelijk geen toegang tot dezelfde interne bestandssystemen als de on-premises nodes. In deze situatie, banen die referenthese bestanden zal niet worden uitgevoerd.

als de Google Cloud-nodes zijn geconfigureerd met interne bestandstoegangspermissies, zullen taken worden uitgevoerd, maar mogelijk niet op dezelfde manier worden uitgevoerd en kunnen extra kosten voor netwerkbandbreedte en uitgang worden gecreëerd. Daarnaast kunnen parallelle taken die zijn verdeeld over on-premises en cloud nodes ook niet goed presteren met de toegevoegde latency tussen de verschillende delen van de app.

voor high-throughput-taken, waarbij HTCondor wordt gebruikt om in cloudbronnen uit te barsten, ontwijkt veel van deze uitdagingen. HTCondor ondersteunt dynamische provisioning met behulp van glideinwms.Als taken in de A-taakwachtrij worden ingediend, kunnen ze knooppunten activeren die worden aangeboden en aan het cluster worden toegevoegd. Wanneer ze worden toegevoegd, de Condor schedulertransfert de invoerbestanden naar de aangewezen knooppunt en gebruikt deze extra nodom de taken uit te voeren en drain de wachtrij.

Lees meer over gebruik van cluster computing op Google Cloud:

• Google Cloud, HEPCloud, and probing the nature of nature
• 220.000 cores and counting: mit math professor breekt record voor Largestever Computing Engine job

Lees meer over:

• File servers op Compute Engine
• Cloud Deployment Manager documentatie

aan de slag met uw cluster:

• Batch-verwerking met Compute Engine Autoscaler
• het Maken van een HTCondor cluster met behulp van Cloud-Implementatie Manager sjablonen

Voorbeeld projecten op GitHub:

• dsub voorbeeld: Eenvoudige batch jobs met Docker
• ElastiCluster voorbeeld

• Pijpleidingen API voorbeelden

• Probeer andere Google Cloud functies voor jezelf. Neem eens een kijkje bij onzetutorials.