Avamar: Capacidad del sistema operativo (SO) (ruta de resolución)

Cómo manejar o solucionar problemas de capacidad del SO en Avamar.

Este artículo de ruta de resolución está diseñado para abordar o solucionar problemas de capacidad del SO en Avamar.


Para conocer los conceptos iniciales y la comprensión de la capacidad del SO, consulte el artículo de capacitación Avamar: Conceptos y capacitación

de administración de capacidadComo se resume en el artículo de capacitación, se debe requerir una comprensión razonable de los siguientes temas para continuar con el resto de este artículo:

• Una comprensión básica de los puntos de control (cp), la validación de puntos de control (hfscheck)y la Recolección de Elementos No Utilizados (GC), y la importancia de cada
• La diferencia entre GSAN (también conocida como "capacidad de usuario" y capacidad del sistema operativo)
• Datos de sobrecarga de puntos de control
• Si alguna de las particiones de datos es superior al 89 % del espacio total de capacidad física del SO, la recolección de elementos no utilizados no se puede ejecutar.
• Cuanto más cerca esté una cuadrícula de Avamar del 100 % de la capacidad del usuario, menor será la capacidad del SO disponible para la sobrecarga de los puntos de control.
• Factores que contribuyen a la sobrecarga de los puntos de control, incluido el procesamiento asíncrono, la cantidad de puntos de control almacenados, HFSCheck y la importancia de la validación de los puntos de control, etc.
• Cómo encontrar los niveles de capacidad del SO
• Acciones básicas para aliviar la capacidad del SO

A menudo, es más fácil considerar la capacidad del SO como el tamaño del GSAN datos (más específicamente, el espacio asignado para estos datos) y la sobrecarga generada por los puntos de control de Avamar. Cuanto mayor sea la cantidad de puntos de control y mayor sea la tasa de cambio, mayor será la sobrecarga del punto de control.

Los impactos de una alta capacidad del SO pueden incluir:

• Falla en la recolección de elementos no utilizados: La GC falla con MSG_ERR_DISKFULL si la capacidad del SO supera el 89 %
• Falla de respaldo o replicación: Los respaldos o la replicación entrante pueden fallar con MSG_ERR_STRIPECREATE si la capacidad del SO supera el 90 %. (Esto es solo si se debe crear una nueva sección de datos. Si no se necesita una nueva sección, es posible que los respaldos y la replicación aún se ejecuten correctamente).
• Falla del punto de control: Un punto de control falla con MSG_ERR_DISKFULL si la capacidad del SO supera el 96 %

Como lo indica lo anterior, la capacidad del SO suele ser el primer tipo de capacidad de Avamar que se debe abordar cuando otras capacidades de Avamar también son altas. Como mínimo, la recolección de elementos no utilizados no se puede ejecutar cuando la capacidad del sistema operativo alcanza ciertos niveles, incluso cuando el GSAN o la capacidad de los usuarios también es alta.

Por lo general, la capacidad del SO se considera alta cuando GC falla con MSG_ERR_DISKFULL si la capacidad del SO aumenta por encima del 89 %. Si la capacidad del SO es inferior al 89 %, no se verán afectados los trabajos de mantenimiento. 

La capacidad del SO de Avamar puede aumentar debido a una combinación de las siguientes razones:

• Alta tasa de cambio de datos de respaldo, agregando "demasiado demasiado rápido"
• Alta GSAN o "Capacidad de usuario", que deja menos espacio para la capacidad del sistema operativo y, a veces, incluso puede dar lugar a tasas de cambio más altas
• El punto de control no se completa correctamente, lo que da como resultado el estado "MSG_ERR_DISKFULL", como se ve en el resultado.
• Una validación de punto de control (hfscheck) falló o no se ejecutó recientemente, de modo que los puntos de control más antiguos no se pueden quitar ni revertir
• Los puntos de control no se desactivan por otros motivos, incluida una configuración de retención de puntos de control demasiado alta

La alta capacidad del sistema operativo en otras particiones de disco puede deberse a diversas causas, incluida la ubicación incorrecta de los datos, que los archivos de registro sean demasiado grandes, etc.

• Como antecedente, los puntos de control de Avamar son una instantánea de solo lectura y un enlace a los datos en tiempo real. Dado que esto se crea con vínculos, un punto de control no utilizará espacio de disco adicional inmediatamente después de su creación. Si no hay cambios en los datos activos, el punto de control no utiliza espacio adicional.
• Esto cambia a medida que se modifican los datos en vivo mientras que el punto de control sigue siendo el mismo. En ese momento, hay una copia original de los datos en el punto de control y la Live Copy actualizada de los datos modificados. Esto es completamente intencionado y por diseño. Esta es la razón por la que hay espacio reservado para la capacidad del SO.
• Sin embargo, si la cantidad o la tasa de los datos de cambio aumentan de manera drástica y repentina, esto puede causar un pico poco común en el tamaño de la capacidad del SO y considerarse "demasiado demasiado rápido"
• La variable capacity.sh mostraría esto como la causa al comparar el resultado en varios días.

Si los trabajos de mantenimiento, incluida la recolección de elementos no utilizados, fallan con la alta capacidad del SO Avamar, siga estos pasos:

1. Recolecte toda la información de capacidad de Avamar para hacerse una idea de la situación: Avamar: Cómo recopilar la información necesaria para solucionar problemas de capacidad.

2. A continuación, revise qué tan alta es la capacidad del SO y qué acciones pueden ser necesarias. En el artículo de recolección de datos, esto se puede encontrar mediante el siguiente comando: 

avmaint nodelist | egrep 'nodetag|fs-percent-full'

La forma en que funciona Avamar es que el valor MÁS ALTO para fs por ciento lleno que se muestra es el factor limitante para la capacidad actual del SO. Según la generación y el tamaño del tipo de nodo, la cantidad de particiones de datos que almacenan datos de respaldo y punto de control puede variar. Como se ve desde el sistema operativo Linux, estos pueden ser discos o particiones como "/data0*", donde "*" puede ser un solo dígito. La cantidad de particiones de datos depende del tipo de nodo, la generación del hardware y el tamaño (y no se puede cambiar).

3. Revise la cantidad de puntos de control encontrados y cuán recientemente se validaron desde el comando:

cplist

cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980

4. Ejecute el siguiente comando para verificar si las operaciones de punto de control fallan desde "MSG_ERR_DISKFULL":

dumpmaintlogs --types=cp --days=4 | grep "\<430"

Si los puntos de control se completaron correctamente, se observa un resultado similar al siguiente:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

Si se produjo un error debido a MSG_ERR_DISKFULL, se observa esta salida:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

6. Determine la tasa de cambio:

capacity.sh  

Ejemplo del mensaje de salida:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

A veces, si se repite la alta tasa de cambio o la situación de "demasiado y demasiado rápido", esto se puede aliviar reduciendo la tasa de cambio general GSAN o la capacidad de los usuarios. Con un menor GSAN capacidad, hay un poco más de espacio para la sobrecarga de capacidad del SO y también da como resultado menos cambios en el contenedor de almacenamiento de datos. Para obtener ayuda con esta situación, abra una solicitud de servicio con el equipo de soporte de Avamar de Dell Technologies; de lo contrario, continúe desde el paso 7.

7. Los problemas con las altas capacidades del sistema operativo en otras particiones de disco tienen varias causas, pero las soluciones requieren soporte técnico. Abra una solicitud de servicio con el equipo de soporte de Avamar de Dell Technologies; de lo contrario, continúe desde el paso 7.

Una vez que se aborda la capacidad del SO, GSAN se puede revisar la capacidad u otras capacidades de Avamar. Consulte Solución de problemas, problemas y preguntas de capacidad de Avamar: toda la capacidad (ruta de resolución)