Data Domain: Wisbare grootte is een schatting

Er bestaat vaak verwarring over de op te schonen GiB-waarde die wordt weergegeven op een Data Domain-systeem en onjuiste verwachtingen over de hoeveelheid ruimte die wordt hersteld bij het uitvoeren van een opschoonbewerking.

Het opgegeven getal "Opschoonbare GiB" is slechts een schatting, en het is niet mogelijk om een nauwkeurige waarde te krijgen voor de hoeveelheid ruimte die zal worden vrijgemaakt door het uitvoeren van opschoonbewerking, vanwege de technologische keuzes die zijn gemaakt bij het ontwikkelen van het Data Domain bestandssysteem.

Hieronder volgt een beknopte uitleg waarom schattingen van reinigbare ruimte aanzienlijk kunnen afwijken van de daadwerkelijk teruggewonnen ruimte. Er zijn echter andere factoren waarmee hier geen rekening wordt gehouden, waardoor de schatting en de hoeveelheid schijfruimte die echt vrijkomt bij het uitvoeren van een schone batterij aanzienlijk kunnen verschillen
 

Wanneer data worden opgenomen door het Data Domain-systeem, wordt de waarde na de compressie berekend en opgeslagen als statische data voor elk bestand. De waarde "Cleanable" is gewoon de som van de post-compressiewaarde voor alle verwijderde bestanden sinds de laatste keer dat DD clean is uitgevoerd tot voltooiing.
 

De waarde Opschoonbaar wordt onnauwkeurig als de bestandssegmenten voor verwijderde bestanden zijn gebruikt bij het dedupliceren van gegevens in andere bestanden die niet zijn verwijderd. Zolang er één bestand is dat verwijst naar een bestaand uniek segment, worden die segmenten niet teruggevorderd door het DD-opschoonproces. Dus zelfs als de post-comp van een bestand is toegevoegd in de "Cleanable GiB"-teller alsof alle unieke segmenten op het punt staan te worden verwijderd, is het mogelijk dat sommige (of veel) dat niet doen omdat ze door andere bestanden worden hergebruikt.
 

Een gedetailleerder voorbeeld van dit effect volgt:

Stel dat u 5 bestanden hebt, één voor één toegevoegd aan een Data Domain systeem, zonder dat er eerder andere data op staan.

Aangezien de eerste bestanden van 100 GB alle unieke gegevens bevatten, is de compressieverhouding 1x (ervan uitgaande dat het eerste bestand geen redundantie had in het bestand zelf). De 2e-5e bestanden waren in staat om te deduperen tegen de gegevens van het 1e bestand en elk van de oudere bestanden wanneer ze werden toegevoegd, waarbij elk een toenemende deduplicatie kreeg vanwege de toenemende bestanden waartegen moest worden gededupliceerd.

File 1: precomp: 100 GB postcomp: 100 GB compression ratio: 1x
File 2: precomp: 100 GB postcomp:  50 GB compression ratio: 2x
File 3: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 4: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 5: precomp: 100 GB postcomp:   1 GB compression ratio: 100x

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         500           -      -                -
/backup: post-comp      1000         201         799    20%                0
----------------   ---------   ---------   ---------   ----   --------------

Voorbeeld 1. Status na het verwijderen van de eerste 3 bestanden uit /backup :
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         200           -      -                -
/backup: post-comp      1000         201         799    20%              175
----------------   ---------   ---------   ---------   ----   --------------

Als u hierna Cleaning uitvoert, kunt u mogelijk 125 terugwinnen in plaats van de volledige 175 cleanable. Dit komt door het feit dat de laatste 2 bestanden segmenten delen met bestanden 1-3.  De overige 50 GB aan ruimte wordt niet hersteld omdat deze segmenten nog steeds in gebruik zijn door bestanden 3-5.
 

Voorbeeld 2: Met hetzelfde uitgangspunt als bij voorbeeld 1, ga je ervan uit dat bestand 1 is verwijderd, vervolgens wordt een fastcopy uitgevoerd op de hele /backup-map (d.w.z. alle 5 bestanden), en vervolgens worden bestanden 2-4 verwijderd. 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         201         799    20%              200
----------------   ---------   ---------   ---------   ----   --------------

Het "Size GiB"-cijfer voor pre-comp komt van (500-100) = 400 * 2 = 800, wat 500 oplevert voor de 5 originele bestanden, 100 aftrekken voor het verwijderen van bestand 1 geeft 400 GiB.  Vervolgens wordt 400 GiB vermenigvuldigd met 2 vanwege de fastcopy op alle 4 de resterende bestanden.

Houd er rekening mee dat de gebruikte ruimte na de compositie nog steeds hetzelfde is, omdat een bestandskopie slechts een kleine hoeveelheid ruimte toevoegt, bestaande uit de metadatawijzers aan de oorspronkelijke gegevens. Het ruimtegebruik is niet veranderd ondanks het verwijderen van bestand 1 omdat er geen "filesys clean start" is uitgevoerd (om het opschonen te starten). 
 

Na de schoonmaak zullen we zien:
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         176         824    18%                0
----------------   ---------   ---------   ---------   ----   --------------

Houd er rekening mee dat hoewel 200 GB kon worden opgeschoond, slechts 25 GB daadwerkelijk is opgeschoond. De "Cleanable GiB" werd weergegeven als 200 omdat de "post-comp" bestandsgrootte van de bestanden 1 t/m 4 bij elkaar opgeteld 200 GB bedroeg.  Alleen "Bestand 1" werd verwijderd dat 100 GB was, maar waarvan 75 GB nog steeds in gebruik was door de andere 4 bestanden (vanwege deduplicatie).  

Dat lijkt misschien vreemd, aangezien "Bestand 2" tot en met "Bestand 4" ook waren verwijderd, maar onthoud dat hoewel het systeem "Bestand 2" tot en met "Bestand 4" als verwijderd weergeeft, de werkelijke gegevenssegmenten voor die bestanden niet konden worden verwijderd omdat die bestanden naar een andere map waren gekopieerd.   Pas nadat alle fastcopy-versies ook zijn verwijderd, kan de ruimte volledig worden hersteld door op te schonen.

Aangezien wisbare GiB slechts een 'schatting' is en mogelijk niet nauwkeurig is, kan het zelfs soms een grote of even grote fysieke capaciteit van Data Domain weergeven.

Dit kan leiden tot verwarring over de vraag of de geplande DDFS-opschoning moet worden uitgevoerd of handmatig moet worden uitgevoerd als het gebruik van de DDFS-ruimte bijna 100% is omdat wisbare GiB in de buurt of dezelfde waarde wordt weergegeven als "/data: post-comp".

Om een betere en betrouwbaardere manier te hebben om te schatten hoeveel schijfruimte er zou worden opgeschoond tijdens het uitvoeren, is het vanaf DDOS 7.7.x nu mogelijk om aan de hand van de CLI de werkelijke 'Totaal opschoonbare ruimte' te bepalen die de volgende GC op de Active-laag kan vrijmaken. Dit is een samenvatting van de CLI :
 

# filesys cleanable-space calculate
Cleanable space calculation started. Use 'filesys cleanable-space watch' to monitor progress.

Het proces zal hetzelfde doen als een gewone GC, waarbij fase 1 tot en met 4 wordt doorlopen, maar fase 5 (kopie) wordt overgeslagen, wat de fase is die effectief voorwaartse containers kopieert om de dode schijfruimte terug te winnen. Als zodanig duurt het net zo lang als een gewone GC duurt om schone fasen 1 tot en met 4 te voltooien om een waarde te retourneren, dus dit is niet iets dat regelmatig moet worden uitgevoerd voor een bijgewerkte schatting, maar alleen wanneer dat nodig is. Met andere woorden, "filesys cleanable-space calculate" zal GC uitvoeren in de Active-laag, waarbij alleen het gedeelte wordt overgeslagen waarin het ruimte vrijmaakt.

Het proces kan als volgt worden bewaakt:
 

# filesys cleanable-space watch
Beginning 'filesys cleanable-space calculation' monitoring.  Use Control-C to stop monitoring.

Cleaning: phase 1 of 4 (pre-merge)
  100.0% complete, 96233 GiB free; time: phase  0:02:07, total  0:02:07

Cleaning: phase 2 of 4 (pre-analysis)
  100.0% complete, 96233 GiB free; time: phase  0:06:51, total  0:08:59

Cleaning: phase 3 of 4 (pre-enumeration)
  100.0% complete, 96233 GiB free; time: phase  0:00:20, total  0:09:20

Cleaning: phase 4 of 4 (pre-select)
  100.0% complete, 96233 GiB free; time: phase  0:00:25, total  0:09:46

Eenmaal voltooid, heeft men toegang tot het reinigbare meetresultaat:

# filesys cleanable-space status

Cleanable space on active tier is 94649698202 bytes. Last calculated on 2023/08/25 03:29:51
Cleanable space calculation finished at 2023/08/25 03:29:51.

Als hier in de bovenstaande voorbeeldtest de DD GC nu moet worden uitgevoerd, komen er 94649698202 bytes vrij. Dat is 88,1 GiB, terwijl op het moment van de berekening de schatting gerapporteerd door "df" in het gebruikte lab DD 41,9 GiB was. Als er wijzigingen worden aangebracht in de FS (nieuwe back-ups, meer verwijderingen, snapshots die worden gemaakt en verlopen, enz.), gaat de berekening natuurlijk af.

Indien nodig, om het bovenstaande proces te stoppen kan de opdracht worden gebruikt:

# filesys cleanable-space stop

The 'filesys cleanable-space stop' command stops calculating cleanable space in the system.
Are you sure? (yes|no) [no]: yes

ok, proceeding.

# filesys cleanable-space status
Cleanable space on active tier is 2607064 bytes. Last calculated on 2021/06/27 23:23:05
Cleanable space calculation started at 2021/06/27 23:27:58 and was aborted at 2021/06/27 23:28:19.
Cleaning was aborted by user.

Opmerking: deze CLI is alleen van toepassing op de DD Active-laag. Er is geen gelijkwaardig proces om de wisbare te berekenen voor een DD-cloudeenheid, die een eigen schatting heeft, onderhevig aan dezelfde onzekerheden als hierboven beschreven.