Solución de problemas de deduplicación y tasa de compresión deficientes de archivos en data domain restorers (DDR)

Los restauradores de Data Domain (DDR) están diseñados para contener grandes cantidades de datos lógicos (previamente comprimidos) mediante un espacio físico mínimo en disco (posterior a la compresión). Esto se logra mediante:

• Desduplicación de datos recopilados para eliminar fragmentos duplicados de datos que ya están almacenados en el disco en el DDR, dejando solo datos únicos
• Compresión de datos únicos antes de que esos datos se escriban físicamente en el disco.

La tasa de compresión general de los datos que un DDR puede recopilar varía debido a varios factores, como los siguientes:

• Caso de uso
• Tipos de datos que se recopilan
• Configuración de la aplicación de respaldo

Cuando se configuran de manera óptima, las DDR suelen alcanzar una tasa de compresión general de 10 a 20 veces (y, a veces, pueden mostrar proporciones superiores a esta). Por el contrario, sin embargo, en algunos entornos, la tasa de compresión general puede ser menor que esta, lo que puede causar lo siguiente:

• El DDR agotará rápidamente su capacidad útil
• Impacto en el rendimiento del respaldo, la restauración o la replicación
• Una falla del DDR para cumplir con las expectativas del cliente

Este artículo está diseñado para analizar lo siguiente:

• Una breve descripción general de la desduplicación y la compresión de datos en un DDR
• Cómo determinar la tasa de compresión general para el sistema y los archivos individuales
• Factores que pueden causar degradación a la tasa de compresión general

¿Cómo recopila un restaurador de Data Domain los datos nuevos?

• La aplicación de respaldo envía datos (es decir, archivos) al DDR.
• El DDR divide estos archivos en fragmentos de 4 a 12 Kb de tamaño: cada fragmento se ve como un "segmento".
• El DDR genera una "huella digital" única (similar a una suma de comprobación) para cada segmento según los datos contenidos dentro del segmento.
• Las huellas digitales de los segmentos recién llegados se comprueban en los índices de disco en el DDR para determinar si el DDR ya contiene un segmento con la misma huella digital.
• Si el DDR ya tiene un segmento con la misma huella digital, el segmento correspondiente en los datos recién llegados es un duplicado y se puede descartar (es decir, desduplicado).
• Una vez que se hayan eliminado todos los segmentos duplicados de los datos recién llegados, solo quedan segmentos únicos o nuevos.
• Estos segmentos únicos o nuevos se agrupan en "regiones de compresión" de 128 Kb y, a continuación, se comprimen (mediante el algoritmo lz de manera predeterminada).
• Las regiones de compresión comprimidas se comprimen en unidades de almacenamiento de 4,5 Mb conocidas como "contenedores" que luego se escriben en el disco duro.

¿Cómo rastrea el DDR qué segmentos componen un determinado archivo?

Además de la desduplicación/compresión de los datos recién llegados, el DDR también crea un "árbol de segmentos" para cada archivo recopilado. Esta es esencialmente una lista de "huellas digitales" de segmentos que componen ese archivo. Si el DDR debe leer el archivo posteriormente, debe realizar lo siguiente:

• Determine la ubicación del árbol de segmentos de archivos.
• Lea el árbol de segmentos para obtener una lista de todas las huellas digitales del segmento que componen la región del archivo que se lee.
• Use en índices de disco para determinar la ubicación física (es decir, el contenedor) de los datos en el disco.
• Lea los datos del segmento físico de los contenedores subyacentes en el disco.
• Utilice datos de segmentos físicos para reconstruir el archivo.

Los árboles de segmentos de archivos también se almacenan en contenedores de 4,5 Mb en el disco y representan la mayoría de los "metadatos" de archivos (que se analizan más adelante en este artículo).

¿Cómo se puede determinar la tasa de compresión general en un DDR?

La utilización general de un DDR (y la tasa de compresión) se puede ver mediante el comando "filesys show space". Por ejemplo:

Nivel activo:
GiB de tamaño de recurso GiB utilizado GiB disponible% GiB limpiable*
---------------- -------- -------- --------- ---- --------------
/datos: pre-comp - 115367.8 - - - -
/data: post-comp 6794 0.2 6242.4 551.8 92 % 202.5
/ddvar 49.2 9.1 37.6 20 % -


---------------- -------- -------- --------- ---- --------------En este caso, vemos lo siguiente:

• Datos comprimidos previamente o lógicos que se conservan en DDR: 115 367,8 Gb
• Espacio físico o posterior comprimido que se utiliza en DDR: 6242,4 Gb
• La tasa de compresión general es 115367.8/6242.4 = 18.48 veces

La salida del comando "filesys show compression" confirma los datos que se conservan, el espacio utilizado y la tasa de compresión. Por ejemplo:

                   Factor de factor
(reducción %)
---------------- -------- --------- ----------- ---------- -------------
Descomp. total-comp
local (GiB) (GiB) previo a la compresión:*   115367.8 6242.4 - - 18.5x (94.6) <=== NOTA
Escrita:                                                                          
  Últimos 7 días 42214.7 1863.2 11.0x 2.1x 22.7x (95.6)
  Las últimas 24 horas 4924.8 274.0 8.8x 2.0x 18.0x (94.4)
---------------- -------- --------- ----------- ---------- -------------

Overall utilization figures on the DDR se calculan de la siguiente manera:

• Total de datos comprimidos previamente: La suma del tamaño precomprimido (lógico) de todos los archivos que contiene el DDR.
• Total de datos posteriores a la compresión: La cantidad de "contenedores" en uso en el disco multiplicada por 4,5 Mb (el tamaño de un solo contenedor).
• Tamaño total posterior a la compresión: La cantidad máxima de "contenedores" que se crean dado el espacio de disco disponible en el sistema.

Las estadísticas sobre el máximo de contenedores de uso están disponibles en los soportes automáticos. Por ejemplo:

conjunto de contenedores 73fcacadea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <=== Tamaño del contenedor en bytes
...
    attrs.max_containers = 1546057 <=== Máximo de contenedores
posibles attrs.free_containers = 125562 <=== Contenedores
libres actualmente attrs.used_containers = 1420495 <=== Contenedores
actualmente en uso...

Vea lo siguiente:
 
¿Cómo se pueden determinar las tasas de deduplicación y compresión para un archivo, directorio o árbol de directorios individuales?

Cuando se recopila un archivo, las estadísticas de registros de DDR sobre el archivo incluyen:

• Bytes precomprimidos (lógicos)
• Tamaño de segmentos únicos después de la desduplicación
• Tamaño de segmentos únicos después de la desduplicación y la compresión
• Tamaño de los metadatos del archivo (es decir, árbol de segmentos, etc.)

Es posible volcar algunas de estas estadísticas mediante el comando "filesys show compression [path]", por ejemplo, para informar estadísticas de un solo archivo:

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1;  bytes/storage_used: 2,9
bytes originales:        3242 460 364
comprimidos globalmente:        1113 584 070
comprimidos localmente:        1130 871 915
Metadatos:            4772 672

Para informar estadísticas de un árbol de directorios completo:

SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files: 3;  bytes/storage_used: 1.4
Bytes originales:        7554 284 280
comprimidos globalmente:        5,425,407,986
Comprimida localmente:        5510 685 100
metadatos:           23 263 692

Sin embargo, tenga en cuenta que hay un par de advertencias en torno al uso de estas estadísticas:

• Las estadísticas se generan en el momento de la recopilación de datos o archivos y, después de esto, no se actualizan. Debido a la forma en que funciona un DDR, la recopilación de nuevos archivos o la eliminación de archivos que hacen referencia a los mismos datos, etc., puede cambiar la manera en que un archivo se desduplica con el tiempo, lo que hace que estas estadísticas se vuelvan obsoletas.
• Además, ciertos casos de uso en el DDR (como la copia rápida de un archivo y la eliminación del archivo original) pueden hacer que estas estadísticas se vuelvan engañosas o incorrectas.

Como resultado, estas cifras se deben considerar solo como estimaciones.

Los bytes precomprimidos no son necesariamente el tamaño precomprimido/lógico del archivo. En su lugar, es la cantidad total de bytes escritos en un archivo en su vida útil. Como resultado, en ciertos ambientes, los archivos existentes se sobrescriben comúnmente (por ejemplo, aquellos que utilizan la funcionalidad de biblioteca de cintas virtuales), esta figura puede ser mayor que el tamaño lógico de los archivos correspondientes.

¿La recopilación de datos de "mala calidad" puede causar degradación en la tasa de compresión general?

Sí. Para que un DDR logre una buena relación de compresión general de los datos recopilados, debe ser capaz de desduplicar y comprimir esos datos. Hay varios tipos de datos que pueden evitar esto, como se describe a continuación:

datos precomprimidos/cifrados previamente:

estos son tipos de datos que están comprimidos o cifrados en el sistema cliente o por la aplicación de respaldo. Esto también puede incluir archivos específicos de aplicaciones que se comprimen o cifran por diseño (por ejemplo, archivos de medios) y archivos de base de datos que están comprimidos o cifrados, o bien incorporar objetos binarios, como archivos de medios.

Debido a la manera en que el algoritmo de compresión o cifrado funciona, un cambio relativamente pequeño en los datos subyacentes de un archivo hace que los cambios se "dominen" en todo el archivo. Por ejemplo, un cliente puede contener un archivo cifrado de 100 Mb dentro del cual se modifican 10 Kb. Normalmente, el archivo resultante sería idéntico antes y después de la modificación aparte de la sección de 10 Kb que cambió. Cuando se utiliza el cifrado, a pesar de que solo se han cambiado 10 KB de datos no cifrados antes y después de la modificación, el algoritmo de cifrado hace que el contenido completo del archivo cambie.

Cuando estos datos se modifican periódicamente y se envían periódicamente a un DDR, este efecto de "dominó" hace que cada generación del archivo se vea diferente a las generaciones anteriores del mismo archivo. Como resultado, cada generación contiene un conjunto único de segmentos (y huellas digitales de segmentos), por lo que muestra una tasa de deduplicación deficiente.

Tenga en cuenta también que, en lugar de archivos precomprimidos, es poco probable que el algoritmo lz pueda comprimir aún más los datos del segmento constitutivo, de modo que los datos no se puedan comprimir antes de que se escriban en el disco.

Como regla general, la precompresión o el cifrado previo provocan lo siguiente:

• Datos cifrados previamente: Tasa de deduplicación deficiente, pero tasa de compresión aceptable
• Datos comprimidos previamente: Tasa de deduplicación deficiente y tasa de compresión deficiente

Cuando un DDR recopila múltiples veces los datos precomprimidos/cifrados previamente (sin cambios), la tasa de deduplicación de los datos mejora, ya que, a pesar del uso de algoritmos de compresión o cifrado, se observa un conjunto similar de segmentos (y huellas digitales de segmentos) durante cada respaldo.

Cuando sea posible, los datos enviados a un DDR no se deben cifrar ni comprimir: esto puede requerir deshabilitar el cifrado o la compresión en el cliente final o dentro de la aplicación de respaldo correspondiente.

Para obtener ayuda en la comprobación, modificación de la configuración de cifrado o compresión dentro de un determinado respaldo, aplicación cliente o sistema operativo, comuníquese con el proveedor de soporte correspondiente.

Archivos de medios:

Ciertos tipos de archivos contienen datos previamente comprimidos o cifrados previamente por diseño. Por ejemplo:

• Archivos PDF
• Ciertos archivos de audio (mp3, cd, ogg, etc.)
• Archivos de video (avi, avi, etc.)
• Archivos de imagen (png, bmp, jpeg, etc.)
• Archivos específicos de la aplicación (Microsoft Office, Open Office, Libre Office, etc.)

Los datos dentro de los archivos se comprimen o cifran mediante el códec del archivo y, como resultado, provoca los mismos problemas cuando se recopilan en un DDR como se describió anteriormente para los datos previamente comprimidos o cifrados previamente.

Archivos con alta "exclusividad":

Lograr una buena tasa de deduplicación depende de que el DDR vea el mismo conjunto de segmentos (y huellas digitales de segmento) varias veces. Sin embargo, ciertos tipos de datos contienen solo datos transaccionales únicos que, por diseño, contienen datos "únicos".

Si estos archivos se envían a un DDR, cada generación del respaldo contiene un conjunto único de segmentos o huellas digitales de segmentos y, como resultado, ve una tasa de deduplicación degradada.

Algunos ejemplos de estos archivos son los siguientes:

• Registros de transacciones de base de datos (por ejemplo, registros de archivo de Oracle).
• Registros de transacciones de Microsoft Exchange

El primer respaldo de un cliente "nuevo" a un DDR también puede causar este problema (ya que el DDR no ha visto los datos anteriormente, por lo que los segmentos o las huellas digitales de segmentos correspondientes en el respaldo son únicos). Sin embargo, con el tiempo, a medida que se envían generaciones futuras del mismo respaldo al DDR, la tasa de deduplicación de los respaldos mejora, ya que menos segmentos en cada respaldo nuevo son únicos. Debido a esto, se espera que la tasa general de deduplicación o compresión en un DDR recién instalado que reciba principalmente respaldos nuevos se degrade, pero mejore con el tiempo.

Archivos pequeños:

Los archivos pequeños causan varios problemas cuando se escriben en un DDR. Entre ellas se incluyen:

• Bloat de metadatos: el DDR comienza a contener una cantidad de metadatos en archivos mayor de lo esperado en comparación con los datos físicos.
• Utilización deficiente del contenedor: por diseño (debido al diseño de segmento informado de flujo de Data Domain o a la arquitectura SISL, más allá del alcance de este documento), un contenedor de 4,5 Mb en disco solo contiene datos de un solo archivo. Como resultado, el respaldo de un único archivo de 10 Kb, por ejemplo, hace que se escriba al menos un contenedor completo de 4,5 Mb para ese archivo. Esto puede significar que, para dichos archivos, el DDR utiliza mucho más espacio posterior a la compresión (físico) que la cantidad correspondiente de datos precomprimidos (lógicos) que se respaldan, lo que, a su vez, genera una tasa de compresión general negativa.
• Tasa de deduplicación deficiente: los archivos que son más pequeños que 4 Kb (el tamaño mínimo de segmento compatible en un DDR) constan de un solo segmento que se agrega a 4 Kb. Estos segmentos no se desduplican, sino que se escriben directamente en el disco. Esto puede hacer que el DDR contenga varias copias del mismo segmento (que se ven como segmentos duplicados).
• Rendimiento deficiente de respaldo, restauración o limpieza: hay grandes sobrecargas durante el respaldo, la restauración o la limpieza cuando se transfiere de un archivo al siguiente (ya que se debe cambiar el contexto de los metadatos que se utilizan).

Vea lo siguiente:

• El impacto en el rendimiento limpio cuando se utilizan archivos pequeños se ha mitigado, en gran medida, mediante la introducción de la limpieza física o la recolección de elementos no utilizados en DDOS 5.5 y versiones posteriores.
• La limpieza intenta "deshacer" la mala utilización de contenedores mediante la agregación de datos de contenedores con baja utilización en contenedores más estrechamente empaquetados durante su fase de copia.
• La limpieza intenta eliminar segmentos duplicados excesivos durante su fase de copia.

A pesar de lo anterior, se debe evitar el uso de grandes cantidades de archivos o cargas de trabajo pequeños que constan principalmente de archivos pequeños. Es mejor combinar grandes cantidades de archivos pequeños en un único archivo sin comprimir/sin cifrar antes de realizar el respaldo que enviar los archivos pequeños al DDR en su estado nativo. Por ejemplo, es mucho mejor respaldar un único archivo de 10 Gb que contenga 1048576 archivos individuales de 10 Kb que todos los archivos 1048576 individualmente.

Multiplexación excesiva por parte de las aplicaciones de respaldo:

Las aplicaciones de respaldo se pueden configurar para realizar la multiplexación de datos entre los flujos que se envían al dispositivo de respaldo, es decir, los datos de flujos de entrada (es decir, clientes diferentes) se envían en un solo flujo al dispositivo de respaldo. Esta funcionalidad se utiliza principalmente cuando se escribe en dispositivos de cinta físicos de la siguiente manera:

• Un dispositivo de cinta física solo puede admitir un único flujo de escritura entrante.
• La aplicación de respaldo debe mantener un rendimiento suficiente para el dispositivo de cinta para evitar que la cinta se inicie, se detenga o se rebobina (también conocida como rebobinado): esto es más fácil si el flujo que va al dispositivo de cinta contiene datos que se leen desde más de un cliente.

Sin embargo, en el caso de un DDR, esto hace que un solo archivo en el DDR contenga datos de varios clientes que se intercalan en tamaños de fragmento o orden arbitrario. Esto puede causar una tasa de deduplicación degradada, ya que es posible que el DDR no pueda observar con precisión los segmentos duplicados de cada generación de un respaldo de clientes determinado. En general, cuanto menor sea la granularidad de multiplexación, peor será el impacto en la tasa de deduplicación.

Además, el rendimiento de la restauración puede ser deficiente en cuanto a la restauración de ciertos datos de clientes, el DDR debe leer muchos archivos o contenedores donde la mayoría de los datos en los archivos o contenedores es superfluo, ya que se relaciona con los respaldos de otros clientes.

Las aplicaciones de respaldo no deben utilizar multiplexación cuando se escriben en un DDR, ya que los DDR admiten un conteo de flujos entrantes mayor que los dispositivos de cinta físicos y cada flujo puede escribir a una velocidad variable. Como resultado, se debe deshabilitar la multiplexación por parte de las aplicaciones de respaldo. Si el rendimiento del respaldo se ve afectado después de deshabilitar la multiplexación, realice lo siguiente:

• Las aplicaciones de respaldo que utilizan CIFS, NFS u OST (DDBoost) deben aumentar su cantidad de flujos de escritura (de modo que se puedan escribir más archivos en paralelo en el DDR).
• Los entornos que utilizan VTL deben agregar unidades adicionales al DDR, ya que cada unidad permite admitir un flujo de escritura paralelo adicional.

Si necesita ayuda para deshabilitar la multiplexación o si desea analizar la configuración de multiplexación recomendada para una aplicación de respaldo específica, póngase en contacto con el proveedor de soporte contratado.

Aplicaciones de respaldo que insertan marcadores de cinta excesivos:

Algunas aplicaciones de respaldo pueden insertar estructuras de datos repetidas en un flujo de respaldo que se conoce como "marcadores". Los marcadores no representan datos físicos dentro del respaldo, sino que la aplicación de respaldo los utiliza como un sistema de indexación o posicionado.

En algunas circunstancias, la inclusión de marcadores en un flujo de respaldo puede degradar la tasa de deduplicación, por ejemplo:

• En la primera generación de un respaldo, había 12 KB de datos que eran contiguos. Esto fue reconocido por el DDR como un solo segmento.
• Sin embargo, en la segunda generación del respaldo, los mismos 12 KB de datos se dividen por la inclusión de un marcador de respaldo que puede representar 6 Kb de datos, marcador de respaldo y 6 Kb de datos.
• Como resultado, los segmentos que se crean durante la segunda generación del respaldo no coinciden con los generados durante la primera generación del respaldo, por lo tanto, no se desduplican correctamente.

Cuanto más espaciados estén los marcadores, peor será el impacto en la tasa de deduplicación (por ejemplo, una aplicación de respaldo que inserta marcadores cada 32 Kb causa más problemas que una aplicación de respaldo que inserta marcadores cada 1 Mb).

Para evitar este problema, el DDR utiliza tecnología de reconocimiento de marcador que permite lo siguiente:

• Respalde los marcadores que se eliminarán de manera transparente del flujo de respaldo durante la recopilación del respaldo.
• Respaldar marcadores que se reinsertarán en el flujo de respaldo durante la restauración del respaldo

Esto ayuda a evitar la fragmentación de datos o segmentos por marcadores de respaldo y mejora la tasa de deduplicación de los respaldos correspondientes.

Sin embargo, para aprovechar al máximo esta tecnología, es importante que el DDR pueda reconocer correctamente los marcadores que se insertan en los flujos de respaldo. El DDR busca marcadores según la configuración de la opción "tipo de marcador", por ejemplo:

SE@DDVE60_JF## filesys option show
Option Value
-------------------------------- --------
...
Tipo de marcador automático
...


-------------------------------- --------Usualmente, esto se debe establecer en "automático", ya que esto permite que el DDR coincida automáticamente con los tipos de marcador más comunes. Si el sistema está recopilando datos de solo una aplicación de respaldo que inserta marcadores, puede haber un beneficio de rendimiento al especificar un tipo de marcador específico, es decir:

# filesys option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

Vea lo siguiente:

• Es probable que cualquier beneficio para el rendimiento de la selección de un tipo de marcador específico sea mínimo.
• La selección de un tipo de marcador incorrecto puede causar una degradación adicional significativa de la tasa de deduplicación y el rendimiento de respaldo o restauración.

Como resultado, Data Domain generalmente recomienda dejar el tipo de marcador establecido en "automático". Para obtener más información sobre cómo modificar el tipo de marcador, comuníquese con su proveedor de soporte contratado.

Para los sistemas que recopilan datos de aplicaciones que utilizan marcadores de respaldo, pero que no son reconocidos por la tecnología automatizada de manejo de marcadores (como productos del software BridgeHead), póngase en contacto con el proveedor de soporte contratado, el cual puede trabajar con el soporte de Data Domain para determinar la configuración necesaria en el DDR a fin de detectar el marcador no estándar.

Indicaciones de datos de "mala calidad" que recibe un DDR:

En la siguiente tabla se enumeran las tasas de compresión y deduplicación esperadas para los diferentes tipos de datos que se enumeran anteriormente. Esta lista no es exhaustiva y obviamente puede haber alguna variación en las cifras exactas que se ven en un sistema determinado debido a la carga de trabajo o los datos que recopila el DDR:
 

Compresión global	Compresión local	Causa probable
Baja (1x - 4x)	Baja (de 1 a 1,5 veces)	Datos comprimidos o cifrados previamente
Baja (de 1 a 2)	Alta (>2x)	Datos únicos pero comprimibles, como registros de archivo de base de datos
Baja (de 2 a 5 veces)	Alta (>1,5 veces)	Marcadores que no se detectan, alta tasa de cambio de datos o multiplexación de flujos.
Alta (>10 veces)	Baja (<1,5 veces)	Respaldos de los mismos datos comprimidos o cifrados. Esto es poco común.

¿Existen ciertos factores en un DDR que pueden afectar la tasa de deduplicación general?

Sí. Hay varios factores que pueden provocar que los datos antiguos o superflantes se conserven en el disco en un DDR, lo que provoca un aumento en el espacio de disco posterior a la compresión (física) y una disminución en la tasa de compresión general. Estos factores se analizan a continuación.

Una falla al ejecutar regularmente la limpieza del sistema de archivos:

La limpieza del sistema de archivos es la única manera de eliminar físicamente los datos antiguos o superflantes en el disco a los que ya no hacen referencia los archivos en el DDR. Como resultado, un usuario puede eliminar varios archivos del sistema (lo que causa una disminución en la utilización previamente comprimida), pero no ejecutarlo de manera limpia (lo que deja una alta utilización física/posterior a la compresión). Esto provocaría una disminución en la tasa de compresión general.

Data Domain recomienda programar la limpieza para que se ejecute a intervalos regulares de la siguiente manera:

• DDR normal: Una vez por semana
• DDR con retención extendida: Una vez cada dos semanas

La limpieza no se debe ejecutar más de una vez a la semana, ya que esto puede causar problemas con la fragmentación de datos en el disco, lo que se manifiesta como un rendimiento deficiente de restauración/replicación.

Instantáneas antiguas excesivas en el sistema:

Los DDR pueden crear instantáneas de mtree que representan el contenido de un mtree en el momento en que se creó la instantánea. Sin embargo, tenga en cuenta que dejar instantáneas antiguas en un sistema puede causar un aumento en la utilización física/posterior a la compresión, lo que provoca una disminución en la tasa de compresión general. Por ejemplo:

• Existe un mtree que contiene muchos archivos (por lo que la utilización previamente comprimida es alta).
• Se crea una instantánea del mtree.
• Muchos de los archivos se eliminan (lo que provoca la disminución de la utilización previamente comprimida).
• Se ejecuta la limpieza del sistema de archivos; sin embargo, tenga en cuenta que se libera un espacio mínimo en el disco duro, ya que una copia de los archivos eliminados permanece en la instantánea de mtree, lo que significa que los datos a los que hacen referencia esos archivos no se pueden eliminar del disco.
• Como resultado, la utilización física/posterior a la compresión sigue siendo alta

Data Domain recomienda que, si se utilizan instantáneas de mtree (por ejemplo, para la recuperación a partir de la eliminación accidental de datos), se administren mediante programas de instantáneas automatizados, de modo que las instantáneas se creen a intervalos regulares con un período de vencimiento definido (la cantidad de tiempo antes de que la instantánea se elimine automáticamente). Además, el período de vencimiento debe ser lo más breve posible (sin embargo, esto obviamente puede depender del caso de uso de las instantáneas o del nivel de protección que estas instantáneas proporcionan). Esto evita la acumulación de instantáneas antiguas con un período de vencimiento prolongado.

Encontrará más información sobre cómo trabajar con instantáneas y programas de instantáneas en el siguiente artículo: Data Domain: administración de programas de instantáneas

Retraso excesivo de replicación:

La replicación nativa de Data Domain utiliza un registro de replicación o instantáneas de mtree (según el tipo de replicación) para rastrear qué archivos o datos están pendientes de replicación a un DDR remoto. El retraso de replicación es el concepto de la réplica que se encuentra detrás de los cambios en el DDR de origen. Esto puede ocurrir debido a diversos factores, entre los que se incluyen los siguientes:

• Contextos de replicación que se deshabilitan
• Ancho de banda de red insuficiente entre DDR
• Desconexiones frecuentes de la red.

Un retraso de replicación grande puede hacer que el registro de replicación continúe conteniendo referencias a archivos que se han eliminado en el DDR de origen o instantáneas de mtree antiguas o obsoletas en DDR de origen y destino. Como se describió anteriormente, los datos a los que hacen referencia estas instantáneas (o el registro de replicación) no se pueden eliminar físicamente del disco en el DDR, incluso si los archivos correspondientes se eliminaron del sistema. Esto puede provocar un aumento de la utilización física o posterior comprimida del DDR, lo que provoca una degradación de la tasa de deduplicación.

Si los DDR se ven afectados por una alta utilización, y se cree que esto se debe al retraso en la replicación, comuníquese con su proveedor de soporte contratado para obtener más ayuda.

¿Hay cambios en la configuración o ciertos factores en un DDR que pueden aumentar la tasa de compresión general?

Sí. La eliminación o el abordaje de los problemas que se analizaron anteriormente en este documento deberían permitir que un DDR muestre una relación de compresión general que mejore con el tiempo. También hay varios factores o cargas de trabajo en un DDR que pueden dar lugar a un aumento en la tasa de deduplicación. Por lo general, estos implican lo siguiente:

• Reducción de la cantidad de espacio en el disco duro utilizado por los archivos en el DDR (por ejemplo, aumentar la agresividad del algoritmo de compresión utilizado por el DDR)
• Aumento repentino de la cantidad de datos previamente comprimidos (lógicos) en el DDR sin un aumento correspondiente en la utilización física/posterior a la compresión

Modificación del algoritmo de compresión:

De manera predeterminada, los DDR comprimen los datos que se escriben en el disco con el algoritmo lz . Como se mencionó anteriormente, lz se utiliza, ya que tiene sobrecargas relativamente bajas en términos de CPU necesarias para la compresión o la descompresión, pero muestra una efectividad razonable en la reducción del tamaño de los datos.

Es posible aumentar la agresividad del algoritmo de compresión para proporcionar mayores ahorros en la utilización de la unidad de disco duro o posterior a la compresión (y, como resultado, mejorar la relación de compresión general). Los algoritmos de compresión compatibles, en orden de eficacia (de bajo a alto), son los siguientes:

• Lz
• gzfast
• Gz

Una comparación general de cada algoritmo es la siguiente:

• lz en comparación con gzfast ofrece una compresión aproximadamente un 15 % mejor y consume 2 veces más CPU.
• lz en comparación con gz brinda aproximadamente un 30 % de mejor compresión y consume 5 veces más CPU.
• gzfast en comparación con gz ofrece una compresión aproximadamente un 10-15 % mejor.

También es posible deshabilitar completamente la compresión (especifique un algoritmo de ninguno); sin embargo, esto no es compatible para su uso en los sistemas del cliente y es solo para pruebas internas.

Según la tabla anterior, cuanto más agresivo sea el algoritmo de compresión, más CPU se requerirá durante la compresión o descompresión de datos. Debido a esto, los cambios en un algoritmo más agresivo solo se deben realizar en sistemas que se cargan levemente bajo una carga de trabajo normal. Cambiar el algoritmo en sistemas muy cargados puede provocar una degradación extrema en el rendimiento del respaldo o la restauración y posibles alarmas o reinicios del sistema de archivos (lo que provoca una interrupción del DDR).

Para obtener más información sobre cómo cambiar el tipo de compresión, consulte el siguiente artículo: Sistema Data Domain y el impacto en el rendimiento de limpieza de la conversión a compresión

GZDebido al impacto potencial del cambio del algoritmo de compresión, se recomienda que los clientes interesados en hacer esto se comuniquen con su proveedor de soporte contratado para analizar más a fondo el cambio antes de continuar.

Uso de fastcopy del sistema de archivos:

Los DDR permiten el uso del comando "file system fastcopy" para copiar rápidamente un archivo (o un árbol de directorios). Esta funcionalidad crea un archivo mediante la clonación de los metadatos de un archivo existente (o grupo de archivos) de modo que, si bien los archivos nuevos no están conectados físicamente al archivo original, hacen referencia exactamente a los mismos datos en el disco que el archivo original. Esto significa que, independientemente del tamaño del archivo original, el nuevo archivo consume poco espacio en el disco (ya que se desduplica perfectamente contra los datos existentes).

El resultado de este comportamiento es que cuando se utiliza fastcopy del sistema de archivos, el tamaño precomprimido (lógico) de los datos en el DDR aumenta rápidamente, pero la utilización física/posterior a la compresión del DDR permanece estática.

Por ejemplo, el siguiente DDR tiene la utilización de la siguiente manera (lo que indica una tasa de compresión general de ~1,8x):

Nivel activo:
Tamaño de recurso GiB GiB utilizado GiB uso disponible% GiB*
---------------- -------- -------- --------- ---- --------------
/datos: previo a la compresión - 12.0 - - -
/datos: post-comp 71.5 6.8 64.7 10 % 0.0
/ddvar 49.2 1.1 45.6 2 % -
/ddvar/core 158.5 0.2 150.2 0 % -
---------------- -------- -------- --------- ---- --------------

Contiene un archivo grande (/data/col1/backup/testfile):

!!! DDVE60_JF SUS DATOS ESTÁN EN PELIGRO !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root 3221225472 Jul 29 04:20 /data/col1/backup/testfile

El archivo se copia varias veces:

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

Esto hace que la utilización previamente comprimida aumente para un pequeño cambio en la utilización posterior a la compresión:

nivel activo:
GiB de tamaño de recurso GiB utilizado GiB uso disponible% GiB que se puede limpiar*
---------------- -------- -------- --------- ---- --------------
/datos: previo a la compresión - 21.0 - - - -
/datos: posterior a la compresión 71.5 6.8 64.7 10 % 0.0
/ddvar 49.2 1.1 45.6 2 % -
/ddvar/core 158.5 0.2 150.2 0 % -
---------------- -------- -------- --------- ---- --------------

As un resultado, el DDR ahora muestra una relación de compresión general de ~3.1x.

Como se mencionó anteriormente, las estadísticas de compresión de las copias muestran que se desduplican perfectamente:

sysadmin@DDVE60_JF# filesys show compression /data/col1/backup/testfile_copy1
Total files: 1;  bytes/storage_used: 21331976.1
Bytes originales:        3242 460 364
comprimidos globalmente:                    0
Compresión local:                    0
Metadatos:                  152

La funcionalidad FastCopy no se puede utilizar para mejorar la relación de compresión general mediante la reducción de la utilización física del DDR; sin embargo, puede ser la causa de una alta tasa de compresión general (especialmente en ambientes que hacen un uso extensivo de FastCopy, como Avamar 6.x).