Avamar: Teoría y comportamiento del rendimiento del respaldo

El propósito de este artículo es describir lo que sucede durante un respaldo de Avamar con un enfoque en ayudar al lector a comprender el comportamiento del rendimiento del respaldo.

Este artículo es complementario de los siguientes artículos:

• Avamar: Solución de problemas de rendimiento de respaldo lento
• Avamar: Ajuste de respaldos para que se completen rápidamente

¿Qué sucede durante un respaldo de Avamar?

El proceso de respaldo de avtar :

1) Carga el archivo y los archivos de caché hash en la memoria

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) Crea instantáneas de VSS (en Windows):

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) Recorrer todos los archivos definidos por el conjunto de datos Para todos los archivos dentro del conjunto de datos fuente, avtar toma la ruta completa y la combina con los metadatos similares a estadísticas para calcular un hash con el fin de identificar de
manera única el archivo.

Para obtener más detalles, consulte Avamar: ¿Qué sucede cuando avtar lee un archivo durante la fase de escaneo de archivos?

4) Compare los hashes calculados con los de las cachés de clientes locales:

Avtar busca el hash del archivo en la caché de archivos. Comprueba si es nuevo o si se modificó desde el respaldo anterior.

Si la búsqueda en la caché de archivos se realiza correctamente, el archivo existe y no se modifica.

Si la búsqueda falla, el archivo es nuevo o cambió. Debe ser leído y procesado.

Para obtener más detalles, consulte Avamar Client: ¿Qué debe cambiar antes de que avtar considere que un archivo se ha modificado?

5) Procesar archivos nuevos y modificados

Para cualquier archivo nuevo o modificado, avtar debe:

• Leer el archivo completo
• Divídelo en partes de tamaño variable
• Comprimir cada fragmento
• Calcule un hash para cada fragmento

6) Compruebe si los hashes faltantes están presentes en el servidor Avamar.

Avtar envía datos de los hashes faltantes a través de la red al servidor Avamar para comprobar si ya existen. Estas se conocen como solicitudes 'ispresent'.

7) Los datos se escriben en Avamar Server (y, si corresponde, en Data Domain). 

Para obtener más detalles sobre el flujo de trabajo, consulte la Avtarprocess.pdf adjunta.


Visión general de un respaldo de Avamar desde una perspectiva de rendimiento:

Tomando las etapas anteriores, las dividimos en las "fases" que tienen el mayor impacto en el rendimiento de la copia de seguridad:

Fase 0. Crear instantáneas de VSS.

El servicio Volume Shadowcopy (VSS) crea instantáneas de los volúmenes especificados dentro del conjunto de datos fuente. Las aplicaciones pueden continuar escribiendo en el volumen mientras se ejecuta el respaldo.
Avamar respalda la instantánea "congelada" de solo lectura del volumen en lugar del volumen con capacidad de escritura. Esto garantiza que tenga un conjunto coherente de datos para respaldar.

Las instantáneas de VSS tardan segundos en completarse. Si un cliente experimenta problemas de VSS, esto retrasa o impide que el respaldo continúe.

Fase 1. Fase de escaneo de archivos. El proceso avtar estadística todos los archivos en el conjunto de datos

de destinoPara los clientes con millones de archivos, esta fase puede ser la que más tiempo consume.
Los datos de la base de datos contienen pocos archivos más grandes, por lo que la fase de escaneo de archivos tarda poco tiempo. Por lo general, los clientes de la base de datos consumen su tiempo durante la fase #2.

Para un cliente con discos rotativos en la configuración RAID 5, el rendimiento de escaneo de archivos de ~1 millón de archivos por hora es típico. Esto varía de 300.000 a 3 millones por hora. Depende del entorno del cliente y de las características de los datos que se respaldan.

A partir de v7.3, los clientes Linux que respaldan en Data Domain pueden aprovechar la funcionalidad de Linux Fast Incremental (LFI). Esto evita analizar todo el conjunto de datos cada vez que se ejecuta el respaldo.

Recursos críticos: rendimiento de búsqueda aleatoria del disco donde se almacenan los datos de respaldo.

Fase 2. Avtar lee los archivos modificados y, a continuación, fragmenta, comprime y aplica hash a los datos.

Durante esta fase, se produce una gran cantidad de computación. Para cada archivo modificado o nuevo, avtar lo divide en fragmentos pequeños. Comprime cada fragmento y calcula un hash como una "huella digital" para identificar el fragmento.

Los archivos en los respaldos de bases de datos suelen ser grandes y tienden a cambiar diariamente. Avtar pasa la mayor parte del tiempo en esta fase. Es mejor utilizar los plug-ins oficiales de la base de datos de Avamar para asegurarse de que la base de datos se maneje de manera eficiente aprovechando la funcionalidad de respaldo incremental, los registros de transacciones, etc.

El rendimiento típico del procesamiento de archivos es de alrededor de 100 GB por hora, pero puede variar hasta 300 GB por hora. Esto depende del entorno.

Recursos críticos: Disco de cliente y CPU

Para los respaldos de LAN donde no hay cuellos de botella en el envío de datos al servidor Avamar, las fases #1 y #2 tardan más tiempo.

En el siguiente gráfico, tenga en cuenta que la cantidad de área en las barras del gráfico corresponde al tiempo que tarda el respaldo. Los archivos modificados pueden aumentar drásticamente la cantidad de tiempo necesario, especialmente si esos archivos son grandes.

Para los conjuntos de datos del sistema de archivos, se espera que ~0-3 % de los archivos cambien a diario.

Avtar debe ejecutar "stat()" en cada archivo que cambia mediante la ejecución de dos operaciones de I/O, una para comprobar los atributos del archivo y otra para los atributos de seguridad.

Para lograr el rendimiento de la tasa de análisis del parámetro de referencia de ~1 millón de archivos por hora para los respaldos del sistema de archivos, avtar requiere aproximadamente dos millones de operaciones de búsqueda por hora o 600 operaciones de búsqueda por segundo.

Por ejemplo: Si un respaldo tiene una tasa de cambio del 3 %, 97 de cada 100 archivos requieren dos operaciones de búsqueda de discos para identificar si cambiaron. Los tres restantes, que cambiaron, se deben escanear, fragmentar, comprimir y aplicar hash.

Esto considera solo la fase de escaneo de archivos y no tiene en cuenta los recursos de I/O necesarios para procesar los archivos que se modificaron.
Cuantos más datos haya en los archivos modificados, más trabajo se necesitará para completar el respaldo.

Fase 3. Comprobación de la existencia de hashes en el servidor

AvamarLas fases #1 y #2 producen hashes que apuntan a elementos del respaldo. Estos elementos pueden ser fragmentos de archivos únicos, sistemas de archivos o respaldos completos.

Los hashes se escriben en los archivos de caché del cliente y se comparan con los hashes presentes en el servidor Avamar para comprobar si se deben agregar datos nuevos. Esto es cierto ya sea que un servidor Avamar o Data Domain sea el almacenamiento de destino.

Las comparaciones de hash entre el cliente y el servidor Avamar suelen ser rápidas. No deben generar cuellos de botella en el respaldo si el servidor Avamar está

• Sano
• Bajo niveles de carga regulares
• Ubicado en el mismo segmento de LAN que el cliente

Dado que los hashes tienen un tamaño de solo 20 bytes, esta fase está más influenciada por la latencia de la red que por el ancho de banda de la red. Cuando el hash llega al servidor Avamar, la carga general y el rendimiento de búsqueda aleatoria del subsistema de disco de los nodos de datos determinan la rapidez con la que se recupera el hash y se compara con el enviado por el cliente.

Recursos críticos: El tiempo de respuesta de la red y el rendimiento de búsqueda aleatoria del nodo de datos de Avamar.

El rendimiento de búsqueda aleatoria de una escala física de Avamar con la cantidad y el tamaño de los nodos de datos. Los sistemas AVE tienen un rendimiento menos bueno, en comparación con un sistema de nodo único.

Fase 4. Envío del nuevo fragmento a través de la red al servidor Avamar o Data Domain

Cuando un cliente envía un fragmento nuevo y único (de hasta 64 KB de tamaño) al servidor, el rendimiento depende principalmente del ancho de banda de la red. Esto afecta principalmente a los clientes basados en WAN que generan una gran cantidad de datos modificados cada día. También puede afectar a aquellos que operan a través de enlaces de red congestionados. 

A continuación, se muestran esquemas que muestran el flujo de datos donde un cliente envía datos a un sistema Avamar y a un sistema integrado Avamar - Data Domain.






Recursos críticos: Ancho de banda de red entre el cliente y el servidor

Fase 5. Datos escritos en Avamar Server o Data Domain

Los datos de respaldo se deben escribir en el servidor Avamar o en el sistema Data Domain.

Recursos críticos: Rendimiento de escritura en disco y carga general del servidor Avamar.