Design og implementation af klynge-løsning til biologisk forskning

Transkript

1 Design og implementation af klynge-løsning til biologisk forskning Skriftligt 2.dels projekt Datalogisk Institut Københavns Universitet (DIKU) Lars G.T. Jørgensen & Sidsel Jensen Marts 17, 2003 Resumé Dette projekt omhandler design og implementering af en klynge til brug for biologisk forskning. Projektet er blevet til i samarbejde med Center for Bioinformatik og Zoologisk Museum. Projektet er opdelt i tre faser, den første omhandler udarbejdelsen af en specifikation af klyngen, den anden fase omhandler inkøb af klyngen og den sidste fase omhandler opsætning og evaluering af klyngen. Resultatet af disse tre faser er en 240 maskiners klynge, kaldet BioCluster ( der snart er klar til at blive taget i brug. Klyngen vil kunne nedsætte databehandlingstiden for de to institutter betydeligt og derved fremme deres forskning.

2 Indhold 1 Indledning Organisatorisk setup Motivation for anskaffelse af klynge Definition af bioinformatik Klyngens arbejdsopgaver Grundlæggende molekylær biologi Biologiske termer Proteiner Proteinsyntese Sekvenssammenligning Parvis og multipel sekvenssammenligning Global og lokal sekvenssammenligning Mellemrumsproblemet Phylogenetik Analyse Programmerne Evolutionær matrix POY POY testdatasæt TNT NCBI BLAST BLAST testdatasæt Hidden Markov Models HMM testdatasæt Forundersøgelser Testmaskiner Målingsværktøjer Forsøg og resultater Valg af hardware Valg af CPU Varmeudvikling og strømforbrug Hukommelsesovervejelser Netværksteknologi Valg af disk Valg af server Opsumering over valg af hardware Valg af software Valg af styresystem Valg af filsystem Valg af installationssystem Jobstyringssoftware Biblioteker og applikationer i

3 INDHOLD INDHOLD 6 Setup og design af klyngen Installationsystemet Navngivning af maskiner Netværksstrukturen De fysiske rammer Konfiguration af server Det endelig setup Test og Evaluering af klyngen Fejl og mangler MTBF begrebet Linpack Test af programmerne BLAST POY HMM Opsummering på testkørsler Konklusion 30 9 Perspektivering Litteraturliste 32 A Kørselsudskrifter fra forundersøgelser 34 A.1 Testkørsel af POY A.1.1 POY på testmaskine A.1.2 POY på testmaskine A.1.3 POY på testmaskine A.2 Testkørsel af BLAST A.2.1 BLAST på testmaskine A.2.2 BLAST på testmaskine A.2.3 BLAST på testmaskine A.3 Testkørsel af HMM A.3.1 HMM på testmaskine A.3.2 HMM på testmaskine A.3.3 HMM på testmaskine B Kravspecifikation på klyngecomputere 39 B.1 Computere C Oversigt over tilbud 41 D Dell tilbud 43 E El tilbud 49 F Kølings tilbud 52 ii

4 INDHOLD INDHOLD G Switch tilbud 57 H Linpack konfigurationsfil 63 H.1 Vores HPL.dat H.2 Horseshoes HPL.dat iii

5 1 INDLEDNING 1 Indledning Dette er et skriftligt 2.dels projekt, skrevet på Datalogisk Institut Københavns Universitet (DIKU) i perioden september marts Projektets formål er at analysere et antal programmer specificeret af de involverede forskere fra Center for Bioinformatik og Zoologisk Museum og, udfra disse at designe en klyngecomputer. Herefter er projektets formål at implementere den i designfasen skitserede klynge og evaluere de omtalte programmers performance på klyngen. Et delmål er derfor at måle klyngens performance med benchmark programmet Linpack, som benyttes til performance målinger for TOP500 Supercomputere. Samtidig udvikles et dokumentations website, hvor information om klyngen og dens setup vil kunne forefindes: ( Projektet har arbejdet under en deadline, der hed udgangen af år 2002, for købet af computerne til klyngen. Projektet er derfor naturligt faldet i 3 faser indenfor den afsatte tid. Hvor fordelingen har været 1/3 tid til analyse og 1/3 tid til design/indkøb og den sidste trediedel til implementering, herunder istandsættelse af serverrum til klyngen. Undervejs i projektet var vi i november på en en-dags studietur til Odense, hvor vi snakkede med Brian Vinther, som er ansvarlig for Syddanske Universitets (SDU) klynge Horseshoe, der er sammenkoblet med en tilsvarende klynge på Danmarks Tekniske Universitet (DTU) i Lyngby. Projektet er undervejs blevet udvidet fra det oprindelige projekt, som kun omhandlede en klynge til det nyoprettede Center for Bioninformatik, til også at indeholde en klynge til Zoologisk Museum. Zoologisk Museum henvendte sig til Eric Jul i DIKUs Distlab gruppe for at få hjælp til deres projekt. Vi blev så naturligt tilkoblet deres klyngeprojekt, da vores vejleder Jørgen Sværke Hansen snakkede sammen med Eric Jul. Projektet er derfor vokset til dobbelt størrelse, i forhold til hvad vi havde forestillet os. 1.1 Organisatorisk setup Den klynge, der er tale om i denne rapport, er altså finanscieret af to selvstændige institutter på København Universitet: Center for Bioninformatik og Zoologisk Museum. En trediedel af pengepuljen på 1,2 million kroner kom fra Center for Bioinformatik og de sidste to trediedele kom fra Zoologisk Museum. Det blev ret hurtigt afgjort på et fælles møde, at der som minimum skulle laves en fælles indkøbsaftale mellem de to institutter. Center for Bioinformatik er et lille og helt nyoprettet institut på København Universitet og bor derfor pt. i nogle lokaler, som er udlånt af Zoologisk Institut. I løbet af de næste 2-3 år, vil der blive bygget et nyt center i universitetsparken, som skal huse uddannelsen. Det var derfor et krav fra starten, at klyngen skulle kunne deles op i to seperate dele, såfremt Bioinformatik skulle flytte lokaler. Dette har dog relativt lange udsigter, set i forhold til klyngens formodede levetid, så det faldt naturligt at spørge Zoologisk Museum, om de havde mulighed for at huse hele klyngen i det serverrum, som de havde afsat til projektet. 1

6 1 INDLEDNING 1.2 Motivation for anskaffelse af klynge Zoologisk Museum, havde dog på det givne tidspunkt ikke et rum, som var indrettet til dette formål. Det blev derfor en del af projektet at få skabt et serverrum, som kunne huse klyngen under de rette forudsætninger, så som pladsforbrug, el og køling. Dette arbejde stod Zoologisk Museums System Administrator Claes Petersen i høj grad for at organisere, og projektet her er blevet til med en stor indsats fra hans side. Vi vil yderligere gerne takke John fra Zoologisk Museum og Ciprian fra GBIF for deres hjælp i projektet. 1.2 Motivation for anskaffelse af klynge Forskerne på Zoologisk Museum, anført af Nikolai Sharff, havde et meget stærkt ønske om en klynge, da de allerede idag benytter sig af en klyngecomputer på American Museum of National History, som de betaler for. Ved anskaffelsen af deres egen klynge, ville de dermed kunne spare de penge, der lå i købet af computertid i USA. Der var derfor ikke nogen tvivl hos Zoologisk Museum om, at de ønskede en klynge, der så vidt muligt matchede den klynge, de allerede havde vendt sig til at benytte. Anders Krogh, centerleder fra Center for Bioinformatik, ønskede ligeledes en klynge af forskningshensyn. Klynger er blevet specielt populære indenfor bioninformatik, da de prismæssigt er meget konkurrencedygtige, specielt set i forhold til de traditionelle supercomputere som f.eks. Blade Servers eller Sun Fire familien. 10 ud af 10 af verdens hurtigste computere er idag klynge-computere. Meget forskning indenfor lige præcis bioinformatik bliver dog udført på desciderede compute farms idag, da de fleste bioinformatik algoritmer er meget nemme at parallelisere. 1.3 Definition af bioinformatik Bioinformatik kan defineres på følgende måde: De forskellige matematiske, statistiske og computerbaserede beregningsmæssige metoder, der stræber mod at løse biologiske problemer ved hjælp af DNA og aminosyre sekvenser og den dertil relaterede information. Bioinformatik er et relativt nyt forskningsområde, som blev skabt i 1980 erne, hvor man opdagede, hvad man kunne benytte computere til indenfor det biologiske forskningsområde. Der er fortsat flere forskellige måder at definere bioinformatik på. Generelt gælder det, at bioinformatik bygger ovenpå den eksisterende viden om biologi. 1.4 Klyngens arbejdsopgaver Vi ønskede, som noget af det første, på et møde med forskerne, at få fastlagt klyngens fremtidige arbejdsopgaver. Vores umiddelbare opgave var nemlig at finde et udsnit af de applikationer, forskerne ønskede at benytte, som tegnede en profil for klyngens brug. Disse arbejdsopgaver ville give os nogle kendetegn for de kerneapplikationer, de to grupper af forskere har til fælles. Det viste sig ret hurtigt, at begge grupper hovedsagligt arbejdede med DNA og protein sekvenser. Det kunne f.eks. være at finde relationen mellem to organismer ud fra deres arvemasse. 2

7 2 GRUNDLÆGGENDE MOLEKYLÆR BIOLOGI 2 Grundlæggende molekylær biologi Vi vil her kort starte med at introducere lidt grundlæggende molekylær biologisk viden. Denne viden vil gøre det langt nemmere at forstå de programmer, der skal køre på klyngen, men også vise lidt om, hvad det er for nogle forskningsområder, klyngen skal benyttes til. 2.1 Biologiske termer Hver celle i en organisme har nogle få meget lange DNA (eng. deoxyribonucleic acid) molekyler. DNA er opbygget som en dobbelt- kæde opbygget af simplere molekyler. En enkelt af disse kæder kaldes for en streng. Hvert af de lange DNA molekyler kaldes et kromosom. Hvert kromosom kan indeholde flere forskellige gener. Et gen er kendetegnet ved at være en sammenhængende klump indefor kromosomet. Mellem generne findes det man kalder ikke-kodende DNA (eng. junk DNA). Det er fornyligt blevet estimeret, at helt op til 90% af DNA en i de menneskelige kromosomer består af ikkekodende DNA. Indenfor kromosomet findes derfor desciderede start og stop codon er, som beskriver hvor vi skal læse fra og hvortil. Dette kaldes en open reading frame forkortet ORF. DNA er opbygget af nitro-genererede basepar. Der findes fire forskellige baser: Adenin, Guanin, Thymin og Cytosin. Disse baser komplementere hinanden. Adenine binder altid til Thymin og Guanin binder altid til Cytosin. Den sidste base Uracil, der findes i RNA, binder også til Adenin. Et gen siges at kode for et protein. Proteiner er opbygget af kæder af aminosyrer. Aminosyrer er kroppens mindste byggeblokke. Der findes 20 aminosyrer, som normalt indgår i proteiner i kroppen Proteiner Proteiner er en del af kroppens biologiske proces, tilstedeværelsen eller manglen på et protein kan påvirke kroppen i meget høj grad. Derfor er det uhyre intressant rent forskningsmæssigt at kortlægge, hvilke proteiner der er tilstede, og hvilken funktion de har. Da vi alle formodes at afstamme fra den samme forfader, er der meget arvemasse, der stadig er bevaret fra dengang. Hvis to proteiner i to vidt forskellige organismer (men med en fælles stamfader), har den samme funktion, form eller bindingssted, kaldes de for homologer. Det vil sige, at hvis vi kan finde et gen i en anden organisme, der modsvarer et gen i mennesket, kan vi lige så vel studere det i den pågældende organisme og dermed forudsige, hvordan det vil påvirke et menneske Proteinsyntese Proteinsyntese er den process i kroppen, der sørger for automatisk at generere de forskellige proteiner, kroppen har brug for. 3

8 2 GRUNDLÆGGENDE MOLEKYLÆR BIOLOGI 2.1 Biologiske termer Figur 1: Overblik over protein syntese processen. Ved hjælp af et start codon genkender cellemekanismen starten af et givet gen, og der tages en kopi af genet i form af et RNA molekyle. Den resulterende RNA kaldes for messenger RNA eller blot mrna. mrna en er fuldstændig identisk med DNA en bortset fra at basen Thymin (T) bliver erstattet med Uracil (U). Fordi RNA er enstrenget og DNA er dobbelt-strenget, vil den producerede mrna kun være identisk til den ene af strengene i DNA en. Denne proces kaldes for transskription. Selve proteinsyntesen foregår inden i en cellestruktur kaldet ribosomet, som består af rrna og proteiner. Ribosomets funktion minder om et samlebånd. Som input tages det før omtalte mrna molekyle, samt en anden form for RNA molekyle kaldet transfer RNA eller blot trna. trnaen er det molekyle, som rent faktisk implementerer den genetiske kode i den process, som kaldes translation. trnaet skaber forbindelsen mellem et givet codon og den specifikke aminosyre, som codonet koder for. Mens mrnaet passerer igennem ribosomet, binder trnaet til mrnaet med den korrekte aminosyre. Et passende enzym sørger for at katalysere processen, således at aminosyren forlader trna molekylet og istedet binder til proteinet. Når et STOP codon optræder, vil trnaet ikke associere nogen aminosyrer til mrnaet, og syntesen stopper og mrnaet bliver frigivet og nedbrudt til ribonucleotider af cellemekanismerne i kroppen. Disse genbruger kroppen til at skabe anden RNA. 4

9 2 GRUNDLÆGGENDE MOLEKYLÆR BIOLOGI 2.2 Sekvenssammenligning 2.2 Sekvenssammenligning Sekvensering er den process, hvormed man ønsker at opnå information om en given DNA strengs sammensætning af base-par sekvenser. Et menneskeligt kromosom indeholder omkring 10 8 base-par. De største stykker af DNA, som kan sekvenseres i et laboratorie er omkring 700 basepar langt. Dette betyder, at der er et hul i størrelsesordenen 10 5 mellem den skala for, hvad der kan sekvenseres og et kromosoms størrelse. Det er derfor uhyre interessant at kunne nedbryde sekvenseringen i mindre dele og undersøge disse smådele hver for sig for derefter at samle dem til større stykker igen. Sekvenssammenligning (eng. alignment), er en af de allervigtigste primitiver indenfor bioinformatik. Det fungerer, som basis for mange andre langt mere komplekse manipulationer. Groft sagt handler sekvenssammenligning om at afgøre, hvilke dele af en given DNA eller proteinsekvens der er ens og hvilke dele, der ikke er ens Parvis og multipel sekvenssammenligning Da proteiner bliver kodet ud fra arvemassen, kan vi, ved at finde ligheder i den, forudsige funktionen af et protein. Da DNA og proteiner kan repræsenteres som strenge, kan ligheder mellem deres funktion ofte findes som ligheder i strukturen ([protein]). En parvis sekvenssammenligning er, som navnet antyder, en sammenligning mellem to sekvenser bestående af det samme alfabet og typisk nogenlunde samme længde. En multipel sekvenssammenligning er en sammenligning mellem mere end 2 givne sekvenser Global og lokal sekvenssammenligning Både indenfor parvis, såvel som multipel sekvenssammenligning, skelner man mellem lokal og global sammenligning. Global sammenligning består i at matche to hele strenge imod hinanden og finde den bedste sammenligning. Man kan indsætte mellemrum (eng. a gap) i strengene for at de matcher bedre. En lokal sammenligning består i at matche to givne del-strenge imod hinanden på samme måde Mellemrumsproblemet En ting, der skal tages højde for i de videnskablige beregninger er muligheden for mellemrum i de to givne sekvenser, der skal sammenlignes. Der er forsøgt forskellige tilgangsmåder til at løse dette problem. En af måderne, at løse det på, er at tilføje et mellemrum, som et bogstav til alfabetet, men med en passende straf, så algoritmen derved tvinges til at prøve at undgå dem. For at finde den bedste sammenligning mellem to strenge, taler man om den optimale sammenligning. Det kan godt eksistere flere optimale sammenligninger. I nogle tilfælde snakker man om Træ-sekvenssammenligning (eng. tree alignment). Dette skyldes at man nogle gange arbejder på et evolutionært træ for den givne sekvens. Træ-sekvenssammenlignings problemet er NP hårdt. Det eksisterer en algoritme, som 5

10 3 ANALYSE 2.3 Phylogenetik finder den optimale løsning, men denne er eksponentiel i antallet af sekvenser, der skal sammenlignes. 2.3 Phylogenetik Forskernes fra Zoologisk Museum arbejder bl.a. med evolutionære træer og Phylogenetik. Phylogenetik er et område indenfor biologien, som behandler relationerne mellem forskellige organismer. Det inkluderer kortlæggelsen af disse evalutionære relationer, samt studier af anledningen til disse mønstre. Indenfor dette område, taler man om phylogenetiske træer, som bl.a. bygger på den føromtalte træsekvenssammenligning. 3 Analyse I det følgende afsnit beskriver vi de applikationer, der skal benyttes på klyngen, samt undersøger deres virkemåde vha. forskellige forundersøgelser. 3.1 Programmerne Det følgende er en beskrivelse af de 4 programmer, som forskerne helt sikkert kommer til at køre på klyngen. Programmerne POY og TNT skal bruges af forskerne fra Zoologisk Museum, mens BLAST og Hidden Markov Models (forkortet HMM er) skal bruges af Center for Bioinformatik. POY og TNT er begge programmer, der laver multipel alignment ved brug af en træbaseret model. Dette gør det muligt for forskerne at finde relationer mellem forskellige organismers udvikling. BLAST og HMMer foretager begge en databasesøgning, hvor de forsøger at finde sekvenser, der ligner den givne forespørgselssekvens Evolutionær matrix En given sekvens kan ændre sig over tid vha. mutationer. Mutationer i arvemateriale er en naturlig del af evolutionen. Det vil sige, at en base eller en aminosyre over tid ændres til en lidt anden. Da der ikke er lige stor sandsylighed for, at alle par af aminosyrer eller baser kan muteres til hinanden, er der udviklet nogle forskellige matricer, der beskriver sandsynligheden for, at en base ændrer sig over tid. Denne matrice efterligner dermed den process, som sker i naturen. Et eksempel på en sådan matrix er PAM250. Den beskriver sandsynligheden for mutationer over 250 generationer POY POY er en algoritme udviklet ved American Museum of Natural History af Ward Wheeler. POY er som nævnt tidligere et program, der benytter sig af træsammenligninger til undersøgelse af phylogenetiske træer. POY benytter en metode, der kaldes Parsimony til at opbygge disse træer. Begrebet Parsimony kan groft sagt oversættes med sparsommelighed. Tanken bag metoden er, at afsøge alle træer og for hver træ at beregne prisen for dem. Det billigste træ vil have en lav højde og så lille en afstand 6

11 3 ANALYSE 3.1 Programmerne mellem forældre og barn, som muligt. Den simpleste måde at udregne parsimony på, er som følgende (hvor C er prisen af træet) [binf, pp. 175]: Initalization: Set C = 0 and k = 2n-1 Recursion: If k is leaf noe: Set R_k = x^{k}_{u} If k is not a leaf node: Compute Ri, Rj for the daughter node i, j og k and set R_k = R_i \intersect R_j if the intersection is not empty, or else set R_k = R_i \union R_j and increment C Termination: Minimal cost of tree = C POY udfører en lidt anden form for multipel alignment. Det gør den, ved at finde det formodede træ, over de angive sekvenser og deres forfædre. Algoritmens fremgangsmåde, er at forsøge at finde fællesmængden mellem de to strenge og ud fra det, at danne en forfader. Hvis fællesmængden er tom, bruges foreningsmængden. Dette forsøges med de forskellige kombinationer, og POY forsøger derved at finde det træ med de fleste og bedste fællesmængder (se [poy]) POY testdatasæt Som testdatasæt har vi benyttet atpa, der indeholder ca. 438 taxa for det mitochondrionencodede gen atpa, der encoder α-delenheden af mitochondrial ATP syntese. Der er altså tale om et plante-gen TNT Programmet TNT (eng. Tree analysis using New Technology) er udviklet af argentineren Pablo Goloboff i 1999, der også har skrevet programmerne Nona (NoName) og PiWe (eng. Parsimony with Implied WEights). Pablo Goloboff besøgte Danmark i slutningen af februar i forbindelse med, at han skulle give undervisning på Botanisk Institut, og blev således den første person, der kom til at køre programmer på klyngen. Han var blevet kraftigt opfordret til at oversætte sine DOS/Windows programmer til UNIX, så de i fremtiden kunne køre på klyngen. Alle tre programmer: TNT, Nona og PiWe kan således nu køres på klyngen. TNT baserer sig på den samme metode (parsimony) som POY, men sigtet med TNT er kørsler på meget store datasæt f.eks taxa. TNT benytter sig af en søgestrategi, der er meget effektiv, som hedder parsimony ratchet. Tanken er, at man genvægter et tilfældigt sample fra sit datasæt, for derved at komme ud af et lokalt optimum, og søgningen kan fortsætte up-hill. Når man når til et nyt optimum, skifter algoritmen tilbage til den oprindelige vægtningsstrategi, og søgningen fortsætter. Fordelen ved denne strategi er, at de genvægtede hill-climbing cykler, bevarer nogle 7

12 3 ANALYSE 3.1 Programmerne af de originale phylogenetiske signaler samtidig med at tiden, der bruges på trinvis addition reduceres væsentligt (se [WEBTNT]). Programmet TNT er desværre fortsat et beta-program, og vi har derfor ikke kunnet køre programmet på en tilfredsstillende måde indenfor den afsatte tid. F.eks. kræver programmet et password udleveret af Pablo Goloboff, for overhovedet at kunne køre og give uddata NCBI BLAST Programmet NCBI BLAST (Basic Local Alignment Search Tool) [BLAST], stammer, som navnet indikierer, fra National Center for Biontechnology Information. BLAST er et af de allermest populære programmer indenfor biologisk forskning for tiden. Programmet er fra 1990, men det har gennemgået en del ændringer siden da, bl.a. i sekvenssøgningsdatabasens form. Der findes flere andre implementationer af BLAST end den NCBI distribuerer. Når BLAST skal søge i en database med sekvenser, gør den det på følgende måde: 1. Lav en liste over mulige HSP (High Scoring Points) ved at generere strenge, der giver en høj score ved sammenligninger med søgestrengen. 2. Brug disse HSPer til at søge i databasen vha. en tilstandsmaskine. 3. For alle hits udvid da resultatet, så det bliver en så stor match som muligt (vha. en tilstandsmaskine). Metoden BLAST baserer sig på de teoretiske resultater beskrevet i [statistics]. Disse resultater beskriver, hvordan det er muligt at, i stedet for at lave en præcis alignment ved hjælp af én sekvens, er det muligt at lave en række andre sekvenser, der giver en høj score ved sammenligning med sekvensen. Disse kandidater kan derefter bruges til at søge i databasen og finde sekvenser. De sekvenser, der bliver fundet ved denne søgning, har en høj sandsynlighed for at være dem, der ville findes ved en rigtig kørsel BLAST testdatasæt Som dataset bruger GenBank en database, hvis mål det er at indeholde alle sekvenser i eksistens. Da GenBank distribueres i FASTA formatet, så skal den først formateres og indekseres til at BLAST kan søge i den. Den oprindelige database er på ca. 8 Gb, men når den bliver formateret, fylder den kun ca. 2,6 Gb. Denne database indeholder kun information omkring DNA og RNA sekvenser, da det kun er det vi har valgt at søge på. En søgning efter en 700 basers sekvens, tager ca. 1,5 min. Det kan godt være, at det ikke lyder som et overvældende tal, men ofte forekommer det, at man skal søge med mange forskellige sekvenser i databasen. Efterbehandling af resultaterne fra en BLAST kørsel, tager typisk også lang tid Hidden Markov Models Metoden Hidden Markov Models (herefter forkortet HMM) er ikke unik for biologisk sekvenssøgning. Den bliver også brugt i mange andre sammenhænge. Skjulte Markov 8

13 3 ANALYSE 3.2 Forundersøgelser modeller beskriver en række tilfældige variable og deres indbyrdes relation. Det vil sige, at det er muligt at modellere forskellige mønstre i en sekvens. Træne modellen til at finde nogle bestemte sekvenser og derefter bruge den til at søge med. Forskellen mellem BLAST og HMM er, at i BLAST søges i sekvenser, mens man i HMM er søger i en model. BLAST er derfor god, hvis man allerede har den sekvens, man ønsker at finde, hvorimod HMM er er en mere generel metode, hvor det ikke gør nogen forskel, om sekvensen indeholder junk DNA HMM testdatasæt Som testdatasæt, har vi fået udleveret 451 sekvenser fra S. Pombe genomet. S. Pombe er en bestemt type gær, der har samme cellestruktur som mennesker. Gær bliver typisk brugt til biologisk forskning, da det er en éncellet struktur, der indeholder en cellekerne, og den er nem at dyrke, samt den er fuldt sekvenseret (hvilket skete i 2002). 3.2 Forundersøgelser Selv om man kan komme langt ved at se på forskellige hardware specifikationer, har vi også været nød til at lave nogle konkrete test-kørsler for at identificere, hvordan applikationerne reagerer i forhold til den valgte hardware Testmaskiner For at udføre vores forsøg brugte vi en række testmaskiner. Modeller og konfigurationer er noget spredt, alt efter hvilke maskiner vi har haft mulighed for at lægge beslag på til testen. Maskintype CPU RAM Disk 1 Intel Celeron 1 GHz 256Mb IDE 2 Intel Pentium4 2 GHz 512 Mb IDE 3 AMD Athlon XP ,5 GHz 512 Mb IDE 4 Dual Pentium III 1 GHz 1 Gb SCSI 5 Intel Pentium4 2.4GHz 512 Mb IDE Målingsværktøjer Vi var nødt til at finde nogle værktøjer, der kunne undersøge, hvordan de forskellige applikationer, der skulle køre på klyngen, opførte sig. De emner, der umiddelbart var interessante for os at se på, var hvilke behov applikationerne havde for forskellige faste ressourcer f.eks. CPU, RAM, disk og netværk. Der findes mange forskellige værktøjer til at undersøge et programs opførsel på en Linux maskine. De fleste benytter /proc-filsystemet til at læse information fra Linux kernen, men med disse værktøjer er det ikke muligt at undersøge specfikke hændelser på CPUen. Enten fordi informationen ikke er tilgængelig, eller fordi den ikke kan indhentes hurtigt nok. Derfor har vi set på kerneudvidelsen Perfctr, der er en del af 9

14 3 ANALYSE 3.2 Forundersøgelser Performance API (forkortet PAPI) værktøjerne. For at undersøge om et program brugte sin hovedvægt på CPU eller I/O brugte vi en kombination af to kommandoer, nemlig time og strace. time kan vise hvormeget tid en process bruger i kernen og hvormeget den bruger i brugertilstand. strace opfanger alle systemkald, som et program bruger og kan derefter udskrive en opsummering af antallet af de forskellige systemkald. Så for at undersøge forholdet mellem I/O og CPU forbrug, vil vi bruge time til at undersøge den totale køretid af programmet og strace til at undersøge hvormeget af tiden, der er blevet brugt på henholdsvis read og writes. Perfctr implementerer PAPI grænsefladen, der gør det muligt at undersøge et program, ved at tilføje specielle funktionskald. Men det er også muligt at undersøge et program uden at ændre i selve programmet. Det var bl.a. en af de ting vi ønskede at benytte, da vi har valgt at fastholde applikationerne og fremskyde en eventuel forbedring af dem til efter klyngen er opsat og kørende. Programmet, der blev benyttet til at undersøge programmerne var lperfex, der er en videreudvikling af et program, der følger med Perfctr. Lperfex starter en børneprocess, der kører det program, der skal undersøges, på en sådan måde at den overtager processens processblok. Dette gør at det er muligt, at konfigurere statusregistrene i processoren, køre programmet og derefter indsamle de informationer, der er blevet gemt i registrene. Programmet har symbolske konstanter for at definere nogle bitmasker, der programmerer registrene til at gemme de ønskede hændelser. Denne funktionalitet er desvære endnu ikke implementeret på Pentium 4 processoren (forkortet P4). Dette skyldes to ting: P4 har betydelig flere muligheder indbygget for selv at indhente status informationer end tidligere processorer, men den er også relativt ny. Vi var derfor nødt til at sætte os ind i, hvordan denne mekanisme er lavet, for at kunne programmere den. Vi vil her kort beskrive, hvordan den fungerer. Hændelsesmålingsmekanismerne i P4 er baseret på to typer af registre. Den ene type register bruges til at konfigurere hvilken type af hændelser (eng. Event Select Control Registers), der skal gemmes, mens den anden type benyttes til at konfigurere tællerne (eng. Counter Configuration Control Registers). Hver ESCR og CCCP er en del af en gruppe, der modsvarer en del af CPUen. Perfctr havde ikke understøttelse for konstanter defineret for disse registre, men den havde mulighed for at definere de bitmasker, der skulle gemmes i dem. Vores mål var derfor at finde den korrekte bitmaske, der ville konfigurere processoren til at gemme de hændelser, vi ønskede at undersøge. Et at de emner vi ønskede at få klarlagt, var hvorledes applikationerne forholdt sig til maskinernes Level 2 cache. Dette er en af de vigtige forskelle mellem high-end CPUer og desktop CPUer. Dette kan bl.a. ses på, at P4 har 512 kb L2 cache, hvorimod en Celeron kun har 128 kb L2 cache. Men de to arkitekturer er selvfølgelig også forskellige på mange andre punkter end lige cache. Generelt gælder dog, at hvis programmerne ikke kan finde ud af at benytte cache overhovedet, er det er det lige så hensigtsmæssigt at vælge en 10

15 3 ANALYSE 3.2 Forundersøgelser Figur 2: En oversigt over hændelsesmålingslogiken i en P4 Celeron-baseret løsning, som en Pentium4-baseret løsning. Hvis programmerne derimod udnytter cachen, er det et argument for at vælge en P4-baseret løsning. Da vi skulle måle P4s cache tog vi udgangspunkt i følgende eksempel af hvordan man måler level 1 cache misses med Perfctr. perfex -e 0x0003B000/0x @0x C --p4pe=0x p4pmv=0x1 some_program Ud fra [P4Spec, pp. B-37] kan man se, at den eneste forskel mellem at måle level 1 og level 2 misses, er at bit 1 istedet for bit 0 er sat i PEBS ENABLE. Så parameteren p4pe skal ændres for at måle level 2 misses Forsøg og resultater Vi udførte tre forundersøgelser. En test på maskine 1 og 2, til identifikation af Cache Level2 udnyttelsen, en simpel test på maskine 2, 3 og 4, vha. top programmet til identifikation af RAM forbruget og en test på maskine 3, 4 og 5 til identifikation af programmernes CPU og I/O mønstre. For at udføre undersøgelsen, installerede vi en alternativ kerne på maskine 1 og 2. Derefter kørte vi programmet POY og talte antallet af cachelinier, der blev læst ind og gangede dette med størrelsen på cache- linierne. Vores lille forsøg afdækkede, at den samme mænge data blev hentet fra lageret på begge typer af maskiner. Det vil sige, at applikationen POY ikke udnytter den større cache, der er tilrådighed på maskine 2. Man skal dog være opmærksom på at maskine 2 har en langt hurtigere hukommelsesbus end maskine 1. Resultatet af RAM testen afdækkede, at programmet POY brugte mindre end 256 MB RAM, når det blev kørt. BLAST derimod benytter RAM i forhold til Databasens 11

16 4 VALG AF HARDWARE størrelse. Dvs. RAM forbruget er relativt højt, når man kører BLAST på en enkelt computer, men når man kører BLAST på en klynge, deles databasen op i mindre bidder, der lægges ud på hver computer. Så, jo flere knuder BLAST køres på, jo mindre bliver RAM forbruget. Den sidste test er lidt sværere at konkludere noget specifikt på, da programmerne fordeler sig over et ret bredt spektrum. POY er mest CPU intensivt, mens BLAST er mest I/O intensivt. Programmet HMM placerer sig i begge ender af spektret, hvor træningsdelen er I/O intensiv, mens selve decodedelen er CPU intensiv. Hvis man skal sige noget generelt, kan man konkludere at vi har behov for begge dele. Der er derfor behov for en velafvejet klynge, hvor der er lige meget fokus på CPU og I/O. Resultatet af disse forundersøgelser blev at vi begyndte mere specifikt at formulere kravne til hardware, således at en kravspecifikation kunne udsendes til forskellige PC-leverandører. På baggrund af kravspecifikationen kunne vi indhente forskellige computertilbud, der nemt kunne sammenlignes. 4 Valg af hardware De fleste dele i en moderne computer forbedrer idag sin ydelse med et fast tidsinterval f.eks. får CPUer dobbelt så mange halvledere hver 18. måned. Et af de vigtigste krav, når man designer en klynge, er at finde ud af hvad den billigste hardware er, i forhold til ydelse og de krav, som applikationen stiller til hardwaren på grund af forældelsesfaktoren. 4.1 Valg af CPU Ved valg af CPU skulle vi afveje en prioritering mellem strømforbrug, hastighed og pris. De to leverandører af CPUer vi primært så på, var AMD og Intel. Hvis man kort skal beskrive dem, så har begge leverandører to typer af CPUer. En billig version med mindre cache og en dyr version med højere ydelse. Hos Intel er de to typer repræsenteret af Celeron, baseret på Coppermine (Pentium 3) og Pentium 4, baseret på Northwood II. Hos AMD hedder de to modeller Duron og Athlon. En gennemgående trend for alle leverandører er, at AMD er billigere per CPU end Intel, men de har desværre også et større strømforbrug. AMDs processorer er heller ikke gearet til at overleve en eventuel overophedning, hvorimod Intels CPUer har en indbygget sikkerhedsforanstaltning kaldet speedstep, der sørger for, at processoren clocker ned i hastighed. Dette sikrer, at CPUen ikke brænder sammen. Grunden til at vi har fokuseret vores interesse på disse typer af CPUer fra AMD og Intel er, at de fleste alternativer på ingen måde kan forsvares fra et økonomisk synspunkt. Alternativer, så som AI-64, PowerPC eller Alpha bliver ikke produceret i samme størrelsesorden som IA-32 maskinerne, selv om de på mange måder har mere tiltalende egenskaber. Ydelsen er ikke god nok til at opveje den prisforskel, der fortsat er. 12

17 4 VALG AF HARDWARE 4.2 Varmeudvikling og strømforbrug Udover forskellige arkitekturer, er der også et valg mellem enkelt- processor maskiner eller SMP baserede maskiner. Intels nyeste processor til high-end performance hedder Xeon og benytter sig af en ny teknologi kaldet Hyper Threading. Hyper Threading gør det muligt for en processor at fremstå som 2 processorer. Med en Xeon processor er det nemt at bygge SMP maskiner, da man reelt kun vil have behov for det halve antal processorer i forhold til tidligere tiders SMP løsninger. Et argument mod SMP maskiner er imidlertid, at CPUerne sidder tætkoblet og derfor deles om den samme RAM-bus på bundkortet, og dette kan danne en flaskehals. Som alle andre nye processorer er prisen også væsentlig højere end for lidt ældre CPUer. [2-4-8] beskriver nogle scenarier, hvor dual maskiner kan være begrænsende i sig selv, i forbindelse med visse beregninger, og de er derfor uinteressante ud fra et pris/ydelses synspunkt. 4.2 Varmeudvikling og strømforbrug Ret hurtigt i forløbet gik det op for os, at to vigtige parametre i forbindelse med design af klyngen var strømforbrug og køling. Da ingen af os, havde den store erfaring med nogle af disse emner, var vi nød til at arbejde med problemet. At finde det reelle energiforbrug for en computer var lidt af en udfordring, da de fleste computerfabrikanter blot oplyste maksimum kapaciteten på strømforsyningen og ikke det reelle forbrug. Vi var derfor nødsaget til at kontakte nogle af leverandørerne, der havde indsendt tilbud, en gang til for at få specificeret dette tal. Et vigtigt faktum var også at de standard tal, der oplyses, normalt inkluderer en skærm tilsluttet computeren. Vores klyngeløsning var baseret på rå computerkraft uden skærme. Det viste sig, at standard strømforbruget for en computer ligger på omkring 75 Watt. Maximum brug Mininum brug Sleep OFF 291 BTU/hr 127 BTU/hr 9 BTU/hr 4 BTU/hr Figur 3: Varmeudviklingstal for en Dell OptiPlex GX260 maskine Det var et vigtigt tal, da det kræver ca. samme energi at fjerne den varme, som 75 Watt genererer. Disse tal skulle derfor bruges som oplysning til de kølefirmaer, der blev kontaktet for at give tilbud på en køleløsning. Vi kontaktede 3 firmaer, der specialiserede sig i løsninger af edb-køling, og heraf vente 2 af dem tilbage i tide. Begge disse firmaer var ude og besigtige serverrummet og afgav tilbud på baggrund af dette. Der var tre mulige løsningsscenarier: Køleenhederne blev placeret inde i rummet Køleenhederne blev placeret i et tilstødende tomt lokale 13

18 4 VALG AF HARDWARE 4.3 Hukommelsesovervejelser Køleenhederne blev placeret udenfor selve bygningen Den løsning der blev valgt, benytter sig af det faktum, at der lige ved siden af serverrummet findes et tomt lokale, hvor der tidligere har stået et oliefyr, hvor der var boret hul i ydervæggen, så der trækkes frisk luft ind. Køleenhederne er placeret i sammenhæng med dette luftindtræk, og der bores hul i væggen tre steder indtil serverrummet, hvor der monteres tre blæsere. To af dem blæser kold luft ind i rummet, mens den sidste suger varm luft ud af rummet. De er fysisk placeret spredt i rummet, så airflowet bliver optimalt. På denne måde optager køleanlægget også minimal plads i det ellers ret pakkede serverrum. Køleløsningen kan køle op til 25kWatt. Dette skulle være overdimensioneret i forhold til det reelle forbrug i forhold til klyngen, så køleanlæggets maksimum kapacitet ikke nås fra dag et. 4.3 Hukommelsesovervejelser Et andet sted, vi var nødt til at træffe nogle valg, var i forbindelse med at fastsætte hvilken type RAM og hvilken størrelsesorden af RAM, der var behov for i maskinerne. Der findes flere forskellige konkurrerende RAM typer, primært anført af DDR-SDRAM og RAMBUS RAM (RDRAM). De fleste computere idag leveres idag med DDR RAM, da RAMBUS RAM har problemer med latenstiden og derfor ikke anses for at være hurtig nok. For at bestemme mængden af RAM, der skulle i klynge computerne, valgte vi at køre et af de før omtalte performance målingsprogrammer, for at se på programmernes reelle RAM forbrug. På baggrund af disse tests, valgte vi at få 512 MB RAM i en klods i hver computer, ikke mindst fordi dette var standard, men også fordi det var mere end en fordobling i forhold til, hvad behovet umiddelbart blev. Ligeledes giver dette, mulighed for en senere udvidelse af RAMen, med en klods mere til 1 GB RAM, hvis det bliver nødvendigt. 4.4 Netværksteknologi Når der skal vælges netværksteknologi for en klynge, er der to grupper at vælge imellem: specielle klyngenetværk med lav latenstid (MyriNet eller SCI) eller standard Ethernet (100 eller 1000 Mbit). Efter at have studeret de udvalgte applikationer, valgte vi ud fra et økonomisk og behovssynpunkt at bruge standard Ethernet. Da de fleste andre løsninger, ville have været uhensigstmæssigt dyre, da specialkortene i sig selv, ville svare til halvdelen af prisen for en knude. Derudover, var vi også heldige, idet den leverandør, der endte ud med at have det bedste tilbud, leverede alle maskinerne med indbygget Intel Gigabit Ethernet netkort. For at lettere kunne installere maskinerne, var det et krav at netkortene undstøttede Pre-Boot Execution Environment (PXE) standarden. PXE er en stardard defineret af Intel i forbindelse med deres Wired for Management (WfM) standard. Det muliggør at hente en bootloader og kerne over nettet fra en central server. Dette er en stor fordel, når man skal håndtere et stort antal maskiner. PXE er egentligt blot en DHCP client, der kan overføre data. 14

19 4 VALG AF HARDWARE 4.5 Valg af disk Udover netværkskortene behøvede vi naturligvis også, en sammenkobling af netværket. Da vores maskiner har gigabit Ethernet, ville det bedste være at forbinde dem med et rent Gigabit netværk. Men da Gigabit endnu ikke er så udbredt, at prisen har nået et niveau, hvor den ikke vil overskygge resten af udgifterne til klyngen, valgte vi at benytte kategori 6 kabler, der kan håndterer Gigabit, hvis der på et givet tidspunkt blev indkøbt netværksudstyr, der kunne håndtere det. Så den aktuelle struktur er nu på to niveauer med 100 Mbit stackede switche for hver 96 maskiner og et Gigabit uplink til en central gigabit switch. Der blev indhentet flere forskellige tilbud på netværksudstyr. Heriblandt HP, Cisco og Enterasys. Priserne lå jævnt fordelt med Cisco i den høje ende og HP i den lave ende. Det endelig valg faldt på udstyret fra Enterasys, som er et spinoff firma af det gamle Cabletron. Den primære grund til at valget faldt på dette udstyr, var for det første at det prismæssigt lå i mellemgruppen, samt at resten af Zoologisk Museums netværksstuktur er opbygget af dette udstyr og for det andet at det blev modtaget positivt af netværksafdelingen, fordi den administrative byrde blev lettet ved ikke at introducere andre typer netværksudstyr. 4.5 Valg af disk Harddiskene i de enkelte knuder skal opfylde to krav: De skal have en relativt høj ydelse og størrelse. De harddiske der som standard findes i de fleste computere idag er IDE diske. IDE har en god ydelse og en rotationshastighed på 7200 RPM og en standard størrelse på ca Gbyte. Et alternativ til standard IDE diske havde været en SCSI baseret løsning. SCSI leveres typisk sammen med serverløsninger, hvorimod IDE leveres sammen med løsninger til små computere. SCSI standarden giver nem mulighed for at isætte mere end 4 diske i en maskine, og de er typisk også hurtigere end IDE diskene. Et minus er blot, at prisen dermed også er højere, samt at de fleste maskiner ikke leveres med en SCSI controller, men kun IDE controller. Prisen bliver derfor en vigtig performance parameter endnu en gang. Vi valgte derfor ikke at udskifte de IDE diske, som fulgte med i computertilbuddende. Disse diske er også dækket ind under den generelle 3 års on-site garanti, så i tilfælde af fejl på hardware, vil de blive skiftet uden yderligere omkostninger. 4.6 Valg af server Der er behov for en server i klyngen, til styring af forskellige administrative opgaver. Det er muligt at koncentrere disse opgaver på en enkelt server, men det er også muligt at dele funktionerne ud over flere maskiner. De opgaver der umiddelbart skal håndteres er: Information omkring brugere og forskningsgrupper Opbevaring af brugernes data, som de skal bruge på klyngen Software til kørsel og schedulering af programmerne 15

20 4 VALG AF HARDWARE 4.7 Opsumering over valg af hardware En af de primære faktorer, der påvirker vores valg af server, er det faktum, at klyngen på et givet tidspunkt, eventuelt skal opdeles i to. Vi valgte derfor ret hurtigt, at læne os op ad de eksisterende systemer, da dette giver en nem mulighed for at klone serveren over på en tilfældig knude i tilfælde af deling af klyngen, eller simpelt hardware nedbrud. På denne måde vil hovedswitchen for klyngen, også fungere som samlingspunkt for det resterende server-netværk. Derfor, har vi valgt at bruge en af de computere, der skal indgå i klyngen, som server. Serverens hovedopgave bliver bruger-administration og igangsættelse af jobs på klyngen. Tilgengæld har vi valgt at bibeholde filserver-opgaverne på de to institutters eksisterende afdelings filservere, som er langt bedre rustet til denne opgave, med RAID systemer og dertilkoblede backup procedurer. 4.7 Opsumering over valg af hardware Det endelige valg af klynge computer faldt på Dell OptiPlex GX260, der er en 2.4 GHz Intel baseret computer med 512 MB DDR RAM. Computeren er en Small Form Factor model, der derfor ikke fylder specielt meget. Alle Dell computere leveres med et Intel baseret Gigabit netkort integreret på bundkortet. Grafikkortet er også et Intel kort, men da vi på ingen måde er interesseret i at benytte grafiske redskaber, havde vi ingen krav til grafikkortet. Dell OptiPlex computerne er udstyret med en 40 GB IDE disk og et alm. floppy drev, tilgengæld fulgte der ikke noget cd-rom drev med, da der ikke var behov for dette. Dell OptiPlex maskinen er kendetegnet ved, at være meget støjsvag og har et lavt strømforbrug. Yderligere var denne maskine langt den billigste, af alle de tilbud vi havde modtaget. Den lå ca kr under de andre mærker, selv saml-selv-bambus maskinerne, så der var ingen tvivl om, hvilken maskine der bedst matchede vores krav. Det, at prisen var så lav, betød at der kunne købes mange flere computere. Fra et oprindeligt regnskab på under 200 computere, blev der råd til 241 computere, hvilket var væsentligt flere end estimeret i det oprindelige projekt. Figur 4: Dell OptiPlex GX260 computer 16

21 5 VALG AF SOFTWARE 5 Valg af software Men, en klynge består jo som bekendt ikke kun af hardware. Det kræver en hel del software. Det følgende afsnit beskæftiger sig, med de forskellige valg indenfor software vi traf i forbindelse med etableringen af klyngen. Groft sagt falder de indenfor følgende kategorier: Fastlæggelse af styresystem Installation og vedligholdelse Jobstyring Biblioteker og applikationer til kørsel på klyngen 5.1 Valg af styresystem Der var flere forskellige muligheder indenfor valg af et styresystem til klyngen. Primært lå valget mellem Windows eller UNIX. TNT programmet var før februar måned kun lavet til Windowsplatformen, så dette var en reel mulighed. Der ville dog ligge en betydelig udgift i indkøb af licenser til alle maskiner, derfor lå det ret hurtigt klart at klyngen skulle køre en form for UNIX som styresystem. Men hvilken UNIX version var den bedste? Da vi fortsat skulle tage hensyn til økonomien var det oplagt at benytte et gratis open source baseret UNIX styresystem. De to alternativer i betragtning var henholdsvis FreeBSD og Linux. FreeBSD 4.7 er kendetegnet ved at være en af de mest stabile, skalerbare og produktionsmodne opensource operativsystemer. Det har langt færre fejl end f.eks. Linux 2.4 serien. Problemet var dog at der rent administrativt var mere erfaring med Linux hos f.eks. Center for Bioinformatik og de har med fordel benyttet sig af Debian Linux på deres computerinstallationer. Debian Linux er kendetegnet ved at være relativt konservativt opbygget i forhold til f.eks. Red Hat Linux, og har et langt mere modent pakkestyringsystem til installation og vedligeholdelse af software end Red Hats RPM system. Debians pakkesystem er modeleret efter FreeBSDs ports-træ, som er et avanceret pakkesystem som bl.a. checker pakker for afhængigheder og selv henter de afhængige programmer der mangler. Det endelige valg af styresystem faldt derfor på Debian Linux, da det var et godt kompromis for alle parter. Men valget blev spcielt truffet ud fra et krav om nemmere vedligeholdelse og support af systemet. 5.2 Valg af filsystem I sammenhæng med valget af styresystem, skulle der også træffes et valg omkring hvilken type filsystem klyngen skulle køre på. Et oplagt valg var Linux standard filsystemet ext3. Havde vi valgt FreeBSD fremfor Debian, ville filsystemet have heddet ufs og benyttet softupdates til asynkrone skrivninger til disken. ext3 er kendetegnet ved at være et journaliserings filsystem. Af andre kendte journaliserende filsystemer kan nævnes ReiserFS og SGIs xfs. Et journaliseringsfilsystem er kendetegnet ved at operationer på disken opbevares midlertidigt i en journal og derefter skrives til disk. I 17

22 5 VALG AF SOFTWARE 5.3 Valg af installationssystem tilfælde af et systemnedbrud er der derfor kun behov for at checke indholdet i journalfilen fremfor at køre filesystem check af hele disken (fsck). Dette er specielt gavnligt, når man arbejder på store diske, hvad der typisk er standarden idag. 5.3 Valg af installationssystem For at kunne installere det store antal maskiner er der behov for en nem måde at kunne installere dem på. Da alle maskiner har identisk hardware er det nemt at lave et system til at geninstallere dem. Den basale tilgangsmåde er at installere en maskine og derefter kopiere installationen ud på de andre maskiner. For at forenkle denne process findes der en række forskellige værktøjer, der er mere eller mindre produktionsmodne. De systemer vi har set på er: Ka-boot, SystemImager og PartImage. Det sidste er ikke et desideret klonings - program. Det er kun beregnet til at gemme og gendanne partitioner. Ka-boot [ka-tools] består af en række småprogrammer. Dels til styring af installationen af maskinerne og dels af nogle små klientprogrammer, der henter data på klienterne. Det muliggør, at man fra en server kan sige at knude 1 skal replikeres til de andre n-1 knuder. Ka-boot er også open source og understøtter multicast og derigennem hurtig installation af et stort antal maskiner. SystemImager [systemimager] ligner på mange måder Ka-boot men har et bredere fokus, da det ikke kun er designet til klynger. PartImage [partimage] fungerer i stor udstrækning som Unix kommandoen dd. Den gemmer data fra disken i en fil, som kan komprimeres med gzip eller bzip2. Der også mulighed for at hente filerne fra en server. Vi har valgt at bruge programmet PartImage og nogle ekstra små programmer, da det var det, der var nemmest at få til at fungere. Vi fravalgte Ka-boot, da det var for dårligt dokumenteret og Systemimager, da vi først blev introduceret til det, efter vi havde fået PartImage til at virke. 5.4 Jobstyringssoftware For at systemet skal kunne køre fornuftigt, skal det være muligt at styre, hvem der kan starte jobs og hvormeget tid de forskellige jobs bruger, så en enkelt person ikke kan dominere klyngen. De to stykker software, der ansvarlige for at varetage disse opgaver, er et batchsystem og en scheduler. Batchsystemet starter og stopper jobs og scheduleringssytemet bestemmer hvilke jobs der skal køres i hvilken rækkefølge. Som batchsystem valgte vi at bruge gratis versionen af Portable Batch System (OpenPBS). PBS findes også i en kommerciel udgave kaldet PBSPro, som blandt andet benyttes på Odense-klyngen. OpenPBS har defineret et API, sådan at det er muligt at bruge forskellige schedulers. Der følger også en række af forskellige schedulers med. 18