Avamar: Un par de replicación muestra diferentes niveles de uso de capacidad. Cómo investigar las causas.

Causas y posibles razones de las diferencias entre los valores de “utilización del servidor”:

Diferencias lógicas o físicas entre las cuadrículas:

• Un cantidad diferente de nodos de datos en las cuadrículas de origen y de destino.
• Los nodos de datos de cada cuadrícula tienen diferentes configuraciones de disco.
• Distribución adecuadamente equilibrada de franjas entre los nodos de datos dentro de cada sistema (con una diferencia del 2 %)
• Los requisitos de almacenamiento y paridad difieren entre las versiones de Avamar. Se puede observar una diferencia en el uso si las versiones de software de origen y de destino difieren.
• El nivel de solo lectura del disco del Avamar Server puede diferir entre las dos cuadrículas.   
• Es posible que una cuadrícula esté configurada para la paridad RAIN, pero la otra no.

Configuración de replicación:

• Los respaldos replicados en el sistema de destino pueden tener una política de retención diferente en comparación con los de origen. Revise la marca expiredelta para obtener más información. También es posible que los respaldos replicados solo cubran un período de tiempo determinado. Por ejemplo, las últimas 4 semanas de respaldos del origen.
• La replicación se puede configurar para replicar solo un subconjunto de clientes del sistema de origen al sistema de destino. Compruebe si se utilizan configuraciones de “inclusión” o “exclusión”.
• Es posible que los clientes y sus respaldos asociados se hayan eliminado del sistema de origen. La eliminación de un cliente o de respaldos en el origen no elimina los mismos respaldos del sistema de destino. Los respaldos permanecen en el destino hasta que venzan de acuerdo con la configuración de retención.
• Las políticas de retención se pueden cambiar para respaldos o clientes en el sistema de origen. El cambio en las políticas de retención solo afecta a los nuevos respaldos. Los nuevos respaldos se replican en el destino y cumplen con la política de retención actualizada. Los respaldos que ya existen en el destino conservan la política de retención que se les aplicó cuando se replicaron.

Actividad previa a la administración de capacidad:

• No es inusual que los clientes observen que uno de los sistemas de pares de replicación de Avamar está cerca de su capacidad máxima y actúen para reducirla. Recuerde que un par de replicación de Avamar consta de dos sistemas administrados de manera independiente. Si se llevan a cabo acciones en un sistema, también se deben realizar en el otro. 
• Si se eliminan respaldos o se reducen las retenciones en el sistema de origen, se deben realizar cambios idénticos en el de destino. La mejor manera de administrar la capacidad de esta manera es con el script modify-snapups. Esto se puede ejecutar en ambos Avamar Servers con las mismas opciones de modificación o eliminación de respaldo.  

Estructura de franjas diferente (por ejemplo, más franjas de paridad en un sistema):

• Al ser independientes, dos sistemas Avamar pueden terminar con estructuras de franjas diferentes. Los sistemas de múltiples nodos pueden presentar diferencias debido a su uso de franjas de paridad para proteger los datos. Según su historial de capacidad, dos sistemas de múltiples nodos contienen los mismos respaldos, pero uno podría tener una mayor cantidad de franjas de paridad que el otro.
• Al igual que las franjas regulares, una franja de paridad siempre permanece en el sistema una vez creada. A diferencia de las franjas normales, esta siempre consume una cantidad fija de espacio dentro del Avamar Server. Esto es así incluso si las franjas seguras de su grupo de paridad no contienen datos. La recolección de elementos no utilizados no tiene ningún efecto en este comportamiento.
• Un sistema de destino de replicación está protegido indirectamente contra problemas de capacidad importantes en la fuente de replicación. Sin embargo, la situación podría ocurrir en cualquiera de las máquinas si una de ellas está mal administrada desde una perspectiva de capacidad.
• Artículo relacionado: Avamar muestra hasta ~30 % de uso incluso después de que se hayan eliminado todos los respaldos y se hayan recolectado los elementos no utilizados

Respaldos aún en MC_DELETED:

• Un caso poco frecuente que se debe tener en cuenta es cuando un cliente se elimina en la fuente, pero se conservan sus respaldos. Esto podría dar lugar a que la fuente tenga una mayor utilización que la de destino, en la que se espera que los respaldos caduquen de forma natural. El uso del script dump_root_hashes.rb con la opción backupcompare ayuda a comprobar esta situación.

Datos en el sistema de destino de respaldos no replicados:

• Si el sistema replica en *una sola dirección*, compruebe en el destino que no existan clientes fuera de /REPLICATE y MC_SYSTEM.

Otros comportamientos:

• Es posible que las tareas de replicación no se completen de manera confiable. Los datos enviados al destino pueden retrasarse varios días con respecto a la fuente.
• Ambos sistemas contienen la misma cantidad de datos desduplicados, pero la cantidad de sobrecarga de paridad en cada uno de ellos es diferente. Esto ocurre en la siguiente situación: 
  • Un sistema de origen Avamar está casi lleno. 
  • Muchos respaldos se eliminan del sistema de origen para reducir su nivel de capacidad. 
  • Luego, se produce la replicación de los datos desduplicados del origen al destino. 
  • La cantidad de datos desduplicados es la misma en ambos sistemas.
  • Inicialmente, el sistema de origen almacena más sobrecarga de paridad que el sistema de destino.
• La replicación no copia las franjas físicas desde la cuadrícula de origen hasta la de destino. En su lugar, se permite que la cuadrícula de destino determine por sí misma dónde se almacenan las franjas y los fragmentos de datos.
• En ocasiones, los sistemas Avamar de destino pueden almacenar datos de manera más eficiente que una cuadrícula de origen en la que los datos se respaldaron originalmente.

Comprenda el entorno de replicación:

• Anote el nombre de host completo de la cuadrícula de origen Avamar.
• Examine la configuración de replicación de los sistemas afectados para comprender qué sistemas replican qué datos y hacia dónde. 
  • Puede resultar útil dibujar un esquema del entorno si es algo más complicado que la replicación de un Avamar Server a otro.
• Si el origen se integra con Data Domain (DD), descubra si la preocupación del cliente se relaciona con los respaldos replicados entre dispositivos DD.
• Tome nota del nombre de host completo de la cuadrícula de destino de Avamar y de cualquier dispositivo DD asociado que reciba respaldos replicados.

Verifique el estado general y la situación de la cuadrícula:

• Ejecute el script de verificación proactiva en ambas cuadrículas, obtenga una copia de hc_results.txt y revíselo para comprender la situación general del sistema. 

¿Qué tan grave es el diferencial de capacidad?

• El cliente debe proporcionar una captura de pantalla que muestre lo que ve y que lo lleva a creer que existe un diferencial de consumo de capacidad entre el origen y el destino.
• No consideramos que haya motivo de alarma si la diferencia de capacidad es inferior al 5 %.
• Compruebe la interfaz de usuario de Avamar Administrator para comprender los niveles de capacidad de Avamar Server y (si Data Domain está integrado) la capacidad de los metadatos.
• Tenga en cuenta cómo funciona la visualización de capacidad de la interfaz de usuario (analizada en El tablero de la interfaz del usuario de Avamar en la versión 7.2 muestra la utilización de metadatos, en lugar de Avamar Utilization).
• Ejecute el siguiente comando en ambos sistemas. El valor de utilización del servidor proporciona un valor general de los niveles de capacidad del Avamar Server (pero no de Data Domain):

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Verifique que el hardware sea el mismo en ambas cuadrículas:

• Solo tiene sentido comparar las diferencias de capacidad para sistemas “similares”. 
• Con el resultado de la verificación proactiva, observe el tipo de nodos presentes en el sistema.
• El siguiente comando muestra la cantidad general, el tamaño y el consumo de espacio en los nodos físicos:

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Este resultado facilita la determinación de la cantidad y el tamaño de los nodos en el sistema. Son (23,3/3 = aprox. 7,8 TB). 
• La cantidad y el tamaño de las particiones de disco duro en cada nodo deben corroborar esto.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• Con esta información, compruebe lo siguiente:

Compruebe la versión y configuración del software:

• Con el resultado del comando status.dpn, compare la versión de Avamar que se ejecuta en cada sistema.
• En el caso de los sistemas de múltiples nodos, confirme que ambos estén configurados con paridad RAIN según Avamar: Cómo determinar si un servidor tiene o no RAIN
• Compruebe y compare los parámetros de configuración de Avamar Server relacionados con la capacidad de los dos sistemas. Por ejemplo:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Compruebe el balanceo de franjas:

• Compruebe el resultado status.dpn y anote la cantidad total de franjas en cada nodo de datos. El número de franjas se identifica entre paréntesis (por ejemplo,onl:xxx). 
• Debe haber menos del 2 % de diferencia entre la cantidad total de franjas en cada nodo de datos.  

Compruebe que la recolección de elementos no utilizados se haya ejecutado correctamente en ambos sistemas:

• Si la recolección de elementos no utilizados no se ejecuta de manera coherente y eficaz, no eliminará los datos vencidos. El sistema informa un uso de capacidad superior al esperado. 
  • Consulte el artículo Ruta de resolución de GC en las notas restringidas para obtener más información.  

Confirme que la replicación se completa correctamente:

• Asegúrese de que todas las tareas de replicación de origen a destino se completen correctamente. Si esto no ha sucedido, es posible que aún queden datos por replicar del origen al destino.  

Verifique la configuración de replicación:

• Verifique la configuración de replicación (en la interfaz de usuario, la CLI o los registros) en busca de cualquiera de las siguientes marcas:  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Verifique las tasas de ingesta y eliminación de datos de ambos sistemas:

• Ejecute proactive_check.pl --capacity en ambos sistemas y compare las tasas de ingesta de los sistemas de origen y de destino.
• Si el destino es solo un sistema de destino y recibe TODOS los respaldos del origen, su tasa de ingesta debe seguir de cerca la tasa de ingesta del origen.
• Las columnas NEW o DDR NEW de Avamar muestran la cantidad de datos nuevos que se agregan a esos sistemas.
• También preste mucha atención a las columnas “removed”, “mins” y “pass” para comprender el comportamiento de la recolección de elementos no utilizados en ambos sistemas.
• Esta información brinda una visión clara de lo que está sucediendo en ambos sistemas.
• Para obtener más información sobre la interpretación del resultado, consulte Avamar: Cómo administrar la capacidad con el script de capacity.sh  

Descargue una lista de respaldos existentes en cada sistema:

• El script dump_root_hashes.rb es una utilidad que ayuda a comparar la diferencia en los respaldos almacenados entre un sistema Avamar de origen y uno de destino. Esto es así incluso si los respaldos se alojan en el almacenamiento de Data Domain.   
• Consulte Avamar: Avamar: Cómo utilizar el script dump_root_hashes.rb para generar una lista de clientes y respaldos para obtener información sobre la descarga de la utilidad y los casos de uso, incluida la comparación del contenido de dos sistemas Avamar.
  • Ejecute la herramienta. Compruebe si hay incoherencias en los conteos de los respaldos en todos los clientes. Preste atención a las diferencias de +/-2.  
• Como se analiza en la sección Causes, la administración asimétrica de la capacidad genera diferencias entre los dos sistemas. Revise el resultado para determinar si este podría ser el caso.
• Además:
  • Verifique en el destino si hay datos provenientes de respaldos no replicados en el sistema de destino.
  • Verifique en el origen si hay datos que no se hayan replicado en el destino.  

Verifique si hay diferentes estructuras de franjas (por ejemplo, más franjas de paridad en un sistema):

• Al ser independientes, los dos sistemas Avamar pueden tener estructuras de franjas diferentes. Los sistemas de múltiples nodos pueden presentar diferencias debido a su uso de franjas de paridad para proteger los datos. Según su historial de capacidad, dos sistemas de múltiples nodos contienen los mismos respaldos, pero uno podría tener una mayor cantidad de franjas de paridad que el otro.  
• Al igual que las franjas regulares, una franja de paridad permanece en el sistema una vez creada. A diferencia de las franjas normales, una franja de paridad siempre consume una cantidad fija de espacio dentro de Avamar, incluso si las franjas seguras del grupo de paridad no contienen datos. La recolección de elementos no utilizados no tiene ningún efecto en este comportamiento.
• Un sistema de destino de replicación está protegido indirectamente contra problemas de capacidad importantes en la fuente de replicación. Sin embargo, la situación podría ocurrir en cualquiera de las máquinas si una de ellas está mal administrada desde una perspectiva de capacidad.
• Artículo relacionado:  Avamar muestra hasta ~30 % de uso incluso después de que se hayan eliminado todos los respaldos y se hayan recolectado los elementos no utilizados  

Respaldos aún en MC_DELETED:

• Un caso poco frecuente que se debe tener en cuenta es cuando un cliente se eliminó en la fuente, pero se conservaron sus respaldos. Esto da lugar a que la fuente tenga una mayor utilización que la de destino, en la que se espera que los respaldos caduquen de forma natural. El uso del script dump_root_hashes.rb con la opción backupcompare debería ayudar a comprobar esta situación.