Data Domain: El tamaño que se puede limpiar es una estimación

A menudo, hay confusión sobre el valor de GiB que se puede limpiar presentado en un sistema Data Domain y expectativas inadecuadas sobre la cantidad de espacio que se recuperará después de ejecutar la limpieza.

La cantidad de GiB que se puede limpiar es solo una estimación, y no es posible obtener un valor preciso de la cantidad de espacio que se recuperará mediante la ejecución de la limpieza, debido a las elecciones tecnológicas realizadas durante el desarrollo del sistema de archivos de Data Domain.

A continuación se presenta una explicación sucinta de por qué las estimaciones de espacio limpiable pueden variar sustancialmente del espacio real recuperado. Sin embargo, hay otros factores que no se tienen en cuenta aquí, lo que puede hacer que la estimación y la cantidad de espacio en disco realmente liberado al ejecutar de forma limpia difieran sustancialmente
 

Cuando el sistema Data Domain ingiere datos, el valor posterior a la compresión se calcula y se almacena como datos estáticos para cada archivo. El valor "Limpiable" es simplemente la suma del valor posterior a la compresión de todos los archivos eliminados desde la última vez que se ejecutó DD clean hasta su finalización.
 

El valor Limpiable se vuelve inexacto si los segmentos de archivos de los archivos eliminados se han utilizado para desduplicar datos en otros archivos que no se han eliminado. Siempre y cuando haya un solo archivo que haga referencia a un segmento único existente, el proceso de limpieza de DD no considerará esos segmentos para su recuperación. Por lo tanto, incluso si el post-comp de un archivo se agregó en el contador "GiB limpiable" como si todos sus segmentos únicos estuvieran a punto de ser eliminados, es posible que algunos (o muchos) no lo hagan debido a que otros archivos los reutilizan.
 

A continuación se muestra un ejemplo más detallado que muestra este efecto:

Suponga que tiene 5 archivos, agregados uno por uno a un sistema Data Domain, sin otros datos previamente en él.

Dado que los primeros archivos de 100 GB contenían todos los datos únicos, su tasa de compresión es 1x (suponiendo que el primer archivo no tuviera ninguna redundancia dentro del archivo en sí). Los archivos del 2.º al 5.º fueron capaces de desduplicar los datos del primer archivo y cada uno de los archivos más antiguos a medida que se agregaban, cada uno de los cuales obtenía una deduplicación cada vez mayor debido al aumento de los archivos contra los que se podía desduplicar.

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

Ejemplo 1. Estado después de eliminar los primeros 3 archivos de /backup:
 

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

Si ejecuta la limpieza después de esto, es posible que pueda reclamar 125 en lugar de los 175 que se pueden limpiar completos. Esto se debe al hecho de que los últimos 2 archivos comparten segmentos con los archivos 1-3.  La limpieza no recuperará los otros 50 GB de espacio porque esos segmentos aún están en uso en los archivos 3-5.
 

Ejemplo 2: Utilizando el mismo punto de partida que con el ejemplo 1, supongamos que se eliminó el archivo 1, luego se realizó una copia rápida en toda la carpeta /backup (es decir, los 5 archivos) y, a continuación, se eliminaron los archivos 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 de "Tamaño GiB" para pre-comp proviene de (500-100) = 400 * 2 = 800, lo que da 500 para los 5 archivos originales, restando 100 para eliminar el archivo 1 da 400 GiB.  A continuación, 400 GiB multiplicados por 2 debido a la copia rápida en los 4 archivos restantes.

Tenga en cuenta que el espacio utilizado después de la compresión sigue siendo el mismo porque una copia de archivo solo agrega una pequeña cantidad de espacio, que consiste en los punteros de metadatos a los datos originales. El uso del espacio no ha cambiado a pesar de eliminar el archivo 1 porque no se ha ejecutado un "filesys clean start" (para iniciar la limpieza). 
 

Después de la limpieza veremos:
 

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

Tenga en cuenta que, aunque se mostró que se podían limpiar 200 GB, solo se limpiaron realmente 25 GB. El "GiB que se puede limpiar" se mostraba como 200 porque el tamaño de archivo "posterior a la compresión" de los archivos 1 a 4 sumaba 200 GB.  Solo se eliminó el "Archivo 1", que tenía 100 GB, pero los otros 4 archivos aún usaban 75 GB (debido a la deduplicación).  

Esto puede parecer extraño, ya que los "Archivos 2" a "Archivo 4" también se han eliminado, pero recuerde que, aunque el sistema mostrará los "Archivos 2" a "Archivo 4" como eliminados, los segmentos de datos reales de esos archivos no se pudieron eliminar porque esos archivos se han copiado rápidamente a otra carpeta.   Solo después de que también se hayan eliminado todas las versiones de fastcopy, se puede recuperar completamente el espacio mediante la limpieza.

Dado que GiB limpiables es solo una "estimación" y puede no ser preciso, incluso a veces puede reflejar un tamaño grande o igual al de la capacidad física de Data Domain.

Esto puede causar confusión sobre si permitir que se ejecute la limpieza de DDFS programada o manualmente si el uso del espacio de DDFS está cerca del 100 % debido a que GiB limpiables se muestran cerca o tienen el mismo valor que "/data: post-comp".

Para tener una manera mejor y más confiable de calcular la cantidad de espacio de disco que se podría recuperar cuando se ejecute, a partir de DD OS 7.7.x, ahora es posible determinar desde la CLI el "Espacio total que se puede limpiar" real que se podrá recuperar en el próximo GC en el nivel activo. Este es un resumen de la CLI:
 

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

El proceso hará lo mismo que un GC normal, pasando por las fases 1 a 4, pero omitiendo la fase 5 (copia), que es la que copiaría eficazmente los contenedores hacia adelante para recuperar el espacio en disco muerto. Por lo tanto, tomará el tiempo que un GC normal tarde en completar las fases limpias de la 1 a la 4 para devolver un valor, por lo que esto no es algo que deba ejecutarse regularmente para tener una estimación actualizada, sino solo cuando sea necesario. En otras palabras, "filesys cleanable-space calculate" ejecutará GC en el nivel activo y omitirá la parte en la que recupera espacio.

El proceso puede ser monitoreado de la siguiente manera:
 

# 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 vez completado, se puede acceder al resultado de la medición que se puede limpiar:

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

Aquí, en la prueba de ejemplo anterior, si DD GC se va a ejecutar ahora, liberará 94649698202 bytes. Eso es 88,1 GiB, mientras que, en el momento del cálculo, la estimación informada por "df" en el DD de laboratorio utilizado era de 41,9 GiB. Por supuesto, a medida que se realicen cambios en el FS (respaldos nuevos, más eliminaciones, creación y vencimiento de instantáneas, etc.), el cálculo se disparará.

Si es necesario, para detener el proceso anterior, se puede utilizar el siguiente comando:

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

Tenga en cuenta que esta CLI se aplica solo al nivel activo de DD. No existe un proceso equivalente para calcular lo que se puede limpiar para una unidad de nube de DD, que tiene su propia estimación, sujeta a las mismas incertidumbres que se describieron anteriormente.