Einführung
In diesem Dokument werden Schritte zur Untersuchung eines Absturzes des Unified Computing System Fabric Interconnect (FI) oder eines unerwarteten Neustart-Fehlers beschrieben.
Auf allgemeiner Ebene können die folgenden Probleme zu einem Neustart der FI führen
- Kernel Space-Prozess ist abgestürzt ( auch Kernel Panic genannt)
- Dem Kernel ist der Arbeitsspeicher ausgegangen ( Out of Memory - OOM zum Töten eines Benutzerprozesses, um Arbeitsspeicher zurückzugewinnen )
- Der Platz-Prozess ist abgestürzt ( z. B. - netstack, fcoe_mgr, callhome usw. )
- FI-Firmware-Problem ( seltenes Szenario , Beispiel - CSCuq46105 ) oder Hardware-Komponentenfehler ( wie SSD zum Speichern verwendet )
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Cisco Unified Computing System (UCS) Manager
Cisco Unified Computing System (UCS) Manager Command Line Interface (CLI)
Erforderliche Protokolldateien
Wenn FI unerwartet neu startet, sammeln Sie die folgenden Protokolle und laden Sie sie auf TAC Service Request hoch.
- UCSM-Technologie-Support-Protokollpaket
- Überprüfen Sie, ob die Core-Dump-Datei zum Zeitpunkt des Neustarts erstellt wird.
Sie können über CLI oder GUI nach Dump-Dateien für Kerne suchen.
UCS-FI # Überwachung des Umfangs
UCS-FI/Monitoring # Scope Sysdebug
UCS-FI/monitoring/sysdebug # Angabe der Kerne
- Wenn die FI so konfiguriert wurde, dass Protokolle auf den Syslog-Server exportiert werden, sammeln Sie Protokollmeldungen vom Syslog-Server für das Gerät, das 7 Tage im Verlauf vor dem Neustart-Timestamp bereitstellt.
- Kernel-Stack-Trace (Wenn der Neustart auf die Kernel-Panik zurückzuführen ist)
Analysieren von Protokollen für erste Hinweise
1) Überprüfen Sie den Grund- und Zeitstempel des Neustarts vom Nexus-Betriebssystem (NX-OS) Ausgabe des Befehls show version ".
2) Aktivieren Sie die Befehlsausgabe show logging nvram für Protokollmeldungen vor dem Neustart des Zeitstempels.
3) Überprüfen Sie die Protokollmeldungen, die auf dem Syslog-Server gespeichert sind, um weitere Hinweise zu erhalten.
4) Wenn der Neustart durch einen Absturz des Benutzerplatzprozesses ausgelöst wurde, überprüfen Sie das Core Dump, das dem Prozessnamen und dem Neustart-Zeitstempel entspricht.
6) Wenn es sich um eine Kernel-Panic handelt, suchen Sie in der Datei " sw_kernel_trace_log " nach der Kernelstack-Ablaufverfolgungsausgabe.
Ab UCSM 2.2.1b ist diese Datei im UCSM-Supportpaket enthalten.
Für UCSM-Version vor 2.2.1b erfassen Sie die Ausgabe der folgenden Befehle.
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 " enthält alle zwei Sekunden die Ausgabe des Befehls " top ". Vor dem Neustart speichert UCSM alte Protokollsätze als /opt/sam_logs.tgz. Es kann Informationen über Arbeitsspeicher, Nutzung oder Prozesse bereitstellen.
8) Wenn Sie feststellen, dass Meldungen wie Out of Memory (OOM) einen Prozess beendet haben und der Prozess abstürzen könnte einen Neustart des FI auslösen und als Grund für das Zurücksetzen angegeben werden.In solchen Szenarien ist der Prozess höchstwahrscheinlich das Opfer eines niedrigen Speicherzustands und möglicherweise nicht die Ursache für einen Absturz oder Speicherlecks.
Sammeln von Informationen zur UCS-Einrichtung
Die Beantwortung der folgenden Fragen hilft, die Systemeinrichtung und ihren Zustand vor dem Neustart besser zu verstehen.
1) Ist dieses Problem schon einmal aufgetreten?
2) Gab es zum Zeitpunkt des Neustarts irgendwelche Benutzeraktivitäten?
3) Jegliche kürzlich vorgenommenen Software-/Hardware-/Konfigurationsänderungen am FI?
4) Wird Wi-Fi von externen Anwendungen überwacht ( über SNMP , XML API )?
5) Falls ja, wie häufig fragen die Anwendungen das FI nach Daten ab? Welche Informationen werden von dieser Anwendung in regelmäßigen Abständen abgefragt? (ohne SNMP-Abfragen)
6) Wurde Datenverkehr zum FI-Management-Port gestürmt?
7) Ist diese Skalierung konfiguriert? (Anzahl Chassis, Blades, virtuelle Schnittstellen)
Vorschlag für eine proaktive Überwachung des FI
1) Konfigurieren Sie UCSM für den Export von Protokollen auf den Syslog-Server
2) Ermitteln Sie in regelmäßigen Abständen die Ausgabe von " show process " von local-mgmt, um den Trend in CPU und Arbeitsspeicher zu überwachen.
Nutzung von Prozessen. Dies ist nicht erforderlich, wenn die FI bereits von einer externen Anwendung überwacht wird.
Zugehörige Informationen
Konfigurationsleitfaden für Cisco UCS Manager
Feedback