Dépannage des pannes inaccessibles du serveur sur les serveurs UCS

Introduction

Ce document décrit comment dépanner les causes courantes de l'erreur Serveur inaccessible qui peut être vue pour la plupart des types de serveurs UCS.

Conditions préalables

Exigences

Cisco recommande que vous connaissiez la gestion des serveurs dans Unified Computing System Manager (UCSM) et Intersight Managed Mode (IMM).

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques. 

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Il existe un problème courant que les utilisateurs peuvent recevoir dans leur domaine UCS, c'est-à-dire vous avertir qu'un serveur est inaccessible. Cela peut être dû à un certain nombre de raisons et l'erreur peut apparaître de différentes manières selon les outils de surveillance et les versions UCSM/IMM.

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

Si IMM est en cours d'utilisation, un message Connection to Server was lost (Connexion au serveur perdue) peut être vu dans l'interface utilisateur graphique. Une déconnexion des défaillances d'Intersight peut également être observée. 

La connexion au serveur a été perdue IMM

Cette alerte s'affiche lorsque le contrôleur de gestion intégré Cisco (CIMC) d'une lame rencontre un problème et redémarre ou tente de redémarrer. Cela déclenche une alerte Serveur inaccessible, car pendant le redémarrage du plan de gestion de la lame, UCSM/IMM ne peut pas communiquer avec la lame et pense donc qu'elle est inaccessible. Une fois le CIMC redémarré, l'état des lames revient à la normale. 

C'est pourquoi vous pouvez recevoir cette alerte, puis lorsque vous vérifiez le domaine, le serveur recherche et l'intégrité. 

Référence De Défauts Courants

ID de bogue Cisco CSCwe19822 - S'applique aux serveurs M5/M6 après 4.2(2c)/après 5.0(1c) pour la gamme X
ID de bogue Cisco CSCwa8567 - S'applique aux serveurs M5/M6 entre 4.1(3e) et 4.2(2a) Inclut également la série X après 5.0(1b)
ID de bogue Cisco CSCvz62711 - S'applique aux serveurs M5/M6 entre 4.1(3d) et 4.2(2a)
ID de bogue Cisco CSCwi5091 - S'applique aux lames de la gamme M5/M6 sur le code antérieur à la version 4.3(2e)
ID de bogue Cisco CSCv7912 - S'applique aux serveurs M5/M6 entre 4.0(4h) et 4.2(1a)/4.1(3d)
ID de bogue Cisco CSCvh25786 - S'applique aux serveurs M4/M5 après 2.0(13f) et 3.0(4a) 

Dépannage

Scénario 1

La première et la plus courante situation est la réception de l'alerte, puis lors de la vérification UCSM/IMM le serveur semble opérationnel, sain, et sans (nouveau) défaut. Lors de la vérification du système d'exploitation, celui-ci semble avoir été opérationnel sans interruption.

Serveur sain dans UCSM

Les paquets de journaux affichent ce message dans l'un des journaux OBFL qui se trouvent à l'adresse CIMCx_TechSupport.tar.gz > obfl > obfl-log.

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

Cela nous indique que CIMC s’est bloqué et a redémarré de lui-même. 

Dans ce scénario, aucune action supplémentaire n'est requise car CIMC a redémarré avec succès et il n'y a aucun problème avec le serveur. 

Scénario 2

La situation suivante est la réception de l'alerte, puis lors de la vérification UCSM/IMM, le serveur apparaît toujours comme inaccessible si vous utilisez UCSM ou déconnecté si vous utilisez IMM. Lors de la vérification du système d'exploitation, celui-ci semble être opérationnel sans interruption.

Comme le système d'exploitation est opérationnel mais que UCSM/IMM ne peut pas communiquer avec la lame, cela signifie que CIMC n'a pas redémarré ou qu'il est bloqué dans le processus. 

La première étape de ce scénario consiste à connecter SSH ou console aux interconnexions de fabric (FI) et à exécuter cette commande en remplaçant x/y par le châssis/la lame concerné(e). Il y a trois conséquences différentes.

1) La connexion à CIMC a réussi.

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 ]#

Si ce résultat est visible, il reste de la vie sur CIMC et vous pouvez essayer de réinitialiser CIMC pour récupérer la lame.

Si UCSM est utilisé, accédez à Equipment > Chassis > Chassis Number > Servers > Server Number > Recover Server > Reset CIMC.

Emplacement du serveur de restauration pour lame

Réinitialiser CIMC

Si IMM est en cours d'utilisation, accédez au serveur affecté et sélectionnez Actions > System > Reboot Management Controller.

Redémarrer IMM du contrôleur de gestion

Si, après le redémarrage de CIMC, le serveur revient à la normale, le problème est résolu et aucune action supplémentaire n'est requise.

Si le problème persiste, passez aux étapes de dépannage de la sortie connect cimc suivante.

2) La connexion à CIMC échoue.

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) La connexion à CIMC est bloquée. Dans ce cas, rien ne se passe après l'exécution de la commande et lorsque vous essayez de vous échapper (Ctrl + C), cela est observé.

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...

Le dépannage de l'une ou l'autre des deux dernières sorties est identique. Dans ce cas, CIMC est complètement arrêté et ne peut pas communiquer avec les interconnexions de fabric. Un redémarrage du serveur est nécessaire pour récupérer CIMC. Il est toujours recommandé de prendre une fenêtre de maintenance lors du redémarrage des lames. 

Si UCSM est utilisé, vous pouvez simuler la réinstallation physique de la lame en établissant une connexion SSH aux interconnexions de fabric et en exécutant cette commande pour remplacer x/y par le châssis/serveur concerné. Il est impératif d'entrer le châssis/serveur correct car cette commande ne vous invite pas à confirmer.

UCSM-A# reset slot x/y

Cette commande ne renvoie rien si elle aboutit. Si l'exécution de la commande échoue, un message s'affiche. 

Si IMM est en cours d'utilisation ou si la commande reset slot n'a pas résolu le problème inaccessible, la seule autre option consiste à redémarrer physiquement la lame.

Si, après la réinstallation physique de la lame, le problème persiste, contactez le TAC pour un dépannage plus approfondi. 

Scénario 3

La situation finale est la réception de l'alerte, puis lors de la vérification UCSM/IMM, le serveur apparaît toujours comme inaccessible si vous utilisez UCSM ou déconnecté si vous utilisez IMM. Lors de la vérification du système d'exploitation, il est hors service et également inaccessible.

Dans ce cas, il suffit de redémarrer le serveur pour que le système redémarre. Si un redémarrage n'est pas possible, réinstallez physiquement le serveur. 

Si, après la réinstallation physique de la lame, le problème persiste, contactez le TAC pour un dépannage plus approfondi. 

Conclusion

Il peut y avoir de nombreuses raisons de recevoir des erreurs Server Inaccessible, certaines ayant plus d'impact que d'autres. Les étapes présentées ici constituent un bon point de départ pour évaluer si un dépannage est nécessaire ou si votre domaine est sain et qu'aucune action n'est nécessaire.