Risoluzione dei problemi di inaccessibilità del server sui server UCS

Introduzione

In questo documento viene descritto come risolvere i problemi relativi ai motivi più comuni dell'errore di server inaccessibile che si possono verificare per la maggior parte dei tipi di server UCS.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza della gestione dei server in Unified Computing System Manager (UCSM) e Intersight Managed Mode (IMM).

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware. 

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Esiste un errore comune che gli utenti possono ricevere nel proprio dominio UCS, ovvero notificare all'utente che un server è inaccessibile. Le cause possono essere diverse e l'errore può essere visualizzato in diversi modi, a seconda degli strumenti di monitoraggio e delle versioni 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

Se IMM è in uso, è possibile che nella GUI venga visualizzato il messaggio Connessione al server interrotta. Si può anche osservare la disconnessione dagli errori di Intersight. 

Connessione al server interrotta con IMM

Questo avviso può essere visualizzato quando Cisco Integrated Management Controller (CIMC) su un blade rileva un problema e si riavvia o tenta di riavviarsi. In questo modo viene attivato un avviso Server inaccessibile perché, mentre il piano di gestione del blade è in fase di riavvio, UCSM/IMM non è in grado di comunicare con il blade e quindi lo ritiene inaccessibile. Una volta riavviato CIMC, lo stato dei blade ritorna alla normalità. 

Per questo motivo, è possibile ricevere questo avviso e, quando si controlla il dominio, il server cerca in buono stato e risulta integro. 

Riferimento comune al difetto

ID bug Cisco CSCwe19822 - Si applica ai server M5/M6 dopo la 4.2(2c)/dopo la 5.0(1c) per la serie X
ID bug Cisco CSCwa85667 - Si applica ai server M5/M6 tra 4.1(3e) e 4.2(2a) Include anche le serie X dopo la versione 5.0(1b)
ID bug Cisco CSCvz62711 - Si applica ai server M5/M6 con intervallo tra 4,1 (3d) e 4,2 (2a)
ID bug Cisco CSCwi50991 - Si applica ai blade serie M5/M6 con codice precedente alla 4.3(2e)
ID bug Cisco CSCv79912 - Si applica ai server M5/M6 con velocità compresa tra 4,0(4h) e 4,2(1a)/4,1(3d)
ID bug Cisco CSCvh25786 - Si applica ai server M4/M5 dopo le versioni 2.0(13f) e 3.0(4a) 

Risoluzione dei problemi

Scenario 1

La prima e la più comune situazione è ricevere l'avviso, quindi quando si controlla UCSM/IMM il server appare funzionante, integro e senza (nuovi) errori. Quando si controlla il sistema operativo, sembra che sia stato attivato e funzionante senza interruzioni.

Server integro in UCSM

I bundle di log mostrano questo messaggio in uno dei log OBFL che si trovano in 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.

Questo ci dice che CIMC si è bloccato e si è riavviato da solo. 

In questo scenario non sono necessarie ulteriori azioni al riavvio di CIMC e non sono presenti problemi con il server. 

Scenario 2

La situazione successiva è la ricezione dell'avviso, quindi quando si controlla UCSM/IMM il server risulta ancora inaccessibile se si utilizza UCSM o disconnesso se si utilizza IMM. Quando si controlla il sistema operativo, questo sembra essere attivo e funzionante senza interruzioni.

Poiché il sistema operativo è operativo ma UCSM/IMM non è in grado di comunicare con il blade, CIMC non è stato riavviato o bloccato nel processo. 

Il primo passaggio in questo scenario è inviare il supporto SSH o la console alle interconnessioni fabric (FI) ed eseguire questo comando sostituendo x/y con lo chassis/blade interessato. Ci sono tre risultati diversi.

1) Connessione a CIMC riuscita.

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

Se questo output viene visualizzato, il CIMC è ancora attivo e si può provare a reimpostare CIMC per ripristinare il blade.

Se UCSM è in uso, selezionare Apparecchiatura > Chassis > Numero chassis > Server > Numero server > Ripristina server > Ripristina CIMC.

Percorso del server di ripristino per il blade

Ripristina CIMC

Se IMM è in uso, passare al server interessato e selezionare Azioni > Sistema > Controller di gestione riavvio.

IMM controller di gestione riavvio

Se dopo il riavvio di CIMC il server ritorna alla condizione normale, il problema viene risolto e non è necessario eseguire altre operazioni.

Se l'errore persiste, procedere con le operazioni di risoluzione dei problemi dell'output cimc di connessione successivo.

2) Connessione al CIMC non riuscita.

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) Collegamento ai gabinetti CIMC. In questo caso, non accade nulla dopo l'esecuzione del comando e quando si tenta di eseguire l'escape (Ctrl + C) questo viene osservato.

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

La risoluzione dei problemi per uno degli ultimi due output è la stessa. In questi casi CIMC è completamente inattivo e non è in grado di comunicare con le interconnessioni fabric. Per ripristinare CIMC è necessario riavviare il server. Durante il riavvio dei blade, si consiglia sempre di utilizzare una finestra di manutenzione. 

Se UCSM è in uso, è possibile simulare il riposizionamento fisico del blade tramite SSH sulle interconnessioni fabric ed eseguire questo comando sostituendo x/y con lo chassis/server interessato. È indispensabile immettere lo chassis/server corretto, in quanto questo comando non richiede la conferma.

UCSM-A# reset slot x/y

Se l'operazione ha esito positivo, il comando non restituisce alcun risultato. Se l'esecuzione del comando non è riuscita, viene visualizzato un messaggio. 

Se IMM è in uso o il comando di ripristino dello slot non ha risolto il problema di inaccessibilità, l'unica opzione disponibile consiste nel riavviare fisicamente il blade.

Se, dopo aver riposizionato fisicamente il blade, il problema persiste, contattare TAC per ulteriore risoluzione del problema. 

Scenario 3

La situazione finale sta ricevendo l'avviso quando si controlla UCSM/IMM il server continua a essere inaccessibile se si utilizza UCSM o disconnesso se si utilizza IMM. Quando si controlla il sistema operativo, esso è inattivo e anche inaccessibile.

In questo caso, è sufficiente riavviare il server. Se il riavvio non è possibile, ricollocare fisicamente il server. 

Se, dopo aver riposizionato fisicamente il blade, il problema persiste, contattare TAC per ulteriore risoluzione del problema. 

Conclusioni

I motivi per cui si ricevono errori di server inaccessibili possono essere molteplici, alcuni dei quali hanno un impatto maggiore rispetto ad altri. I passaggi descritti in questa sezione rappresentano una buona base per valutare se è necessaria una risoluzione dei problemi o se il dominio è integro e non è necessario alcun intervento.