Projektrapport Oprettelse af et e-mail system til en Internet Service Provider Tema: Distribuerede informationssystemer

Gisp Global Internet Service Provider Projektrapport Oprettelse af et e-mail system til en Internet Service Provider Tema: Distribuerede informationssystemer Aalborg Universitet Master i IIT - Systemadministration

Titel: "GISP Global Internet Service Provider." Tema: "Distribuerede informationssystemer" Projektperiode: 1. september 2002 til 30. maj 2003 Forfatter(e): Axel Kellermann Jørgen Letager Hansen Synopsis: Rapporten beskriver opbygningen af et email system til en Internetudbyder. Først formuleres og afgrænses problemet. Derefter undersøges hvilke produkter og teknikker der kan komme på tale ifølge afgrænsningen. På baggrund af dette beskrives og etableres et testsystem, som testes i forhold til de stillede spørgsmål. Konklusionen er at det kan lade sig gøre at opbygge et Open Source system, der er stort nok til en Internet Service Provider. Den endelige maksimale størrelse kan dog vanskeligt vurderes, da testopstillingen var på gamle uoptimerede maskiner og med klare flaskehalse. Derfor er der foreslået yderligere tests der skal fortages før en endelig systemsammensætning kan afgøres. Ud fra bilagene skulle det være muligt at installere et komplet e-mailsystem. Vejledere: Michael Collin Oplagstal: 7 Sideantal: 45 Bilagsantal og -art: 4 bilag, Afsluttet den: 30. maj 2003 Rapporten må offentliggøres, udlånes eller gengives uden yderligere tilladelse fra forfatterne såfremt det sker med klare kildehenvisninger. GISP Global Internet Service Provider Side 2 af 45

1. Indholdsfortegnelse 1. Indholdsfortegnelse... 3 1.1 Oversigt over figurer... 5 1.2 Oversigt over tabeller... 5 1.3 Oversigt over kodeeksempler... 5 2. Forord... 6 3. Abstract... 7 4. Problemformulering og afgræ nsning... 8 4.1 Problemformulering... 8 4.2 Problemafgræ nsning... 8 5. Beskrivelse af teknikker og begreber fra distribuerede mailsystemer... 9 5.1 En e-mails vej gennem Internettet... 10 5.2 Sikkerhedsaspekter... 11 5.2.1 Netvæ rkssikkerhed...11 5.2.2 Datasikkerhed...11 5.2.3 Fysisk sikkerhed...12 5.2.4 Oppetid - Redundans...12 5.2.5 Skalerbarhed...12 5.2.6 Applikationssikkerhed...12 5.2.7 Ond vilje...13 5.3 Fejltyper... 13 5.3.1 Menneskelige fejl...13 5.3.2 Data fejl...13 5.3.3 Hardware fejl...13 5.3.4 Software fejl...13 5.4 Skalering... 14 5.4.1 Plads på filsystem...14 5.4.2 Netvæ rk...14 5.4.3 Processorkraft...14 5.4.4 I/O...14 6. Analyse... 15 6.1 Beskrivelse af nuvæ rende system... 15 6.1.1 Vurdering af systemet...15 6.2 Arkitektur for nyt system... 15 6.3 Skitsering af Mailsystem arkitektur... 16 6.4 Opbevaring af mail... 17 6.4.1 Cluster løsninger med databaser...17 6.4.2 Valg af opbevaringsmetode...18 6.5 Filsystemer... 18 6.5.1 Parallel Virtual File System...19 6.5.2 Coda...19 6.5.3 OpenAFS...19 6.5.4 GFS...20 6.5.5 OpenGFS...20 6.5.6 Hardwarebaserede systemer...21 6.5.7 Storage Area Network SAN...21 6.5.8 Network File System - NFS...22 6.5.9 Valg af filsystem...22 6.6 Valg af OS... 23 6.7 Valg af MTA til indgående e-mails og SMTP relay... 23 6.8 Valg af database... 23 7. Design... 24 GISP Global Internet Service Provider Side 3 af 45

7.1 Grundlæ ggende overvejelser om design... 24 7.2 Fysisk setup... 24 7.2.1 Filsystem...24 7.2.2 Relaying SMTP...24 7.2.3 Indgående SMTP...25 7.2.4 POP3, IMAP og Web-mailservere...25 7.2.5 Loadbalancing...25 7.2.6 Sikkerhed...25 7.2.7 Administration og overvågning...25 8. Installation af testsystem... 26 8.1 Beskrivelse af forsøgsbetingelserne... 26 8.2 Beskrivelse af arkitektur... 26 8.3 Installationen... 26 8.4 Database design... 27 8.4.1 MySQL master/slave opsæ tning....27 8.4.2 SMTP...27 8.4.3 POP3 og IMAP...27 8.4.4 Web-mail...27 8.5 Test af valgt arkitektur... 28 8.5.1 Forsøg 1...28 8.5.2 Forsøg 2...28 8.5.3 Forsøg 3...29 8.5.4 Forsøg 4...29 8.5.5 Konklusion på forsøg...29 8.5.6 Vurdering af forsøg...29 8.5.7 Vurdering af kapacitet på den valgte arkitektur...30 8.6 Yderligere test... 30 8.6.1 Optimering af storage...30 8.6.2 Optimering af arkitektur...30 8.6.3 Testdata der skal registreres...31 8.7 Beskrivelse af nødprocedurer... 31 8.8 Opgraderingsplan... 31 8.9 Systemvæ rktøjer... 32 8.9.1 Fjernadministration...32 8.9.2 Backup...32 8.9.3 Versioneringssystem...32 8.9.4 Overvågning...33 8.10 Alternative løsnings modeller... 34 8.10.1 Brugere fordelt på serverene...34 8.10.2 Flere tjenester på frontend serverne...35 8.10.3 Kroupware...36 8.10.4 Flad skalering...36 9. Erfaringer og konklusion... 37 9.1 Konklusion... 37 9.1.1 Projektmiljøet...37 9.2 Samlet konklusion.... 38 9.2.1 I forhold til uddannelsen...38 10. Ordforklaring... 39 11. Kilder... 41 11.1 Internet kilder... 41 11.2 Bøger... 44 12. Bilag... 45 GISP Global Internet Service Provider Side 4 af 45

1.1 Oversigt over figurer Figur 5-1: En e-mails vej gennem Internettet... 10 Figur 6-1: Principskitse for mail system... 16 Figur 6-2: Parallel Virtual File System... 19 Figur 6-3: Sistina GFS... 20 Figur 6-4: HDS... 21 Figur 7-1: Oversigt over arkitekturen... 24 Figur 8-1: Testopstilling - findes i større udgave i bilag 4... 26 Figur 8-2: BigBrother Skæ rmdump... 33 Figur 8-3: MRTG Skæ rmdump... 33 Figur 8-4: Alternativ model... 34 Figur 8-5: Flere tjenester pr. frontend... 35 1.2 Oversigt over tabeller Tabel 6-1: Typer af mailopbevaring... 17 Tabel 8-1 Forsøg 1... 28 Tabel 8-2 Forsøg 2... 28 Tabel 8-3 Forsøg 3... 29 1.3 Oversigt over kodeeksempler Kodeeksempel 5-1: Eksempel på mail header... 10 GISP Global Internet Service Provider Side 5 af 45

2. Forord Denne rapport er et resultat af to studerendes arbejde på 3. år på Master-uddannelsen i Industriel Informationsteknologi med speciale i systemadministration. (MII) Rapporten bygger videre på gruppens arbejde fra 2. år af uddannelsen, som omhandler opbyggelsen af en ISP (Internet Service Provider). I denne rapport blev beskrevet hvordan GISP (Global Internet Service Provider) blev opbygget med valg af styresystemer og applikationer. Næ rvæ rende rapport omhandler opbygningen af et skalerbart mailsystem til denne Internetudbyder (ISP). Det forudsæ ttes at læ seren har kendskab til rapporten 1 fra 2. år eller et indgående kendskab til de teknikker der benyttes på Internettet, samt UNIX. Da der er flere henvisninger til sidste års rapport er den vedlagt som bilag Rapporten er opbygget på den måde at der indledes med problemformulering og afgræ nsning, hvorefter der laves en vurdering af systemet fra sidste rapport. Derefter beskrives arkitekturen for et nyt system. Til sidst beskrives hvorledes systemet opbygges og hvordan implementationen og test gennemføres. Efter indholdsfortegnelsen er der en liste over henholdsvis figurer, tabeller og kodeeksempler, der indgår i selve rapporten. Bagest i rapporten findes en ordforklaring og en liste over kildehenvisninger. Til rapporten hører fire bilag: Bilag 1: Brugerhåndbog. I dette bilag er der en beskrivelse til brugere, hvordan e- mail fungerer forklaret i almindelige ord, samt hvordan man opfører sig som ansvarlig bruger med hensyn til brug af e-mail med speciel henblik på spam og vira. Derudover er der en beskrivelse af hvordan man sæ tter en K-mail klient op, hvor de enkelte begreber forklares. Bilag 2: Driftshåndbog. Dette er en introduktion af nogle væ rktøjer i Unix, der kan bruges til administration af systemet. Bilag 3: Installationshåndbog. I dette bilag er der beskrivelser af alle installationer, der er foretaget i forbindelse med opbygningen af dette mailsystem. Med denne skulle det væ re muligt at lave en fæ rdig installation af et tilsvarende system Bilag 4: Systembeskrivelse. I dette bilag beskrives det testsystem, der er opbygget i forbindelse med udarbejdelsen af dette projekt. Dette bilag indeholder også testdata, samt konklusioner på den test, der blev foretaget. Bilagene er skrevet således at disse kan læ ses uafhæ ngigt af hoveddokumentet. Dette kan nogle få steder give gentagelser. I opbygningen af systemerne bruges der fortrinsvis frit tilgæ ngeligt software. Denne type software har forskellige typer af licenser, som man skal væ re opmæ rksom på ved brugen af softwaren. De licenstyper, der er næ vnt i rapporten er kort forklaret i sidste års rapport. Vi takker TDC samt Sol og Strand Feriehusudlejning A/S for donering af udtjent udstyr til en testopstilling 1 Rapporten fra 2. år er offentligt tilgæ ngelig på adressen http://gisp.boruphede.dk GISP Global Internet Service Provider Side 6 af 45

3. Abstract. This report describes the building of an email system for an Internet Service Provider. The main goal of this report is to verify that you can build a large e-mailsystem for an Internet Service Provider using Open Source. The different products and techniques known to the authors are described and a test system is build. This is tested for capacity in order to answer the raised questions. The conclusion is that it is possible to build a system large enough for a Internet Service provider, but the size of a final system can not be estimated because the test system was build out of old unoptimized hardware with obvious bottlenecks. The appendices (written mostly in Danish) are written in a way that makes you able to build a system of your own. GISP Global Internet Service Provider Side 7 af 45

4. Problemformulering og afgrænsning 4.1 Problemformulering Projektet udarbejdes som en del af uddannelsen Master of Industrial Information Technology på linien systemadministration. Ifølge studieordningen skal projektet indeholde aspekter inden for sikkerhed, planlæ gning, automatisering og integration På andet studieår blev der opbygget en Internet Service Provider GISP. Dennes e-mail del blev ikke implementeret, derfor ønskes opbygget et skalerbar, driftsikker system der er sikret mod uønsket adgang. Dette skal gøres ved at distribuere systemerne over flere maskiner, sikre at maskiner hurtigt kan erstattes ved nedbrud, samt ved overvågning af systemerne. Derudover sker der ske en sikring af systemerne ved brug af en Firewalls. Systemerne vil i videst muligt omfang blive baseret på Open Source. 4.2 Problemafgrænsning ISPen fra 2. studieår udbød følgende serviceydelser: Internetadgang, mailadgang og Webhotel for brugerne, samt en selvbetjeningsdel, hvor kunderne selv kunne oprette nedlæ gge og konfigurere de enkelte services. Mail-delen blev ikke fæ rdigimplementeret pga. problemer med det valgte software. Dette projekt vil derfor behandle opbygningen af et mailsystem med speciel væ gt på arkitekturen, samtidig med at sikkerheden og skalerbarheden sikres. Dette vil gøres ved at forsøge besvarelse af følgende spørgsmål: Kan der opbygges en skalerbart mailsystem med Open Source programmer? På hvilken måde skal mails gemmes for at systemet er hurtigt, skalerbart, har gode oppetider og kan sikres med sikkerhedskopiering, der kan reetableres hurtigt? Hvor mange brugere kan systemet håndtere med den givne konfiguration? Hvor mange mails kan systemet håndtere med den givne konfiguration? Hvor stort kan systemarkitekturen skaleres til? Selvbetjeningsdelen implementeres ikke da det umiddelbart vil væ re muligt at anvende det tidligere udviklede selvbetjeningsinterface. GISP Global Internet Service Provider Side 8 af 45

5. Beskrivelse af teknikker og begreber fra distribuerede mailsystemer. I dette kapitel beskrives de teknikker og begreber man støder på under analysen af et distribueret e-mailsystem. I dette kapitel vil der blive behandlet begreber indenfor: E-mailens vej igennem Internettet Sikkerhed Fejltyper Skalering Omkring mailsystemer er der blevet taget et enkelt afsnit med fra 2. års rapporten, der beskriver en e-mailsystems vej igennem Internettet. Dette er taget med for at give et overblik over hvilke teknikker der bruges for at route en e-mail fra afsender til modtager. Ud over dette behandlede samme rapport det system der benyttes til udvikling og godkendelse af tekniske standarder til Internettet RFC-systemet (RFC = Request For Comment). 2. år rapport er vedlagt som bilag til denne rapport. GISP Global Internet Service Provider Side 9 af 45

5.1 En e-mails vej gennem Internettet. (Nedenstående figur stammer fra GISP1 rapporten) Afsender Udgående MTA for afsender server Indgående MTA for modtager Modtagers mailboks Modtager Figur 5-1: En e-mails vej gennem Internettet Her er et eksempel på en e-mails vej gennem Internettet (Kan ses ved at vise header i modtagers e-mail klient) Headeren skal læ ses nedefra op. Eksemplet viser en e-mail sendt fra en maskine ved navn let2 med afsenderadressen jlha@post4.tele.dk til modtageradressen jlha00@itorg.auc.dk, let2 bruger fepz.post.tele.dk som udgående MTA. fepz.post.tele.dk videresender mailen til mira.itorg.auc.dk (der er Indgående MTA for itorg.auc.dk. jlha00@itorg.auc.dk er sat op til at videresende al post til jorgen@letager.dk Derfor sender mira.itorg.auc.dk mailen videre til fepf.post.tele.dk Mailen bliver så placeret i jorgen@letager.dk mailboks hvorfra den kan hentes med f.eks. pop3 Return-Path: <jlha@post4.tele.dk> Received: from mira.itorg.auc.dk ([130.225.192.37]) by fepf.post.tele.dk (InterMail vm.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20020403131148.QPME16199.fepF.post.tele.dk@mira.itorg.auc.dk> for <jorgen@letager.dk>; Wed, 3 Apr 2002 15:11:48 +0200 Received: by mira.itorg.auc.dk with Internet Mail Service (5.5.2448.0) id <GP12M0DL>; Wed, 3 Apr 2002 15:22:17 +0200 Received: from fepz.post.tele.dk ([195.41.46.133]) by mira.itorg.auc.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id GP12M0DK; Wed, 3 Apr 2002 15:22:15 +0200 Received: from let2 ([80.62.244.168]) by fepz.post.tele.dk (InterMail vm.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020403131144.TVTY6796.fepZ.post.tele.dk@let2> for <jlha00@itorg.auc.dk>; Wed, 3 Apr 2002 15:11:44 +0200 Message-ID: <003d01c1db11$5fdd7340$0c01a8c0@let2> From: "Jorgen Letager Hansen" <jlha@post4.tele.dk> To: <jlha00@itorg.auc.dk> Subject: test af header Date: Wed, 3 Apr 2002 15:13:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Kodeeksempel 5-1: Eksempel på mail header GISP Global Internet Service Provider Side 10 af 45

5.2 Sikkerhedsaspekter Sikkerhed i forbindelse med IT-systemer af denne type dæ kker over følgende aspekter: - Netvæ rkssikkerhed sikkerhed for at uønskede udefrakommende gæ ster ikke kan træ nge ind og ødelæ gge systemerne eller bruge dem til andre formål end planlagt - Datasikkerhed sikkerhed for at de opbevarede data er tilgæ ngelige og at de kan reetableres ved eventuelt nedbrud - Fysisk sikkerhed sikkerhed for at uønskede personer ikke kan få adgang til de fysiske systemer - Driftssikkerhed sikring af at systemerne er tilgæ ngelige i de perioder, det er planlagt. For ISP er er det typisk 24 timer i døgnet 7 dage om ugen - Skalerbarhed sikkerhed for at systemet kan udbygges også til fremtidige belastninger og evt. til andre serviceydelser uden at systemet nødvendigvis skal redesignes og således at en udbygning kan ske uden væ sentlige forstyrrelser for kunderne - Applikationssikkerhed sikkerhed for at det brugerid, der bruges til en applikation lige præ cis har de rettigheder, der er nødvendige for at drive den applikation, så eventuelle hackere kan lave så lidt skade som muligt ved en overtagelse af applikationen - Ond vilje Disse aspekter vil blive beskrevet yderligere i det følgende. 5.2.1 Netværkssikkerhed. Siden menneskehedens start har der altid væ ret personer, der misbruger andres åbenhed. Dette gør at man ikke kan eksponere et system ud til Internettet uden at sikre det mod uønsket adgang og brug. Dette gøres med en såkaldt firewall og ved at opdatere de bagvedliggende systemer således at alle kendte svagheder udbedres så snart det er muligt. I et stort system, som en ISP ers mailsystem vil en FireWall-funktion ofte væ re bygget sammen med en funktion for fordeling af ressourcer (loadbalancer og portforwarder), da disse funktioner begge skal vide noget om protokoltype, destination m.m., som er oplysninger der ligger i de enkelte datapakker 5.2.1.1 Mailfiltrering Ved at filtrere mails, hvor disse kommer ind i systemet, er det muligt at mindske antallet af spammails og vira, som når frem til kunderne. Dette gøres ved at integrere antispam/virus systemer med smtp softwaren. Typiske vil antispam systemerne lave et opslag i lister over kendte syndere, et stort antal servere på nettet er listet fordi de i større eller mindre omfang har medvirket til udsendelse af spam, eller scanne e-mail efter hvor mange kendte spam ord der er i e-mailen og udfra dette tildele mailen et spam index som modtageren kan agere ud fra. Dette spam index indskrives i mailens header. Antivirus programmerne vil normalt scanne e-mailen efter kendte mønstre. Såfremt man væ lger at bruge disse må man væ re forberedt på at der også vil blive afvist et mindre antal legale e-mails. Samme systemer kan bruges til kundernes udgående e-mails, hvorved spredningen af virus fra kunderne mindskes. 5.2.2 Datasikkerhed Når man som ISP er opbevarer data for kunder er det af yderste vigtighed at disse data ikke på nogen måde kan gå tabt. Derfor er det væ sentligt at data sikres mod tab ved: GISP Global Internet Service Provider Side 11 af 45

- at tage sikkerhedskopier med jæ vne mellemrum, kontrollere at de virker og at de kan indlæ ses hurtigt og effektivt - at disk- og filsystemer er sikret mod nedbrud og datafejl Som ISP er det vigtigt at tage stilling til følgende forhold og tilrette kundevilkårene derefter. Sikring af data i tilfæ lde af nedbrud. Hvor meget data er det acceptabelt at miste i tilfæ lde af hardwarenedbrud. Sikring mod datafejl. Hvordan sikres bedst muligt med datafejl (både umiddelbart synlige og lurende fejl) Hvordan skal applikationerne testes inden idriftsæ ttelse? 5.2.3 Fysisk sikkerhed I sikkerhedsdebatten er det ofte et overset problem at det også er vigtigt at sikre systemerne mod fysisk adgang. Der kan laves mange sikkerhedssystemer i softwaren, men der er stort set ikke noget system der kan modstå når den uønskede person har fysisk adgang til systemerne. Denne fysiske adgang kan ofte passes sammen med at systemerne placere i omgivelser, der er brandhæ mmende og kølige, men alligevel så tilgæ ngelige at systemadministratorer har relativ nem adgang til dem for daglig overvågning og vedligeholdelse. I den forbindelse er det vigtigt også at sikre systemadministratorens væ rktøjer og lokaler. 5.2.4 Oppetid - Redundans Der skal tages stilling til hvilken oppetid systemet skal have. Ønskes en høj oppetid skal systemet opbygges redundant. Der bør tages stilling til forhold som strømforsyning, elforsyning, bygninger m.m. Ved planlæ gningen af et system af denne type, skal man vurdere hvilke væ rst tæ nkelige scenarier man kan forestille sig og hvilke af disse man vil forebygge, samt vurdere økonomien i forhold til sikkerheden. Principielt kan det sige at udgiften for at have en oppetid på 100,00% er uendelig, men prisen på en oppetid på f.eks. 98% er væ sentlig lavere, men valget ender sandsynligvis imellem disse to procenter. Til GISP ønskes et fuldt redundant miljø hvor det ikke er muligt for en enkelt hardwarefejl at påvirke systemets funktionalitet. Redundansen er så vidt muligt søgt opnået ved at tilføje systemet yderligere ressourcer således at evt. fejl kun vil betyde nedbragt ydeevne. 5.2.5 Skalerbarhed Ved oprettelse af systemer af denne type er det vigtigt at have planer for hvordan man udskifter udtjent udstyr og hvordan man tilføjer ekstra kapacitet før græ nserne nås. Her er det også vigtigt løbende at overvåge kapaciteten så opgraderingersplanlæ gning er muligt. 5.2.6 Applikationssikkerhed Frontend maskinerne opbygges således at det underlæ ggende operativsystem er ens. Her på kører en enkelt applikation. Hver applikation skal have tildelt sin egen unikke brugerid således at det er muligt at flytte applikationer mellem frontendservere såfremt der er behov for det. Dette brugerid skal have så få rettigheder, som muligt, da man derved kan begræ nse skaderne ved hackerangreb og evt. dårlig software. GISP Global Internet Service Provider Side 12 af 45

Med en sådan opsæ tning vil det også væ re muligt at køre alle applikationerne på den samme frontend indtil maskinen bliver tilstræ kkeligt belastet 5.2.7 Ond vilje svæ rest at sikre sig imod er ond vilje hvor enten en intern eller ekstern person på en eller anden vis har adgang til systemet (en legal eller illegal adgang) og ønsker at skade udbyderen. Denne person kan lave datafejl og skjule disse således at der løbende sker datatab/dataforfalskning. Denne type fejl kan kun undgås ved at holde en streng kontrol med adgang til systemerne og løbende overvåge hvad der sker på serverne. 5.3 Fejltyper Følgende fejltyper kan alle medføre datatab, men det er vidt forskellige ting der skal til for at afhjæ lpe fejlene. 5.3.1 Menneskelige fejl Dette er klart en af de væ rste former for fejl, da fejlene vil blive repliceret ud på alle serverne. Et eksempel på denne slags fejl er en sysadm. der kommer til at køre rm rf * i et forkert bibliotek eller på en forkert server. Som regel er fejlen dog så markant at det opdages øjeblikkeligt og så er det med at få gang i backuppen. Denne type fejl er utroligt svæ r at gardere sig imod, men det understreger at et system ikke er mere sikkert end dem der arbejder med det. 5.3.2 Data fejl Data fejl kan også væ re noget af en udfordring da de kan væ re svæ re at opdage og sandsynligvis er ens på hele systemet. Såfremt data ikke er ens grundet datafejl, skal man udover opdage fejlen også finde ud af hvilke data der er de rigtige. 5.3.3 Hardware fejl Hardwarefejl er typisk nemme at konstatere og indkredse. Dette betyder at disse fejl er ret nemme at korrigere for, samt hvis systemet er redundant vil en fejl væ re vanskelig at mæ rke for brugerne af systemet. Da disse fejl ikke eksisterer under en funktionstest af det samlede system er det vigtigt at overvåge de enkelte delsystemer for disse fejl. 5.3.4 Software fejl Software fejl kan inddeles i 2 typer, den ene er hvor programmet går ned og blot skal genstartes. Den anden type er hvor software gør noget forkert ved data. Førstnæ vnte er som hardwarefejl mens den sidste giver datafejl. GISP Global Internet Service Provider Side 13 af 45

5.4 Skalering Når et system er bygget til at skalere er det med baggrund i forventning om at systemet løbende skal udbygges. Tidspunktet for denne udbygning bestemmes af hvor belastet systemet er. Denne belastning skal derfor måles. Et komplekst system er vanskeligt at give en entydig målestok for, men i forhold til et system, som det der er beskrevet i denne rapport, er det væ sentligt at fokusere på hvor flaskehalse kan væ re og derudfra bestemme om systemet skal udbygges. For at kunne overvåge flaskehalsene i systemet er det vigtigt at væ re opmæ rksom på følgende forhold 5.4.1 Plads på filsystem Da det er af afgørende betydning for systemet at kunne skrive til filsystemerne bør man væ re meget opmæ rksom på at disse ikke løber fuld. Bemæ rk også at de filsystemer som bruges af operativsystemet er vigtige. (Der bør f.eks. væ re god plads til logfiler, ligesom der løbende skal ryddes op i disse.) 5.4.2 Netværk Dette vil forholdsvis let kunne opgraderes, men man kan ikke forvente at netvæ rket kan udnyttes 100% og det er derfor vigtigt at have en god del ledig kapacitet. 5.4.3 Processorkraft I et distribueret miljø kan den samlede processorkraft let opgraderes, mens der i enkeltstående systemer vil væ re behov for at skifte væ sentlige dele ud (eks. kan det væ re nødvendigt at skifte bundkort.) Enkeltstående systemer vil desuden have en øvre græ nse for hvad der er muligt. 5.4.4 I/O I/O til netkort og disksystemer er også normalt et af de steder hvor serverne løber tør fra ressourcer. Som med processorkraft er det ofte et spørgsmål om at skulle udskifte væ sentlige dele på serverne. GISP Global Internet Service Provider Side 14 af 45

6. Analyse I det følgende analyseres og væ lges produkter for de enkelte delsystemer. 6.1 Beskrivelse af nuværende system Det nuvæ rende system består af en enkelt server med alle funktionaliteter samlet. Der anvendes Courier til hele maildelen og MySQL til brugerinformation. Courier anvender maildir til mailopbevaring. Det hele kører på en standard PC (Pentium II 266 MHz med 128 MB RAM) med SCSI-disk på 4 GB med et standard filsystem. Systemet er installeret på en FreeBSD 4.5 med programmerne hentet fra portscollection. 6.1.1 Vurdering af systemet Systemet er bygget op som et uddannelsesprojekt og er ikke dimensioneret til produktion. Både kapaciteter og hastigheder ligger langt under standard Pc er i dag. Systemet blev ikke testet for kapacitet mht. modtagelse af mail, da mailsystemet ikke er fungerende. Ved en test af et nogenlunde tilsvarende system kunne der modtages ca. 10.000 mails pr. time. Denne rapport vil videre behandle hvordan et produktionssystem kan opbygges og hvilke overvejelser, der skal gøre før installation og idriftsæ tning. Tidligere erfaringer viser at lignende systemer kan bæ re 5-10 tusinde brugere. 6.2 Arkitektur for nyt system Der er lagt stor væ gt på at få en arkitektur, som er overskuelig, nem at vedligeholde, udbygge og fejlfinde på:. Arkitekturen har følgende formål: - Skalerbarhed hvis det skal væ re muligt at skalere til meget store kundemasser vil det væ re nødvendigt at kunne skalere både horisontalt og vertikalt. Da de fleste systemer kan skalere vertikalt fokuseres der i det følgende på at finde et system som også kan skalere horisontalt. - Driftssikkerhed De enkelte komponenter kan dubleres og hvis det ikke er muligt skal der ofres mere på driftssikre komponenter. Ved dublering skal der etableres system til fordeling af belastningen GISP Global Internet Service Provider Side 15 af 45

6.3 Skitsering af Mailsystem arkitektur Ud fra disse kriterier ønskes opbygget et system der består af følgende komponenter: - Load balancer - system/apparat, der kan fordele trafik efter type og evt. efter underliggende systemers belastning - SMTP-relay der er kundernes udadgående mailserver. Den vil videresende mails til modtagende mailservere (MTA) hvad enten det er egne eller andre ISP er eller organisationer - MTA til indgående e-mail SMTP-server der fordeler mail til kundernes konti - Mailstore Disk- og filsystem til opbevaring af mails - IMAP server Server til betjening af kunder, der har mails liggende hos udbyderen - POP3 server Server der betjener kunder, der henter mails ned på egen maskine - Web-server til web-mail Server til betjening af kunder der lader mails ligge på serveren eller kunder der er på rejse - Web-server til provisionering Server til brug for oprettelse, æ ndringer og nedlæ ggelse af kunder og services for den enkelte kunde (ikke implementeret i dette projekt). - Database til brugerinformation De primære tjenester er de tjenester, der er direkte eksponeret til kunderne. De sekundære tjenester er de tjenester, der bruges bag ved de primæ re, men stadig kunderettede. Såfremt en sekundæ r tjeneste er nede vil systemerne stadigt virke, men der vil væ re forsinkelser. (eks. indgående smtp) De tertiæ re tjenester er de vedligeholdelsessystemer, der bruges af systemadministratorer til overvågning af kapaciteter og helbred på systemerne. Disse tjenester vil ikke påvirke de kundevendte direkte, men det kan påvirke mulighederne for f. eks. at skifte password. Figur 6-1: Principskitse for mail system GISP Global Internet Service Provider Side 16 af 45

6.4 Opbevaring af mail. Da opbevaringen af e-mail er afgørende for hvilke systemer der kan anvendes til henholdsvis modtagelse af e-mails og til bruger interfaces er det meget naturligt at starte med at undersøge mulighederne for mail opbevaring. Der er flere grundlæ ggende muligheder for mail opbevaring, som skitseres i nedenstående skema Type Beskrivelse Fordele Ulemper Programmer Mbox, mail opbevares i en fil pr. brugermappe Få filer pr. bruger Såfremt der er mange e- mails kan det tage en del ressource at skulle søge filen igennem for at finde den rette e-mail. Med mange brugere på systemet vil der væ re Postfix, Qmail, Exim Maildir, Database et directory pr. brugermappe Denne kan laves i tre varianter: Mail og vedhæ ftede filer opbevares i database Mail opbevares i database og vedhæ ftede filer opbevares i filsystemet Mail og vedhæ ftede filer opbevare i filsystemet, men placeringen findes i databasen Tabel 6-1: Typer af mailopbevaring Lille mulighed for konflikter mellem skrivninger, da chancen for at der skal skrives til samme fil fra forskellige processer er usandsynlig lille Alle informationer samlet på et sted mange filer Mange filer pr. bruger Ved evt. restore af systemet vil dette væ re en udfordring. Enten vil databasen væ re meget stor eller også vil der væ re rigtig mange filer. Courier, Postfix, Exim, Qmail Dbmail http://www.dbmail.org For at kunne skaleres i horisontal retning skal systemerne skalere således at de adgangstyper der bruges kan serviceres. I et mailsystem, der f.eks. hovedsagligt er baseret på POP3 afhentning af mails vil stort set samtlige adgange væ re æ ndringer af data. Hvis data opbevares i en database skal denne kunne skaleres således at alle noder i en evt. cluster kan håndtere dataæ ndringer. I Open Source miljøet har vi set et system Dbmail fra IC&S i Holland - der baserer sig på databaseopbevaring af mails. Dbmail kan køre på enten en MySQL eller en PostgreSQL database. Derfor er det vigtigt at se på disse programmers muligheder for skalering. 6.4.1 Cluster løsninger med databaser Et cluster er en samling af maskiner, der samarbejder om en opgave og som udadtil virker som en maskine. Der sker meget på clusterløsninger for tiden, så situationen kan meget vel have æ ndret sig meget om f.eks. et år. Der findes forskellige typer af cluster: - Regneclustere Cluster, der bruges til f.eks. modelberegninger m.m. Til dette formål er der lavet mange væ rktøjer i dag, således at man kan bruge mange små maskiner og dermed opnå supercomputerfunktionaliteter. GISP Global Internet Service Provider Side 17 af 45

- Fil-cluster Cluster hvor flere maskiner danner et fæ lles filsystem. Der findes flere eksempler på dette, hvor fokus dog kan væ re forskelligt enten på sikkerhed, på performance eller på ønsket om at opbevare store mæ ngder af data - Database-cluster Denne cluster type er den svæ reste, da database af natur er meget dynamiske og det derfor er vanskeligt at holde flere sæ t af data opdaterede atomisk. Det ses bl.a. af at flere af database-clustre kører på fæ lles filsystemer, således at der kun er et sæ t af data. I det følgende beskrives kort både nogle OpenSource databaser og nogle kommercielle, med henblik på den bagvedliggende teknik for deres cluster -løsninger. 6.4.1.1 MySQL Bruger master-slave opsæ tning. Her sker alle skrivningerne til masteren mens læ sningerne sker fra slaverne. Dette virker fint såfremt der er væ sentlige flere læ sninger end skrivninger. (Masteren skal kunne håndtere alle skrivningerne samt servicere alle slaverne.) Såfremt masteren går ned opgraderes en af slaverne til master 6.4.1.2 PostgreSQL Har en master, og en hot standby. På PostgreSQL hjemmeside foreslås det at man opdaterer database ved hjæ lp af rsync (fil replikering i UNIX) til en standby maskine og ved nedbrud indsæ ttes denne i systemet. 6.4.1.3 DB2 Databasen er installeret på en eller flere maskiner, der forbinder til en filer der servicere disse med databasefilerne. 6.4.1.4 Oracle Bruger sit eget system til at kommunikere mellem noderne. Går en node ned tager en anden node over. Systemet er bygget op som et cluster med at antal Linux-maskiner med et fæ lles SAN-disksystem, således at det er samme db-filer der arbejdes med 6.4.2 Valg af opbevaringsmetode Ingen af ovenstående OpenSource systemer anses som væ rende brugbare til store e- mailsystemer, hvor e-mails gemmes i databasen. Dette begrundes med at der i et mailsystem altid er mange æ ndringer af data. Mails kommer ind i systemet (skrives), for derefter at blive hentet og slettet. Derfor væ lges det ikke at anvende en database til opbevaring af mails. Dette giver to muligheder for opbevaring af mails: Maildir eller Mbox. Hvis man følger diskussionen på OpenSource hjemmesiderne kan det ses at Mbox er den oprindelige metode for opbevaring af mails, men den har vist sig upraktisk når systemerne bliver større og der sker både læ sninger og skrivninger på samme tid. Flere af hjemmesiderne anbefaler Maildir for større systemer. 6.5 Filsystemer Det vigtigste i hele systemet er diskserveren da denne skal kunne håndtere adskillige samtidige forbindelser fra både smtp, pop3, imap og web-servere. GISP Global Internet Service Provider Side 18 af 45

Kravene til et filsystem er flg. Performance systemet skal kunne følge med i performance. Redundant såfremt en del af systemet gå ned skal al data stadigt væ re til rådighed. Skalerbart når ekstra kapacitet er nødvendigt skal det væ re muligt at udvide systemet uden nedetid. Af kandidater er bla. flg. distribuerede filsystemer. 6.5.1 Parallel Virtual File System Har en del af disse funktionaliteter men mangler redundans, er der derfor bare en node som er nede vil al data som er hel eller delvis placeret på denne node væ re nede. Alle forespørgsler går til en management node som videresender forespørgselen til en I/O node. Figur 6-2: Parallel Virtual File System 6.5.2 Coda Codas styrke ligger i cache, således at klienterne cacher data fra hovedfilserveren. Cache er en fordel, når mange læ ser de samme data, men i et mailsystem vil data kun blive læ st få gange. Derfor er en læ se-cache ikke interessant for et mailsystem. Er der en markant overvæ gt af brugere som anvender IMAP, der dermed efterlader posten på serveren vil cache give mening, da der så vil væ re en anden væ gt mellem læ sninger og skrivninger 6.5.3 OpenAFS OpenAFS er igen et system hvis store styrke ligger i et distribueret miljø med fokus på cache, således foregår alle skrivning til en master. Systemet er dog opbygget hierarkisk hvor hver del har sin egen master. OpenAFS er meget udbredt i universitetsverden hvor styrken er at man kan nå sine filer fra hele Internettet vha. en klient som fås til de fleste operativsystemer. Samtidigt anvender OpenAFS kerberos til bruger validering som gør at det er sikkert at anvende på et åbent net. GISP Global Internet Service Provider Side 19 af 45

6.5.4 GFS GFS er et kommercielt produkt hvor fokus er skalerbarhed og performance. Oprindeligt var GFS open source, men er nu et rent kommercielt produkt. Sistina, der udvikler GFS, vendte ikke tilbage på en henvendelse om en test licens og produktet er derfor ikke undersøgt næ rmere. Figur 6-3: Sistina GFS GFS er journalised filesystem baseret på et SAN hvor alle serverne har adgang til den delte diskressource. 6.5.5 OpenGFS OpenGFS er baseret på den oprindelige kode til GFS før denne blev lukket. Desvæ rre er dokumentation mangelfuld og svæ rt at finde hoved og hale i. Derfor blev vi desvæ rre nødt til at fravæ lge en dybdegående test af OpenGFS. Det fremgår f. eks. ikke af dokumentation hvilke pakker der skal væ re installeret før OpenGFS kan installeres.) GISP Global Internet Service Provider Side 20 af 45

6.5.6 Hardwarebaserede systemer De hardware baserede systemer fungere på den måde at de med specielt sammensat hardware styrer et antal diske som kan stilles til rådighed for klienterne via nfs, SCSI interface, iscsi, fiber eller lign. Systemet skjuler diskenes fysisk layout for klienterne og stiller enten rå diskplads eller virtuelle diske til rådighed for klienterne. De 3 væ sentligste udbydere af hardware baseret storage er Hitachi HDS (Hitachi Data Systems) EMC Netapp (Network appliance) Figur 6-4: HDS Fordele Skalering af disksystemet foregår på dertil specielt udviklet systemer Kan skalere til meget store datamæ ngder Kan bruges til at opnå redundans på tvæ rs af forskellige fysiske lokaliteter. 2 ens systemer kan placeres adskilt med spejlede data) Rigtig opsat kan opnås en meget høj performance. Flere servere kan tilgå de samme data Som oftest er der backupfunktioner indbygget i systemet således at man f.eks. kan tage et snapshot af et komplet system. Ulemper Pris, GB prisen er væ sentlig dyre end på standard systemer Administrationskræ vende. Skal performance udnyttes optimalt kræ ver det at systemet sæ ttes 100% korrekt op. (Klienten skal ligeledes opsæ ttes så det er muligt at æ ndre diskstørrelsen) Bundet til en leverandør, da systemerne er fuldstæ ndig proprietæ re skal alle stumper købes hos leverandøren (Som ofte helt ned til de fysiske diske som er i boksen) 6.5.7 Storage Area Network SAN Storage Area Network er en kraftigt voksende teknik i dag. SAN er oftest en hardwareboks som beskrevet ovenfor, der sæ dvanligvis bygger på et fibernetvæ rk. Ressourcen, der stilles til rådighed, kan enten væ re for en enkelt server og virke som en disk eller det kan væ re et filsystem, der stilles til rådighed for flere servere, der bruger de samme ressourcer. Et SAN er optimeret til at væ re hurtigt og sikre hurtig backup, samtidig med at det er fleksibelt med hensyn til allokering af ressourcer og yderligere udbygning. Prisen pr. GB. er høj men ydelse, fleksibilitet og sikkerhed svarer til prisen. GISP Global Internet Service Provider Side 21 af 45

6.5.8 Network File System - NFS NFS er et filsystem der er udviklet til UNIX, hvor en UNIX-maskine kan mounte et filsystem fra en anden maskine og benytte det som sit eget. Da NFS blot er et spørgsmål om at dele et eksisterende filsystem, er der ikke i selve NFS indbygget redundans, denne skal sikres på et lavere niveau. NFS er ikke speciel optimeret til høj ydelse, dog findes der specielle hardware bokse som er optimeret som NFS servere. 6.5.9 Valg af filsystem Desvæ rre har det ikke væ ret muligt at finde et open source baseret system som opfylder de opsatte krav og som samtidigt har en rimelig dokumentation. Men da netop performance af filsystemet er afgørende for performance af hele systemet, bør man netop nøje overveje om det er et gratis system der skal væ lges eller det er et kommercielt som er bedre. Den besparelse der opnås kan lynhurtigt blive spist af større udgifter til servere andre steder i systemet. NFS er klart ikke optimeret til et system som dette, men da fokus er at få testet arkitekturen bruges der en NFS server til testen. Vi er dog overbevist om at f.eks. OpenGFS ville kunne anvendes til systemet såfremt der er den fornødne tid til at sæ tte serverne op. Alternativt vil et SAN væ re det rette valg. Øvrige komponenter i systemet søges gjort så simple som muligt, da de ikke skal opbevare data, men de skal kunne skalere horisontalt. GISP Global Internet Service Provider Side 22 af 45

6.6 Valg af OS. Som tidligere næ vnt er dette ikke et af analysens hovedfokusområder, og valget sker af rent praktiske hensyn. Inden en egentlig idriftsæ ttelse vil det væ re nødvendigt at foretage en dybdegående analyse med henblik på at finde det optimale operativsystem i forhold til de stillede krav. Til test af den valgte arkitektur væ lges Redhat da dette er det mest udbredte Freeware OS og dermed stort set altid er understøttet og med de bedste vejledninger. Til produktionsformål er det dog tvivlsomt at valget vil falde på Redhat da deres fokus er brugerflader og hurtige opdateringer. Der er f.eks. udkommet 2 major releases mens arbejdet på dette projekt er foregået. 6.7 Valg af MTA til indgående e-mails og SMTP relay Da arkitekturen er meget åben, kan stort set alle MTA er på markedet anvendes. Der væ lges Postfix da denne er meget udbredt og kan bruge database til brugeroplysninger. 6.8 Valg af database Til opbevaring af brugerinformation væ lges en MySQL database da denne ret simpelt kan opsæ ttes i en master / slave opsæ tning hvor skrivningerne sker til masteren og alle læ sningerne sker fra slaverne. Da skrivninger er begræ nset til æ ndringer / nyoprettelser af kundeoplysninger vil det væ re rimeligt at antage at masteren kan følge med til dette, samt at opdatere slaverne. Denne maskine vil kun kunne skalere vertikalt mens resten af systemet (slaverne) kan skalere både vertikalt og horisontalt. Selve e-mail systemet æ ndre ikke i data. GISP Global Internet Service Provider Side 23 af 45

7. Design I dette kapitel vil der blive gjort rede for de overvejelser, der skal gøres ved design af et større mailsystem med de teknikker, der er beskrevet i det foregående kapitel. 7.1 Grundlæ ggende overvejelser om design For at lave de enkelte enheder af designet, så simple som muligt, samtidig med at gøre systemet så overskueligt og gennemskueligt i forbindelse med fejlfinding vil hver enkelt maskine i systemet så vidt muligt kun have en funktion. Dette har også den fordel at den enkelte maskine kan koncentrere sig om opgave frem for at bruge ressourcer på processkifter mellem de enkelte funktioner 7.2 Fysisk setup 7.2.1 Filsystem Der oprettes et delt filsystem til alle dataserverne. Dataserverne der deler filsystem er i dette tilfæ lde indgående SMTP, POP3, IMAP og Web-mail servere. Databaseserverne har ikke fæ lles filsystem, men kan evt. dele et @ disksystem også med dataservere, men det skal bero på en vurdering af økonomi kontra ydelse og sikkerhed. Da prisen for fæ lles disksystemer er høj vurderes det at det vil væ re mest hensigtsmæ ssigt i forhold til økonomi og sikkerhed at bruge spejlede diske til VLAN SMTP databaseserverne. SMTP Relay Indgående SMTP 7.2.2 Relaying SMTP Der opsæ ttes en ræ kke enkeltstående smtp servere med spejlede diske. Disse skal modtage e-mail fra Internettet, samt virke som udgående smtp servere for kunderne. Disses redundans sikres bedst ved at placere serverne fysisk adskilte og fordelingen af belastningen sker ved DNS-loadbalancing (se 7.2.5.) Et SMTP relaysystem kan fungere, som et sikkerhedssystem, da det kan opbevare mails, der ikke kunne leveres i en næ rmere defineret periode. SMTP-relayen kan med fordel samtidigt fungerer som kundernes udgående SMTP-server. Dette giver desuden den fordel at serverene bruger DNS-opslag, så eventuelle fejlkonfigurationer af mailsystemernes lokale liste over domæ ner ikke medfører at mails bliver fejlafleveret eller fejlafvist 2. VLAN POP3 POP3 servere VLAN IMAP IMAP servere VLAN Webmail Webmail servere VLAN Database Database servere VLAN Diskserver Disk servere Figur 7-1: Oversigt over arkitekturen 2 De fleste mailsystemer bruger deres lokal domæ neliste før de slår op i DNS, og en fejl i denne liste vil opvirke håndteringen af e-mails. GISP Global Internet Service Provider Side 24 af 45

7.2.3 Indgående SMTP Disse servere modtager kun e-mails fra de førnæ vnte relaying smtp servere. Serverne skriver direkte til det delte filsystem. Serverne skal have læ seadgang til databasen, da oplysninger om hvor data skal placeres på disken opbevares i databasen. Da der ikke opbevares data på selve serveren skal lokale diske kun bruges til operativsystem og applikationer. 7.2.4 POP3, IMAP og Web-mailservere Principperne for disse er ens. Kunderne tilgår tjenesten på serveren, som kan præ sentere mails for kunden, via adgang til database og det delte filsystem. Serverne skal have læ seadgang til databasen og skriveadgang til disken for at læ ste mails kan slettes. Som ved SMTP bruges de lokale diske kun til OS og applikation. 7.2.5 Loadbalancing SMTP serverne loadbalanceres vha. DNS round robin -princip, hvor SMTP-domæ net har flere MX-records med same prioritering og forskellige IP-nummre. Dette bevirker at DNSserverne roterer mellem disse IP-numre, så der sker en fordeling af belastningen. POP3, imap og web loadbalanceres ved hjæ lp af dedikeret hardware som styrer hvilken server der skal svare på forespørgslen. Dette kan væ re baseret på round robin -princippet eller på hvor belastet en server er. Forespørgelser kan f.eks. sendes til den server med den laveste svartid. 7.2.6 Sikkerhed Netvæ rkssikkerheden opnås ved at oprette en ræ kke VLAN. Hvert VLAN er dedikeret til en service. I kant-routeren oprettes der filtre som kun tillader den nødvendige trafik til disse services. 7.2.7 Administration og overvågning Administrations og overvågnings serverne placeres ligeledes i en ræ kke VLANS således at de ikke kan nå produktionsserverne på andet end de nødvendige porte. Ved overvågning og fejlfinding er det vigtigt at samtlige servere har samme tid. Dette kan opnås ved at synkronisere tiden vha. af en tidsserver. GISP Global Internet Service Provider Side 25 af 45

8. Installation af testsystem I det følgende beskrives hvordan testsystemet, der blev stillet op i forbindelse med dette projekt, blev lavet og hvilke overvejelser, der blev fortaget. Der er en mere detaljeret beskrivelse af testsystemet i Bilag 4 Formålet med testsystemet er at få afklaret hvor mange e-mails et givet system kan håndtere. 8.1 Beskrivelse af forsøgsbetingelserne For at teste en opsæ tning af systemet blev der stillet et grupperum på Aalborg Universitet til vores rådighed. I dette grupperum blev der opsat det antal Pc-servere der var nødvendige for at teste systemet. Pc-serverne er udtjente maskiner fra Sol og Strand Feriehusudlejning A/S suppleret med de studerendes egne maskiner. Alle har tjent som servere eller arbejdsstationer i 4-5 år. Ingen af dem var ens, derfor har der væ ret en del problemer med komponenter der ikke virkede og en del hardware, der ikke var understøttet af softwaresystemerne, hvilket gør testbetingelserne lidt tvivlsomme, samtidig med at der ikke umiddelbart kan laves meget præ cise konklusioner på egenskaber og kapaciteter i forhold til moderne hardware. Forsøgene kan dog give en indikation om systemets samlede funktionalitet. 8.2 Beskrivelse af arkitektur Systemet blev oprettet med 2 IP-adresser mod AAUs KOM-net, der virker som systemets Internet. På de 2 IP-adresser monteres 2 GPL-licenserede FireWalls (SmoothWall 1.0). Bag disse firewalls er der henholdsvis et klientnet, der er dedikeret til arbejdsstationer m.m., der ikke er del af selve systemet, samt et servernet, hvor selve systemet er monteret. Der er adgang til begge net igennem begge FireWalls 8.3 Installationen FireWalls installeres direkte fra Cd-rom og konfigureres med de relevante regler, adgange og redirgeringer. Serverne installeres med RedHat 8 Linux i tekst mode, med en minimumsinstallation, hvilket gør at der ikke er kompileringsvæ rktøjer m.m. Derefter installeres de relevante applikationer fra rpm-pakker, der er lavet på en kompileringsmaskine. Der oprettes to servere per service, således at det ville kunne sæ ttes op med DNS-loadbalancing for hele systemet i denne opstilling Figur 8-1: Testopstilling - findes i større udgave i bilag 4 GISP Global Internet Service Provider Side 26 af 45

8.4 Database design Databasen oprettes med 3 tabeller med følgende hovedindhold: - Brugerdata (tabel: mailbox) - Oplysninger om aliases (tabel: alias) - Oplysninger om hvilke domæ ner der betjenes (tabel: domain) 8.4.1 MySQL master/slave opsæ tning. For at opnå en vis skalerbarhed og driftssikkerhed oprettes der en cluster med en masterserver til MySQL samt 2 slave servere. I dette eksempel bruges MySQL ver. 4.0.12. Teknikken er under stæ rk udvikling, så der kan væ re æ ndret noget i forhold til andre releases. MySQL anbefaler at der bruges version 4.x til dette, da 3.27 klart er på forsøgsbasis. Ved overgang til ver 4.1 skulle teknikken væ re stabil til produktion. Teknikken fungerer på den måde at al opdatering sker til master serveren, hvorefter slave serverne henter disse opdateringer ved at følge med i den binæ re log, som masterserveren laver. På masteren gives der tilladelse til at slaveserverne laver replikering med nogle almindelige grant-sæ tninger, der også fortæ ller hvilke tabeller det drejer sig om. Det er vigtigt at der IKKE sker opdateringerne på slaveservernes tabeller, da det gør at replikeringen stopper. Derfor laves der på de replikerede tabeller på slaverne grants, der kun tillader læ sning, da replikeringen ødelæ gges ved skrivninger. For at denne opsæ tning giver en skalerbarhed er det vigtigt at alle læ sninger sker til slaverne således at masteren kun skal håndtere skrivninger og replikere data til slaverne. 8.4.2 SMTP Der opsæ ttes 2 SMTP-servere, der virker som indgående server for domæ nerne. Udgående server for kunderne og SMTP-relay implementeres ikke i testen. 8.4.3 POP3 og IMAP POP3 og IMAP installeres på samme server, da det er samme produkt, Courier-IMAP, der bruges til begge protokoller. IMAP er væ sentligt mere kræ vende end POP3, da brugeren har en forbindelse til serveren i den tid brugeren bruger til at behandle e-mails, da de bliver liggende på serveren. Ved et produktionssystem bør de skilles ad. Under testen afprøves disse hver for sig. 8.4.4 Web-mail Web-mail er ofte implementeret som en kombination af et IMAP-produkt og et produkt, der viser IMAP-billedet i en Web-browser. I testen bruges SQWebmail som er fra samme leverandør som Courier og derfor er baseret på samme kerne som denne. (SQWebmail kræ ver derfor ingen ekstern IMAP server.) SQWebmail oprettes på en separat maskine. Det samlede system kan ses i Figur 8-1 og bilag 4 GISP Global Internet Service Provider Side 27 af 45

8.5 Test af valgt arkitektur For at afprøve testsystemet laves der et expect-script med en løkke, der kan afsende et antal mails i hurtig ræ kkefølge. Tilsvarende laves der et andet script, der ved hjæ lp af POP3 downloader en mail og sletter den. Scriptet findes i bilag 4. Der er i forvejen oprettet 1000 mailkonti på et domæ ne. Til hver af disse konti sendes der 1 mail fra hver instans af scriptet. Følgende resultater fås: 8.5.1 Forsøg 1 Script Server antal mails tid bemæ rkninger 1000 4 min Sirius er en Pentium 166 MHz med Sirius 1000 5 min 64 Mb RAM SMTP 1000 10 min Opti er en Pentium 100 MHz med Opti 1000 10 min 32 Mb RAM Der startes 4 instanser af scriptet inden for de samme 10 sekunder. Alle mails gemmes på Space. Alle mails er ens og består kun af meget lidt tekst. Der kommer den samme fejlmeddelelse på begge SMTP-serverne: nfs: server space not responding, still trying Dette betyder at NFS-serveren har svæ rt ved at besvare alle forespørgslerne På begge maskiner var der ledig CPU, og ingen brug af swap dog var der et loadindex på 5-6 Tabel 8-1 Forsøg 1 8.5.2 Forsøg 2 Script Server antal mails tid bemæ rkninger 1000 6 min Mira 1000 6 min POP3 1000 9 min Apollo 1000 8 min Der startes 4 instanser af scriptet inden for de samme 10 sekunder. Alle mails er gemt på Space. Alle mails er ens og består kun af meget lidt tekst. Der kommer den samme fejlmeddelelse på begge SMTP-serverne: nfs: server space not responding, still trying Dette betyder at NFS-serveren har svæ rt ved at besvare alle forespørgslerne Der var dog nogle af postkasserne der var tomme hvilket gav fejl på scriptet, da det forsøgte at slette en mail, der ikke var der. På begge maskiner var der ledig CPU, og ingen brug af swap dog var der et loadindex på 5-6 Tabel 8-2 Forsøg 2 GISP Global Internet Service Provider Side 28 af 45

8.5.3 Forsøg 3 Script Server antal mails tid bemæ rkninger SMTP Sirius 1000 3 min POP3 Mira 1000? min SMTP Opti 1000 5 min POP3 Apollo 1000? min Der startes 2 instanser af hvert script inden for de samme 10 sekunder. Alle mails er gemt på Space. Alle mails er ens og består kun af meget lidt tekst. Der kommer den samme fejlmeddelelse på begge SMTP-serverne: nfs: server space not responding, still trying Dette betyder at NFS-serveren har svæ rt ved at besvare alle forespørgslerne Der var dog nogle af postkasserne der var tomme hvilket gav fejl på POP3-scriptet, da det forsøgte at slette en mail, der ikke var der. På alle maskiner var der ledig CPU, og ingen brug af swap dog var der et loadindex på 5-6 Tabel 8-3 Forsøg 3 8.5.4 Forsøg 4 For at få et indtryk af hvordan et system ville køre, hvis alle funktioner blev samlet på en maskine, blev et mindre forsøg etableret. Dette forsøg viste en nogenlunde tilsvarende kapacitet, men her var selve maskinen væ sentligt mere belastet. Umiddelbart virkede det som om flaskehalsen lå i at maskinen brugte meget tid på at skifte processer 8.5.5 Konklusion på forsøg Af dette kan det konkluderes at flaskehalsen som forventet er filsystemet NFS. Derfor kan det anbefales at bruge væ sentlige dele af ressourcerne på fil- og disksystemer. Et oplagt valg er benyttelse af SAN, der er konstrueret til at dele diske/filsystemer for flere maskiner. SAN er en hardwareboks med et disksystem, hvor der er fokuseret på driftssikkerhed, men hvor der ikke er forudbestemt hvilket operativsystem, der benyttes. Dernæ st er det også anbefalelsesvæ rdigt at benytte maskiner med rigeligt RAM, da det kan forbedre peak-performance væ sentligt, dog med den fare at der mistes data ved nedbrud, da chachede mails derved tabes. Denne fare betragtes dog som minimal. CPU kraften er ikke væ sentlig. Af forsøg 1 kan det ses at der kan modtages 4000 mails inden for 10 minutter. Dette vil sige 24.000 mails i timen med en jæ vn belastning. I betragtning af systemets åbenlyse svagheder med hensyn til maskiner og teknikker må det betragtes som et rimeligt resultat. 8.5.6 Vurdering af forsøg Forsøgene skulle have væ ret planlagt mere grundigt, således at det kunne konstateres hvordan systemet reagerede under forskellige belastninger. Det skulle blandt andet have væ ret undersøgt hvordan det ville reagere når der var vedhæ ftede filer ved mailene, eventuelt filer af forskellige størrelser. Forsøgene med blandede SMTP og POP3 skulle have væ ret gennemført uden fejl og skulle også have væ ret kombineret med IMAP og Web-mail. Endelig ville nogle forsøg med performance ved brug af mbox have væ ret godt. Disse forsøg blev ikke gennemført på grund af manglende tid. GISP Global Internet Service Provider Side 29 af 45

8.5.7 Vurdering af kapacitet på den valgte arkitektur Som det fremgår af forsøgene er der ikke opnået væ sentligt bedre kapacitet på dette setup end på en dedikeret server, men såfremt problemet med filsystemet løses vil systemet væ re meget mere skalerbart og redundant. 8.6 Yderligere test De afprøvninger af systemet, der er blevet foretaget er indledende forsøg, der skal give indtryk af om systemet virker og eventuelle flaske halse. I forbindelse med yderligere test skal scripts skrives således at de selv registrerer start og sluttid i en log fil. Samtidig bør målinger fra overvågningsprogrammer så som iostat, vmstat m.m. gemmes i logfiler med tidsangivelser. Det forudsæ ttes at tiden mellem serverne er koordineret. Med det formål at afklare hvilke forbedringer, der skal ske for at systemet kan optimeres yderligere foreslås følgende tests gennemført. Følgende forsøg bør ske med samme server eller en sammenlignelig server. Derefter kan de samme forsøg gøres med en moderne server, således at forskellen mellem serverkraften og ydelsen kan konstateres. 8.6.1 Optimering af storage 8.6.1.1 Ændret disksystem for NFS-serveren Det foreslås at æ ndre disksystemet med et SCSI-disksystem. Dette skal ses i lyset at SCSIsystemer er bedre egnet i serversystemer end IDE. SCSI har indbygget visse optimeringsfunktioner i forhold til læ se og skrive aktiviteter på diskene. Disse funktioner sammenholdt med at SCSI har større båndbredde end IDE vil måske give en forbedret ydelse på NFS-serveren. Der kan også væ re forskel på hvordan SCSI-diskene er sat op. Om de er stripped med eller uden paritet og om de er spejlede. 8.6.1.2 Ændret filsystem på NFS-serveren Ved at æ ndre filsystemet på NFS-serveren kan det konstateres om der er forskel på filsystemernes ydelse. Der kan f.eks. prøves med en FreeBSD for at se om dette filsystem kan yde mere end et Linux filsystem. Dette afprøves både med IDE og SCSI. 8.6.1.3 Ændring af filsystem til OpenGFS Ved at æ ndre til et distribueret filsystem kan det konstateres hvad det gør ved ydelsen i forhold til NFS. 8.6.2 Optimering af arkitektur Formålet med dette forsøg vil væ re om det giver problemer at samle de 4 frontendservices på samme maskiner med henblik på at gøre nedbrud mindre mæ rkbare. I de første forsøg er arkitekturen sat sammen så hver enkelt frontendserver har en funktion. Denne arkitektur kan æ ndres således at alle frontendservere har alle funktionerne (SMTP, POP3, IMAP og Web-mail). Denne arkitektur giver mulighed for at den enkelte maskine kun belastes med en lavere %-del af den samlede belastning frem for at have en stor %-del af den enkelte service. Dette er en fordel ved nedbrud, hvor et nedbrud af en frontend med f.eks. 10% alle funktioner vil knapt væ re mæ rkbart, men et nedbrud af f.eks. 30% af POP3 vil tydeligt kunne mæ rkes. GISP Global Internet Service Provider Side 30 af 45

Det skal sikres, at opsæ tningen er sammenlignelig med et eller flere af forsøgene omkring optimering af storage. 8.6.3 Testdata der skal registreres Følgende oplysninger skal registreres i et skema: Protokol hvilke protokoller der anvendes ved script hvilke scripts der er anvendt logfil hvilke logfiler der laves afsendende server modtagende server antal mails tid Belastningsindex fra top Disk I/O fra iostat processor belastning fra iostat swap Bemæ rkninger Ud fra de registrerede data kan det vurderes hvilke disk-, filsystemer og arkitektur der bør væ lges. 8.7 Beskrivelse af nødprocedurer På kbt kører en overvågningsproces baseret på bigbrother. Alle serverne melder deres tilstand ind til kbt. Her er det så muligt at monitorere samtlige serveres tilstand på en webside. Såfremt en server et gået ned og det ikke er muligt at få den op igen kan man vha. hot standby servere bygge en maskine der kan overtage den defektes arbejdsopgaver. Til dette formål er der på install placeret en ræ kke scripts 3 som kan bruges til at få installeret de nødvendige services. Herefter skal den nye maskine blot overtage den defektes navn og ipadresse hvorefter den er klar til at udføre dennes arbejde. 8.8 Opgraderingsplan Som det tydeligt fremgår af testen er NFS-serveren systemets flaskehals og der bør derfor findes en afløser for denne. Dette kan væ re i form af et SAN (såfremt hardware budget tillader dette) alternativt vil et system som opengfs eller GFS sandsynligvis kunne løse opgaven. For at nedbringe tiden som smtp serveren skal bruge til at validere brugerne mod databasen, bør mulighederne for en lokal databasecache eller lign undersøges De 2 firewalls og DNS round robin mellem disse bør udskiftes med en rigtig loadbalancer eller som minimum en layer 4 switch. Endeligt bør serverne bringes op til moderne standard. (De anvende servere er typisk en Pentium 133 med 32-64 MB ram.) 3 Disse scripts er beskrevet i bilag 3. GISP Global Internet Service Provider Side 31 af 45

8.9 Systemvæ rktøjer Da disse er tertiæ re i forhold til det setup som vi ønsker at teste er der ikke lavet nogen analyse af hvad der er det bedste væ rktøj, der er blot valgt væ rktøjer som i forvejen var kendte med det formål at teste arkitekturen. 8.9.1 Fjernadministration Til fjernadministration af Unix servere er der i dag ingen vej udenom SSH, det er dog vigtigt at væ re opmæ rksom på hvilken version man bruger da der er adskillige sikkerhedshuller i de æ ldre versioner af SSH. I setupet er der en X-server med enkelte grafiske baserede væ rktøjer som en Mozilla browser. 8.9.2 Backup Der er i testsetupet ikke implementeret backup, og det betragtes ikke væ rende nødvendigt at tage backup af servernes filsystem og konfigurationsfiler (Dette kan hurtigt genskabes ud fra vejledninger og cvs) Fokus på backup bør derfor væ re database, filserver og cvsserver. I forbindelse med backup bør der væ lges et system som kan håndtere et meget stort antal små filer. Det bør også kontrolleres hvad restore tiden er, da der kan væ re nogle udfordringer med at få restore tiden ned på et acceptabelt niveau. 8.9.3 Versioneringssystem Til versionsstyring bruges CVS. Som CVS server bruges serveren fra andet år. GISP Global Internet Service Provider Side 32 af 45

8.9.4 Overvågning Overvågning baseres på BigBrother og MRTG. Disse 2 er valgt da de supplerer hinanden ret godt. Hvor BigBrother giver et hurtigt og præ cist oversigtsbillede (med grønne, gule og røde lamper) hvor det hurtigt kan observeres om der er noget som kræ ver her og nu service Figur 8-2: BigBrother Skæ rmdump giver MRTG et overblik over ressource forbruget og hvordan udvikling er. Figur 8-3: MRTG Skæ rmdump GISP Global Internet Service Provider Side 33 af 45

8.10 Alternative løsnings modeller I denne rapport er der opbygget et system, der er baseret på at hele systemet virker udadtil som et system og hvor de enkelte delsystemer er dedikeret til en type opgave, men for alle kunderne. Der er selvfølgelig andre måder at opbygge sådanne systemer på, som vil give det samme resultat at betjene mange kunder. I det følgende vil der kort blive beskrevet andre måder at gøre dette på. Ingen af de flg. er testet men bør indgå i overvejelserne for at finde den optimale løsning. 8.10.1 Brugere fordelt på serverene En ræ kke enkeltstående servere som har hver en del af brugerne. Mailen fordeles mellem serverne vha. hardcodet informationer på de indgående MTA servere. Hver server har så sine brugere og disses filer og kører både web, pop3 og imap. Ved skalering skal der manuelt flyttes brugere fra de eksisterende servere til de nye, samtidigt med at mailroutningen æ ndres på indgående MTA servere. Server1 brugere som begynder med a MTA med hardcodet mailroutning Server2 brugere som begynder med b Fordeler boks Brugere Server n. Brugere som begynder med z Figur 8-4: Alternativ model Fordele: Alt foregår på en server og dermed er der ingen afhæ ngigheder til andre servere Dele af setupet kan væ re nede uden at det påvirker hele setupet. Ulemper: Hver server skal skaleres for sig Ingen udnyttelse af ledige ressourcer på tvæ rs (dårlig Erlang) Manuel opsæ tning af layer4-7 switch og mailroutning. Ingen redundans. Såfremt en server er nede vil det påvirke alle brugerne på denne server. Fordeler boksen skal udfra kundens brugernavn forwarde forespørgelser til den rigtige pop3/imap/webserver GISP Global Internet Service Provider Side 34 af 45

8.10.2 Flere tjenester på frontend serverne Baseret på den testede arkitektur, men der installeres både pop3, imap og web på alle frontends (evt. også smtp) @ SMTP Relay Indgående SMTP, pop3, imap og webmail VLAN dataservere VLAN Database Database servere VLAN Diskserver Disk servere Figur 8-5: Flere tjenester pr. frontend Fordele Bedre udnyttelse af ledige ressourcer. (Forsøget viser klart at de anvendte services ikke alle anvender de samme ressourcer på maskinen nogle er cpu tunge mens andre er I/O tunge, vil der væ re væ sentlige ressourcer som kan udnyttes bedre.) Større redundans, i og med der er flere servere som deler opgaven vil et nedbrud på en enkelt server ikke fjerne så stor en procentdel af kapaciteten. (Der vil dog så forsvinde kapacitet fra alle tjenesterne.) Ulemper Sikkerhed, da der skal væ re adgang til flere systemer, skal alle serverne have en flere ekstra rettigheder, men da både smtp og pop/imap/web har behov for de samme adgange til databasen og disksystemet er dette ikke et reelt problem. Da samtidigt web/pop/imap er baseret på den samme familie af software bør denne mulighed udnyttes. GISP Global Internet Service Provider Side 35 af 45

8.10.3 Kroupware Kroupware er et komplet system udviklet til at understøtte Outlook og kmail. Kroupware er baseret på en samling open source programmer (Postfix, Cyrus, OpenLDAP, OpenSSL, ProFTP og Apache) Som lim mellem disse er der udviklet kode som gør at systemet som helhed kan bruges som server for Outlook og kmail klienter. Kroupware er godt dokumenteret. (Det fremgår dog ikke tydeligt hvordan systemet skaleres, men det skulle væ re muligt at distribuere applikationerne over flere servere og dermed opnå en større kapacitet.) I Kroupware projektet er der ikke taget stilling til hvordan eller hvilket filsystem der skal væ re under applikationen og dermed er deres opsæ tning meget lig den der er anvendt i dette projekt. Det vil i fremtiden blive muligt at udskifte dele af Kroupware serveren, men dette vil kræ ve yderligere æ ndringer i andre dele af systemet. Kroupware leverer også kalender og gruppefunktioner. 8.10.4 Flad skalering Denne skal blot næ vnes fordi det er der hvor mange starter. Der opsæ ttes et antal server som hver har et eller flere domæ ner (men et domæ ne er kun på en server) Alle services installeres på samme maskine men der tillades kun et begræ nset antal kunder pr. server. Fordele: Forholdsvis let at opsæ tte. Går en server ned påvirker det kun kunderne på selve denne server. Ulemper: Der kan kun væ re et begræ nset antal kunder pr. domæ ne. Der er ingen redundans Der er ingen muligheder for horisontal skalering Kunder kan kun flyttes ved at flytte et helt domæ ne (evt. subdomæ ne) GISP Global Internet Service Provider Side 36 af 45

9. Erfaringer og konklusion. 9.1 Konklusion. I betragtning af det udstyr, der blev benyttet til testopstillingen kan det konkluderes at et system af denne type vil kunne bygges stort, hvis alle erfaringerne mønter sig ud i nogle fornuftige valg af hardware 9.1.1 Projektmiljøet Som uddannelsesprojekt har det væ ret læ rerigt med et miljø, hvor der er alle mulige problemer, der skal løses, men det kan væ re både tidskræ vende og frustrerende når det begynder at gå ud over resultaterne. Nogle af de problemer der er opstået undervejs har væ ret: uens maskiner maskinerne er komme forskellige steder fra og har haft vidt forskellige bestykninger, bios-versioner og har i visse tilfæ lde også indehold gammelt hardware, der enten ikke virkede eller ikke var understøttet af softwaren lokalet Der blev stille et almindeligt grupperum til rådighed for projektet på ca. 12 m 2 (30 m 3 ) med et vestvendt vindue med masser af eftermiddagssol. Dette bevirkede at der var maskiner, der gik ned når vejret var godt og temperaturen steg til væ sentligt over 30 o C. En del af maskinerne blev slukket d. 1/5 for ikke at bræ nde dem af. Af denne grund var yderligere forsøg hellere ikke mulig. fjernarbejde Dette setup var bygget op på den måde at AAU s KOM-net fungerede som systemets Internet. Dette betød at forsøg fra hjemmearbejdspladsen kun kunne forgå ved fjernbetjening af maskiner på KOM-nettet og derfra fjernbetjening af egne maskiner. Dette giver et meget dårligt billede af hvordan reaktionen på systemet er Et stort setup for kun 2 studerende Der har væ ret mange ting vi burde undersøge næ rmere og planlæ gge bedre, men der har ikke væ ret ressourcer at dele ud af, da der kun har væ ret 2 projektdeltagere. Dette har klart gjort at der skulle prioriteres hårdt mellem opgaverne med fejlprioriteringer til følge. Tilgæ ngelighed af materialer Gruppen har væ ret heldige med at have adgang gennem arbejdspladsen og egne lagre til udstyr, for det stod klart fra begyndelsen at det var meget begræ nset hvad AAU kunne stille op med. Til projektet har AAU leveret: o 1 switch 3com 24 ports 10 Mb, o 4 strøm skinner o 3 harddiske o strøm o 2 IP-adresser på KOM-nettet med tilhørende DNS o Maskiner til scriptafvikling til test o grupperum GISP Global Internet Service Provider Side 37 af 45

9.2 Samlet konklusion. Det er muligt at anvende open source til et projekt som dette, men det vil væ re meget vigtigt at væ lge hardware baserede komponenter hvor performance er vigtig, hvilket i dette setup vil sige storage og load balancing. Den valgte arkitektur vil kunne bruges og systemets begræ nsning vil væ re afhæ ngig af storage systemets performance. Såfremt vi havde haft bedre test forhold, tror vi på at vi kunne væ re nået videre og haft et mere afsluttet resultat. Da det samtidigt har vist sig at de forskellige tjenester belaster serverne forskelligt tror vi der kan væ re fordele i at samle flere frontend tjenester på frontend serverne, men at dette kun bør ske hvor det ikke kompromitterer sikkerheden. 9.2.1 I forhold til uddannelsen Temaet for dette studie år er automatisering og integration, hvor der skal behandles emner som automatisering af drift, sikkerhed og integration mellem platforme. Vi har behandlet så mange af emnerne som muligt, men grundet de begræ nsede ressourcer (2 studerende) har integrationen ikke væ ret medtaget som en direkte del af projektet, men det miljø projektet er blevet udført i har væ ret væ sentligt bredere. Windows har væ ret en meget stor del af det miljø der har frembragt denne rapport og den platform hvor alle data er blevet samlet og bearbejdet på. Ligeledes blev der brugt en blanding af Unix og Windows baserede maskiner til administration af serverne. Derudover har projektet givet deltagerne væ sentligt bedre indsigt i de teknikker og metoder der bruges i forbindelse med drift af større netvæ rk GISP Global Internet Service Provider Side 38 af 45

10. Ordforklaring EMC Erlang HDS horisontal skalering iscsi layer 4-7 switch licenstyper loadbalancer NAS Netapp provisionering PXE RAID X EMC Storage Et formel sæ t som kan bruges til at udregne nødvendig kapacitet såfremt man kan tillade x% afviste kunder (bruges fortrinsvis i telebranchen til udregning af nødvendige linier mellem 2 centraler) Erlang inddrager stordriftsfordel. Hitachi Data Systems Skalering hvor der ved udbygning sæ ttes flere maskiner op, som deler arbejdsbelastningen. Dette betegnes også som clustering, som kan optræ de på mange måder. Meget anvendt inden for WEB-servere er loadbalancing, hvor der er en el. flere maskiner, der sørger for fordelingen af belastningen på de bagvedliggende servere Se også vertikal skalering Internet SCSI - SCSI kommandoer der er pakket ind i TCP/IP-pakker Intelligent routning baseret på information på et højt lag eks. kan forspørgelser til en web-server fordeles udfra filtype. Disse er gennemgået i GISP1 rapporten Apparat der er konstrueret til at fordele trafik til forskellige bagvedliggende systemer. Dette kan gøres enten ved round robin princippet, ved at undersøge hvilke systemer der er belastede ved f.eks. at måle svartider Network Attached Storage. En server dedikeret til fil-deling. NASen tilsluttes LANet og giver dermed direkte adgang til at gemme filer network Appliance Den proces som skubber nødvendig data fra kundestyringssystemet til produktionssystemet Preboot execution enviroment. Intelplatformens måde at boot over et netvæ rk. Kræ ver DHCP-server og BOOT-server Redundant Array of Independent (Inexpensive) Disks. Raid underinddeles efter hvilken sikkerhedsteknik, der anvendes. Her er nogel eksempler: RAID 0: Striping - sammenkobling af et antal diske uden sikring mod diskfaillure RAID 1: Spejling af diske, således at der kan mistes en disk uden data tab. Disken kan derefter udskiftes og spejlet genoprettes. RAID 5: Striping med paritet. Minimum 3 diske, hvor de min. 2 indeholder data og den sidste indeholder en paritetsvæ rdi, der kan bruges til genetablering af data, hvis GISP Global Internet Service Provider Side 39 af 45

en af diskene fejler Raid 10: Spejling af en RAID 5 hvor der skabes en dobbelt sikkerhed mod diske der fejler, samt at man forbedrer skrive/læ sehastighed. RAID 0+1: Spejling af en RAID 0, hvor fejlsikkerheden er lig med RAID 1 og RAID 5, men med bedre læ se/skrive hastighed. redundans SAN Stratum-server vertikal skalering WOL Valget af RAID teknologi afhæ nger af ønsket af sikkerhed sammenholdt ydeevne og økonomi. Oprindeligt: fylde, overflod; det, at en sproglig meddelelse indeholder så meget overflødig oplysning, at den forstås, selv om en del af tegnene (signalerne) går tabt. IT-systemer: Opbygning (dublering) af systemer, således at der ved udfald alligevel vil kunne betjenes brugere - ønskelig tilstand. Data: Overflødig data - betegnelse for data, der forekommer flere steder, således at opdateringer vanseliggøres - ikke ønskelig tilstand. Storage Area Network. Specielt netvæ rk der gør at flere servere kan dele de samme storage-enheder. I dette tilfæ lder har den enkelte server ikke egen storageenheder til dataopbevaring. (Grundet prisen væ lges ofte lokale diske til operativsystemet.) Tids server der har meget præ cis tidsangivelse. Anbefales kun at det er servere, der henter tiden f.eks. en ISPers tidsserver, der derefter betjener kunderne Skalering hvor yderligere kapacitet bygges op på en eksisterende maskine i form af mere diskplads, RAM og ekstra processorer. Den mest anvendte skaleringmetode. Se også horisontal skalering Wake On LAN. Facilitet på netkort, der kan starte en computer ved specifik trafik til netkortet. Både netkort og bundkort skal væ re forberedt for funktionen GISP Global Internet Service Provider Side 40 af 45

11. Kilder 11.1 Internet kilder Linux.org Oversigt over filsystemer http://www.linux.org/docs/ldp/howto/ Filesystems-HOWTO-9.html Apache Opensource WEBserver http://www.apache.org/ Beyond the SAN Cloud Describtion of storage strategy http://www.eu.hds.com/pdf/db- STORAGE2002.pdf Bigbrother Network monitoring http://bb4.com/ system Clemson University. Parallel Virtual File http://parlweb.parl.clemson.edu/pvfs/ System (PVFS) Coda file system advanced networked http://www.coda.cs.cmu.edu/ filesystem Courier MTA / pop3 / imap http://www.courier-mta.org/ Courier/postfix/mysql Virtual Domains and http://high5.net/howto/ Users w/ Postfix / Courier-IMAP / MySQL Courier/postfix/mysql Setup of Courier/postfix and mysql http://www.firstpr.com.au/web-mail/rh71- Postfix-Courier-Maildrop-IMAP/ CVS Concurrent Versioning http://www.cvshome.org/ System - system, der kan registrere æ ndringer i tekstfiler. F. eks til brug for sourcefiler i systemudviklingsprojekt Cygwin Unix tools for windows http://www.cygwin.com EMIC Networks Kommercielt produkt til http://www.emicnetworks.com at clustre MySQL exim MTA http://www.exim.org high-availability Kommercielt produkt http://www.high-availability.com/ RSF-1 der understøtter cluster af 2-64 servere på forskellige UNIX'er. F.eks. SUN, AIX, FreeBSD og Linux IBM RedBooks Paper on Fundamentals of grid Computing http://www.redbooks.ibm.com/redpapers/pdfs /redp3613.pdf IEEE International Conference on Cluster Computing Årlig konference om clustercomputing med links til forskellige universiteter, der arbejder med clustercomputing http://www.csis.hku.hk/cluster2003/ Kernel.org Linux kernel http://mirrors.kernel.org/ldp/howto/ Kernel-HOWTO-2.html GISP Global Internet Service Provider Side 41 af 45

Kimberlite HA - cluster til linux. GPL http://oss.missioncriticallinux.com/projects/kimber lite/download.php kroupware kroupware www.kroupware.org Linux Operativsystem http://www.linux.org/ Linux Magazine Test af Parallel Virtual http://www.linux-mag.com/depts/extreme.html File System Linux Virtual Server Linux Virtual server http://www.linuxvirtualserver.org/ built on a cluster of real servers. MailScanner System til automatisk http://www.sng.ecs.soton.ac.uk/mailscanner/ scanning af mails monit Automatisk http://www.tildeslash.com/monit/ overvågnings appl. MRTG Overvågningsvæ rktøj http://people.ee.ethz.ch/~oetiker/webtools/mrtg/ MySQL Open Source database http://www.mysql.com/ NPACI Rocks Linuxcluster baseret på http://www.rocksclusters.org/ Cluster Distribution RedHat ntpdate Opdatering af servertid i http://www.ntp.org/ forhold til tidsserver Onlamp.com Understanding Filesystem Inodes http://www.onlamp.com/pub/a/bsd/2001/03/07/ FreeBSD_Basics.html ORDB Open Relay Database http://www.ordb.org/ Postfix MTA http://www.postfix.org/ Postfix Building Postfix rpm http://postfix.wl0.org/en/building-rpms/ PostgreSQL Database http://www2.dk.postgresql.org/ Practical PostgreSQL Bog http://www.commandprompt.com/ppbook/ ReiserFS ReiserFS, et JFS http://www.namesys.com/ Replikering af Manualsider for http://www.mysql.com/doc/en/replication.html MySQL replikering af MySQL databaser rfc Request for comment - http://rfc.sunsite.dk System for Internetstandarder, hvor brugere kan indstille til tekniske standarder og derefter få dem godkendt, hvis de er egnede RFC Sourcebook Site med mange http://www.networksorcery.com beskrivelser af protokoller m.m. Rice Computer cluster-based computing http://www.cs.rice.edu/database/systems.shtml Science Sistina Sistina Global File http://www.sistina.com/products_gfs.htm System GFS SlashDot Gennemgang af mailsystemer SpamAssassin mail filter http://spamassassin.org/ Solaris Operativsystem http://www.sun.com Sourceforge opengfs - filsystem http://opengfs.sourceforge.net/ http://slashdot.org/askslashdot/99/07/29/ 2152242.shtml GISP Global Internet Service Provider Side 42 af 45

SSH Secure SHell - Krypteret terminaladgang til en server SunFreeware.com Fæ rdige pakker til Solaris The Globus Project Et Toolkit til at bygge "computational grids" usenix Scalable Content-aware Request Distribution in Cluster-based Network Servers http://www.openssh.org http://www.sunfreeware.com http://www.globus.org/ http://www.usenix.org/publications/library/procee dings/ usenix2000/general/aron/aron_html/node10.html whatis?com iscsi http://whatis.techtarget.com/definition/ 0,,sid9_gci750136,00.html GISP Global Internet Service Provider Side 43 af 45

11.2 Bøger TCP/IP-bogen. Jakob Mose og Jan Ferré. IDG-bøger, København 1998 The Complete Reference SQL James R. Groff og Paul N. Weinberg. Osborne/McGraw-Hill.1999: isbn: 0-07-211845-8 PHP and MySQL Web Development Luke Welling and Laura Thomsen. Sams Publishing 2001: isbn 0-672-31784-2 Computer Networks and Internets Second Edition Douglas E. Comer Prentice Hall: isbn 0-13-84222-2 Perl 5 Unleashed SAMS PUBLISHING: isbn 0-672-30891-6 Postfix Richard Blum SAMS PUBLISHING: isbn 0-672-32114-9 Unix backup and recovery W. Curtis Preston O Reilly: isbn 1-56592-642-0 Unix Bible 2 nd edition Yves Lepage and Paul Iarrera IDG Books: isbn 0-7645-4687-2 DNS & Bind Paul Albitz & Cricket Liu O Reilly: isbn 0-596-00158-4 Automating Solaris Installations Paul Anthony Kasper, Alan L. McClellan SunSoft: isbn 0-13-312505-X Managing & Using MySQL George Reese, Randy Jay Yanger & Tim King O Reilly: isbn 0-596-00211-4 GISP Global Internet Service Provider Side 44 af 45

12. Bilag Bilag 1: Brugerhåndbog. I dette bilag er der en beskrivelse til brugere, hvordan e- mail fungerer forklaret i almindelige ord, samt hvordan man opfører sig som ansvarlig bruger med hensyn til brug af e-mail med speciel henblik på spam og vira. Derudover er der en beskrivelse af hvordan man sæ tter en K-mail klient op, hvor de enkelte begreber forklares. Bilag 2: Driftshåndbog. Dette er en introduktion af nogle væ rktøjer i Unix, der kan bruges til administration af systemet. Bilag 3: Installationshåndbog. I dette bilag er der beskrivelser af alle installationer, der er foretaget i forbindelse med opbygningen af dette mailsystem. Med denne skulle det væ re muligt at lave en fæ rdig installation af et tilsvarende system Bilag 4: Systembeskrivelse. I dette bilag beskrives det testsystem, der er opbygget i forbindelse med udarbejdelsen af dette projekt. Dette bilag indeholder også testdata, samt konklusioner på den test, der blev foretaget. Derudover er rapporten, brugerhåndbog og driftshåndbog fra 2. år vedlagt. GISP Global Internet Service Provider Side 45 af 45