Fejlfinding af dårlig deduplikering og komprimeringsforhold for filer på Data Domain Restorers (DDR'er)

Data Domain Restorers (DDR'er) er designet til at indeholde store mængder logiske (prækomprimerede) data vha. minimal fysisk (postkomprimeret) diskplads. Dette opnås ved at bruge:

• Deduplikering af lagrede data for at fjerne dubletter af data, der allerede er gemt på disken på DDR, så kun entydige data efterlades
• Komprimering af entydige data, før disse data skrives fysisk til disken.

Det samlede komprimeringsforhold for data, som en DDR kan hente, varierer af forskellige faktorer som f.eks.:

• Use case
• Datatyper, der er inkluderet
• Konfiguration af sikkerhedskopieringsprogram

Når den er optimalt konfigureret, opnår DDR'er typisk 10-20x samlet komprimeringsforhold (og nogle gange kan vise forhold, der er højere end dette). Omvendt kan det overordnede komprimeringsforhold i nogle miljøer være lavere end dette, hvilket kan forårsage:

• DDR for hurtigt at udtøme sin brugbare kapacitet
• Påvirkning af ydeevnen for sikkerhedskopiering, gendannelse eller replikering
• En ddr-fejl, der lever op til kundens forventninger

Denne artikel har til formål at diskutere:

• En kort oversigt over deduplikering og komprimering af data på en DDR
• Sådan bestemmes det samlede komprimeringsforhold for systemet og individuelle filer
• Faktorer, der kan forårsage forringelse i det samlede komprimeringsforhold

Hvordan kan en Data Domain Restorer indlæse nye data?

• Sikkerhedskopieringsprogrammet sender data (dvs. filer) til DDR.
• DDR opdeler disse filer i dele på 4-12 Kb i størrelse - hvert afsnit ses som et "segment".
• DDR genererer et unikt "fingeraftryk" (svarende til en kontrolsum) for hvert segment afhængigt af de data, der er indeholdt i segmentet.
• Fingeraftrykkene på nyligt modtagne segmenter kontrolleres i forhold til diskindekser på DDR for at afgøre, om DDR allerede har et segment med samme fingeraftryk.
• Hvis DDR allerede indeholder et segment med det samme fingeraftryk, er det tilsvarende segment i de nyankomne data et duplikat og kan fjernes (det er deduplikeret).
• Når alle duplikerede segmenter er blevet fjernet fra de nyligt modtagne data, er der kun unikke eller nye segmenter tilbage.
• Disse unikke eller nye segmenter grupperes i 128 Kb "komprimeringsområder" og komprimeres derefter (vha. lz-algoritmen som standard).
• Komprimerede komprimeringsområder er pakket i 4,5 Mb lagerenheder, der kaldes "containere", som derefter skrives til harddisken.

Hvordan sporer DDR, hvilke segmenter udgør en bestemt fil?

Ud over deduplikering/komprimering af nyligt indkomne data opbygger DDR også et "segmenttræ" for hver registreret fil. Dette er egentlig en liste over "fingeraftryk" i segmentet, der udgør denne fil. Hvis DDR senere skal læse filen tilbage, skal den:

• Find placeringen af filsegmenttræet.
• Læs segmenttræet for at få en liste over alle segment-fingeraftryk, der udgør det område af filen, der skal læses.
• Brug på diskindekser til at bestemme den fysiske placering (det er beholder) af dataene på disken.
• Aflæs data for det fysiske segment fra de underliggende beholdere på disken.
• Brug fysiske segmentdata til at rekonstruere filen.

Filsegmenttræer gemmes også i 4,5 Mb containere på disken og repræsenterer størstedelen af hver fils "metadata" (beskrevet senere i denne artikel).

Hvordan kan det samlede komprimeringsforhold på en DDR bestemmes?

Den samlede udnyttelse af et DDR (og komprimeringsforhold) kan ses ved hjælp af kommandoen "filesys show space". For eksempel:

Aktivt niveau:
Ressourcestørrelse GiB Brugt GiB Anvendelse GiB Brug % cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - -
/data: post-comp 6794.2 6242,4 551,8 92 % 202,5
/ddvar 49,2 9,1 37,6 20 % -


---------------- -------- -------- --------- ---- --------------I dette tilfælde kan vi se:

• Forhåndskomprimerede eller logiske data, der findes på DDR: 115367,8 GB
• Postkomprimeret eller fysisk plads, der bruges på DDR: 6242,4 GB
• Det samlede komprimeringsforhold er 115367,8/6242,4 = 18,48x

Outputtet fra kommandoen "filesys show compression" bekræfter de data, der holdes, den anvendte plads og komprimeringsforholdet. F.eks.:

                   Pre-comp post-comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) faktorfaktor
(reduktion %)
---------------- -------- --------- ----------- ---------- -------------
aktuelt anvendt:*   115367.8 6242.4 – - 18,5x (94,6) <=== BEMÆRK
Skrevet:                                                                          
  Sidste 7 dage 42214,7 1863,2 11,0x 2,1x 22,7x (95,6)
  Sidste 24 timer 4924,8 274,0 8,8x 2,0x 18,0x (94,4)
---------------- -------- --------- ----------- ---------- -------------

Overalingsudnyttelsesfigurer på DDR er beregnet som følger:

• Samlet antal forudkomprimerede data: Summen af den (logiske) forhåndskomprimerede størrelse af alle filer, der ligger i DDR.
• Samlet antal postkomprimerede data: Antallet af "containere" i brug på en disk multipliceret med 4,5 Mb (størrelsen af en enkelt beholder).
• Samlet postkomprimeret størrelse: Antallet af maksimale "containere", der oprettes, gives ledig diskplads på systemet.

Statistik omkring maksimum i brug-beholdere er tilgængelige i autosupports. For eksempel:

Beholdersæt 73fc deta763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <=== Objektbeholderens størrelse i byte
...
    attrs.max_containers = 1546057 <=== Maksimalt muligt antal containere
attrs.free_containers = 125562 <=== Aktuelt ledige containere
attrs.used_containers = 1420495 <=== Aktuelt i brug af beholdere
...

Se her:
 
Hvordan kan deduplikerings- og komprimeringsforhold for en individuel fil, mappe eller mappetræ bestemmes?

Når en fil er optaget, registrerer DDR-posternes statistik om filen, herunder:

• Forudkomprimerede (logiske) bytes
• Størrelse af unikke segmenter efter deduplikering
• Størrelse af unikke segmenter efter deduplikering og komprimering
• Størrelse på filens metadata (dvs. segmenttræ osv.)

Det er muligt at dumpe nogle af disse statistikker ved hjælp af kommandoen "filesys show compression [path]" - for eksempel at rapportere statistik for en enkelt fil:

SE@DDVE60_JF## filesys show compression /data/dæk1/backup/testfile
Total filer: 1;  byte/storage_used: 2,9
oprindelige bytes:        3.242.460.364
Globalt komprimeret:        1.113.584.070
lokalt komprimeret:        1.130.871.915
Metadata:            4.772.672

Sådan rapporteres statistik for et helt mappetræ:

SE@DDVE60_JF## filesys show compression/data/a1/backup
Total files: 3;  byte/storage_used: 1.4
Oprindelige bytes:        7.554.284.280
Globalt komprimeret:        5.425.407.986
lokalt komprimeret:        5.510.685.100
Metadata:           23.263.692

Bemærk dog, at der er et par forbehold omkring brugen af disse statistikker:

• Statistikken genereres på tidspunktet for fil- eller dataindtagelse, og derefter opdateres disse ikke. På grund af, hvordan et DDR fungerer, kan ved brug af nye filer eller sletning af filer, der henviser til de samme data, ændre, hvordan en fil deduplikeres over tid, hvilket får disse statistikker til at blive forældede.
• Derudover kan visse brugstilfælde på DDR (f.eks. hurtig kopi af en fil, derefter sletning af den oprindelige fil) medføre, at disse statistikker bliver misvisende eller ukorrekte.

Som følge heraf bør disse tal kun anses som anslåede.

De forudkomprimerede bytes er ikke nødvendigvis den forudkomprimerede/logiske størrelse af filen. I stedet er det samlede antal byte skrevet til en fil i dens levetid. Derfor overskrives eksisterende filer i visse miljøer ofte (f.eks. dem, der bruger funktionen til virtuelt båndbibliotek), og denne figur kan være større end den logiske størrelse af de tilsvarende filer.

Kan forringelse af data af "dårlig kvalitet" forårsage forringelse af det samlede komprimeringsforhold?

Ja – For at et DDR kan opnå et godt samlet komprimeringsforhold for indlagte data, skal det være i stand til at deduplicere og komprimere disse data. Der findes forskellige typer data, som kan forhindre dette som beskrevet nedenfor:

Prækomprimerede/forkrypterede data:

Disse er datatyper, der enten er komprimeret eller krypteret på klientsystemet eller af sikkerhedskopieringsprogrammet. Dette kan også omfatte programspecifikke filer, der er komprimeret eller krypteret i design (f.eks. mediefiler) og databasefiler, som enten er komprimerede eller krypterede eller integrerede binære objekter som f.eks. mediefiler.

På grund af, hvordan komprimerings- eller krypteringsalgoritmen fungerer som en relativt lille ændring af en fils underliggende data, medfører det ændringer i "ripple out" på tværs af filen. En klient kan f.eks. indeholde en 100 MB krypteret fil, hvor 10 KB er ændret. Normalt ville den resulterende fil være identisk før og efter modifikationer bortset fra 10 KB-afsnittet, der er blevet ændret. Når der bruges kryptering, selvom kun 10 Kb ukrypterede data er blevet ændret før og efter modifikationer, ændrer krypteringsalgoritmen hele filens indhold.

Når sådanne data regelmæssigt ændres og jævnligt sendes til en DDR, får denne "ripple out"-effekt hver generation af filen til at se anderledes ud end tidligere generationer af den samme fil. Derfor indeholder hver generation et unikt sæt segmenter (og segment-fingeraftryk), så det viser et dårligt deduplikeringsforhold.

Bemærk også, at i stedet for forhåndskomprimerede filer vil lz-algoritmen sandsynligvis ikke være i stand til at komprimere avancerede segmentdata yderligere, så data ikke kan komprimeres, før de skrives til disken.

Som en generel retningslinje for prækomprimering/prækryptering medfører det følgende:

• Præ-krypterede data: Dårligt deduplikeringsforhold, men acceptabelt komprimeringsforhold
• Forudkomprimerede data: Dårligt deduplikeringsforhold og dårligt komprimeringsforhold

Når de samme (det er uændret) forhåndskomprimerede/prækrypterede data anvendes af et DDR flere gange, forbedres deduplikeringsforholdet for dataene, da der på trods af brugen af komprimerings- eller krypteringsalgoritmer ses et lignende sæt segmenter (og segment-fingeraftryk) under hver sikkerhedskopi.

Hvor det er muligt, bør data, der sendes til en DDR, ikke krypteres eller komprimeres - Dette kan være nødvendigt at deaktivere kryptering eller komprimering på slutklienten eller i det tilsvarende sikkerhedskopieringsprogram.

Hvis du vil have hjælp til at kontrollere, ændre krypterings- eller komprimeringsindstillinger i et bestemt sikkerhedskopierings-, klientprogram eller operativsystem, skal du kontakte den relevante supportudbyder.

Mediefiler:

Visse filtyper indeholder prækomprimerede eller præ-krypterede data efter design. F.eks.:

• PDF-filer
• Visse lydfiler (mp3, wma ogg osv.)
• Videofiler (avi, mkv osv.)
• Billedfiler (png, bmp, jpeg osv.)
• Programspecifikke filer (Microsoft Office, Open Office, Libre Office osv.)

Dataene i filerne komprimeres eller krypteres af filens codec og forårsager derfor de samme problemer, når de lagres på et DDR som beskrevet ovenfor for prækomprimerede eller prækrypterede data.

Filer med høj "unikhed":

At opnå et godt deduplikeringsforhold afhænger af, at DDR ser det samme sæt segmenter (og segment-fingeraftryk) flere gange. Visse datatyper indeholder imidlertid kun entydige transaktionsdata, der med design indeholder "entydige" data.

Hvis disse filer sendes til en DDR, så indeholder hver generation af sikkerhedskopien et unikt sæt segmenter eller segment-fingeraftryk og ser derfor et forringet deduplikeringsforhold.

Eksempler på sådanne filer er:

• Logfiler for databasetransaktion (f.eks. Oracle-arkivlogfiler).
• Microsoft Exchange-transaktionslogfiler

Den første sikkerhedskopiering af en "ny" klient til en DDR kan også forårsage dette problem (da dataene ikke er blevet set før af DDR, er de tilsvarende segmenter eller segment-fingeraftryk i sikkerhedskopien unikke). Med tiden bliver deduplikeringsforholdet for sikkerhedskopier forbedret, efterhånden som fremtidige generationer af samme sikkerhedskopiering sendes til DDR, da færre segmenter i hver ny sikkerhedskopiering er unikke. På grund af dette forventes det, at det samlede deduplikerings- eller komprimeringsforhold på en nyligt installeret DDR, der modtager mest nye sikkerhedskopier, er forringet, men forbedres over tid.

Små filer:

Små filer forårsager forskellige problemer, når de skrives til et DDR. Disse omfatter:

• Metadata for data – DDR begynder at indeholde en højere mængde filmetadata end forventet sammenlignet med fysiske data.
• Dårlig udnyttelse af beholdere – efter design (på grund af Data Domain Stream Informed Segment-layoutet eller BENCHMARKINGL-arkitekturen – ud over omfanget af dette dokument) indeholder en 4,5 Mb-beholder på disken kun data fra en enkelt fil. Som følge heraf sikkerhedskopieres en enkelt 10 Kb-fil, hvilket f.eks. medfører, at der skrives mindst én fuld 4,5 Mb-beholder til den pågældende fil. Det kan betyde, at DDR for sådanne filer bruger betydeligt mere postkomprimeret (fysisk) plads end den tilsvarende mængde forudkomprimerede (logiske) data, der sikkerhedskopieres, hvilket igen resulterer i et negativt samlet komprimeringsforhold.
• Dårligt deduplikeringsforhold - Filer, der er mindre end 4 Kb (den mindste understøttede segmentstørrelse på en DDR), består af et enkelt segment, der er polstret til 4 Kb. Sådanne segmenter er ikke deduplikeret, men skrives i stedet direkte til disken. Dette kan medføre, at DDR opbevarer flere kopier af det samme segment (set som dublerede segmenter).
• Dårlig sikkerhedskopiering, gendannelse eller ren ydeevne - Der er store omkostninger ved sikkerhedskopiering, gendannelse eller rydning, når du flytter fra én fil til den næste (da konteksten for anvendte metadata skal ændres).

Se her:

• Påvirkningen af ren ydeevne ved brug af små filer er blevet begrænset til en vis grad ved introduktionen af fysisk rengøring eller garbage collection i DDOS 5.5 og nyere.
• Rengøring forsøger at "fortryde" dårlig udnyttelse af beholderen ved at samle data fra beholdere med lav udnyttelse i mere tæt pakkede containere i kopieringsfasen.
• Rengøring forsøger at fjerne overflødige duplikerede segmenter i dens kopifase.

På trods af ovenstående bør man undgå at bruge et stort antal små filer eller workloads bestående af små filer. Det er bedre at kombinere et stort antal små filer i et enkelt ukomprimeret/ukrypteret arkiv før sikkerhedskopiering, end at sende de små filer til DDR i deres oprindelige tilstand. Det er f.eks. langt bedre at sikkerhedskopiere en enkelt 10 GB fil, der indeholder 1048576 individuelle 10 Kb-filer, end alle 1048576 filer individuelt.

Overdreven multipleksing af sikkerhedskopieringsprogrammer:

Sikkerhedskopieringsprogrammer kan konfigureres til at udføre multiplexing af data på tværs af streams, der sendes til sikkerhedskopieringsenheden, dvs. data fra inputstrømme (som er forskellige klienter), sendes i en enkelt stream til sikkerhedskopieringsenheden. Denne funktion er primært beregnet til brug ved skrivning til fysiske båndenheder som:

• En fysisk båndenhed kan kun understøtte en enkelt indgående skrivestream.
• Sikkerhedskopieringsprogrammet skal opretholde tilstrækkelig overførselshastighed til båndenheden for at forhindre, at båndet starter, stopper eller spol tilbage (også kendt som genstart) - Dette er nemmere, hvis streamen, der går til båndenheden, indeholder data, der læses fra mere end én klient.

I tilfælde af et DDR medfører dette imidlertid, at en enkelt fil på DDR indeholder data fra flere klienter, der er indflettet i vilkårlig rækkefølge eller chunk-størrelser. Dette kan medføre et forringet deduplikeringsforhold, da DDR muligvis ikke vil være i stand til nøjagtigt at bemærke dublerede segmenter fra hver generation af en given klientsikkerhedskopiering. Generelt, jo mindre multipleksing-finmaskethed, jo værre er indvirkningen på deduplikeringsforholdet.

Derudover kan gendannelsen af ydeevnen være dårlig, da ddr skal læse mange filer eller containere for at gendanne visse klientdata, hvor de fleste data i filer eller beholdere er ulæselige, da det relaterer til andre klienters sikkerhedskopieringer.

Sikkerhedskopieringsprogrammer må ikke bruge multiplexing, når de skriver til en DDR, da DDR'er understøtter et højere indgående stream-antal end fysiske båndenheder, hvor hver stream er i stand til at skrive med variabel hastighed. Derfor bør multipleksing fra sikkerhedskopieringsprogrammer deaktiveres. Hvis sikkerhedskopieringsydeevnen påvirkes efter deaktivering af multipleksing, skal du:

• Sikkerhedskopiering af programmer ved hjælp af CIFS, NFS eller OST (DDBoost) bør have øget antallet af skrivestrømme (så flere filer kan skrives parallelt på DDR).
• Miljøer, der bruger VTL, bør tilføje yderligere drev til DDR, da hvert drev giver mulighed for understøttelse af en ekstra parallel skrivestrøm.

Hvis det er nødvendigt at få hjælp til at deaktivere multipleksing, eller hvis du vil diskutere anbefalet multipleksing-konfiguration af et bestemt sikkerhedskopieringsprogram, skal du kontakte din kontraktlige supportudbyder.

Sikkerhedskopiering af programmer, der indsætter for mange båndmarkører:

Nogle sikkerhedskopieringsprogrammer kan indsætte gentagne datastrukturer i en sikkerhedskopieringsstrøm, der kaldes "markører". Markeringer repræsenterer ikke fysiske data i sikkerhedskopien, men bruges i stedet som et indekserings- eller positionssystem af sikkerhedskopieringsprogrammet.

I nogle tilfælde kan inkluderingen af markører i en sikkerhedskopistrøm forringe deduplikeringsforholdet, f.eks.:

• I den første generation af en sikkerhedskopi var der 12 Kb data, der var sammenhængende - Dette blev genkendt af DDR som et enkelt segment.
• I anden generation af sikkerhedskopien opdeles de samme 12 Kb data ved at inkludere en sikkerhedskopieringsmarkør, som kan være repræsenteret af 6 Kb data, sikkerhedskopieringsmarkering, 6 Kb data.
• Derfor stemmer de segmenter, der oprettes i løbet af den anden generation af sikkerhedskopien, ikke overens med dem, der genereres under den første generation af sikkerhedskopien, og de deduplikeres derfor ikke korrekt.

Jo mere der er mellemrum mellem markørerne, jo værre er påvirkningen af deduplikeringsforholdet (f.eks. vil et sikkerhedskopieringsprogram, der indsætter markører for hver 32 Kb, give flere problemer end et sikkerhedskopieringsprogram, der indsætter markører hver 1. mb).

For at undgå dette problem anvender DDR markørgenkendelsesteknologi, som tillader:

• Sikkerhedskopieringsmarkører skal fjernes gennemsigtigt fra sikkerhedskopieringsstrømmen under hentning af sikkerhedskopien.
• Sikkerhedskopieringsmarkører, der skal sættes i sikkerhedskopieringsstrømmen igen under gendannelse af sikkerhedskopien

Dette hjælper med at forhindre fragmentering af data eller segmenter ved hjælp af sikkerhedskopieringsmarkører og forbedrer deduplikeringsforholdet for tilsvarende sikkerhedskopier.

For at udnytte denne teknologi fuldt ud, er det vigtigt, at DDR kan genkende de markører, der indsættes i sikkerhedskopieringsstreams, korrekt. DDR søger efter mærker afhængigt af indstillingen for "markørtype", f.eks.:

SE@DDVE60_JF## filesys viser
Indstillingsværdi
-------------------------------- --------
...
Marker-type auto
...


-------------------------------- -------- dette bør normalt efterlades indstillet til "auto", da dette gør det muligt for DDR automatisk at matche de mest almindelige markørtyper. Hvis systemet kun fjerner data fra ét sikkerhedskopieringsprogram, som indsætter markøre, kan der være en fordel ved ydeevnen ved at angive en bestemt markørtype, dvs. :

# fileys-indstillingen set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1 | none}

Se følgende:

• Der er sandsynligvis en minimal fordel ved ydeevnen ved at vælge en bestemt markørtype.
• Hvis du vælger en forkert markørtype, kan det medføre en betydelig yderligere forringelse for sikkerhedskopiering eller gendannelse af ydeevne og deduplikeringsforhold.

Som følge heraf anbefaler Data Domain generelt at lade markørtypen være indstillet til "auto". Du kan få yderligere rådgivning om ændring af markørtype ved at kontakte din kontrakt-supportudbyder.

For systemer, der optage data fra programmer, der bruger sikkerhedskopieringsmarkører, men som ikke genkendes af automatiseret markørhåndteringsteknologi (f.eks. produkter fra BridgeHead-software), skal du kontakte din kontraktunderstøttede supportudbyder, som kan arbejde med Data Domain-support for at finde de nødvendige indstillinger på DDR for at finde den ikke-standardmarkør.

Tegn på data af "dårlig kvalitet", der modtages af et DDR:

Følgende tabel viser forventede deduplikerings- og komprimeringsforhold for de forskellige datatyper, der er anført ovenfor. Denne liste er ikke udtømmende, og der kan naturligvis være nogle forskelle i de nøjagtige tal, der er set på et givent system på grund af workloads eller data, der er inkluderet af DDR:
 

Global komprimering	Lokal komprimering	Sandsynlig årsag
Lav (1x -4x)	Lav (1x - 1,5x)	Forhåndskomprimerede eller krypterede data
Lav (1x - 2x)	Høj (>2x)	Entydige, men komprimerelige data, som f.eks. databasearkivlogfiler
Lav (2x - 5x)	Høj (>1,5x)	Markers, der ikke registreres, eller som ikke har en høj dataændringshastighed eller streamer multipleksing.
Høj (>10x)	Lav (<1,5x)	Sikkerhedskopier af de samme komprimerede eller krypterede data. Dette er ikke ualmindeligt.

Er der visse faktorer på en DDR, som kan påvirke det samlede deduplikeringsforhold?

Ja - Der er flere faktorer, der kan medføre, at gamle/superflouse data bevares på en disk på en DDR, hvilket medfører en stigning i postkomprimeret (fysisk) diskplads og et fald i det samlede komprimeringsforhold. Sådanne faktorer beskrives nedenfor.

Fejl ved regelmæssig kørsel af filsystemrensning:

Oprydning af filsystemet er den eneste måde, hvorpå man fysisk kan fjerne gamle/overflødige data på disken, som ikke længere henvises til af filer på DDR. Som følge heraf kan en bruger slette flere filer fra systemet (hvilket medfører et fald i forkomprimeret udnyttelse), men ikke kør ren (hvilket efterlader postkomprimeret/fysisk udnyttelse høj). Dette vil medføre et fald i det samlede komprimeringsforhold.

Data Domain anbefaler, at der planlægges en ren kørsel med regelmæssige intervaller som følger:

• Normal DDR: Én gang om ugen
• DDR ved brug af udvidet opbevaring: Én gang hver anden uge

Clean bør ikke køres mere end én gang om ugen, da dette kan forårsage problemer med fragmentering af data på disken, der manifesterer sig som dårlig gendannelses-/replikeringsydeevne.

For mange gamle snapshots på systemet:

DDR'er kan oprette mTree-snapshots, som repræsenterer indholdet af en mTree på det tidspunkt, hvor snapshottet blev oprettet. Bemærk dog, at hvis du efterlader gamle snapshots på et system, kan det medføre en stigning i postkomprimeret/fysisk udnyttelse og medføre et fald i det samlede komprimeringsforhold. F.eks.:

• Der findes et mTree, der indeholder mange filer (så forudkomprimeret udnyttelse er høj).
• Der oprettes et snapshot af mTree.
• Mange af filerne slettes (hvilket medfører, at forkomprimeret udnyttelse falder).
• Filsystemoprydning køres - bemærk dog, at der frigøres minimal plads på harddisken, da en kopi af de slettede filer forbliver i mtree-snapshottet, hvilket betyder, at data, der henvises til af disse filer, ikke kan fjernes fra disken.
• Som følge heraf forbliver postkomprimeret/fysisk udnyttelse høj

Data Domain anbefaler, at hvis der bruges mtree-snapshots (f.eks. ved utilsigtet sletning af data), administreres de vha. automatiske snapshot-tidsplaner, så der oprettes snapshots med regelmæssige intervaller med en defineret udløbsdato (den tid, før snapshottet fjernes automatisk). Derudover bør udløbsdatoen være så kort som muligt (men dette kan naturligvis afhænge af brugen af de snapshots eller det beskyttelsesniveau, som disse snapshots giver). Dette forhindrer ophobning af gamle snapshots med en lang udløbsperiode.

Yderligere oplysninger om at arbejde med snapshots og snapshot-tidsplaner er tilgængelige i følgende artikel: Data Domain - Administration af snapshot-planer

For lang replikeringsforsinkelse:

Standard Data Domain-replikering bruger enten en replikeringslog eller mtree-snapshots (afhængigt af replikeringstype) til at spore, hvilke filer eller data der afventer replikering til en fjern-DDR. Replikeringsforsinkelse er konceptet med, at replikaen falder bag ændringer af kilde-DDR'en. Dette kan ske på grund af forskellige faktorer, herunder:

• Replikeringskontekster deaktiveres
• Der er ikke tilstrækkelig netværksbåndbredde mellem DDR'er
• Hyppige netværksafbrydelser.

Store replikeringsforsinkelser kan medføre, at replikeringsloggen fortsætter med at indeholde referencer til filer, der er blevet slettet på kilde-DDR'en eller gamle eller forældede mtree-snapshots på kilde- og destinations-DDI'er. Som beskrevet ovenfor kan data, der henvises til af disse snapshots (eller replikeringsloggen), ikke fysisk fjernes fra disken på DDR, selvom tilsvarende filer er blevet slettet fra systemet. Dette kan forårsage postkomprimeret eller fysisk udnyttelse af DDR'en til at stige, hvilket derefter medfører en forringelse af deduplikeringsforholdet.

Hvis DDR'er oplever en høj udnyttelse, og det menes at skyldes replikeringsforsinkelse, skal du kontakte din kontraktførte supportudbyder for at få yderligere hjælp.

Er der konfigurationsændringer eller visse faktorer på en DDR, som kan øge det samlede komprimeringsforhold?

Ja – fjernelse eller adressering af de problemer, der er beskrevet tidligere i dette dokument, bør gøre det muligt for et DDR at vise et forbedring af det samlede komprimeringsforhold over tid. Der er også forskellige faktorer eller arbejdsbelastninger på en DDR, som kan føre til en stigning i deduplikeringsforholdet. Disse involverer generelt:

• Reducer mængden af plads på harddisken, der bruges af filer på DDR 'en (for eksempel at øge aggressiviteten for den komprimeringsalgoritme, der anvendes af DDR)
• Pludselig stigende mængden af forudkomprimerede (logiske) data på DDR'en uden en tilsvarende stigning i postkomprimeret/fysisk udnyttelse

Ændring af komprimeringsalgoritme:

DDR'er komprimerer som standard data, der skrives til disken med lz-algoritmen . Som tidligere nævnt bruges lz , da den har relativt lave overheads i forhold til CPU, der kræves til komprimering eller dekomprimering, men viser rimelig effektivitet til at reducere datastørrelsen.

Det er muligt at øge aggressiviteten af komprimeringsalgoritmen for at give yderligere besparelser i postkomprimeret eller harddiskudnyttelse (og som et resultat forbedre det samlede komprimeringsforhold). Understøttede komprimeringsalgoritmer, i rækkefølge efter effektivitet (fra lav til høj), er som følger:

• Lz
• gzfast
• Gz

En generel sammenligning af hver algoritme er som følger:

• lz sammenlignet med gzfast giver ~15 % bedre komprimering og forbruger 2x CPU.
• lz sammenlignet med gz giver ~30 % bedre komprimering og forbruger 5x CPU.
• gzfast sammenlignet med gz giver ~10-15 % bedre komprimering.

Det er også muligt helt at deaktivere komprimering (angiv en algoritme på ingen), men dette understøttes ikke til brug på kundens systemer og er kun til intern testning.

I henhold til ovenstående tabel, jo mere aggressiv komprimeringsalgoritmen er, jo mere CPU kræves der under komprimering eller dekomprimering af data. På grund af dette bør ændringer af en mere aggressiv algoritme kun foretages på systemer, der let indlæses under normal arbejdsbelastning. Ændring af algoritmen på meget belastede systemer kan føre til ekstrem forringelse i sikkerhedskopierings- eller gendannelsesydeevnen og mulige filsystem går i panik eller genstarter (hvilket medfører et nedbrud af DDR).

Du kan få yderligere oplysninger om ændring af komprimeringstypen i følgende artikel: Påvirkning af datadomænesystem og rengøring af ydeevne ved konvertering til GZ-komprimering

På grund af den potentielle indvirkning af en ændring af komprimeringsalgoritmen anbefales det, at kunder, der er interesseret i at gøre dette, kontakter deres kontraktlige supportudbyder for at drøfte ændringen yderligere, før du fortsætter.

Brug af filsystemets hurtigkopi:

DDR'er giver mulighed for at bruge kommandoen "file system fastcopy" til hurtigt at kopiere en fil (eller mappetræ). Denne funktion opretter en fil ved at klone metadataene for en eksisterende fil (eller gruppe af filer), så selvom de nye filer ikke fysisk er forbundet til den oprindelige fil, henviser de til nøjagtigt de samme data på disken som den oprindelige fil. Det betyder, at uanset størrelsen på den oprindelige fil bruger den nye fil kun lidt plads på disken (da den deduplikerer perfekt i forhold til eksisterende data).

Resultatet af denne adfærd er, at når filsystemets hurtigkopi bruges, bliver den forudkomprimerede (logiske) størrelse af data på DDR hurtigt forøget, men den postkomprimerede/fysiske udnyttelse af DDR forbliver statisk.

For eksempel har følgende DDR udnyttelse som følger (indikerer det samlede komprimeringsforhold på ~1,8x):

Aktivt niveau:
Ressourcestørrelse GiB anvendt GiB Tilg. Brug% rengørbar GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 12,0 - -
/data: post-comp 71,5 6,8 64,7 10 % 0,0
/ddvar 49,2 1,1 45,6 2 % -
/ddvar/core 158,5 0,2 150,2 0 % -
---------------- -------- -------- --------- ---- --------------

Den indeholder en stor fil (/data/processor1/sikkerhedskopiering/testfil):

!!! DDVE60_JF DINE DATA ER I FARLIGE !!! # ls -al /data/1/backup/testfile-rw-r-r
-- 1 root 3221225472 29. juli 04:20 /data/backup1/testfile

Filen fastgøres flere gange:

sysadmin@DDVE60_JF# filesys fastcopy source /data/backup/testfile destination /data/hard1/backup/backup/backup/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data/dine1/backup/testfile destination /data/backup1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/data/dine1/backup/testfile destination /data/backup1/backup/testfile_copy3

Dette får forudkomprimeret udnyttelse til at stige for lille ændring i postkomprimeret udnyttelse:

Aktivt niveau:
Ressourcestørrelse GiB Anvendt GiB Anvendelse % cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 21,0 - -
/data: post-comp 71,5 6,8 64,7 10 % 0,0
/ddvar 49,2 1,1 45,6 2 % -
/ddvar/core 158,5 0,2 150,2 0 % -
---------------- -------- -------- --------- ---- --------------

Som følge heraf viser DDR nu det samlede komprimeringsforhold på ~3,1x.

Som nævnt ovenfor viser komprimeringsstatistikken for kopierne, at de deduplikeres perfekt:

sysadmin@DDVE60_JF# filesys viser komprimering /data/data/program1/sikkerhedskopiering/testfile_copy1
Filer i alt: 1;  byte/storage_used: 21331976.1
Oprindelige bytes:        3.242.460.364
Globalt komprimeret:                    0
Lokalt komprimeret:                    0
Metadata:                  152(152)

Fastcopy-funktionaliteten kan ikke bruges til at forbedre det samlede komprimeringsforhold ved at reducere den fysiske udnyttelse af DDR, men det kan være årsagen til et højt overordnet komprimeringsforhold (især i miljøer, der gør omfattende brug af hurtigkopi som F.eks. Avamar 6.x).