Sommario

Introduzione

Prerequisiti

Requisiti

File di registro necessari

Analisi dei log per gli indizi iniziali

Raccogliere informazioni sull'installazione di UCS

Suggerimenti per il monitoraggio proattivo di FI

Informazioni correlate

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