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
Comentarios