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
Feedback