Data Domain – ofte stillede spørgsmål om komprimering

GÆLDER FOR

• Alle DDR'er
• Alle udgivelser

Komprimering: Ofte stillede spørgsmål:

Ideelt set ville dette være sandt. I praksis bruger den fulde sikkerhedskopi lidt mere plads end den inkrementelle på grund af følgende årsager. Disse grunde forklarer også, hvorfor en fuld sikkerhedskopi uden ændringer i data stadig vil forbruge en positiv mængde plads.

• Metadataene tager ca. 0.5% af sikkerhedskopiens logiske størrelse. Antag, at den logiske størrelse af den fulde er 100 GB, og den for den inkrementelle er 2 GB. Antag, at den trinvise komprimering komprimeres til 1 GB. Derefter tager den fulde mindst 1.5 GB.
• DD-komprimeringsprogrammet omskriver nogle identiske datasegmenter af hensyn til ydeevnen. Jo dårligere datalokaliteten af ændringerne er, desto mere skrives dubletterne. Duplikaterne genvindes senere af "filesys cleaning". Jeg har set omkring 2% af den logiske størrelse omskrevet som duplikat. Hvis vi antager dette niveau af dubletter, kan det fulde tage 1 GB (komprimeret) + 0.5 GB (metadata) + 2 GB (dubletter) = 3.5 GB. Mængden af skrevne dubletter kan styres via en systemparameter, men vi justerer generelt ikke denne parameter i feltet.
• Datasegmenteringen kan variere lidt fra sikkerhedskopiering til sikkerhedskopiering afhængigt af den rækkefølge, NFS-klienten sender dataene i. Denne rækkefølge er ikke deterministisk. Generelt tolererer segmenteringsalgoritmen skift og ombestilling. Det skaber dog også nogle "tvungne" segmenter, som er tilbøjelige til skift og ombestilling. Typisk er ca. 0,2% af segmenterne tvunget, så man kan forvente, at der bruges meget mere plads.

"filesys show space" angiver komprimeringsforholdet baseret på den logiske størrelse af de lagrede data og den diskplads, der bruges på det tidspunkt, hvor kommandoen køres.

"filesys show compression" angiver komprimeringsforholdet baseret på, hvordan hver fil blev komprimeret på det tidspunkt, den blev oprettet.

"filesys show compression" bruges mest til support og fejlfinding. I nærvær af filsletninger overvurderer "filesys show compression" komprimeringsforholdet.

For eksempel er antagelsen, at den første fulde sikkerhedskopi får 2x komprimering. En efterfølgende fuld sikkerhedskopiering uden dataændringer får 200x komprimering. Den første fulde sikkerhedskopi slettes. "filesys show space" viser et komprimeringsforhold på 2x. "filesys show compression" vil nu vise et komprimeringsforhold på 200x, fordi den eneste fil, der findes nu, fik en komprimering på 200x, da den blev oprettet.

I eksemplet nævnt ovenfor, efter den anden sikkerhedskopi, vil "filesys show space" vise det kumulative forhold på ca. 4x. Det kumulative forhold forbedres asymptotisk mod 200x, hvis man fortsætter med at lave flere sikkerhedskopier uden sletning.

Der er nogle andre mindre forskelle:

•  "filesys show compression" tager ikke højde for spild på containerniveau, hvilket overvurderer komprimeringsforholdet yderligere
•  "filesys show compression" tager ikke højde for dobbelteliminering ved global komprimering, hvilket undervurderer komprimeringsforholdet
•  "filesys show compression" kan give oplysninger pr. fil eller pr. mappe, mens "filesys show space" er begrænset til hele systemet
•  "filesys show compression" angiver fordelingen mellem global og lokal komprimering, mens "filesys show space" ikke gør det

REFERENCER

• Hvorfor er komprimeringsforholdene forskellige for "filesys show space" og "vtl tape show summary"?

Komprimeringsforholdet, der vises i "oversigt over vtl-båndshow", er beregnet til at matche "filesys show compression /backup/vtc".

Mere generelt kan denne VTL-kommando gives et valgfrit filter til at vælge et undersæt af båndkassetter, og komprimeringen formodes at matche "filesys show compression" på den delmængde af patroner.

Men på grund af en fejl i VTL UI-koden er komprimeringen vist i "vtl tape show summary" fejlagtig. Dette er et kendt problem, som løses ved version 4.5.0.0.
 

• Hvorfor svarer "filesys show compression last 24 hours" ikke til forventningen til VTL?

For VTL opfylder outputtet af kommandoer som "filesys show compression last 24 hours" ofte ikke forventningerne baseret på andre kilder såsom "system show performance".

Problemet opstår på grund af en ejendommelighed i "filesys show compression" (fsc). Generelt viser "filesys show compression" kumulativ statistik i valgte filer. Kvalifikatoren "sidste 24 timer" vælger de filer, der er blevet opdateret inden for de seneste 24 timer. Statistikken er stadig kumulativ, da filen blev oprettet eller sidst afkortet til nulstørrelse. Således, hvis en fil blev tilføjet inden for de sidste 24 timer, vil "filesys show compression last 24 hours" vise sin kumulative statistik før de sidste 24 timer.

I ikke-VTL-miljøer skrives backupfiler kun én gang, så der er ikke meget uoverensstemmelse mellem opdaterede filer og oprettede filer. Med VTL kan der tilføjes sikkerhedskopier til eksisterende båndfiler. Overvej for eksempel et bånd med kapacitet på 100 GB, der er fyldt op til 50 GB. Hvis der er tilføjet 10 GB data til dette bånd inden for de sidste 24 timer, vil "filesys show compression last 24 hours" vise filens "Original bytes" skrevet ved 60 GB.
 

• Hvordan beregnes det kumulative kompressionsforhold?

Individuelle kompressionsforhold tilføjer ikke lineært.

Antag, at komprimeringen på den første fulde sikkerhedskopi er 2x, og at den på den anden fulde backup er 20x. Den kumulative komprimering er ikke (2+20)/2 eller 11x, men 2/(1/2+1/20) eller 3,64x.

Generelt har lavere kompressionsforhold større indflydelse end højere på det kumulative kompressionsforhold.

Antag, at den ith backup har logisk størrelse si og kompressionsforhold ci. Derefter kan det kumulative komprimeringsforhold for k-sikkerhedskopier beregnes som følger:

C = (samlet logisk størrelse)/(samlet anvendt plads)
samlet logisk størrelse = s1 + s2 + .. + sk
samlet brugt plads = s1 / c1 + s2 / c2 + ... + sk/ck

Ofte er de logiske størrelser nogenlunde de samme. I så fald forenkler ovenstående beregning følgende:

Hvis den første fulde sikkerhedskopiering f.eks. får 3x komprimering, og hver efterfølgende fuld får 30x komprimering, og opbevaringsperioden er 30 dage, ser brugeren en kumulativ komprimering på 30/(1/3+29/30) eller 23x.
 

• Hvordan fungerer Data Domain Compression?

Dette spørgsmål besvares detaljeret i en separat KB-artikel, "Understanding Data Domain Compression" Data Domain: Om Data Domain-komprimering
 

• Understøtter Data Domain multiplexing? ​​​​​​​

Multiplekserede data fra sikkerhedskopieringsprogrammet resulterer i meget dårlig global deduplikering. Du kan finde flere oplysninger i den relaterede artikel Multiplexing i sikkerhedskopieringssoftware understøttes ikke Data Domain: Multiplexing i sikkerhedskopieringssoftware. 
 

• Hvorfor viser replikaen bedre global komprimering med 1-til-1-biblioteksreplikering?​​​​​​​

Dette skyldes normalt variationer i niveauet af duplikatsegmenter, der er skrevet på systemet:

• De data, der er gemt ved kilden, er blevet deduplikeret én gang - mod de tidligere data, der er gemt ved kilden.
• De data, der sendes via ledningen, er blevet deduplikeret én gang – i forhold til de data, der er gemt på replikaen.
• De data, der er gemt på replikaen, er blevet deduplikeret to gange, én gang, når dataene blev sendt over ledningen, og igen, når de modtagne data skrives på replikaen.

Da deduplikeringsprocessen efterlader nogle dubletter, har data, der er blevet deduplikeret flere gange, færre dubletter. De data, der er gemt ved kilden og sendt over ledningen, deduplikeres én gang, så de er stort set de samme, forudsat at de data, der er gemt ved kilden og replikaen, er ens. De data, der er gemt på replikaen, deduplikeres to gange, så de komprimeres bedre.

Filsystemrensning fjerner de fleste dubletter. Når rensningen er kørt på kilden og replikaen, bør mængden af data, der er gemt der, derfor være omtrent den samme.

• Hvad er ændringen i komprimering, når du bruger lz, gzfast og gz lokale komprimeringsindstillinger?

filesys option set komprimering {none | lz | gzfast | gz}
 

Advarsel: Før du ændrer den lokale komprimeringstype, skal filsystemet lukkes ned. Den kan derefter genstartes umiddelbart efter, at komprimeringsindstillingen er blevet indstillet.

Generelt er kompressionsrækkefølgen som følger:

Den grove forskel er:

• lz til gzfast giver ~ 15% bedre komprimering og bruger 2x CPU
• LZ til GZ giver ~ 30% bedre komprimering og bruger 5x CPU
• GzFast til GZ giver ~ 10-15% bedre kompression

Bemærk, at ændring af den lokale komprimering først påvirker nye data, der skrives til DataDomain Restorer, efter ændringen blev foretaget. De gamle data bevarer deres tidligere komprimeringsformat indtil næste rensningscyklus. Den næste oprydningscyklus kopierer alle de gamle data videre til det nye komprimeringsformat. Dette får rengøringen til at køre meget længere og tage mere CPU.

Hvis kundesystemet allerede er ved at løbe tør for CPU, især hvis kunden foretager sikkerhedskopiering og replikering samtidig, kan dette gøre sikkerhedskopieringen og/eller replikeringen langsommere. Kunden ønsker måske eksplicit at planlægge noget tid til at udføre denne konvertering.

Videnreferencer:

• Løsning af migreringsproblemer
• Data Domain: Om Data Domain-komprimering