Implementasjon av et Beowulf PC kluster

Innledning

Beowulf var navnet på en legendarisk helt fra 1600-tallet som frigjorde et helt folk fra et terroriserende monster med navnet Grendel. Navnet Beowulf er brukt som en metafor innenfor en ny strategi i en verden av superdatamaskiner. Billig teknologi innenfor massemarkedet benyttes for å takle høye tidskostnader og hardware kostnader for forskere og ingeniører.

Hva er et Beowulf PC kluster?

Billige komponenter (mikroprosessorer, hukommelses brikker, input/output (I/O) kontrollere og hovedkort med tilhørende mikrochips) som utgjør en PC gjør det mulig for individer med lav økonomi å bygge en nokså brukbar superdatamaskin med stor regnekraft.

Et Beowulf kluster inneholder fra noen få noder (PCer) til flere 100 stk., og kan oppnå hastigheter fra noen 100 Megaflops til flere titalls Gigaflops. De som benytter seg av slike klustere er stort sett universiteter, nasjonale laboratorier, industrielle konsern, nasjonale regjeringer og mange mindre firmaer. F.eks. verdens billigste superdatamaskin finner man i Oak Ridge National Laboratory i USA [3].

Metaforen Beowulf [4] ble tatt i bruk i et prosjekt ved Center of Excellence and Information Sciences (CESDIS) ved NASA-Goddard Space Center i Maryland, USA av sjefsforskeren dr. Thomas Sterling i 1994. Forskeren Donald Becker skrev de nødvendige nettverksdriverne for Linux [5]. NASA har i stor grad bidratt til at Linux brukere verden over nå kan bygge sin egen superdatamaskin med svært lave kostnader.

I 1997 kom den første dedikerte Linux Beowulf distribusjonen med navnet Red Hat [6] Extreme Linux. Extreme Linux [7] er i dag mer eller mindre navnet på en organisasjon som arbeider for å gjøre Linux bedre for forskermiljøer, som benytter seg av superdatamaskiner til kraftige beregninger (simuleringer eller håndtering av tunge grafiske systemer).

Hva er forskjellen mellom et Beowulf PC kluster og et COW?

I et COW blir all aksess til klient nodene utført via fjern oppkoblinger fra server node, dedikert konsoll node eller en seriell konsoll. Siden det heller ikke er en nødvendighet for klient nodene å aksessere maskiner utenfor klusteret (eller fra maskiner utenfra til klient nodene i klusteret), så er det vanlig praksis å gi nodene private IP adresser i adresse områder som f.eks. 10.0.0.0/8 eller 192.168.0.0/16 (RFC 1918) [8]. Vanligvis er det kun server noden som er tilkoblet resten verden vha. et ekstra nettverkskort.

Klusteret kan stort sett være totalt blottet for en del aspekter innen sikkerhet da et ekte Beowulf PC kluster benytter seg av firewall teknologi. Det er også normalt å unnlate sekundære lagringsmedier i klient nodene slik at de får sine system- og programfiler fra serveren ved oppstart over nettverket. På denne måten vil et Beowulf PC kluster fra utsiden se ut som kun en stor superdatamaskin når klient nodene er igang med å dele en større arbeidsoppgave seg imellom, f.eks. et parallelt simuleringsprogram av et biosystem.

En vanlig måte å aksessere systemet på er å logge seg på serveren direkte på konsollet eller via secure shell, telnet eller remote login fra en arbeidsstasjon. Med en egen DNS (Domain Name System) server kan man sette opp klusteret slik at når brukere logger seg på systemet, vil de havne på tilfeldige noder i klusteret (fordelen er en bedre lastfordeling for systemet). De kan så benytte seg av regnekraften alle nodene tilbyr vha. parallell/kluster software som MPI [9] eller/og PVM [10].

I de fleste tilfeller blir COW benyttet til parallelle beregninger over natten og i helger (på tids-punkter hvor brukerene normalt ikke benytter seg av arbeidsstasjonene til daglig arbeide. På denne måten kan man utnytte CPU tid på en økonomisk måte. Beowulf systemer derimot er dedikert til parallelle beregninger og optimalisert for dette formålet. Forholdet mellom pris og ytelse er mye bedre, siden klusteret er bygd opp av "hyllevare" komponenter, og at mye av programvaren et slikt kluster kjører hovedsaklig er gratis. Et Beowulf PC kluster skal ha evnen til å kunne kamuflere seg som kun en stor superdatamaskin.

Beowulf PC kluster arkitektur

En enkel og grei måte å beskrive en Beowulf PC kluster arkitektur på, er å benytte et eksempel som ligner på en 100% riktig konfigurert Beowulf kluster, men som systemadministratorer kanskje kan kjenne seg igjen i. DEC Alpha undergraduate computer laboratory ved the Faculty of Sciences, USQ, Australia har en server med navn Beldin og klient maskinene blir kalt Scilab01, Scilab02, Scilab03 og opp til Scilab20. Alle klientene har en lokal kopi av Digital Unix 4.0 operating system installert, men får sine hjemmeområder (/home) og /usr/local fra serveren via NFS [11] (Network File System). Hver klient får tilgang til serveren og til alle de andre klientene vha. /etc/hosts.equiv filen. Dette betyr at alle klientene kan eksekvere et remote shell på de andre maskinene. Server maskinen kjører også en NIS server [12] (Network Information Server) for hele laboratoriet, slik at konto informasjon blir den samme på alle maskinene. En bruker kan altså sitte ved maskinens Scilab02 konsoll, og få det samme oppsettet som om han var logget på serveren eller Scilab15.

Årsaken til at alle klientene har den samme "look and feel" er at operativsystemet er installert og konfigurert på samme måte på alle maskinene, og at brukerens /home og /usr/local områder ligger fysisk på serveren, og blir aksessert av klientene vha. NFS.

Det samme prinsippet benyttes på informatikk avdelingens kluster med navn Sleipner [13]. Dette er et kluster som består av åtte maskiner med navn Node1.sleipner til Node8.sleipner. Node1.sleipner er serveren og Node2.sleipner til Node8.sleipner er klientene. Klientene får sine filsystemer og brukerinformasjon tildelt av node1’s NFS server og NIS server.

System design av et Beowulf PC kluster

1. Disk

   Hvis man velger diskløse klienter vil klientene få sine filer fra serveren. Fordelen er enklere administrasjon og fleksibilitet når det gjelder å legge til nye noder. Ulempen er økt NFS trafikk over nettet, og et mer komplekst server oppsett. Diskløse klienter må bootes fra floppy disk eller en bootROM Ethernet kort. Diskløse klienter er den konfigurasjonen som kommer nærmest en Beowulf arkitektur.

   Velger man å ha disk på klientene kan man velge å gjøre en full installasjon eller installere bare det aller nødvendigste for å få klientene opp på beina. Deretter oppkobles viktige partisjoner fra serveren. Fordelen med å installere mest mulig software lokalt på klientene er liten NFS trafikk og høyere kalkulasjons ytelse. Ulempen er mer administrasjon og vedlikehold. For små klustere er denne type konfigurasjon veldig vanlig.

2. Deling av filer

   Standard NFS konfigurasjon er som regel den mest vanlige metoden for å dele filer til klientene. Desverre så er det slik at NFS har en del ulemper når det gjelder dataoverføring og sikkerhet. En bedre løsning er distribuerte filsystemer som eksisterer på multiple noder. Det finnes mange varianter, og en av de som finnes for bl.a. Linux heter Coda File System [14]. Coda har gode egenskaper som passer i et Beowulf PC kluster når det gjelder skalerbarhet.

3. Hukommelse

   Valg av mengden hukommelse er en av de viktigste oppgavene når det gjelder design av et Beowulf system. Hvis man ikke har nok hukommelse til å utføre viktige kalkulasjons-oppgaver eller benytter dårlig hukommelseshardware, så vil man minste ytelsen (verdifull eksekveringstid) f.eks. pga. mye swapping av data til og fra disk. Swapping av data er noe man ikke vil ha! Hvis hukommelsen ikke har god nok håndtering av bitfeil i hardwaren, så sitter man med en ganske så verdiløs kjempekalkulator til rådighet. Kvalitet og kvantitet er viktig når det gjelder valg av hukommelse. Hvis man har en rask CPU kjørende på en rask buss, så er det som regel hukommelsen som vil være flaskehalsen i systemet. Man bør velge minimum 16ns SDRAM.

4. CPU (mikroprosessor)

   Det er stort sett to valg man har av CPU familier: Intel x86 og DEC Alpha systemer. Intel er det man kommer nærmest som billig "hyllevare" produkt, fordi Intels instruksjonsett støttes av flere CPUer som AMD og Cyrix. DEC Alpha er dyrere pris fordi den ikke har tilsvarende konkurrenter, men dens ytelse er blant de beste. P-II og P-III er de prosessorene som anbefales da de er gode til å håndtere flyttallsoperasjoner.

   En annen viktig faktor som er verdt å merke seg er cache størrelsen assosiert med prosessoren. Jo større cache, desto raskere dataprosessering får vi.

   I stedet for å kjøre en CPU pr. node kan man i stedet bruke Symmetric Multiprocessor (SMP) hovedkort med to eller flere CPUer. Dette er svært vanlig i Beowulf systemer. Hovedfordelen er lavere kostnader pr. ytelse, og større kommunikasjonshastigheter mellom to eller flere prosessorer på samme kretskort. Bygger man et større kluster så er det mye hardware kostnader å spare ved valg av SMP hovedkort. F.eks. med to prosessorer i en node så halverer man klusterets størrelse og tilnærmet det samme når det gjelder kostnader.

   Det er svært viktig å ha nok CPU sykluser til å takle tunge NFS last, hvis klusteret er basert på diskløse klienter. I tillegg, hvis server noden benyttes av mange brukere (dvs. at brukere ikke spres utover klusteret vha. en godt konfigurert DNS server), kan det bli noe kritisk med ytelsen.

5. Nettverket

   100 Mbps switched full duplex Ethernet er det mest vanlige nettverket brukt i et Beowulf PC kluster. Et svitsjet Ethernet nettverk gir den fordelen, som et vanlig Ethernet nettverk ikke har, at båndbredden mellom to vilkårlige noder tilkoblet svitsjen er dedikert.

   Som tidligere nevnt benyttes det som oftest private IP adresser i et Beowulf nettverk. Fordelen er bl.a. at bak firewall’en trenger man ikke å bekymre seg så mye om data-sikkerheten til klientene, Beowulf klusteret ser faktisk ut som kun en datamaskin og du sparer mange offentlige IP adresser. Den eneste noden som faktisk har en "ekte" IP adresse er server noden. Server noden har fysisk to nettverkskort (eth0 og eth1), hvor firewall støtte i Linux kjernen og firewall konfigurasjonen bestemmer hva som slippes igjennom til klient nodene av nettverkspakker.

   

6. Programvare og distribusjon

   Open source OS er en viktig ingrediens for et Beowulf system. Linux, med monolitisk kjerne, multitasking support, multiuser support, virtuell hukommelse og demand paging, er et POSIX [15] kompatibelt, fritt tilgjengelig og svært stabilt operativsystem. OpenBSD og FreeBSD benyttes også, men Linux er den mest populære for Beowulf systemer.

   Den mest vanlige Linux distribusjonen på et Beowulf PC kluster er Red Hat Linux. Den er enkel å installere og er tilgjengelig gratis via FTP. En av de store fordelene med å benytte Red Hat Linux er dens dedikasjon til server miljøet, og det faktum at den benytter seg av RPM [16] (Red Hat Package Manager) teknologi. RPM gjør det svært enkelt å installere, oppgradere og slette programvare som befinner seg på systemet. I tillegg så bør et Beowulf system ha MPI og PVM installert. Det finnes også en hel del Beowulf dedikert parallell software fritt tilgjengelig på nettet [17].

   Et Beowulf system bør også inneholde algoritmer for prosess emigrering og balansering av last, slik at en tungt belastet node kan fordele prosessene sine over til andre noder som har lite å gjøre. MOSIX [18] software er et slikt tiltak. MOSIX er software som kompileres sammen med Linux kjernen.

Konklusjon

Det er kun fantasien som bestemmer hvor stort et kluster skal være. Hardware og software oppgraderinger gjøres av brukeren eller den lokale administrator, og ikke av representanter fra diverse leverandører. Administrasjonen er stort sett ikke noe vanskeligere enn å administrere en helt vanlig Linux arbeidsstasjon.

Det er svært viktig å være klar over at ytelsen man får av et kluster er helt avhengig av hvordan parallell software er konstruert. Utnytter man ikke et Beowulf PC kluster vha. spesial software, så sitter man i prinsippet med en COW eller en NOW (Networks of Workstations).

Utfordringen blir for et slikt system å utvikle nye verktøy for effektiv håndtering av Beowulf, utvikle effektive skaleringsteknikker for å forbedre ytelsesmulighetene og utvikling av applikasjoner med avanserte latency-tolerant algoritmer. Beowulf prosjektet fra NASA har endelig gitt oss "vanlige" brukere en mulighet til å dele teknologi, resultater og metoder for en superdatamaskin med andre likesinnende.

Refereranser

[2] Open-source og GNU (GNUs not Unix), http://www.opensource.org/ og http://www.gnu.org.

[3] The Stone SouperComputer, http://www.esd.ornl.gov/facilities/beowulf/.

[4] The Beowulf Project at CESDIS, NASA, http://www.beowulf.org.

[5] Linux homepages, http://www.linux.org, http://www.linux.no, http://www.linux.com.

[6] Red Hat homepage. http://www.redhat.com

[7] Extreme Linux Community, "http://www.extremelinux.org

[8] RFC 1918, http://www.alternic.net/rfcs/1900/rfc1918.txt.html

[9] LAM/MPI (Local Area Multicomputer / Message Passing Interface), http://www.mpi.nd.edu/lam/

[10] Parallel Virtual Machine, http://www.epm.ornl.gov/pvm/pvm_home.html

[11] Network File System HOWTO (NFS HOWTO), Nicolai Langfeldt, http://www.linux-howto.com/LDP/HOWTO/NFS-HOWTO.html

[12] The Linux NIS(YP)/NYS/NIS+ HOWTO, Thorsten Kukuk, http://www.linux-howto.com/LDP/HOWTO/NIS-HOWTO.html

[13] Sleipner Beowulf Cluster, http://www.sleipner.hiof.no

[14] Coda advanced networked filesystem, http://www.coda.cs.cmu.edu

[15] POSIX, http://www.knosof.co.uk/posix.html

[16] RPM, http://www.rpm.org

[17] Beowulf resources (mange nyttige referanser), http://www.beowulf-underground.org

[18] Scalable cluster computing for Linux, http://www.cs.huji.ac.il/mosix

[19] Sterling, Salmon, Becker, Savarese, "How to Build a Beowulf", The MIT Press, 1999, ISBN 0-262-69218-X.

[20] Linux Parallel Processing HOWTO, Hank Dietz, http://www.linux-howto.com/LDP/HOWTO/Parallel-Processing-HOWTO.html

[21] Rajkumar Buyya, "High Performance Cluster Computing: Architectures and Systems", vol.1/2., Prentice Hall PTR, NJ, USA, 1999. http://www.dgs.monash.edu.au/~rajkumar/cluster/index.html