Lage egen supercomputer ved å clustre mange forskjellige maskiner?

[reminett]

Hei!

 

Jeg har googlet i noen timer nå for å prøve å lære litt om clustering.

Siden jeg har en del maskiner liggende rundt her, tenkte jeg at det hadde vært kult få dem i bruk til noe.

 

Og da lurer jeg på:

Er det mulig å lage én stor supercomputer av mange forskjellige maskiner?

Det aller beste hadde vært om jeg kunne lage en supercomputer som kjørte virtuelle maskiner..

Blir det slik at en supercomputer får like mye minne og prosessorkraft som alle enkeltmaskinene utgjør til sammen, eller har jeg misforstått hele konseptet?

 

Jeg setter pris på alle tilbakemeldinger, gjerne erfaringer og evt linker til prosjekter osv

Endret 3. juli 2010 av cyclo
Tittel endret da original tittel brøt med forumets retningslinjer

[mikeys]

Hørtes ut som et kult prosjekt. Skulle ønske jeg også hadde en haug gamle maskiner liggende

 

Jeg tror en kan si at (nesten) alle ressursene til nodene i clusteret vil være tilgjengelige, men det vil neppe skalere linjært (Amdahls lov).

[reminett]

Ja, jeg syntes det virker veldig kult å få noe slikt til..

 

Men er det slik at den virtuelle maskinen da kjøres som én diger maskin med hauger av prosessorkraft og minne?

 

Og hvordan fungerer egentlig et cluster?

 

Hva gjør jeg for å komme i gang?

[mikeys]

Jeg vet kan ikke si det for sikkert, men jeg tror ikke det vil la seg lett gjøre å skalere en virtuell maskin over et cluster. Det eneste "clusteret" jeg har vært borti var for en stund siden da jeg gjorde noe video omkoding med to tre PCer Av det jeg fikk med meg den gang fungerte det slik at jeg hadde en master som fordelte arbeidet og flere slaver som utførte arbeidet.

 

Det kan godt hende at det finnes andre typer cluster enn dette, jeg har egentlig ikke satt meg særlig godt inn i emnet.

[gnom1]

Har overhode ingen peiling på clustering, men inntrykket mitt er at det finnes flere fundamentalt ulike former for clustering. Uansett, husker at jeg leste om ParallelKnoppix på Distrowatch for noen år siden. Nå heter det visst PelicanHPC

[olefiver]

Kan også ta en titt på Rocks Cluster Distribution, og evt lese deg opp på Beowulf clustere.

 

 

[Del]

Det er viktig å skille begrepene. Det første man bør være klar over er forskjellen mellom delt minne og distribuert minne.

 

http://en.wikipedia.org/wiki/Shared_memory

 

Beowulf er en standard klynge med distribuert minne hvor kommunikasjon mellom prosesser på forskjellige noder skjer ved MPI.

 

Det er fullt mulig å ha et SSI på en rekke standard noder, altså presenterer klyngen som delt minne og la operativsystemet ta seg av fordelingen mellom noder. Dette har av forskjellige årsaker ikke tatt av, og bør fortsatt betraktes som eksperimentelt.

 

Virtualisering, slik som med KVM, er noe ganske annet. For at det skal ha noe for seg må du nesten ha ganske nye prosessorer som støtter virtualisering, ellers blir ytelsen svært lav.

 

En Beowulf klynge er derimot svært lett å sette opp, du finner veiledning her:

http://wiki.diskusjon.no/index.php/Guide:%28K%29Ubuntu_server_howto/For_entusiasten_og_bedriften#Linux-klynge_-_bygg_din_egen_superdatamaskin

[reminett]

Takk for svar, Del.

 

Jeg prøver så godt jeg kan å forstå dette konseptet, og hva som må til for å gjøre det jeg ønsker.

Kan du forklare hva en klynge faktisk gjør og hvordan den fungerer? Evt peke meg til en lettfattelig beskrivelse av dette?

 

Målet mitt er å kjøre virtuelle maskiner som er helt uavhengig av hardware.

 

Eks:

 

4 maskiner kjører 1 virtuell maskin.

Gjerne slik at maskin nr 3 kan tas ut av drift og de resterende 3 får større last.

 

På denne måten kan man skape en stor maskin eller kjøre flere virtuelle maskiner helt hardwareuavhengige, slik at oppgradering eller flytting av virtuell(e) maskin(er) blir enklere.

 

Jeg spør kanskje dumt her, men dette har jeg veldig lite peiling på...

 

Tusen takk

[Sokkalf™]

Deling av ressurser mellom mange maskiner er nok en relativt vanskelig oppgave, som har store utfordringer på problemer som ikke er svært parallelliserbare.

 

Å få 4 maskiner til å kjøre én virtuell maskin er uvanlig, og jeg er usikker på om det har noe for seg mtp. problemene man får med å få en sånn løsning til å gi god ytelse (hvis det i det hele tatt er mulig).

 

Det som derimot er mye mer vanlig, er å kjøre et høyt antall virtuelle maskiner på flere noder. F.eks 32 VM på 4 fysiske maskiner, men hvor en VM kjører på kun én node om gangen (Eller to - men da gjør de to VMene nøyaktig det samme, det er kun for availability-formål, litt som å kjøre 2 maskiner i RAID-1.)

 

Må en node tas ned for vedlikehold, flyttes ("live migration") VMs på denne til andre noder før den går ned. Ved kræsj restartes typisk VMene på ledige noder - eller hvis man bruker denne "RAID-1" løsningen, vil man ikke merke noe nedetid.

 

Det finnes flere virtualiseringsløsninger som tilbyr dette den dag idag, men det du spør etter hvor man deler minne og CPU er nok ikke helt praktisk mulig.

[Del]

Evt peke meg til en lettfattelig beskrivelse av dette?

Vil egentlig oppfordre deg til å lese lenkene jeg ga i forrige innlegg, det er det mest lettfattelige jeg har for hånden. Du kan jo også lese wikipediasiden om beowulf cluster, den gir en fin oversikt over klynger.

Målet mitt er å kjøre virtuelle maskiner som er helt uavhengig av hardware.

Dessverre er nok dette utopi. Virtualisering er fortsatt en krevende øvelse for effektivt system design. Det er ingen hellig gral som løser alle problemer, snarere tvert imot. Typisk vil det være naturlig å avgjøre egnethet for virtualisering tjeneste for tjeneste.

4 maskiner kjører 1 virtuell maskin.

Gjerne slik at maskin nr 3 kan tas ut av drift og de resterende 3 får større last.

Et mer relevant scenario er at du har en eller flere virtuelle maskiner som som du kan fordele mellom noder, og flytte fra noden til node ved behov.

På denne måten kan man skape en stor maskin eller kjøre flere virtuelle maskiner helt hardwareuavhengige, slik at oppgradering eller flytting av virtuell(e) maskin(er) blir enklere.

Hadde det vært så enkelt, så ville verden sett svært annerledes ut. I virkeligheten har du trade-offs og kompromisser.

 

Spesielt ønsker du her å blande to teknologier som begge er i et tidlig stadie, og hvor det er fundamentale utfordringer på begge fronter. Først nå er vi omtrent der at virtualiserte maskiner kan begynne å utnytte hardware til en enkelt node med minimal performance hit. Når det gjelder SSI er det mest lovende jeg har sett Fraunhofer sin virtual machine, men dette er en kommersiell løsning som krever spesiell hardware (infiniband mellom noder). I dag tror jeg rett og slett ikke det er mulig å kombinere disse teknologiene. Jeg har til god å se noen kjøre paravirtualisering på en SSI.

Endret 11. august 2010 av Del

[tingo]

@reminett: det er viktig å forstå at (per dags dato) så er en "supercomputing" maskin / klynge ikke det samme som en veldig kraftig "vanlig" datamaskin. En klynge er en spesialisert datamaskin, som krever spesialtilpassede programmer. Dette betyr blant annet at du ikke kan kjøre vanlige virtualiseringsprogrammer på en slik klynge; de må tilpasses først.

[kpolberg]

Cray hadde vel i sin tid, en måte å koble flere noder sammen slik at det ble presentert som én stor maskin.

 

Sitter endel med dette på jobb, men det er store forskjeller på hva som skal regnes på, og derfor er clusterene satt opp forskjellig.

[Del]

Cray lagde maskiner med delt minne. Det er noe annet enn å få flere maskiner til å dele minne. Du kan få store maskiner med delt minne i dag også. Både IBM og HP tilbyr dette med hhv power og itanium. Med de største x86 nodene fra amd og Intel blir skillet diffust. Men da snakker vi altså om maskiner som fremstår som en enkelt node.

Endret 11. august 2010 av Del

[kpolberg]

Del, du har selvfølgelig helt helt rett...Jeg tenkte på Craylink, som egentlig ble brukt i SGI maskiner under navnet numalink.

 

IBM sine PowerPC er jeg (heldigvis) lite borti. HP sin Itanium satsing må vel snart være død? Her på bruket går det heller mot flere i stedet for raskere. Altså det er billigere å kjøpe flere og så kunne kjøre flere jobber i parallell i stedet for at 1 jobb kjører veldig fort.

 

Ser forresten nå at SGI sine Itanium2(Altix 3000) baserte maskiner laget i 03, har numalink, som senere har blitt brukt i Altix UV med Intel x86-64 prosessorer.

 

Ganske så spennende, men gevinsten i forhold til "hyllevare" må nok settes opp mot hverandre.

[reminett]

Tusen takk til alle sammen her, spesielt til Del og Sokkalf for utfyllende info som fikk satt meg litt på plass

 

Er fremdeles imponert over hjelpelysten til enkelte her

[kyrsjo]

Klarer ikke holde meg unna denne tråden

 

Takk for svar, Del.

 

Jeg prøver så godt jeg kan å forstå dette konseptet, og hva som må til for å gjøre det jeg ønsker.

Kan du forklare hva en klynge faktisk gjør og hvordan den fungerer? Evt peke meg til en lettfattelig beskrivelse av dette?

 

Målet mitt er å kjøre virtuelle maskiner som er helt uavhengig av hardware.

 

Eks:

 

4 maskiner kjører 1 virtuell maskin.

Gjerne slik at maskin nr 3 kan tas ut av drift og de resterende 3 får større last.

 

På denne måten kan man skape en stor maskin eller kjøre flere virtuelle maskiner helt hardwareuavhengige, slik at oppgradering eller flytting av virtuell(e) maskin(er) blir enklere.

 

Jeg spør kanskje dumt her, men dette har jeg veldig lite peiling på...

 

Tusen takk

 

Hei!

 

Jeg tviler på at dette går, da flaskehalsen i ett cluster alltid er dataoverføringen mellom nodene.

Det å derfor forsøke å kjøre et program (ett helt operativsystem faktisk) transparent oppå flere maskiner og få det til å framstå som én maskin, vil derfor være skikkelig treigt. Dette skyldes at systemet som kjører i den viritualiserte maskinen regner med at den kan aksessere hele minnet like kjapt -- men dette holder overhodet ikke vann når deler av minnet ligger på en annen node.

 

Derfor kan ikke multi-core programmer automatisk kjøre på et cluster (men andre veien går stort sett fint, gitt at du har en stor nok multi-core maskin). For entrådete, sekvensielle, programmer er det komplett umulig -- da må først én ting gjøres, så neste, osv; og speedup fra paralellprosessering er ikke mulig. Som et eksempel: Tenk deg et program som summerer fibonaci-rekken, som er gitt ved:

a_0 = 1

a_1 = 1

a_2 = a_0 + a_1

a_3 = a_1 + a_2

a_4 = a_2 + a_3

osv.

 

Dermed kan du ikke regne ut a_3 før du har regnet ut a_2, og for å kunne berenge a_4 trenger du a_3 og a_2 osv. Ettersom flere CPU'er ikke gjør at det går noe fortere å hente ut to tall, legge dem sammen, og lagre resultatet, så nytter det ikke med raskere CPU. Du trenger én stor kjapp en. Veldig mange programmer/algoritmer er slik.

 

Andre programmer lar seg i større grad paralellisere, slik at to CPU'er kan jobbe en stund, utveksle (deler av) løsningene de kom fram til, jobbe videre osv. Desto mindre de trenger å utveksle, desto fortere går det. Klassikeren for dette er Monte-Carlo integrasjons-algoritmer, som stort sett trenger å utveksle étt tall på slutten av en beregning som kan ta mange minutter eller timer på hver core.

 

Det finnes mange måter å skrive slike programmer; ett av de mest populære er MPI.

http://en.wikipedia.org/wiki/Message_Passing_Interface

Dersom du programmerer i Python, er PP et veldig fint sted å starte for å lage multicore/cluster-programmer:

http://www.parallelpython.com/

 

I tillegg finnes det selsagt mange andre teknikker, slik som Grid. Her sender man enkelt-jobber til hver maskin, som tar seg av en liten del av datasettet. Til slutt laster man ned resultatene, og slår dem sammen. Dette er fint for ting som overhodet ikke trenger å komunisere under beregning (kalles ofte "embarrassingly paralell").

[Del]

Klarer ikke holde meg unna denne tråden

Lurte på hvor det hadde blitt av deg, hyggelig du lar deg lokke frem

Jeg tviler på at dette går, da flaskehalsen i ett cluster alltid er dataoverføringen mellom nodene.

Det å derfor forsøke å kjøre et program (ett helt operativsystem faktisk) transparent oppå flere maskiner og få det til å framstå som én maskin, vil derfor være skikkelig treigt. Dette skyldes at systemet som kjører i den viritualiserte maskinen regner med at den kan aksessere hele minnet like kjapt -- men dette holder overhodet ikke vann når deler av minnet ligger på en annen node.

Ja, og dette er hovedsaklig grunnen til at SSI over en klynge ikke har tatt av. Som Fraunhofer demonstrerer kan man delvis overkomme dette med høyhastighetskobling mellom noder. Med bare vanlig Gbit nett mellom noder vil det være svært begrenset hvilken last som skulle kunne tenkes å kjøres med systemet satt opp som SSI.

 

Faktisk er stort sett alle server-løsninger i dag Numa, hvilket betyr at minneaksess ikke er like rask uansett om du er på en klynge eller en maskin med delt minne. Intel sine systemer basert på FSB hadde derimot lik aksess til minnet for alle prosessorer, men det gikk faktisk på bekosting av minneytelsen. Et noe subtilt poeng som selv Linus snubler med. Du kan ta en titt her for litt dypdykk:

http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=79870&threadid=79593&roomid=2

bare les deg nedover svarene.

 

Med andre ord kan du i prinsippet ha samme minneaksess på en klynge som på en maskin med delt minne. Doble infiniband er faktisk rimelig nærme AMD sine HT links mellom prosessorer. Det betyr ikke at problemet kun stikker i kjapp nok node-kommunikasjon. Med delt minne må faktisk maskinen holde styr på hvilken CPU som eier hvilket minne (hvis en CPU laster opp data i cache, så må den sikre seg at andre ikke skriver til samme minne område når den skal skrive tilbake). Dette løses i hardware på en maskin med delt minne ved noe som kalles cache coherency. Cache coherency har vist seg å være en betydelig ytelsesutfordring på større maskiner med delt minne, og løsningene for å bøte på det går gjerne på bekostning av latency. Ved MPI er det programmereren eksplisitt som fordeler minne, og har ansvaret for hvilken CPU som skriver til hva. Hvorvidt SSI over en klynge med kjapp kobling har noe for seg koker dermed fort ned til hvorvidt det å håndtere cache coherency i software gjennom MPI er en brukbar løsning. Dette er fortsatt uavklart etter min mening, selv om Linus er rimelig klar i sin sak:

http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=110508&threadid=110430&roomid=2

Ettersom flere CPU'er ikke gjør at det går noe fortere å hente ut to tall, legge dem sammen, og lagre resultatet, så nytter det ikke med raskere CPU. Du trenger én stor kjapp en. Veldig mange programmer/algoritmer er slik.

Amdahls lov er kanskje passende lesing for å se nærmere på denne problematikken. Endret 15. august 2010 av Del

[kyrsjo]

Klarer ikke holde meg unna denne tråden

Lurte på hvor det hadde blitt av deg, hyggelig du lar deg lokke frem

Hyggelig å høre fra deg også; Jeg er tidvis rammet av et ganske heftig tilfelle av Thesis Repulsion Field

 

Jeg tviler på at dette går, da flaskehalsen i ett cluster alltid er dataoverføringen mellom nodene.

Det å derfor forsøke å kjøre et program (ett helt operativsystem faktisk) transparent oppå flere maskiner og få det til å framstå som én maskin, vil derfor være skikkelig treigt. Dette skyldes at systemet som kjører i den viritualiserte maskinen regner med at den kan aksessere hele minnet like kjapt -- men dette holder overhodet ikke vann når deler av minnet ligger på en annen node.

Ja, og dette er hovedsaklig grunnen til at SSI over en klynge ikke har tatt av. Som Fraunhofer demonstrerer kan man delvis overkomme dette med høyhastighetskobling mellom noder. Med bare vanlig Gbit nett mellom noder vil det være svært begrenset hvilken last som skulle kunne tenkes å kjøres med systemet satt opp som SSI.

 

Faktisk er stort sett alle server-løsninger i dag Numa, hvilket betyr at minneaksess ikke er like rask uansett om du er på en klynge eller en maskin med delt minne. Intel sine systemer basert på FSB hadde derimot lik aksess til minnet for alle prosessorer, men det gikk faktisk på bekosting av minneytelsen. Et noe subtilt poeng som selv Linus snubler med. Du kan ta en titt her for litt dypdykk:

http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=79870&threadid=79593&roomid=2

bare les deg nedover svarene.

 

Godt svar, og interessant lesing (selv om jeg ikke har 100% kontroll på hvordan CC funker).

 

Hva er SSI?

 

Jeg er dog litt overrasket over at Linus hardnakket påstår at alle "skikkelige" problemer trenger å dele alt av data på tvers av prosesser/tråder? Hverken i Monte-Carlo beregninger (mitt felt)

eller løsning av differentsiallikninger på strukturert grid eller FEM (snart mitt felt) er dette tilfelle, og message passing er fint og flott, men delt minne fullstendig unødvendig.

 

Med andre ord kan du i prinsippet ha samme minneaksess på en klynge som på en maskin med delt minne. Doble infiniband er faktisk rimelig nærme AMD sine HT links mellom prosessorer. Det betyr ikke at problemet kun stikker i kjapp nok node-kommunikasjon. Med delt minne må faktisk maskinen holde styr på hvilken CPU som eier hvilket minne (hvis en CPU laster opp data i cache, så må den sikre seg at andre ikke skriver til samme minne område når den skal skrive tilbake). Dette løses i hardware på en maskin med delt minne ved noe som kalles cache coherency. Cache coherency har vist seg å være en betydelig ytelsesutfordring på større maskiner med delt minne, og løsningene for å bøte på det går gjerne på bekostning av latency. Ved MPI er det programmereren eksplisitt som fordeler minne, og har ansvaret for hvilken CPU som skriver til hva. Hvorvidt SSI over en klynge med kjapp kobling har noe for seg koker dermed fort ned til hvorvidt det å håndtere cache coherency i software gjennom MPI er en brukbar løsning. Dette er fortsatt uavklart etter min mening, selv om Linus er rimelig klar i sin sak:

http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=110508&threadid=110430&roomid=2

 

Infiniband etc. må da gi ganske heftig latency i forhold til å kjøre på én stor maskin? Selv om båndbredden kanskje er bra nok (sjokkerende med et eksternt grensesnitt som kommer i nærheten av hva som er mulig på ett og samme kort ).

 

Ettersom flere CPU'er ikke gjør at det går noe fortere å hente ut to tall, legge dem sammen, og lagre resultatet, så nytter det ikke med raskere CPU. Du trenger én stor kjapp en. Veldig mange programmer/algoritmer er slik.

Amdahls lov er kanskje passende lesing for å se nærmere på denne problematikken.

[Del]

Hva er SSI?

In distributed computing, a single system image (SSI) cluster is a cluster of machines that appears to be one single system.

ref: http://en.wikipedia.org/wiki/Single-system_image

Jeg er dog litt overrasket over at Linus hardnakket påstår at alle "skikkelige" problemer trenger å dele alt av data på tvers av prosesser/tråder? Hverken i Monte-Carlo beregninger (mitt felt)

eller løsning av differentsiallikninger på strukturert grid eller FEM (snart mitt felt) er dette tilfelle, og message passing er fint og flott, men delt minne fullstendig unødvendig.

Hvilket forteller oss at ingen kan ha peiling på alt, selv ikke Linus. Morsomme tema, lov å spørre om hva du tar oppgaven på?

Infiniband etc. må da gi ganske heftig latency i forhold til å kjøre på én stor maskin? Selv om båndbredden kanskje er bra nok (sjokkerende med et eksternt grensesnitt som kommer i nærheten av hva som er mulig på ett og samme kort ).

Tror du overvurderer maskiner med delt minne, de er ikke så annerledes i hardware. Det er ikke akkurat et svært kretskort med en suppe av CPU'er og minnebrikker sindig loddet sammen. På latency hadde Pathscale med sin infinipath løsning (som brukte en HT link for å koble mellom noder) latency fullt på høyde med SGI sin Altix. Dette var for fem år siden.

ref: http://icl.cs.utk.edu/hpcc/hpcc_results.cgi

(siste tall gir ring latency, sammenlign Pathscale sin submission med Itanium-baserte Altix fra SGI, Pathscale sin er standard Opteron med distribuert minne som bruker infinipath interconnect mens Itamium Altix er delt minne med SGIs numalink).

Endret 15. august 2010 av Del

[kyrsjo]

Hva er SSI?

In distributed computing, a single system image (SSI) cluster is a cluster of machines that appears to be one single system.

ref: http://en.wikipedia.org/wiki/Single-system_image

Jeg er dog litt overrasket over at Linus hardnakket påstår at alle "skikkelige" problemer trenger å dele alt av data på tvers av prosesser/tråder? Hverken i Monte-Carlo beregninger (mitt felt)

eller løsning av differentsiallikninger på strukturert grid eller FEM (snart mitt felt) er dette tilfelle, og message passing er fint og flott, men delt minne fullstendig unødvendig.

Hvilket forteller oss at ingen kan ha peiling på alt, selv ikke Linus. Morsomme tema, lov å spørre om hva du tar oppgaven på?

 

Nå for tiden holder jeg på med full-simulering av testbeam-eksperimenter for sensor-karakterisering. Dvs. vi fyrer høy-energi (~180 GeV) pioner på et setup med ATLAS pixel silisium-sensorene vi vil teste, samt et sett av sensorer vi bruker til å spore partiklene igjennom oppsettet.

 

Dette simulerer jeg, både hvordan partikklene beveger seg igjennom oppsettet, legger igjen energi etc., samt hvordan sensorene reagerer.

 

Kan lenke til masteroppgaven så fort jeg er ferdig (et par uker). Ellers så finner du softwaren på CERN sin SVN (om du har tilgang der så kan jeg gjerne poste addressen).

 

For PhD skal jeg jobbe med simulering og design for CLIC-akseleratoren. Skal da bruke T3P og liknende:

http://www-group.slac.stanford.edu/acd/Codes.html

på NERSC. Bruker-agreement'en til NERSC er morsom, og trolig mest retta mot folk som jobber for US gov... Måtte bla skrive under på at "jeg lover å ikke simulere atomvåpen (eller annet hemmeligstemplet stæsj; <liste>) på deres maskiner"...

http://www.nersc.gov/nusers/accounts/usage.php

 

Infiniband etc. må da gi ganske heftig latency i forhold til å kjøre på én stor maskin? Selv om båndbredden kanskje er bra nok (sjokkerende med et eksternt grensesnitt som kommer i nærheten av hva som er mulig på ett og samme kort ).

Tror du overvurderer maskiner med delt minne, de er ikke så annerledes i hardware. Det er ikke akkurat et svært kretskort med en suppe av CPU'er og minnebrikker sindig loddet sammen. På latency hadde Pathscale med sin infinipath løsning (som brukte en HT link for å koble mellom noder) latency fullt på høyde med SGI sin Altix. Dette var for fem år siden.

ref: http://icl.cs.utk.edu/hpcc/hpcc_results.cgi

(siste tall gir ring latency, sammenlign Pathscale sin submission med Itanium-baserte Altix fra SGI, Pathscale sin er standard Opteron med distribuert minne som bruker infinipath interconnect mens Itamium Altix er delt minne med SGIs numalink).

 

Hmm, interessant