Ruta de resolución de capacidad de usuario o GSAN de Avamar

Para obtener los conceptos iniciales y la comprensión de la capacidad del sistema operativo (SO), consulte Avamar: Capacitación general sobre capacidad: ruta de resolución

A menudo es más fácil de considerar GSAN Capacidad como espacio y utilización para respaldos de clientes.

• Conocimientos básicos sobre la desduplicación
• Conocimientos básicos sobre el punto de control, la validación del punto de control (hfscheck), y la Recolección de Elementos No Utilizados, y la importancia de cada uno.
• La diferencia entre GSAN (o Usuario) Capacidad y capacidad del SO
• Tasa de cambio
• Estado de equilibrio

• Falla de respaldo o replicación cuando el estado de acceso a la cuadrícula cambia al "modo de administrador"

  • Un trabajo de respaldo del cliente puede fallar con un mensaje similar al siguiente:  ”avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• La deshabilitación automática del programador de respaldos (hasta que alguien lo confirme y lo borre)

• 80 %: advertencia de capacidad
• 95%: se alcanzó el límite de evaluación del estado (esto a veces puede deshabilitar el programador de respaldo, al menos hasta que se confirme manualmente)
• 100 %: se alcanzó el límite de solo lectura del servidor (la cuadrícula entra en modo de administrador)

1. Debido a la desduplicación, Avamar solo necesita guardar y almacenar los cambios menores y las diferencias entre cada trabajo de respaldo del cliente. A medida que se ejecutan nuevos respaldos (o replicación entrante), puede agregar datos nuevos y aumentar la capacidad o el valor de utilización de Avamar. 
2. Después de una cierta cantidad de tiempo, los respaldos vencerán en función de su retención y vencimiento configurados, y no se encontrarán disponibles para restaurar en la cuadrícula de Avamar. 
3. Cuando se ejecuta el trabajo de mantenimiento de Avamar denominado Garbage Collection (GC), encuentra todas las partes únicas o fragmentos de datos que ya no son necesarios debido a estos respaldos vencidos. GC verifica que ningún otro respaldo actual comparta esos mismos datos (debido a la desduplicación) y , a continuación, elimina o libera esos fragmentos de datos que ya no son necesarios para reducir la capacidad o la utilización del servidor Avamar.

Cuando la cantidad de datos entrantes diarios agregados es aproximadamente la misma que la cantidad de datos diarios que se limpian, esto se denomina "estado estable". Este es el objetivo de todas las cuadrículas de Avamar instaladas.

Antes de instalar y configurar una nueva cuadrícula de Avamar, se realizan cálculos generales de dimensionamiento previos a la instalación a fin de determinar la capacidad necesaria para almacenar los datos de respaldo. Estos cálculos se basan en los requisitos de retención de los clientes y en la cantidad de datos que se respaldarán. También calcula cuántos de esos datos podrían desduplicarse en promedio y así sucesivamente.

1. La recolección de elementos no utilizados no se ejecuta de manera coherente
2. El rendimiento de la recolección de elementos no utilizados es lento o no se ejecuta durante el tiempo suficiente
3. Las estimaciones de desduplicación antes de la instalación en cuadrícula de Avamar no eran lo suficientemente precisas
4. Los datos distintos de los calculados antes de la instalación de Avamar Grid se están respaldando en este Avamar Server.
5. Otras razones

Valide que cada paso de solución de problemas que se indica a continuación sea verdadero para el entorno:

Paso 1. Recogida de datos:

Asegúrese de que no haya otros problemas no relacionados con la capacidad de la cuadrícula de Avamar. Si los hubiera, podrían requerir atención ANTES de solucionar problemas de capacidad.

Esto incluye errores de hardware, problemas de integridad de datos (incluidos los nodos offline), fracciones offline, fallas de validación de puntos de control o trabajos de mantenimiento fallidos. Si alguno de estos presenta un problema, se debe detener la solución de problemas de capacidad y se deben abordar otros problemas. Una vez que se hayan resuelto otros problemas, se puede volver a revisar la capacidad.

Se debe ejecutar una evaluación del estado (Avamar: Cómo ejecutar el script de evaluación del estado de proactive_check.pl en un Avamar Server, pero, como mínimo, la status.dpn puede proporcionar una descripción general rápida y la verificación de la mayoría de esos mismos problemas. Consulte Avamar: Cómo comprender el resultado generado por el comando status.dpn

Consulte el siguiente artículo para obtener información adicional: Avamar: Cómo aplicar correctamente el enfoque de "jerarquía de solución de problemas de Avamar".

Si se requiere asistencia para abordar cualquier problema no relacionado con la capacidad, cree una solicitud de servicio con el equipo de soporte de Avamar de Dell Technologies.

Paso 2. Recopilación de información de capacidad: 

Consulte lo siguiente para obtener toda la información necesaria para solucionar problemas de capacidad de Avamar: Avamar: Cómo recopilar la información para solucionar problemas de capacidad

Por lo menos, el status.dpn o los valores dentro de la interfaz de usuario de Avamar Administration muestran el comando GSAN capacidad.

Paso 3. Compruebe si la capacidad del SO está llena:

El siguiente comando ayuda a mostrar el valor actual de la capacidad del sistema operativo para cada partición de disco. Si alguno de los valores alcanzó o superó el 85 %, como en el resultado de la segunda muestra, se considera alta capacidad del SO:

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

Ejemplos de salidas:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

Solo si la capacidad del SO es inferior al 85 % GSAN La solución de problemas de capacidad continúa. 

Paso 4. Problemas de falta de capacidad que a veces se pueden malinterpretar como capacidad:

Es posible que los respaldos de clientes fallen, no por motivos de "capacidad", sino por motivos de "cuota". A veces, se pueden malinterpretar como capacidad.

Esta situación puede ser confirmada por el status.dpn o algunos de los otros resultados recolectados que muestran una menor capacidad.

También es posible que los respaldos del cliente hayan fallado o no se hayan ejecutado debido a Non-GSAN Razones de capacidad. La información recolectada debe confirmar esto o también se puede ver en la interfaz de usuario de administración de Avamar.

• Avamar: Ruta de resolución de la capacidad de metadatos
• Data Domain: Alta capacidad de la ruta de resolución de integración de Avamar

Si la solicitud en GSAN La capacidad es alta y estas otras capacidades también son altas, la solución de problemas se puede realizar en cualquier orden (excepto para la capacidad del SO, que siempre debe ser la primera).

Paso 5. Balance de secciones y equilibrio de discos del SO:

Las "fracciones" en Avamar son los archivos de contenedor en los que se almacenan los datos de respaldo en los nodos de datos (excepto en el caso de una cuadrícula de Avamar de nodo único).

La expectativa es que las secciones estén "equilibradas" o distribuidas uniformemente entre los diferentes discos y nodos dentro de la cuadrícula; sin embargo, a veces pueden desequilibrarse.

Por diseño en Avamar, el nodo más grande o la partición de disco es el factor limitante cuando se trata de la capacidad de Avamar.

Esto es intencional, de modo que ninguno de los discos o nodos cree más fracciones de las que pueden manejar (o permiten), por lo tanto, tener franjas balanceadas es importante para la capacidad.

Por ejemplo, cuando se agregan nodos de datos adicionales para la expansión de cuadrícula de Avamar, se debe ejecutar el balanceo para distribuir uniformemente las secciones a los nuevos nodos a fin de disminuir el porcentaje general de capacidad de Avamar.

Otro tipo de equilibrio que debe comprenderse es el equilibrio de discos del SO. Esto solo se limita a las particiones de datos en el mismo nodo, no a las particiones en varios nodos. 

Si en el mismo nodo de datos, una partición es mucho más grande o más pequeña que otra partición del mismo nodo, se puede superar un límite llamado "freespaceunbalance". Por lo general, esto ocurre en el SO y no en el GSAN Capacity, se puede informar como un GSAN Problema de capacidad.

Paso 6. Compruebe si la recolección de elementos no utilizados se está completando: 

Ejecute el siguiente comando para obtener información sobre la recolección de elementos no utilizados:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

Idealmente, el resultado mostrará que se completó la GC durante los últimos 30 días:

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

Los mensajes de falla de GC pueden incluir, entre otros, lo siguiente:

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

Si GC presentó fallas, abórdelo primero mediante el siguiente artículo como referencia: Avamar: Solución de problemas de fallas de recolección de elementos no utilizados (GC) (ruta de resolución)
(Si ya resolvió algún problema, vaya al paso siguiente).

Paso 7. ¿GC está funcionando el tiempo suficiente?

un. Ejecute el siguiente comando para comprobar el tiempo máximo permitido para GC:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Resultado de muestra:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

Tome nota de la maxtime value, que en este ejemplo es 14400 (segundos).
(Un valor 0 significa ilimitado)

b. Ejecute el siguiente comando para determinar por cuánto tiempo se ejecuta el GC y cuántas "pasadas" se completan:
(Las pasadas deben realizarse con las capas de los datos de respaldo almacenados. Piensa en el GSAN Capacidad como las capas de una cebolla. Las capas externas deben despegarse o retirarse antes de que se vean las capas internas. Cada pasada es una capa de la GSAN datos almacenados).

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Resultado de muestra:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

Tome nota del número de pases y de la elapsed-time (segundos).

c. Suponiendo que el maxtime es distinto de cero, calcule 2/3 de maxtimey compáralo con el tiempo transcurrido.
(En el ejemplo anterior, 2/3 de 14400 es 9600 y todas las salidas de tiempo transcurrido están muy por debajo de esta cifra).

Varios problemas pueden provocar que GC se ejecute lentamente o que no se analice todo. Esto puede incluir no haber tenido suficiente tiempo para ejecutarse durante una cantidad significativa de tiempo o días en el pasado, configuración incorrecta, errores y más.

Si existen inquietudes sobre el maxtimeo la cantidad de pasadas, cree una solicitud de servicio con el equipo de soporte de Avamar de Dell Technologies para investigar más a fondo.

Paso 8. Si se sospecha que GC no eliminó suficientes datos o los datos esperados:

Si se confirma que GC está en ejecución durante el tiempo suficiente, es posible que los datos no se estén recopilando por razones ajenas al control de la recolección de elementos no utilizados. Esta es una lista de las razones documentadas que generalmente se deben verificar:

un. Verifique que los respaldos estén configurados para que al menos venzan con el tiempo o con regularidad. Si no hay respaldos que venzan con frecuencia, GC no tendrá mucho trabajo que hacer.

b. Utilice este artículo para encontrar los clientes de "tasa de cambio principal": Avamar: Cómo administrar la capacidad con el script capacity.sh. (Revise el "% OF TOTAL" y "CHGRATE".)

c. Verifique los hashes omitidos por Avamar: La recolección de elementos no utilizados de Avamar informa "hashes omitidos" que no se pueden limpiar. Si estos ocurren, pero son poco frecuentes, esto es normal y se puede omitir.

d. Hay una marca o una opción que obliga al servidor Avamar a conservar el último y más reciente respaldo de cada cliente. Esto se utiliza con fines de seguridad, de modo que un cliente no tenga todos los respaldos vencidos accidentalmente. Sin embargo, esto puede causar otros problemas cuando se trata de la limpieza de datos y la recolección de elementos no utilizados. El equipo de soporte de Avamar de Dell Technologies puede confirmar si esta opción está activada.

e. Si los respaldos se cambiaron recientemente de GSAN al back-end de DD o hubo un error accidental GSAN respaldo, pero el GSAN La capacidad no disminuye, cree una solicitud de servicio con el equipo de soporte de Avamar de Dell Technologies para investigar más a fondo.

Paso 9. La cuadrícula de Avamar es insuficiente para la cantidad de datos actuales o previstos que se agregarán:

Una vez que se hayan revisado todas las demás soluciones y las posibles causas para determinar si hay alta capacidad, y esto no es un problema de configuración o un problema con datos accidentales:

Esto significa que los datos pueden requerir la eliminación o la exploración de opciones, como la migración de ciertos clientes a otras cuadrículas de Avamar, la adición de nuevos nodos de datos, etc.

Paso 10. Confirme cualquier evento de capacidad y reanude el programador de respaldo si es necesario:

un. Una vez que se resuelvan los problemas de capacidad, confirme todos los eventos relacionados con la capacidad en la interfaz de usuario de Avamar Admin.

b. Reanude el programador de respaldo:

dpnctl start sched

Para cualquier otra pregunta, capacitación, solución de problemas y más sobre la capacidad de Avamar, consulte: Avamar: Solución de problemas, problemas y preguntas de capacidad: toda la capacidad (ruta de resolución)

• Esta acción en sí misma puede "enmascarar" y ocultar los problemas reales, y solo hacer que vuelvan a aparecer en unos días o semanas después, lo que hace que este trabajo manual sea una pérdida de tiempo.
• Además, es posible que la GC manual no se ejecute de manera tan eficiente ya que se está ejecutando fuera de lo programado.
  • En ocasiones, puede empeorar otros problemas. Para obtener más información, consulte: Avamar: Acerca del uso de la recolección manual de elementos no utilizados

• Por lo general, este cambio o acción no se realiza y no se debe considerar de manera predeterminada. Un ingeniero L2 de Avamar o un experto en la materia (SME) deben aprobar este cambio.
• Lamentablemente, estas acciones a menudo pueden causar daños permanentes a una cuadrícula de Avamar de diversas maneras que solo se pueden resolver mediante la adición de nodos de almacenamiento adicionales o la reimplementación.

Comprenda que ninguna de las acciones enumeradas anteriormente se realiza porque el equipo de soporte desea ayudar a resolver los problemas de capacidad de la manera más beneficiosa.