Dominio de datos Una descripción general de las fases de limpieza del sistema de archivos de Data Domain (DDFS) o de recolección de elementos no utilizados (GC)

El sistema de archivos Data Domain (DDFS) es diferente de muchas implementaciones de sistemas de archivos comunes en que, cuando se elimina un archivo del espacio del sistema de archivos utilizado por ese archivo, no está disponible de inmediato para su reutilización. El motivo de esto es que el restaurador de Data Domain (DDR) no sabe inmediatamente si los datos a los que hace referencia el archivo eliminado también se deduplican con otros archivos y, por lo tanto, si es seguro eliminar esos datos o no.

La limpieza (a veces denominada recolección de elementos no utilizados/GC) es el proceso mediante el cual un DDR:

• Determina qué datos del disco son superfluos (es decir, ya no son referenciados por objetos como archivos o instantáneas)
• Elimina físicamente los datos superfluos, lo que hace que el espacio en disco subyacente esté disponible para volver a usar (es decir, recopilación de datos nuevos)

La limpieza/GC está programada para ejecutarse a intervalos regulares (de manera predeterminada, se inicia a las 06:00 cada martes) y puede ser:

• Ejecución prolongada
• Costoso de cómputo

Sin embargo, tenga en cuenta que no hay ninguna forma distinta a la ejecución de Clean/GC en la que los datos se pueden eliminar o liberar espacio físicamente en un restaurador de Data Domain (es decir, no hay accesos directos para acelerar este proceso).

Este artículo describe Clean/GC en más detalle:

• Las fases que se ejecutan en general
• Los diferentes algoritmos de limpieza utilizados en varias versiones de DDOS

Ninguno

Cada vez que se ejecuta Clean/GC, tiene dos propósitos principales: en primer lugar, debe encontrar datos superfluos en el DDR: una breve descripción general de cómo se hace esto es la siguiente:

• Clean/GC enumera el contenido del sistema de archivos DDFS, en el cual se buscan objetos como archivos, instantáneas y registros de replicación que actualmente existen en el sistema.
• A continuación, se determinan todos los datos físicos del disco al que hacen referencia activamente estos objetos.
• Se dice que los datos a los que se hace referencia activamente se consideran "activos" y no se pueden eliminar del DDR de lo contrario, los objetos que hacen referencia a estos datos podrían dañarse (ya no podrán leerse, ya que los datos subyacentes de los que dependen ya no existirán en el disco).
• Se dice que los datos a los que no hace referencia activamente ningún objeto están "inactivos" y son superfluos. estos datos se pueden extraer de manera segura del sistema
• Todos los datos en un DDR se empaquetan en objetos de 4,5 MB de tamaño conocido como contenedores
• A través de la enumeración Clean/GC puede determinar qué contenedores de 4.5 MB contienen datos inactivos y la cantidad de datos inactivos en cada uno
• De manera predeterminada, Clean/GC seleccionará los contenedores de 4.5 MB que contengan > datos inactivos del 8% para el "procesamiento"

En segundo lugar, debe eliminar los datos inactivos en el DDR: una breve explicación de cómo se hace esto es la siguiente:

• Los contenedores seleccionados para el procesamiento se vuelven a verificar para confirmar que contengan una buena cantidad de datos inactivos
• Los datos en vivo se extraen de estos contenedores y se escriben en nuevos contenedores de 4.5 MB al final del sistema de archivos
• Una vez que se completan los contenedores seleccionados (incluidos los datos inactivos que contienen), se eliminan del disco que libera físicamente espacio en disco.

El proceso de limpieza se divide en una cantidad de "fases" con el conteo total de fases que depende de lo siguiente:

• La versión de DDOS que se utiliza en el DDR (por lo tanto, el algoritmo limpio utilizado, de forma predeterminada, por esa versión de DDOS)
• La configuración/contenido del sistema

Sin embargo, en general, el proceso de búsqueda de datos "inactivos" y la selección de los contenedores correspondientes se lleva a cabo en varias fases, mientras que la eliminación de datos muertos se lleva a cabo en una sola fase denominada "copia". Por ejemplo, algunas versiones de DDOS ejecutarán fases limpias de la siguiente manera:

1. Previo a la enumeración: enumerar el contenido del sistema de archivos DDFS
2. Premerge: realice una combinación de índice de DDFS para asegurarse de que la copia más reciente de la información del índice se vacíe en el disco
3. Pre-Filter: determinar si hay datos duplicados en el sistema de archivos DDFS y, si es así, Dónde está
4. Preseleccione: determina qué contenedores de 4.5 MB se deben "procesar" mediante la limpieza
5. Copiar: extraer físicamente los datos de Live de los contenedores seleccionados, escribir esto en nuevos contenedores y, a continuación, eliminar los contenedores seleccionados
6. Resumen: vectores de Resumen de reconstrucción (que se utilizan como una optimización durante la recopilación de datos nuevos)

En el ejemplo anterior, se utilizan las fases de 1-4 para determinar dónde existen los datos "inactivos" en el DDR (denominados "fases de enumeración" en el resto de este documento), mientras que la fase 5 (copia) se utiliza para eliminar físicamente estos datos.

Tenga en cuenta que no se liberará espacio físicamente en el sistema hasta que Clean/GC alcance la fase de copia. En consecuencia, puede haber un retraso significativo entre el inicio de la limpieza y el espacio que comienza a liberarse (debido a que el proceso de enumeración tiene que ejecutarse en primer lugar). Por este motivo, los sistemas no deben tener permiso para completar el 100% completo antes de que se inicie la limpieza/GC.

Las fases de enumeración tienden a ser costosas en términos de utilización de CPU (es decir, suelen estar limitadas por CPU), mientras que la fase de copia es costosa en términos de CPU y de e/s (es decir, generalmente son CPU y de I/O vinculadas). Sin embargo, en resumen es posible decir que:

• La longitud total de las fases de enumeración depende de la cantidad de datos en el DDR que se deben enumerar
• La longitud total de la fase Copy depende de la cantidad de datos inactivos en el DDR que debe eliminarse y de la fragmentación de los datos en disco (que se analizan más abajo)

El número/funcionalidad de las fases de enumeración depende de la versión de DDOS que se utiliza en un DDR.

DDOS 5,4 (y anterior): algoritmo de limpieza completo: Ejecuta 6 o 10 fases (como se muestra anteriormente):

• El contenido del sistema de archivos DDFS se enumera en sentido descendente (es decir, se centra en archivos)
• DDFS Descubre todos los archivos que existen en el DDR luego escanea cada archivo por turno para determinar los datos a los que hace referencia ese archivo.
• Esto permite que Clean/GC determine qué datos del disco está "activo".

DDOS 5,5 (y superior): algoritmo de limpieza física (PGC): Ejecuciones de 7 o 12 fases:

• El contenido de la DDFS se enumera en sentido ascendente (es decir, ya no Escanea archivos individuales).
• DDFS Descubre los metadatos del sistema de archivos que hace referencia a los datos físicos del disco y escanea esos metadatos para determinar los datos a los que se hace referencia
• Esto permite que Clean/GC determine qué datos del disco está "activo".
• Esto se logra mediante la adición de una fase de "análisis" (por lo tanto, el aumento en el conteo de fase sobre el algoritmo de limpieza completo)
• Sin embargo, en la mayoría de los casos, se espera que la duración total de la limpieza física sea más breve que la limpieza total para el mismo sistema (a pesar de que constan de fases más individuales).

DDOS 6,0 (y superior): algoritmo de limpieza física perfecta (PPGC):

• Esto es simplemente una optimización para el algoritmo de limpieza físico y se analiza más adelante

Tenga en cuenta que DDOS cambió del algoritmo de limpieza completo al algoritmo de limpieza físico para mejorar la escalabilidad y el rendimiento del proceso de enumeración, debido a la naturaleza de la parte más baja del algoritmo de limpieza completo, no se escaló bien en DDR con uno de los siguientes elementos:

• Una gran cantidad de archivos pequeños (como el conmutador de contexto cuando se transfiere de la enumeración de un archivo a la siguiente era costosa/lenta)
• Tasa de deduplicación alta (a medida que varios archivos hacen referencia a los mismos datos físicos, de modo que los mismos datos se enumeraron varias veces)

El conmutador de DDR se realiza automáticamente cuando se actualiza desde DDOS 5,4 (o anterior) a 5,5 (o posterior). La única excepción a esto son los sistemas configurados con Extended Retention, donde se debe comprobar el contenido del sistema de archivos DDFS para buscar archivos antes de que se pueda habilitar la limpieza física: un análisis de este proceso se encuentra fuera del alcance de este documento, sin embargo, esta comprobación se ejecuta automáticamente después de la actualización y la limpieza física se habilita cuando se completa esta comprobación

, pero De manera similar, el switch de DDR se realiza de manera automática a algoritmos de limpieza física perfectas cuando se actualiza de DDOS 5. x a 6,0 (o posterior). Sin embargo, tenga en cuenta que el algoritmo de limpieza físico perfecto requiere que los índices estén en el formato "índice 2,0" para poder usarlos. Tenga en cuenta que:

• El formato "índice 2,0" se incorporó con DDOS 5,5 (de modo que todos los sistemas de archivos creados en 5,5 o superior ya utilizarán el índice 2,0)
• El sistema de archivos creado en 5,4 o una versión anterior inicialmente habrá índices en el formato 1,0 del índice. Una vez que se actualiza a DDOS 5,5 (o posterior), los índices se convertirán en el formato del índice 2,0. la conversión se produce cada vez que se realiza una limpieza, sin embargo, solo ~ 1% de los índices se convierten durante cada limpieza, por lo que puede tardar hasta 2 años (suponiendo que 2,0 las ejecuciones de limpieza son cada semana)

Los DDR que ejecutan inicialmente DDOS 5,4 (o anterior), pero que posteriormente se han actualizado a DDOS 5,5 (o posterior), se pueden forzar a convertir los índices al formato 2,0 de un solo uso por una sola vez, "reconstrucción del índice". Sin embargo, tenga en cuenta que una recreación del índice requiere un periodo de inactividad mientras que los índices se reconstruyen físicamente; esta operación generalmente tarda 2-8 horas en completarse según el tamaño o la cantidad de datos en el DDR. Para analizar la realización de una reconstrucción del índice, comuníquese con su proveedor de soporte contratado.

Como se mencionó anteriormente, independientemente del algoritmo de limpieza/GC utilizado, la limpieza puede requerir un número variable de fases; por ejemplo, el algoritmo de limpieza completo puede requerir 6 o 10 fases. El motivo de esto es que:

• Cuando se inicia DDFS, se reserva una cantidad fija de memoria para ser utilizada por Clean/GC
• Dentro de esta memoria, Clean/GC crea las estructuras de datos para describir los resultados de la enumeración (es decir, la descripción de la ubicación en la que se encuentran los datos en vivo en el disco)
• Cuando un DDR contiene una cantidad relativamente pequeña de datos, todo el contenido del sistema de archivos de DDFS se puede describir en esta área de memoria.
• Sin embargo, en muchos sistemas, esto no es posible y este área de memoria se agotaría antes de que se enumerara todo el contenido del sistema de archivos de DDFS
• Como resultado, estos sistemas realizan un "muestreo" que aumenta la cantidad de fases limpias requeridas

Cuando se utiliza el borrado limpio/GC, se realiza lo siguiente:

• Realice un paso de muestra de la enumeración en todo el sistema de archivos; tenga en cuenta que esta enumeración no es "Complete" (es decir, no registra información completa acerca de cada parte del sistema de archivos, sino que se aproxima a la información de cada parte del sistema de archivos)
• Utilice esta información de muestreo para determinar qué parte del sistema de archivos de DDFS se beneficiaría de la mayor parte de la ejecución de una limpieza/GC (es decir, qué parte del sistema de archivos daría como resultado las mejores devoluciones en términos de espacio liberado si se limpió)
• Realizar una segunda ronda de la enumeración completa en función de la parte seleccionada del sistema de archivos cuyo contenido ahora se puede describir por completo en la memoria reservada para GC

El muestreo se habilita automáticamente durante la limpieza/GC si es necesario. sin embargo, se producirá lo siguiente:

• Un aumento en la cantidad de fases que se deben realizar por limpieza/GC
• Un aumento correspondiente en la duración total de Clean/GC

Antes de DDOS 6,0, la mayoría de los DDR ejecutan la toma de muestras durante el Clean/GC (a menos que tengan un conjunto de datos relativamente pequeño). Sin embargo, el algoritmo de limpieza físico perfecto incluye varias optimizaciones para reducir la cantidad de memoria requerida por limpieza/GC cuando se enumeran los datos dentro del sistema de archivos. Esto significa que muchos sistemas que realizaron la toma de muestras durante la limpieza/GC en DDOS 5. x ya no requerirán la muestra en DDOS 6,0. por lo tanto, se reduce la cantidad de fases ejecutadas por limpieza y se provoca una disminución correspondiente en el tiempo de ejecución de limpieza total (es decir, mejora en el rendimiento limpio).

No hay información disponible para determinar directamente que un sistema ha cambiado del algoritmo de limpieza físico al algoritmo de limpieza físico perfecto que no sea:

• Cuando el sistema estaba ejecutando una limpieza física en DDOS 5,5-5,7, estaba realizando 12 fases durante el borrado
• Después de que el sistema se actualiza a DDOS 6,0 (o posterior), realiza solo 7 fases durante el borrado

Si un sistema que ejecuta DDOS 6,0 aún debe realizar la muestra, se activará automáticamente durante el borrado y se revertirá a la ejecución de 12 fases durante el borrado.

Independientemente del algoritmo de limpieza, se utiliza la fase de copia (donde los datos inactivos se eliminan físicamente del sistema) de manera similar en todas las versiones. El rendimiento de la fase de copia generalmente depende de lo siguiente:

• La cantidad de datos "inactivos" que se deben eliminar
• La "fragmentación" de estos datos inactivos (es decir, cómo se distribuye entre discos)

Como se describe anteriormente, la copia funciona mediante la selección de contenedores de 4,5 MB que contienen datos inactivos, la extracción de los datos de Live de esos contenedores y la escritura de esos datos en nuevos contenedores y la eliminación de los contenedores seleccionados originalmente. Los siguientes ejemplos describen por qué es importante la fragmentación de los datos inactivos:

ejemplo 1:

• se seleccionan 10 contenedores para copiar (45 MB total Data)
• Todos si estos contenedores no tienen datos activos (es decir, los datos que contienen son totalmente incompletos/inactivos)
• Como resultado, simplemente debe marcar estos contenedores como eliminados para liberar espacio físico de 45 MB en disco.

Ejemplo 2:

• se seleccionan los contenedores 100 para la copia (450Mb total Data)
• Cada uno de estos contenedores contiene el 90% de datos en vivo/10% de datos inactivos
• Para procesar la copia de estos contenedores, debe:

Se requiere claramente una cantidad considerablemente mayor de I/O y CPU para ejecutar la copia que se describe en el ejemplo 2, en comparación con la que se presenta en el ejemplo 1. por lo tanto, se tardará bastante más en liberar espacio físico de 45 MB en el disco en este ejemplo.

Por lo general, los usuarios no tienen control sobre la "fragmentación" de los datos inactivos en el disco en un DDR, ya que esto depende del caso de uso/tipo de datos que se escriben en el sistema. Sin embargo, tenga en cuenta que Clean/GC mantiene las estadísticas que ayudan a determinar la "fragmentación" de los datos inactivos que se encuentran durante la fase de copia (que, por lo tanto, permite a un usuario determinar si esta fragmentación puede explicar una fase de ejecución potencialmente larga). Estas estadísticas de la fase más reciente de Clean/GC se recopilan en soporte automático. Por ejemplo, a continuación se muestra una fase de copia en la que los datos inactivos eran bastante contiguos (es decir, la mayoría de los contenedores seleccionados para la copia en la mayoría de los datos inactivos):

porcentaje de datos activos en copiados:              3,6% 4,3%

Por el contrario, a continuación se muestra una fase de copia en la que se fragmentaron los datos inactivos (es decir, la mayoría de los contenedores seleccionados para la copia en la mayoría de los datos activos):

porcentaje de datos de Live en copiados:             70,9% 71,5%

Tal como se describe anteriormente, la limpieza/GC tendrá que realizar un trabajo comparativamente mucho más en el segundo escenario para liberar físicamente el espacio del DDR lo que provocará que se reduzca el rendimiento de la fase de copia.

El rendimiento de la fase de copia también puede verse afectado negativamente por:

• El uso del cifrado: Es posible que los datos deban descifrarse/volver a cifrarse durante la copia, lo cual aumenta considerablemente la cantidad de CPU requerida.
• El uso de optimización de bajo ancho de banda: Es posible que los contenedores necesiten la información de "Esbozo" que se generará durante la copia, lo que también provoca un aumento significativo en la cantidad de CPU requerida.

Tenga en cuenta que si la optimización del ancho de banda bajo y/o el cifrado se han activado recientemente, es posible que sea necesario cifrar todos los contenedores existentes (independientemente de si se han seleccionado para copiarlos o no), o tener la información de esbozo que se genera en el momento de la limpieza posterior.

En el siguiente artículo de la base de conocimientos, se encuentran disponibles notas adicionales sobre la comprobación/modificación del programa de limpieza y la regulación: https://support.emc.com/kb/306100

Nota:

• En circunstancias normales, se debe programar la limpieza para que se ejecute como máximo una vez por semana: ejecución más frecuente que esto puede hacer que los datos en el disco se conviertan en un estado excesivamente "fragmentado" (es decir, que exhiben una localidad deficiente de menor nivel) que puede provocar un rendimiento deficiente de lectura/replicación/transferencia de datos.
• La regulación limpia no afecta la cantidad total de CPU y el ancho de banda de I/O consumidos por Clean: en lugar de eso, controla la manera en que la limpieza confidencial es otra carga de trabajo en el sistema. Por ejemplo:

• De manera predeterminada, la regulación limpia se establece en 50. es la responsabilidad del usuario probar la ejecución de una limpieza con diferentes configuraciones de regulación, mientras que la DDR de la carga de trabajo normal para determinar una configuración de regulación que permite:

• Tenga en cuenta que una larga ejecución limpia no necesariamente un problema siempre y cuando:

• El sistema que utiliza la función Extended Retention debe configurarse de manera tal que:

• La información completa de la operación de limpieza más reciente se incluye en soporte automático y detalles: