Data Domain - Veelgestelde vragen over compressie

VAN TOEPASSING OP

• Alle DDR's
• Alle releases

Compressie: Veelgestelde vragen:

In het ideale geval zou dit waar zijn. In de praktijk neemt de volledige back-up iets meer ruimte in beslag dan de incrementele back-up, en wel om de volgende redenen. Deze redenen verklaren ook waarom een volledige back-up zonder wijzigingen in data nog steeds een positieve hoeveelheid ruimte in beslag neemt.

• De metadata nemen ongeveer 0,5% van de logische grootte van de back-up in beslag. Stel dat de logische grootte van de volledige 100 GB is en die van de incrementele 2 GB. Stel dat de incrementele comprimeert tot 1 GB. Dan neemt de volledige minimaal 1,5 GB in beslag.
• De DD-compressie-engine zal enkele dubbele gegevenssegmenten herschrijven voor prestaties. Hoe slechter de gegevenslocatie van de wijzigingen, hoe meer de duplicaten worden geschreven. De duplicaten worden later teruggevorderd door "filesys cleaning". Ik heb ongeveer 2% van de logische grootte herschreven zien worden als duplicaat. Uitgaande van dit niveau van duplicaten, kan het volledige 1 GB (gecomprimeerd) + 0,5 GB (metadata) + 2 GB (duplicaten) = 3,5 GB in beslag nemen. Het aantal geschreven duplicaten kan worden geregeld via een systeemparameter, maar we stemmen deze parameter over het algemeen niet af in het veld.
• De datasegmentatie kan enigszins variëren van back-up tot back-up, afhankelijk van de volgorde waarin de NFS-client de data verzendt. Deze volgorde is niet deterministisch. Over het algemeen tolereert het segmentatie-algoritme verschuivingen en herschikkingen. Het creëert echter ook enkele "geforceerde" segmenten, die vatbaar zijn voor verschuivingen en herschikking. Doorgaans wordt ongeveer 0,2% van de segmenten geforceerd, dus men kan verwachten dat er veel meer ruimte wordt gebruikt.

"filesys show space" biedt de compressieverhouding op basis van de logische grootte van de opgeslagen data en de schijfruimte die wordt gebruikt op het moment dat de opdracht wordt uitgevoerd.

"filesys show compression" biedt de compressieverhouding op basis van hoe elk bestand is gecomprimeerd op het moment dat het werd gemaakt.

"filesys show compression" wordt meestal gebruikt voor ondersteuning en foutopsporing. In het geval van bestandsverwijderingen, overschat "filesys show compression" de compressieverhouding.

De aanname is bijvoorbeeld dat de eerste volledige back-up 2x compressie krijgt. Een daaropvolgende volledige back-up zonder datawijzigingen krijgt een compressie van 200x. De eerste volledige back-up wordt verwijderd. "filesys show space" toont een compressieverhouding van 2x. "filesys show compression" toont nu een compressieverhouding van 200x, omdat het enige bestand dat nu bestaat een compressie van 200x kreeg toen het werd gemaakt.

In het hierboven genoemde voorbeeld wordt na de tweede back-up "filesys show space" weergegeven met een cumulatieve verhouding van ongeveer 4x. De cumulatieve verhouding zou asymptotisch verbeteren in de richting van 200x als er meer back-ups zouden worden gemaakt zonder te verwijderen.

Er zijn nog enkele andere kleine verschillen:

•  "filesys show compression" houdt geen rekening met verspilling op containerniveau, waardoor de compressieverhouding verder wordt overschat
•  "filesys show compression" houdt geen rekening met dubbele eliminatie door globale compressie, waardoor de compressieverhouding wordt onderschat
•  "filesys show compression" kan informatie per bestand of per directory bieden, terwijl "filesys show space" beperkt is tot het hele systeem
•  "filesys show compression" biedt de uitsplitsing tussen globale en lokale compressie, terwijl "filesys show space" dat niet doet

VERWIJZINGEN

• Waarom zijn de compressiesnelheden verschillend voor "filesys show space" en "vtl tape show summary"?

De compressieverhouding die wordt weergegeven in "vtl tape show summary" is bedoeld om overeen te komen met "filesys show compression /backup/vtc".

Meer in het algemeen kan aan dit VTL-commando een optioneel filter worden gegeven om een subset van tapecartridges te selecteren, en de compressie wordt verondersteld overeen te komen met "filesys show compression" op die subset van cartridges.

Vanwege een bug in de VTL UI-code is de compressie die wordt weergegeven in "vtl tape show summary" echter onjuist. Dit is een bekend probleem dat is opgelost bij release 4.5.0.0.
 

• Waarom komt "filesys show compression last 24 hours" niet overeen met de verwachting voor VTL?

Voor VTL voldoet de uitvoer van opdrachten zoals "filesys show compression last 24 hours" vaak niet aan de verwachtingen op basis van andere bronnen zoals "system show performance".

Het probleem doet zich voor als gevolg van een eigenaardigheid in "filesys show compression" (fsc). Over het algemeen toont "filesys show compression" cumulatieve statistieken in geselecteerde bestanden. De kwalificatie "last 24 hours" selecteert de bestanden die in de afgelopen 24 uur zijn bijgewerkt. De statistieken zijn nog steeds cumulatief sinds het bestand is gemaakt of voor het laatst is afgekapt tot nulgrootte. Dus als een bestand in de afgelopen 24 uur is toegevoegd, toont "filesys show compression last 24 hours" de cumulatieve statistieken vóór de afgelopen 24 uur.

In niet-VTL-omgevingen worden back-upbestanden slechts één keer geschreven, dus er is niet veel verschil tussen bijgewerkte bestanden en gemaakte bestanden. Met VTL kunnen back-ups worden toegevoegd aan bestaande tapebestanden. Beschouw bijvoorbeeld een tape met een capaciteit van 100 GB die is gevuld tot 50 GB. Als er in de afgelopen 24 uur 10 GB aan data aan deze tape is toegevoegd, wordt met "filesys show compression last 24 hours" de "Original bytes" van het bestand weergegeven die zijn geschreven op 60 GB.
 

• Hoe wordt de cumulatieve compressieverhouding berekend?

Individuele compressieverhoudingen tellen niet lineair op.

Stel dat de compressie op de eerste volledige back-up 2x is en die op de tweede volledige back-up 20x. De cumulatieve compressie is niet (2+20)/2 of 11x, maar 2/(1/2+1/20) of 3,64x.

Over het algemeen hebben lagere compressieverhoudingen meer invloed dan hogere op de cumulatieve compressieverhouding.

Stel dat de i-de back-up logische grootte si en compressieverhouding ci heeft. Vervolgens kan de cumulatieve compressieverhouding voor k back-ups als volgt worden berekend:

C = (totale logische grootte)/(totale gebruikte ruimte)
totale logische grootte = s1 + s2 + .. + SK
totale gebruikte ruimte = s1/c1 + s2/c2 + ... + SK/CK

Vaak zijn de logische maten ongeveer hetzelfde. In dat geval vereenvoudigt de bovenstaande berekening het volgende:

Als de eerste volledige back-up bijvoorbeeld 3x compressie krijgt en elke volgende volledige back-up 30x compressie en de retentieperiode 30 dagen is, ziet de gebruiker een cumulatieve compressie van 30/(1/3+29/30) of 23x.
 

• Hoe werkt Data Domain-compressie?

Deze vraag wordt in detail beantwoord in een apart KB-artikel, "Understanding Data Domain Compression" Data Domain: Data Domain compressie begrijpen
 

• Ondersteunt Data Domain multiplexing? ​​​​​​​

Meervoudige data van de back-upapplicatie leidt tot een zeer slechte globale deduplicatie. Raadpleeg voor meer informatie het gerelateerde artikel Multiplexing in back-upsoftware wordt niet ondersteund Data Domain: Multiplexing in back-upsoftware. 
 

• Waarom geeft de replica bij 1-op-1 directoryreplicatie een betere algehele compressie weer?​​​​​​​

Dit komt meestal door variaties in het niveau van dubbele segmenten die op het systeem zijn geschreven:

• De gegevens die bij de bron zijn opgeslagen, zijn eenmaal gededupliceerd ten opzichte van de eerdere gegevens die bij de bron zijn opgeslagen.
• De data die via de kabel zijn verzonden, zijn één keer gededupliceerd ten opzichte van de data die zijn opgeslagen bij de replica.
• De data die zijn opgeslagen op de replica zijn twee keer gededupliceerd, één keer wanneer de data via de kabel werden verzonden en opnieuw wanneer de ontvangen data naar de replica worden geschreven.

Aangezien het deduplicatieproces enkele duplicaten achterlaat, hebben data die meerdere keren zijn gededupliceerd minder duplicaten. De gegevens die bij de bron zijn opgeslagen en via de kabel worden verzonden, worden één keer gededupliceerd, dus ze zijn ongeveer hetzelfde, ervan uitgaande dat de gegevens die bij de bron zijn opgeslagen en de replica vergelijkbaar zijn. De data die op de replica zijn opgeslagen, worden twee keer gededupliceerd, zodat ze beter worden gecomprimeerd.

Bij het opschonen van het bestandssysteem worden de meeste duplicaten verwijderd. Daarom moet de hoeveelheid opgeslagen gegevens die daar is opgeslagen ongeveer hetzelfde zijn nadat de bron en de replica zijn opgeschoond.

• Wat is de verandering in compressie bij het gebruik van lokale compressie-instellingen voor lz, gzfast en gz?

Filesys option set compression {none | lz | gzfast | gz}
 

Waarschuwing: Voordat u het lokale compressietype wijzigt, moet het bestandssysteem worden afgesloten. Het kan dan direct opnieuw worden gestart nadat de compressieoptie is ingesteld.

Over het algemeen is de volgorde van compressie als volgt:

Het ruwe verschil is:

• lz naar gzfast geeft ~15% betere compressie en verbruikt 2x CPU
• LZ naar GZ geeft ~30% betere compressie en verbruikt 5x CPU
• GZFAST naar GZ geeft ~10-15% betere compressie

Houd er rekening mee dat het wijzigen van de lokale compressie eerst van invloed is op nieuwe gegevens die naar de DataDomain Restorer worden geschreven nadat de wijziging is aangebracht. De oude data behouden hun vorige compressie-indeling tot de volgende opschooncyclus. Bij de volgende opschooncyclus worden alle oude gegevens doorgestuurd naar het nieuwe compressieformaat. Dit zorgt ervoor dat het opschonen veel langer duurt en meer CPU in beslag neemt.

Als het CPU-systeem van de klant al bijna leeg is, met name als de klant tegelijkertijd back-up en replicatie uitvoert, kan dit de back-up en/of replicatie vertragen. Het kan zijn dat de klant expliciet wat tijd wil plannen om deze conversie uit te voeren.

Kennisreferenties:

• Migratieproblemen oplossen
• Data Domain: Data Domain compressie begrijpen