Contenu

Introduction

Conditions préalables

Conditions requises

Fichiers journaux requis

Analyse des journaux pour les indices initiaux

Collecte d'informations sur la configuration UCS

Suggestion pour la surveillance proactive des FI

Informations connexes

Introduction

Le document fournit des étapes pour étudier le plantage de l'interconnexion de fabric Unified Computing System ( FI ) ou l'échec inattendu du redémarrage.

À un niveau élevé, les problèmes suivants pourraient entraîner le redémarrage de FI

- Le processus d'espace du noyau s'est interrompu ( alias panique du noyau )

- Mémoire insuffisante dans le noyau ( Mémoire insuffisante - OOM qui tue un processus utilisateur pour récupérer la mémoire )

- Le processus d'espace utilisateur s'est écrasé ( ex. - netstack, fcoe_mgr, callhome etc )

- Problème de microprogramme FI ( scénario rare, exemple - CSCuq46105 ) ou défaillance de composant matériel ( comme SSD utilisé pour le stockage )

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

Cisco Unified Computing System (UCS) Manager

Interface de ligne de commande (CLI) de Cisco Unified Computing System (UCS) Manager

Fichiers journaux requis

Lorsque le module FI redémarre de manière inattendue, collectez les journaux suivants et téléchargez-les dans la demande de service du centre d'assistance technique.

- Offre groupée du journal de support technique UCSM

- Vérifiez si le fichier de vidage principal est créé au moment de l'événement de redémarrage.

Vous pouvez rechercher des fichiers de vidage de coeurs via l'interface de ligne de commande ou l'interface utilisateur graphique

Surveillance de l'étendue UCS-FI

UCS-FI /monitoring # scope sysdebug

UCS-FI /monitoring/sysdebug # show coeurs detail

- Si l'IF a été configuré pour exporter des journaux vers le serveur syslog, collectez les messages du journal à partir du serveur syslog pour le périphérique qui fournit 7 jours d'historique avant l'horodatage de redémarrage.

- Suivi de la pile du noyau ( Si le redémarrage est dû à la panique du noyau )

Analyse des journaux pour les indices initiaux

1) Vérifiez la raison et l'horodatage du redémarrage à partir de la sortie de la commande Nexus Operating System (NX-OS) " show version "

2) Vérifiez la sortie de la commande show logging nvram " pour les messages de journal avant le tampon d'heure de redémarrage

3) Vérifiez les messages du journal stockés sur le serveur Syslog pour obtenir des indices supplémentaires

4) Si le redémarrage a été déclenché par une panne du processus de l'espace utilisateur, vérifiez le vidage principal qui correspond au nom du processus et à l'horodatage du redémarrage.

6) S'il s'agit d'une panique du noyau, vérifiez la sortie de suivi de la pile du noyau dans le fichier nommé " sw_kernel_trace_log "

À partir d'UCSM 2.2.1b, ce fichier est inclus dans l'offre UCSM show techsupport.

Pour la version UCSM antérieure à la version 2.2.1b, veuillez collecter les résultats des commandes suivantes

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 " contient la sortie de la commande " top " toutes les deux secondes. Avant le redémarrage, UCSM enregistre l'ancien jeu de journaux sous forme de fichier /opt/sam_logs.tgz Il peut fournir des informations sur la mémoire, l'utilisation ou les processus.

8) Si vous remarquez que des messages tels que OOM (Out of Memory) ont tué un processus et que le crash du processus peut déclencher le redémarrage de FI et être répertorié comme raison de réinitialisation.Dans de tels scénarios, il est probable que le processus soit victime d'une condition de mémoire insuffisante et ne soit pas à l'origine d'une panne ou d'une fuite de mémoire.

Collecte d'informations sur la configuration UCS

Répondre aux questions suivantes permet de mieux comprendre la configuration du système et son état avant le redémarrage.

1) Ce problème est-il déjà survenu ?

2) Existe-t-il une activité utilisateur spécifique au moment du redémarrage ?

3) Des modifications récentes apportées aux logiciels, au matériel et à la configuration au FI ?

4) Le Wi-Fi est-il surveillé par des applications externes ( sur SNMP, API XML ) ?

5) Si oui, à quelle fréquence les applications interrogent l’IF pour obtenir des données ?  Quelles informations sont collectées à intervalles réguliers par cette application ? ( ex requêtes SNMP )

6) Y a-t-il une tempête de trafic vers le port de gestion FI ?

7) Cette mise à l'échelle est-elle configurée ? ( Nombre de châssis, lames, interfaces virtuelles )

Suggestion pour la surveillance proactive des FI

1) Configurer UCSM pour exporter les journaux vers le serveur syslog

2) Collecter à intervalles réguliers le résultat de la commande show processes à partir de la gestion locale pour surveiller la tendance du processeur et de la mémoire

utilisation des processus. Cela n'est pas nécessaire si l'IF est déjà surveillée par une application externe.

Informations connexes

Guide de configuration de Cisco UCS Manager