Contents

Introduction

Prerequisites

Requirements

Arquivos de log necessários

Analisando registros para pistas iniciais

Coletar informações sobre a configuração do UCS

Sugestão para monitoramento pró-ativo de FI

Informações Relacionadas

Introduction

O documento fornece etapas para investigar o travamento do Unified Computing System Fabric Interconnect (FI) ou uma falha inesperada na reinicialização.

Em um nível avançado, os seguintes problemas podem resultar na reinicialização do FI

- O processo de espaço do kernel travou ( conhecido como pânico do Kernel )

- O kernel ficou sem memória ( Fora de memória - OOM mata um processo do usuário para recuperar a memória )

- O processo de espaço do usuário travou ( ex. - netstack, fcoe_mgr , callhome etc )

- Problema de firmware FI (cenário raro, exemplo - CSCuq46105 ) ou falha de componente de hardware (como SSD usado para armazenamento )

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

Cisco Unified Computing System (UCS) Manager

Interface de linha de comando (CLI) do Cisco Unified Computing System (UCS) Manager

Arquivos de log necessários

Quando o FI reinicializar inesperadamente, colete os seguintes registros e faça o upload para a solicitação de serviço do TAC.

- pacote de log de suporte técnico do UCSM

- Verifique se o arquivo de despejo principal é criado no momento do evento de reinicialização.

Você pode verificar os arquivos de despejo de núcleos via CLI ou GUI

UCS-FI # scope monitoring

UCS-FI /monitoramento # scope sysdebug

UCS-FI /monitoramento/sysdebug # show cores detail

- Se o FI tiver sido configurado para exportar registros para o Servidor syslog, reúna mensagens de log do Servidor syslog para o dispositivo que fornece 7 dias de histórico antes da reinicialização do carimbo de data e hora.

- Rastreamento da pilha do kernel ( Se a reinicialização for devido ao pânico do kernel )

Analisando registros para pistas iniciais

1) Verifique a razão da reinicialização e o datador de hora do Nexus Operating System (NX-OS) " show version " command output

2) Verifique a saída do comando " show logging nvram " para mensagens de log antes da reinicialização do carimbo de data e hora

3) Verifique as mensagens de log armazenadas no Servidor syslog para obter dicas adicionais

4) Se a reinicialização foi acionada por um travamento do processo de espaço do usuário, verifique o dump central que corresponde ao nome do processo e reinicialize o carimbo de data e hora.

6) Se estiver em pânico do kernel, verifique a saída de rastreamento da pilha do kernel no arquivo chamado " sw_kernel_trace_log "

No UCSM 2.2.1b, esse arquivo está incluído no pacote show techsupport do UCSM.

Para a versão do UCSM anterior à 2.2.1b, colete a saída dos seguintes comandos

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 " contém a saída do comando " top " a cada dois segundos. Antes da reinicialização, o UCSM salva o antigo conjunto de registros como arquivo /opt/sam_logs.tgz. Ele pode fornecer informações sobre memória, utilização ou processos.

8) Se você notar que mensagens como Out of Memory (OOM) mataram um processo e o travamento do processo pode disparar a reinicialização do FI e seriam listados como motivo de redefinição.Nesses cenários, é mais provável que o processo seja vítima de uma condição de memória baixa e não seja a causa por trás do travamento ou do vazamento de memória.

Coletar informações sobre a configuração do UCS

Responder às perguntas a seguir ajuda a entender melhor a configuração do sistema e seu estado anterior à reinicialização.

1) Esse problema ocorreu antes?

2) Houve alguma atividade de usuário específica no momento da reinicialização?

3) Qualquer alteração recente de software/hardware/configuração feita no FI ?

4) O Fi está sendo monitorado por qualquer aplicativo externo ( sobre SNMP , XML API )?

5) Em caso afirmativo, com que frequência os aplicativos pesquisam dados no FI?  Que informações são pesquisadas em intervalos regulares por esse aplicativo? ( ex. consultas SNMP )

6) Houve alguma tempestade de tráfego na porta de gerenciamento FI?

7) Essa configuração de escala é ? ( Número de chassis, blades, interfaces virtuais )

Sugestão para monitoramento pró-ativo de FI

1) Configurar o UCSM para exportar registros para o Servidor syslog

2) Colete a saída de " show processes " do local-mgmt em intervalos regulares para monitorar a tendência na CPU e na memória

uso de processos. Isso não é necessário se o FI já estiver sendo monitorado por aplicativos externos.

Informações Relacionadas

Guia de configuração do Cisco UCS Manager