Feilsøke dårlig deduplisering og komprimeringsforhold for filer på Data Domain Restorers (DDR-er)

Data Domain Restorers (DDRs) er utformet for å inneholde store mengder logiske (forhåndskomprimerte) data ved hjelp av minimal fysisk (postkomprimert) diskplass. Dette oppnås ved hjelp av:

• Deduplisering av inntatte data for å fjerne dupliserte deler av data som allerede er lagret på disken på DDR, gir bare unike data
• Komprimering av unike data før disse dataene skrives fysisk til disken.

Det totale komprimeringsforholdet for data som en DDR kan innta varierer avhengig av flere faktorer, for eksempel:

• Brukstilfelle
• Datatyper som blir inntatt
• Konfigurasjon av sikkerhetskopieringsapplikasjon

Når det er optimalt konfigurert, oppnår DDR-er vanligvis 10–20 x totalt komprimeringsforhold (og kan noen ganger vise forhold som er høyere enn dette). Derimot kan imidlertid det totale komprimeringsforholdet i enkelte miljøer være lavere enn dette, noe som kan føre til følgende:

• DDR for raskt å bruke dens brukbare kapasitet
• Innvirkning på ytelsen til sikkerhetskopiering, gjenoppretting eller replikering
• DDR mislykkes i å oppfylle kundens forventninger

Denne artikkelen er ment å drøfte:

• En kort oversikt over deduplisering og komprimering av data på en DDR
• Slik finner du det totale komprimeringsforholdet for systemet og individuelle filer
• Faktorer som kan føre til degradering til det totale komprimeringsforholdet

Hvordan inntar en Data Domain Restorer nye data?

• Sikkerhetskopieringsapplikasjonen sender data (det vil si filer) til DDR.
• DDR deler disse filene i deler på 4–12 kb i størrelse – hver del vises som et segment.
• DDR genererer et unikt fingeravtrykk (lik et kontrollsum) for hvert segment, avhengig av dataene i segmentet.
• Fingeravtrykkene til nylig ankomne segmenter kontrolleres mot diskindekser på DDR for å finne ut om DDR allerede har et segment med samme fingeravtrykk.
• Hvis DDR allerede har et segment med samme fingeravtrykk, er det tilsvarende segmentet i de nylig komede dataene et duplikat og kan droppes (som deduplicated).
• Når alle dupliserte segmenter er fjernet fra de nylig ankomne dataene, er det bare unike eller nye segmenter igjen.
• Disse unike eller nye segmentene grupperes i komprimeringsområder på 128 kb og deretter komprimert (ved hjelp av lz-algoritmen som standard).
• Komprimerte komprimeringsområder er pakket inn i 4,5 Mb lagringsenheter som kalles beholdere, som deretter skrives til harddisken.

Hvordan sporer DDR hvilke segmenter som utgjør en bestemt fil?

I tillegg til deduplisering/komprimering av nylig ankomne data bygger DDR også et segmenttre for hver inntatte fil. Dette er i hovedsak en liste over segment "fingeravtrykk" som utgjør denne filen. Hvis DDR senere må lese filen tilbake, gjør du følgende:

• Finn plasseringen av filsegmenttreet.
• Les segmenttreet for å få en liste over alle segmentfingeravtrykk som utgjør filområdet som leses.
• Brukes på diskindekser for å fastslå den fysiske plasseringen (som er beholderen) for dataene på disken.
• Les de fysiske segmentdataene fra de underliggende beholderne på disken.
• Bruk fysisk segmentdata til å rekonstruere filen.

Filsegmenttrær lagres også i 4,5 Mb beholdere på disken og representerer de fleste filene "metadata" (drøftet senere i denne artikkelen).

Hvordan kan det totale komprimeringsforholdet på en DDR bestemmes?

Den generelle bruken av en DDR (og komprimeringsforhold) kan ses ved hjelp av kommandoen «filesys show space». For eksempel:

Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - -
/data: post-comp 67 94,2 6242,4 551,8 92 % 202,5
/ddvar 49,2 9,1 37,6 20 % -


---------------- -------- -------- --------- ---- -------------- I dette tilfellet ser vi følgende:

• Forhåndskomprimerte eller logiske data som holdes på DDR: 115 367,8 Gb
• Postkomprimert eller fysisk plass som brukes på DDR: 6242,4 GB
• Det totale komprimeringsforholdet er 115367,8 / 6242,4 = 18,48 x

Utdataene fra kommandoen «filesys show compression» bekrefter dataene som holdes nede, plassen som brukes, og komprimeringsforholdet. Eksempel:

                   Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Faktorfaktor
(reduksjon %)
---------------- -------- --------- ----------- ---------- -------------
Strøm brukt:*   115367.8 6242.4 – 18.5x (94.6) <=== MERK
Skrevet:                                                                          
  Siste 7 dager 42214,7 1863,2 11,0 x 2,1 x 22,7x (95,6)
  Siste 24 timer 4924,8 274,0 8,8 x 2,0 x 18,0 x (94,4)
---------------- -------- --------- ----------- ---------- -------------

Overall-utnyttelsesfigurer på DDR beregnes som følger:

• Totalt forhåndskomprimert data: Summen av den forhåndskomprimerte (logiske) størrelsen på alle filer som holdes av DDR.
• Totalt antall postkomprimerte data: Antallet i bruk "beholdere" på disk multiplisert med 4,5 Mb (størrelsen på én enkelt beholder).
• Total postkomprimert størrelse: Antallet maksimale beholdere som opprettes med tilgjengelig diskplass på systemet.

Statistikk rundt maksimum i bruk beholdere er tilgjengelig i automatisk støtte. For eksempel:

Beholdersett 73fc piperdea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <=== Beholderstørrelse i byte
...
    attrs.max_containers = 1546057 <=== Maksimalt antall beholdere
attrs.free_containers = 125562 <=== For øyeblikket kostnadsfrie beholdere
attrs.used_containers = 1420495 <=== Beholdere
som er i bruk for øyeblikket ...

Se dette:
 
Hvordan kan deduplisering og komprimeringsforhold for et enkelt fil-, katalog- eller katalogtre fastslås?

Når en fil er inntatt, registrerer DDR-statistikk om filen, inkludert:

• Forhåndskomprimerte (logiske) byte
• Størrelse på unike segmenter etter deduplisering
• Størrelse på unike segmenter etter deduplisering og komprimering
• Størrelsen på filens metadata (som er segmenttre og så videre)

Det er mulig å dumpe noen av disse statistikkene ved hjelp av kommandoen «filesys show compression [path]» – for eksempel å rapportere statistikk for én enkelt fil:

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1;  bytes/storage_used: 2,9
originale byte:        3 242 460 364
globalt komprimerte:        1 113 584 070
lokalt komprimert:        1,130,871,915
Meta-data:            4 772 672

Slik rapporterer du statistikk for et helt katalogtre:

SE@DDVE60_JF## filesys viser komprimerings-/data/kolonne1/sikkerhetskopieringssumfiler
: 3;  bytes/storage_used: 1.4
Opprinnelige byte:        7 554 284 280
globalt komprimert:        5,425,407,986
Lokalt komprimert:        5 510 685 100
metadata:           23 263 692

Vær imidlertid oppmerksom på at det finnes et par forbehold rundt bruk av denne statistikken:

• Statistikken genereres på tidspunktet for fil- eller datainntak, og etter dette oppdateres ikke. På grunn av hvordan en DDR fungerer, kan inntak av nye filer eller sletting av filer som refererer til de samme dataene, og så videre, endre hvordan en fil deduplicates over tid, slik at denne statistikken blir foreldet.
• I tillegg kan visse brukstilfeller på DDR (for eksempel rask kopiering av en fil og sletting av den opprinnelige filen) føre til at denne statistikken blir forvrengt eller feil.

Som et resultat av dette bør disse figurene bare betraktes som estimater.

De forhåndskomprimerte bytene er ikke nødvendigvis den forhåndskomprimerte/logiske størrelsen på filen. I stedet er det totalt antall byte skrevet til en fil i levetiden. Som et resultat av dette er eksisterende filer i visse miljøer ofte overskrevet (for eksempel de som bruker funksjonalitet for virtuelt båndbibliotek). Denne figuren kan være større enn den logiske størrelsen på de tilsvarende filene.

Kan inntak av data av dårlig kvalitet forårsake forringelse i det totale komprimeringsforholdet?

Ja – for at en DDR skal oppnå et godt samlet komprimeringsforhold på inntatte data, må den kunne deduplicate og komprimere disse dataene. Det finnes ulike typer data som kan forhindre dette som beskrevet nedenfor:

Forhåndskomprimerte/forhåndskrypterte data:

Dette er datatyper som enten er komprimert eller kryptert på klientsystemet eller av sikkerhetskopieringsapplikasjonen. Dette kan også omfatte applikasjonsspesifikke filer som komprimeres eller krypteres etter design (for eksempel mediefiler) og databasefiler som enten er komprimerte eller krypterte eller innebygde binære objekter, for eksempel mediefiler.

På grunn av hvordan komprimerings- eller krypteringsalgoritmen fungerer, vil en relativt liten endring av den underliggende dataene i en fil føre til endringer som «riper ut» på tvers av filen. En klient kan for eksempel inneholde en 100 Mb kryptert fil der 10 KB er endret. Vanligvis vil den resulterende filen være identisk før og etter endring bortsett fra 10 KB-delen som er endret. Når kryptering brukes, selv om bare 10 kb ukrypterte data er endret før og etter endring, fører krypteringsalgoritmen til at hele innholdet i filen endres.

Når slike data endres regelmessig og sendes med jevne mellomrom til en DDR, vil denne ringvirkningen føre til at hver generasjon av filen ser annerledes ut enn tidligere generasjoner av samme fil. Som et resultat inneholder hver generasjon et unikt sett med segmenter (og segmenter fingeravtrykk), slik at det viser dårlig dedupliseringsforhold.

Vær også oppmerksom på at lz-algoritmen i stedet for forhåndskomprimerte filer sannsynligvis ikke vil være i stand til å komprimere segmentdata ytterligere, slik at data ikke kan komprimeres før de skrives til disken.

Som en generell retningslinje fører prekomprimering/forhåndskryptering til følgende:

• Forhåndskrypterte data: Dårlig dedupliseringsforhold, men akseptabelt komprimeringsforhold
• Forhåndskomprimerte data: Dårlig dedupliseringsforhold og dårlig komprimeringsforhold

Når de samme (som er uendret) forhåndskomprimerte/forhåndskrypterte data inntatt av en DDR flere ganger, blir dedupliseringsforholdet til dataene bedre, til tross for bruk av komprimerings- eller krypteringsalgoritmer, vises et lignende sett med segmenter (og segmentfingeravtrykk) under hver sikkerhetskopiering.

Hvis det er mulig at data som sendes til en DDR, ikke skal krypteres eller komprimeres, kan dette kreve deaktivering av kryptering eller komprimering på sluttklienten eller i den tilsvarende sikkerhetskopieringsapplikasjonen.

Hvis du trenger hjelp til å kontrollere, endre krypterings- eller komprimeringsinnstillinger i en bestemt sikkerhetskopi, en klientapplikasjon eller et operativsystem, kan du kontakte den aktuelle støtteleverandøren.

Mediefiler:

Enkelte filtyper inneholder forhåndskomprimerte eller forhåndskrypterte data etter design. Eksempel:

• PDF-filer
• Enkelte lydfiler (mp3, wma, ogg og så videre)
• Videofiler (avi, mkv og så videre)
• Bildefiler (png, bmp, jpeg og så videre)
• Applikasjonsspesifikke filer (Microsoft Office, Open Office, Libre Office og så videre)

Dataene i filene komprimeres eller krypteres av filens kodek, og forårsaker derfor de samme problemene ved inntatt på en DDR som beskrevet ovenfor for forhåndskomprimerte eller forhåndskrypterte data.

Filer med høy unikhet:

Å oppnå et godt dedupliseringsforhold avhenger av at DDR har samme sett med segmenter (og segmenter fingeravtrykk) flere ganger. Enkelte datatyper inneholder imidlertid bare unike transaksjonsdata som etter design inneholder unike data.

Hvis disse filene sendes til en DDR, inneholder hver generasjon av sikkerhetskopieringen et unikt sett med segmenter eller segmentfingeravtrykk, og som et resultat ser dedupliseringsforholdet degradert.

Eksempler på slike filer er:

• Databasetransaksjonslogger (for eksempel Oracle-arkivlogger).
• Transaksjonslogger for Microsoft Exchange

Den første sikkerhetskopien av en "ny" klient til en DDR kan også forårsake dette problemet (ettersom dataene ikke har blitt sett tidligere av DDR, og derfor er de tilsvarende segmentene eller segmentfingeravtrykkene i sikkerhetskopien unike). Etter hvert som fremtidige generasjoner av samme sikkerhetskopiering sendes til DDR, blir dedupliseringsforholdet for sikkerhetskopiering forbedret ettersom færre segmenter i hver nye sikkerhetskopiering er unike. På grunn av dette forventes det at det totale dedupliserings- eller komprimeringsforholdet på en nylig installert DDR som mottar for det meste nye sikkerhetskopier, blir degradert, men forbedret over tid.

Små filer:

Små filer forårsaker ulike problemer når de skrives til en DDR. Disse omfatter:

• Oppsvulmet metadata – DDR begynner å inneholde en høyere enn forventet mengde filmetadata sammenlignet med fysiske data.
• Dårlig beholderutnyttelse – etter design (på grunn av datadomenestrømming informert segmentoppsett eller SISL-arkitektur – utenfor omfanget til dette dokumentet) inneholder en 4,5 Mb beholder på disken bare data fra én enkelt fil. Resultatet er at sikkerhetskopiering av én enkelt 10 KB-fil, for eksempel, fører til at minst én full 4,5 Mb beholder skrives for denne filen. Dette kan bety at DDR for slike filer bruker betydelig mer postkomprimert (fysisk) plass enn den tilsvarende mengden forhåndskomprimerte (logiske) data som sikkerhetskopieres, noe som igjen fører til et negativt samlet komprimeringsforhold.
• Dårlig dedupliseringsforhold – filer som er mindre enn 4 kB (minimum støttet segmentstørrelse på en DDR), består av ett enkelt segment som er polstret til 4 kB. Slike segmenter blir ikke deduplicated, men blir i stedet skrevet direkte til disken. Dette kan føre til at DDR holder flere kopier av samme segment (sett som dupliserte segmenter).
• Dårlig sikkerhetskopiering, gjenoppretting eller ren ytelse – Det er store kostnader under sikkerhetskopiering, gjenoppretting eller rengjøring når du flytter fra én fil til den neste (ettersom konteksten for metadata som brukes, må byttes).

Se dette:

• Innvirkningen på ren ytelse ved bruk av små filer er i en viss grad redusert ved innføring av fysisk rengjøring eller datasanering i DDOS 5.5 og nyere.
• Rengjøring forsøker å "angre" dårlig beholderbruk ved å aggregere data fra beholdere med lav utnyttelse i mer tettpakkede beholdere under kopieringsfasen.
• Rengjøring forsøker å fjerne for mange dupliserte segmenter under kopieringsfasen.

Til tross for det ovennevnte bør du unngå bruken av et stort antall små filer eller workloader som hovedsakelig består av små filer. Det er bedre å kombinere et stort antall små filer i ett enkelt ukomprimert/ukryptert arkiv før sikkerhetskopiering enn å sende de små filene til DDR i opprinnelig tilstand. Det er for eksempel langt bedre å sikkerhetskopiere én enkelt 10 Gb-fil som inneholder 1048576 individuelle 10 KB-filer enn alle 1048576 filer individuelt.

Overdreven multipleksing av sikkerhetskopieringsapplikasjoner:

Sikkerhetskopieringsapplikasjoner kan konfigureres til å utføre multipleksing av data på tvers av strømmer som sendes til sikkerhetskopieringsenheten. Data fra inndatastrømmer (som er forskjellige klienter) sendes i én enkelt strømming til sikkerhetskopieringsenheten. Denne funksjonaliteten er hovedsakelig til bruk når du skriver til fysiske båndenheter som:

• En fysisk båndenhet kan bare støtte én enkelt innkommende skrivestrøm.
• Sikkerhetskopieringsapplikasjonen må opprettholde tilstrekkelig gjennomstrømming til båndenheten for å hindre at bånd starter, stopper eller spoler tilbake (også kjent som pstedrelyd) – Dette er enklere hvis strømmen som går til båndenheten, inneholder data som leses fra mer enn én klient.

Hvis det gjelder en DDR, fører dette imidlertid til at én enkelt fil på DDR inneholder data fra flere klienter som er innfelt i vilkårlig rekkefølge eller i en delstørrelse. Dette kan føre til degradert dedupliseringsforhold fordi DDR kanskje ikke kan legge merke til dupliserte segmenter nøyaktig fra hver generasjon av en gitt sikkerhetskopiering av klienter. Generelt sett, jo mindre multiplumkantet er, jo dårligere har innvirkningen på dedupliseringsforholdet.

I tillegg kan gjenopprettingsytelsen være dårlig fordi for å gjenopprette en bestemt klientdata må DDR lese mange filer eller beholdere der mesteparten av dataene i filene eller beholderne er overordnede når det gjelder sikkerhetskopiering av andre klienter.

Sikkerhetskopieringsapplikasjoner må ikke bruke multipleksing når du skriver til en DDR, ettersom DDR-er støtter høyere antall innkommende strømmer enn fysiske båndenheter der hver strømming kan skrive med variabel hastighet. Som et resultat bør multipler av sikkerhetskopieringsapplikasjoner deaktiveres. Hvis sikkerhetskopieringsytelsen påvirkes etter deaktivering av multipleksing, gjør du følgende:

• Sikkerhetskopieringsapplikasjoner som bruker CIFS, NFS eller OST (DDBoost), bør øke antallet skrivestrømmer (slik at flere filer kan skrives parallelt på DDR).
• Miljøer som bruker VTL, bør legge til flere disker i DDR, ettersom hver stasjon tillater støtte for en ekstra parallell skrivestrøm.

Hvis du trenger hjelp til å deaktivere multipleksing, eller hvis du vil diskutere anbefalt multipleksingskonfigurasjon for en bestemt sikkerhetskopieringsapplikasjon, kontakter du kundestøtteleverandøren du har inngått.

Sikkerhetskopieringsapplikasjoner som setter inn for mange båndmarkeringer:

Noen sikkerhetskopieringsapplikasjoner kan sette inn gjentatte datastrukturer i en sikkerhetskopistrøm som kalles "markører". Markører representerer ikke fysiske data i sikkerhetskopien, men brukes i stedet som et indekserings- eller posisjonssystem av sikkerhetskopieringsapplikasjonen.

I noen tilfeller kan inkludering av markører i en sikkerhetskopieringsstrøm for eksempel redusere dedupliseringsforholdet:

• I den første generasjonen av en sikkerhetskopi var det 12 kB med data som var sammenhengende – dette ble gjenkjent av DDR som ett enkelt segment.
• I den andre generasjonen av sikkerhetskopieringen deles imidlertid de samme 12 kb med data ved å inkludere en sikkerhetskopieringsmarkør som kan representeres av 6 kb data, sikkerhetskopieringsmarkør, 6 kb data.
• Resultatet er at segmentene som opprettes i løpet av den andre generasjonen av sikkerhetskopieringen, ikke samsvarer med de som genereres i løpet av den første generasjonen av sikkerhetskopieringen, og dermed de deduplicates ikke på riktig måte.

Jo nærmere mellomrom markørene er jo dårligere innvirkning på dedupliseringsforholdet (for eksempel en sikkerhetskopieringsapplikasjon som setter inn markører hver 32 kB, fører til flere problemer enn en sikkerhetskopiapplikasjon som setter inn markører hver 1 Mb).

For å unngå dette problemet bruker DDR markergjenkjenningsteknologi som gjør det mulig:

• Sikkerhetskopier markører som skal fjernes fra sikkerhetskopistrømmen under sikkerhetskopiere.
• Sikkerhetskopier markører som skal settes inn i sikkerhetskopistrømmen på nytt under gjenoppretting av sikkerhetskopien

Dette bidrar til å forhindre fragmentering av data eller segmenter etter sikkerhetskopieringsmarkeringer og forbedrer dedupliseringsforholdet for tilsvarende sikkerhetskopieringer.

For å dra full nytte av denne teknologien er det imidlertid viktig at DDR gjenkjenner markørene som settes inn i sikkerhetskopieringsstrømmer på riktig måte. DDR ser etter markører avhengig av innstillingen for alternativet "marker type", for eksempel:

SE@DDVE60_JF## filesys option show
Option Value
-------------------------------- --------
...
Marker-type auto
...


-------------------------------- -------- Dette bør vanligvis settes til "auto", da dette gjør at DDR automatisk samsvarer med de vanligste markørtypene. Hvis systemet inntar data fra bare én sikkerhetskopieringsapplikasjon som setter inn markører, kan det være en ytelsesfordel ved å angi en bestemt markørtype, det vil være:

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

Se dette:

• Alle fordeler med ytelsen ved å velge en bestemt markørtype er sannsynligvis minimal.
• Hvis du velger feil markørtype, kan det føre til betydelig ekstra degradering for sikkerhetskopiering eller gjenoppretting av ytelse og dedupliseringsforhold.

Som et resultat anbefaler Data Domain vanligvis å la markørtypen være satt til "auto". Hvis du vil ha ytterligere råd om endring av markørtype, kan du kontakte den avtalte kundestøtteleverandøren.

For systemer som inntar data fra applikasjoner som bruker sikkerhetskopieringsmarkeringer, men som ikke gjenkjennes av automatisert markørhåndteringsteknologi (for eksempel produkter fra BridgeHead-programvare), kan du kontakte den avtalte kundestøtteleverandøren som deretter kan samarbeide med Data Domain-støtte for å fastslå nødvendige innstillinger på DDR for å oppdage den ikke-standardmarkøren.

Indikasjoner på data med dårlig kvalitet som mottas av en DDR:

Følgende tabell inneholder forventede dedupliserings- og komprimeringsforhold for de ulike datatypene som er oppført ovenfor. Denne listen er ikke uttømmende, og det kan selvsagt være en viss variasjon i de nøyaktige tallene som vises på et gitt system på grunn av arbeidsbelastning eller data som er inntatt av DDR:
 

Global komprimering	Lokal komprimering	Sannsynlig årsak
Lav (1–4 x)	Lav (1–1,5 x)	Forhåndskomprimerte eller krypterte data
Lav (1–2 x)	Høy (>2 x)	Unike, men komprimerbare data, for eksempel databasearkivlogger
Lav (2–5 x)	Høy (>1,5 x)	Markører som ikke oppdages eller høy dataendringshastighet eller strømmer multipleksing.
Høy (>10 x)	Lav (<1,5 x)	Sikkerhetskopiering av de samme komprimerte eller krypterte dataene. Dette er uvanlig.

Er det visse faktorer på en DDR som kan påvirke det generelle dedupliseringsforholdet?

Ja – Det finnes flere faktorer som kan føre til at gamle/superflous data beholdes på disken på en DDR som fører til en økning i postkomprimert (fysisk) diskplass og et fall i det totale komprimeringsforholdet. Slike faktorer er beskrevet nedenfor.

Hvis du ikke kjører rengjøring av filsystemet regelmessig:

Rensing av filsystemet er den eneste måten å fysisk fjerne gamle/superflous data på disken som ikke lenger refereres til av filer på DDR. Som et resultat av dette kan en bruker slette flere filer fra systemet (forårsake fall i forhåndskomprimert bruk), men ikke kjøre ren (etterkomprimert/fysisk bruk høy). Dette vil føre til et fall i det totale komprimeringsforholdet.

Data Domain anbefaler at du utfører en ren planlegging for kjøring med jevne mellomrom på følgende måte:

• Normal DDR: Én gang i uken
• DDR ved hjelp av utvidet oppbevaring: Én gang hver andre uke

Clean skal ikke kjøres mer enn én gang i uken, da dette kan føre til problemer med fragmentering av data på disken som manifesterer seg som dårlig gjenoppretting/replikeringsytelse.

For mange gamle øyeblikksbilder på systemet:

DDR-er kan opprette mTree-øyeblikksbilder som representerer innholdet i et mTree på tidspunktet da øyeblikksbildet ble opprettet. Vær imidlertid oppmerksom på at å etterlate gamle øyeblikksbilder på et system kan føre til en økning i postkomprimert/fysisk bruk som forårsaker et fall i det totale komprimeringsforholdet. Eksempel:

• Det finnes et mtree som inneholder mange filer (så forhåndskomprimert utnyttelse er høy).
• Et øyeblikksbilde av mTree opprettes.
• Mange filer slettes (noe som fører til at forhåndskomprimert bruk reduseres).
• Rensing av filsystemet kjøres – vær imidlertid oppmerksom på at minimalt med harddiskplass frigjøres, ettersom en kopi av de slettede filene blir værende i mtree-øyeblikksbildet, noe som betyr at data som referanse til disse filene, ikke kan fjernes fra disken.
• Som et resultat av dette er postkomprimert/fysisk bruk fortsatt høy

Data Domain anbefaler at hvis mTree-øyeblikksbilder brukes (for eksempel for gjenoppretting fra sletting av utilsiktede data) administreres ved hjelp av automatiserte øyeblikksbildeplaner, slik at øyeblikksbilder opprettes regelmessig med en definert utløpsperiode (tidsrommet før øyeblikksbildet fjernes automatisk). I tillegg skal utløpsperioden være så kort som mulig (men dette kan selvsagt avhenge av brukstilfeller av øyeblikksbildene eller beskyttelsesnivået disse øyeblikksbildene gir). Dette forhindrer en oppbyggelse av gamle øyeblikksbilder med en lang utløpsperiode.

Du finner mer informasjon om hvordan du arbeider med øyeblikksbilder og tidsplaner for øyeblikksbilder i følgende artikkel: Data Domain – Administrere tidsplaner for øyeblikksbilder

Overdreven replikeringsforsinkelse:

Replikering av opprinnelig Data Domain bruker enten en replikeringslogg eller mtree-øyeblikksbilder (avhengig av replikeringstype) til å spore hvilke filer eller data som venter på replikering til en ekstern DDR. Replikeringsforsinkelse er konseptet med replikaen som faller bak endringer i kilde-DDR. Dette kan forekomme på grunn av ulike faktorer, inkludert følgende:

• Replikeringskontekster deaktiveres
• Utilstrekkelig nettverksbåndbredde mellom DDR-er
• Hyppig nettverk kobles fra.

Store replikeringsforsinkelser kan føre til at replikeringsloggen fortsetter å inneholde referanser til filer som har blitt slettet på kilde-DDR eller gamle eller foreldede mtree-øyeblikksbilder på kilde- og mål-DDR-er. Som beskrevet ovenfor kan ikke data som refereres til av disse øyeblikksbildene (eller replikeringsloggen) fysisk fjernes fra disken på DDR, selv om tilsvarende filer har blitt slettet fra systemet. Dette kan føre til at den postkomprimerte eller fysiske bruken av DDR øker, noe som deretter fører til forringelse av dedupliseringsforholdet.

Hvis DDR-er har høy utnyttelse, og det antas at dette skyldes replikeringsforsinkelse, kontakter du kundestøtteleverandøren for å få mer hjelp.

Er det konfigurasjonsendringer eller bestemte faktorer på en DDR som kan øke det totale komprimeringsforholdet?

Ja – hvis du fjerner eller adresserer problemene som tidligere er beskrevet i dette dokumentet, kan en DDR vise et forbedret samlet komprimeringsforhold over tid. Det finnes også ulike faktorer eller belastninger på en DDR som kan føre til en økning i dedupliseringsforholdet. Disse omfatter vanligvis følgende:

• Redusere mengden harddiskplass som brukes av filer på DDR (for eksempel øke aggressiviteten til komprimeringsalgoritmen som brukes av DDR)
• Plutselig øker mengden forhåndskomprimerte (logiske) data på DDR uten en tilsvarende økning i postkomprimert/fysisk bruk

Endring av komprimeringsalgoritme:

Som standard komprimerer DDR-data som skrives til disken med lz-algoritmen . Som nevnt tidligere brukes lz siden den har relativt lave kostnader når det gjelder CPU som kreves for komprimering eller dekomprimering, men viser rimelig effektivitet for å redusere datastørrelsen.

Det er mulig å øke aggressiviteten til komprimeringsalgoritmen for å gi ytterligere besparelser ved postkomprimert eller harddiskbruk (og dermed forbedre det totale komprimeringsforholdet). Støttede komprimeringsalgoritmer, i rekkefølge av effektivitet (fra lav til høy), er som følger:

• Lz
• gzfast
• Gz

En generell sammenligning av hver algoritme er som følger:

• lz sammenlignet med gzfast gir ~15 % bedre komprimering og bruker 2x CPU.
• lz sammenlignet med gz gir ~30 % bedre komprimering og bruker 5x CPU.
• gzfast sammenlignet med gz gir ~10–15 % bedre komprimering.

Det er også mulig å fullstendig deaktivere komprimering (angi en algoritme for ingen), men dette støttes ikke for bruk på kundesystemer og er bare for intern testing.

I henhold til tabellen ovenfor, jo mer aggressiv komprimeringsalgoritmen er det nødvendig med mer CPU under komprimering eller dekomprimering av data. På grunn av dette bør endringer i en mer aggressiv algoritme bare gjøres på systemer som er lett belastet under normal arbeidsbelastning. Endring av algoritmen på systemer med stor innlasting kan føre til ekstrem forringelse ved sikkerhetskopiering eller gjenoppretting av ytelse og mulige filsystemkriser eller omstarter (forårsaker nedetid i DDR).

Hvis du vil ha mer informasjon om hvordan du endrer komprimeringstypen, kan du se følgende artikkel: Innvirkning på datadomenesystem og rengjøringsytelse ved konvertering til GZ-komprimering

På grunn av den potensielle effekten av å endre komprimeringsalgoritmen anbefales det at kunder som er interessert i å gjøre dette, kontakter kundestøtteleverandøren for å diskutere endringen videre før de fortsetter.

Bruk av fastcopy for filsystemet:

DDR-er gjør det mulig å bruke kommandoen «file system fastcopy» for raskt å kopiere en fil (eller et katalogtre). Denne funksjonaliteten oppretter en fil ved å klone metadataene til en eksisterende fil (eller filgruppe), slik at selv om de nye filene ikke er fysisk koblet til den opprinnelige filen, refererer de nøyaktig de samme dataene på disken som den opprinnelige filen. Dette betyr at uavhengig av størrelsen på den opprinnelige filen, bruker den nye filen lite plass på disken (ettersom den deduplicates perfekt mot eksisterende data).

Resultatet av denne atferden er at når filsystemets hurtigkopi brukes, øker den forhåndskomprimerte (logiske) størrelsen på data på DDR raskt, men den postkomprimerte/fysiske bruken av DDR forblir statisk.

Følgende DDR har for eksempel bruk på følgende måter (noe som indikerer det totale komprimeringsforholdet på ~1,8x):

Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable 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 % -
---------------- -------- -------- --------- ---- --------------

Det inneholder en stor fil (/data/col1/backup/testfile):

!!! DDVE60_JF DATAENE DINE ER !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root root 3221225472 29. juli 04:20 /data/col1/backup/testfile

Filen blir raskt kopiert flere ganger:

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

Dette fører til at forhåndskomprimert bruk øker for liten endring i postkomprimert utnyttelse: Active Tier:


Resource Size GiB Used GiB Avail GiB Use% 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 et resultat viser DDR nå det totale komprimeringsforholdet på ~3,1x.

Som nevnt ovenfor viser komprimeringsstatistikken for kopiene at de deduplicate perfectly:

sysadmin@DDVE60_JF# filesys show compression /data/col1/backup/testfile_copy1
Total files: 1;  bytes/storage_used: 21331976.1
Opprinnelige byte:        3 242 460 364
globalt komprimerte:                    0
lokalt komprimert:                    0
Meta-data:                  152

Fastcopy-funksjonalitet kan ikke brukes til å forbedre det totale komprimeringsforholdet ved å redusere fysisk bruk av DDR, men det kan være årsaken til høyt samlet komprimeringsforhold (spesielt i miljøer som gjør omfattende bruk av fastkopi, for eksempel Avamar 6.x).