Contenido

Introducción

Prerequisites

Requirements

Archivos de registro necesarios

Análisis de registros para pistas iniciales

Recopilar información sobre la configuración de UCS

Sugerencia de supervisión proactiva de FI

Información Relacionada

Introducción

El documento proporciona los pasos necesarios para investigar la caída de Unified Computing System Fabric Interconnect (FI) o la falla inesperada de reinicio.

En un nivel alto, los siguientes problemas podrían resultar en el reinicio de FI

- El proceso de espacio del núcleo se ha roto (también conocido como pánico del núcleo)

- El núcleo se ha quedado sin memoria (sin memoria - OOM ha eliminado un proceso de usuario para recuperar memoria)

- El proceso de espacio del usuario se ha interrumpido ( p. ej. - netstack, fcoe_mgr , callhome etc )

- Problema de firmware FI (situación poco común, ejemplo - CSCuq46105 ) o falla de componente de hardware (como SSD utilizado para almacenamiento )

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

Cisco Unified Computing System (UCS) Manager

Interfaz de línea de comandos (CLI) de Cisco Unified Computing System (UCS) Manager

Archivos de registro necesarios

Cuando FI se reinicie inesperadamente, recopile los registros siguientes y cárguelos en la Solicitud de servicio del TAC.

- paquete de registro de soporte técnico de UCSM

- Verifique si el archivo de vaciado de memoria se crea alrededor del momento del evento de reinicio.

Puede comprobar si hay archivos de vaciado de núcleos a través de CLI o GUI

Supervisión del alcance de UCS-FI

UCS-FI /monitor # scope sysdebug

UCS-FI /monitor/sysdebug # show cores detail

- Si la FI se ha configurado para exportar registros al servidor syslog, recopile mensajes de registro del servidor syslog para el dispositivo que proporciona 7 días de historial antes de la indicación de fecha y hora del reinicio.

- Rastro de pila del núcleo ( Si el reinicio se debe al pánico del kernel )

Análisis de registros para pistas iniciales

1) Compruebe la razón del reinicio y la marca de tiempo de la salida del comando del sistema operativo Nexus (NX-OS) " show version "

2) Verifique la salida del comando " show logging nvram " para los mensajes de registro antes de la indicación de hora de reinicio

3) Verifique los mensajes de registro almacenados en el servidor syslog para obtener pistas adicionales

4) Si el reinicio fue activado por el desperfecto del proceso de espacio del usuario, verifique el vaciado de memoria que coincida con el nombre del proceso y la marca de hora de reinicio.

6) Si es pánico en el kernel, verifique si hay resultado de seguimiento de pila en el archivo denominado " sw_kernel_trace_log "

Desde UCSM 2.2.1b, este archivo se incluye en el paquete UCSM show techsupport.

Para la versión de UCSM anterior a 2.2.1b, recopile el resultado de los siguientes comandos

connect nxos

show logging onboard  kernel-trace | no-more

show logging onboard  obfl-history | no-more

show logging onboard  stack-trace | no-more

show logging onboard internal kernel | no-more

show logging onboard internal kernel-big | no-more

show logging onboard internal platform | no-more

show logging onboard internal reset-reason | no-more

7) " topout.log "contiene el resultado del comando " top " cada dos segundos. Antes del reinicio, UCSM guarda el antiguo conjunto de registros como archivo /opt/sam_logs.tgz. Puede proporcionar información sobre la memoria, la utilización o los procesos.

8) Si observa que mensajes como Out of Memory (OOM) han matado un proceso y la caída del proceso podría desencadenar el reinicio de FI y se indicaría como razón de reinicio.En tales escenarios, es muy probable que el proceso sea víctima de una condición de memoria baja y que no sea la causa detrás de la caída o la pérdida de memoria.

Recopilar información sobre la configuración de UCS

Responder a las siguientes preguntas ayuda a comprender mejor la configuración del sistema y su estado antes del reinicio.

1) ¿Este problema ha ocurrido antes?

2) ¿Había actividad específica del usuario en el momento del reinicio?

3) ¿Se ha realizado algún cambio reciente en el FI en software, hardware o configuración?

4) ¿Hay alguna aplicación externa que supervise las redes Wi-Fi (a través de SNMP , API XML )?

5) En caso afirmativo, ¿con qué frecuencia consultan los datos al FI?  ¿Qué información se consulta a intervalos regulares con esta aplicación? (ex consultas SNMP )

6) ¿Ha habido alguna tormenta de tráfico hacia el puerto de administración de FI?

7) ¿Se ha configurado esta escala? (Número de chasis, blades, interfaces virtuales)

Sugerencia de supervisión proactiva de FI

1) Configure UCSM para exportar registros al servidor syslog

2) Recopile el resultado de " show processes " de la administración local a intervalos regulares para monitorear la tendencia en CPU y memoria

uso de procesos. Esto no es necesario si la FI ya está siendo monitoreada por una aplicación externa.

Información Relacionada

Guía de configuración de Cisco UCS Manager