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

Para obtener los conceptos iniciales y una 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 la capacidad de GSAN como el espacio y la utilización de los respaldos de los clientes.

• Conocimientos básicos sobre la deduplicación
• Conocimientos básicos sobre el punto de control, la validación del punto de control (hfscheck), la Recolección de elementos no utilizados y la importancia de cada uno.
• La diferencia entre la capacidad de GSAN (o Usuario) y capacidad del SO
• Tasa de cambio
• Estado estable

• Falla en el respaldo o la 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 respaldos, 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. Gracias a la deduplicación, Avamar solo necesita guardar y almacenar los cambios menores y las diferencias entre cada trabajo de respaldo de los clientes. A medida que se ejecutan nuevos respaldos (o replicaciones entrantes), puede agregar datos nuevos y aumentar la capacidad o el valor de utilización de Avamar. 
2. Después de un cierto 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 GC (Recolección de elementos no utilizados, Garbage Collection), este 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 deduplicació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 de Avamar Server.

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 se calculan cuántos de esos datos podrían deduplicarse 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. Los cálculos de deduplicación antes de la instalación en la cuadrícula de Avamar no fueron lo suficientemente precisos.
4. Otros datos distintos de los calculados antes de la instalación de la cuadrícula de Avamar se están respaldando en este Avamar Server.
5. Otros motivos.

Valide que cada paso de solución de problemas que aparece a continuación se pueda realizar en el entorno.

Paso 1. Recolección de datos:

Asegúrese de que no haya otros problemas que no estén relacionados con la capacidad de la cuadrícula de Avamar. Si los hubiera, es posible que requieran atención ANTES de solucionar los problemas de capacidad.

Esto incluye errores de hardware, problemas de integridad de datos (incluidos los nodos fuera de línea), secciones fuera de línea, fallas de validación de puntos de control o fallas en los trabajos de mantenimiento. 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 proactive_check.pl en un Avamar Server, pero, como mínimo, el status.dpn comando puede proporcionar una descripción general rápida y verificar la mayoría de esos mismos problemas. Consulte Avamar: cómo interpretar 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 la solución de problemas de Avamar”.

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

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

Consulte lo siguiente a fin de 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 comando status.dpn o los valores dentro de la interfaz de usuario de Avamar Administration muestran la capacidad de GSAN .

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 (SO) 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'

Resultados de muestra:

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 % se debe continuar con la solución de problemas de capacidad de GSAN . 

Paso 4. Problemas que no son de capacidad que a veces pueden malinterpretarse como de capacidad:

Es posible que los respaldos del cliente fallen, no por motivos de “capacidad”, sino por motivos de “cuota”. A veces, se pueden malinterpretar como capacidad.

Esta situación puede confirmarse con el comando 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 motivos de capacidad de Non-GSAN . La información recolectada debe confirmar esto o también se puede ver en la interfaz de usuario de Avamar Administrator.

• 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 GSAN 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. Equilibrio de secciones y discos del SO:

Las “secciones” en Avamar son los archivos de contenedor donde 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 de manera uniforme entre los diferentes discos y nodos dentro de la cuadrícula; sin embargo, a veces pueden desequilibrarse.

Según el diseño de Avamar, el nodo o la partición del disco más grande 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 secciones de las que pueden manejar (o se permiten), por lo tanto, tener secciones equilibradas 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 equilibrio para distribuir de manera uniforme 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". Si bien esto ocurre por lo general en el SO y no en la capacidad de GSAN , se puede informar como un problema de capacidad de GSAN .

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 la 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 la GC presentó fallas, abórdelas primero mediante el siguiente artículo como referencia: Avamar: solución de problemas de fallas de la Recolección de elementos no utilizados (GC) (ruta de resolución)
(Si ya resolvió algún problema, vaya al paso siguiente).

Paso 7. ¿La GC se ejecuta durante el tiempo suficiente?

a. Ejecute el siguiente comando a fin de comprobar el tiempo máximo permitido para la 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 del valor maxtime , que en este ejemplo es 14 400 (segundos).
(Un valor 0 significa ilimitado)

b. Ejecute el siguiente comando para determinar durante cuánto tiempo se ejecuta la GC y cuántas “pasadas” se completan:
(Las pasadas deben realizarse con las capas de los datos de respaldo almacenados. Piense en la capacidad de GSAN 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 los datos almacenados de GSAN ).

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 pasadas y de elapsed-time (segundos).

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

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

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

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

Si se confirma que la GC se ejecuta durante el tiempo suficiente, es posible que los datos no se estén recolectando 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:

a. 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, la GC no tendrá mucho trabajo que hacer.

b. Utilice este artículo para encontrar los clientes con la “tasa de cambio más alta”: Avamar: cómo administrar la capacidad con el script de capacity.sh. (Revise “% OF TOTAL” y “CHGRATE”).

c. Verifique los hashes omitidos según Avamar: la Recolección de elementos no utilizados de Avamar informa los “hashes omitidos” que no se pueden limpiar. Si esto ocurre, pero es poco frecuente, es normal y se puede omitir.

d. Hay una marca o una opción que obliga a Avamar Server 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 respaldo accidental de GSAN , pero la capacidad de GSAN no disminuye, puede Crear una solicitud de servicio para 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 los que se prevén agregar:

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 respaldos si es necesario:

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

b. Reanude el programador de respaldos:

dpnctl start sched

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

• Esta acción en sí misma puede “enmascarar” y ocultar los problemas reales, lo que provocaría 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 SME (Subject Matter Expert, experto en la materia) 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.