Introduzione
In questo documento viene descritto come analizzare un arresto anomalo del sistema di calcolo unificato (FI, Unified Computing System Fabric Interconnect) o un errore imprevisto di riavvio.
Ad alto livello, i seguenti problemi potrebbero determinare il riavvio di FI
- Arresto anomalo del processo dello spazio del kernel (ovvero errore irreversibile del kernel)
- Memoria insufficiente nel kernel ( Memoria insufficiente - OOM impossibile recuperare memoria )
- Arresto anomalo del processo dello spazio utente ( es. - netstack, fcoe_mgr , callhome e così via )
- Problema del firmware FI ( scenario raro , esempio - CSCuq46105 ) o guasto di un componente hardware (come SSD utilizzata per lo storage )
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
Cisco Unified Computing System (UCS) Manager
Interfaccia della riga di comando (CLI) di Cisco Unified Computing System (UCS) Manager
File di registro necessari
Quando il file FI viene riavviato in modo imprevisto, raccogliere i seguenti log e caricarli in TAC Service Request.
- Pacchetto di log per il supporto tecnico UCSM
- Verificare se il file di dump principale viene creato in prossimità dell'evento di riavvio.
È possibile controllare i file di dump dei core tramite CLI o GUI
UCS-FI # monitoraggio dell'ambito
UCS-FI /monitoring # ambito sysdebug
UCS-FI /monitoring/sysdebug # visualizzazione dettagli core
- Se l'FI è stato configurato per l'esportazione dei log nel server syslog, raccogliere i messaggi di log dal server syslog per il dispositivo che fornisce 7 giorni di cronologia prima del timestamp di riavvio.
- Analisi dello stack del kernel ( se il riavvio è dovuto a un errore del kernel )
Analisi dei log per gli indizi iniziali
1) Controllare il motivo del riavvio e il timestamp dall'output del comando " show version " del sistema operativo Nexus (NX-OS)
2) Controllare l'output del comando " show logging nvram " per i messaggi di registro prima del timestamp del riavvio
3) Controllare i messaggi di log memorizzati sul server syslog per ulteriori indizi
4) Se il riavvio è stato attivato dall'arresto anomalo del processo dello spazio utente, controllare il dump del core che corrisponda al nome del processo e al timestamp del riavvio.
6) In caso di errore irreversibile del kernel, controllare l'output della traccia dello stack del kernel nel file denominato " sw_kernel_trace_log "
Da UCSM 2.2.1b, questo file è incluso in UCSM show tech support bundle.
Per UCSM versione precedente alla 2.2.1b, raccogliere l'output dei seguenti comandi
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 " contiene l'output del comando " top " ogni due secondi. Prima del riavvio, UCSM salva il vecchio set di registri come file /opt/sam_logs.tgz. Può fornire informazioni sulla memoria, l'utilizzo o i processi.
8) Se si notano messaggi come OOM (Out of Memory) che ha interrotto un processo e l'arresto anomalo del processo potrebbe provocare il riavvio di FI e verrebbe elencato come motivo di ripristino.In questi scenari, è molto probabile che il processo sia vittima di una condizione di memoria insufficiente e potrebbe non essere la causa del crash o della perdita di memoria.
Raccogliere informazioni sull'installazione di UCS
Rispondendo alle domande seguenti è possibile comprendere meglio la configurazione del sistema e il relativo stato prima del riavvio.
1) Il problema si è già verificato?
2) Si è verificata un'attività specifica dell'utente al momento del riavvio?
3) Eventuali modifiche recenti al software, all'hardware o alla configurazione apportate al FI?
4) Fi è monitorato da applicazioni esterne ( tramite SNMP , XML API )?
5) In caso affermativo, con quale frequenza le applicazioni eseguono il polling dei dati? Quali informazioni vengono sottoposte a polling a intervalli regolari da questa applicazione? ( query SNMP )
6) Si sono verificati problemi di traffico verso la porta di gestione FI?
7) Questa impostazione della scala? ( Numero di chassis, blade , interfacce virtuali )
Suggerimenti per il monitoraggio proattivo di FI
1) Configurare UCSM per esportare i log nel server syslog
2) Raccogliere l'output di " show processes " dalla gestione locale a intervalli regolari per monitorare la tendenza della CPU e della memoria
utilizzo dei processi. Ciò non è necessario se l’impianto è già monitorato da un’applicazione esterna.
Informazioni correlate
Guida alla configurazione di Cisco UCS Manager
Feedback