infectedtech: The AAPEN Project - kommentartraad

[The Crusher]

Okey, da venter vi i spenning

[[Infected]]

Ok, en aldri saa liten teaser er lagt ut

 

MvH

[infected]

[Hestejente99]

Berre eg som slit litt med bileta i teaseren?

[The Crusher]

Får de ikke opp jeg heller

[[Infected]]

Lynet tok modemet og halve distrib. switch'en, saa gikk strommen

 

MvH

[infected]

[The Crusher]

Uffda, men prosjektet ble vel ikke skadet?

[Big SturL]

Jeg ser du forklarer lenger bak her hva denne maskina er til for, men jeg må innrømme at jeg forstod godt lite av det... Kan du kanskje forklare med enklere begrep hva det går ut, evt. linke meg til en side hvor jeg kan lese om det?

[[Infected]]

Jeg ser du forklarer lenger bak her hva denne maskina er til for, men jeg må innrømme at jeg forstod godt lite av det... Kan du kanskje forklare med enklere begrep hva det går ut, evt. linke meg til en side hvor jeg kan lese om det?

 

AAPEN er en research cluster, dvs. vil den kjore det meste av clustering software som finnes der ute, enten permanent eller for test og utvikling.

 

Et godt sted aa starte vil jo vare med aa lese litt om hva cluster computing er http://en.wikipedia.org/wiki/Cluster_(computing)

 

AAPEN kan vare en HA cluster, en load balancing cluster, eller en compute cluster, alt etter hva software som respektivt da blir lastet paa nodene.. dette inkluderer alt fra Microsoft Cluster Server (MSCS) til hadoop, kerrighed, beowulf, openmosix, Amazon EC2, og saa videre.

Kort sagt, AAPEN vil kjore en rekke forskjellige clusters paa samme tid..

 

Om AAPEN var en bil, ville det vaert ett merkelig sporsmaal aa stille:

"Hvor skal du kjore med den bilen der da?", kanskje en gang paa hytta (MSCS), en gang paa butikken (Hadoop), kanskje til tanta paa sorlandet (EC2) og saa videre. Paa samme maate som fordelen med en bil at den kan naa flere destinasjoner, kan AAPEN kjore en hel rekke forskjellige typer cluster software losninger, alt etter behov, og det er akkurat denne fleksibiliteten AAPEN har blitt designet for

 

 

I clustere er det grovt sett to typer clustere i bruk, det er SSI (Single System Image) der alle cpu'er og minne i systemet er samlet sammen til ett 'virituelt system' og alle disse ressursene er tilgjengelig og oppforer seg som om de skulle tilhore en og samme maskin. (tenk Cray XT, IBM superdatamaskiner, tenk $1m++, etc.)

 

Andre typen er saakalte paralelle clusters, disse krever at enten programvaren er "cluster aware" og kan allokere sine egne traader til arbeidsnodene (compute nodes). Eksempel paa slike type clusters er feks. Beowulf og lignende. Storparten av alle clustere i der ute i den vide verden i dag er slike former for clustere.

 

Problemet med SSI er at minne og cpu'er maa vare interconnected me saa lav latency at dette er praktisk mulig (ved bruk av enten Infiniband eller lignende internconnects med latency og baandbredde tilnaermet hastigheten paa minnet selv).

 

Paralelle clusters bruker vanlige interconnects som feks Ethernet (som er mange tusen ganger tregere (latency) og flere titalls ganger lavere baandbredde enn feks.infiniband). Derfor har det i praksis lite for seg aa kjore flere paralelle systemer sammen i ett "SSI", siden en cpu ikke vil ha direkte tilgang til minnet paa en annen node (raskere aa kjore traaden lokalt enn aa laste opp minnet og saa kjore paa en annen node etc.) Problemet med Paralelle clusters er at software maa vare "cluster aware". 'Cant eat your cake and have it too', som det heter

 

Wikipedia, disse topics'ene kan vare ett bra sted aa starte:

http://en.wikipedia.org/wiki/Computer_cluster,

http://en.wikipedia.org/wiki/Single_system_image,

http://en.wikipedia.org/wiki/Distributed_computing,

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

http://en.wikipedia.org/wiki/Symmetric_multiprocessing,

http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access,

 

MvH

[infected]

[weebl]

ser du har en forkjærlighet for "sukkerbiter" når du ordner kabling osv og det er sikkert veldig greit på prosjekter som er mye i endring osv.

 

men har det ikke vært likere å lodde sammen kablene? spesielt mtp airflow og over tid så må/bør jo koblingsklemmer etterstrammes da kabler har en styggg tendens til å løsne.

[[Infected]]

ser du har en forkjærlighet for "sukkerbiter" når du ordner kabling osv og det er sikkert veldig greit på prosjekter som er mye i endring osv.

 

men har det ikke vært likere å lodde sammen kablene? spesielt mtp airflow og over tid så må/bør jo koblingsklemmer etterstrammes da kabler har en styggg tendens til å løsne.

 

Lodding er gjort der det er hensiktsmessig aa gjore dette, er flere dusin loddinger i prosjektet ogsaa, men paagaa at strommene i stystemet er saa hoye, maa man bruke industri solder, noe som igjen betyr svaert hoye temperaturer paa bolten (maa bruke butanbrenner) og dette stiller veldig hoye krav til kvaliteten av hver eneste lodding.. (pga temperaturer og rating) saa kort sagt med tanke paa ledningsdimensjonene og typen kobber i bruk er ikke det aa lodde sammen ledningene hensiktsmessig ei heller fordelaktig her.

 

Luftflyt i denne maskinen er ogsaa ulikt designet fra hvordan man ville bygget en feks I7 gaming rigg.. blir litt mye aa gaa inn paa dynamikken i dette akkurat her, men systemet er designet for konstant undertrykk (samme som de fleste rack servere er..) og noen ledninger foran viftene har saers lite relevans i en slik build.. Derfor har AAPEN samme svaket som de fleste servere, at kjolesystemet vil ikke virke skikkelig naar man fjerner lokket...

 

Alt dette er selvfolgelig testet og dokumentert til en akademisk standard

Samt at jeg har hatt hjelp av en rekke kompetente fagpersoner (sivil ingeniorer og phd's) naar jeg har gjort mine respektive valg.

 

MvH

[infected]

[weebl]

ok

 

kunne du kort fortalt forklare hvorfor rackservere har undertrykk og ikke overtrykk som en desktop gjerne har?

[[Infected]]

ok

 

kunne du kort fortalt forklare hvorfor rackservere har undertrykk og ikke overtrykk som en desktop gjerne har?

 

Overtrykk er basert paa aa faa saa mye luft paa komponentene som mulig, effekten av kjolingen er luften som flyter over komponentene. Enkelt sagt betyr dette at det er mer luft som gaar inn i kabinettet enn hva som gaar ut (luften vil jo alltids finne veien ut uansett, enten det eller kabinettet vil blaase seg opp som en ballong ) Siden luften blir blaast paa komponentene er det jo da ikke bra aa ha ting i veien som 'deflecter' denne strommen for den treffer komponenten... som feks kabler eller kort eller etc.

 

Servere bruker generelt undertrykk, det vil si at det er flere vifter som trykker luften ut av kabinettet enn hva som presser luften inn. Dette er gjerne gjort naar man vil ha en vifte til aa kjole mer enn en komponent. (om man suger luft ut av ett tett kabinett, vil luften naturlig nok komme fra hullene som er beleilig plassert paa ett strategisk sted). Dell/HP/IBM etc. har ogsaa mange desktops med undertrykkskjoling (ofte ved aa bruke de plastgreiene som dekker over CPU'en)

 

Her er ett eksempel paa hvordan Juniper bruker undertrykk til aa presse luften fra front, over chipssett og gjennom cpu'en (se paa sidene av radial-viften og "tunnelen" fra cpu og bak til viften). Naar jeg aapner dekselet vil luften ta den enkle veien rett i viften, men naar lokket er paa, vil luften komme forfra.. og flyte over chipssettet, gjennom cpu'en og etc.

 

 

Siden luften blir dratt ut av kabinettet vil det oppstaa undertykk og luften vil naturlig finne den enkleste veien aa utjenve dette.. derfor ikke relevant for kjoling av cpu at det ligger noen PSU kabler "i veien" for luften. Luften vil ikke 'deflecte' siden den ikke har noen vei aa gaa utover den veien den skal..

 

 

Forovrig bruker AAPEN baade undertrykk og overtrykk, kabinettet vil alltid holdes ved konstant undertrykk siden flere vifter trekker luft ut enn hva som blaaser inn, samt at CPU'ene har sin egen vifte som da bruker denne luften som konstant gjennomstrommer til aa kjole cpu'ene og chipssett.

 

Dette er veldig grovt seff, men haaper prinsippet ivertfall gir mening

 

 

Om du synest AAPEN ser ulogisk ut, ta en liten titt paa hvordan en IBM IntelliServer ser ut paa innsiden

 

MvH

[infected]

Endret 13. august 2011 av [Infected]

[kpolberg]

Se der, infiniband, som interconnect. Ikke værst, hvilken switch har du gått for? Legger du på IP over IB?

[[Infected]]

Se der, infiniband, som interconnect. Ikke værst, hvilken switch har du gått for? Legger du på IP over IB?

 

Har ikke lyst aa gaa inn paa eksakt hva modell jeg har valgt enda, det kommer senere men kan si saa mye at den er fully managed og fra en av de aller mest etablerte og respekterte merkene innenfor IB, og har en total bi-directional fabric baandbredde paa 960gbit/s

 

MvH

[infected]

[kpolberg]

Trenger du båndbredden IB tilbyr, eller er det latency, som har innvirkning på oppgavene clusteret bearbeider?

 

10G har i endel tilfeller vist seg å være endel billigere, så lenge oppgavene som skal kjøres ikke er avhengig av lav latency.

[[Infected]]

Well spotted

 

Latency er nok den mest sentrale aarsaken til at jeg har valgt IB, selv om baandbredden i seg selv selvfolgelig ikke er noe aa forakte En annen aarsak er ogsaa at jeg har diverse andre planer paa gang der en ren fabric implementasjon definitivt ikke er aa forakte..

 

Stemmer nok at 10GB Ethernet ville vaert baade vensentlig billigere og ikke minst langt enklere aa ha med aa gjore, men IB er IB, og IB != ethernet

 

MvH

[infected]

[kpolberg]

Hehe, det vet jeg alt om...Trenger ikke akkurat gå inn på detaljer, IP over IB er forøvrig ett kapittel i seg selv...

 

Hvilket køsystem er det planlagt å bruke? torque/pbs?

[[Infected]]

Hehe, det vet jeg alt om...Trenger ikke akkurat gå inn på detaljer, IP over IB er forøvrig ett kapittel i seg selv...

 

Hvilket køsystem er det planlagt å bruke? torque/pbs?

 

Ja, si det du vi faar se hva som skjer naar det kommer til implementering av den delen av programvaren..

 

MvH

[infected]

[weebl]

Veldig intressant prosjekt dette egentlig, har ikke stor peiling på servere osv, er på nivået hvor jeg nå planlegger å sette opp en ubuntu filserver basert på et mini itx kort og en drøss med disker

kan ikke se for meg å ha et helt rack fult av ting liksom, men nå er jo dette nærmest en hobby da så blir noe annet.

 

men jeg kommer helt klart til å lage en worklog for min hovedoppgave i år, er framdeles innen computer science men på den andre siden av spekteret, her blir det laget en rover med gps navigasjon og kanskje et snev av autonomi.

[[Infected]]

Veldig intressant prosjekt dette egentlig, har ikke stor peiling på servere osv, er på nivået hvor jeg nå planlegger å sette opp en ubuntu filserver basert på et mini itx kort og en drøss med disker

kan ikke se for meg å ha et helt rack fult av ting liksom, men nå er jo dette nærmest en hobby da så blir noe annet.

 

men jeg kommer helt klart til å lage en worklog for min hovedoppgave i år, er framdeles innen computer science men på den andre siden av spekteret, her blir det laget en rover med gps navigasjon og kanskje et snev av autonomi.

 

+1 for GPL og Open Hardware

 

MvH

[infected]