Felsökning av dåligt deduplicerings- och komprimeringsförhållande för filer på Data Domain Restorers (DDR:s)

Data Domain Restorers (DDR: er) är utformade för att innehålla stora mängder logiska (förkomprimerade) data med minimalt fysiskt (postkomprimerat) diskutrymme. Detta uppnås med hjälp av:

• Deduplicering av intag av data för att ta bort dubbletter av datablock som redan har lagrats på disken i DDR lämnar endast unika data
• Komprimering av unika data innan dessa data skrivs fysiskt till disken.

Det totala komprimeringsförhållandet för data som kan matas in av DDR varierar på grund av flera faktorer som:

• Användning
• Datatyper som matas in
• Säkerhetskopiering av programkonfiguration

När den är optimalt konfigurerad uppnår DDR:erna vanligtvis det totala komprimeringsförhållandet 10–20 gånger (och kan ibland visa förhållanden som är högre än så). Men i vissa miljöer kan det totala komprimeringsförhållandet vara lägre än så, vilket kan orsaka:

• DDR kan snabbt tömma sin användbara kapacitet
• Påverkan på prestanda för säkerhetskopiering, återställning eller replikering
• DDR-felet uppfyller kundernas förväntningar

Den här artikeln är avsedd att diskutera:

• En kort översikt över deduplicering och komprimering av data på en DDR
• Så här fastställer du det övergripande komprimeringsförhållandet för systemet och enskilda filer
• Faktorer som kan orsaka försämring av det övergripande komprimeringsförhållandet

Hur matar en Data Domain Restorer in nya data?

• Säkerhetskopieringsprogrammet skickar data (dvs. filer) till DDR.
• DDR delar upp dessa filer i delar om 4–12 Kb i storlek – varje block ses som ett "segment".
• DDR genererar ett unikt "fingeravtryck" (liknar en kontrollsumma) för varje segment beroende på de data som finns i segmenten.
• Fingeravtrycken för nyligen ankomna segment kontrolleras mot diskindex på DDR för att avgöra om DDR redan har ett segment med samma fingeravtryck.
• Om DDR redan har ett segment med samma fingeravtryck är motsvarande segment i de nyligen angivna data en dubblett och kan utelämnas (som är deduplicerad).
• När alla dubblettsegment har tagits bort från de nyligen ankomna data finns endast unika eller nya segment kvar.
• Dessa unika eller nya segment grupperas i 128 Kb-komprimeringsområden och komprimeras sedan (med lz-algoritmen som standard).
• Komprimerade komprimeringsområden packas in i 4,5 Mb-enheter av lagringsenheter som kallas "behållare" som sedan skrivs till hårddisken.

Hur spårar DDR vilka segment som utgör en viss fil?

Utöver deduplicering/komprimering av nyligen angivna data bygger DDR även ett "segmentträd" för varje intag av filer. Det här är i princip en lista med segment med "fingeravtryck" som utgör den filen. Om DDR senare måste läsa filen igen finns följande:

• Ta reda på platsen för filsegmentträdet.
• Läs segmentträdet för att få en lista över alla segmentfingeravtryck som utgör den region i filen som läss.
• Använd volymer på disken för att fastställa den fysiska platsen (dvs. behållaren) för data på disken.
• Läs de fysiska segmentdata från de underliggande behållarna på disken.
• Använd fysiska segmentdata för att rekonstruera filen.

Filsegmentträd lagras också i 4,5 Mb-behållare på disken och representerar majoriteten av filernas "metadata" (beskrivs senare i den här artikeln).

Hur kan det övergripande komprimeringsförhållandet på en DDR bestämmas?

Den totala användningen av ett DDR-förhållande (och komprimeringsförhållande) kan ses med kommandot "filesys show space". Exempel:

Aktiv nivå:
Resursstorlek GiB använde GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: före kompri comp - 115367.8 - -
/data: post-comp 6794 2 6242,4 551,8 92 % 202,5
/ddvar 49,2 9,1 37,6 20 % –


---------------- -------- -------- --------- ---- --------------I det här fallet ser vi följande:

• Förkomprimerade eller logiska data som finns på DDR: 115 367,8 Gb
• Postkomprimerat eller fysiskt utrymme som används på DDR: 6242,4 Gb
• Det totala komprimeringsförhållandet är 115 367,8/6 242,4 = 18,48 x

Utdata från kommandot "filesys show compression" bekräftar de data som lagras, det utrymme som används och komprimeringsförhållandet. Till exempel:

                   Pre-comp post-comp global-comp lokal-comp total-comp
(GiB) (GiB) factor factor
(reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently used:*   115367.8 6242.4 - - 18,5x (94,6) <=== Anmärkning
skriven:                                                                          
  Senaste 7 dagarna 42214.7 1863.2 11.0x 2.1x 22.7x (95.6)
  Senaste 24 tim 4924.8 274.0 8.8x 2.0x 18.0x (94.4)
---------------- -------- --------- ----------- ---------- -------------

Överbliven användningsfigurer på DDR beräknas enligt följande:

• Totalt antal förkomprimerade data: Summan av den förkomprimerade (logiska) storleken på alla filer som innehas av DDR.
• Totalt antal postkomprimerade data: Antalet använda "behållare" på disken multiplicerat med 4,5 Mb (storleken på en enda behållare).
• Total postkomprimerad storlek: Det maximala antalet "behållare" som skapas ges tillgängligt diskutrymme i systemet.

Statistik om maximal användning av behållare för användning finns i autosupport. Exempel:

Container set 73fcacadea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <=== behållarstorlek i byte
...
    attrs.max_containers = 1546057 <=== Högsta möjliga behållare
attrs.free_containers = 125562 <=== För närvarande attrs.used_containers lediga behållare
= 1420495 <=== För närvarande i användningsbehållare
...

Se det:
 
Hur kan kvoter för deduplicering och komprimering för en enskild fil, katalog eller katalogträd fastställas?

När en fil matas in registrerar DDR-poster statistik om filen, inklusive:

• Förkomprimerade (logiska) byte
• Storlek på unika segment efter deduplicering
• Storleken på unika segment efter deduplicering och komprimering
• Storlek på filens metadata (alltså segmentträdet osv.)

Det går att dumpa en del av den här statistiken med kommandot "filesys show compression [path]" – till exempel att rapportera statistik för en enda fil:

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

Om du vill rapportera statistik för ett helt katalogträd:

SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files: 3;  byte/storage_used: 1,4
originalbyte:        7 554 284 280
globalt komprimerade:        5 425 407 986
lokalt komprimerade:        5 510 685 100
metadata:           23 263 692

Observera dock att det finns ett par varningar om att använda den här statistiken:

• Statistiken genereras vid tidpunkten för fil- eller datainsamling och följer inte den här uppdateringen. På grund av hur en DDR fungerar, intag av nya filer eller borttagning av filer som refererar till samma data, och så vidare, kan ändra hur en fil deduplicerar över tid, vilket gör att denna statistik blir inaktiv.
• Vissa användningsfall på DDR (t.ex. FastCopy i en fil och sedan borttagning av den ursprungliga filen) kan dessutom leda till att denna statistik blir missvisande eller felaktig.

Det gör att dessa siffror endast anses vara uppskattade.

De förkomprimerade byte-byte är inte nödvändigtvis den förkomprimerade/logiska storleken på filen. I stället är det det totala antalet byte som skrivs till en fil under dess livstid. Därför skrivs befintliga filer ofta över i vissa miljöer (t.ex. de som använder funktionen virtual tape library) och den här bilden kan vara större än den logiska storleken på motsvarande filer.

Kan intag av data av "dålig kvalitet" orsaka försämringar i det totala komprimeringsförhållandet?

Ja – för att ett DDR ska uppnå ett bra övergripande komprimeringsförhållande för intag av data måste den kunna deduplicera och komprimera dessa data. Det finns olika typer av data som kan förhindra detta enligt beskrivningen nedan:

förkomprimerade/förkrypterade data:

Dessa är datatyper som antingen komprimeras eller krypteras på klientsystemet eller av säkerhetskopieringsprogrammet. Detta kan även inkludera programspecifika filer som är komprimerade eller krypterade av design (t.ex. mediefiler) och databasfiler som antingen är komprimerade eller krypterade eller bäddar in binära objekt, till exempel mediefiler.

På grund av hur algoritmen för komprimering eller kryptering fungerar leder en relativt liten förändring av en fils underliggande data till att ändringar "kryper ut" över filen. En klient kan till exempel innehålla en krypterad fil på 100 Mbit inom vilken 10 KB har ändrats. Den resulterande filen är vanligtvis identisk före och efter modifieringen, förutom i 10Kb-avsnittet som har ändrats. Även om endast 10 kB okrypterade data har ändrats före och efter modifieringen gör krypteringsalgoritmen att hela innehållet i filen ändras när krypteringsalgoritmen används.

När sådana data ändras regelbundet och regelbundet skickas till en DDR gör den här "utslitningseffekten" att varje generation av filen ser annorlunda ut än tidigare generationer av samma fil. Som en följd av detta innehåller varje generation en unik uppsättning segment (och segmentfingeravtryck) så att det visar dåligt dedupliceringsförhållande.

Observera också att lz-algoritmen i stället för förkomprimerade filer sannolikt inte kommer att kunna komprimera ytterligare segmentdata så att data inte kan komprimeras innan de skrivs till disken.

Som allmän förkomprimering/prekryptering leder det här:

• Förkrypterade data: Dåligt dedupliceringsförhållande men acceptabelt komprimeringsförhållande
• Förkomprimerade data: Dåligt dedupliceringsförhållande och dåligt komprimeringsförhållande

När samma (oförändrade) förkomprimerade/förkrypterade data matas in av DDR flera gånger förbättras dedupliceringsförhållandet för data eftersom, trots användning av komprimerings- eller krypteringsalgoritmer, en liknande uppsättning segment (och segmentfingeravtryck) ses under varje säkerhetskopia.

Där det är möjligt ska data som skickas till en DDR inte krypteras eller komprimeras – det kan kräva att kryptering eller komprimering avaktiveras på slutklienten eller inom motsvarande säkerhetskopieringsprogram.

Kontakta lämplig supportleverantör om du vill ha hjälp med att kontrollera, ändra krypterings- eller komprimeringsinställningar i en viss säkerhetskopiering, klientapplikation eller ett operativsystem.

Mediefiler:

Vissa filtyper innehåller förkomprimerade eller förkrypterade data avsiktligt. Till exempel:

• PDF-filer
• Vissa ljudfiler (mp3, wma, ogg osv.)
• Videofiler (avi, mkv osv.)
• Bildfiler (png, bmp, jpeg osv.)
• Programspecifika filer (Microsoft Office, Open Office, Libre Office osv.)

Data i filerna komprimeras eller krypteras av filens codec och orsakar därmed samma problem när de matas in på en DDR enligt beskrivningen ovan för förkomprimerade eller förkrypterade data.

Filer med hög "unikhet":

För att uppnå ett bra dedupliceringsförhållande är beroende av att DDR ser samma uppsättning segment (och segmentfingeravläsare) flera gånger. Vissa datatyper innehåller dock endast unika transaktionsdata som avsiktligt innehåller "unika" data.

Om dessa filer skickas till en DDR innehåller varje generation av säkerhetskopian en unik uppsättning segment eller segmentfingeravläsare och som ett resultat av detta ser du ett degraderat dedupliceringsförhållande.

Exempel på sådana filer är:

• Databastransaktionsloggar (t.ex. Oracle-arkivloggar).
• Microsoft Exchange-transaktionsloggar

Den första säkerhetskopieringen av en "ny" klient till en DDR kan också orsaka problemet (eftersom data inte har setts tidigare av DDR är motsvarande segment eller segmentfingeravläsare i säkerhetskopian unika). Men med tiden, när framtida generationer med samma säkerhetskopia skickas till DDR, förbättras dedupliceringsförhållandet för säkerhetskopiering eftersom färre segment i varje ny säkerhetskopia är unika. På grund av detta förväntas det övergripande deduplicerings- eller komprimeringsförhållandet på en nyligen installerad DDR som tar emot mestadels nya säkerhetskopior försämras men förbättras med tiden.

Små filer:

Små filer orsakar olika problem när de skrivs till en DDR. Exempel på sådana komponenter:

• Överhettning av metadata – DDR börjar innehålla en högre än förväntad mängd filmetadata jämfört med fysiska data.
• Dålig användning av behållare – Avsiktligt (på grund av Data Domain Stream Informed Segment Layout eller DUOL-arkitektur – utanför det här dokumentets omfattning) innehåller en 4,5 Mbit-behållare på disken endast data från en enda fil. Till exempel gör säkerhetskopiering av en enda fil på 10 Kb att minst en fullständig 4,5 Mb-behållare skrivs för den filen. Detta kan innebära att DDR använder betydligt mer postkomprimerat (fysiskt) utrymme för sådana filer än den motsvarande mängden förkomprimerade (logiska) data som säkerhetskopieras, vilket i sin tur orsakar ett negativt övergripande komprimeringsförhållande.
• Dåligt dedupliceringsförhållande – Filer som är mindre än 4 KB (den minsta segmentstorleken som stöds på en DDR) består av ett enda segment som är vadderat till 4 Kb. Sådana segment dedupliceras inte utan skrivs direkt till disken. Det kan leda till att DDR har flera kopior av samma segment (visas som dubbletter av segment).
• Dålig säkerhetskopiering, återställning eller ren prestanda – det finns stora kostnader under säkerhetskopiering, återställning eller rensning när du flyttar från en fil till en annan (eftersom kontexten för metadata som används måste bytas).

Se det:

• Effekten av att rensa prestanda vid användning av små filer har i viss mån mildrats genom införandet av fysisk rengöring eller skräpinsamling i DDOS 5.5 och senare.
• Städningsförsök att "ångra" dålig behållaranvändning genom att aggregering av data från behållare med låg användning i mer komprimerade behållare under kopieringsfasen.
• Städningsförsök att ta bort för många dubbletter av segment under kopieringsfasen.

Trots ovanstående bör användningen av ett stort antal små filer eller arbetsbelastningar som huvudsakligen består av små filer undvikas. Det är bättre att kombinera ett stort antal små filer i ett enda okomprimerat/okrypterat arkiv före säkerhetskopiering än att skicka de små filerna till DDR i sitt inbyggda tillstånd. Det är till exempel mycket bättre att säkerhetskopiera en enda 10 Gb-fil som innehåller 1048576 enskilda 10 Kb-filer än alla 1048576 filer individuellt.

Överdriven multiplexering av säkerhetskopieringsprogram:

Säkerhetskopieringsprogram kan konfigureras för att utföra multiplexering av data över strömmar som skickas till säkerhetskopieringsenheten, dvs. data från inmatningsströmmar (som är olika klienter) skickas i en enda ström till säkerhetskopieringsenheten. Den här funktionen används främst vid skrivning till fysiska bandenheter som:

• En fysisk bandenhet kan endast stödja en enda inkommande skrivström.
• Säkerhetskopieringsprogrammet måste ha tillräckligt genomflöde till bandenheten för att förhindra bandstart, stopp eller tillbakaspolning (kallas även för indelning) – Det är enklare om strömmen till bandenheten innehåller data som läses från mer än en klient.

När det gäller DDR leder det emellertid till att en enda fil på DDR innehåller data från flera klienter som är interfolierade i godtycklig ordning eller blockstorlekar. Detta kan orsaka ett degraderat dedupliceringsförhållande eftersom DDR kanske inte kan märka dubbletter av segment från varje generation av en viss klientsäkerhetskopiering. I allmänhet är det mindre ju multiplexing-granularitet som är desto värre är effekten på dedupliceringsförhållandet.

Dessutom kan återställningsprestandan vara dålig eftersom DDR för att återställa en viss klientdata måste läsa många filer eller behållare där det mesta av data i filerna eller behållarna är överflödiga när det gäller andra klienters säkerhetskopiering.

Säkerhetskopieringsprogram måste inte använda multiplexing när du skriver till en DDR eftersom DDR:er stöder högre inkommande strömantal än fysiska bandenheter, där varje strömning kan skriva med variabel hastighet. Det innebär att multiplexing av säkerhetskopieringsprogram bör inaktiveras. Om säkerhetskopieringsprestanda påverkas efter att multiplexering har inaktiverats ska du:

• Säkerhetskopieringsprogram med CIFS, NFS eller OST (DDBoost) bör få sitt antal skrivströmmar ökade (så att fler filer kan skrivas parallellt på DDR).
• Miljöer som använder VTL bör lägga till ytterligare enheter till DDR eftersom varje enhet ger stöd för ytterligare en parallell skrivström.

Kontakta din supportleverantör om du behöver hjälp med att avaktivera multiplexning eller om du vill diskutera rekommenderad multiplexningskonfiguration för ett specifikt säkerhetskopieringsprogram.

Säkerhetskopieringsprogram som sätter in för många bandmarkörer:

Vissa säkerhetskopieringsprogram kan infoga upprepade datastrukturer i en ström för säkerhetskopiering som kallas "markören". Pennor representerar inte fysiska data i säkerhetskopieringen utan används istället som indexerings- eller positionssystem av säkerhetskopieringsprogrammet.

I vissa fall kan införandet av markören i en säkerhetskopieringsström försämra dedupliceringsförhållandet, till exempel:

• Under den första generationen av en säkerhetskopiering fanns det 12 KB data som var sammanhängande – detta identifierades av DDR som ett enda segment.
• I den andra generationen av säkerhetskopian delas emellertid samma 12 Kb data genom att en säkerhetskopia inkluderas som kan representeras av 6 KB data, markör för säkerhetskopiering, 6 KB data.
• Det innebär att de segment som skapas under den andra generationen av säkerhetskopian inte matchar de som genererades under den första generationen av säkerhetskopieringen. Därför deduplicerar de inte korrekt.

Ju mer utdelade markörena är desto värre är effekten på dedupliceringsförhållandet (t.ex. orsakar ett säkerhetskopieringsprogram som sätter in pennor var 32 Kb fler problem än att ett säkerhetskopieringsprogram sätter in pennor var 1 Mb).

För att undvika problemet använder DDR tekniken för markörigenkänning som gör att:

• Säkerhetskopiera pennor som ska tas bort transparent från säkerhetskopieringsströmmen under intag av säkerhetskopian.
• Säkerhetskopieringsmarkörer som ska sättas in i säkerhetskopieringsströmmen igen under återställningen av säkerhetskopian

Detta bidrar till att förhindra fragmentering av data eller segment genom säkerhetskopieringsmarkörer och förbättrar dedupliceringsförhållandet för motsvarande säkerhetskopior.

För att dra full nytta av den här tekniken är det dock viktigt att DDR korrekt känner igen markören som sätts in i säkerhetskopieringsströmmar. DDR söker efter pennor beroende på inställningen för alternativet "markörtyp", till exempel:

alternativet SE@DDVE60_JF## filesys visar
alternativvärdet
-------------------------------- --------
...
Automarkörtyp
...


-------------------------------- --------Usually bör detta lämnas inställt på "auto" eftersom det gör det möjligt för DDR att automatiskt matcha de vanligaste markörtyperna. Om systemet matar in data från endast ett säkerhetskopieringsprogram som sätter in pennor kan det finnas prestandafördelar med att ange en specifik markörtyp, d.v.s

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

Se följande:

• Eventuella fördelar med att välja en viss markörtyp är troligtvis minimala.
• Om du väljer en felaktig markörtyp kan det orsaka betydande ytterligare försämringar av säkerhetskopiera eller återställa prestanda och edupliceringsförhållande.

Därför rekommenderar Data Domain i allmänhet att markörtypen lämnas inställd på "auto". Kontakta din supportleverantör om du vill ha mer information om hur du ändrar markörtyp.

För system som matar in data från program som använder säkerhetskopieringsmarkörer men som inte identifieras av automatiserad markörhanteringsteknik (t.ex. produkter från BridgeHead-programvara) kontaktar du din kontrakterade supportleverantör som sedan kan arbeta med Data Domain-support för att fastställa de inställningar som krävs för DDR för att detektera den icke-standardmarkören.

Indikationer på data av "dålig kvalitet" som tas emot av en DDR:

I följande tabell visas förväntade kvoter för deduplicering och komprimering för de olika datatyperna som anges ovan. Den här listan är inte heltäckande och det kan så klart finnas en viss variation i de exakta siffrorna som syns på ett visst system på grund av arbetsbelastning eller data som matas in av DDR:
 

Global komprimering	Lokal komprimering	Sannolik orsak
Låg (1 x – 4 gånger)	Låg (1x–1,5x)	Förkomprimerade eller krypterade data
Låg (1 x – 2 gånger)	Hög (>2 gånger)	Unika men komprimerbara data, t.ex. databasarkivloggar
Låg (2 x – 5 gånger)	Hög (>1,5x)	Pennor som inte upptäcks eller hög dataändringshastighet eller strömma multiplexning.
Hög (>10 gånger)	Låg (<1,5x)	Säkerhetskopiering av samma komprimerade eller krypterade data. Detta är ovanligt.

Finns det vissa faktorer på en DDR som kan påverka det övergripande dedupliceringsförhållandet?

Ja – Det finns flera faktorer som kan göra att gamla/superflous-data behålls på disken på en DDR, vilket orsakar en ökning av postkomprimerat (fysiskt) diskutrymme och en minskning av det totala komprimeringsförhållandet. Sådana faktorer diskuteras nedan.

Ett fel med att regelbundet köra rensning av filsystem:

Rensning av filsystemet är det enda sättet att fysiskt ta bort gamla/superflous-data på disken, som inte längre refereras till av filer på DDR. Det innebär att användaren kan ta bort flera filer från systemet (vilket orsakar en minskning av förkomprimerad användning) men inte köra rent (vilket lämnar postkomprimerad/fysisk användning hög). Det skulle leda till ett fall i det totala komprimeringsförhållandet.

Data Domain rekommenderar schemaläggning av rensning för att köras regelbundet enligt följande:

• Normal DDR: En gång i veckan
• DDR med utökad kvarhållning: En gång varannan vecka

Clean bör inte köras mer än en gång i veckan eftersom det kan orsaka problem med fragmentering av data på disken som visas som dålig återställnings-/replikeringsprestanda.

För många gamla snapshots i systemet:

DDR:er kan skapa mtree-snapshots som representerar innehållet i ett mtree vid den tidpunkt då snapshotet skapades. Observera dock att om gamla snapshots lämnas i ett system kan det leda till en ökning av postkomprimerad/fysisk användning, vilket orsakar en minskning av det totala komprimeringsförhållandet. Till exempel:

• Det finns ett mtree med många filer (så förkomprimerad användning är hög).
• En snapshot av mtree skapas.
• Många filer tas bort (vilket gör att förkomprimerad användning försvinner).
• Rensning av filsystemet körs . Observera att det minimala hårddiskutrymmet frigörs som en kopia av de borttagna filerna i mtree-snapshotet, vilket innebär att data som refereras till av dessa filer inte kan tas bort från disken.
• Postkomprimerad/fysisk användning är därför fortfarande hög

Data Domain rekommenderar att om mtree-snapshots används (t.ex. för återställning från oavsiktlig databorttagning) hanteras de med hjälp av automatiserade snapshotscheman så att snapshots skapas regelbundet med en definierad utgångsperiod (tiden innan snapshotet tas bort automatiskt). Dessutom ska utgångsperioden vara så kort som möjligt (men det kan självklart bero på användningsfall för snapshots eller skyddsnivå som dessa snapshots ger). Det förhindrar ansamling av gamla snapshots med lång utgångsperiod.

Mer information om hur du arbetar med ögonblicksbilder och scheman för snapshots finns i följande artikel: Data Domain – hantera snapshotscheman

För stor replikeringsfördröjning:

Vid replikering av native Data Domain används antingen en replikeringslogg eller mtree-snapshots (beroende på replikeringstyp) för att spåra vilka filer eller data som väntar på replikering till en fjärr-DDR. Replikeringsfördröjning är konceptet med replikeringar som faller efter ändringar i käll-DDR. Detta kan inträffa på grund av olika faktorer, inklusive:

• Replikeringskontexter inaktiveras
• Otillräcklig nätverksbandbredd mellan DDR:erna
• Frekventa nätverksfrånkopplingar.

Stor replikeringsfördröjning kan leda till att replikeringsloggen fortsätter att innehålla referenser till filer som har tagits bort från KÄLL-DDR eller gamla eller inaktuella mtree-snapshots på käll- och mål-DDR:er. Enligt beskrivningen ovan kan data som refereras till av dessa snapshots (eller replikeringsloggen) inte tas bort fysiskt från disken på DDR även om motsvarande filer har tagits bort från systemet. Detta kan leda till att DDR-ddr-minneshöljet postkomprimeras eller används fysiskt, vilket sedan orsakar försämring i kvoten för deduplicering.

Om DDR:er är drabbade av hög användning, och det verkar bero på replikeringsfördröjning, kontaktar du din supportleverantör för att få ytterligare hjälp.

Finns det konfigurationsändringar eller vissa faktorer på en DDR som kan öka det totala komprimeringsförhållandet?

Ja – om man tar bort eller tar itu med de problem som beskrivs tidigare i det här dokumentet bör ddr kunna visa ett förbättrat övergripande komprimeringsförhållande över tid. Det finns också olika faktorer eller arbetsbelastningar på en DDR som kan leda till en ökning i dedupliceringsförhållandet. Dessa omfattar i allmänhet:

• Minska mängden hårddiskutrymme som används av filer på DDR (till exempel öka aggressiviteten hos komprimeringsalgoritmen som används av DDR)
• Plötsligt ökar mängden förkomprimerade (logiska) data på DDR utan motsvarande ökning av postkomprimerad/fysisk användning

Modifiering av komprimeringsalgoritmen:

Som standard komprimerar DDR:er komprimerade data som skrivs till disk med lz-algoritmen . Som tidigare nämnts används lz eftersom den har relativt låg belastning när det gäller processorkraft som krävs för komprimering eller dekomprimering, men visar rimlig effektivitet när det gäller att minska datastorleken.

Det är möjligt att öka aggressiviteten hos komprimeringsalgoritmen för att ge ytterligare besparingar i postkomprimerad användning eller hårddiskanvändning (och därmed förbättra det övergripande komprimeringsförhållandet). Komprimeringsalgoritmer som stöds i ordningsföljd (från låg till hög) är följande:

• Lz
• gzfast
• Gz

En allmän jämförelse av varje algoritm är som följer:

• lz jämfört med gzfast ger ~15 % bättre komprimering och förbrukar två processorer.
• lz jämfört med gz ger ~30 % bättre komprimering och förbrukar 5 x CPU.
• gzfast jämfört med gz ger ~10–15 % bättre komprimering.

Det är också möjligt att helt avaktivera komprimering (ange en algoritm av ingen), men det här stöds inte för användning på kundsystem och är endast för interna tester.

Enligt ovanstående tabell krävs mer cpu vid komprimering eller dekomprimering av data, desto mer aggressiv komprimeringsalgoritm. På grund av detta bör ändringar av en mer aggressiv algoritm endast göras på system som läses in lätt under normal arbetsbelastning. Om du ändrar algoritmen i system med stor belastning kan det leda till extrem försämring av säkerhetskopierings- eller återställningsprestanda och eventuellt få filsystemet att kraschar eller startas om (vilket orsakar ett avbrott i DDR).

Mer information om hur du ändrar komprimeringstyp finns i följande artikel: Data Domain-system och rensning av prestandapåverkan vid konvertering till GZ-komprimering

På grund av den potentiella effekten av en ändring av komprimeringsalgoritmen rekommenderar vi att kunder som är intresserade av att göra detta kontaktar sin supportleverantör för att diskutera ändringen ytterligare innan du fortsätter.

Användning av filsystemet FastCopy:

DDR tillåter användning av kommandot "file system fastcopy" för att snabbt kopiera en fil (eller katalogträdet). Den här funktionen skapar en fil genom att klona metadata för en befintlig fil (eller grupp av filer) så att även om de nya filerna inte är fysiskt anslutna till den ursprungliga filen refererar de till exakt samma data på disken som den ursprungliga filen. Det innebär att oavsett storleken på den nya filen förbrukar den nya filen lite utrymme på disken (eftersom den deduplicerar perfekt mot befintliga data).

Resultatet av detta beteende är att när filsystemet FastCopy används förkomprimeras (logisk) storlek på data på DDR ökar snabbt, men den postkomprimerade/fysiska användningen av DDR förblir statisk.

Till exempel har följande DDR-användning enligt följande (anger det totala komprimeringsförhållandet ~1,8x):

Aktiv nivå:
Resursstorlek GiB Använde 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 innehåller en stor fil (/data/col1/backup/testfile):

!!! DDVE60_JF DATA ÄR FARLIGA !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root 3221225472 29 jul kl. 04:20 /data/col1/backup/testfile

Filen kopieras snabbt flera gånger:

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

Detta gör att förkomprimerad användning ökar för liten förändring i efterkomprimerat användning:

Aktiv nivå:
Resursstorlek GiB använde 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% -
---------------- -------- -------- --------- ---- --------------

As ett resultat som DDR nu visar det övergripande komprimeringsförhållandet på ~3,1x.

Som nämnts ovan visar komprimeringsstatistiken för kopiorna att deduplicera perfekt:

sysadmin@DDVE60_JF# filesys visar komprimering /data/col1/backup/testfile_copy1
Totalt antal filer: 1;  byte/storage_used: 21331976.1
ursprungligt byte:        3 242 460 364
globalt komprimerade:                    0
Lokalt komprimerad:                    0
metadata:                  152

FastCopy-funktionen kan inte användas för att förbättra det övergripande komprimeringsförhållandet genom att minska den fysiska användningen av DDR, men det kan vara orsaken till ett högt övergripande komprimeringsförhållande (särskilt i miljöer som använder FastCopy som Avamar 6.x).