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

23 5 VALG AF SOFTWARE 5.5 Biblioteker og applikationer Den simpleste er en ren FIFO (eng. First In First Out) scheduler. Figur 5: OpenPBS og Mauis udførsels af et job OpenPBS kan deles op, således at opgaverne fordeles på tre typer af maskiner: frontends, servers og execution hosts. En PBS server har defineret en rækker køer, hvori jobbene kan tilføjes. Dette kan gøres fra en frontend maskine, der bruger kommandoen qsub (1), der også kan bruges til at angive hvilke ressourcer et job skal bruge. Dette kan f.eks. være 8 maskiner. PBS informerer Maui om, at den har modtaget jobbet (2), som melder tilbage når jobbet skal startes (3). Når PBS starter jobbet reserverer den det antal maskiner, der skal bruges og sender kørselsfilen ud til den første af maskinerne (4). Herfra bliver kørslen udført af den lokale pbs mom, der fortæller programmet hvilke maskiner den har tilgængelig, så den kan brede sig til dem. Når programmet er kørt færdig bliver uddata fra det sendt til serveren (6), som gemmer det i en fil med jobnummeret på frontend knuden (7). En anden scheduler, der også understøttes i PBS API er Maui [Maui]. Da klygens ejere en en større konstallation af personer og for senere at kunne håndtere muligheden for at sælge processortid, valgte vi at bruge Maui scheduleren. Maui har mange muligheder for at beskrive hvordan en klynge må anvendes og bliver brugt i sammenhæng med OpenPBS i mange store systemer, så den er meget velafprøvet og det er nemt at implementere forskellige klynge-styrings politikker. 5.5 Biblioteker og applikationer Da vi ikke kun var ansvarlige for at få klyngen op og køre, men også for at få de forskellige programmer til at køre, var vi nød til at undersøge hvad det stillede for krav til softwaren, installeret på maskinerne. Vi kan naturligvis ikke forudsige alle typer 19

24 6 SETUP OG DESIGN AF KLYNGEN af programmer, der skal installeres på klyngen, men vi kan undersøge, hvad der skal bruges, sådan at en geninstallering af klyngen ikke er nødvendig i den kommende tid. Vi har på dette grundlag valgt, at installere de mest almindelige biblioteker for parallelle programmer nemlig PVM (eng. Parallel Virtual Machine) og MPICH (eng. Message Passing Interface Channel). Biblioteket PVM benyttes af programmerne POY og TNT, mens bl.a. Performance testningsprogrammet Linpack benytter MPICH biblioteket til sine kørsler. Programmerne BLAST og HMM er er pinligt parallelle og benytter sig derfor ikke af nogen biblioteker. 6 Setup og design af klyngen Efter at have fået leveret maskinerne, lavede vi en lille testklynge med tre maskiner. I denne fik vi fastlagt hvordan maskinernes BIOS skulle konfigureres og hvordan vi skulle sammensætte vores installationssystem. Udover at få installationssystemet og jobstyringsystemet til at virke, var der også mange praktiske ting, der skulle ordnes i forbindelse med opsætning af klyngen. De to største var køling og strøm. 6.1 Installationsystemet Da alle maskiner har PXE og er ens, er det muligt at fuldt ud automatisere installationen, med følgende trin: 1. Først sender serveren en wake-on-lan pakke til maskinerne, der starter dem. 2. Derefter starter PXE med at sende en DHCP forespørgsel ud. 3. Når DHCP serveren modtager en forspørgsel sender den en IP konfiguration tilbage til klienten og yderligere information omkring PXE: Hvor den skal hente sin bootloader fra og hvad den hedder. 4. Når klienten har modtaget denne information bruges TFTP (også en del af PXE) til at hente bootloaderen over nettet. 5. Bootloaderen bruger PXE til at hente en konfigurationsfil, der indeholder information om hvilken kerne, der er tilgængelig og hvilke parametre den skal bruge. Formatet minder meget om det mest almindelige for bootloadere til Linux. 6. Derefter henter den kernen, der er blevet defineret som standard, eller indtastet af brugeren. 7. Derefter starter kernen, som den havde normalt ville gøre. 8. Når kernen er startet, er det muligt at få IP konfigurationen fra PXE så root filsystemet kan monteres på NFS. 9. Efter at kernen har startet init fra root filsystemet køres et almindeligt filsystem 10. Derefter køres sfdisk med en inddata-fil og partitionerer harddisken. 11. Herefter gendanner PartImage data til disken. 12. Maskinen genstartes og er herefter klar til brug. 20

25 6 SETUP OG DESIGN AF KLYNGEN 6.1 Installationsystemet Figur 6: Opstartsprocessen for en maskine. PXE Linux gør det muligt for os, at definere på serveren hvilken kerne maskinerne skal starte med. På denne måde kan vi vælge om maskinerne skal starte lokalt på disk eller via NFS. Vi kan også vælge hvilken NFS export det skal være, så vi kan få forskellig opførsel fra maskinerne f.eks. en fuld installation eller bare en opgradering. Partioneringen af diskene giver også, en vis frihed til at vælge hvormeget af systemet man vil opdatere. Måden vi har opdelt filsystemet på er: dell utility fat16 hda1 /boot 128 MB hda2 ext3 / 1 GB hda3 ext3 swap 2 GB hda5 (Logisk) ext3 /usr 4 GB hda6 (Logisk) ext3 /var 2 GB hda7 (Logisk) ext3 /tmp 512 MB hda8 (Logisk) ext3 /scratch resten (30 GB) hda9 (Logisk) ext3 Hvor tanken er at /scratch partitionen, skal fungere som midlertidigt lagringssted af resultater, når programmerne kører på klyngen. Denne måde at installere på, kan give problemer, da alle maskiner samtidig forsøger at læse fra serveren. Det betyder, at serverens disk bliver overbelastet. Det er netop dette problem, som Ka-boot programmet forsøger at løse. Men da vi første gang skulle installere alle maskinerne skulle vi også indsamle samtlige MAC adresser og fysisk mærke maskinerne, så det blev ikke så stort et problem for serveren, da vi fysisk kun installerede en maskine ad gangen. Det kan eventuelt i fremtiden blive nødvendigt, at 21

26 6 SETUP OG DESIGN AF KLYNGEN 6.2 Navngivning af maskiner bruge et system som Ka-boot, eller noget lignende hvis man ønsker en lavere installationstid. Vi har siden da reinstalleret styresystemet på knuderne et par gange, og har i den forbindelse kunne se, at det rent faktisk giver problemer med installationstiden, da serveren bliver overbelastet. Installationstiden går fra at vare 5 min, per maskine, til at vare ca. 15 min, per maskine. Det må dog forventes, at reinstallation af alle maskiner på en gang, bliver en sjældenhed når først klyngen går i produktion. 6.2 Navngivning af maskiner For at kunne identificere hvilke maskiner, der sidder på hvilken switch og for at kunne finde en maskine hvis den går ned, var vi nød til at bruge en systematisk tilgang til at navngive maskinerne. Efter råd fra Odense valgte vi at give maskinerne IP adresser efter hvilken switch de sad placeret på og vi associerer derfor IP adresser med maskiner ved hjælp af MAC adresser i DHCP filen. Alle maskiner har derfor et IP nummer, der er kendetegnet ved : switchnr.portnr. Yderligere har vi også fysisk mærket alle maskiner med labels, så de er nemme at finde. Alle maskiner er navngivet så de hedder bionode<nummer>, hvor nummeret er et løbenummer fra 1 op til Netværksstrukturen Klyngen er fysisk placeret på det undernetværk, der i daglig tale bliver kaldt for AKIZCI under KU. AKIZCI består af AKI (August Krogh Instituttet), ZI (Zoologisk Institut), ZM (Zoologisk Museum) og IFI (Institut For Idræt). BINF (Bioinformatik-centret) sidder, midlertidigt tilknyttet AKIZCI nettet og ønsker sig en stor netværksforbindelse til klyngen, så den kan udnyttes optimalt. Der er dog nogle problemer i den nuværende netværksstruktur. For tiden har BINF f.eks. en firewall der laver NAT (eng. Network Address Translation) ud mod resten af AKIZCI. Dette er gjort for ikke at benytte for mange eksterne IP numre, på et ellers internt net. Dvs. at internt bruger BINF de samme lokale IP adresser som klyngen bruger. Dette har besværliggjort netværksopsætningen af NAT og routning mellem institutterne. Løsningen blev, at der blevet lavet en class-less routning mellem de 3 net (BINF, AKI og bioclusteret) og BINF får begrænset sine lokale IP adresser til et lidt mindre range. Et yderligere problem, er at det er den samme router, der skal styre NAT ud mod omverden, som router ind mod lokalnettet. Dette gjorde, at det ikke var muligt at nå ud på internettet fra klyngemaskinerne. Dette gør, at forbindelser ud fra klyngen kommer til at gå gennem BINF, når der fysisk bliver lavet en fiber-forbindelse mellem BINF og klyngen. Den fiber-forbindelse, som kan ses på Figur 7 eksisterer altså ikke pt. 22

27 6 SETUP OG DESIGN AF KLYNGEN 6.4 De fysiske rammer Figur 7: Den logiske struktur på netværket 6.4 De fysiske rammer Rummet hvor maskinerne skal stå i, kan ses på Figur 8. Maskinerne er placeret på reolerne. I de to rackskabe er ZMUC og GBIFs servere placeret. GBIF (eng. Global Bio Diversity Information Facility) er en institution, der deler serverrum og byggning med ZMUC, men har ud over dette, ikke noget vores arbejde at gøre. Med henblik på køling, så er der to indblæsningssteder og et udsug. Dette medvirker til at den nye luft bliver suget gennem de tre reoler hvorpå maskinerne står og sikrer maksimalt airflow i rummet. Termostaten, der styrer kølingen, er placeret ved siden af udsugningen, hvor luften principielt er varmest. Figur 8: Den fysiske udformning af serverrummet. 23

28 6 SETUP OG DESIGN AF KLYNGEN 6.5 Konfiguration af server I forbindelse med klargøringen af rummet til serverrum, er el-installationen blevet opgraderet til at kunne klare de mange maskiner. Dette fremgår ikke af oversigtstegningen, men el-installationen var en betydelig udgift på budgettet. Den nye el-installation krævede en udvidelse af den eksisterende el-tavle, oprettelse af nye grupper samt etablering af UPS-strøm til bl.a. fiber-hovedswitchen. Installationen af el og køling har været den proces, der har taget længst tid i klargøringen af serverrummet. 6.5 Konfiguration af server Som tidligere nævnt, så valgte vi at bruge en af maskinerne, som server, så den var nem, at erstatte ved eventuelle fejl. Det der adskiller serverens konfiguration, fra knudernes konfiguration er følgende programmer: DHCP-server TFTP-server Navneserver (DNS) Filserver (NFS) NIS-server Jobstyringsserver (OpenPBS) Køstyringsserver (Maui) DHCP, DNS og TFTP delen benyttes i sammenhæng med installationsystemet. Filserver delen, benyttes til at eksportere folks hjemmekataloger rundt på klyngen, så de altid fysisk kun er placeret et sted, nemlig på serveren. Men de er til enhver tid tilgængelige fra f.eks. frontend maskinerne. De tre sidste programmer: NIS, OpenPBS og Maui er alle tre relateret til jobstyring på klyngen. Det var nødvendigt at installere NIS, for at OpenPBS kunne validere brugere på tværs af knuder, da brugerne kun er oprettet på serveren, men ikke på knuderne. server_state = Idle scheduling = False total_jobs = 2 state_count = Transit:0 Queued:0 Held:0 Waiting:0 Running:2 Exiting:0 managers = [email protected],[email protected], [email protected] default_queue = dque log_events = 511 mail_from = adm resources_assigned.nodect = 48 scheduler_iteration = 600 pbs_version = OpenPBS_ Figur 9: OpenPBS serverens konfiguration Vi benyttede os af [pbsinstall], som vejledning til hvordan vi skulle konfigurere OpenPBS og Maui, så det fungerede korrekt sammen. Både OpenPBS og Maui er glimrende dokumenteret, så det var intet problem, at konfigurere disse programmer. Vores konfiguration kan ses som Figur 9. Der er pt. kun en nkelt jobkø kaldet dque (eng. default queue) tilgængelig. 24

29 7 TEST OG EVALUERING AF KLYNGEN 6.6 Det endelig setup 6.6 Det endelig setup Figur 10: Billeder af klyngen. Det endelige biocluster klynge setup, består af 241 Dell OptiPlex GX260 maskiner, der alle kører Debian Linux. Hver hylde i en reol indeholder 12 computere. Der er taget 4 computere fra til specielle roller. En er taget fra som server (tintin), en er taget fra som failover, hvis tintin fejler (dupont) og to maskiner er taget fra, til at fungere som frontend maskiner for henholdsvis Zoologisk Museum og Center for Bioinformatik. Resten af maskinerne fungerer som bionoder. På figur 10 kan ses to billeder af det endelige klynge setup, som det ser ud idag. 7 Test og Evaluering af klyngen I det følgende afsnit beskæftiger vi os med klyngens generelle performance, dels ved kørsler af programmet inpack, dels ved kørsler af de biologiske programmer. Bioclusteret har det sidste stykke tid desværre, været ramt af hardware fejl, der har besværliggjort vores testmuligheder. Derfor er tuningen af klyngen, endnu ikke helt på plads. 7.1 Fejl og mangler Vi opdagede allerede ret tidligt, at vores fiber-hovedswitch havde et problem, da den efter en dag i drift gik ned. Problemet blev afhjulet af en netværkskonsulent og herefter virkede den korrekt i 14 dage. I løbet af projektets sidste uge, gik den ned igen og denne gang i en så udefinerbar tilstand, at den skulle skiftes under garantien. En erstatning blev bestilt i Irland, men blev af uvisse årsager forsinket så væsentligt at 25

30 7 TEST OG EVALUERING AF KLYNGEN 7.2 MTBF begrebet den først kommer til Danmark omkring d. 18/3, hvilket er efter afleveringsfristen for denne opgave. Da dette er hovedswitchen, der binder hele netværket sammen, havde vi ingen mulighed for at kører nogle tests på klyngen på mere end 96 maskiner, uden den. Vi lånte derfor midlertidigt en Dell gigabit-switch af DIKUs Distlab gruppe således at maskinerne kunne snakke sammen internt, men der var ingen forbindelse til noget eksternt net. Det lykkedes os også at låne en fiber-switch af GBIF, således at vi fik ekstern netforbindelse indtil vores egen fiber-switch kommer retur. Undervejs i vores tests gik det op for os, at der var et eller andet galt med netværket, da vi fik nogle meget mystiske resultater retur fra vores kørsler. Ved brug af programmet Netperf kunne vi se, at der kun var 46 Mbit forbindelse mellem to maskiner, der fysisk sad på den samme stackede switch. Endnu værre stod det til med forbindelsen fra tintin til knuderne, her var hastigheden helt nede på 2 Mbit. Det viste sig, at over halvdelen af knuderne stod til at køre 100Mbit half duplex istedet for 100Mbit full duplex. Kun de øverste af de stackede switche var konfigureret korrekt til 100Mbit full duplex, resten stod til autonegotiate. Da fejlen først var fundet og identificeret, tog det ikke lang tid at udbedre, men vi brugte næsten en hel uge på at finde frem til denne fejl, og vi måtte smide samtlige testkørselsresultater, fra før fejlen blev rettet ud, da de ikke gav nogen mening. Efter fejlen blev rettet kørte vi Netperf programmet igen og kunne nu se at alle maskinerne havde en båndbredde på ca. 96 Mbit til serveren, hvilket er væsentligt tættere på de forventede 100 Mbit. Sidst, men ikke mindst, skal det siges at kølingen i rummet blev endeligt tilsluttet tirsdag d. 11/3. Det var således ikke muligt at have alle maskiner tændt på en gang, før dette tidspunkt, da rummet blev meget varmt og det ikke er specielt sundt for maskinerne. Kølingen nåede også at gå i stykker en enkelt gang siden d. 11/3, men blev dog ordnet allerede dagen efter. Tre maskiner er muligvis brændt af den nat, kølingen stoppede. 7.2 MTBF begrebet Termen MTBF (eng. Mean Time Between Failure) beskriver komponenternes formodede levetid. Lige meget hvor gode vores programmer er, har hardware en forventet levetid. Hvis programmerne ikke implementerer en form for checkpointing, kan det være relevant at give den enkelte programkørsel yderligere kørsels-timer, hvis en eller flere af knuderne er gået ned under kørslen. Dette kan OpenPBS garantere os - men vi kan ikke garantere os mod fejlene. Der er dog ofte stor forskel mellem den teoretiske og den faktiske fejlrate. Erfaringer fra Odense viser, at hvor de burde have et nedbrud per dag, har de istedet typisk et nedbrud per 3 dage. Nedenstående graf er taget fra Brian Vinther (SDU) (se Figur 11). Teoretisk set burde vores klynge have nedbrud ca. hver 33 time. Vi kender desværre endnu ikke de reelle tal. Vi vil dog anbefale, at der placeres en logbog sammen med 26

31 7 TEST OG EVALUERING AF KLYNGEN 7.3 Linpack Figur 11: Graf over Mean Time Between Failure. klyngen, hvor evt. systemnedbrud noteres samt servicepapirer placeres, så man efter 3-6 mdr. har mulighed for at bedømme den reelle nedetid af klyngen og fastsætte passende ekstra tid til folks kørsler efter dette. 7.3 Linpack For at sammenligne vores klynge med andre eksisterende klynger har vi udført en kørsel med performancemålingsprogrammet Linpack. Da alle maskinerne teoretisk set skulle kunne udføre 2 flydende tals operationer per clockcykel så burde klyngen principielt kunne udføre ca Giga FLOPS. Det problem som Linpack forsøger at løse, er n ligninger med n ubekendte. De ting man kan justere på i Linpack er hvor stort et n (N) man vil bruge og hvor stor blokstørrelse (NB) man vil bruge til at opdele problemet. Man kan yderligere definere geometrien af det logiske grid som maskinerne bliver placeret i (P og Q). Ud fra de vejledninger vi har læst omkring Linpack, har vi fundet ud af, at n skal være: 80% af RAM (512*0,8) divideret med størrelsen af et dobbelt flydende talord ganget med antallet af computere. Dette giver os et tal på ca Det største resultat det er lykkedes os at få til at køre er på 182 maskiner. T/V N NB P Q Time Gflops W11R2C e+01 Et resultat på 50 Gigaflops, må siges at være meget langt fra vores teoretiske mål. Vi har forsøgt at lokalisere kilden til dette skæve tal, men har svært ved trænge ind til kernen af problemet. Vi ved derfor ikke om det skyldes en fejl i vores MPI installation, eller om det skyldes fejl i valg af parametre til Linpack. Vi har korresponderet med Brian Vinther fra Odense, og bl.a. fået udleveret deres Linpack konfigurationsfil. Den lignede i høj grad vores egen (se H). Brian anbefalede 27

32 7 TEST OG EVALUERING AF KLYNGEN 7.4 Test af programmerne dog brug af MPI-LAM biblioteket istedet for MPICH biblioteket som vi indtil nu har benyttet os af. Det kan tænkes, at dette kan give langt bedre performance. 7.4 Test af programmerne I det følgende afsnit vil vi forklare, hvordan vi har kørt de forskellige biologiske programmer, samt vise de forskellige programmers performance på klyngen BLAST I den nuværende version af BLAST, som vi bruger, er den almindeligste strategi for at distribuere arbejde, at dele databasen op i flere små dele, som kører med den samme forespørgeselssekvens på mange maskiner. Vi har kørt BLAST på 4 og 8 maskiner. Tiderne er vist i Figure 12. Tiderne måler kun selve databasesøgningen og ikke overførslen af data. For at undersøge BLAST kørte programmet med følgende parametre: formatdb -v $volume_size -p F -o T -i $DB_BASE blastall -p blastn -d $dbname -i tempfasta Hvor volume size er databasestørrelsen divideret med antallet af knuder. Og dbname er navnet på de enkelte dele af databasen. Antal maskiner Tider per maskine (sek) Gennemsnitlig tid 4 273, 283, 289, , , 267, 267, 269, 270, 273, 277, Figur 12: Køretider af BLAST Som det kan ses af figur 12, opnår vi en lille speedup, ved at køre BLAST på dobbelt så mange maskiner. Kørselstiden formindskes kun en lille smule, ved halvering af databasen. Dette tyder på et stort opstartsoverhead ved søgning i databasen med kun en forespørgslessekvens. Dette tyder på, at vores paralleliseringsstrategi for databasen er uegnet til at køre på en klynge, i sin nuværende form. Det kan skyldes at vores scenario er urealistisk. Grunden til at vi ikke har fået kørt BLAST på flere maskiner, skyldes problemer med programmet til formateringen af databasen (formatdb). Den splittede ikke databasen, som forventet. Dette problem vil forhåbentlig blive løst af en person med større forståelse for BLAST programmet, end os POY POY er den eneste af applikationerne hvor vi har fundet tidligere littaratur omkring programmets opførsel på en klynge [parapoy]. POY har to forskellige metoder til at køre på en klynge. Den ene kaldes for parallel og den anden kaldes for multi. I den første samarbejder alle knuder om det samme træ, hvor den i den anden arbejder på 28

33 7 TEST OG EVALUERING AF KLYNGEN 7.4 Test af programmerne forskellige træer. Dette gør at multi skalerer bedre end parallel, da en af måderne at køre multi på er udtømmende søgning, så burde den fungere rigtig godt på en klynge. Da vi ikke kunne afgøre hvilke parametre, der passede bedst til vores datasæt, valgte vi at bruge defaultværdier for alle parametre. For at undersøge POY kørte vi programmet med følgende parametere: poy -verbose -parallel -molecularmatrix /home/lars/poy/fn221 /home/lars/poy/atpa Figur 13: Kørsler og Speedup for POY. POY er det program, hvor det er lykkedes os at få de fleste resultater og programmet afvikler betydeligt hurtigere i parallel. Men vores kørsler ligger dog langt fra de tæt på ideelle køretider bseskrevet i [parapoy] HMM Strategien, der bliver brugt for at udnytte parallel computerkraft med HMMer, er at man laver parallel krydsvalidering. Dvs. at man deler sit datasæt op i n dele hvor (n-1)/n bliver brugt til træning og den sidste 1/n bliver brugt til at kontrollere at modellen er korrekt. Når vi kørte HMM er i parallelversionen, kørte vi træningsdelen og dekodningsdelen på sammen maskine. For undersøge HMM kørte vi programmet med følgende parametere: cat data/pombe.lab.1 data/pombe.lab.2 data/pombe.lab.3 data/pombe.lab.4./trainanhmm runs/pombe55/ml.0 -modelfile models/pombe00c.imod -f setup/mlstd.ini > runs/pombe55/ml.0.out cat data/pombe.lab.0./decodeanhmm runs/pombe55/ml.0.bsmod -N1 -pp -ps -pl > runs/pombe55/ml.0.pred cat data/pombe.lab.1 data/pombe.lab.2 data/pombe.lab.3 data/pombe.lab.4./trainanhmm runs/pombe55/chmm.0 -modelfile runs/pombe55/ml.0.bsmod -f setup/chmmstd.ini > runs/pombe55/chmm.0.out cat data/pombe.lab.0./decodeanhmm runs/pombe55/chmm.0.bsmod -N1 -pp -ps -pl > runs/pombe55/chmm.0.pred cat data/pombe.lab.0 data/pombe.lab.2 data/pombe.lab.3 data/pombe.lab.4./trainanhmm runs/pombe55/ml.1 -modelfile models/pombe00c.imod -f setup/mlstd.ini > runs/pombe55/ml.1.out cat data/pombe.lab.1./decodeanhmm runs/pombe55/ml.1.bsmod -N1 -pp -ps -pl > runs/pombe55/ml.1.pred 29

34 8 KONKLUSION Vores kørselstider for HMM er findes i Figur 14. Da der ikke er nogen kommunikation mellem processerne undervejs, tager den parallel kørsel, samme tid som den længst kørende process er om at blive færdig. De resultater vi har fået fra HMM er modsvarer det vi havde forventet, da HMM er har en meget lav grad af granularitet. Grunden til, at vi ikke har fået kørt flere kørsler med HMM er, der ellers ser meget lovende ud, er at det var det sidste program vi kom til at køre tests på og vi desværre derfor ikke havde nok tid til yderligere kørsler. Antal maskiner Tider per maskine (sek) Wallclock tid , 9245, Figur 14: Køretider på krysvalidering af HMM Opsummering på testkørsler Vores testkørsler viser, at programmerne afvikler hurtigere på klyngen end de ville have gjort serielt på en enkelt maskine. Vi har desværre ikke haft tid til at udføre evalueringen i sådan grad, som vi gerne ville. Dette skyldes dels at det har taget os betydeligt længere tid at få programmerne køre på klyngen end først antaget, og dels de allerede omtalte problemer relateret til opsætningen af netværket. 8 Konklusion Vores formål med dette projekt var at analysere, designe og implementere en klyngeløsning til biologisk forskning. Vi har evalueret de applikationer, som forskerne ønsker at benytte på klyngen og vi har målt klyngens performance med programmet Linpack. Vi har i høj grad nået, det vi havde sat os for, på trods af at projektet er blevet dobbelt så stort, som oprindeligt antaget. Hvis man ser på de tværfaglige aspekter i opgaven, har udvidelsen af projektet ikke kun øget antallet af applikationer, der skulle evalueres, det har også betydet en væsentlig forøgelse i antallet af involverede personer. Dette har betydet, at der opstod et langt større behov for kommunikation og videns-udveksling på tværs i gruppen end først antaget. Det har i den grad kompliceret beslutningsprocessen undervejs i projektet. Det er vores holdning, at det ville have været hensigtsmæssigt med en tilknyttet projektleder, der kunne koordinere projektet og følge op på problemer. En person, som havde været hævet over de organisatoriske strukturer, da projektet har båret præg af forvirring omkring ansvarsområder og mangel på koordinerende møder. Rent økonomisk har projektet nydt godt af at vores arbejdskraft har været næstengratis for de tilknyttede institutter. Hvis man havde valgt at benytte en ekstern konsulent ville en større del af projektets budget være gået til afløning. Men selv ved at gøre dette, ville projektet næppe have fungeret bedre, da en stor del af forsinkelserne 30

35 9 PERSPEKTIVERING skyldtes etableringen af serverrummet, der tog meget længere tid, end først antaget (3-4 måneder). På trods af alle disse forhindringer, er vi nu i en situation, hvor vi vurderer at klyngen kan tages rigtigt i brug indenfor kort tid. Der er fortsat et par udeståender, f.eks. mangler vi fortsat at dokumentere de daglige procedurer for brugen af klyngen og der er behov for yderligere tuning af opsætningen. Vi mener dog, at de valg der truffet, har givet den bedst ydende klynge, set i forhold til prisen. Dette baserer vi dels på vores evaluering af programmerne, dels på at Horseshoe klyngen i Odense fornylig, er blevet udvidet med maskiner af samme model, som vores. 9 Perspektivering Det skriftlige projekt er nu afsluttet, men klyngen er endnu ikke taget i daglige drift. I den kommenende tid, vil der derfor komme en hel række af ekstra opgaver i relation til klyngen. Første skridt bliver at få genetableret den rigtige fiber-hovedswitch, så klyngen kan fungere korrekt. Herefter skal der arbejdes på tuningen af klyngen, så forskerne kan få den optimale ydelse ud af maskinerne inden den officielle ibrugtagning af den. Forskerne har store forhåbninger til klyngen og der arbejdes bl.a. på en pressemeddelelse, der skal informere offentligheden om dens eksistens. To af vores egne udeståender består i, at få etableret et dokumentations website ( hvor forskerne kan få svar på de mest almindelige spørgsmål i forbindelse med klyngen. Yderligere er vi blevet bedt om at holde en Klynge introduktions-dag for forskerne, så de kan komme godt igang med at benytte klyngen. Allerede nu, står forskerne på Zoologisk Museum, med 3 nye programmer, de ønsker at prøve af på klyngen. Det drejer sig om: Nona, PiWe og Mr. Bayes, der alle arbejder med at løse phylogeni problemer. På lidt længere sigt, skal der implementeres en mere udvidet brug af de forskellige brugs-politikker i OpenPBS og Maui, så opsætningen garantere at ingen monopoliserer klyngen i længere tid. En anden ting vi ønsker at se på, er en forbdring af applikationerne, så de er bedre egnet til klyngekørler. Et eksempel er en MPI version af programmet BLAST, der fornylig er blevet frigivet, og vil være værd at undersøge performance på. Der er også tale om at blive koblet på det danske Grid computing initiativ. Grid Computing initiativet er et forsøg på, at koble alle de danske forsknings klyngecomputere sammen til en stor løstkoblet klynge, til støtte for dansk forskning. 31

36 10 LITTERATURLISTE 10 Litteraturliste Websider [diskless] NFS Root Mini HOWTO single/nfs-r/ [Maui] Maui Scheduler [OpenPBS] OpenPBS Administrators Guide admin.pdf [SYSLINUX] About SysLinux Project [pvm] Parallel Virtual Machine home.html [Dellbenchmark] Rizwan Ali et al. Evaluating High-Performance Computing Clusters Using Benchmarks [Freshmeat] Linux Clustering Software [bioinf] Bioinformatics [ka-tools] Ka Tools [systemimager] SystemImager [partimage] PartImage [pbsinstall] OpenPBS Install Notes Artikler [PVMMPI] G. A. Geist et al. PVM and MPI: a comparison of Features Artikel, pp. 1-16, [POYexplo] Gonzalo Giribet Exploring the Behavior of POY, a Program for Direct Optimization of Molecular Data Cladistics 17, pp , [MOSIX] Ammon Barak et al. The MOSIX Multicomputer Operating System for High Performance Cluster Computing Artikel, pp. 1-14, 199x. [BEOWULF] Donald J. Becker et al. Beowulf: A Parallel Workstation for Scientific Computation Artikel, pp. 1-4,

37 10 LITTERATURLISTE [Bioinformatics] O. Trelles On the Parallelisation of Bioinformatic Applications Briefings in Bioinformatics vol. 2, nr. 2, pp , May [BLAST] Stephen F. Altschul et. al Basic Local Aligment Search Tool Journal of Molecular Biology vol. 215, pp , [statistics] Samuel Karlin and Stephen F. Altschul Methods for assessing the statistical significance of molecular sequence features by using general scoring schemes Procedings of National Academic Science of USA, vol 87, pp , March 1990 Evolution. [protein] William R. Pearson Protein sequence comparision and Protein evolution Tutorial ISMB200, October [P4Perf] Brinkley Sprunt Pentium 4 Performance-Monitoring Features IEEE Micro no. 4, pp , [P4Spec] Intel Intel Pentium 4 Processor Performance Metrics Intel r Pentium r 4 Processor Optimization Reference Manual, Appendix B, [2-4-8] B. Vinter, O. Anshus, T. Larsen, J. Bjørndalen Using Two-, Four- and Eight-Way Multiprocessors as Cluster Components Procedings of Communicating Process Architectures, CPA, 2001 [binf] R. Durbin, et. al Biological sequence analysis - Probabilistic models of proteins and nucleic acids, Camb. press 1998 [parapoy] Daniel A. Janies and Ward C. Wheeler Efficiency of Parallel Direct Optimization, Cladistics 17, S71-S82, 2001 [tnt] Pablo A. Goloboff Analyzing Large Data Sets in Reasonable Times: Solutions for Composite Optima, Cladistics 15, , 1999 [poy] Ward Wheeler Optimization Alignment: The end of multiple sequence alignment in phylogenetics, Cladistics 12, 1-9, 1996 Algoritmer [WEBPOY] POY ftp://ftp.amnh.org/pub/molecular/poy [WEBBLAST] BLAST [WEBTNT] TNT 33

38 A KØRSELSUDSKRIFTER FRA FORUNDERSØGELSER A Kørselsudskrifter fra forundersøgelser A.1 Testkørsel af POY A.1.1 POY på testmaskine 3 Process took 56 seconds % time seconds usecs/call calls errors syscall write old_mmap brk read munmap open stat readlink close mprotect access fcntl fstat time uname rt_sigaction sigaltstack total real user sys 0m55.944s 0m55.080s 0m0.100s A.1.2 POY på testmaskine 4 Process took 97 seconds % time seconds usecs/call calls errors syscall brk write old_mmap read munmap open stat readlink close fcntl time mprotect fstat uname rt_sigaction sigaltstack semget total real user sys 1m36.354s 1m36.130s 0m0.290s A.1.3 POY på testmaskine 5 Process took 38 seconds % time seconds usecs/call calls errors syscall write brk old_mmap read stat open munmap readlink time close fcntl mprotect fstat uname rt_sigaction sigaltstack 34

39 A KØRSELSUDSKRIFTER FRA FORUNDERSØGELSER A.2 Testkørsel af BLAST total real user sys 0m38.617s 0m38.570s 0m0.030s A.2 Testkørsel af BLAST A.2.1 BLAST på testmaskine 3 execve("/usr/bin/blastall", ["blastall", "-p", "blastn", "-d", "nt", "-i", "tempfasta"], [/* 19 vars */]) = 0 % time seconds usecs/call calls errors syscall read write munmap mmap _llseek old_mmap brk open stat time close clone fstat mprotect rt_sigsuspend pipe socket connect rt_sigaction sigreturn rt_sigprocmask uname getcwd access wait _sysctl fcntl getpid setrlimit getrlimit getuid total real user sys 2m32.498s 0m30.530s 0m5.880s A.2.2 BLAST på testmaskine 4 execve("/usr/bin/blastall", ["blastall", "-p", "blastn", "-d", "nt", "-i", "tempfasta"], [/* 14 vars */]) = 0 % time seconds usecs/call calls errors syscall read write munmap _llseek brk old_mmap open stat rt_sigsuspend mmap time close fstat mprotect connect socket sigreturn pipe clone uname rt_sigprocmask wait rt_sigaction getcwd _sysctl fcntl64 35

40 A KØRSELSUDSKRIFTER FRA FORUNDERSØGELSER A.3 Testkørsel af HMM getrlimit setrlimit semget getpid getuid total real user sys 2m11.028s 0m52.030s 0m6.010s A.2.3 BLAST på testmaskine 5 % time seconds usecs/call calls errors syscall munmap write read stat open poll old_mmap mmap time brk close rt_sigsuspend fstat socket mprotect clone pipe sendto connect rt_sigprocmask readv uname sigreturn rt_sigaction fcntl wait _sysctl recvfrom setsockopt bind getpid ioctl _llseek setrlimit gettimeofday getrlimit getuid total real user sys 1m2.291s 0m0.840s 0m2.470s A.3 Testkørsel af HMM A.3.1 HMM på testmaskine 3 train: execve("./trainanhmm", ["./trainanhmm", "runs/pombe55/ml.0", "-modelfile", "models/pombe00c.imod", "-f", "setup/mlstd.ini"], [/* 18 vars */]) = 0 % time seconds usecs/call calls errors syscall write brk read open munmap old_mmap close fstat time access mprotect ioctl uname getpid

41 A KØRSELSUDSKRIFTER FRA FORUNDERSØGELSER A.3 Testkørsel af HMM total real user sys 27m55.494s 27m48.070s 0m4.380s decode: execve("./decodeanhmm", ["./decodeanhmm", "runs/pombe55/ml.0.bsmod", "-N1", "-pp", "-ps", "-pl"], [/* 18 vars */]) = 0 % time seconds usecs/call calls errors syscall write read brk munmap old_mmap open time close fstat access mprotect ioctl uname total real user sys 8m1.041s 7m58.220s 0m1.070s A.3.2 HMM på testmaskine 4 train: execve("/net/bin/trainanhmm", ["trainanhmm", "runs/pombe55/ml.0", "-modelfile", "models/pombe00c.imod", "-f", "setup/mlstd.ini"], [/* 14 vars */]) = 0 % time seconds usecs/call calls errors syscall brk read close write open munmap old_mmap fstat time mprotect ioctl uname getpid semget total real user sys 38m46.153s 38m33.880s 0m5.310s decode: execve("/net/bin/decodeanhmm", ["decodeanhmm", "runs/pombe55/ml.0.bsmod", "-N1", "-pp", "-ps", "-pl"], [/* 14 vars */]) = 0 % time seconds usecs/call calls errors syscall read write brk munmap old_mmap open fstat close mprotect ioctl uname time semget total real user sys 10m6.720s 10m4.600s 0m0.680s 37

42 A KØRSELSUDSKRIFTER FRA FORUNDERSØGELSER A.3 Testkørsel af HMM A.3.3 HMM på testmaskine 5 train: execve("./trainanhmm", ["./trainanhmm", "runs/pombe55/ml.0", "-modelfile", "models/pombe00c.imod", "-f", "setup/mlstd.ini"], [/* 13 vars */]) = 0 % time seconds usecs/call calls errors syscall brk write read open munmap old_mmap close fstat time mprotect ioctl uname getpid total real user sys 16m53.451s 16m52.010s 0m1.070s decode: execve("./trainanhmm", ["./trainanhmm", "runs/pombe55/ml.0", "-modelfile", "models/pombe00c.imod", "-f", "setup/mlstd.ini"], [/* 13 vars */]) = 0 % time seconds usecs/call calls errors syscall brk write read open munmap old_mmap close fstat time mprotect ioctl uname getpid total real user sys 6m8.785s 6m7.700s 0m0.140s 38

43 B KRAVSPECIFIKATION PÅ KLYNGECOMPUTERE B Kravspecifikation på klyngecomputere Vedlagt findes en kravspecifikation på en computerkonfiguration som skal benyttes til en klyngecomputer. Vi ønsker et tilbud der i størst mulig grad imødekommer vores krav. B.1 Computere Vi skal bruge en pris på to computere dels en Pentium 4 og dels en Celeron. Da vi endnu ikke har fastsat vores krav til L2 cache. Vi ønsker ikke tilbud på AMD processorer. Del CPU Disk Netkort Bios Hukommelse Bundkort Kabinet Krav Pentium 4 (2.4 GHz gerne med tilbud på 400 og 533 MHz front side bus) eller Celeron (2 GHz Northwood). 40 Gb (7200 RPM med lav varmeudvikling) 100 Mbit Fast Ethernet (skal fungere med Linux) Bios indstilling skal kunne gemmes til og gendannes fra diskette 512 Mb DDR (i en klods eller et bundkort med fire slots ) Med PXE (netkort/grafikkort/etc onboard) Small form faktor (gerne A-Open) eller noget lignende Netværk Maskinerne skal sammenkoples med to niveauer af switche. Del Første niveau switche Anden niveau switch Krav 100 Mbit Fast Ethernet (gerne 48 porte) med en 1Gb port. En 1Gb switch (gerne modulær). Levering Da vi skal bruge i omegnen af 200 af disse computere vil vi gerne vide om de kan leveres inden udgangen af året. Tilbud skal sendes til: Claes Petersen System Administrator Zoological Museum Administration Department Universitetsparken 15 DK-2100 Copenhagen Ø Denmark Tel: Mobil:

44 B KRAVSPECIFIKATION PÅ KLYNGECOMPUTERE B.1 Computere Fax:

45 C OVERSIGT OVER TILBUD C Oversigt over tilbud 41

46 C OVERSIGT OVER TILBUD Fyld 42

47 D DELL TILBUD D Dell tilbud 43

48 D DELL TILBUD Fyld 44

49 D DELL TILBUD Fyld 45

50 D DELL TILBUD Fyld 46

51 D DELL TILBUD Fyld 47

52 D DELL TILBUD Fyld 48

53 E EL TILBUD E El tilbud 49

54 E EL TILBUD Fyld 50

55 E EL TILBUD Fyld 51

56 F KØLINGS TILBUD F Kølings tilbud 52

57 F KØLINGS TILBUD Fyld 53

58 F KØLINGS TILBUD Fyld 54

59 F KØLINGS TILBUD Fyld 55

60 F KØLINGS TILBUD Fyld 56

61 G SWITCH TILBUD G Switch tilbud 57

62 G SWITCH TILBUD Fyld 58

63 G SWITCH TILBUD Fyld 59

64 G SWITCH TILBUD Fyld 60

65 G SWITCH TILBUD Fyld 61

66 G SWITCH TILBUD Fyld 62

67 H LINPACK KONFIGURATIONSFIL H Linpack konfigurationsfil H.1 Vores HPL.dat HPLinpack benchmark input file Innovative Computing Laboratory, University of Tennessee HPL.big output file name (if any) 1 device out (6=stdout,7=stderr,file) 3 # of problems sizes (N) Ns 3 # of NBs NBs 2 # of process grids (P x Q) Ps Qs 16.0 threshold 1 # of panel fact 1 PFACTs (0=left, 1=Crout, 2=Right) 1 # of recursive stopping criterium 4 NBMINs (>= 1) 1 # of panels in recursion 2 NDIVs 1 # of recursive panel fact. 2 RFACTs (0=left, 1=Crout, 2=Right) 1 # of broadcast 1 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM) 1 # of lookahead depth 1 DEPTHs (>=0) 2 SWAP (0=bin-exch,1=long,2=mix) 60 swapping threshold 0 L1 in (0=transposed,1=no-transposed) form 0 U in (0=transposed,1=no-transposed) form 1 Equilibration (0=no,1=yes) 8 memory alignment in double (> 0) H.2 Horseshoes HPL.dat HPLinpack benchmark input file Innovative Computing Laboratory, University of Tennessee HPL.out output file name (if any) 1 device out (6=stdout,7=stderr,file) 3 # of problems sizes (N) Ns 3 # of NBs NBs 4 # of process grids (P x Q) Ps 63

68 H LINPACK KONFIGURATIONSFIL H.2 Horseshoes HPL.dat Qs 16.0 threshold 3 # of panel fact PFACTs (0=left, 1=Crout, 2=Right) 2 # of recursive stopping criterium 3 4 NBMINs (>= 1) 1 # of panels in recursion 4 NDIVs 1 # of recursive panel fact. 1 RFACTs (0=left, 1=Crout, 2=Right) 3 # of broadcast BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM) 3 # of lookahead depth DEPTHs (>=0) 2 SWAP (0=bin-exch,1=long,2=mix) 64 swapping threshold (64) 1 L1 in (0=transposed,1=no-transposed) form 1 U in (0=transposed,1=no-transposed) form 1 Equilibration (0=no,1=yes) 16 memory alignment in double (> 0) 64