Innhold. Planlegge og installere en linux-server. Introduksjon... 2

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 «IINI3008 Linux systemdrift» 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. Det skal gå an å klikke på lenkene i leksjonen, så fremt pdf-leseren din støtter funksjonen. Det samme gjelder innholdslista og andre kryssreferanser. Kodeeksempler kan klippes ut og kopieres for å prøve dem ut. 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 Ext

2 side 2 av 38 Innhold Reiserfs JFS XFS Btrfs Minne 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 Oppsummering Introduksjon Velkommen til faget «Linux systemdrift». 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 tjener for systemansvarlige» som ser et annet tjeneroperativsystem. Når det gjelder filtjener ser vi på NFS og 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 kurset ser vi på bruk av webproxy, dhcp-protokollen, tynnklientløsninger og fjernadministrasjon. Vi tar også for oss nettjener (webserver), e-post og databaser

3 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 mac eller 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. Enkelte synes at noen av leksjonene er ganske store i dette faget. Men husk at det er et fag uten lærebok. Derfor burde ikke de 38 sidene i denne leksjonen være avskrekkende. En kort leksjon som henviser til et kapittel i en lærebok, forutsetter gjerne at man leser mange sider i den aktuelle boka. Stoffet i leksjonene er laget for debian-distribusjonen av linux. Det går an å bruke andre distribusjoner enn debian. (F.eks. ubuntu eller redhat.) Men husk at det er en del forskjeller på distribusjonene: Noen pakker kan ha andre navn. En del distribusjoner bruker et anderledes pakkesystem. (rpm-baserte, og gentoo-baserte) Filer kan være plassert i andre mapper Oppskriftene i leksjonene vil ikke passe like godt til andre distribusjoner. For de som uansett liker å finne ut av ting på egen hånd, behøver det ikke være noe stort problem. Men det blir en avveiing: Med debian vil leksjonene passe bedre, opp mot grunnene til at du foretrekker en annen distribusjon. 1 Planlegge og installere en linux-server 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

4 side 4 av 38 Planlegge og installere en linux-server på veldig lite plass, men det er enklere å sette av gigabyte. DSL 1 bruker f.eks. bare 50MB. Debian linux kan presses inn på ca. 500MB, men det tar fort såpass lang tid at det i en arbeidssituasjon lønner seg bedre å bruke 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, sd-kort eller USB-penn. 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 SATA-300 disk har ikke sjanse til å overføre 300 MB/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. SSD blir stadig mer populært. Diskene er raske fordi de ikke har roterende plater og deres tilhørende venting. En laptop med SSD starter opp og lar oss logge inn på ca. 10s, mot 1/2 1 minutt med roterende disk. Men SSD er også såpass dyrt at en stor tjenermaskin som regel må ha mye av lagerplassen på roterende disker. 1 Damn Small Linux 2 Uønsket reklame og annen søppelpost.

5 Harddisk typer side 5 av 38 SCSI 3 Disse brukes en del i tjenermaskiner. For tiden er typisk rotasjonshastighet for SCSIdisker 7200, eller rpm. SCSI koster gjerne mer enn SATA, men har ofte bedre garantiordninger. De billigste diskene er ikke i samme grad bygd for å vare lenge. 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 4 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 i så fall flere kontrollere. Da må man imidlertid være oppmerksom på at overføringskapasiteten på PCIbussen 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 pci-busser. PCI-express (PCIe) har høyere kapasitet, og det fins diskkontrollere for denne bussen. Hvis scsi-kontroller og nettverkskort er på samme pci-buss halveres busskapasiteten for filtjenester, ettersom data først overføres fra kontroller til minnet og deretter fra minnet til nettverkskortet. Bussen brukes altså to ganger. SATA Serial ATA er en billigvariant av scsi. Protokollen som brukes er scsi-protokollen, derfor behandler linux SATA-disker som scsi-utstyr. Men prisene for SATA-utstyr lavere. Med SATA har man en ledning per disk. Overføringskapasiteten i en slik kabel er MB/s, men som diskplatene ikke kommer i nærheten av. SSD SSD 5 er lagringsmedium uten bevegelige deler. I stedet for en roterende magnetisk plate, har SSD flash-minne. For tjenermaskiner fins større SSD-enheter, basert på flash eller i noen tilfeller RAM. Disse diskene er typisk dyrere enn roterende harddisker, og har noe lavere kapasitet. Men 3 Small Computer System Interface 4 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. 5 Eng: Solid state disk

6 side 6 av 38 Planlegge og installere en linux-server de er også betydelig raskere, på grunn av et problem med vanlige harddisker: Når en pc leser fra flere steder på en roterende harddisk, må lesehodene flyttes fra et sted til et annet. Det tar tid. Deretter må man simpelthen vente på at rett del av plata roterer inn under lesehodet. En roterende disk som fint klarer 90MB/s så lenge den får lese data i den rekkefølgen det er lagret, vil fort falle ned på en hundredel hvis den må flytte lesehodene mye rundt omkring. SSD har ikke dette problemet. Data kan leses fra hvor som helst uten forsinkelser, fordi det ikke er noen bevegelige deler å vente på. I skrivende stund er SSD dyrere enn roterende disker, så SSD brukes først og fremst der man har mest nytte av det. Noen anvendelser er sekvensielle i natur, f.eks. å streame video. Her vil ikke SSD oppleves raskere. Hvis du derimot streamer mange ulike videoer samtidig, i en youtube-lignende tjeneste, vil SSD kunne hjelpe. Kompilering av store prosjekt med titusener av filer, eller travel database, er eksempel på en annen anvendelse hvor mange små datasett hentes fra ulike steder på disken i rask rekkefølge. I slike tilfeller kan hastighetsforskjellen med SSD være dramatisk. I ekstreme tilfeller går store jobber fra å måles i timer til minutter. Databaser som er for store til å holdes i minnet, drar også nytte av SSD. Å starte opp en maskin som har operativsystem og programvare installert på SSD, er også en god del raskere enn om det er installert på vanlig harddisk. En rimelig SSD kobles til maskinen med SATA-kabel. Men SATA overfører på MB/s, som ofte blir en begrensning. I motsetning til roterende disker, kan flashminne overføre data raskere enn dette. Dyrere SSD-løsninger har flashminne montert på et PCIe-kort. Dermed er ikke overføringshastigheten lenger begrenset av SATA, man kan utnytte PCI-express fullt ut. 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.

7 Harddisker partisjoner side 7 av 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 i linux. 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å mapper vi kan ønske å skille ut av plasshensyn: /home /var Hjemmemapper. 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 epoststorm 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 6. Dette området kan fylles opp hvis en bruker skriver ut noe veldig stort. Fotografier og lignende høyoppløselige bilder tar mye plass. /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. 6 Evt. /var/spool/lpd, avhengig av hvilken spooler man bruker.

8 side 8 av 38 Planlegge og installere en linux-server /boot Her ligger typisk linuxkjernen, og evt. noen få andre filer som trengs for å starte maskinen. Hvis maskien bruker UEFI 7, vil /boot være uefipartisjonen. 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 mappetre, 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. Tidligere har f.eks. en del sørget 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 scriptkiddies 8 som bare bruker et rootkit 9 uten å forstå hva som skjer. De lar seg ofte stoppe av slike små hindringer. I det siste har distribusjonene lagt om oppstartrutinene slik at /usr trengs tidlig i oppstarten. Det anbefales derfor ikke lenger å ha /usr på en egen partisjon. Andre sikkerhetsrelaterte mount-opsjoner: nodev noexec nosuid 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 10. Bør brukes på alle filsystemer hvor eksekverbare filer tillates, utenom /bin, /usr/bin, /usr/local/bin og tilsvarende for sbin. Disse mappene har normalt bruk for suid-programmer, mens f.eks. /home og /usr/src kan ha bruk for exec men neppe suid. 7 Unified Extensible Firmware Interface 8 Umodne personer med liten innsikt, som morer seg med datainnbrudd o.l. 9 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. 10 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 38 sync 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 minnepinner 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 21 ser vi på filsystemer med forskjellige egenskaper. Flere partisjoner gjør det mulig å bruke ulike filsystemer på ulike partisjoner Minimum partisjonering Det går an å skille ut /var, /home, og /tmp som egne partisjoner. (Evt. kan man ha /tmp på en ramdisk) Dermed står vi også igjen med en 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. Problemet har det også med å komme tilbake hver gang det taes i bruk nye typer disker. Det har etterhvert blitt vanlig å ha /usr som en del av rotfilsystemet, fordi programvaren som ligger der kan være nyttig å ha i oppstartfasen før andre filsystemer blir montert. På en filtjener (eller hjemmemaskin) er /home det filsystemet som er viktigst å skille ut. Det er der brukerne lagrer filer. Vi vil ikke at maskinen skal få problemer bare fordi brukerne fyller opp disken. Og hvis vi må reinstallere, er det veldig praktisk at /home er et eget filsystem. Da kan vi formatere rotfilsystemet på nytt, mens brukerne likevel får beholde sine filer uendret. Ofte legger man /tmp i tmpfs, et filsystem på ramdisk. Det er raskt, men kan sluke minne, og det er naturligvis ikke mer plass her enn det er minne i maskinen. Har man bruk for store filer i /tmp, er det bedre å bruke plass på en SSD-disk.

10 side 10 av 38 Planlegge og installere en linux-server Noen liker å ha /var på et eget filsystem. Her ligger mye som får problemer hvis disken skulle bli helt full. F.eks. pakkedatabasen i maskinen, som holder orden på installert programvare. Enkelte tjenester, som databaser, epost og nettjener havner i undermapper på /var. Hvis en slik tjeneste er plasskrevende, er det vanlig å skille den ut i et eget filsystem. Dermed er den beskyttet mot at /var fylles opp på annet vis, og /var er beskyttet mot at tjenesten plutselig tar opp plass. For roterende disker er partisjonenes rekkefølge på disken 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 Linux (83). Typen Linux swap (82) brukes for swap-partisjoner, og Linux raid autodetect

11 Flere harddisker side 11 av 38 (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 nettbutikk 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 8 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 roterende harddisker. Når en harddisk er travelt opptatt bruker den mesteparten av tiden på å flytte lese/skrivehodene rundt omkring. Med

12 side 12 av 38 Planlegge og installere en linux-server 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 selv om en annen er overbelastet. La oss se på en maskin som både er fil- post- og nettjener 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å nettjeneren 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. 11 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/sky-tjenester er populært for tiden, og som konsulent kan man fort ende opp med å kjøre f.eks. nettjenester 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 nettsidene 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 program som er godt igang kan dermed få bruk for å hente inn mer av programfilen 11 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.

13 Flere harddisker side 13 av 38 når en annen del av programmet plutselig tas i bruk. Igjen er det en fordel om dette kan skje uten å måtte vente på filtjenere, nettjenere o.l RAID RAID 12 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-10, 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

14 side 14 av 38 Planlegge og installere en linux-server 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 lese/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 13. 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. Sikkerheten øker og prisen øker med flere disker, men ikke kapasiteten. 13 eng: hot spare

15 Flere harddisker side 15 av 38 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 ut fra de andre. 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

16 side 16 av 38 Planlegge og installere en linux-server 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 paritetssektoren. 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-databaser 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 softwareraid, 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. 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.

17 Flere harddisker side 17 av 38 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å: Eksempel 14 Matematikken bak raid6.pdf 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, da få kontrollere har støtte for RAID-6. Det finnes de som mener raid-5/6 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/6, men dette kan man tjene inn med mindre venting på grunn av høyere overføringskapasitet, og bedre håndtering av diskkræsj. Disker koster ikke så mye som de en gang gjorde. 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. RAID-5+1 En 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. RAID-10 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

18 side 18 av 38 Planlegge og installere en linux-server 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 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. Her er det ingen problemer med tidkrevende paritetsberegninger. 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 som raid 1+0. (To store 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. Mange PC-hovedkort leveres med en begrenset mulighet for raid-10, der to og to disker speiles og så kjører man raid-1 på toppen av de to speilene. Men RAID-10 kan være mer enn opplegg med akkurat fire disker. Det er fullt mulig å ha RAID-1 over mer enn to speilsett. Og et speilsett kan forsåvidt inneholde mer enn to disker også, hvis man vil ha mye redundans. Linux RAID-10 Så langt er beskrivelsen av RAID-10 generelt og passer for de fleste operativsystemer. Linux har imidlertid noen ekstra muligheter. Vi kan f.eks. ha RAID-10 med 3 disker og dobbeltlagring. Eller 5 disker. Vi kan også ha opplegg hvor datablokker lagres mer enn 2 ganger, f.eks. 5 disker med tredobbelt lagring. eksemplene blir som følger: 3 disker, A C A B C disker, A E A B C D E disker, tredobbelt A B C D E I stedet for å legge kopiene rett etter hverandre, har linux mulighet for å organisere blokkene slik at den første halvparten av diskene ser ut akkurat som raid-0 (striping). På den andre halvparten av diskene kommer kopiene av blokkene. På dette viset kan raid-10 leses like raskt som raid-0, og likevel ha samme sikkerhet som raid-1. Skriving kan bli langsommere på dette viset, men mange anvendelser har mye mer lesing enn skriving. Dessuten venter vi som regel ikke på treg skriving, fordi det skjer i bakgrunnen. Men

19 Flere harddisker side 19 av 38 for lesing har vi ikke noe valg, vi får ikke resultatene før de er lest inn. Denne typen RAID-10 med 2 disker vil se slik ut: A B 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 SATA 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 hjemmemapper. 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. Webcache og /tmp er andre eksempler på lite kritiske data. 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 12, 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.

20 side 20 av 38 Planlegge og installere en linux-server Hvis du planlegger en stor filtjener, sjekk hvor mange watt diskene og andre komponenter trenger. Så sørger du får tilstrekkelig kraftig strømforsyning, eller evt. separat strøm til diskene. 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 15. 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 hvis 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 Mer informasjon For mer informasjon om harddisker og partisjonering, se HOWTO/Multi-Disk-HOWTO.html. Dette bør leses! 15 multi-disk administration

21 Filsystemer side 21 av 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 mapper 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 mapper 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 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

22 side 22 av 38 Planlegge og installere en linux-server 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 (mapper, 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. Mer informasjon om ext3 finnes på følgende steder:

23 Filsystemer side 23 av Ext4 Ext4 er en videreutvikling basert på ext3, som har høyere ytelse og støtter større filsystemer. Filsystemet kan være opptil en exabyte, og enkeltfiler kan være opptil 16 terabyte. Ext4 har også bedre støtte for SSD; Når en sletter filer på ext4, vil ext4 bruke TRIM-kommandoen for å gi SSD-disken beskjed om at den aktuelle blokken ikke lenger er i bruk. SSD-disker slites ved bruk, og minimerer slitasjen ved flytte blokker som brukes mye til andre deler av flashminnet. Men for å kunne gjøre slikt, må disken vite hvilke blokker som ikke brukes av filsystemet. Ext4 har også en mer effektiv organisering av store filer, basert på extents. Dermed gjør det noe mindre arbeid ved oppdatering i store filer. Mer informasjon om ext4: Reiserfs Reiserfs er et annet journalførende filsystem. Det er raskere enn ext3 og mer effektivt på mapper som inneholder mange 16 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 mapper. Ta en titt på projects/xfs/ for mer informasjon Btrfs Et av de nyeste og mest eksperimentelle filsystemene for linux. Interessant for de som forsker på filsystemer. Nå og da sammenlignes det med ext4, sjekk hvorvidt det har bra 16 tusenvis, titusenvis eller mer

24 side 24 av 38 Planlegge og installere en linux-server ytelse for din anvendelse før du bruker det. Btrfs har noen imponerende muligheter, men er ennå ikke raskest/best for alle anvendelser. Se 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 17. En trenger selvsagt mer for de fleste praktiske anvendelser. Hvis man ønsker å bruke enkle grafisk brukergrensesnitt er det en god idé å ha minst 128MB. For å bruke mer krevende gnome/kde, kan 1 GB være praktisk. Det grafiske brukergrensesnittet er praktisk å ha installert for 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 18. 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 com/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 19 er større enn 0 mesteparten av tiden. Da kan det være fornuftig med mer minne. 17 8MB kan være nok i en maskin som brukes som ruter og evt. brannmur. Nye maskiner har alltid mer, en får ikke lenger kjøpt så små minnebrikker. 18 Vi ser på fjernadministrasjon i en senere leksjon 19 si: swap in, so: swap out

25 Prosessor side 25 av 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 fler prosessorkjerner vil hjelpe. Eksempel på top Se figur 1.1 Figur 1.1: Eksempel på top 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