Product SiteDocumentation Site

Kapittel 12. Avansert administrasjon

12.1. RAID og LVM
12.1.1. Programvare RAID
12.1.2. LVM
12.1.3. RAID eller LVM?
12.2. virtualisering
12.2.1. Xen
12.2.2. LXC
12.2.3. Virtualisering med KVM
12.3. Automatisert installasjon
12.3.1. Fully Automatic Installer (FAI)
12.3.2. Å forhåndsutfylle Debian-Installer
12.3.3. Simple-CDD: Alt i ett løsningen
12.4. Overvåking
12.4.1. Å sette opp Munin
12.4.2. Å sette opp Nagios
Dette kapittelet tar opp igjen noen aspekter vi allerede har beskrevet, med et annet perspektiv: I stedet for å installere en enkelt datamaskin, vil vi studere massedistribusjonssystemer; i stedet for å opprette RAID eller LVM ved nye installasjoner, vil vi lære å gjøre det for hånd, slik at vi senere kan endre våre første valg. Til slutt vil vi diskutere overvåkingsverktøy og virtualiseringsteknikker. Som en konsekvens, er dette kapittelet mer spesielt rettet mot profesjonelle administratorer, og fokuserer litt mindre på personer med ansvar for sine hjemmenettverk .

12.1. RAID og LVM

Kapittel 4, Installasjon har vist disse teknologiene fra installeringssynspunkt, og hvordan de kan integreres til å gjøre utplasseringen lett fra start. Etter den første installasjonen, må en administrator kunne håndtere utvikling av lagringsplassbehov uten å måtte ty til en kostbar reinstallasjon. De må derfor forstå de nødvendige verktøy for å håndtere RAID- og LVM-volumer.
RAID og LVM er begge teknikker til å trekke ut de monterte volumene fra sine fysiske motstykker (faktiske harddisker eller partisjoner); den første sikrer data mot maskinvarefeil ved å innføre redundans, sistnevnte gjør volumadministrasjon mer fleksibel og uavhengig av den faktiske størrelsen på de underliggende disker. I begge tilfeller ender systemet opp med nye blokk-enheter, som kan brukes til å lage filsystemer eller vekselfiler, uten nødvendigvis å ha dem tilordnet til en fysisk disk. RAID og LVM kommer fra helt forskjellige bakgrunner, men funksjonaliteten kan overlappe noe, de er derfor ofte nevnt sammen.
Både for RAID og LVM gir kjernen en blokk-spesialfil, lik dem som svarer til en harddisk eller en partisjon. Når et program, eller en annen del av kjernen, krever tilgang til en blokk innrettet slik, ruter det aktuelle subsystem blokken til det aktuelle fysiske laget. Avhengig av konfigurasjonen, kan denne blokken lagres på en eller flere fysiske disker, og den fysiske plasseringen kan ikke være direkte korrelert til plassering av blokken i den logiske enheten.

12.1.1. Programvare RAID

RAID betyr Redundant Array of Independent Disks. Målet med dette systemet er å hindre tap av data i tilfelle feil på harddisken. Det generelle prinsippet er ganske enkelt: Data er lagret på flere fysiske disker i stedet for bare på én, med en konfigurerbar grad av redundans. Avhengig av denne redundansstørrelsen, og til og med i tilfelle av en uventet diskfeil, kan data uten tap bli rekonstruert fra de gjenværende disker.
RAID kan implementeres enten ved øremerket maskinvare (RAID-moduler integrert i SCSI eller SATA-kontrollerkort), eller ved bruk av programvare-sammendrag (kjernen). Enten maskinvare eller programvare, et RAID-system kan, med nok reserve, transparent fortsette operativt når en disk svikter; de øvre lag av stabelen (applikasjoner) kan også beholde tilgangen til data tross feilen. Denne «degradert modus» kan selvfølgelig ha en innvirkning på ytelsen, og reservekapasiteten er redusert, slik at en ytterligere diskfeil kan føre til tap av data. I praksis vil en derfor bestrebe seg på å bli værende med denne redusert driften bare så lenge som det tar å erstatte den ødelagte disken. Så snart den nye disken er på plass, kan RAID-systemet rekonstruere de nødvendige data, og gå tilbake til en sikker modus. Programmene vil ikke merke noe, bortsett fra en potensielt redusert tilgangshastighet, mens området er i redusert drift, eller under rekonstruksjonsfasen.
Når RAID implementeres av maskinvare, skjer oppsettet vanligvis innen BIOS konfigurasjonsverktøy, og kjernen vil vurdere en RAID-tabell som en enkelt disk, som vil virke som en standard fysisk disk, selv om navnet på enheten kan være forskjellige (avhengig av driveren).
Vi fokuserer bare på programvare RAID i denne boken.

12.1.1.1. Ulike RAID-nivåer

RAID er faktisk ikke et enkelt system, men et spekter av systemer som identifiseres av sine nivåer. Nivåene skiller seg ved sin utforming og mengden av reserve (redundans) de gir. Jo større overflødighet, jo sikrere mot feil, siden systemet vil være i stand til å fortsette arbeidet med flere disker som feiler. Motstykket er at plassen som kan brukes, krymper for et gitt sett med disker, eller med andre ord; flere disker vil være nødvendig for å lagre en gitt mengde data.
Lineær RAID
Selv om kjernens RAID-delsystem kan lage «lineær RAID», er dette egentlig ikke en ekte RAID, siden dette oppsettet ikke gir overskudd. Kjernen samler bare flere disker etter hverandre, og resulterer i et samlet volum som e n virtuell disk (en blokkenhet). Det er omtrent dens eneste funksjon. Dette oppsettet brukes sjelden i seg selv (se senere for unntak), spesielt siden mangelen på overskudd betyr at om en disk svikter, aggregerer det, og gjør alle data utilgjengelige.
RAID-0
Dette nivået gir intet overskudd heller, men diskene blir ikke ganske enkelt fastlåst etter hverandre: De blir delt i striper, og blokkene på den virtuelle enheten er lagret på striper på alternerende fysiske disker. I et to-disk RAID-0 oppsett, for eksempel, vil partalls blokker på den virtuelle enheten bli lagret på den første fysiske disken, mens oddetalls blokker vil komme på den andre fysiske disken.
Dette systemet har ikke som mål å øke pålitelighet, siden (som i det lineære tilfellet) tilgjengeligheten til alle data er i fare så snart en disk svikter, men å øke ytelsen: Under sekvensiell tilgang til store mengder sammenhengende data, vil kjernen være i stand til å lese fra begge disker (eller skrive til dem) i parallell, noe som øker hastigheten på dataoverføringen. Imidlertid krymper RAID-0-bruken når nisjen dens fylles med LVM (se senere).
RAID-1
Dette nivået, også kjent som "RAID-speiling", er både det enkleste og det mest brukte oppsettet. I standardformen bruker den to fysiske disker av samme størrelse, og gir et logisk volum av samme størrelse på nytt. Data er lagret identisk på begge disker, derav kallenavnet «speile». Når en disk svikter, finnes dataene fremdeles på den andre. For virkelig kritiske data, kan RAID-1 selvsagt settes opp på mer enn to disker, med direkte konsekvenser for forholdet mellom maskinvarekostnader opp mot tilgjengelig plass for nyttelast.
Dette RAID-nivået, selv om det er dyrere (da bare halvparten av de fysiske lagringsplass, i beste fall, er i bruk), er mye brukt i praksis. Det er enkelt å forstå, og det gir svært enkle sikkerhetskopier: Siden begge diskene har identisk innhold, kan en av dem bli midlertidig ekstrahert uten noen innvirkning på systemet ellers. Leseytelsen er ofte økt siden kjernen kan lese halvparten av dataene på hver disk parallelt, mens skriveytelsen ikke er altfor alvorlig svekket. I tilfelle med en RAID-matrise med N disker, forblir data tilgjengelig selv med N-1 diskfeil.
RAID-4
Dette RAID-nivået, ikke mye brukt, bruker N plater til å lagre nyttige data, og en ekstra disk til å lagre overskuddsinformasjon. Hvis den disken svikter, kan systemet rekonstruere innholdet fra den andre N-en. Hvis en av de N datadiskene svikter, inneholder den gjenværende N-1 kombinert med «paritets»-disken nok informasjon til å rekonstruere de nødvendige dataene.
RAID-4 er ikke for dyrt siden det bare omfatter en one-in-N økning i kostnader, og har ingen merkbar innvirkning på leseytelsen, men skriving går langsommere. Videre, siden et skript til hvilket som helst av N platene også omfatter et skript til paritetsdisken, ser den sistnevnte mange flere skriveoperasjoner enn den første, og dens levetid kan forkortes dramatisk som et konsekvens. Data på en RAID-4-matrise er bare trygg opp til en feilende disk (av de N + 1).
RAID-5
RAID-5 løser asymmetrispørsmålet til RAID-4: Paritetsblokker er spredt over alle N + 1 disker, uten at en enkeltdisk har en bestemt rolle.
Lese- og skrivehastighet er identiske til RAID-4. Her igjen forblir systemet funksjonelt med opp til en disk som feiler (av de N+1), men ikke flere.
RAID-6
RAID-6 kan betraktes som en forlengelse av RAID-5, der hver serie med N blokker involverer to reserveblokker, og hver slik serie med N+2 blokker er spredt over N+2 disker.
Dette RAID-nivået er litt dyrere enn de to foregående, men det bringer litt ekstra sikkerhet siden opptil to stasjoner (i N+2) kan svikte uten at det går ut over datatilgjengeligheten. Motstykket er at skriveoperasjoner nå innebærer å skrive ut på en datablokk og to reserveblokker, noe som gjør dem enda tregere.
RAID-1+0
Dette er ikke strengt tatt et RAID-nivå, men en samling av to RAID-grupperinger. Med start fra 2×N disker, setter man dem først opp i parene i N RAID-1-volumer; Disse N volumene blir så samlet til ett, enten ved «lineær RAID», eller (i økende grad) av LVM. Dette siste tilfellet går lenger enn ren RAID, men det er ikke noe problem med det.
RAID-1+0 kan overleve flere diskfeil: opp til N i 2xN matrisen som er beskrevet ovenfor, forutsatt at minst en disk fortsetter å virke i hver av RAID-1-parene.
Selvfølgelig vil RAID-nivået velges ut fra begrensningene og kravene til hvert program. Merk at en enkelt datamaskin kan ha flere forskjellige RAID-matriser med forskjellige konfigurasjoner.

12.1.1.2. Å sette opp RAID

Å sette opp RAID-volumer krever mdadm-pakken; den leverer mdadm-kommandoen, som gjør det mulig å lage og håndtere RAID-tabeller, samt prosedyrer og verktøy som integrerer den i resten av systemet, inkludert overvåkningssystemet.
Vårt eksempel vil være en tjener med en rekke disker, der noen er allerede brukt, og resten blir tilgjengelig til å sette opp RAID. Vi har i utgangspunktet følgende disker og partisjoner:
  • sdb-disken, 4 GB, er fullt tilgjengelig;
  • sdc-disken, 4 GB, er også fullt ut tilgjengelig;
  • sdd-disken, er bare partisjonen sdd2 (rundt 4 GB) tilgjengelig;
  • til slutt er en sde-disk, også på 4 GB, fullt ut tilgjengelig.
Vi kommer til å bruke disse fysiske elementer for å bygge to volumer, en RAID-0 og ett speil (RAID-1). La oss starte med RAID-0-volumet:
# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm --query /dev/md0
/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed May  6 09:24:34 2015
     Raid Level : raid0
     Array Size : 8387584 (8.00 GiB 8.59 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:24:34 2015
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : mirwiz:0  (local to host mirwiz)
           UUID : bb085b35:28e821bd:20d697c9:650152bb
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 2095104 4k blocks and 524288 inodes
Filesystem UUID: fff08295-bede-41a9-9c6a-8c7580e520a6
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.9G   18M  7.4G   1% /srv/raid-0
Kommandoen mdadm --create krever flere parametre: Navnet på volumet som skal lages (/dev/md*, der MD står for Multiple Device), RAID-nivået, antall disker (som er obligatorisk til tross for at det er mest meningsfullt bare med RAID-1 og over), og de fysiske enhetene som skal brukes. Når enheten er opprettet, kan vi bruke den som vi ville bruke en vanlig partisjon, opprette et filsystem på den, montere dette filsystemet, og så videre. Vær oppmerksom på at vår etablering av et RAID-0-volum på md0 ikke er et sammentreff, og nummereringen av tabellen ikke trenger å være korrelert til den valgte størrelsen på reservekapasiteten. Det er også mulig å lage navngitte RAID-arrays, ved å gi mdadm parametre slik som /dev/md/linear i stedet for /dev/md0.
Opprettelse av en RAID-1 følger opp en lignende måte, forskjellene blir bare merkbare etter etableringen:
# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1%
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Wed May  6 09:30:19 2015
     Raid Level : raid1
     Array Size : 4192192 (4.00 GiB 4.29 GB)
  Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:30:40 2015
          State : clean, resyncing (PENDING) 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       8       64        1      active sync   /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
          State : clean
[...]
Noen få merknader er på sin plass. Først, mdadm merker at de fysiske elementene har forskjellige størrelser; siden dette innebærer at noe plass går tapt på de større elementene, kreves en bekreftelse.
Enda viktigere er det å merke tilstanden til speilet. Normal tilstand for et RAID-speil er at begge diskene har nøyaktig samme innhold. Men ingenting garanterer at dette er tilfelle når volumet blir opprettet. RAID-subsystem vil derfor gi denne garantien selv, og det vil være en synkroniseringsfase så snart RAID-enheten er opprettet. Etter en tid (den nøyaktige tiden vil avhenge av den faktiske størrelsen på diskene ...), skifter RAID-tabellen til «aktiv» eller «ren» tilstand. Legg merke til at i løpet av denne gjenoppbyggingsfasen, er speilet i en degradert modus, og reservekapasitet er ikke sikret. En disk som svikter på dette trinnet kan føre til at alle data mistes. Store mengder av viktige data er imidlertid sjelden lagret på en nyopprettet RAID før den første synkroniseringen. Legg merke til at selv i degradert modus, vil /dev/md1 kunne brukes, og et filsystem kan opprettes på den, så vel som noe data kopieres på den.
La oss nå se hva som skjer når et av elementene i RAID-1-tabellen svikter. mdadm, spesielt --fail-valget tillater å simulere en slik diskfeiling:
# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Wed May  6 09:39:39 2015
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 19

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       0        0        2      removed

       1       8       64        -      faulty   /dev/sde
Innholdet i volumet er fortsatt tilgjengelig (og, hvis det er montert, legger ikke programmene merke til en ting), men datasikkerheten er ikke trygg lenger: Skulle sdd-disken i sin tur svikte, vil dataene gå tapt. Vi ønsker å unngå denne risikoen, så vi erstatter den ødelagte disken med en ny en, sdf:
# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
[...]
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:48:49 2015
          State : clean, degraded, recovering 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Rebuild Status : 28% complete

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 26

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      spare rebuilding   /dev/sdf

       1       8       64        -      faulty   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Wed May  6 09:49:08 2015
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 41

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf

       1       8       64        -      faulty   /dev/sde
Her igjen utløser kjernen automatisk en rekonstruksjonsfase der volumet fortsatt er tilgjengelig, men i en degradert modus. Når gjenoppbyggingen er over, er RAID-matrisen tilbake i normal tilstand. Man kan da si til systemet at sde-disken er i ferd med å bli fjernet fra matrisen, for å ende opp med et klassisk RAID-speil på to disker:
# mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf
Fra da av kan driveren fysisk fjernes når tjeneren nærmest er slått av, eller til og med hot-fjernes når maskinvareoppsettet tillater det. Slike konfigurasjoner inkluderer noen SCSI-kontrollere, de fleste SATA-disker, og eksterne harddisker som opererer via USB eller Firewire.

12.1.1.3. Sikkerhetskopi av konfigureringen

De fleste av meta-dataene som gjelder gjelder RAID-volumer lagres direkte på diskene til disse matrisene, slik at kjernen kan oppdage matriser og komponentene deres, og montere dem automatisk når systemet starter opp. Men det oppmuntres til sikkerhetskopiering av denne konfigurasjonen, fordi denne deteksjonen ikke er feilfri, og det er bare å forvente at den vil svikte akkurat under sensitive omstendigheter. I vårt eksempel, hvis en svikt i sde-disken hadde vært virkelig (i stedet for simulert), og systemet har blitt startet på nytt uten å fjerne denne sde-disken, kunne denne disken begynne å jobbe igjen etter å ha blitt undersøkt under omstarten. Kjernen vil da ha tre fysiske elementer, som hver utgir seg for å inneholde halvparten av det samme RAID-volumet. En annen kilde til forvirring kan komme når RAID-volumer fra to tjenere er konsolidert inn i bare en tjener. Hvis disse matrisene kjørte normalt før diskene ble flyttet, ville kjernen være i stand til å oppdage og montere parene riktig; men hvis de flyttede diskene hadde blitt samlet i en md1 på den gamle tjeneren, og den nye tjeneren allerede har en md1, ville et av speilene få nytt navn.
Å sikkerhetskopiere konfigurasjonen er derfor viktig, om bare som referanse. Den vanlige måten å gjøre det på er å redigere /etc/mdadm/mdadm.conf-filen, et eksempel på det er listet her:

Eksempel 12.1. mdadm-konfigurasjonsfil

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

# This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100
# by mkconf 3.2.5-3
En av de mest nyttige detaljer er DEVICE-valget, som viser enhetene som systemet automatisk vil se etter deler av RAID-volumer ved oppstartstidspunktet. I vårt eksempel erstattet vi standardverdien, partitions containers, med en eksplisitt liste over enhetsfiler, siden vi valgte å bruke hele disker, og ikke bare partisjoner for noen volumer.
De to siste linjene i vårt eksempel er de som tillater kjernen trygt å velge hvilke volumnummer som skal tilordnes hvilken matrise. Metadataene som er lagret på selve diskene er nok til å sette volumene sammen igjen, men ikke for å bestemme volumnummeret (og det matchende /dev/md*-enhetsnavn).
Heldigvis kan disse linjene generes automatisk:
# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464
Innholdet i disse to siste linjene er ikke avhengig av listen over disker som inngår i volumet. Det er derfor ikke nødvendig å regenerere disse linjene når du skifter ut en feilet disk med en ny. På den annen side må man sørge for å oppdatere filen når du oppretter eller sletter et RAID-oppsett.

12.1.2. LVM

LVM, Logical Volume Manager ( logisk volumhåndtering), er en annen tilnærming for å abstrahere logiske volumer fra sin fysiske forankring, som fokuserer på økt fleksibilitet i stedet for økt pålitelighet. LVM lar deg endre et logisk volum transparent så langt programmene angår; for eksempel er det mulig å legge til nye disker, overføre dataene til dem, og fjerne gamle disker, uten at volumet demonteres.

12.1.2.1. LVM-konsepter

Denne fleksibilitet oppnås med et abstraksjonsnivå som involverer tre konsepter.
Først, PV (Physical Volume, fysisk volum) er enheten nærmest maskinvaren: Det kan være partisjoner på en disk, en full disk, eller til og med en annen blokkenhet (inkludert, for eksempel, en RAID-matrise). Merk at når et fysisk element er satt opp til å bli en PV for LVM, skal den kun være tilgjengelige via LVM, ellers vil systemet bli forvirret.
Et antall PV-er kan samles i en VG (Volume Group, volumgruppe), som kan sammenlignes med både virtuelle og utvidbare disker. VG er abstrakte, og vises ikke i en enhetsfil i /dev-hierarkiet, så det er ingen risiko for å bruke dem direkte.
Den tredje typen objekt er LV (Logical Volume, logisk volum), som er en del av en VG; hvis vi holder på VG-as-disk analogien, LV kan sammenlignes med en partisjon. LV-en fremstår som en blokkenhet med en oppføring i /dev, og den kan brukes som en hvilken som helst annen fysisk partisjon (som oftest, for å være vert for et filsystem eller et vekselminne).
Det viktige er at splittingen av en VG til LVS-er er helt uavhengig av dens fysiske komponenter (PVS-ene). En VG med bare en enkelt fysisk komponent (en disk for eksempel) kan deles opp i et dusin logiske volumer; på samme måte kan en VG bruke flere fysiske disker, og fremstå som et eneste stort logisk volum. Den eneste begrensningen, selvsagt, er at den totale størrelsen allokert (fordelt) til LV-er kan ikke være større enn den totale kapasiteten til PV-ene i volumgruppen.
Det er imidlertid ofte fornuftig å ha en viss form for homogenitet blant de fysiske komponentene i en VG, og dele VG-en i logiske volumer som vil ha lignende brukermønstre. For eksempel, hvis tilgjengelig maskinvare inkluderer raske og tregere disker, kan de raske bli gruppert i en VG, og de tregere i en annen; deler av den første kan deretter bli tildelt til applikasjoner som krever rask tilgang til data, mens den andre kan beholdes til mindre krevende oppgaver.
I alle fall, husk at en LV ikke er spesielt knyttet til en bestemt PV. Det er mulig å påvirke hvor data fra en LV fysisk er lagret, men å bruk denne muligheten på daglig basis er ikke nødvendig. Tvert imot: Ettersom settet med fysiske komponenter i en VG utvikler seg, kan de fysiske lagringsstedene som tilsvarer en bestemt LV, migreres over disker (mens den selvfølgelig blir værende innenfor PV-er tildelt VG-en).

12.1.2.2. Å sette opp LVM

La oss nå følge, trinn for trinn, prosessen med å sette opp LVM for et typisk brukstilfelle: Vi ønsker å forenkle en kompleks lagringssituasjon. En slik situasjon skjer vanligvis etter en lang og innfløkt historie med akkumulerte midlertidige tiltak. For illustrasjonsformål vil vi vurdere en tjener der lagringsbehovene har endret seg over tid, og endte opp i en labyrint av tilgjengelige partisjoner fordelt over flere delvis brukte disker. Mer konkret er følgende partisjoner tilgjengelige:
  • sdb-disken, en sdb2-partisjon, 4 GB;
  • sdc-disken, en sdc3-partisjon, 3 GB;
  • sdd-disken, 4 GB, fullt tilgjengelig;
  • sdf-disken, en sdf1-partisjon, 4 GB; og en sdf2-partisjon, 5 GB.
I tillegg, la oss anta at diskene sdb og sdf er raskere enn de andre to.
Vårt mål er å sette opp tre logiske volumer for tre ulike programmer: En filtjener som krever 5 GB lagringsplass, en database (1 GB), og noe plass for sikkerhetskopiering (12 GB). De to første trenger god ytelse, men sikkerhetskopiering er mindre kritisk med tanke på tilgangshastighet. Alle disse begrensninger forhindrer bruk av partisjoner på egen hånd; å bruke LVM kan samle den fysiske størrelsen på enhetene, slik at den totale tilgjengelige plassen er den eneste begrensningen.
De verktøy som kreves er i lvm2-pakken og det den krever. Når de er installert, skal det tre trinn til for å sette opp LVM som svarer til de tre konseptnivåene.
Først forbereder vi de fysiske volumene ved å bruke pvcreate:
# pvdisplay
# pvcreate /dev/sdb2
  Physical volume "/dev/sdb2" successfully created
# pvdisplay
  "/dev/sdb2" is a new physical volume of "4.00 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb2
  VG Name               
  PV Size               4.00 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I

# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
  Physical volume "/dev/sdc3" successfully created
  Physical volume "/dev/sdd" successfully created
  Physical volume "/dev/sdf1" successfully created
  Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
  PV         VG   Fmt  Attr PSize PFree
  /dev/sdb2       lvm2 ---  4.00g 4.00g
  /dev/sdc3       lvm2 ---  3.09g 3.09g
  /dev/sdd        lvm2 ---  4.00g 4.00g
  /dev/sdf1       lvm2 ---  4.10g 4.10g
  /dev/sdf2       lvm2 ---  5.22g 5.22g
Så langt så bra. Vær oppmerksom på at en PV kan settes opp på en full disk, samt på individuelle partisjoner på den. Som vist ovenfor pvdisplay-kommandoen lister eksisterende PV-er, med to mulige utdataresultater.
Nå la oss sette sammen disse fysiske elementer til VG-er ved å bruke vgcreate. Vi vil samle bare PV-er fra de raske diskene inn i en vg_critical-VG. Den andre VG-en, vg_normal, vil også inkludere langsommere elementer.
# vgdisplay
  No volume groups found
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
  Volume group "vg_critical" successfully created
# vgdisplay
  --- Volume group ---
  VG Name               vg_critical
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               8.09 GiB
  PE Size               4.00 MiB
  Total PE              2071
  Alloc PE / Size       0 / 0   
  Free  PE / Size       2071 / 8.09 GiB
  VG UUID               bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
  Volume group "vg_normal" successfully created
# vgdisplay -C
  VG          #PV #LV #SN Attr   VSize  VFree 
  vg_critical   2   0   0 wz--n-  8.09g  8.09g
  vg_normal     3   0   0 wz--n- 12.30g 12.30g
Her igjen, kommandoer er ganske greie (og vgdisplay foreslår to utdataformater). Merk at det er fullt mulig å bruke to partisjoner på samme fysiske disk i to forskjellige VG-er. Merk også at vi brukte en vg_-forstavelse til å navngi våre VG-er, men det er ikke noe mer enn en konvensjon.
Vi har nå to «virtuelle disker», med størrelse henholdsvis ca. 8 GB og 12 GB. La oss nå riste dem opp i «virtuelle partisjoner» (LV-er). Dette innbefatter lvcreate-kommandoen, og en litt mer komplisert syntaks:
# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
  Logical volume "lv_files" created
# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_critical/lv_files
  LV Name                lv_files
  VG Name                vg_critical
  LV UUID                J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
  LV Write Access        read/write
  LV Creation host, time mirwiz, 2015-06-10 06:10:50 -0400
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created
# lvcreate -n lv_backups -L 12G vg_normal
  Logical volume "lv_backups" created
# lvdisplay -C
  LV         VG          Attr     LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
  lv_base    vg_critical -wi-a---  1.00g                                           
  lv_files   vg_critical -wi-a---  5.00g                                           
  lv_backups vg_normal   -wi-a--- 12.00g
To parametere er nødvendig når du oppretter logiske volumer; de må sendes til lvcreate som valgmuligheter. Navnet på LV som skal opprettes er angitt med alternativet -n, og størrelsen dens er generelt gitt ved å bruke -L-alternativet. Vi trenger også, selvfølgelig, å fortelle kommandoen hvilken VG som skal brukes, derav den siste parameteren på kommandolinjen.
Logiske volumer, en gang laget, ender opp som blokkenhetsfiler i /dev/mapper/:
# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jun 10 16:52 control
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2
For å gjøre ting enklere er praktiske og egnede symbolske lenker også opprettet i kataloger som samsvarer med VG-er:
# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2
LV-er kan deretter brukes akkurat som standard partisjoner:
# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 3145728 4k blocks and 786432 inodes
Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups   12G   30M   12G   1% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base    /srv/base       ext4 defaults 0 2
/dev/vg_critical/lv_files   /srv/files      ext4 defaults 0 2
/dev/vg_normal/lv_backups   /srv/backups    ext4 defaults 0 2
Fra programsynspunkt har de utallige små partisjonene nå blitt abstrahert til ett stort 12 GB volum, med et vennligere navn.

12.1.2.3. LVM over tid

Selv om muligheten til å aggregere partisjoner eller fysiske disker er praktisk, er dette ikke den viktigste fordelen LVM har brakt. Den fleksibiliteten den gir, er spesielt lagt merke til over tid, ettersom behovene utvikler seg. I vårt eksempel, la oss anta at nye store filer må lagres, og at LV øremerket til filtjeneren er for liten til å romme dem. Siden vi ikke har brukt hele plassen i vg_critical, kan vi øke lv_files. For det formålet bruker vi lvresize-kommandoen, deretter resize2fs for å tilpasse filsystemet tilsvarende:
# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  5.0G  4.6G  146M  97% /srv/files
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
  lv_files vg_critical -wi-ao-- 5.00g
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   2   2   0 wz--n- 8.09g 2.09g
# lvresize -L 7G vg_critical/lv_files
  Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents).
  Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
  lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1835008 (4k) blocks long.

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  6.9G  4.6G  2.1G  70% /srv/files
Vi kunne fortsette på en lignende måte å utvide volumet som er vertskap for databasen, bare til vi har nådd VG-ens grense for tilgjengelig plass:
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 1008M  854M  104M  90% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree 
  vg_critical   2   2   0 wz--n- 8.09g 92.00m
Det er ikke noe problem ettersom LVM tillater å legge til fysiske volumer til eksisterende volumgrupper. Vi har for eksempel kanskje lagt merke til at sdb1-partisjonen, som så langt ble brukt utenfor LVM, bare inneholdt arkiver som kan flyttes til lv_backups. Vi kan nå resirkulere den, og integrere den i volumgruppen, og dermed gjenvinne noe ledig plass. Dette er hensikten med vgextend-kommandoen. Selvfølgelig må partisjonen på forhånd forberedes som et fysisk volum. Når VG er utvidet, kan vi bruke lignende kommandoer som tidligere for å utvide det logiske volumet, og deretter filsystemet:
# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
  Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   3   2   0 wz--n- 9.09g 1.09g
# [...]
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  854M  1.1G  45% /srv/base

12.1.3. RAID eller LVM?

RAID og LVM bringer begge udiskutable fordeler så snart man forlater det enkle tilfellet med en stasjonær datamaskin med en enkelt harddisk, der bruksmønster ikke endres over tid. Men RAID og LVM går i to forskjellige retninger, med divergerende mål, og det er legitimt å lure på hvilken som bør velges. Det mest hensiktsmessige svaret vil selvfølgelig avhenge av nåværende og forventede krav.
Det finnes noen enkle tilfeller hvor spørsmålet egentlig ikke oppstår. Hvis kravet er å sikre data mot maskinvarefeil, så vil åpenbart RAID bli satt opp med en romslig matrise med disker, ettersom LVM ikke løser dette problemet. Dersom det, på den annen side, er behov for et fleksibelt lagringsopplegg der volumene lages uavhengig av den fysiske utformingen av diskene, bidrar ikke RAID med mye, og LVM vil være det naturlige valget.
Det tredje bemerkelsesverdige brukstilfellet er når man bare ønsker å samle to disker i ett volum, enten av ytelseshensyn, eller for å ha et enkelt filsystem som er større enn noen av de tilgjengelige diskene. Dette tilfellet kan adresseres både med en RAID-0 (eller til og med en lineær-RAID), og med et LVM-volum. Når du er i denne situasjonen, og sperring gir ekstra begrensninger (for eksempel å måtte være på linje med resten av datamaskinene hvis de bare bruker RAID), vil konfigurasjonsvalget ofte være LVM. Første oppsett er snaut nok komplekst, og den svake økning i kompleksitet mer enn gjør opp for LVMs ekstra fleksibiliteten dersom kravene må endres, eller dersom nye disker må legges til.
Så selvfølgelig er det det virkelig interessante brukereksempel, der lagringssystemet må gjøres både motstandsdyktig mot maskinvarefeil, og gi en fleksibel volumtildeling. Verken RAID eller LVM kan imøtekomme begge kravene på egen hånd. Uansett, det er her vi bruker begge samtidig - eller rettere sagt, den ene oppå den andre. Ordningen som har alt, men er blitt en standard siden RAID og LVM har nådd modenheten til å sikre datatallighet (dataredundans), først ved å gruppere disker i et lite antall store RAID-matriser, og å bruke disse RAID-matrisene som LVM fysiske volumer. Logiske partisjoner vil da bli meislet ut fra disse LV-ene for filsystemer. Salgspoenget med dette oppsettet er at når en disk svikter, vil bare et lite antall RAID-matriser trenge rekonstruering, og dermed begrense tiden administrator bruker for gjenoppretting.
La oss ta et konkret eksempel: PR-avdelingen på Falcot Corp trenger en arbeidsstasjon for videoredigering, men avdelingens budsjett tillater ikke investere i dyr maskinvare fra bunnen av. Det er avgjort å favorisere maskinvaren som spesifikk for det grafiske arbeidets art (skjerm og skjermkort), og å fortsette med felles maskinvare for lagring. Men som viden kjent ,har digital video noen spesielle krav til mengden av date for lagring, og gjennomstrømningshastighet for lesing og skriving er viktig for den generelle systemytelsen (mer enn vanlig aksesstid, for eksempel). Disse begrensningene må være imøtekommet med felles maskinvare, i dette tilfellet med 300 GB SATA-harddisker. Systemdata må også gjøres motstandsdyktige mot maskinvarefeil, og også noen brukerdata. Redigerte videoklipp må faktisk være trygge, men for videoer som venter på redigering er det mindre kritisk, siden de fortsatt er på videobånd, eller på opptaksutstyret.
RAID-1 og LVM kombineres for å tilfredsstille disse begrensningene. Diskene er knyttet til to forskjellige SATA-kontrollere for å optimalisere parallell tilgang, og redusere risikoen for samtidig svikt, og de synes derfor som sda og sdc. De er partisjonert likt langs det følgende skjemaet:
# fdisk -l /dev/sda

Disk /dev/sda: 300 GB, 300090728448 bytes, 586114704 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00039a9f

Device    Boot     Start       End   Sectors Size Id Type
/dev/sda1 *         2048   1992060   1990012 1.0G fd Linux raid autodetect
/dev/sda2        1992061   3984120   1992059 1.0G 82 Linux swap / Solaris
/dev/sda3        4000185 586099395 582099210 298G 5  Extended
/dev/sda5        4000185 203977305 199977120 102G fd Linux raid autodetect
/dev/sda6      203977306 403970490 199993184 102G fd Linux raid autodetect
/dev/sda7      403970491 586099395 182128904  93G 8e Linux LVM
  • De første partisjonene til begge disker (ca 1 GB) er satt sammen til ett RAID-1-volum md0. Dette speilet er direkte brukt til å lagre rotfilsystemet.
  • Partisjonene sda2 og sdc2 brukes som vekselminnepartisjoner, noe som gir en totalt 2 GB vekselminne. Med 1 GB RAM, har arbeidsstasjonen en komfortabel mengde tilgjengelig minne.
  • Partisjonene sda5 og sdc5, så vel som sda6 og sdc6, er samlet til to nye RAID-1-volumer på rundt 100 GB hver, md1 og md2. Begge disse speilene er internalisert som fysiske volumer for LVM, og knyttet til volumgruppen vg_raid. Denne VG-en inneholder derfor et trygt rom på 200 GB.
  • De gjenstående partisjoner, sda7 og sdc7, brukes direkte som fysiske volumer, og knyttet til en annen VG kalt vg_bulk, som da ender opp med omtrent 200 GB lagringsplass.
Når VG-er er opprettet, kan de fordeles svært fleksibelt. Man må huske på at LV-er opprettet i vg_raid, blir bevart selv om en av diskene svikter, noe som ikke vil være tilfelle for LV-er opprettet i vg_bulk. På den annen side vil de sistnevnte fordeles i parallell på begge disker, som tillater høyere lese- eller skrivehastigheter for store filer.
Vi vil derfor lage lv_usr, lv_var og lv_home LVs on vg_raid til å være vertskap for de matchende filsystemene. En annen stor LV, lv_movies, skal brukes som vert for endelige versjoner av filmer etter redigering. Den andre VG-en vil bli delt inn i et stort lv_rushes, for data rett fra det digitale videokameraet, og et lv_tmp for midlertidige filer. Plasseringen av arbeidsområdet er et mindre enkelt valg å ta. Mens god ytelse er nødvendig for det volumet, er det verdt å risikere å miste arbeid hvis en disk svikter under redigeringsøkten ? Avhengig av svaret på det spørsmålet, vil den aktuelle LV-en bli lagt til den ene VG-en, eller på den andre.
Vi har nå både litt overskudd til viktige data, og mye fleksibilitet i hvordan den tilgjengelige plassen er delt på tvers av programmene. Skal ny programvare installeres senere (for å redigere lydklipp, for eksempel), kan LV-vertskapet /usr/ utvides smertefritt.