Fehlerbehebung: Server-Fehler nicht zugänglich auf UCS-Servern

Einleitung

In diesem Dokument wird die Fehlerbehebung bei häufigen Ursachen für den Fehler "Server nicht zugänglich" beschrieben, der bei den meisten Typen von UCS-Servern auftritt.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse im Verwalten von Servern im Unified Computing System Manager (UCSM) und im Intersight Managed Mode (IMM) verfügen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt. 

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Es gibt einen häufigen Fehler, den Benutzer in ihrer UCS-Domäne erhalten können, nämlich die Benachrichtigung, dass auf einen Server nicht zugegriffen werden kann. Dies kann aus verschiedenen Gründen der Fall sein, und der Fehler kann je nach Überwachungstools und UCSM/IMM-Versionen auf verschiedene Weise auftreten.

System Notification from [UCSM Domain Name] - diagnostic:GOLD-minor - 2023-05-25 01:56:41 GMT-04:00 Recovered : Server x/y (service profile: org-root/ls-[service_profile]) inaccessible

Serial number: [Server Serial]
Alert:  System Name: [UCSM Domain Name] 
Time of Event:2022-08-31 03:15:04 GMT-05:00 Event Description:Server x (service profile: org-root/ls-[service_profile]) inaccessible Severity Level:4

Wenn IMM verwendet wird, wird möglicherweise in der GUI die Meldung Verbindung zum Server wurde unterbrochen angezeigt. Auch eine Abschaltung von Intersight-Störungen kann beobachtet werden. 

Verbindung mit Server wurde unterbrochen IMM

Diese Warnung wird angezeigt, wenn der Cisco Integrated Management Controller (CIMC) auf einem Blade-Server auf ein Problem stößt und entweder neu startet oder einen Neustart versucht. Dies löst einen Alarm "Server nicht erreichbar" aus, da UCSM/IMM beim Neustart der Verwaltungsebene des Blades nicht mit dem Blade kommunizieren kann und daher der Ansicht ist, dass auf das Blade nicht zugegriffen werden kann. Nach dem Neustart des CIMC kehrt der Blade-Status zum Normalzustand zurück. 

Aus diesem Grund können Sie diese Warnung erhalten, dann wenn Sie die Domain überprüfen, der Server sucht und gesund. 

Allgemeine Fehlerreferenz

Cisco Bug-ID CSCwe1982 - Gilt für M5/M6-Server nach 4.2(2c)/After 5.0(1c) für X-Serie
Cisco Bug-ID CSCwa8567 - Gilt für M5/M6-Server zwischen 4.1(3e) und 4.2(2a); umfasst auch X-Serie nach 5.0(1b)
Cisco Bug-ID CSCvz62711 - Gilt für M5/M6-Server zwischen 4.1(3d) und 4.2(2a)
Cisco Bug-ID CSCwi5091 - Gilt für Blades der Serie M5/M6 im Code vor 4.3(2e)
Cisco Bug-ID CSCv79912 - Gilt für M5/M6-Server zwischen 4.0(4h) und 4.2(1a)/4.1(3d)
Cisco Bug-ID CSCvh25786 - Gilt für M4/M5-Server nach 2.0(13f) und 3.0(4a) 

Fehlerbehebung

Szenario 1

Die erste und häufigste Situation ist, dass der Server bei der Prüfung von UCSM/IMM betriebsbereit, fehlerfrei und ohne (neue) Fehler erscheint. Bei der Überprüfung des Betriebssystems hat sich gezeigt, dass das System ohne Unterbrechungen in Betrieb war.

Fehlerfreier Server in UCSM

Protokollpakete zeigen diese Meldung in einem der OBFL-Protokolle unter CIMCx_TechSupport.tar.gz > obfl > obfl-log an.

3:2022 Sep  8 10:54:33 UTC:+0000:(4.2(2d)):kernel:-:[watchdog_init]:976:BMC Watchdog resetted BMC.

Das bedeutet, dass CIMC selbstständig abstürzte und neu startete. 

In diesem Szenario sind keine weiteren Maßnahmen erforderlich, da der CIMC erfolgreich neu gestartet wurde und keine Probleme mit dem Server auftreten. 

Szenario 2

Die nächste Situation ist der Empfang der Warnung. Wenn Sie UCSM/IMM überprüfen, wird der Server weiterhin als unerreichbar angezeigt, wenn Sie UCSM verwenden, oder die Verbindung wird getrennt, wenn Sie IMM verwenden. Beim Überprüfen des Betriebssystems scheint es ohne Unterbrechungen betriebsbereit zu sein.

Da das Betriebssystem läuft, aber UCSM/IMM nicht mit dem Blade kommunizieren kann, wurde CIMC entweder nicht neu gestartet oder der Prozess wurde gestoppt. 

Der erste Schritt in diesem Szenario besteht darin, eine SSH- oder Konsolenverbindung zu den Fabric Interconnects (FI) herzustellen und diesen Befehl auszuführen, um x/y durch das betroffene Chassis/Blade zu ersetzen. Es gibt drei verschiedene Ergebnisse.

1) Die Verbindung mit dem CIMC wurde erfolgreich hergestellt.

UCSM-A# connect cimc x (For C Series Rack Mount Server)
UCSM-A# connect cimc x/y (For B/X Series Blade Server)
Trying 127.5.1.1...
Connected to 127.5.1.1.
Escape character is '^]'.

CIMC Debug Firmware Utility Shell [ support ]
[ help ]#

Wenn diese Ausgabe angezeigt wird, kann der CIMC noch einige Zeit in Anspruch nehmen, und Sie können versuchen, den CIMC zurückzusetzen, um den Blade-Server wiederherzustellen.

Wenn UCSM verwendet wird, navigieren Sie zu Equipment > Chassis > Chassis Number > Servers > Server Number > Recover Server > Reset CIMC.

Speicherort des Wiederherstellungsservers für Blade

CIMC zurücksetzen

Wenn IMM verwendet wird, navigieren Sie zum betroffenen Server, und wählen Sie Aktionen > System > Reboot Management Controller aus.

Management Controller IMM neu starten

Wenn der Server nach dem Neustart von CIMC wieder den Normalwert erreicht, ist das Problem behoben, und es ist keine weitere Aktion erforderlich.

Wenn der Fehler weiterhin besteht, fahren Sie mit den Fehlerbehebungsschritten des nächsten connect cimc-Ausgangs fort.

2) Verbindung mit CIMC fehlgeschlagen.

UCSM-A# connect cimc x (For C Series Rack Mount Server)
UCSM-A# connect cimc x/y (For B/X Series Blade Server)
Trying 127.5.1.8...
telnet: Unable to connect to remote host: No route to host

3) Anschluss an CIMC-Stände. In diesem Fall geschieht nach dem Ausführen des Befehls nichts, und beim Versuch zu entkommen (Strg + C) wird dies beobachtet.

UCSM-A# connect cimc x (For C Series Rack Mount Server)
UCSM-A# connect cimc x/y (For B/X Series Blade Server)
^C
Console escape. Commands are:

 l    go to line mode
 c    go to command mode
 z    suspend telnet
 e    exit telent
continuing...

Die Fehlerbehebung für die beiden letzten Ausgaben ist identisch. In diesen Fällen ist der CIMC vollständig ausgefallen und kann nicht mit den Fabric Interconnects kommunizieren. Ein Neustart des Servers ist erforderlich, um CIMC wiederherzustellen. Es wird immer empfohlen, beim Neustart der Blades ein Wartungsfenster zu nutzen. 

Wenn UCSM verwendet wird, können Sie das physische Wiedereinsetzen des Blades simulieren, indem Sie per SSH auf die Fabric Interconnects zugreifen und diesen Befehl ausführen und x/y durch das betroffene Chassis/den betroffenen Server ersetzen. Es ist zwingend erforderlich, dass Sie das richtige Chassis/den richtigen Server eingeben, da dieser Befehl Sie nicht zur Bestätigung auffordert.

UCSM-A# reset slot x/y

Dieser Befehl gibt bei erfolgreicher Ausführung nichts zurück. Wenn der Befehl nicht ausgeführt werden konnte, wird eine Meldung angezeigt. 

Wenn IMM verwendet wird oder der Befehl zum Zurücksetzen des Steckplatzes das unzugängliche Problem nicht behoben hat, besteht die einzige andere Option darin, den Blade-Server neu einzusetzen.

Wenn das Problem auch nach dem Wiedereinsetzen des Blades weiterhin besteht, wenden Sie sich zur weiteren Fehlerbehebung an das TAC. 

Szenario 3

Die letzte Situation ist der Empfang der Warnung. Wenn Sie UCSM/IMM überprüfen, wird der Server weiterhin als unerreichbar angezeigt, wenn Sie UCSM verwenden, oder die Verbindung wird getrennt, wenn Sie IMM verwenden. Bei der Überprüfung des Betriebssystems ist es heruntergefahren und auch nicht zugänglich.

In dieser Situation kann nur ein Neustart des Servers durchgeführt werden. Wenn ein Neustart nicht möglich ist, setzen Sie den Server physisch wieder ein. 

Wenn das Problem auch nach dem Wiedereinsetzen des Blades weiterhin besteht, wenden Sie sich zur weiteren Fehlerbehebung an das TAC. 

Schlussfolgerung

Es kann viele Gründe geben, Server-unzugängliche Fehler zu erhalten, einige davon sind wirkungsvoller als andere. Die folgenden Schritte sind ein guter Ausgangspunkt, um festzustellen, ob eine Fehlerbehebung erforderlich ist oder ob Ihre Domäne intakt ist und keine Maßnahmen erforderlich sind.