håndtering af LVM-Snapshots i LVM2

LVM-Snapshots

vi vil nu begynde at se på nogle mere avancerede LVM2-emner, og den første op administrerer LVM-Snapshots. I den næste blog vil vi se på Tynd Provisioning i LVM. LVM Snapshots er punkt i tid kopier af LVM logiske mængder. De er pladseffektive, idet de begynder at lagre Ingen data, men da data er chenged på kilden LV, skrives de oprindelige data til LVM Snapshot-lydstyrken. Brugssagerne til dette inkluderer:

  • sikkerhedskopier: LVM-snapshots i sig selv er ikke en effektiv sikkerhedskopi, da den skal gemmes inden for den samme Volumengruppe. Snapshots kan dog bruges til at udvide sikkerhedskopier. Bare oprette et øjebliksbillede af målet volumen og derefter backup snapshot volumen til at overvinde eventuelle problemer at gøre med fil-samtidighed under backup. Snapshotet kan slettes i slutningen af sikkerhedskopieringsprocessen
  • Test and Destroy: LVM snapshots er en læse / skrive kopi af den originale LV. Du kan oprette en LVM snapshots af en LV, der indeholder komplekse scripts, ændre ansd teste dem så meget som du ønsker, og derefter ødelægge data, når du er færdig. Alt uden at påvirke de originale scripts.
  • test af nye Programmelinstallationer: installationen af en ny version af programmel kan omfatte mange hundrede filer, der findes gennem mange programmelmapper. Hvis målet placering for alle programmer er på en enkelt LVM logisk volumen så kan vi oprette et øjebliksbillede før opdatering af programmet. Hvis programmet efter test ikke fungerer på den ønskede måde. Det er en simpel opgave at vende tilbage den oprindelige LV til snapshot. Snapshot, selvfølgelig, holder det tidspunkt kopi af det oprindelige kildevolumen på det tidspunkt, hvor snapshotet blev taget.

Følg nedenstående link for at hente ‘Complete Guide to LVM2 i Linuks’, koster bare en pris på 1,99! Når den er hentet eBook kan udskrives, hvis det kræves.

Hent eBook

forberedelse til at oprette en LVM Snapshots

en LVM snapshot skal oprettes i samme volumen gruppe som kilden LV. Ved hjælp af Ko (kopi på Skriv) teknologi skal den underliggende opbevaring være den samme. Tillader uændrede data i snapshot skal læses fra den oprindelige LV kilde. Vores Volumengruppe er fuld, så vi sletter den eksisterende logiske lydstyrke og genskaber den en mindre størrelse. Vi vil også bruge to mountpoints, /mnt/original og /mnt/snap.

efter alt dette arbejde er vi nu tilbage til den situation, hvor vi har et nyligt formateret logisk volumen, som vi har kaldt lv1. Dette er nu monteret på/mnt / original med henblik på demonstrationen. Vi har oprettet lv1 ved 600 MiB, hvilket efterlader 392 MiB ledig plads i Volumengruppen vg1. Husk, at vi kun beskæftiger os med ledig plads i samme Volumengruppe som vores logiske volumener. Snapshot skal oprettes i samme Volumengruppe som kilden LV. hvis vi kontrollerer output fra kommandoen vgs, kan vi se den tilgængelige ledige plads:

# vgs VG #PV #LV #SN Attr VSize VFree vg1 2 1 0 wz--n- 992.00m 392.00m vg2 2 0 0 wz--n- 192.00m 192.00m

denne kommando, som vi har set før, er en fantastisk måde at opsummere Volumengrupper på. For at kunne oprette et øjebliksbillede af det logiske volumen, lv1, skal vi tilføje nogle data. Vi kopierer simpelthen filen/etc /services til/MNT / original.

 # cp /etc/services /mnt/original/ # wc -l /mnt/original/services 612 /mnt/original/services

vi kan også se, at denne fil på min Ubuntu-Server har 612 linjer. Vi har nu data, så lad os knække på.

oprettelse af LVM Snapshots i LVM2

LVM Snapshots er i det væsentlige enkle logiske volumener med nogle ekstra godbidder boltet på. Så de oprettes ved hjælp af kommandoen lvcreate og indstillingen –s. Vi skal også angive kildevolumen, når du opretter snapshot.

 # lvcreate -L 12m -s /dev/vg1/lv1 -n lv1_snap Logical volume "lv1_snap" created.

fra kommandoindstillingerne kan vi se, at vi først angiver størrelsen til at være 12 MiB. Vi har kun brug for plads nok til at gemme de ændringer, vi foretager i kilden. Vi kunne have fyldt kilden LV med 600 MiB data, men hvis kun 12 MiB sandsynligvis vil ændre sig, har vi kun brug for et 12 MiB snapshot-volumen. Vi Størrelse snapshot til at matche størrelsen af ændringer, der vil opstå. Indstillingen – s eller-snapshot angiver kildevolumen til snapshot. Som før indstiller indstillingen-n navnet på den LV, vi opretter.Snapshotet læses / skrives, så det kan monteres. Lad os gå videre og montere den på biblioteket / mnt / snap:

# mount /dev/vg1/lv1_snap /mnt/snap/

vi vil være i stand til at se det samme indhold i begge mapper, selvom der ikke har fundet nogen ændringer sted. LVM snapshots linker til de oprindelige data, indtil de ændres.

når vi ser på detaljerne i både kilde-og snapshot-lydstyrken, vil det se lidt anderledes ud. For det første lv1_snap volumen. Snapshot LV.

# lvdisplay /dev/vg1/lv1_snap --- Logical volume --- LV Path /dev/vg1/lv1_snap LV Name lv1_snap VG Name vg1 LV UUID s8gBiX-IV1z-jiZK-q4dN-paG5-8mvq-TCQkuk LV Write Access read/write LV Creation host, time yogi, 2017-08-22 09:26:14 +0000 LV snapshot status active destination for lv1 LV Status available # open 1 LV Size 600.00 MiB Current LE 150 COW-table size 12.00 MiB COW-table LE 3 Allocated to snapshot 0.36% Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 252:3

vi kan huske, jeg håber bestemt, at du gør det, at vi skabte dette med en størrelse på 12 MiB. LV-størrelsen viser dog som 600 MiB. Den størrelse, vi ser, er af originalen eller kilden LV. Kopiering på skrivning sker, når data ændres i kilden, og de originale data kopieres derefter til snapshot-lydstyrken. Snapshot-lydstyrken viser altid de originale snapshot-filer, uanset om de er ændret eller ej. Ved oprettelse af snapshot er der ingen Koændringer at gemme, så den tildelte værdi er meget lav at starte og vil stige, når der foretages ændringer i kildedataene. Når vi ser på displaydetaljerne nu for lv1 LV, vil det også være lidt anderledes:

# lvdisplay /dev/vg1/lv1 --- Logical volume --- LV Path /dev/vg1/lv1 LV Name lv1 VG Name vg1 LV UUID dmVaWm-kA9V-xouM-OZBR-b7Id-aMUh-EWymB0 LV Write Access read/write LV Creation host, time yogi, 2017-08-21 18:51:57 +0000 LV snapshot status source of lv1_snap LV Status available # open 1 LV Size 600.00 MiB Current LE 150 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 252:0

vi kan se, at det viser som kilde til snapshot for lv1_snap.

ændring af LVM Snapshot Data

hvis vi nu foretager en ændring af dataene i kildevolumenet, begynder vi at se en forskel i dataene i snapshot-lydstyrken. Snapshot volumen vil holde de oprindelige data, mens kilden LV vil holde ændringerne. Først tilføjer vi en ny fil til kildevolumen:

# cp /etc/hosts /mnt/original/

vi kan nu se, at indholdet adskiller sig for kilden til snaphot-volumenerne

vi kan også se, at vi begynder at forbruge mere ko-plads i det logiske volumen. Når vi vender tilbage til lvdisplay for lv1_snap, vil vi se den tildelte procentdel til snapshot stigende.

# lvdisplay /dev/vg1/lv1_snap --- Logical volume --- LV Path /dev/vg1/lv1_snap LV Name lv1_snap VG Name vg1 LV UUID s8gBiX-IV1z-jiZK-q4dN-paG5-8mvq-TCQkuk LV Write Access read/write LV Creation host, time yogi, 2017-08-22 09:26:14 +0000 LV snapshot status active destination for lv1 LV Status available # open 1 LV Size 600.00 MiB Current LE 150 COW-table size 12.00 MiB COW-table LE 3 Allocated to snapshot 0.98% Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 252:3

selvom vi ikke har ændret de eksisterende data, vil tilføjelse af nye data også påvirke snapshot, da snapshot-lydstyrken skal vise dataene, som det var, da snapshot blev taget. Hvis det er nødvendigt, skal vi være i stand til at vende originalen tilbage til de snapshottede data.

dernæst overskriver vi den originale/etc / services-fil:

# > /mnt/original/services

filen / mnt / original / services vil nu være tom. Hvis vi kontrollerer snapshot-filen, vil den stadig have dataene. Ved hjælp af kommandoen toilet kan vi tælle antallet af linjer i hver fil:

 # wc -l /mnt/original/services /mnt/snap/services 0 /mnt/original/services 612 /mnt/snap/services 612 total

selvfølgelig vil rechecking output af lvdisplay for lv1_snap vise, at allokeret til snapshot procent er steget med ændringen:

Allocated to snapshot 1.17%

volumenændringer for LVM Snapshots

attributterne for både kilde og snapshot LVs ændres, når snapshot oprettes. Vi kan se dette detaljeret med kommandoen lvdisplay, men er bedre opsummeret med kommandoen lvs:

der er 10 attributter, som vi læser fra venstre mod højre:

for lv1 læses attributterne:

  • Volumen Type: Oprindelse. Kilden til et øjebliksbillede
  • tilladelser: skrivbar
  • Tildelingspolitik: arvet fra Volumengruppen
  • Fast Mindre nummer er ikke indstillet
  • tilstand: er markeret som aktiv
  • enhed: er åben eller monteret
  • måltype: Snapshot, dvs. det deltager i et øjebliksbillede

for Lv1_snap attributterne læses:

  • Volume Type: Snapshot volume
  • tilladelser: skrivbar
  • Tildelingspolitik: Arvet fra Volumengruppen
  • Fast Mindre nummer er ikke indstillet
  • tilstand: er markeret som aktiv
  • enhed: er åben eller monteret
  • måltype: Snapshot, dvs.det deltager i et snapshot

originalen og målgruppen skal være i samme Volumengruppe som vi allerede har nævnt, men de vandt del ikke nødvendigvis de samme enheder inden for disse Volumengrupper. Dette abstraheres normalt fra os, men vi kan tilføje indstillingen til kommandoen lvs:

tilføjelse i –o for optioner og +enheder viser de underliggende enheder, der udgør LV. vi kan se, at lv1 er større end enten /dev/sdc1 eller /dev/sdc2 og er spændt på tværs af begge. Mens vg1_snap kan gøre brug af det resterende rum i /dev/sdc2. Nummeret i parentes efter enhedsnavnet angiver det fysiske omfang nummer, som LV starter på fra enheden. Vi kan se, at lv1 starter fra på omfang 0 for både / dev /sdc1 og/dev /sdc2 og lv1_snap starter på omfang 26 af/dev / sdc2. For at se alle muligheder, der er tilgængelige for dig med indstillingen –o, skal du bruge kommandoen:

# lvs -o help

da listen er omfattende, har vi ikke medtaget output.

ud over at se direkte på de logiske volumener kan vi også bruge kommandoen lsblk. Her vil vi se flere ændringer, end du måske tror:

 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop1 7:1 0 100M 0 loop sdb 8:16 0 256M 0 disk loop0 7:0 0 100M 0 loop sdc 8:32 0 1000M 0 disk ├─sdc2 8:34 0 500M 0 part │ ├─vg1-lv1-real 252:1 0 600M 0 lvm │ │ ├─vg1-lv1 252:0 0 600M 0 lvm /mnt/original │ │ └─vg1-lv1_snap 252:3 0 600M 0 lvm /mnt/snap │ └─vg1-lv1_snap-cow 252:2 0 12M 0 lvm │ └─vg1-lv1_snap 252:3 0 600M 0 lvm /mnt/snap └─sdc1 8:33 0 499M 0 part └─vg1-lv1-real 252:1 0 600M 0 lvm ├─vg1-lv1 252:0 0 600M 0 lvm /mnt/original └─vg1-lv1_snap 252:3 0 600M 0 lvm /mnt/snap sda 8:0 0 9.8G 0 disk /

vi er allerede bekendt med VG1-lv1-enheden og VG1-lv1_snap-enhederne. Disse har været de underliggende LV ‘ er, vi har arbejdet med. Kernens hovednummer eller driver, der bruges med LVM2, er 252. Så vi ser dette for alle de LV ‘ er, vi har på plads. Den første LV var vg1-lv1, så dette har det mindre antal 0. Når vi ser på vg1-lv1_snap, har dette dog et mindre antal 3, der angiver det 4.LV og ikke 2. som vi kan forvente. I stedet oprettes to indpakning LV ‘ er til snapshot, vg1-lv1-real og vg1-lv1_snap-ko. Disse administreres internt, og vi bliver ikke involveret i dette objekt, som LVM2 bruger til at styre snapshotting-processen. Hver LV, som vi ser her, har også en tilsvarende devmapper-enhed. Hvis vi viser / dev-mappen og filer på dm -*, kan vi vise disse.

# ls /dev/dm-* /dev/dm-0 /dev/dm-1 /dev/dm-2 /dev/dm-3

igen. vi ser de 4 enheder ikke kun de 2, som vi måske har forventet. Så i baggrunden styrer LVM2 meget for os og giver os kun adgang til de elementer, vi har brug for.

tilbageførsel af en lydstyrke til Snapshot

et gendannelsesscenarie med LVM-snapshots giver os mulighed for at vende tilbage til snapshot.Hvis vi finder ud af, at vi er nødt til at vende den originale LV tilbage til det øjebliksbillede, kan vi gøre det. Husk, at snapshot vil være en repræsentation af det oprindelige volumen på tidspunktet for snapshot. Vi kan gøre dette, efter at en opgradering er blevet testet, og beslutningen er taget om at vende tilbage til det øjebliksbillede, der skulle have været taget før opgraderingsprocessen. For at sikre, at vi kan se dette i realtid, afmonterer vi først begge LV ‘ er:

# umount /mnt/{original,snap}

hvis vi ikke lukker enhederne, bliver vi nødt til at vente til den originale LV, vg1 aktiveres næste gang. Ofte er dette ved en genstart. Med både de logiske volumener, der nu er afmonteret og lukket, bruger vi kommandoen lvconvert til at flette snapshot med forælder eller Oprindelse. Dette vender den logiske Kildevolumen tilbage til snapshot-indholdet. Snapshotet fjernes automatisk i slutningen af processen.

# lvconvert --merge /dev/vg1/lv1_snap Merging of volume lv1_snap started. lv1: Merged: 99.2% lv1: Merged: 100.0%

afhængigt af størrelsen på data, der skal flettes, og diskens hastighed er det muligt, at dette kan tage nogen tid. Du gør brug af –b mulighed for at baggrund processen.

hvis vi nu monterer lv1 igen og kontrollerer indholdet. Vi mangler værtsfilen, der blev tilføjet, efter at snapshotet blev taget. Servicefilen har vi nu det indhold, vi har overskrevet.

 # mount /dev/vg1/lv1 /mnt/original/ # ls /mnt/original/ lost+found services # wc -l /mnt/original/services 612 /mnt/original/services

Test og udvikling

en anden anvendelse til LVM-snapshots er i et testmiljø. Hvis du foretrækker at arbejde direkte med de snapshotted data, så kan du. Når du er færdig, skal du bare afmontere snapshot LV og slette det. Den underliggende oprindelige LV forbliver uændret. Dette er fantastisk, hvor du måske vil arbejde på scripts uden at påvirke de originale produktionsskripter.

processen er stort set den samme, men vi arbejder bare med /mnt/snap-mappen nu. En oversigt over kommandoerne følger:

udvidelse af Snapshot-størrelsen

når vi opretter et snapshot-volumen, skal vi indstille en størrelse, som vi føler er tilstrækkelig til at gemme alle de ændringer, der er foretaget i den originale LV, mens snapshot er på plads. Det er dog muligt automatisk at udvide et snapshot-volumen, hvis det kræves.

det er vigtigt at bemærke, at hvis et øjebliksbillede fylder helt, slettes snapshotet automatisk.

standardindstillingerne tillader ikke, at snapshots automatisk vokser. Vi er nødt til at aktivere dette. Konfigurationen af LVM2 er i / etc/lvm / lvm.conf. Hvis vi søger efter de effektive indstillinger ved hjælp af grep:

 # grep -E '^\s*snapshot_auto' /etc/lvm/lvm.conf snapshot_autoextend_threshold = 100 snapshot_autoextend_percent = 20

at have snapshot_autoekstend_threshold indstillet til 100% betyder, at snapshotet aldrig vil vokse. Så snart vi rammer 100% tærsklen, slettes snapshot. Hvis vi har brug for automatisk udvidelse aktiveret, skal du overveje at indstille dette til noget som 70. I så fald, når snapshot bliver 70% fuld, øges størrelsen. Størrelsen af stigningen i kontrolleret af snapshot_autoeksend_percent. Standarden er indstillet til 20%, hvilket betyder, at størrelsen vil stige med 20% af dens nuværende størrelse, hver gang vækst er påkrævet.

Write a Comment

Din e-mailadresse vil ikke blive publiceret.