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
Commentaires