Avamar: Particiones suspendidas, fracciones y fallas de hfscheck en Avamar

1. Es posible que aparezca el siguiente error en la interfaz de usuario del servidor de Avamar Administrator. El mensaje puede generar una solicitud de servicio de devolución (SR):

Symptom Code: 22632, Desc: A server disk has become suspended.

2. Mensajes de ADVERTENCIA relacionados con perfbeat subproceso se informan en los nodos de almacenamiento de datos en el /data01/cur/gsan.log:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66
WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended
WARN: <1084> changing disk 0 on node 0.3 to suspended state

3. La variable status.dpn muestra que un disco tiene secciones suspendidas:
(esta salida solo se produce cuando se produce "WARN <1084>").

Por ejemplo:

0.8 10.10.10.10 7.3.1-125 ONLINE fullaccess mhpu+0hpu+0hpu 1 false 7.36 16350564 3401334 56.0% 66%(onl:1,SUS:2374) 50%(onl:2439) 50%(onl:2433) 

Este resultado muestra que hay 2374 secciones suspendidas.

4. La variable hfscheck falla si una partición se suspende mientras el hfscheck se está ejecutando. Un ejemplo de un error de /data01/hfscheck/err.log o /data01/cur/err.log son: 

ERROR: <0001> indexstripe::hfschecksweepbody stripe=0.0-1209 proxy=0.0-1209 indexelem([hash=ee9b2fe66b4bd472e28c4f41c5097dbeaba7131a stripe=0.1-DF8 offset=1285]) goodowner=true goodelem=false

Periódicamente, cada cinco minutos de forma predeterminada, el gsan "prueba" el I/O realizando pequeñas lecturas de las particiones de datos.

Verifica si el rendimiento de lectura es un 10 % superior al rendimiento normal.

En el siguiente ejemplo, el mensaje indica que, en el nodo concreto que generó el mensaje de advertencia, el rendimiento de lectura promedio en un número extendido de ensayos, mientras hfscheck es de aproximadamente 54,03 MB/segundo. Sin embargo, en esta prueba en particular, el rendimiento real fue de 0,57 MB/segundo, que está por debajo del "límite" del 10 % del valor promedio, o 5,4029 MB/segundo.

Event Summary = perfbeat::outoftolerance mask=[hfscheck] average=54.03 limit=5.4029 mbpersec=0.57

El propósito original de esta prueba era proporcionar una advertencia de que había algún problema con el I/O que hace que el rendimiento de lectura sea excesivamente lento. 

En este caso, más lento que el 10 % del disco "promedio" I/O rendimiento.

La variable perftriallimit Especifica la cantidad de pruebas de lectura de disco consecutivas que deben estar fuera de tolerancia antes de perfbeat Sospecha que un disco puede estar degradado.

La variable perfinterval (valor predeterminado: 300 s o 5 minutos) especifica cuánto tiempo se debe esperar entre cada perftriallimit prueba.

Cuando… perfbeat sospecha que un disco está degradado, le dice al gsan Para alcanzar un estado de inactividad (detener toda la actividad relacionada con el disco). 

Espera como máximo 20 minutos (cableado) para el gsan para alcanzar este estado antes de que se agote el tiempo de espera y no se suspenda el disco.

Si se alcanza el estado inactivo, entonces perfbeat Realiza perfcoldtriallimit (4 de manera predeterminada) más pruebas de lectura espaciadas perfcoldinterval (predeterminado) con 30 segundos de diferencia.

Solo se suspenderá el disco si todas estas pruebas indican que el disco aún está degradado.

Posibles razones para los discos suspendidos:

• Cuando se intenta alcanzar un estado inactivo, el gsan siempre espera al menos un minuto (cableado). También espera todos los discos gsan pendientes I/O actividades relacionadas para completar o suspender su operación. Sin embargo, después de que se alcanza un estado inactivo, es posible que el sistema operativo siga ejecutando discos I/O, como vaciar su caché. Esta actividad de vaciado es una posible explicación de por qué los discos se suspenden innecesariamente. Con mayores cantidades de memoria, puede haber muchos más datos de caché para vaciar.

• Otra posible explicación es que la información del historial de rendimiento no predice con precisión cuál debe ser el rendimiento de lectura de disco esperado durante varios gsan actividades porque el gsan's El comportamiento ha cambiado demasiado rápido para que el historial se refleje (el historial es un promedio de los últimos 10 días de mediciones de rendimiento).

• Otra posible explicación es que podría haber un problema, como no esperar a todos los gsan disco I/O actividades para completar o suspender su funcionamiento antes de llegar a un estado frío.

Además, la investigación mostró que durante la hfscheck ”indexsweep" (cuando se leen todos los hashes de las franjas de índice y, a continuación, se realizan escrituras aleatorias masivas en muchos archivos de registro de referencia de datos (DRL)) la fase probada I/O El rendimiento disminuye durante un período significativo.

En Avamar Data Store Gen4, Gen4s y Gen4T, las operaciones de escritura se priorizaron sobre las operaciones de lectura y la importancia de probar el rendimiento de lectura de I/O subsistema es mucho más bajo. Además, algunas unidades (como Seagate Megalodon unidades) utilizan algunas técnicas diferentes que pueden confundir las pruebas que se están realizando por el de la perfbeat hilo.

Antecedentes:

Por lo general, se ven tres mensajes de advertencia diferentes en el gsan trozas:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66

La advertencia <0968> indica que había una persona gsan I/O prueba que fue lenta.

Este mensaje se puede ignorar de forma segura.

WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended

La advertencia <1051> indica que hubo suficientes lecturas lentas como para que el gsan se consideró poner la partición de datos en estado suspendido, pero se decidió no hacerlo. Eso es lo que indica MSG_ERR_UNNECESSARY.

Este mensaje se puede ignorar de forma segura.

WARN: <1084> changing disk 0 on node 0.3 to suspended state

La advertencia <1084> indica que gsan puso la partición de datos en un "estado suspendido".

Este mensaje no se debe ignorar.

Solución:

Si las fracciones se colocan en un estado suspendido, utilice las siguientes reglas para investigar y corregir los siguientes escenarios:

Realice lo siguiente para identificar la ubicación de la partición suspendida:

1. Inicie sesión en Avamar Utility Node como administrador.

2. Eleve al privilegio raíz.

3. Cargue las claves raíz según Avamar: Cómo iniciar sesión en Avamar Server y cargar varias claves.

4. Ejecute el siguiente comando para identificar la ubicación de la partición suspendida:

mapall --noerror 'grep -i "suspended" /data01/cur/err.log'

5. Revise los escenarios relacionados con los resultados anteriores:

• • No es necesario que realice otra acción. Las franjas vuelven a estar en línea automáticamente. Es muy probable que hfscheck estaban corriendo. 

• • Si las franjas vuelven a estar en línea automáticamente, es muy probable que la recolección de elementos no utilizados o hfscheck estaban corriendo.
  • IMPORTANTE: Esto podría indicar un problema de disco o algún problema subyacente.
  • Aunque la unidad aún no ha fallado, se debe comprobar mediante los pasos que se indican a continuación:

1. Determine qué discos físicos están asociados con el disco que Avamar suspendió. Los problemas con la suspensión del disco físico dentro de un disco virtual serían la causa principal de una suspensión:

avsysreport pdisk vdisk=x 

Donde x es el número del disco virtual (partición de datos) que se suspendió. Por ejemplo, si la primera partición de datos muestra secciones suspendidas, consulte vdis=0.

2. Verifique que no haya fallas de disco, fallas previstas u otros errores en el nivel del disco físico.

3. Confirme que no haya errores de SCSI en los discos físicos que representen al disco virtual en el nodo en cuestión (determinado en el paso 1). 

grep -i "MRMON\|scsi|Adaptec" /var/log/messages

4. Los discos virtuales en el modo de escritura simultánea pueden provocar suspensiones del disco debido a I/O. Compruebe la política de escritura en la controladora:

mapall --noerror --all+ 'avsysreport vdisk | grep "Write Policy"'  

Si se detecta algún problema en los pasos del 2 al 4, abra una SR con el soporte de Avamar de Dell Technologies para realizar una investigación más detallada.

Escenario # 3: Revisar el valor predeterminado perftriallimit Configuración:

1. Verifique que la carpeta perftriallimit se establece en 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Si la solicitud en perftriallimit es cualquier cosa distinta de cero:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"