Data Domain: La dimensione pulibile è una stima

Spesso c è confusione sul valore "Cleanable GiB" presentato su un sistema Data Domain e aspettative errate sulla quantità di spazio che verrà ripristinata dopo l'esecuzione della pulizia.

Il numero di "GiB pulibili" fornito è puramente una stima e non è possibile ottenere un valore preciso della quantità di spazio che verrà recuperata eseguendo la pulizia, a causa delle scelte tecnologiche effettuate durante lo sviluppo del file system di Data Domain.

Di seguito è riportata una breve spiegazione del motivo per cui le stime dello spazio pulibile possono variare notevolmente rispetto allo spazio effettivamente recuperato. Tuttavia, vi sono altri fattori non considerati in questa sede, che potrebbero differire notevolmente tra le stime e la quantità di spazio su disco realmente liberato dopo l'esecuzione della pulizia
 

Quando i dati vengono acquisiti dal sistema Data Domain, il valore di post-compressione viene calcolato e archiviato come dati statici per ogni file. Il valore "Cleanable" è semplicemente la somma del valore di post-compressione per tutti i file eliminati dall'ultima esecuzione di DD Clean fino al completamento.
 

Il valore Cleanable diventa impreciso se i segmenti di file per i file eliminati sono stati utilizzati per deduplicare i dati in altri file che non sono stati eliminati. Finché è presente un singolo file che fa riferimento a un segmento univoco esistente, il processo di pulizia DD non considererà tali segmenti per il recupero. Quindi, anche se la post-compressione di un file è stata aggiunta nel contatore "GiB pulibili" come se tutti i suoi segmenti univoci stessero per essere eliminati, alcuni (o molti) potrebbero non esserlo perché riutilizzati da altri file.
 

Di seguito è riportato un esempio più dettagliato che mostra questo effetto:

Si supponga di disporre di 5 file, aggiunti uno alla volta a un sistema Data Domain, senza altri dati precedentemente inclusi.

Poiché i primi file da 100 GB contenevano tutti dati univoci, il suo rapporto di compressione è 1x (supponendo che il primo file non avesse alcuna ridondanza all'interno del file stesso). I file dal 2° al 5° sono stati in grado di eseguire la deduplica rispetto ai dati del primo file e a ciascuno dei file meno recenti man mano che venivano aggiunti, ottenendo una deduplica crescente a causa dell'aumento dei file su cui deduplicare.

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

Esempio 1. Stato dopo l'eliminazione dei primi 3 file da /backup :
 

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

Se si esegue Cleaning dopo questa operazione, potrebbe essere possibile recuperare 125 invece dei 175 pulibili completi. Ciò è dovuto al fatto che gli ultimi 2 file condividono segmenti con i file 1-3.  La pulizia non recupererà gli altri 50 GB di spazio perché tali segmenti sono ancora in uso dai file 3-5.
 

Esempio 2: Utilizzando lo stesso punto di partenza dell'esempio 1, si supponga che il file 1 sia stato eliminato, quindi venga eseguita una copia veloce sull'intera cartella /backup (cioè tutti e 5 i file), quindi l'eliminazione dei file 2-4. 

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

La cifra "Size GiB" per la pre-compressione proviene da (500-100)=400*2=800, dando 500 per i 5 file originali, sottraendo 100 per eliminare il file 1 si ottengono 400 GiB.  Quindi, 400 GiB moltiplicati per 2 a causa della copia rapida su tutti e 4 i file rimanenti.

Si noti che lo spazio post-compressione utilizzato è sempre lo stesso perché una copia del file aggiunge solo una piccola quantità di spazio, costituita dai puntatori dei metadati ai dati originali. L'utilizzo dello spazio non è cambiato nonostante l'eliminazione del File 1 perché non è stato eseguito un "filesys clean start" (per avviare la pulizia). 
 

Dopo il Clean vedremo:
 

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

Si noti che anche se 200 GB sono stati mostrati pulibili, solo 25 GB sono stati effettivamente puliti. Il "GiB pulibile" era 200 perché la dimensione del file "post-compressione" dei file da 1 a 4 ammontava a 200 GB.  È stato rimosso solo il "File 1", che era di 100 GB, ma 75 GB dei quali erano ancora in uso dagli altri 4 file (a causa della deduplica).  

Può sembrare strano, dal momento che anche "File 2" fino a "File 4" sono stati eliminati, ma ricorda che anche se il sistema mostrerà "File 2" tramite "File 4" come rimossi, i segmenti di dati effettivi per quei file non possono essere rimossi perché quei file sono stati copiati velocemente in un'altra cartella.   Solo dopo aver rimosso anche tutte le versioni fastcopy è possibile recuperare completamente lo spazio attraverso la pulizia.

Poiché i GiB pulibili sono solo una "stima" e potrebbero non essere accurate, talvolta potrebbero persino riflettere dimensioni grandi o uguali alla capacità fisica di Data Domain.

Ciò potrebbe generare confusione nell'opportunità di consentire o manuale la pulizia DDFS pianificata se l'utilizzo dello spazio DDFS è prossimo al 100% a causa del fatto che GiB pulibili mostra un valore vicino o uguale a "/data: post-comp".

Per disporre di un modo migliore e più affidabile per stimare la quantità di spazio su disco che la pulizia recupererebbe durante l'esecuzione, a partire da DDOS 7.7.x è ora possibile determinare dalla CLI lo "spazio totale pulibile" effettivo che il GC successivo sul tier attivo sarà in grado di recuperare. Di seguito è riportato un riepilogo della CLI:
 

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

Il processo eseguirà la stessa operazione di un GC normale, passando attraverso le fasi da 1 a 4, ma ignorando la fase 5 (copia), che è quella che copierebbe efficacemente i container di inoltro per recuperare lo spazio su disco inattivo. Di conseguenza, ci vorrà tutto il tempo necessario a un GC regolare per completare le fasi di pulizia da 1 a 4 per restituire un valore, quindi questo non è qualcosa da eseguire regolarmente per avere una stima aggiornata, ma solo quando necessario. In altre parole, "filesys cleanable-space calculate" eseguirà GC nel tier attivo saltando la parte in cui recupera spazio.

Il processo può essere monitorato in questo modo:
 

# 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

Una volta completato, è possibile accedere al risultato della misurazione pulibile:

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

Nel test di esempio precedente, se il GC DD deve essere eseguito ora, libererà 94649698202 byte. Si tratta di 88,1 GiB, mentre al momento del calcolo, la stima riportata da "df" nel DD di laboratorio utilizzato era di 41,9 GiB. Naturalmente, man mano che vengono apportate modifiche al FS (nuovi backup, più eliminazioni, snapshot create e scadute, ecc.), il calcolo verrà avviato.

Se necessario, per interrompere il processo di cui sopra è possibile utilizzare il comando seguente:

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

Nota: questa CLI si applica solo al tier DD Active. Non esiste un processo equivalente per calcolare il cleanable per un'unità cloud DD, che ha una propria stima, soggetta alle stesse incertezze descritte in precedenza.