Data Domain: Rengørbar størrelse er et skøn

Der er ofte forvirring om værdien "GiB, der kan renses", der vises på et Data Domain-system, og forkerte forventninger til den mængde plads, der genvindes ved kørsel af rensning.

Det angivne "Cleanable GiB"-nummer er udelukkende et skøn, og det er ikke muligt at få en nøjagtig værdi for, hvor meget plads der vil blive genoprettet ved at køre rensning på grund af de teknologiske valg, der blev truffet under udviklingen af Data Domain-filsystemet.

Følgende er en kortfattet forklaring på, hvorfor estimater af rengørbart rum kan variere væsentligt fra det faktiske genvundne rum. Der er dog andre faktorer, der ikke er taget højde for her, hvilket kan gøre estimatet og mængden af diskplads, der virkelig frigøres, når du kører rent, til at afvige væsentligt
 

Når data indtages af Data Domain-systemet, beregnes og gemmes værdien efter komprimering som statiske data for hver fil. Værdien "Rensbar" er simpelthen summen af postkomprimeringsværdien for alle slettede filer siden sidste gang DD-rensning blev kørt til færdiggørelse.
 

Værdien Rengørbar bliver unøjagtig, hvis filsegmenterne for slettede filer er blevet brugt til at fjerne duplikering af data i andre filer, der ikke er blevet slettet. Så længe der er en enkelt fil, der henviser til et eksisterende unikt segment, vil DD-rensningsprocessen ikke tage højde for, at disse segmenter skal genvindes. Så selvom en fils post-comp blev tilføjet i tælleren "Rengørbar GiB", som om alle dens unikke segmenter var ved at blive bortskaffet, kan nogle (eller mange) muligvis ikke på grund af at blive genbrugt af andre filer.
 

Et mere detaljeret eksempel, der viser denne effekt, følger:

Antag, at du har 5 filer, føjet én efter én til et Data Domain-system, uden tidligere at have logget på dem.

Da de første 100 GB-filer indeholdt alle unikke data, er komprimeringsforholdet 1x (forudsat at den første fil ikke havde nogen redundans i selve filen). De 2.-5. filer var i stand til at deduplikere mod 1. fils data og hver af de ældre filer, efterhånden som de tilføjes, hver får stigende de-duplikering på grund af de stigende filer, som de skal de-duplikeres mod.

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

Eksempel 1. Status efter sletning af de første 3 filer fra / backup:
 

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

Hvis du kører rensning efter dette, kan du muligvis genvinde 125 i stedet for de fulde 175, der kan rengøres. Dette skyldes, at de sidste 2 filer deler segmenter med filer 1-3.  Rensning gendanner ikke de andre 50 GB plads, fordi disse segmenter stadig bruges af fil 3-5.
 

Eksempel 2: Brug samme udgangspunkt som med eksempel 1, antag at fil 1 blev slettet, derefter en hurtig kopi udført på hele /backup-mappen (dvs. alle 5 filer) og derefter sletning af filer 2-4. 

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

"Størrelse GiB" -tallet for pre-comp kommer fra (500-100) = 400 * 2 = 800, hvilket giver 500 for de 5 originale filer, trækker 100 for sletning af fil 1 giver 400 GiB.  Derefter 400 GiB ganget med 2 på grund af hurtigkopien på alle 4 resterende filer.

Bemærk, at den anvendte post-comp-plads stadig er den samme, fordi en filkopi kun tilføjer en lille mængde plads, der består af metadatamarkørerne til de originale data. Pladsforbruget er ikke ændret på trods af sletning af fil 1, fordi der ikke er kørt en "filesys clean start" (for at starte rensning). 
 

Efter rengøringen vil vi se:
 

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

Bemærk, at selvom 200 GB blev vist rengørbar, blev kun 25 GB faktisk rengjort. "GiB, der kan renses" blev vist som 200, fordi filstørrelsen "post-comp" for filer 1 til 4 tilføjede op til 200 GB.  Kun "File 1" blev fjernet, som var 100GB, men hvoraf 75GB stadig var i brug af de andre 4 filer (på grund af de-duplikering).  

Det kan virke underligt, da "File 2" til "File 4" også var blevet slettet, men husk, at selvom systemet vil vise "File 2" til "File 4" som fjernet, kunne de faktiske datasegmenter for disse filer ikke fjernes, fordi disse filer var blevet hurtigt kopieret til en anden mappe.   Først efter at alle hurtige versioner også er fjernet, kan pladsen gendannes fuldt ud ved rengøring.

Da GiB, der kan renses, blot er et "estimat" og muligvis ikke er nøjagtigt, kan det nogle gange afspejle stor eller samme størrelse som Data Domains fysiske kapacitet.

Dette kan føre til forvirring om, hvorvidt den planlagte DDFS-oprydning skal køres eller køres manuelt, hvis DDFS-pladsforbruget nærmer sig 100 % på grund af, at GiB, der kan renses, vises i nærheden, eller samme værdi som "/data: post-comp".

For at få en bedre og mere pålidelig måde at estimere mængden af diskplads, som ren ville genvinde under kørsel, startende fra DDOS 7.7.x, er det nu muligt ud fra CLI at bestemme den faktiske 'Total Cleanable-Space' næste GC på Active-niveauet vil kunne genvinde den. Dette er et resumé af CLI:
 

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

Processen vil gøre det samme som en almindelig GC, der går gennem fase 1 til 4, men springer fase 5 (kopi) over, som er den, der effektivt kopierer fremadrettede containere for at genvinde den døde diskplads. Som sådan vil det tage så lang tid som en almindelig GC tager at fuldføre rene faser 1 til 4 for at returnere en værdi, så dette er ikke noget, der skal køres regelmæssigt for at have et opdateret estimat, men kun når det er nødvendigt. Med andre ord kører "filesys cleanable-space calculate" GC i det aktive niveau og springer bare den del over, hvor den genvinder plads.

Processen kan overvåges som denne:
 

# 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

Når man er færdig, kan man få adgang til det rengørbare måleresultat:

# 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.

Så her i ovenstående eksempeltest, hvis DD GC skal køres nu, ville det frigøre 94649698202 bytes. Det er 88,1 GiB, mens estimatet rapporteret af "df" i det anvendte laboratorium DD på tidspunktet for beregningen var 41,9 GiB. Når der foretages ændringer i FS (nye sikkerhedskopier, flere sletninger, snapshots, der oprettes og udløb osv.), Går beregningen naturligvis ud.

Hvis det er nødvendigt, for at stoppe ovenstående proces nedenstående kommando kan bruges:

# 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.

Bemærk, at denne CLI kun gælder for niveauet DD Active. Der er ingen tilsvarende proces til beregning af rengørbar for en DD-cloudenhed, som har sit eget estimat, med forbehold for de samme usikkerheder som beskrevet ovenfor.