Planlegge og installere en linux-server

Transkript

1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Planlegge og installere en linux-server Helge Hafting Lærestoffet er utviklet for faget LC480D Drift av linux-nettverk Innhold Introduksjon Planlegge og installere en linux-server Harddisk typer Størrelse Typer og hastighet Harddisker partisjoner Hva er partisjoner Hvorfor partisjonere Minimum partisjonering fdisk og cfdisk partisjonering av disker Flere harddisker Hvorfor Hvordan RAID Mer informasjon Filsystemer Ext2 enkelt og raskt Ext3 et journalførende filsystem Reiserfs JFS XFS Minne

2 side 2 av 44 Innhold 1.6 Prosessor Nettverk Andre maskinvarebehov Teksteditorer Grafisk eller tekstbasert editor? Noen editorer Teksteditoren vi Kompilere en linuxkjerne Hvorfor Programpakker du trenger Laste ned kode Eventuelle patcher Konfigurere Kompilere Installere kjernen Kort om distribusjoner Distribusjoner og dette faget Installere og oppgradere debianpakker Installere rpm-pakker Andre distribusjoner Installere.tar.gz-filer Linux/debian-tips og repetisjon Debian-distribusjonen Linux-kommandoer Kommandolinjetips tastaturet Diverse Norsk tastatur Oppsummering Introduksjon Dette faget fokuserer på drift og installasjon av linuxtjenere. Vi ser bl.a. en del på linux som filtjener, i så måte er faget i slekt med «Windows server for systemansvarlige» som ser på et annet tjener-operativsystem. Når det gjelder filtjener ser vi på filtjeneren SAMBA, katalogtjenesten openldap, aksesskontrollister, filrettigheter, skrivertjeneste og administrasjon av brukerkonti. Vi ser også en del på shellscript, og hvordan de kan brukes for å automatisere rutinearbeid. Lenger ut i

3 kurset ser vi på bruk av webproxy, dhcp-protokollen, tynnklientløsninger og fjernadministrasjon. Vi tar også for oss webtjener, e-post og databaser For å få gjort praktiske øvinger er det nødvendig med en maskin som kjører linux. For å få fullt utbytte av undervisningen bør man også ha en maskin til som kan være klient for tjeneren. Jeg har tatt utgangspunkt i at klientmaskinene kjører windows, men det vil også være mulig å bruke en linux-maskin som klient. Maskinene trenger ikke være særlig kraftige for å gjennomføre kurset. For å få en god tjener vil man imidlertid bruke noe bedre. I kurset brukes begrepene unix og linux om hverandre. Kort fortalt er linux en variant av operativsystemet unix. Det finnes andre unix-varianter også, som f.eks. BSD og proprietære unix-varianter fra maskinleverandører som IBM, HP og Sun. Vær oppmerksom på at eksemplene ikke kan følges slavisk når dere gjør oppgavene. Her er det nødvendig å tenke seg om og tilpasse for sin egen tjenermaskin. 1 Planlegge og installere en linux-server Resymé: I denne leksjonen vil du få vite hvordan du planlegger og installerer linux. Planlegging tar for seg disker, partisjoner, filsystemer og RAID for en tjenermaskin. Vi ser også på behovet for maskinvare. Leksjonen tar for seg generell konfigurasjon av programmer, og kompilering av linux spesielt. Herunder ser vi også på bruk av teksteditorer i driftssituasjonen. Vi tar en rask titt på distribusjoner, og pakkesystemet i debian. 1.1 Harddisk typer Størrelse Størrelsen er enkel å planlegge, det skal simpelthen være «plass nok til alt.» Hvor mye det blir avhenger av hva tjeneren skal brukes til. Selve operativsystemet kan presses inn på veldig lite plass, men det er enklere å sette av en gigabyte eller to. DSL 1 bruker f.eks. bare 50MB. Debian linux kan presses inn under 200MB, men det tar fort såpass lang tid at det i en arbeidssituasjon lønner seg bedre å kjøpe en stor nok disk med en gang. Små installasjoner har mer for seg i spesielle situasjoner hvor en ikke kan bruke harddisk, og derfor ønsker å boote fra CD, compactflash eller USB-penn. 1 Damn Small Linux

4 side 4 av 44 Planlegge og installere en linux-server For en filtjener tar vi antall brukere og ganger med hvor mye plass hver bruker skal ha. Husk at en ny tjener gjerne skal brukes i noen år, så ta høyde for at det reelle behovet for plass kan øke med tiden. I et firma i vekst bør en også ta hensyn til at antall brukere kan øke. Men ikke overdriv dette med ekstrakapasitet det er enkelt å installere flere harddisker etterhvert og de blir som regel billigere med tiden også. Hvis maskinen skal håndtere e-post også bør en tenke over at det i blant kan komme uvanlig mye på en gang, f.eks. i forbindelse med virusangrep og spam 2. Hvis tjeneren skal kjøre spesielle programmer, f.eks. en database, er som regel programmets behov for plass dokumentert Typer og hastighet Ytelsen bestemmes i stor grad av ting som overføringshastighet og rotasjonshastighet. Når det gjelder overføringshastighet må en se på hvor fort data leses fra platene (off the platter speed), ikke hvor fort data kan overføres over kabelen. Markedsføring oppgir gjerne det siste, men en UDMA-133 disk har ikke sjanse til å overføre 133MB/s særlig lenge ettersom platene ikke er på langt nær så raske. Det kan hende de klarer MB/s... Uansett hvor rask overføringshastigheten er, vil det i praksis være rotasjonshastigheten som begrenser det hele. En filtjener for mange brukere vil til stadighet ha bruk for tilgang til ulike deler av disken, og vil derfor flytte lesehodene en god del. Når de flyttes vil vi deretter i gjennomsnitt måtte vente 1 2 rotasjon før interessante data havner under lesehodet. Med dagens disker er det denne ventingen på 1 2 rotasjon som setter grenser for ytelsen. Med fokus på rotasjonshastighet skjønner vi at det er stor forskjell på / rpm laptop-disker, rpm disker, rpm disker og rpm disker.... IDE 3 IDE-disker er rimelige per megabyte, men ikke blant de raskeste. Jeg vil derfor ikke anbefale IDE når ytelse er viktig. Men den rimelige prisen gjør at de kan ha noe for seg hvis man har svært store datamengder som ikke trenger den raskeste tilgangen. For tiden er rotasjonshastigheten for IDE-disker er typisk 4200, 5400 eller 7200 rpm. Det har dukket opp noen rpm IDE-disker også. 2 Uønsket reklame og annen søppelpost. 3 Integrated Drive Electronics

5 Harddisk typer side 5 av 44 De fleste PCer har to IDE-plugger på hovedkorter. Til hver plugg kan man koble en kabel som kan gå til to harddisker. Man bør imidlertid ikke ha to på samme kabel, fordi maskinen ikke kan kommunisere med mer enn en om gangen over den samme kabelen. Dette er en begrensning i IDE-protokollen. Det hender også at to disker simpelthen ikke vil fungere sammen på samme kabel. Hvis en vil ha mer enn to IDE-disker, bør en derfor anskaffe diskkontrollerkort som plugges inn i PCI-bussen. For å få brukbar ytelse fra IDE-disker bør en bruke programmet hdparm. Det brukes for å optimalisere IDE-driveren i linux. En bør i hvert fall sørge for å bruke DMA 4, interruptunmask 5, multisector 6 io og 32-bit 7 io. Grunnen til at ikke alt dette brukes automatisk er at det fins endel IDE-hardware, spesielt ganske gamle kontrollere, som ikke virker med de mest optimale innstillingene. SCSI 8 For tiden er typisk rotasjonshastighet for SCSI-disker 7200, eller rpm. SCSI koster gjerne mer enn IDE, men har ofte bedre garantiordninger. Med dagens SCSI-kontrollere kan en vanligvis koble opptil 15 disker (eller andre enheter) til en kontroller med en kabel. Maskinen kan kommunisere med flere disker på en gang, bare begrenset av samlet overføringskapasitet i kabelen. Hvis man f.eks. har disker som klarer 40MB/s 9 til/fra platene og en kontroller som klarer 160MB/s kan man dermed utnytte = 4 disker fullt ut. Med en kontroller som klarer 320 MB/s kan vi ha 8 slike disker. Flere disker enn dette vil øke kapasiteten ytterligere, men ikke overføringshastigheten. Har en bruk for enda høyere ytelse trenger en flere kontrollere. Da må man imidlertid være oppmerksom på at overføringskapasiteten på PCI-bussen også er begrenset. En pci-buss går typisk på 33.3 eller 66.6Mhz, og kan overføre 32 eller 64 bit parallelt. Kapasiteten blir dermed MB/s. Hvis det ikke er nok, fins hovedkort med flere separate pcibusser. PCI-express har høyere kapasitet, hvis en kan finne diskkontrollere for den bussen. Hvis scsi-kontroller og nettverkskort er på samme pci-buss halveres busskapasiteten for 4 DMA lar kontrolleren overføre data til og fra minnet selv, prosessoren kan dermed gjøre andre ting i mellomtiden. 5 irq-unmask lar maskinen håndtere interrupter fra annet utstyr samtidig med IDE-interrupter. 6 multisector io gjør det mulig å overføre flere 512-byte sektorer i én operasjon bits overføringer over pci-bussen istedenfor tregere 16-bits overføringer. 8 Small Computer System Interface 9 Vær oppmerksom på forskjellen mellom MB/s (megabyte per sekund) og Mb/s (megabit per sekund). Ytelse for disker og parallelle busser (som PCI og AGP) oppgis gjerne i MB/s, mens nettverk og annen seriell kommunikasjon gjerne opererer med Mb/s. En byte er som kjent 8 bits.

6 side 6 av 44 Planlegge og installere en linux-server filserving, ettersom data først overføres fra kontroller til minnet og deretter fra minnet til nettverkskortet. SATA Serial ATA er en slags mellomting mellom scsi og IDE. Protokollen som brukes er scsiprotokollen, derfor behandler linux SATA-disker som scsi-utstyr. Men prisene for SATAutstyr ligger mer på IDE-nivå. 1.2 Harddisker partisjoner Hva er partisjoner Filene lagres i et filsystem på harddisken. Den enkleste måten, som ofte brukes på hjemmemaskiner, er å ha en stor partisjon med ett filsystem. Det er enklest, og all ledig plass på disken er å finne på ett sted. En partisjon er en del av harddisken, en del som spenner over et antall sylindre. Hver partisjon har ett filsystem, så har man flere partisjoner kan man ha flere uavhengige filsystemer Hvorfor partisjonere Kontroll med diskplass Hvis /home og /var er på hvert sin partisjon kan filsystemet /home gå fullt mens det fremdeles er plass igjen på /var. Umiddelbart kan det se ut som en ulempe det fins ledig plass som vi ikke får utnyttet. Dette er imidlertid en fordel. Vi kan sette av plass for filene under /var, plass som garantert vil være der uansett hvor mye brukerne sløser med plassen sin på /home. Hvis /home blir fullt vil det altså likevel være igjen plass på /var, og programmer som avhenger av denne plassen vil fortsette å virke. Dette er viktig, da /var har mange viktige funksjoner. Når det gjelder å begrense brukere kan vi oppnå samme effekt med diskkvoter, men siden noen brukere bruker lite plass er det praktisk å kunne la andre bruke over gjennomsnittet. Det finnes også mange andre tilfeller hvor kvoter ikke er svaret, f.eks. når filer som eies av systemet konkurrerer med hverandre. Noen eksempler på kataloger vi kan ønske å skille ut av plasshensyn:

7 Harddisker partisjoner side 7 av 44 /home /var Hjemmekataloger. I store organisasjoner kan det også være aktuelt med flere /home-områder. Dette for å beskytte ulike grupper av brukere mot hverandre. Noen kan ha en verre tendens til overforbruk. Å skille ut /var er et minimum, /var deles ofte videre opp avhengig av hva vi har på tjeneren. Hvis /var fylles opp fører det typisk til driftsproblemer og tjenerprosesser som kræsjer. I /var/log fins loggfiler for det meste som skjer, og disse må kunne vokse ved behov. /var/spool/mail Her havner all innkommende post. Blir det fullt tar ikke tjeneren imot post lenger. Dette området kan fylles opp i forbindelse med spam eller mailbombing, det er en fordel om det ikke går utover andre tjeneroppgaver. Spesielt bør ikke en slik poststorm sette resten av /var ut av spill. /var/spool/news Kjører man newstjener er det her artiklene lagres. /var/spool/cups Her mellomlagres utskrifter 10. Dette området kan fylles opp hvis en bruker skriver ut noe veldig stort. /var/www /tmp Her finner vi dokumentrot for webtjener. Her har alle brukere adgang til å lagre midlertidige filer. Dermed er det lett å fylle opp, og bør skilles ut. Har en mange brukere bør det være en kvoteordning på /tmp for å unngå at en ubetenksom bruker ødelegger for andre. Programmer som df viser total plass, brukt plass og ledig plass per filsystem. Slik informasjon er mer brysomt å finne for deler av et filsystem. Programmet du gir forbruket i et enkelt katalogtre, som både kan være mindre eller større enn ett filsystem. Ulik tilgang Ulike filsystemer kan ha ulik tilgang. Vi kan f.eks. ha noen filsystemer som er skrivbare og noen som bare er lesbare. Filsystemer som ikke er skrivbare øker sikkerheten. Det er f.eks. en del som sørger for at /usr ikke er skrivbart, det hindrer til en viss grad crackere i å overskrive programmer. Kommandoen mount /usr -o remount,rw vil gjøre filsystemet skrivbart igjen, noe enhver hacker vet. Men mange angrep utføres av script-kiddies 11 som bare bruker et rootkit 12 uten å forstå hva som skjer. De lar seg ofte stoppe av slike små 10 Evt. /var/spool/lpd, avhengig av hvilken spooler man bruker. 11 Umodne personer med liten innsikt, som morer seg med datainnbrudd o.l. 12 Automatisert verktøy for å bryte seg inn å skaffe tilgang til brukeren root. Utnytter kjente svakheter i operativsystem og tjenerprogramvare og representerer derfor liten fare for de som til enhver tid holder tjeneren sin oppdatert.

8 side 8 av 44 Planlegge og installere en linux-server hindringer. Andre sikkerhetsrelaterte mount-opsjoner: nodev noexec nosuid sync Hindrer devicenoder på filsystemet. Bør brukes på alle filsystemer utenom det som inneholder /dev, det hindrer brukere i å opprette devicenoder på uventede steder. Devicenoder kan misbrukes til å ta kontroll over maskinen. Hindrer eksekverbare filer. Bør brukes overalt hvor slike ikke trengs. Det begrenser bl.a. muligheten til å «gjemme vekk» rootkit-filer. Hindrer eksekverbare filer i å skifte prosessens identitet 13. Bør brukes på alle filsystemer hvor eksekverbare filer tillates, utenom /bin, /usr/bin, /usr/local/bin og tilsvarende for sbin. Disse katalogene har normalt bruk for suid-programmer, mens f.eks. /home og /usr/src kan ha bruk for exec men neppe suid. All tilgang til filer skjer synkront. Dette er mye tregere enn async, men sikrer oss mot datatap i forbindelse med plutselig strømbrudd eller andre former for kræsj. Dette brukes sjelden da programmer som avhenger av synkron lagring kan bruke fflush() og fsync() på normale asynkrone filsystemer. Noen velger likevel å bruke synkron lagring for epost, særlig hvis de bruker en eposttjener som ikke bruker fsync(). Hvis man tillater brukere å bruke egne disketter eller cd er bør man absolutt bruke nodev og nosuid, noe annet er naivt. Noen velger å legge /tmp på en ramdisk (tmpfs) for å få raskest mulig tilgang til midlertidige filer. En må imidlertid være klar over at de midlertidige filene vil bruke av minnet, og programmer som lagrer midlertidige filer gjør det til tider nettopp fordi de opererer med datastrukturer som er store. Å bruke tmpfs kan likevel være en god idé, for det som var for stort for gårsdagens minne er ikke nødvendigvis for stort i dag. Ulike filsystemer I underkapittel 1.4 på side 19 ser vi på filsystemer med forskjellige egenskaper. Flere partisjoner gjør det mulig å bruke ulike filsystemer på ulike partisjoner. 13 Ett suid-program skifter identitet fra brukeren som kjører det, til brukeren som eier programfilen. Programmet passwd, som bytter passord for oss, er et slikt program. Det bytter identitet til root for å kunne legge inn det nye passordet i den beskyttede passordfilen.

9 Harddisker partisjoner side 9 av Minimum partisjonering Det er vanlig å skille ut /usr, /var, /home, og /tmp som egne partisjoner. Dermed står vi også igjen med en nokså liten partisjon for /, rotfilsystemet, og en partisjon for swap. Hvis datamaskinen har en BIOS som ikke kan nå hele disken må en også skille ut /boot, hvor linuxkjernen ligger, og plassere dette filsystemet på begynnelsen av disken. Dette problemet bør høre fortiden til, da det gjelder maskiner produsert før Men kan dukke opp for de som kjører linux på nokså gamle maskiner. Partisjonenes rekkefølge på disken er heller ikke tilfeldig. Den ytterste delen av disken, som vanligvis har de lavest nummererte sylindrene, kan være opptil dobbelt så rask som den innerste delen (høye sylindernumre.) De mest brukte partisjonene bør dermed ligge på den raskeste delen av disken. Når lesehodene flyttes er det dessuten raskere å flytte kort enn langt. Filsystemer som brukes lite bør dermed legges ut mot den trege enden av disken. Rotfilsystemet brukes lite, det er ingen grunn til å legge det først på disken slik mange gjør når de installerer. I en filtjener er gjerne /home viktig, i andre typer tjenere (epost, web,... ) er sannsynligvis /var viktigere. En del velger å legge swap-partisjon og /tmp midt på disken. Det er ikke den raskeste plassen når det gjelder båndbredde, men det er dit veien er kortest å flytte lesehodene på disken. Dette passer bra for swap og /tmp som ofte er tidskritisk og preget av hyppige diskaksesser med små datamengder fdisk og cfdisk partisjonering av disker Disse programmene brukes for å partisjonere disker. Vær forsiktig med disse. Gjør du feil, sletter du fort et helt filsystem eller alt på disken. Disse programmene brukes ikke bare ved installering, men også når man monterer ekstra disker i maskinen. Programmet fdisk er noe tungvint å bruke, en starter programmet, f.eks. med fdisk /dev/hda, og gir en og en kommando for å slette eller opprette partisjoner. Nybegynnere bør bruke kommandoen p ofte, den skriver ut hvordan partisjonstabellen ser ut for øyeblikket. Programmet cfdisk er noe greiere å bruke. Det viser hele tiden hvordan disken er partisjonert, og lar deg velge partisjoner og ledige områder med en tekstbasert meny. Programmet har de samme mulighetene som fdisk, men er mer brukervennlig uten å bli tungt. Begge programmer arbeider med én disk om gangen, og man angir denne disken som parameter når man starter opp programmet. De har innebygd en viss sikkerhet mot feil ved at en må gi en skrivekommando for å lagre forandringer, og dessuten bekrefte kommandoen. I tillegg til å dele opp disken, kan man bestemme hvilken partisjon som skal bootes (hvis noen), og partisjonstyper. Alle linux filsystemer legges normalt på en partisjon av typen

10 side 10 av 44 Planlegge og installere en linux-server Linux (83). Typen Linux swap (82) brukes for swap-partisjoner, og Linux raid autodetect (fd) brukes for software-raid. Det finnes mange andre typer også, som stort sett brukes av andre operativsystemer. 1.3 Flere harddisker Hvorfor Sikkerhet Den mest opplagte grunnen til å ha flere harddisker er mer plass. Men det er mange flere grunner enn det. Flere harddisker kan også øke datasikkerhet og oppetid, hvis vi lagrer samme data på flere disker tåler vi at en går i stykker. Hvis vi kjører en tjener over flere år må vi regne med at harddisker ryker i blant, en ansvarlig administrator må være forberedt på det. Spørsmålet er når, ikke om det skjer! I en tjener med bare en harddisk kan det bli nødvendig å skaffe en ny og legge inn alt fra siste sikkerhetskopi. Da mister vi for det første alt som har skjedd siden kopien ble tatt, og tjeneren er nede en stund. For en webshop kan nedetid fort bli dyrt. Skjer det etter arbeidstid kan det fort gå en stund før noen oppdager feilen også. Har man et godt raid-system og hotplug-disker kan man klare seg helt uten nedetid. Som administrator får man en epost om at en disk har gått dukken, og at systemet inntil videre klarer seg med de andre. Så er det bare å skaffe en ny og installere den når det passer... Vi kan også oppnå bedre sikkerhet mot innbrudd. I underkapittel på side 7 så vi på fordelen med et skrivebeskyttet filsystem. Det kan dessverre omgåes med kommandoen mount. Men en harddisk kan skrivebeskyttes ved å sette en jumper dermed blir det umulig å skrive til den, og dette kan ikke omgåes med programmerte triks. Administrator er nødt til å flytte jumperen hvis innholdet på disken skal oppdateres på noe vis, en som bryter seg inn via nettet har ingen muligheter. Slik kan man beskytte filsystemer som f.eks. /usr, men ulempen er at det blir mer bry med nødvendige endringer som f.eks. sikkerhetsoppdateringer. I ekstreme tilfeller har sikkerhetsbevisste administratorer lagt /usr, /bin og /sbin ut på CD, for å være 100% sikker på at eksekverbare filer ikke kan overskrives ved innbrudd. Men vær oppmerksom på at CD er et tregt medium sammenlignet med harddisk. Ytelse Det er søketiden som begrenser ytelsen for moderne harddisker. Når en harddisk er travelt opptatt bruker den mesteparten av tiden på å flytte lese/skrivehodene rundt omkring. Med

11 Flere harddisker side 11 av 44 mange aktive prosesser kan det gå mange slike søk mellom hver gang en bestemt prosess får lest eller skrevet. Hvis vi har flere harddisker kan vi imidlertid oppnå at en er relativt ledig og gir god ytelse selvom en annen er overbelastet. La oss se på en maskin som både er fil- post- og webtjener på en gang. Med alt på en harddisk er det nok at en av tjenestene overbelaster disken, så går alt tregt fordi alle filoperasjoner ender opp med å vente på hverandre. Hvis vi derimot bruker en harddisk per tjeneste vil de ikke forstyrre hverandre. En overbelastning på webtjeneren vil fortsatt gi tregere tilgang til web, noe vi bare må akseptere. Men post og filtilgang vil fortsatt gå med full fart ettersom disse diskene ikke er overbelastet i øyeblikket. Tilsvarende vil ikke en epost-storm virke inn på web- eller filservice. Enkelte som kommer fra windowsverdenen vil si at det er bedre å kjøre en maskin per tjeneste å samle fire fem tjenester i den samme maskinen kan virke useriøst på slike. Denne tankegangen har sin rot i stabilitetsproblemer, windows har en forhistorie med tilfeller hvor en tjeneste kræsjer og trekker med seg hele maskinen og alle andre tjenester som kjører på den. Men i unixverdenen har vi stabilitet nok til at mange tjenester i én maskin ikke er noe problem. 14 Nedetid er stort sett planlagt, f.eks. når man legger inn sikkerhetsoppdateringer eller oppgraderer prosessoren. Så lenge vi unngår overbelastning lønner det seg med mange tjenester i samme maskin. Færre maskiner å vedlikeholde sparer oss for mye administrasjonsarbeid og utgifter til utstyr, særlig i forbindelse med oppgraderinger Hvordan For en tjener som skal kjøre flere uavhengige tjenester må vi se på hvilke som til tider er disk-intensive og fordele dem på hver sine disker. Dette gjelder ikke bare ulike tjenester som i det forrige eksempelet. Outsourcing er populært for tiden, og som konsulent kan man fort ende opp med å kjøre f.eks. webtjenester for flere kunder på en maskin. En kunde bør ikke vente unødig på grunn av mye trafikk til en annen kundes sider. Dette kan vi unngå ved å ha de travleste websidene på egne disker. Ideelt en disk per kunde, men det kan kanskje bli litt mye. Det kan også være fornuftig å ha filsystemet /usr på en disk som ikke er travelt opptatt. Nesten alle programfiler ligger på /usr, og det er en fordel at de starter raskt. Vær også oppmerksom på at linuxkjernen ikke henter hele programmer inn i minnet når de starter. Et 14 Forutsatt, naturligvis, at maskinvaren er stabil. De fleste linuxkræsj skyldes hardware-problemer som dårlig utstyr, overklokking, strømproblemer og lignende. En administrator som eksperimenterer med betaversjoner av kjernen kan også lage problemer. Ellers regnes kræsj som unormalt, en linuxtjener kan normalt holde ut kontinuerlig drift i årevis. På nettet finnes eksempler ved å søke etter ordet uptime.

12 side 12 av 44 Planlegge og installere en linux-server program som er godt igang kan dermed få bruk for å hente inn mer av programfilen når en annen del av programmet plutselig taes i bruk. Igjen er det en fordel om dette kan skje uten å måtte vente på filtjenere, webtjenere o.l RAID RAID 15 RAID er en teknikk for å få flere disker til å fremstå som én, på det viset kan vi øke lagringkapasitet, ytelse, feiltoleranse eller alle på en gang. Det fins spesielle diskkontrollere som implementerer RAID i hardware, linux vil da se disk-samlingen som én stor disk. Linux har også software-raid som gjør det mulig å bruke RAID med ordinære billigere diskkontrollere. Vær klar over at selv om RAID kan sikre oppetid og øke sikkerheten med tanke på diskfeil, så beskytter ikke RAID mot operativsystemfeil, virus, innbrudd eller operatørfeil. Slike problemer krever en backup-løsning i stedet. Her ser vi på RAID-0, RAID-1, RAID-5 og RAID-6. Det finnes også andre kategorier, men de har liten praktisk interesse. RAID-0 Også kalt striping. Med n disker n - dobles både lagringskapasitet og ytelse, men sikkerheten er dårlig. Hvis én disk ryker er alt tapt. Hvorvidt ytelsen faktisk øker har mye å gjøre med hva slags stripestørrelse en bruker. Ytelsen kan også bli dårligere med et dårlig oppsett dette bør testes under installasjon. På grunn av dårlig sikkerhet bør det ikke brukes til annet enn midlertidige filer som vi tåler at går tapt. Datafiler for en webcache eller newstjener er typiske eksempler. En kan også ha /tmp på raid-0. Nå har en vanligvis ikke behov for så mye plass på /tmp alene et en setter opp raid-0 bare for det, men hvis en har raid-0 for andre formål kan også /tmp plasseres der og få fordel av den høye overføringskapasiteten. Her ser vi hvordan raid-0 fungerer. Arrayet bygges opp ved å plukke en og en stripe fra hver disk. Med to disker A og B, kommer blokken R 0 fra A, R 1 fra B, R 2 fra A igjen, og så videre. Raid-0 kan lages med flere disker også. Til venstre i figuren er diskene, inndelt i x blokker. Til høyre er arrayet slik operativsystemet ser det. Hvis en fil lagres på blokkene R 1 R 3, ligger den altså egentlig på blokkene B 0, A 1 og B Redundant Array of Inexpensive Disks

13 Flere harddisker side 13 av 44 { Virkelige disker }} { A 0 = R 0 A 1 = R 2 B 0 = R 1 B 1 = R 3 A 2 = R 4 B 2 = R 5 A 3 = R + 6 B 3 = R 7. A x 1 = R 2x 2. B x 1 = R 2x 1 = Raid-0 { }} { R 0 R 1 R 2 R 3. R 2x 1 Hastighetsgevinsten får vi fordi maskinen kan less/skrive de ulike diskene samtidig. Men vær oppmerksom på hvordan én ødelagt disk vil ødelegge alt; Hvis f.eks. disk A ryker, mister vi stripene R 0,R 2,R 4...R 2x 2, og står igjen med stripene R 1,R 3,R 5,...R 2x 1 Vi mister altså annenhver stripe, og filsystemet på R-disken tåler ikke slikt. Eksempelet viste raid-0 med to disker, men man kan godt slå sammen mange flere for enda mer kapasitet og ytelse. R-disken bygges da opp med en stripe fra hver av diskene, deretter en til fra hver disk, og så videre. Å miste én av dem vil fortsatt være katastrofalt. RAID-1 Også kalt speiling. Lagringskapasiteten øker ikke, men vi tåler at n 1 av n disker går i stykker samtidig. Linux optimaliserer lesing fra RAID-1 ved å alltid lese fra den disken som har lesehodene nærmest det som skal leses, det kan gi en brukbar ytelsesforbedring. Skriving skjer parallelt til alle diskene, og kan gå langsommere hvis det ikke er overføringskapasitet nok. Ettersom kapasiteten ikke øker med flere disker er det sjelden man bruker mer enn 2 eller 3 disker på dette viset. I tillegg til diskene som er med i raid-1 kan vi ha en eller flere reservedisker 16. Dette er disker som bare er montert i maskinen uten å brukes. Hvis en raid-1 disk ryker tas en reservedisk disk i bruk automatisk, og oppdateres med data fra en disk som er i orden. Dermed blir tiden uten ekstra sikkerhet veldig kort. Systemadministrator kan deretter fjerne den ødelagte disken ved en passende anledning, og montere en ny disk som blir ny reserve. Her ser vi hvordan raid-1 fungerer. De to diskene A og B inneholder det samme. Hver raid-blokk er lagret to ganger. Vi kan ha mer enn to disker i raid-1, men det er ikke så vanlig. 16 eng: hot spare

14 side 14 av 44 Planlegge og installere en linux-server { Virkelige disker }} { A 0 = R 0 A 1 = R 1 B 0 = R 0 B 1 = R 1 A 2 = R 2 B 2 = R 2 A 3 = R + 3 B 3 = R 3. A x 1 = R x 1. B x 1 = R x 1 = Raid-1 { }} { R 0 R 1 R 2 R 3. R x 1 RAID-4 Øker lagringskapasitet og sikkerhet. Med n disker økes kapasiteten n 1 ganger. Den n 1 første diskene brukes til striping, akkurat som RAID-0. Den siste disken er paritetsdisk. Hver byte på paritetsdisken inneholder en xor-sum av tilsvarende bytes på de n 1 diskene i stripesettet. Hvis vi skulle miste én disk, kan innholdet på den beregnes som en xor-sum av de andre diskene og paritetsdisken. Hvis vi derimot mister paritetsdisken, kan den beregnes på nytt. Til tross for mange gode egenskaper, som god kapasitet og sikkerhet, brukes ikke RAID-4. Problemet er paritetsdisken. Hver gang vi oppdaterer én av de andre diskene, må paritetsdisken også oppdateres. Men siden det er n 1 «normale» disker blir det n 1 ganger så mange skriveoperasjoner på paritetsdisken. Da vi ikke kan få kjøpt disker som er n 1 ganger så raske som de andre diskene våre, blir paritetsdisken en plagsom flaskehals som begrenser ytelsen for RAID-4 settet. Dette problemet løses fullstendig med RAID-5. Her ser vi hvordan et raid-4 sett med fire disker blir seende ut. Diskene A, B og C fungerer på akkurat samme måte som et raid-0 sett med tre disker. I tillegg ligger paritetsdata på disk D. { Virkelige disker }} { A 0 = R 0 A 1 = R 3 B 0 = R 1 B 1 = R 4 C 0 = R 2 C 1 = R 5 D 0 = p 0 D 1 = p 1 A 2 = R 6 B 2 = R 7 C 2 = R 8 D 2 = p 2 A 3 = R + 9 B 3 = R + 10 C 3 = R + 11 D 3 = p 3. A x = R 3x 3. B x = R 3x 2. C x = R 3x 1. D x = p x = Raid-5 { }} { R 0 R 1 R 2 R 3. R 3x

15 Flere harddisker side 15 av 44 RAID-5 RAID-5 fungerer akkurat som RAID-4, men med én viktig forskjell: Paritetsinformasjonen ligger ikke på én disk, men spres utover alle de n diskene. Enhver oppdatering skriver til to disker, data lagres på én og paritetsinformasjon på en annen. Men siden paritetsinformasjon havner på ulike disker avhengig av hvilken diskblokk det gjelder, så er det ingen av diskene som overbelastes. Både lagringskapasitet og sikkerhet øker. Med n disker økes kapasiteten n 1 ganger. Hvis én disk ryker mister vi ingen data. Den ødelagte disken kan byttes ut og innholdet på den gjenskapes. Ytelsen ved lesing kan i beste fall øke n 1 ganger, skriving kan det være verre med. Raid-5 kan benytte reservedisker, akkurat som raid-1. Ytelsesproblemer ved skriving kommer av følgende: Ved skriving må vi i tillegg til data-sektoren også oppdatere paritets-sektoren. Hvis denne informasjonen ikke er i cache, må den leses inn først. Dette tar tid. Anvendelser som stort sett leser fra diskene virker bra med raid-5, fordi lesing kan gjøres parallelt på samme måte som for raid-0. Anvendelser som stort sett skriver store datamengder går også fort; hvis en skriver et datasett så stort at det trenger en blokk fra hver disk er det nemlig ikke nødvendig å lese inn paritetsinformasjon. Fordi alle sektorene i en stripe oppdateres samtidig vil linux kunne generere paritetsinformasjon ut fra data som skrives. Anvendelser som stadig skriver mindre datamengder her og der, vil forsinkes ganske mye av paritetsoppdateringene. Raid-5 er dermed ikke egnet til alle anvendelser, travle filtjenere og oracle-baser sies å være spesielt uheldige kombinert med raid-5. Når det er nødvendig med svært høy io-kapasitet kan vi få et annet problem; prosessoren overbelastes med paritetsberegninger. Dette er imidlertid bare et problem for software-raid, en raid-kontroller som gjør slikt i hardware avlaster cpu i slike tilfeller. Her ser vi hvordan raid-5 fungerer. Figuren er nesten den samme som for raid-4. Linja med 0-blokkene er lik, legg merke til hvordan paritetsblokken flyttes fra disk til disk etterhvert som vi kommer nedover. I en normal installasjon er det mange flere blokker, og når paritetsblokken har kommet frem til første disk begynner den på den siste igjen slik at mønsteret gjentar seg.

16 side 16 av 44 Planlegge og installere en linux-server { Virkelige disker }} { A 0 = R 0 A 1 = R 3 A 2 = R 6 A 3 = p 3 + B 0 = R 1 B 1 = R 4 B 2 = p 2 B 3 = R 9 + C 0 = R 2 C 1 = p 1 C 2 = R 7 C 3 = R 10 + D 0 = p 0 D 1 = R 5 D 2 = R 8 D 3 = R = Raid-5 {}}{ R 0 R 1 R 2 R 3. RAID-6 RAID-6 er forholdsvis nytt. Det ligner RAID-5, men tåler at 2 hvilke som helst disker ryker samtidig uten å tape data. Med n disker økes kapasiteten med n 2. De som er interessert i hvordan RAID-6 fungerer kan ta en titt på kernel/people/hpa/raid6.pdf 17. Også raid-6 kan ha reservedisker klare i fall noe skulle skje. Problemene med io-kapasitet og cpu-belastning er verre enn for raid-5. Hver skriving oppdaterer i tillegg to paritetsdisker og beregner to ulike sorter paritet. Dette må som regel gjøres i software, få kontrollere har støtte for RAID-6. Raid i flere nivåer Komponenter i et RAID-system behøver ikke være enkeltdisker. En komponent kan også være et annet RAID-sett. Dette kalles å bruke RAID i flere nivåer. En mye brukt kombinasjon for de som krever høy sikkerhet, er å ha to like store RAID-5 sett, og så slå disse sammen med speiling. Dermed tåler vi å miste opptil tre disker på en gang. Mister vi 3 disker i ett RAID-5 sett er det naturligvis dødt, men på grunn av speilingen får vi data fra det andre RAID-5 settet. Mister vi 2 disker på det ene RAID-5 settet, er det også dødt, men data er fortsatt tilgjengelig fra det andre settet som bare har mistet én disk. Vi må miste minst to disker på hvert RAID-5 sett før vi mister data. Med n disker i en slik kombinasjon blir kapasiteten n 2 1. En annen kombinasjon som brukes en del, er RAID 1+0. Dette kalles også RAID-10. Her har vi flere RAID-1 sett som består av parvis like disker. Disse settene stripes deretter sammen for å oppnå større kapasitet. Her tåler vi alltid å miste én disk, siden den andre i paret fortsatt virker. Vi tåler også å miste mange disker, så lenge vi ikke mister to disker 17 Detaljer om RAID-6 er ikke pensum.

17 Flere harddisker side 17 av 44 i samme RAID-1 sett. Med to disker i hvert RAID-1 sett og n disker, blir kapasiteten n/2. Denne varianten gir høy ytelse, også om den er implementert i software. For å unngå å miste to disker i samme speil, lager man gjerne speilparene av disker fra ulike produsenter. Ulik teknologi gjør gjerne at de ikke feiler samtidig under identiske forhold. En bedrift med et slikt oppsett klarte seg bra når samtlige disker fra en produsent gikk dukken i løpet av noen uker, det var gjort feil i produksjonen. Mange røk samtidig, men de var altså speilet mot disker fra en annen produsent som ikke hadde det samme problemet. Vær oppmerksom på at kombinasjonen RAID 0+1 ikke er like sikker. (To stripe-sett kombinert med speiling.) RAID 0+1 tåler forsåvidt å miste én disk, men sjansen for havari er mye større hvis vi mister to ettersom sjansen er omtrent 1/2 for at de to ødelagte diskene er i hvert sitt speil. Det finnes de som mener raid-5 har utspilt sin rolle på grunn av ytelsesproblemet ved paritetsoppdateringer. Teknikker som raid-1+0 har langt bedre ytelse og tåler også bedre tap av disker. Man trenger selvsagt flere disker for å få samme kapasitet som raid-5, men dette kan man tjene inn med mindre venting på grunn av høyere overføringskapasitet, og bedre håndtering av diskkræsj. Implementasjoner i hardware og software Hardware raid går ut på å ha en spesiell diskkontroller som tar seg av raid-funksjonalitet for disker koblet til kontrolleren. Operativsystemet trenger dermed ikke bruke tid på dette, for linux ser en raid-enhet ut som en hvilken som helst annen disk. Dette kan være en fordel med raid-5, da beregning av sjekksummer både tar tid og ekstra io-kapasitet. Fordelen er mindre med raid-1 og raid-0, da disse er så enkle at de ikke stjeler noen kapasitet av betydning. Software-raid går ut på å bruke vanlige diskkontrollere, og la linux gjøre jobben med å beregne sjekksummer (for raid-5) og doble eller splitte opp io-operasjoner for raid-1 og raid-0. Fordelen med dette er fleksibilitet. Diskene i et software-raid kan være spredt på flere kontrollere. Disse behøver ikke være fra samme leverandør, de kan til og med være av ulik type, f.eks. både IDE og SCSI. Flere kontrollere gir bedre ytelse, ettersom hver kontroller har sine egne begrensninger. Dessuten arbeider software-raid med partisjoner, ikke hele disker. Når budsjettet setter begrensninger kan vi dermed ha en to-disk tjener hvor deler av de to diskene brukes til et raid-1 for data vi ikke tåler å miste, f.eks hjemmekataloger. Resten av de to diskene kan brukes til mindre kritiske data. Operativsystemet er, overraskende for noen, lite kritisk. Dette fordi det lett kan reinstalleres ved behov. News og webcache er andre eksempler på lite kritiske data.

18 side 18 av 44 Planlegge og installere en linux-server Raid og planlegging Vær oppmerksom på at siden raid får flere disker til å tilsynelatende fremstå som én, så har vi ingen innflytelse på hvordan data organiseres innenfor ett raid-sett. Planlegging som i avsnitt på side 11, av hvilke filer eller tjenester som havner på hvilken disk innenfor ett raid5-sett er altså umulig. Med tilstrekkelig mange disker kan en forsåvidt ha flere separate raid-sett, for ulike anvendelser. Da blir maskinen ganske stor, en får fort bruk for et ekstra kabinett til diskene. En maskin med mange disker har også lett for å trenge ekstra strømforsyning. Raid i praksis, og partisjoner Hardware-raid settes opp ved hjelp av programvare som følger med raid-kontrolleren. Ofte skjer dette ved hjelp av kontrollerens BIOS-oppsett, som aktiveres ved å trykke en bestemt tast når maskinen starter opp. Software-raid settes opp ved hjelp av programmet mdadm 18. De som er interessert, kan installere debianpakken mdadm og lese man-sider og annen dokumentasjon. Så langt har vi sett på RAID som en sammenstilling av hele disker. Software-raid i linux tillater imidlertid at vi setter sammen ulike diskpartisjoner i RAID. Et eksempel: Vi har to harddisker, hver med to partisjoner. Altså hda1, hda2, hdb1 og hdb2. Her kan vi f.eks. kombinere hda1 og hdb1 med RAID-1, for å få økt sikkerhet. Vi kan fortsatt bruke hda2 og hdb2 som separate partisjoner med egne filsystemer. De to partisjonene hda1 og hdb1 er ikke tilgjengelige for å legge vanlige filsystemer på, de er nå slått sammen til en ny enhet, kalt md0. Første raid-enhet får navnet md0, den andre får navnet md1 osv. Tallene har altså ingenting å gjøre med hvorvidt det er raid-1, raid-0 eller raid-5. For å legge et filsystem på vår nye sikre raid1-enhet, bruker vi mkfs og oppretter filsystemet på /dev/md0. For å bruke dette filsystemet, legger vi /dev/md0 inn i /etc/fstab hvor alle filsystemene er listet opp. Sett aldri sammen flere partisjoner fra samme disk til en RAID-enhet. Ytelsen blir elendig fordi lesehodene hele tiden må flytte seg mellom de to partisjonene, og sikkerheten uteblir helt ettersom begge partisjoner ryker når hele disken ryker. Til slutt vil jeg nevne at raid-enheter kan partisjoneres. Dette er nokså nytt. I eksempelet over kunne vi altså ha delt opp /dev/md0 i partisjoner som /dev/md0p1, /dev/md0p2 og så videre. Hvis en har kompliserte diskoppsett bør en ta notater i maskinens loggbok, slike notater er gode å ha hvis det noensinne blir problemer med oppsettet. 18 multi-disk administration

19 Filsystemer side 19 av Mer informasjon For mer informasjon om harddisker og partisjonering, se HOWTO/Multi-Disk-HOWTO.html. Dette bør leses! 1.4 Filsystemer Ext2 enkelt og raskt Det finnes mange filsystemer for linux, og flere av dem kan være aktuelle på en tjener. Ext2 velprøvd og det eldste av de praktisk brukbare filsystemene. Det er også det raskeste i vanlig bruk. Ext2 har imidlertid et problem. Hvis filsystemet avbrytes ukontrollert (strømbrudd, systemkræsj) må det gjennom en tidkrevende sjekk etterpå. Dette fordi filsystemet kan havne i en tilstand med delvis oppdaterte kataloger og strukturer, som må rettes før filsystemet kan brukes. Sjekken kan ta flere minutter for en håndfull gigabyte, og den kan dermed bli plagsomt lang med flere ti- eller hundretalls gigabyte. For mer informasjon om ext2, ta en titt på net/ext2intro.html Ext3 et journalførende filsystem Ext3 er stort sett som ext2, men er i tillegg et journalførende filsystem. Journalen øker datasikkerheten og unngår tidkrevende sjekking etter kræsj. Ulempen er at journaloperasjonene også tar tid, ext3 er dermed ikke fullt så raskt som ext2. En fordel med ext3 er at man kan konvertere eldre ext2-baserte systemer til ext3. Det går også greit å konvertere tilbake til ext2 om det skulle bli nødvendig. Generelt om journalførende filsystemer Journalføring vil si at alle endringer i filsystemet (blokkallokeringer, forandring av kataloger o.l.) først skrives ut til en journalfil, for deretter å bli skrevet ut på sine riktige områder på disken. Hvis maskinen kræsjer mens disken oppdateres får vi samme slags feil i filsystemet som med en ext2-kræsj. Men det er ikke nødvendig å lete etter feil når maskinen starter opp igjen, det er bare å hente inn de siste oppdateringene fra journalen og legge dem ut på disken på rett sted. Det tar bare noen sekunder, og deretter vet vi at filsystemet er i orden og klart til bruk. Hvis maskinen kræsjer mens ext3 oppdaterer journalen får vi en ødelagt

20 side 20 av 44 Planlegge og installere en linux-server journal, men på et slikt tidspunkt er det garantert ingen halvgjorte forandringer i filsystemet. Når maskinen starter opp igjen kan den dermed nøye seg med å lage en ny journal, og anta at filsystemet er i stand uten ytterligere sjekking. Journalen for ext3 er typisk på 32MB, og ligger vanligvis på en skjult fil. Vi kan imidlertid få bedre ytelse ved å legge journalen på en annen disk, skriving til journalen vil dermed ikke konkurrere med vanlig bruk av filsystemet. For maksimal ytelse bruker noen en batteridrevet ram-disk for journalformål. RAM er mye raskere enn en vanlig harddisk, og batteriene sørger får at ingenting går tapt ved strømbrudd eller kræsj. Data skrives til journalen til den går full, deretter skrives alt sammen ut på disken også før ext3 starter en ny omgang i journalen. Journalen har altså fast størrelse, som vi kan velge når vi oppretter filsystemet. Alternativer for journalføring i ext3 Ext3 har tre måter å håndtere journalen. «data=writeback» er den raskeste måten, og tilsvarer måten andre journalførende filsystemer virker på. Det er bare metadata (kataloger, allokeringsinformasjon) som journalføres. Vanlige data, altså innhold i filer, journalføres ikke. Ved kræsj kan vi dermed garantere at filsystemet er konsistent, men filer som var åpne da maskinen kræsjet kan inneholde søppel i form av tilfeldige data. Den viktigste grunnen til å bare journalføre metadata er at det er lite metadata i forhold til vanlige data, dermed får det lite å si for ytelsen. Standard-alternativet er «data=ordered». Det er fortsatt bare metadata som journalføres, men metadata overføres ikke til journalen til før data for de tilhørende filene også er skrevet ut på disken. Dette fører til at data må skrives ut hver gang journalen går full. Det gir noe dårligere ytelse fordi filene oppdateres oftere, men større sikkerhet ved kræsj. Etter kræsjet vil det ikke være noen filer med ubrukelig innhold, ettersom innholdet skrives før journalen. Vi risikerer imidlertid at filer som var i ferd med å bli utvidet blir kuttet ned i forbindelse med kræsjet. For maksimal sikkerhet har vi alternativet «data=journal». Med dette alternativet journalføres alt, både metadata og vanlig data. Det gir dårligere ytelser fordi absolutt alt må skrives to ganger, først en gang i journalen og deretter en gang på disken. Det er dermed et tungt alternativ for filsystemer med mye skriving. Til gjengjeld har vi perfekt sikkerhet, ingenting av det som skrives til disk går tapt ved kræsj! Vær imidlertid oppmerksom på at et program som var kommet halvveis med å oppdatere en fil fortsatt etterlater seg en halvveis oppdatert fil etter kræsjet. Hvis programmet er såpass velskrevet at det kan finne igjen hvor det stoppet går dette bra, ettersom ingenting går tapt. Det er slett ikke alle programmer som får til dette, men f.eks. en kommersiell database bør klare det.

21 Minne side 21 av 44 Mer informasjon om ext3 finnes på følgende steder: Reiserfs Reiserfs er et annet journalførende filsystem. Det er raskere enn ext3 og mer effektivt på kataloger som inneholder mange 19 filer. Det er også mer plass-effektivt når det gjelder små filer, da det kan lagre flere små filer i én diskblokk. For mer informasjon om reiserfs, se JFS Dette er linux-versjonen av IBM s JFS fra AIX. JFS står for «Journalling File System». Ta en titt på for mer informasjon XFS Dette er et journalførende filsystem utviklet av SGI. Det er utviklet med tanke på høy ytelse, spesielt for store filer og store kataloger. Ta en titt på projects/xfs/ for mer informasjon. 1.5 Minne For en tjener bør en ha minne med paritet. Det er litt dyrere, men oppdager evt. feil. Feil på enkeltbits rettes automatisk, og logges av operativsystemet. Hvis en plages med minnefeil bør minnet byttes ut. Hvis det ikke hjelper bytter man hovedkort eller prosessor. En tjener skal ikke ha ustabil hardware! En velkonfigurert linux-tjener skal være så stabil at tilsynelatende tilfeldige kræsj, som ikke kan spores til et bestemt program eller en spesiell driver, bør få en til å mistenke og undersøke hardware. Linux trenger ikke mye minne selv, så lite som 8MB kan fungere 20. En trenger selvsagt mer for de fleste praktiske anvendelser. Hvis man ønsker å bruke grafisk brukergrensesnitt er det en god idé å ha MB. Det grafiske brukergrensesnittet er praktisk å ha installert for 19 tusenvis, titusenvis eller mer 20 8MB kan være nok i en maskin som brukes som ruter og evt. brannmur.

22 side 22 av 44 Planlegge og installere en linux-server administrasjonsbruk. Men siden tjenere ofte står for selv mesteparten av tiden velger mange å bare starte det opp ved behov. Dermed kan minnet nyttes til andre formål, som f.eks. diskcache. Det er sjelden man behøver å sette seg ned ved en linux-tjener, all programvare for administrasjon (både tekst- og grafikkbasert) kan kjøres via nettverket 21. Grafiske programmer kan fint kjøres via nett selv om tjeneren ikke har noe skjermkort i det hele tatt. Ellers må en se på minnebehovene for programmene en kjører. Dette oppgis gjerne i et grunnbehov pluss en mengde minne per bruker. Se HOWTO/HP-HOWTO/linux-intranet.html for noen eksempler på dette. Filtjeneren SAMBA bruker f.eks. ca. 800kB per bruker. Når tjeneren er i gang kan man bruke kommandoen vmstat 1 for å se hvordan minnet og diskene brukes. Hvis det er mye swapping, ser vi at tallene kolonnene si og so 22 er større enn 0 mesteparten av tiden. Da kan det være fornuftig med mer minne. 1.6 Prosessor Man skal ha mange brukere for at prosessoren skal bli en begrensning, dette fordi linux utnytter prosessoren veldig effektivt. Hvis tjeneren har andre og tyngre oppgaver, som f.eks. databaser, stadig kompilering på en utviklingstjener, produksjon av animasjoner e.l., kan dette skje. Kjør i så fall top. Hvis belastningen (load) er over 1 over tid er prosessoren for svak. En raskere prosessor, eller en løsning med to eller flere prosessorer vil hjelpe. Eksempel på top Se figur 1.1 på neste side Her ser vi at kompilatoren (cc1) bruker 26% av cputiden, mens resten av programmene bruker veldig lite. Det er 107 programmer i gang, belastningen er på 0.33, dvs. 33% av hva prosessoren kan klare. For øyeblikket er det altså ingen mangel på prosessorkraft. Hvis noen lurer på hvorfor kompilatoren ikke bruker resten av prosessorkraften er det flere grunner til det. Innimellom venter den på å få lest programkode fra harddisken, andre ganger stopper den når den er ferdig med en fil og startes opp igjen for den neste. Prosesser med kort levetid rapporteres ikke presist av verktøyet top. Kort forklaring av kolonnene: 21 Vi ser på fjernadministrasjon i en senere leksjon 22 si: swap in, so: swap out

23 Prosessor side 23 av 44 Figur 1.1: Eksempel på top PID Process ID. Et greit nummer å vite f.eks. hvis vi ønsker å drepe prosessen med kommandoen kill. USER Brukeren som kjører prosessen, så vet vi hvem vi kan kjefte på. :-) PR NI VIRT RES SHR Prioritet. Nice. Positivt tall betyr en «snill» prosess som kjører med lavere prioritet og dermed slipper til andre prosesser oftere. Negativt tall betyr en «ikke-snill» prosess som har fått ekstra prioritet. Hvor mye virtuelt minne prosessen bruker. Resident size hvor mye virkelig minne prosessen bruker nå. Hvor mye av minnet som er delt minne. Dette er minne som går med til delte biblioteker, f.eks. C-bibliotek og brukergrensesnitt-biblioteker. Slikt minne