Data Domain – vanliga frågor och svar om komprimering

GÄLLER

• Alla DDR:er
• Alla utgåvor

Komprimering: Vanliga frågor och svar:

Helst skulle detta vara sant. I praktiken använder den fullständiga säkerhetskopieringen lite mer utrymme än den inkrementella på grund av följande orsaker. Dessa skäl förklarar också varför en fullständig säkerhetskopiering utan dataändringar fortfarande förbrukar en positiv mängd utrymme.

• Metadata tar cirka 0,5 % av säkerhetskopians logiska storlek. Anta att den logiska storleken för den fullständiga är 100 GB och den för den inkrementella är 2 GB. Anta att de inkrementella komprimeringarna blir 1 GB. Då tar det hela minst 1,5 GB.
• DD-komprimeringsmotorn skriver om vissa duplicerade datasegment för prestanda. Ju sämre dataplatsen för ändringarna är, desto mer skrivs dubbletterna. Dubbletterna återtas senare genom "filesys cleaning". Jag har sett ca 2% av den logiska storleken skrivas om som dubblett. Om vi antar den här nivån av dubbletter kan den fullständiga ta 1 GB (komprimerad) + 0,5 GB (metadata) +2 GB (dubbletter) = 3,5 GB. Mängden dubbletter som skrivs kan styras via en systemparameter, men vi justerar vanligtvis inte den här parametern i fältet.
• Datasegmenteringen kan variera lite från säkerhetskopia till säkerhetskopiering beroende på i vilken ordning NFS-klienten skickar data. Den här ordningen är inte deterministisk. I allmänhet tolererar segmenteringsalgoritmen skiftningar och omordning. Men det skapar också några "tvingade" segment, som är benägna att förskjutas och ombeställas. Vanligtvis är cirka 0,2 % av segmenten tvingade, så man kan förvänta sig att mycket mer utrymme används.

"filesys show space" ger komprimeringsförhållandet baserat på den logiska storleken på de data som lagras och det diskutrymme som används när kommandot körs.

"filesys show compression" ger komprimeringsförhållandet baserat på hur varje fil komprimerades när den skapades.

"filesys show compression" används mest för support och felsökning. Om filer tas bort överskattar "filesys show compression" komprimeringsförhållandet.

Antagandet är till exempel att den första fullständiga säkerhetskopian får 2x komprimering. En efterföljande fullständig säkerhetskopiering utan några dataändringar får 200x komprimering. Den första fullständiga säkerhetskopian tas bort. "filesys show space" visar ett komprimeringsförhållande på 2x. "filesys show compression" kommer nu att visa ett komprimeringsförhållande på 200x, eftersom den enda fil som finns nu fick en komprimering på 200x när den skapades.

I exemplet som nämns ovan, efter den andra säkerhetskopieringen, visar "filesys show space" ett kumulativt förhållande på cirka 4x. Det kumulativa förhållandet skulle förbättras asymptotiskt mot 200x om du fortsätter att göra fler säkerhetskopieringar utan borttagning.

Det finns några andra mindre skillnader:

•  "filesys show compression" tar inte hänsyn till slöseri på containernivå, vilket gör att komprimeringsförhållandet överskattas ytterligare
•  "filesys show compression" tar inte hänsyn till duplicerad eliminering genom global komprimering, vilket innebär att komprimeringsförhållandet underskattas
•  "filesys show compression" kan ge information per fil eller per katalog, medan "filesys show space" är begränsat till hela systemet
•  "filesys show compression" visar uppdelningen mellan global och lokal komprimering, medan "filesys show space" inte gör det

REFERENSER

• Varför är komprimeringsförhållandena olika för "filesys show space" och "vtl tape show summary"?

Komprimeringsförhållandet som visas i "vtl tape show summary" är avsett att matcha "filesys show compression /backup/vtc".

Mer allmänt kan detta VTL-kommando ges ett valfritt filter för att välja en delmängd av bandkassetter, och komprimeringen är tänkt att matcha "filesys show compression" på den delmängden av kassetter.

Men på grund av en bugg i VTL UI-koden är komprimeringen som visas i "vtl tape show summary" felaktig. Det här är ett känt problem som åtgärdas i version 4.5.0.0.
 

• Varför matchar inte "filesys show compression last 24 hours" förväntningarna för VTL?

För VTL uppfyller utdata från kommandon som "filesys show compression last 24 hours" ofta inte förväntningarna baserat på andra källor som "system show performance".

Problemet uppstår på grund av en egenhet i "filesys show compression" (fsc). I allmänhet visar "filesys show compression" kumulativ statistik i valda filer. Kvalificeraren "senaste 24 timmarna" väljer de filer som har uppdaterats under de senaste 24 timmarna. Statistiken är fortfarande kumulativ sedan filen skapades eller senast trunkerades till nollstorlek. Således, om en fil har lagts till under de senaste 24 timmarna, kommer "filesys show compression last 24 hours" att visa dess kumulativa statistik före de senaste 24 timmarna.

I icke-VTL-miljöer skrivs säkerhetskopieringsfiler bara en gång, så det finns ingen större skillnad mellan filer som uppdateras och filer som skapas. Med VTL kan säkerhetskopior bifogas till befintliga bandfiler. Tänk dig till exempel ett band med en kapacitet på 100 GB som är fyllt upp till 50 GB. Om 10 GB data har lagts till på det här bandet under de senaste 24 timmarna, kommer "filesys show compression last 24 hours" att visa filens "Original bytes" skrivet på 60 GB.
 

• Hur beräknas det kumulativa kompressionsförhållandet?

Individuella kompressionsförhållanden går inte ihop linjärt.

Anta att komprimeringen vid den första fullständiga säkerhetskopian är 2x och att komprimeringen vid den andra fullständiga säkerhetskopian är 20x. Den kumulativa komprimeringen är inte (2+20)/2 eller 11x, utan 2/(1/2+1/20) eller 3,64x.

I allmänhet har lägre kompressionsförhållanden större inverkan än högre på det kumulativa kompressionsförhållandet.

Anta att den i:te säkerhetskopian har logisk storlek si och komprimeringsförhållande ci. Sedan kan det kumulativa komprimeringsförhållandet för k-säkerhetskopior beräknas enligt följande:

C = (total logisk storlek)/(totalt utrymme som används)
total logisk storlek = s1 + s2 + .. + SK
totalt använt utrymme = S1/C1 + S2/C2 + ... + sk/ck

Ofta är de logiska storlekarna ungefär desamma. I så fall förenklas ovanstående beräkning till följande:

Om den första fullständiga säkerhetskopian till exempel får 3x komprimering och varje efterföljande fullständig får 30x komprimering och kvarhållningsperioden är 30 dagar, ser användaren en kumulativ komprimering på 30/(1/3+29/30) eller 23x.
 

• Hur fungerar Data Domain Compression?

Den här frågan besvaras i detalj i en separat KB-artikel, "Understanding Data Domain Compression" Data Domain: Förstå komprimering i Data Domain
 

• Har Data Domain stöd för multiplexering? ​​​​​​​

Multiplexerade data från säkerhetskopieringsprogrammet resulterar i mycket dålig global deduplicering. Mer information finns i den relaterade artikeln Multiplexering i säkerhetskopieringsprogrammet stöds inte Data Domain: Multiplexering i säkerhetskopieringsprogram. 
 

• Varför visar repliken bättre global komprimering med 1-till-1-katalogreplikering?​​​​​​​

Detta beror vanligtvis på variationer i nivån på dubbletter av segment som skrivs i systemet:

• De data som lagras vid källan har deduplicerats en gång – mot tidigare data som lagras vid källan.
• De data som skickas via kabeln har deduplicerats en gång – mot de data som lagras på repliken.
• Data som lagras på repliken har deduplicerats två gånger, en gång när data skickades via kabeln och igen när mottagna data skrivs på repliken.

Eftersom dedupliceringsprocessen lämnar vissa dubbletter har data som har deduplicerats flera gånger färre dubbletter. De data som lagras vid källan och skickas via kabeln dedupliceras en gång, så de är ungefär desamma, förutsatt att de data som lagras vid källan och repliken är liknande. Data som lagras på repliken dedupliceras två gånger, så det är bättre komprimerat.

Rensning av filsystemet tar bort de flesta dubbletterna. När rensningen har körts på källan och repliken bör därför mängden data som lagras där vara ungefär densamma.

• Vad är förändringen i komprimering när du använder lz, gzfast och gz lokala komprimeringsinställningar?

Filesys alternativuppsättningskomprimering {ingen | lz | gzfast | gz}
 

Varning! Innan du ändrar den lokala komprimeringstypen måste filsystemet stängas av. Den kan sedan startas om omedelbart efter att komprimeringsalternativet har ställts in.

I allmänhet är komprimeringsordningen följande:

Den grova skillnaden är:

• lz till gzfast ger ~15 % bättre komprimering och förbrukar 2x CPU
• lz till gz ger ~30 % bättre komprimering och förbrukar 5x CPU
• GZfast till GZ ger ~10-15% bättre komprimering

Observera att om du ändrar den lokala komprimeringen påverkas nya data som skrivs till DataDomain Restorer efter att ändringen har gjorts. De gamla uppgifterna behåller sitt tidigare komprimeringsformat till nästa rensningscykel. Nästa rensningscykel kopierar alla gamla data till det nya komprimeringsformatet. Detta gör att rensningen körs mycket längre och tar mer CPU.

Om kundsystemet redan har ont om processor, särskilt om kunden säkerhetskopierar och replikerar samtidigt, kan detta göra säkerhetskopieringen och/eller replikeringen långsammare. Kunden kanske uttryckligen vill schemalägga en tid för att göra den här konverteringen.

Kunskapsreferenser:

• Lösa migreringsproblem
• Data Domain: Förstå komprimering i Data Domain