Problemen met slechte deduplicatie en compressieratio van bestanden op Data Domain Restorers (DDR's) oplossen

Data Domain Restorers (DDR's) zijn ontworpen om grote hoeveelheden logische (vooraf gecomprimeerde) data te bewaren met minimale fysieke (postcomppresse) schijfruimte. Dit wordt bereikt met behulp van:

• Deduplicatie van ingeslikte data om dubbele chunks van data te verwijderen die al op de schijf op de DDR zijn opgeslagen, waarbij alleen unieke data achterblijven
• Compressie van unieke data voordat die data fysiek naar de schijf worden geschreven.

De algehele compressieratio van data die een DDR kan opnemen, varieert vanwege verschillende factoren, zoals:

• Gebruiksscenario
• Datatypen die worden opgenomen
• Configuratie van back-upapplicatie

Indien optimaal geconfigureerd, bereiken DDR's doorgaans een totale compressieratio van 10-20x (en soms kunnen ratio's hoger worden weergegeven dan dit). Omgekeerd kan de totale compressieratio in sommige omgevingen echter lager zijn dan dit, wat kan leiden tot:

• De DDR om snel zijn bruikbare capaciteit te benutten
• Gevolgen voor back-up-, herstel- of replicatieprestaties
• Een fout van de DDR om te voldoen aan de verwachtingen van de klant

Dit artikel is bedoeld om het onderstaande te bespreken:

• Een kort overzicht van deduplicatie en compressie van data op een DDR
• De algehele compressieratio voor het systeem en afzonderlijke bestanden bepalen
• Factoren die degradatie tot de algehele compressieratio kunnen veroorzaken

Hoe kan een Data Domain Restorer nieuwe data opnemen?

• De back-upapplicatie stuurt data (dat zijn bestanden) naar de DDR.
• De DDR splitst deze bestanden op in segmenten van 4-12 Kb in grootte- elk segment wordt gezien als een 'segment'.
• De DDR genereert een unieke 'vingerafdruk' (vergelijkbaar met een checksum) voor elk segment, afhankelijk van de data in het segment.
• De vingerafdrukken van nieuw gearriveerde segmenten worden gecontroleerd op schijfindexen op de DDR om te bepalen of de DDR al een segment met dezelfde vingerafdruk heeft.
• Als de DDR al een segment met dezelfde vingerafdruk heeft, is het bijbehorende segment in de nieuw gearriveerde data een duplicaat en kan het worden verwijderd (dat is gededupliceerd).
• Zodra alle dubbele segmenten zijn verwijderd uit de nieuw gearriveerde data, blijven alleen unieke of nieuwe segmenten over.
• Deze unieke of nieuwe segmenten worden gegroepeerd in 'compressiegebieden' van 128 Kb en vervolgens gecomprimeerd (standaard met behulp van het lz-algoritme ).
• Gecomprimeerde compressiegebieden zijn verpakt in storage-eenheden van 4,5 Mb die bekend staan als 'containers' die vervolgens naar de harde schijf worden geschreven.

Hoe kan de DDR bijhouden welke segmenten een bepaald bestand vormen?

Naast deduplicatie/compressie van nieuw gearriveerde data, maakt de DDR ook een 'segment tree' voor elk opgenomen bestand. Dit is in feite een lijst met segment 'vingerafdrukken' waarover het bestand bestaat. Als de DDR het bestand later opnieuw moet lezen, wordt het volgende gedaan:

• Bepaal de locatie van de segmentstructuur van de bestanden.
• Lees de segmentstructuur voor een lijst met alle segmentvingers die deel uit maken van het bestand dat wordt gelezen.
• Gebruik op schijfindexen om de fysieke locatie (dat is container) van de data op schijf te bepalen.
• Lees de data van het fysieke segment uit de onderliggende containers op de schijf.
• Gebruik fysieke segmentdata om het bestand te reconstrueren.

Bestandssegmenten worden ook opgeslagen in 4,5 Mb-containers op schijf en vertegenwoordigen het merendeel van de bestanden 'metadata' (later in dit artikel besproken).

Hoe kan de algehele compressieratio op een DDR worden bepaald?

Het algehele gebruik van een DDR (en compressieverhouding) kan worden waargenomen met behulp van de opdracht 'filesys show space'. Bijvoorbeeld:

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


---------------- -------- -------- --------- ---- -------------- In dit geval zien we dat:

• Vooraf gecomprimeerde of logische data die op DDR worden bewaard: 115367,8 Gb
• Postcomppresse of fysieke ruimte die wordt gebruikt op DDR: 6242,4 Gb
• De totale compressieratio is 115367,8/6242,4 = 18,48x

De uitvoer van de opdracht 'filesys show compression' bevestigt de data die worden vastgehouden, ruimte die wordt gebruikt en de compressieverhouding. Bijvoorbeeld:

                   Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:*   115367.8 6242.4 - - 18,5x (94,6) <xxx OPMERKING
Geschreven:                                                                          
  Afgelopen 7 dagen 42214,7 1863,2 11,0 x 2,1 x 22,7x (95,6)
  De laatste 24 uur 4924,8 274,0 8,8x 2,0x 18,0x (94,4)
---------------- -------- --------- ----------- ---------- -------------

Overall gebruikscijfers op de DDR worden als volgt berekend:

• Totale vooraf gecomprimeerde data: De som van de vooraf gecomprimeerde (logische) grootte van alle bestanden die in het bezit zijn van de DDR.
• Totale post-gecomprimeerde data: Het aantal in gebruik 'containers' op schijf vermenigvuldigd met 4,5 Mb (de grootte van één container).
• Totale grootte postcompressed: Het aantal maximale 'containers' dat wordt gemaakt, geeft beschikbare schijfruimte op het systeem.

Statistieken over het maximumaantal in gebruikscontainers zijn beschikbaar in autosupport. Bijvoorbeeld:

Containerset 73fc tutorialsdea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <aliseerde containergrootte in bytes
...
    attrs.max_containers = 1546057 <• Maximaal mogelijke containers
attrs.free_containers = 125562 <• Momenteel gratis containers
attrs.used_containers = 1420495 <• Momenteel in gebruik zijnde containers
...

Zie dat:
 
Hoe kunnen deduplicatie- en compressieratio's voor een afzonderlijke bestands-, directory- of directorystructuur worden bepaald?

Wanneer een bestand wordt opgenomen, worden de DDR-recordsstatistieken over het bestand opgenomen, waaronder:

• Vooraf gecomprimeerde (logische) bytes
• Grootte van unieke segmenten na deduplicatie
• Grootte van unieke segmenten na deduplicatie en compressie
• Grootte van de metadata van het bestand (dat is segmentstructuur, enzovoort)

Het is mogelijk om sommige van deze statistieken te dumpen met behulp van de opdracht 'filesys show compression [path]' - bijvoorbeeld om statistieken te rapporteren voor één bestand:

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1;  bytes/storage_used: 2,9
oorspronkelijke bytes:        3242,460,364
wereldwijd gecomprimeerd:        1.113.584.070
lokaal gecomprimeerd:        1.130.871.915
metadata:            4.772.672

Als u statistieken wilt rapporteren voor een volledige directorystructuur:

SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files: 3;  bytes/storage_used: 1,4
oorspronkelijke bytes:        7.554.284.280
wereldwijd gecomprimeerd:        5.425.407.986
lokaal gecomprimeerd:        5.510.685.100
metadata:           23.263.692

Houd er echter rekening mee dat er een aantal kanttekeningen zijn bij het gebruik van deze statistieken:

• De statistieken worden gegenereerd op het moment van opname van bestanden of data, en de volgende worden niet bijgewerkt. Als gevolg van hoe een DDR werkt, kan de opname van nieuwe bestanden of het verwijderen van bestanden die verwijzen naar dezelfde data, enzovoort, veranderen hoe een bestand na verloop van tijd dedupliceert, waardoor deze statistieken verlopen.
• Bovendien kunnen bepaalde gebruiksscenario's op de DDR (zoals fastcopy van een bestand en vervolgens het verwijderen van het oorspronkelijke bestand) ertoe leiden dat deze statistieken misleidend of onjuist worden.

Als gevolg hiervan moeten deze cijfers alleen worden beschouwd als schattingen.

De vooraf gecomprimeerde bytes zijn niet noodzakelijkerwijs de vooraf gecomprimeerde/logische grootte van het bestand. In plaats daarvan is het het totale aantal bytes dat in zijn levensduur naar een bestand is geschreven. Als gevolg hiervan worden in bepaalde omgevingen bestaande bestanden meestal overschreven (zoals bestanden die gebruikmaken van de functionaliteit van de virtuele tapebibliotheek). Deze afbeelding kan groter zijn dan de logische grootte van de bijbehorende bestanden.

Kan opname van data van 'slechte kwaliteit' degradatie in de algehele compressieratio veroorzaken?

Ja - Voor een DDR om een goede algehele compressieratio van ingeslikte data te bereiken, moet deze data kunnen dedupliceren en comprimeren. Er zijn verschillende soorten data die dit kunnen voorkomen, zoals hieronder wordt beschreven:

Vooraf gecomprimeerde/vooraf versleutelde data:

Dit zijn datatypen die worden gecomprimeerd of versleuteld op het clientsysteem of door de back-upapplicatie. Dit kunnen ook applicatiespecifieke bestanden zijn die door het ontwerp worden gecomprimeerd of versleuteld (bijvoorbeeld mediabestanden) en databasebestanden die gecomprimeerd of versleuteld zijn of binaire objecten zoals mediabestanden bevatten.

Vanwege de manier waarop het compressie- of versleutelingsalgoritme werkt, zorgt een relatief kleine wijziging van de onderliggende data van een bestand ervoor dat wijzigingen in het hele bestand worden 'weggedrukt'. Een client kan bijvoorbeeld een 100 Mb versleuteld bestand bevatten waarin 10 KB wordt gewijzigd. Normaal gesproken zou het resulterende bestand identiek zijn vóór en na de wijziging, afgezien van de 10Kb-sectie die is gewijzigd. Wanneer versleuteling wordt gebruikt, hoewel slechts 10 Kb aan niet-versleutelde data vóór en na wijziging is gewijzigd, zorgt het versleutelingsalgoritme ervoor dat de volledige inhoud van het bestand wordt gewijzigd.

Wanneer dergelijke data regelmatig worden gewijzigd en regelmatig naar een DDR worden verzonden, zorgt dit 'uitgezette' effect ervoor dat elke generatie van het bestand er anders uitziet dan eerdere generaties van hetzelfde bestand. Als gevolg hiervan bevat elke generatie een unieke set segmenten (en segmentvingers) zodat de deduplicatieverhouding laag is.

Houd er ook rekening mee dat het lz-algoritme in plaats van vooraf gecomprimeerde bestanden waarschijnlijk niet in staat is om segmentdata voor compressie verder te comprimeren, zodat data niet kunnen worden gecomprimeerd voordat ze naar de schijf worden geschreven.

Als algemene richtlijn veroorzaakt precompressie/preversleuteling het volgende:

• Vooraf versleutelde data: Slechte deduplicatieratio, maar aanvaardbare compressieratio
• Vooraf gecomprimeerde data: Slechte deduplicatieratio en slechte compressieratio

Wanneer dezelfde (ongewijzigde) vooraf gecomprimeerde/vooraf versleutelde data meerdere keren worden opgenomen door een DDR, verbetert de deduplicatieratio van de data omdat, ondanks het gebruik van compressie- of versleutelingsalgoritmen, een vergelijkbare set segmenten (en segmentvingers) wordt waargenomen tijdens elke back-up.

Waar mogelijk mogen data die naar een DDR worden verzonden, niet worden versleuteld of gecomprimeerd . Dit kan nodig zijn om versleuteling of compressie uit te schakelen op de eindclient of binnen de bijbehorende back-upapplicatie.

Neem voor hulp bij het controleren, wijzigen van versleuteling of compressie-instellingen binnen een bepaalde back-up, clientapplicatie of besturingssysteem contact op met de juiste supportprovider.

Mediabestanden:

Bepaalde bestandstypen bevatten vooraf gecomprimeerde of vooraf versleutelde data. Bijvoorbeeld:

• PDF-bestanden
• Bepaalde audiobestanden (mp3, wma, ogg, enzovoort)
• Videobestanden (avi, mkv, enzovoort)
• Afbeeldingsbestanden (png, bmp, jpeg, enzovoort)
• Applicatiespecifieke bestanden (Microsoft Office, Open Office, Libre Office, enzovoort)

De data in de bestanden worden gecomprimeerd of versleuteld door de codec van het bestand en veroorzaakt daardoor dezelfde problemen wanneer ze worden opgenomen in een DDR zoals hierboven beschreven voor vooraf gecomprimeerde of vooraf versleutelde data.

Bestanden met een hoge 'unicness':

Het bereiken van een goede deduplicatieratio hangt af van het feit dat de DDR meerdere keren dezelfde set segmenten (en segmentvingervingers) ziet. Bepaalde datatypen bevatten echter alleen unieke transactionele data die naar ontwerp 'unieke' data bevatten.

Als deze bestanden naar een DDR worden verzonden, bevat elke generatie van de back-up een unieke set segmenten of segmentvingers en als gevolg hiervan ziet u een verslechterde deduplicatieratio.

Voorbeelden van dergelijke bestanden zijn:

• Database-transactielogboeken (bijvoorbeeld Oracle-archieflogboeken).
• Microsoft Exchange-transactielogboeken

De eerste back-up van een 'nieuwe' client naar een DDR kan dit probleem ook veroorzaken (omdat de data nog niet eerder door de DDR zijn waargenomen, waardoor de bijbehorende segmenten of segmentvingers in de back-up uniek zijn). Naarmate toekomstige generaties van dezelfde back-up echter naar de DDR worden verzonden, verbetert de deduplicatieratio van back-ups naarmate minder segmenten in elke nieuwe back-up uniek zijn. Hierdoor wordt verwacht dat de algehele deduplicatie- of compressieratio op een nieuw geïnstalleerde DDR die meestal nieuwe back-ups ontvangt, is verslechterd, maar na verloop van tijd beter wordt.

Kleine bestanden:

Kleine bestanden veroorzaken verschillende problemen wanneer ze naar een DDR worden geschreven. Deze omvatten:

• Metadata bloat - De DDR begint een hogere dan verwachte hoeveelheid bestandsmetadata te bevatten in vergelijking met fysieke data.
• Slecht containergebruik - Door het ontwerp (vanwege de Data Domain Stream Informed Segment Layout of SISL-architectuur - buiten het bereik van dit document) bevat een 4,5 Mb-container op schijf slechts data van één bestand. Als gevolg hiervan wordt er bijvoorbeeld een back-up gemaakt van een enkel 10 Kb-bestand, waardoor ten minste één volledige 4,5 Mb-container voor dat bestand wordt geschreven. Dit kan betekenen dat de DDR voor dergelijke bestanden aanzienlijk meer postcomprimeerde (fysieke) ruimte gebruikt dan de bijbehorende hoeveelheid vooraf gecomprimeerde (logische) data waarvan een back-up wordt gemaakt, wat op zijn beurt een negatieve algehele compressieratio veroorzaakt.
• Slechte deduplicatieratio - Bestanden die kleiner zijn dan 4 Kb (de minimale ondersteunde segmentgrootte op een DDR) bestaan uit één segment dat is gestoffeerd tot 4 Kb. Dergelijke segmenten zijn niet gededupliceerd, maar worden in plaats daarvan rechtstreeks naar de schijf geschreven. Dit kan ertoe leiden dat de DDR meerdere kopieën van hetzelfde segment heeft (gezien als dubbele segmenten).
• Slechte back-up-, herstel- of schone prestaties - Er zijn grote overheads tijdens back-up, herstel of opschoning bij het verplaatsen van het ene bestand naar het andere (omdat de context van metadata die wordt gebruikt moet worden overgeschakeld).

Zie dat:

• De impact op het opschonen van prestaties bij het gebruik van kleine bestanden is tot op zekere hoogte verminderd door de introductie van fysieke reiniging of garbage collection in DDOS 5.5 en hoger.
• Opschoning probeert slecht containergebruik 'ongedaan te maken' door data van containers met een laag gebruik te verzamelen in meer nauw verpakte containers tijdens de kopieerfase.
• Opschoning probeert tijdens de kopieerfase overmatige segmenten te verwijderen.

Ondanks het bovenstaande moet het gebruik van grote aantallen kleine bestanden of workloads die voornamelijk uit kleine bestanden bestaan, worden vermeden. Het is beter om grote aantallen kleine bestanden te combineren in een enkel niet-gecomprimeerd/niet-versleuteld archief voordat u een back-up maakt, dan de kleine bestanden naar de DDR te verzenden in hun eigen staat. Het is bijvoorbeeld veel beter om een back-up te maken van een enkel 10 Gb-bestand met 1048576 afzonderlijke 10 Kb-bestanden dan alle 1048576 bestanden afzonderlijk.

Overmatige multiplexing door back-upapplicaties:

Back-upapplicaties kunnen worden geconfigureerd voor het uitvoeren van multiplexing van data over streams die naar het back-upapparaat worden verzonden. Dit zijn data van invoerstromen (dat zijn verschillende clients) die in één stream naar het back-upapparaat worden verzonden. Deze functionaliteit wordt vooral gebruikt bij het schrijven naar fysieke tapeapparaten als:

• Een fysiek tapeapparaat kan slechts één inkomende schrijfstroom ondersteunen.
• De back-upapplicatie moet voldoende doorvoer naar het tapeapparaat behouden om te voorkomen dat tape wordt gestart, gestopt of terugspoelen (ook wel bekend als tapes- of knippering). Dit is eenvoudiger als de stroom naar het tapeapparaat data bevat die van meer dan één client worden gelezen.

In het geval van een DDR leidt dit er echter toe dat één bestand op de DDR data van meerdere clients bevat die in willekeurige volgorde of segmentgroottes zijn interleaved. Dit kan leiden tot een verminderde deduplicatieratio omdat de DDR mogelijk geen dubbele segmenten van elke generatie back-up van een bepaalde client nauwkeurig kan zien. Over het algemeen geldt dat hoe kleiner de multiplexing-granulariteit, hoe slechter de impact op deduplicatieratio.

Bovendien kunnen de herstelprestaties slecht zijn om bepaalde clientdata te herstellen, moet de DDR veel bestanden of containers lezen waarbij de meeste data in de bestanden of containers overbodig zijn, omdat het betrekking heeft op back-ups van andere clients.

Back-upapplicaties mogen geen multiplexing gebruiken bij het schrijven naar een DDR, omdat DDI's een hoger aantal binnenkomende stroom ondersteunen dan fysieke tapeapparaten waarbij elke stream op een variabele snelheid kan schrijven. Als gevolg hiervan moet multiplexing door back-upapplicaties worden uitgeschakeld. Als de back-upprestaties worden beïnvloed na het uitschakelen van multiplexing, dan:

• Back-upapplicaties met CIFS, NFS of OST (DDBoost) moeten hun aantal schrijfstreams verhogen (zodat er meer bestanden parallel kunnen worden geschreven op de DDR).
• Omgevingen met VTL moeten extra schijven toevoegen aan de DDR omdat elke schijf ondersteuning biedt voor een extra parallelle schrijfstroom.

Neem contact op met uw gecontracteerde supportprovider als u hulp nodig hebt bij het uitschakelen van multiplexing of als u de aanbevolen multiplexing-configuratie voor een specifieke back-upapplicatie wilt bespreken.

Back-upapplicaties die overmatige tape-markeringen plaatsen:

Sommige back-upapplicaties kunnen herhaalde datastructuren in een back-upstroom plaatsen die bekend staat als 'markeringen'. Labels vertegenwoordigen geen fysieke data binnen de back-up, maar worden door de back-upapplicatie gebruikt als een indexerings- of positioneel systeem.

In sommige gevallen kan het opnemen van markeringen in een back-upstroom de deduplicatieratio verlagen, bijvoorbeeld:

• In de eerste generatie van een back-up was er 12 Kb aan data die aaneengesloten was- dit werd door de DDR herkend als één segment.
• In de tweede generatie van de back-up wordt dezelfde 12 Kb aan data echter gesplitst door het opnemen van een back-upmarkering die kan worden weergegeven door 6 Kb aan data, back-upmarkering, 6 Kb aan data.
• Als gevolg hiervan komen de segmenten die zijn gemaakt tijdens de tweede generatie van de back-up niet overeen met de segmenten die zijn gegenereerd tijdens de eerste generatie van de back-up, waardoor ze niet correct dedupliceren.

Hoe dichter de markeringen in de spaties staan, hoe slechter de impact op deduplicatieratio (een back-uptoepassing die bijvoorbeeld elke 32 Kb markeert, veroorzaakt meer problemen dan een back-upapplicatie die elke 1 Mb aan penwijzers plaatst).

Om dit probleem te voorkomen, maakt de DDR gebruik van markeerherkenningstechnologie waarmee:

• Back-upservers worden transparant verwijderd uit de back-upstroom tijdens het opnemen van de back-up.
• Back-upservers die tijdens het terugzetten van de back-up in de back-upstroom moeten worden teruggezet

Dit helpt bij het voorkomen van fragmentatie van data of segmenten door back-upmarkers en verbetert de deduplicatieratio van de bijbehorende back-ups.

Om optimaal te profiteren van deze technologie, is het echter belangrijk dat de DDR de markeringen die in back-upstreams worden geplaatst, correct herkent. De DDR zoekt naar markeringen, afhankelijk van de instelling van de optie 'markeertype', bijvoorbeeld:

SE@DDVE60_JF## filesys-optie toont
optiewaarde
-------------------------------- --------
...
Auto van het type
markeermarkering ...


-------------------------------- -------- Dit moet echter worden ingesteld op 'auto', omdat hierdoor de DDR automatisch overeenkomt met de meest voorkomende markeertypen. Als het systeem data inneemt van slechts één back-upapplicatie die wel markeringen invoegt, kan er een prestatievoordeel zijn bij het specificeren van een specifiek markeertype, namelijk:

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

Zie dat:

• De prestaties van het selecteren van een specifiek markeertype zijn waarschijnlijk minimaal.
• Het selecteren van een onjuist markeertype kan leiden tot aanzienlijke extra degradatie van de back-up- of herstelprestaties en deduplicatieratio.

Als gevolg hiervan raadt Data Domain over het algemeen aan om het markeringstype ingesteld te laten op 'auto'. Neem voor meer advies over het wijzigen van het markeertype contact op met uw gecontracteerde supportprovider.

Voor systemen die data opnemen van applicaties die back-upmarkers gebruiken, maar die niet worden herkend door geautomatiseerde markeermarkeringsverwerkingstechnologie (zoals producten van BridgeHead-software), neemt u contact op met uw gecontracteerde supportprovider die vervolgens kan samenwerken met Data Domain-support om de vereiste instellingen op de DDR te bepalen om de niet-standaardmarkering te detecteren.

Indicaties van 'slechte kwaliteit' data die worden ontvangen door een DDR:

De volgende tabel bevat de verwachte deduplicatie- en compressieratio's voor de verschillende datatypen die hierboven worden vermeld. Deze lijst is niet uitputtend en er kan natuurlijk enige variatie zijn in de exacte cijfers die op een bepaald systeem worden waargenomen als gevolg van workload of data die door de DDR worden opgenomen:
 

Wereldwijde compressie	Lokale compressie	Waarschijnlijke oorzaak
Laag (1x - 4x)	Laag (1x - 1,5x)	Vooraf gecomprimeerde of versleutelde data
Laag (1x - 2x)	Hoog (>2x)	Unieke maar gecomprimeerde data, zoals databasearchieflogboeken
Laag (2x - 5x)	Hoog (>1,5x)	Markeringen die niet worden gedetecteerd of een hoge datawijzigingssnelheid of stream multiplexing.
Hoog (>10x)	Laag (<1,5x)	Back-ups van dezelfde gecomprimeerde of versleutelde data. Dit komt niet vaak voor.

Zijn er bepaalde factoren op een DDR die van invloed kunnen zijn op de algehele deduplicatieratio?

Ja - Er zijn verschillende factoren die ertoe kunnen leiden dat oude/superlaagse data op schijf op een DDR worden bewaard, wat leidt tot een toename van postcomprimeerde (fysieke) schijfruimte en een daling van de algehele compressieratio. Dergelijke factoren worden hieronder besproken.

Een fout bij het regelmatig opschonen van het bestandssysteem:

Het opschonen van het bestandssysteem is de enige manier om fysiek oude/superlaagse data op schijf te verwijderen die niet langer worden vermeld door bestanden op de DDR. Als gevolg hiervan kan een gebruiker verschillende bestanden van het systeem verwijderen (waardoor een daling van het vooraf gecomprimeerde gebruik wordt veroorzaakt), maar niet schoon worden uitgevoerd (waarbij postcompressed/fysiek gebruik hoog blijft). Dit zou leiden tot een daling van de algehele compressieratio.

Data Domain raadt aan om de opschoning regelmatig als volgt uit te voeren:

• Normale DDR: Eenmaal per week
• DDR met uitgebreide retentie: Eenmaal per twee weken

Clean mag niet meer dan eenmaal per week worden uitgevoerd, omdat dit problemen kan veroorzaken met fragmentatie van data op de schijf die zich als slechte herstel-/replicatieprestaties manifesteert.

Overmatige oude snapshots op het systeem:

DDR's kunnen mtree-snapshots maken die de inhoud van een mtree weergeven op het moment dat de snapshot werd gemaakt. Houd er echter rekening mee dat het achter laten van oude snapshots op een systeem kan leiden tot een toename van het postcomppresse/fysieke gebruik, wat een daling van de algehele compressieratio veroorzaakt. Bijvoorbeeld:

• Er bestaat een mtree met veel bestanden (dus het vooraf gecomprimeerde gebruik is hoog).
• Er wordt een snapshot van de mtree gemaakt.
• Veel bestanden worden verwijderd (waardoor het vooraf gecomprimeerde gebruik afneemt).
• Het opschonen van het bestandssysteem wordt uitgevoerd. Houd er echter rekening mee dat er minimale ruimte op de harde schijf wordt vrijgemaakt omdat een kopie van de verwijderde bestanden in de mtree-snapshot blijft staan, wat betekent dat data waarnaar wordt verwezen door deze bestanden niet van de schijf kunnen worden verwijderd.
• Als gevolg hiervan blijft het postcomppresse/fysieke gebruik hoog

Data Domain raadt aan dat als mtree-snapshots worden gebruikt (bijvoorbeeld voor herstel na accidentele dataverwijdering) ze worden beheerd met behulp van geautomatiseerde snapshotschema's, zodat snapshots regelmatig worden gemaakt met een gedefinieerde verloopperiode (de hoeveelheid tijd voordat de snapshot automatisch wordt verwijderd). Bovendien moet de vervaldatum zo kort mogelijk zijn (dit kan natuurlijk afhankelijk zijn van het gebruiksscenario van de snapshots of het beschermingsniveau dat deze snapshots bieden). Dit voorkomt het opbouwen van oude snapshots met een lange vervaldatum.

Meer informatie over het werken met snapshots en snapshotschema's is beschikbaar in het volgende artikel: Data Domain - Snapshotschema's

beherenBuitensporige replicatievertraging:

Native Data Domain replicatie maakt gebruik van een replicatielogboek of mtree-snapshots (afhankelijk van het replicatietype) om bij te houden welke bestanden of data in behandeling zijn voor replicatie naar een externe DDR. Replicatievertraging is het concept van de replica die achterloopt op wijzigingen in de bron-DDR. Dit kan worden veroorzaakt door verschillende factoren, waaronder:

• Replicatiecontexten worden uitgeschakeld
• Onvoldoende netwerkbandbreedte tussen DDR's
• Vaak wordt de verbinding met het netwerk verbroken.

Grote replicatievertraging kan ertoe leiden dat het replicatielogboek verwijzingen blijft bevatten naar bestanden die zijn verwijderd op de bron-DDR of oude of verouderde mtree-snapshots op bron- en doel-DDR's. Zoals hierboven beschreven, kunnen data waarnaar wordt verwezen door deze snapshots (of het replicatielogboek) niet fysiek worden verwijderd van de schijf op de DDR, zelfs niet als de bijbehorende bestanden uit het systeem zijn verwijderd. Dit kan ertoe leiden dat postcomppressed of fysiek gebruik van de DDR toeneemt, waardoor de deduplicatieratio wordt verlaagd.

Als DDR's te maken hebben met een hoog gebruik en dit waarschijnlijk het gevolg is van replicatievertraging, neem dan contact op met uw gecontracteerde supportprovider voor verdere hulp.

Zijn er configuratiewijzigingen of bepaalde factoren op een DDR die de algehele compressieratio kunnen verhogen?

Ja - als u de problemen verwijdert of aanpakt die eerder in dit document zijn besproken, zou een DDR in de loop van de tijd een verbetering van de algehele compressieratio moeten kunnen weergeven. Er zijn ook verschillende factoren of werkbelastingen op een DDR die kunnen leiden tot een toename van deduplicatieratio. Hierbij gaat het over het algemeen om:

• Vermindering van de hoeveelheid ruimte op de harde schijf die wordt gebruikt door bestanden op de DDR (bijvoorbeeld het verhogen van de agressiviteit van het compressiealgoritme dat door de DDR wordt gebruikt)
• Plotseling de hoeveelheid vooraf gecomprimeerde (logische) data op de DDR verhogen zonder een overeenkomstige toename van het postcomppresse/fysieke gebruik

Wijziging van compressiealgoritme:

DDR's comprimeren standaard data die naar de schijf worden geschreven met het lz-algoritme . Zoals eerder vermeld, wordt lz gebruikt omdat het relatief lage overheads heeft wat betreft CPU die nodig is voor compressie of decompressie, maar redelijke effectiviteit toont bij het verminderen van de datagrootte.

Het is mogelijk om de agressiviteit van het compressiealgoritme te verhogen om verdere besparingen op het gebruik van postcomppressed of harde schijven te bieden (en zo de algehele compressieratio te verbeteren). Ondersteunde compressiealgoritme's, in volgorde van effectiviteit (van laag naar hoog), zijn als volgt:

• Lz
• gzfast
• Gz

Een algemene vergelijking van elk algoritme is als volgt:

• lz in vergelijking met gzfast biedt ~15% betere compressie en verbruikt 2x CPU.
• lz in vergelijking met gz biedt ~30% betere compressie en verbruikt 5x CPU.
• gzfast in vergelijking met gz biedt ~10-15% betere compressie.

Het is ook mogelijk om compressie volledig uit te schakelen (geef een algoritme van geen op), maar dit wordt niet ondersteund voor gebruik op klantsystemen en is alleen voor interne tests.

Volgens de bovenstaande tabel, hoe agressiever het compressiealgoritme, hoe meer CPU nodig is tijdens compressie of decompressie van data. Hierdoor moeten wijzigingen in een agressiever algoritme alleen worden aangebracht op systemen die licht worden geladen onder normale workloads. Het wijzigen van het algoritme op zwaar belaste systemen kan leiden tot extreme degradatie in back-up- of herstelprestaties en mogelijke problemen met het bestandssysteem of opnieuw opstarten (wat een storing van de DDR veroorzaakt).

Raadpleeg het volgende artikel voor meer informatie over het wijzigen van het compressietype: Impact van data domain-systeem- en reinigingsprestaties bij het converteren naar GZ-compressie

Vanwege de mogelijke gevolgen van het wijzigen van het compressiealgoritme, is het raadzaam dat klanten die dit willen doen, contact opnemen met hun gecontracteerde supportprovider om de wijziging verder te bespreken voordat u verdergaat.

Gebruik van file system fastcopy:

DDR's staan het gebruik van de opdracht 'file system fastcopy' toe om snel een bestand (of mapstructuur) te kopiëren. Deze functionaliteit maakt een bestand door de metadata van een bestaand bestand (of groep bestanden) te klonen, zodat de nieuwe bestanden niet fysiek zijn verbonden met het oorspronkelijke bestand, maar exact dezelfde data op de schijf verwijzen als het oorspronkelijke bestand. Dit betekent dat het nieuwe bestand, ongeacht de grootte van het oorspronkelijke bestand, weinig ruimte op de schijf verbruikt (omdat het perfect dedupliceert ten opzichte van bestaande data).

Het resultaat van dit gedrag is dat wanneer fastcopy van het bestandssysteem wordt gebruikt, de vooraf gecomprimeerde (logische) grootte van data op de DDR snel toeneemt, maar het postcomppresse/fysieke gebruik van de DDR statisch blijft.

De volgende DDR heeft bijvoorbeeld het volgende gebruik (wat de totale compressieratio van ~1,8x aangeeft):

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% -
---------------- -------- -------- --------- ---- --------------

Het bevat een groot bestand (/data/col1/backup/testfile):

!!! DDVE60_JF UW DATA IN GEVAAR !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root root 3221225472 29 juli 04:20 /data/col1/backup/testfile

Het bestand wordt meerdere keren fastcopied:

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

Dit zorgt ervoor dat het vooraf gecomprimeerde gebruik toeneemt voor weinig verandering in postcomppressed gebruik:

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

De DDR toont nu de totale compressieratio van ~3,1x.

Zoals hierboven vermeld, tonen de compressiestatistieken van de kopieën aan dat ze perfect dedupliceren:

sysadmin@DDVE60_JF# filesys tonen compressie /data/col1/backup/testfile_copy1
Totale bestanden: 1;  bytes/storage_used: 21331976.1
Oorspronkelijke bytes:        3242,460,364
wereldwijd gecomprimeerd:                    0
Lokaal gecomprimeerd:                    0
Meta-data:                  152

Fastcopy-functionaliteit kan niet worden gebruikt om de algehele compressieratio te verbeteren door het fysieke gebruik van de DDR te verminderen, maar dit kan de oorzaak zijn van een hoge algehele compressieratio (met name in omgevingen die veel gebruik maken van fastcopy zoals Avamar 6.x).