Monitorización y búsqueda de cuellos de botella en NetAPP 3140

Previo

Existen herramientas gráficas para controlar esto, pero en este caso se va a utilizar solamente herramientas de comandos.


La monitorización de un sistema de almacenamiento NetAPP se basa principalmente en la interpretación de la salida de los comandos 'sysstat' y 'stats'.

stats

Lista de elementos monitorizables:

#stats list objects
#stats list instances
#stats list counters

Descripción de cada contador

#stats explain [COUNTER]

IOPS

#priv set advanced
#stats show -i SEGUNDOS -n NUMEROPRUEBAS volume:NOMBREVOLUMEN:PARAMETRO

Siendo:

• SEGUNDOS: Tiempo entre mediciones.
• NUMEROPRUEBAS: Número de repeticiones.
• NOMBREVOLUMEN: Volumen a monitorizar.
• PARAMETRO: "read_ops", "write_ops", "total_ops"

vg.-

    filer2*>  stats show -i 3 -n 10 volume:LunsSATA:read_ops volume:LunsSATA:write_ops volume:LunsSATA:total_ops
        Instance read_ops write_ops total_ops
                       /s        /s        /s
        LunsSATA      265       390       656
        LunsSATA      176       253       430
        LunsSATA      221       237       458
        LunsSATA      174       182       356
        LunsSATA      250       256       508
        LunsSATA      349       339       688
        LunsSATA      219      1163      1383
        LunsSATA      207       300       507
        LunsSATA      482       327       809
        LunsSATA      204       346       552

Discos HotSpot

#priv set advanced
 #sysstat -x 1

El valor “Disk Util” indica el nivel de uso del disco con más uso en la lectura actual.
Si este valor está de forma continua en valores del 100% o muy cercanos, significa que al menos un disco es un punto caliente o “hot spot”, lo que indica que está siendo sometido al máximo estrés. Esto afecta al rendimiento, aunque es habitual ver estos valores mientras el sistema ejecuta taréas de reconstrucción de RAID o deduplicación.
¿Existen procesos de deduplicación activos?:

#sis status
#sis status -l

¿Existen procesos de reconstrucción de raid activos?:

#aggr status

Si no se están ejecutando tareas de este tipo, el volumen o agregado que contiene el problema debe pasar por un proceso de “reallocate” para redistribuir de forma balanceada los datos entre todos los discos y eliminar el hot spot.
Para descubrir que disco es un hot-spot:

#stats show disk:*:disk_busy

Muestra el nivel de ocupación de todos los discos. Para saber que disco es exactamente y buscarlo en el agregado:

# storage show disk -a

Los valores aceptables de uso de disco deben situarse por debajo del 70% en media.

Fragmentación/Desfragmentación:

El comando

#filer2*> reallocate measure -o /vol/vol23

sobre un volumen o agregado devuelve valores del estilo (la ejecución tarda varios minutos):

#filer2*> Tue Oct  9 17:38:20 CEST [filer2: wafl.reallocate.check.value:info]: Allocation measurement check on '/vol/vol23' is 1.

El valor de 1 indica una fragmentación óptima (baja). Valores superiores a 4 comienzan a afectar significativamente al rendimiento.
La fragmentación se soluciona con los procesos de “reallocate”. Ejecutar (con cuidado) el comando reallocate para desfragmentar volúmenes y LUNs fragmentadas. Estos procesos deben ser ejecutados siempre que se añadan nuevos discos a agregados ya existentes.
En realidad “reallocate” se puede ejecutar sobre volúmenes, LUNs o agregados, pero sobre estos últimos no es recomendable hacerlo salvo en circunstancias muy especiales y supervisión del soporte de NetAPP.

Latencias de acceso a volúmenes

#priv set advanced
#stats show -i SEGUNDOS -n NUMEROPRUEBAS volume:NOMBREVOLUMEN:PARAMETRO

SEGUNDOS: Tiempo entre mediciones.
NOMBREVOLUMEN: Volumen que se monitoriza.
NUMEROPRUEBAS: Número de testeos.
PARAMETRO: - “read_latency”, “write_latency”, “total_ops”, “avg_latency”.

vg.-

     filer*> stats show -i 1 volume:LunsFC:read_latency volume:LunsFC:write_latency
        Instance read_latency write_latenc
                           us           us
          LunsFC      6786.93      2249.36
          LunsFC      1688.08      1964.02
          LunsFC      6594.67       561.32
          LunsFC      8214.19       210.74
          LunsFC      8856.70       956.05
          LunsFC      7876.88      1415.67
          LunsFC      5996.99      1465.29
        [...]

El límite de latencia en la industria está en 20ms. Por debajo de 20ms de latencia se consideran niveles aceptables. Según profesionales de NetAPP, para volúmenes albergados en discos SATA, la latencia normal se sitúa en torno a los 20ms. Para discos FC sería de unos 5ms. Particularmente para discos SAS,  hay un advisor de NetAPP con la siguiente tabla:

De 0 -1000 us    Good
De 1000 us – 2000 us    Reasonable
De 2000 us – 5000 us    Busy
> 5000 us    Bad

Alineamientos

A partir de On-TAP 8, la forma más sencilla de comprobar el alineamiento de LUNs es ejecutando el comando:

#lun show -v

HITs de Caché

#sysstat -x 1

 Este valor “Cache hit” indica que cantidad de peticiones de lectura son procesadas con información que ya está en caché y no es necesario acceder a disco para obtenerla. Este valor debe ser lo más cercano a 100% para un rendimiento óptimo. Un 100% de hit significa que todas las peticiones se resuelven desde caché. Valores sostenidos de hit por debajo del 85% suponen una merma de rendimiento aunque es un problema de difícil solución.

LUN's Longitudes de cola (Queue Length) y latencias medias

#priv set advanced
#lun stats -o -i5 -c1

Average lantency es la latencia de respuesta de cada LUN en milisegundos. Valores por encima de 20 indican alta carga y afectan negativamente al rendimiento.
Queue Length es la longitud de la cola. Las peticiones de bloques a LUN pueden comenzar a encolarse en caso de no poder ser respondidas al ritmo suficiente. Valores por encima de 2.0 ó 3.0 indican una sobrecarga excesiva de la LUN o del propio sistema completo.
El valor de QFULL, en caso de ser diferente a cero significa que la cantidad de peticiones encoladas en superior a la que el sistema puede atender (superior al tamaño de la cola) y empezará a descartar algunas. Cualquier valor diferente a cero en este item implica un problema de congestión serio en el sistema. Normalmente la longitud máxima de la cola tiene que ver con el buffer y la capacidad de la interfaz física por la que viaja el almacenamiento.

 CONSISTENCY POINTS (CP)

Los CP son operaciones de escritura a disco físico. Normalmente toda la IO se produce desde la memoria caché del sistema, pero periódicamente los cambios son escritos a disco o los datos son recuperados del mismo si no se encuentran en la caché. También se producen por muchas otras cosas.
Observar el tipo de CPs (Columna CP ty)  y el tiempo que consumen (CP time):

#priv set advanced
#sysstat -x 1

Sirve para saber cuantos flush se realiza al disco y la causa. Aunque el tipo de CP es importante, lo es más el CP time, que indica cuanto del tiempo que ha tardado en realizarse el CP se ha usado realmente en tal operación y cuanto se ha desperdiciado (en esperas por los recursos). De esta forma, cuanto más se aproxime al 100% el CP Time, mejor rendimiento habrá pq menos debe esperar la operación en terminarse. El tipo de CP es representativo de cuanto de ocupado está el sistema e idealmente habría pocas. Si no hay CP en ejecución (valor '-'), el CP time lógicamente será 0%.

Explicación de los “CP Type" en este enlace.

CPU

#priv set diag
#sysstat -M 1

 Valores sostenidos por encima del 65% indican cargas altas de CPU. Según NetAPP, valores por debajo de 85% son aceptables.