Utilizarea clusterelor pentru calculul tehnic la scară largă în cloud

această soluție oferă îndrumări pentru efectuarea calculului tehnic la scară largăpe Google Cloud. Multe aplicații tehnice de calcul necesităun număr mare de noduri individuale de calcul, conectate împreună într-un cluster și coordonarea calculului și a accesului la date între noduri.

conceptele și tehnologiile care stau la baza calculului cluster s-au dezvoltat în ultimele decenii și sunt acum mature și mainstream. Migrarea software-ului în Google Cloud poate adăuga câteva riduri, dar oferă și o serie de oportunități de a reduce costurile și de a atenua blocajele existente în mediile de calcul de înaltă performanță de astăzi. Acest ghid oferă o imagine de ansamblu a tehnologiilor, provocărilor și a gamei actuale de soluții pentru rularea clusterelor computaționale pe Google Cloud.

cluster computing agregă și coordonează o colecție de mașini pentru a lucra împreună pentru a rezolva o sarcină. Clusterele au de obicei un singur nod de cap(uneori numit nod principal), un număr de noduri de calcul și, eventual, alte câteva noduri de specialitate. Nodul capului este creierul sistemului și esteresponsabil pentru:

• înregistrarea nodurilor de calcul în sistem.
• monitorizarea nodurilor.
• alocarea de locuri de muncă pentru anumite noduri.

utilizatorii trimit locuri de muncă, care sunt compuse din mai multe sarcini, în cazul în care o sarcină este unitatea de bază de lucru. Unele aplicații necesită ca toate sarcinile dintr-o lucrare să ruleze în prezent și să permită sarcinilor să comunice pentru a implementa un algoritm paralel;unele sarcini au un set complex de dependențe de sarcini, astfel încât anumite sarcini trebuie rulate înaintea altora; iar unele sarcini ar putea necesita anumite configurări de noduri în ceea ce privește memoria, procesoarele sau alt hardware special pe care să ruleze. Sarcinile sunt executabile care citesc datele de intrare din stocare, proceseazădate pentru a produce un rezultat, apoi scrieți rezultatele finale înapoi în stocare.

există două tipuri principale de sarcini de lucru de calcul cluster:

• high — performance computing (HPC) – un tip de calcul care utilizează noduri manyworker, strâns cuplat, și executarea concomitent pentru a realiza atask. Aceste mașini au de obicei nevoie de latență scăzută a rețelei pentru a comunicaîn mod eficient. Exemple de aplicații din acest spațiu includ modelarea vremii, dinamica fluidelor computaționale (CFD), modelarea stresului în inginerie și proiectarea electronicii.

• high — throughput computing (HTC) – un tip de calcul în care aplicațiile au mai multe sarcini care sunt procesate independent una de cealaltă, fără a fi nevoie ca nodurile individuale de calcul să comunice. Uneori, aceste sarcini de lucru sunt numite sarcini de lucru jenante paralele sau batch. Exemple tipice includ redare media, transcodare, genomica, andparticle-fizica-simulare eveniment și prelucrare. Dacă aveți nevoie pentru a procesa o mulțime de fișiere individuale, este, probabil, un volum de muncă HTC.

Cluster computing software stivă

un cluster computing software stivă este format din:

• software de gestionare a sistemului care furnizează și construiește clustere.
• programatori care orchestrează executarea de locuri de muncă.
• aplicații pentru utilizatorul final.

următoarele secțiuni discută despre software-ul de gestionare a sistemului și planificatorii.

software de gestionare a sistemului

puteți rula software de grupare fie direct pe hardware-ul metalic, fie în clustere locale, fie în medii virtualizate, ca și în cloudenvironments. Orchestrarea mai multor noduri într-un cluster de mână este timeconsuming și erori predispuse. Puteți utiliza software specializat de gestionare a clusterelor pentru a furniza și configura mai multe noduri și resurse, împreună, într-un mod accesibil și determinist.

software-ul open sourceElastiCluster de la Universitatea din Zurich oferă o abordare cloud-nativ tocluster management, cu suport pentru provisioning noduri, prin utilizarea motorului de calcul, și configurarea nodurilor prin utilizarea unui set de Ansibleplaybooks. ElastiCluster furnizează nodurile și instalează un softwarestack de bază, inclusiv NFS pentru servirea fișierelor, gestionarea contului de utilizator NIS și ajob scheduler pentru executarea aplicațiilor utilizatorului. ElastiCluster suportă o varietate ofschedulers, și îl puteți folosi din cutie sau personaliza pentru a satisface nevoile de mici la Echipe mijlocii.

dacă utilizați alte sisteme de gestionare a configurației pentru a gestiona clusterele HPC, cum ar fi Chef, Puppet sau Terraform, puteți utiliza aceste investiții în timp ce migrați la Google Cloud utilizând instrumentele și pluginurile disponibile.

Google Cloud oferă servicii native pentru furnizarea și implementareasisteme software multi-nod. Cloud Deployment Manager vă permite să furnizațiun set de resurse cloud, inclusiv Compute Engine, grupuri de instanțe Compute Enginemanaged și stocare în Cloud. TheHTCondor tutorial vă arată cum să utilizați Cloud Deployment Manager și grupuri de instanță gestionate toprovision și configurați un cluster.

job schedulers

după ce cluster-ul este operațional, software-ul care gestionează task executionand node allocation se numește un job scheduler (uneori numit workloadmanager sau queue manager). Adesea, un manager de cluster vine cu abuilt-in Job scheduler. Planificatorii de locuri de muncă oferă o varietate de capabilități pentru a ajutagestiona locuri de muncă și sarcini, cum ar fi:

• suport pentru prioritățile de locuri de muncă între utilizatori și grupuri, care ajută la furnizarea de planificare de locuri de muncă pe bază de politici.
• suport pentru sarcini eșuate prin așteptare și reprogramarea sarcinilor.
• luarea în considerare a dependențelor de sarcini și a nevoilor de resurse pentru alocarea sarcinilor.
• scalarea dimensiunii clusterului în funcție de numărul de lucrări din coadă.

există o varietate de manageri populari DE SARCINI comerciale și open source.Exemple includhtcondor de la Universitatea din Wisconsin, Slurm de la SchedMD,Univa Grid Engine și LSF Symphony de la IBM. Fiecare are punctele sale forte.

HTCondor este construit cu o filozofie comună-nimic și este usedacross resurse partajate pentru a programa oportunist locuri de muncă pe altfel idleresources. Acesta oferă propria mișcare de date și, prin urmare, nu necesită sisteme sharedfile. Ca rezultat, HTCondor scalează la sute de mii de nuclee șiputeți să-l utilizați în mai multe zone și regiuni. HTCondor a fost folosit pentrusarcini de lucru hibride, unde lucrarea este partajată sau împărțită între sisteme locale și bazate pe cloud. Cu toate acestea, după cum sugerează și numele său, se concentrează asupralocuri de muncă cu randament ridicat, nu strâns cuplate, locuri de muncă paralele.

Slurm și Univa Grid Engine oferă un mediu de cluster HPC mai tradițional,susținând atât aplicații paralele de înaltă performanță, cât și aplicații paralele de înaltă performanță. Ambele presupun un sistem de fișiere partajat peste noduri, ceea ce elimină necesitatea de a muta datele. Ambele oferă un mediu de utilizare convenabil și familiar pentrudezvoltarea aplicațiilor, deoarece acestea sunt adesea aceleași instrumente utilizate la fața locului.Aceste planificatoare de locuri de muncă tradiționale sunt suficiente pentru clustere mici și mijlocii,dar pe măsură ce dimensiunea clusterului crește, sarcina pe serverul de fișiere devine thebottleneck pentru performanță. Sistemele de fișiere paralele și distribuite (vezi secțiunea următoare) potajuta la această problemă la scară largă. Alternativ, în cazul în care nu este necesar un acces de fișiere cu latență redusă, puteți utiliza stocarea în Cloud, care oferăacces paralel la obiecte utilizând API-ul sau pringcsfuse,undeeste necesară compatibilitatea POSIX.

în cele din urmă, Google Cloud include un serviciu simplu pentru programarea sarcinii bazate pe aDocker pe Compute Engine pentru sarcini de lucru de mare viteză: API-ul cloud Life SciencesPipelines.Acest serviciu necesită să descompuneți lucrarea în SARCINI,să gestionați dependențele între sarcini și să gestionați ciclul de viață al activității. Thedsub proiect open source oferă un instrument de linie de comandă pentru a lansa locuri de muncă lot șisprijină Cloud Life Sciences conducte API.

stocare

majoritatea aplicațiilor HPC necesită o soluție de stocare a fișierelor care acceptă API-ul POSIX. Pentru clustere mai mici,FileStore oferă un serviciu de stocare a fișierelor bazat pe NFS gestionat de Google. Cu toate acestea,pentru clustere mai mari, I/o-ul aplicației poate deveni un blocaj de performanță.Scalarea și sistemele de fișiere paralele, cum ar fielastifile (achiziționate de Google), Luster,sauquobyte, ajută la scalarea la clustere mari (sau chiar i/O-clustere mai mici grele).

alternativ, în cazul în care nu este necesar acces la fișiere cu latență redusă, puteți utiliza stocarea în Cloud, care oferă acces la obiecte paralele utilizând API sau throughgcsfuse,unde este necesară compatibilitatea POSIX.

oportunități de calcul cluster în cloud

există multe motive pentru a rula clustere de calcul în cloud:

• timp-la-soluție. Lansarea unui cluster de calitate a producției în clouddurează doar câteva minute, de la un mic cluster de 10 noduri cu sute de nuclee disponibile, până la clustere la scară largă cu o sută de mii sau mai multecore. În schimb, construirea de noi clustere la fața locului poate dura luni de zile pentru a fi gata de funcționare. Chiar și atunci când clusterele locale sunt disponibile, acestea au de obicei o utilizare ridicată și timpi de așteptare lungi-uneori ore sau zile —înainte ca lucrările să fie programate să ruleze. În schimb, puteți să vă construiți propriile clustere în cloud, să le utilizați pentru încărcările dvs. de lucru și să eliminați clusterele atunci când analiza dvs. este completă.

• costuri totale mai mici de proprietate. Google Cloud nu numai că reduce soluția timeto, dar poate reduce și costul total pe rulare prin valorificarea VM-urilor preemptibile,reduceri de utilizare pe termen lung și scalare dinamică. Puteți adăuga noduri atunci când job-urilesunt în coadă și le eliminați atunci când nu este necesar.

• sprijin pentru colaborare. În multe situații, analiza calculelor este dezvoltată în colaborare cu diferite persoane din mai multe organizații. Google Cloud oferă nivel de proiectidentitate și instrumente de gestionare a accesului pentru a permite accesul controlat la date și instrumente analitice. Utilizatorii autorizați pot accesa aceleași aplicații, date și clustere pentru a se asigura că toată lumea se află pe aceeași pagină fără a fi nevoie să copiați date, să gestionați versiuni sau configurații synccluster.

• resurse adaptate sarcinilor. Deoarece costul unui loc de muncă depinde doar de orele de bază totale, mai degrabă decât de instanțele numerice, rularea clusterelor în cloud permite fiecărei echipe sau grupuri să aibă propriul cluster dedicat. Această abordare poate atenua un alt punct de durere major al dezvoltării politicilor în jurul utilizării în mai multe grupuri. Apoi, puteți personaliza fiecare cluster cloud dedicat pentru a-l regla pentru aplicația țintă. Clusterele locale tind să cuprindă o resursă unică pentru toate grupurile și aplicațiile. Într-un astfel de mediu, politicile de partajare între grupuri tind să fie complexe de înființat și menținut.

• integrare. Înainte de a putea executa lucrări mari de calcul, cercetătorii fac o muncă semnificativă pentru a pregăti seturile de date. După trecerea la cloud, acesteacercetătorii pot utiliza instrumentele de date mari disponibile în cloud. Ieșirile sistemelor de calcul trebuie, de asemenea, analizate. Instrumente precum BigQuery și Datalab pot oferi avantaje semnificativepeste cele disponibile în sistemele locale.

considerații arhitecturale

în timp ce avantajele descrise până acum sunt convingătoare, există totuși unele provocări tehnice care împiedică adesea proiectele de migrație.

• mișcarea datelor. Seturile de date care sunt procesate de computenodurile unui cluster trebuie de obicei să fie organizate în cloud înainte de a rula lucrările.Gestionarea mișcării datelor poate fi complexă, în funcție de volumuldate și modul în care este gestionat. Instrumente precum avere vă pot ajuta oferind un strat de cache în cloud care mută automat datele când este necesar, dar pentru multe aplicații seturile de date trebuie să fie organizate manual.

• Acces La Date. Multe aplicații HPC necesită acces partajat la un setfișiere și directoare. Modul în care este furnizat acest acces poate afecta semnificativperformanța aplicației. Puteți utiliza datele partajate stocate înmagazinare cloud, în servere NFS, cum ar FileStore, sau folosind sisteme de fișiere paralele, așa cum sa discutat în secțiunea stocare.

• securitatea. Pentru datele sensibile, trebuie să aveți grijă să vă asigurați că accesul este întotdeauna autorizat și că datele sunt criptate corespunzător în repaus și în tranzit. În timp ce stocarea în Cloud criptează datele în repaus și în tranzit, youpoate aplica un strat suplimentar de control și gestiona cheile fie inCloud Key Management Service,fie pe cont propriu. Cheile trebuie să fie preluate sau instalate pe computenodes înainte de a rula lucrarea.

• latență inter-nod. Pentru aplicațiile HPC strâns cuplate, performanțapoate fi sensibil la latența inter-nod între nodurile din cluster.Deoarece Google Cloud oferă noduri cu dimensiuni de până la 64 de nuclee, putețirulați lucrări paralele pe 64 de căi fără a traversa noduri. În cele mai multe cazuri, lucrările de aproximativ 1000 de nuclee sau mai mici funcționează destul de bine pe hardware-ul de rețea nespecializat.

• managementul licențelor Software. Multe aplicații comerciale necesită server alicense, uneori cunoscut sub numele de server cheie. Unele aplicații vin cu un server de licență încorporat sau recomandat, iar altele ar putea fi compatibile cu ofertele existente de server de licență. Unii programatori de locuri de muncă vă pot ajutagestionarea licenței și oprirea executării lucrărilor până când este disponibilă o licență.

arhitecturi recomandate și cele mai bune practici

tehnica de calcul oferă multe instrumente și abordări pentru diferite circumstanțe. Cu atât de multe opțiuni, s-ar putea să vă fie greu să începeți.Indiferent de alegerea software-ului de gestionare a clusterului și a planificatorului, existăo serie de bune practici pe care le puteți urma atunci când rulați pe Google Cloud.

• pârghie VMs preemptibile ori de câte ori este posibil. VM-urile preemptibile sunt la fel ca VM-urile regulate pe motorul de calcul, dar au un preț cu până la 80% mai mic decât VM-urile regulate, cu avertismentul că pot fi recuperate cu puțină notificare.Pentru sarcini de lucru cu randament ridicat, programatorii dvs. de locuri de muncă detectează pierderea nodului și îl tratează ca pe un eșec al nodului și reprogramează orice sarcini care rulează pe acel nod pe o altă resursă. În timp ce orice lucrare făcută pe acele noduri pierdutepoate fi pierdut, probabilitatea pierderii nodului este suficient de scăzută încât prețul mai mic merită șansa. Rata pierderilor așteptate este de 5% până la 15%. Preemptiblevm-urile sunt limitate la maximum 24 de ore de utilizare înainte de a fi recuperate.
• utilizați costul și lățimea de bandă a stocării în Cloud în loc derularea propriului sistem de fișiere paralel. Stocarea în Cloud oferăconsistență puternică și performanță paralelă scalabilă, cu costuri globale reduse.În timp ce latența primului octet este ridicată la aproximativ 100 ms, aplicațiile care potleverage cloud Storage în loc să ruleze un server de fișiere paralel pe motorul de calcul sunt mai eficiente din punct de vedere al costurilor. Lățimea de bandă disponibilă între stocarea în Cloud și nodurile de calcul este suficientă pentru manyapps, unii clienți au raportat o lățime de bandă agregată susținută de peste 23 GB/s.
• construiți un cluster cu o singură aplicație sau un singur grup. Clusterele tradiționale sunt împărțite între mai mulți utilizatori, grupuri și aplicații, ceea ce poate duce la perioade lungi de așteptare pentru locuri de muncă și la utilizarea ineficientă a resurselor de către aplicații. OnGoogle Cloud, luați în considerare crearea mai multor clustere pentru fiecare grup sauproiect și utilizarea clusterelor optimizate pentru anumite aplicații care rulează pe ele. Indiferent dacă rulați un cluster timp de două ore sau două clustere pentru o oră fiecare, costul total este același, dar ultimul model poate reducequeue-așteptați timpii și îmbunătățiți performanța aplicației.

deși fiecare implementare este unică, următoarele secțiuni oferă câteva recomandări generale pentru trei cazuri comune.

cercetător Independent care caută să-și proceseze datele

cercetătorii individuali încearcă de obicei să-și ruleze aplicația pe datele lor și să ajungă la finalizare cât mai repede posibil. Ei ar putea fi experți în lorapp, dar ei nu doresc să fie experți în administrarea clusterului saumanagement.

Dacă executați sarcini de lucru de mare viteză, atunci puteți lua în considerare utilizarea API-ului cloud Life SciencesPipelines.API-ul Pipelines vă cere să puneți aplicația într-un container Docker și să plasați fișierele de intrare într-o găleată de stocare în Cloud. După aceea isdone, puteți utiliza instrumentul de linie de comandă gcloud pentru a lansa aplicația împotrivafiecare dintre fișierele din cupa de stocare în Cloud. Puteți plasa rezultatele într-o altă găleată de stocare în Cloud.

Iată un exemplu de comandă pentru a executa o sarcină care usesSAMtools pentru a genera un fișier index BAM dintr-un fișier BAM de intrare:

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

unde

• reprezintă ID-ul aplicației în API conducte.
• reprezintă numele găleții de stocare în Cloud.
• reprezintă numele directorului dvs.

nu există niciun cluster de furnizat sau gestionat. Sarcinile pur și simplu rula până lacompletare într-un VM care este furnizat și gestionat de API conducte. Acest lucru iscost eficient, deoarece calcula facturile de motor pe secundă de utilizare.

cluster de dimensiuni mici și medii pentru un singur proiect sau echipă

într – un proiect sau echipă, membrii ar putea avea acces la un cluster administrat de acentral team pentru utilizatorii din întreaga companie sau ar putea avea acces la resurse la scară largă la un centru HPC off-site. În ambele situații, clusterele sunt gestionate profesional și accesate folosind instrumente standard. Forexample, utilizatorii ar putea folosi ssh pentru a se conecta la un nod cap și de a folosi Grid Enginesubmit script-uri să prezinte locuri de muncă pentru execuție.

o abordare pentru o astfel de echipă este de a utiliza ElastiCluster pentru a defini un mediu de clusterenvironment care este similar cu sistemele lor locale. Ei pot personaliza thecluster selectând un tip de mașină Compute Engine care este cel mai potrivitpentru aplicația lor și personalizează scripturile de pornire pentru a instala software-ul dependențe pentru aplicația lor. Datele de intrare pot fi în continuare etapizate lacloud Storage și puteți instalagcsfuse pe nodurile de calcul pentru a monta datele de intrare.

aceste detalii sunt înregistrate în fișierul de configurare ElastiCluster, și atunci când este nevoie de calcul, un cluster este adus prin utilizarea instrumentului de linie de comandă, forexample:

% elasticluster start astrocluster1

clusterul, numit în fișierul de configurare ca astrocluster1 , este provisionedand configurat așa cum este specificat. Definițiile dintr-un fișier de configurare suntflexibile și acceptă diferite tipuri de noduri pentru nodurile Head și compute,discuri Compute Enginepersistent pentru spațiul scratch, VM-uri preemptibile pentru a reduce costul încărcărilor de lucru de înaltă capacitate și GPU-uri pentru funcționarea accelerată. Un exemplu de basicconfiguration pentru un cluster bazat pe Slurm cu 10 noduri de calcul și 1 nod capfolosind mașini virtuale cu 32 de nuclee bazate pe CentOS ar arăta după cum urmează:

 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 

în cele din urmă, atunci când nu mai multe locuri de muncă se execută în sistem, puteți opri cluster:

% elasticluster stop astrocluster1

pentru sarcini de lucru mai mari, puteți:

• uita-te pentru a personaliza tipurile de mașini de cluster pentru a reduce și mai mult costurile.
• adăugați un filer paralel extern pentru a crește performanța la scară.
• adăugați capabilități de scalare automată pentru a adăuga și elimina noduri suplimentare pe baza adâncimii cozii.

HPC center adăugând capacitate de spargere clusterelor existente

centrele centrale HPC au o capacitate extraordinară de calcul, dar pentru că sunt utilizate de multe grupuri din întreaga companie sau organizație, centrele HPC tind să aibă o utilizare constantă ridicată și timpi lungi de așteptare. Acestea sunt achiziționate în mod tipic având în vedere o anumită capacitate de producție și, atunci când sarcinile de lucru neprevăzute sunt prezentate în amestec, acestea pot încetini semnificativ progresul.

în aceste situații, puteți izbucni în mediul Cloud Google adăugând noduri de calcul temporar în cluster. Clusterul devine un hibrid, cu nodul principal și unele noduri de calcul care rulează local și alte computere care rulează pe Google Cloud. Când cozile de locuri de muncă au fost drenate, nodurile suplimentare pot fi eliberate.

spargerea în cloud este convenabilă din câteva motive:

• menține un mediu de utilizator consistent pentru depunerea și gestionarea locurilor de muncă. Utilizatorii nu știu sau nu le pasă dacă se adaugă noduri suplimentare.
• permite managerilor IT să definească politici pentru momentul în care să explodeze, pentru a controla costurile.

cea mai mare provocare este furnizarea unui spațiu de nume de date și fișiere consistente pentru lucrările utilizatorilor în nodurile locale și Google Cloud. Este posibil ca nodurile cloud google să nu aibă acces la aceleași sisteme de fișiere interne ca și nodurile locale. În această situație, lucrările care fac referințăaceste fișiere nu vor funcționa.

dacă nodurile Google Cloud sunt configurate cu fișiere interne-accesspermissions, apoi locuri de muncă va rula, dar s-ar putea să nu efectueze în același mod andmight crea lățime de bandă suplimentară de rețea și taxe de ieșire. În plus, lucrările paralele care sunt împărțite între nodurile locale și cloud ar putea, de asemenea, să nu funcționeze bine cu latența adăugată între diferitele părți ale aplicației.

pentru locuri de muncă de mare randament, folosind HTCondor pentru a izbucni în resurse cloud ocoleștemulte dintre aceste provocări. HTCondor acceptă furnizarea dinamică utilizândglideinwms.Ca locuri de muncă sunt prezentate în o coadă de locuri de muncă, ele pot declanșa noduri beingprovisioned și adăugate la cluster. Când sunt adăugate, programatorul condortransferă fișierele de intrare la nodul desemnat și folosește acele noduri suplimentarepentru a executa sarcinile și a scurge coada.

citiți mai multe despre cazurile de utilizare a computerelor cluster pe Google Cloud:

• Google Cloud, HEPCloud și sondarea naturii naturii
• 220.000 de nuclee și numărare: profesorul de matematică MIT bate recordul pentru cea mai mare lucrare a motorului de calcul

citiți mai multe despre:

• servere de fișiere pe motorul de calcul
• documentația managerului de implementare Cloud

începeți cu Clusterul:

• prelucrare lot cu Compute Engine Autoscaler
• crearea unui cluster HTCondor utilizând șabloane Cloud Deployment Manager

Exemple de proiecte pe GitHub:

• dsub exemplu: simplu lot de locuri de muncă cu Docker
• ElastiCluster exemplu

• conducte API Exemple

• încercați alte funcții Google Cloud pentru dvs. Aruncati o privire la nostrututoriale.