Problemas comuns CUCM na plataforma UCS: Núcleo, alta utilização da CPU - I/O, estado suspenso

Introdução

Este documento descreve como pesquisar defeitos cinco encenações do problema comum encontradas com o gerente das comunicações unificadas de Cisco (CUCM) na plataforma do sistema de Unified Computing (UCS).

• Cenário 1: Utilização elevada da CPU devido à edição da espera I/O
• Cenário 2: Repartições CUCM periodicamente
• Cenário 3: Impactos CUCM
• Encenação 4: CUCM pendura
• Encenação 5: CUCM reage do modo somente leitura

Algumas das causas comum são:

• Falha no disco rígido
• Falha de controlador da matriz redundante de discos independentes (RAID)
• Falha da unidade de bateria de backup (BBU)

Cenário 1: Utilização elevada da CPU devido à edição da espera I/O

Sintomas

Os serviços do Cisco Call Manager (CCM) e da integração de telefonia e computador (CTI) reiniciam devido ao núcleo CCM CTI.

Como verificar

Traços CUCM

Use estes comandos CLI a fim recolher traços CUCM:

• mostre o processador central de utilização-mais do processo
• show status
• os utils retiram o núcleo da lista ativa
• o núcleo util analisa a saída a mais <latest, o último output> dois

Examine estes logs da ferramenta do monitoramento em tempo real (RTMT):

• CCM detalhado
• CTI detalhado
• Coletor de dados PerfMonLogs do server de informação em tempo real (RI)
• Log de aplicativo event viewer
• Log de sistema do visualizador de eventos

Saída de exemplo

Aqui estão alguns exemplos de saída:

admin:utils core active list
Size Date Core File Name
===============================================                           
355732 KB 2014-X-X 11:27:29 core.XXX.X.ccm.XXXX
110164 KB 2014-X-X 11:27:25 core.XXX.X.CTIManager.XXXX

admin:util core analyze output 

====================================
CCM service backtrace
===================================
#0 0x00df6206 in raise () from /lib/libc.so.6
#1 0x00df7bd1 in abort () from /lib/libc.so.6
#2 0x084349cb in IntentionalAbort (reason=0xb0222f8 "CallManager unable to process
signals. This may be due to CPU or blocked function. Attempting to restart 
CallManager.") at ProcessCMProcMon.cpp:80
#3 0x08434a8c in CMProcMon::monitorThread () at ProcessCMProcMon.cpp:530
#4 0x00a8fca7 in ACE_OS_Thread_Adapter::invoke (this=0xb2b04270) at OS_Thread_
Adapter.cpp:94
#5 0x00a45541 in ace_thread_adapter (args=0xb2b04270) at Base_Thread_Adapter.cpp:137
#6 0x004aa6e1 in start_thread () from /lib/libpthread.so.0
#7 0x00ea2d3e in clone () from /lib/libc.so.6
====================================
 
 
====================================
CTI Manager backtrace
===================================
#0 0x00b3e206 in raise () from /lib/libc.so.6
#1 0x00b3fbd1 in abort () from /lib/libc.so.6
#2 0x08497b11 in IntentionalAbort (reason=0x86fe488 "SDL Router Services declared
dead. This may be due to high CPU usage or blocked function. Attempting to restart
CTIManager.") at ProcessCTIProcMon.cpp:65
#3 0x08497c2c in CMProcMon::verifySdlTimerServices () at ProcessCTIProcMon.cpp:573
#4 0x084988d8 in CMProcMon::callManagerMonitorThread (cmProcMon=0x93c9638) at Process
CTIProcMon.cpp:330
#5 0x007bdca7 in ACE_OS_Thread_Adapter::invoke (this=0x992d710) at OS_Thread_
Adapter.cpp:94
#6 0x00773541 in ace_thread_adapter (args=0x992d710) at Base_Thread_Adapter.cpp:137
#7 0x0025d6e1 in start_thread () from /lib/libpthread.so.0
#8 0x00bead3e in clone () from /lib/li
====================================

Do coletor de dados PerfMonLogs RI, você pode ver o I/O alto do disco durante o tempo do núcleo.

O backtrace combina a identificação de bug Cisco CSCua79544: Núcleos frequentes do processo CCM devido ao I/o. alto do disco. Este erro descreve um problema de hardware e explica como isolar mais o problema.

Permita o relatório I/O do arquivo (FIOR):

Use estes comandos a fim permitir FIOR:

utils fior start
utils fior enable

Então, espera para a ocorrência seguinte. Está aqui o comando CLI recolher a saída: o arquivo obtém o activelog platform/io-stats. Incorpore estes comandos a fim desabilitar FIOR:

utils fior stop
utils fior disable

Está aqui algum registro de saída da amostra FIOR:

kern 4 kernel: fio_syscall_table address set to c0626500 based on user input
kern 4 kernel: fiostats: address of do_execve set to c048129a
kern 6 kernel: File IO statistics module version 0.99.1 loaded. 
kern 6 kernel: file reads > 265000 and writes > 51200 will be logged
kern 4 kernel: fiostats: enabled.
kern 4 kernel: fiostats[25487] started.

Solução

A ESPERA I/O é geralmente uma edição com a plataforma UCS e seu armazenamento.

O log UCS é exigido para isolar o lugar da causa. Refira como recolher a seção dos logs UCS para que as instruções recolham os traços.

Cenário 2: Repartições CUCM periodicamente

Sintomas

As repartições CUCM devido a um impacto ESXI mas à questão subjacente são que a máquina UCS perde a potência.

Como verificar

Examine estes traços CUCM:

• Coletor de dados PerfMonLog de Cisco RI
• Log de aplicativo event viewer
• Visualizador de eventos - Log de sistema
• CCM detalhado

Não há nada relevante nos traços CUCM. O CUCM para antes do incidente e este é seguido um reinício normal do serviço. Isto elimina CUCM e indica que a causa se encontra em outra parte.

A plataforma UCS onde as corridas CUCM têm o problema. A plataforma UCS tem muitos exemplos da máquina virtual (VM) que são executado nela. Se qualquer VM encontra um erro, a seguir vê-se nos logs UCS.

O log UCS é exigido a fim isolar o lugar da causa. Refira como recolher a seção dos logs UCS para instruções sobre como recolher os traços.

Prove o controlador do gerenciamento integrado de Cisco (CIMC) Output

Aqui estão alguns exemplos de saída:

5:2014 May 11 13:10:48:BMC:kernel:-:<5>[lpc_reset_isr_handler]:79:LPC Reset ISR ->
ResetState: 1
5:2014 May 11 13:10:48:BMC:kernel:-:<5>drivers/bmc/usb/usb1.1/se_pilot2_udc_usb1_1.c:
2288:USB FS: VDD Power WAKEUP- Power Good = OFF
5:2014 May 11 13:10:48:BMC:kernel:-:<5>[se_pilot2_wakeup_interrupt]:2561:USB HS: 
VDD Power = OFF
5:2014 May 11 13:10:48:BMC:BIOSReader:1176: BIOSReader.c:752:File Close : 
/var/nuova/BIOS/BiosTech.txt
5:2014 May 11 13:10:48:BMC:kernel:-:<5>[block_transfer_fetch_host_request_for_app]:
1720:block_transfer_fetch_host_request_for_app : BT_FILE_CLOSE : HostBTDescr = 27 : 
FName = BiosTech.txt
5:2014 May 11 13:10:48:BMC:IPMI:1357: Pilot2SrvPower.c:466:Blade Power Changed To: 
[ OFF ]
5:2014 May 11 13:10:49:BMC:lv_dimm:-: lv_dimm.c:126:[lpc_reset_seen]LPC Reset Count 
is Different [0x1:0x2] Asserted LPC Reset Seen
 

Solução

Quando você encontra este erro, a potência Pilot2SrvPower.c:466:Blade mudou a: [OFF] - Questão de energia, significa que a máquina UCS perde a potência. Daqui, você deve assegurar-se de que a máquina UCS obtenha energias suficientes.

Cenário 3: Impactos CUCM

Sintomas

Os impactos CUCM VM mas ainda respondem aos sibilos. As visualizações óticas de tela de console do vSphere esta informação:

*ERROR* %No Memory Available*ERROR* %No Memory Available

Como verificar

Examine estes traços CUCM:

• Coletor de dados PerfMonLog de Cisco RI
• Log de aplicativo event viewer
• Visualizador de eventos - Log de sistema
• CCM detalhado

Não há nada relevante nos traços CUCM. O CUCM para antes do incidente e é seguido por um reinício normal do serviço. Isto elimina CUCM e indica que a causa se encontra em outra parte.

A plataforma UCS onde as corridas CUCM têm o problema. A plataforma UCS tem muitos exemplos VM que são executado nela. Se qualquer VM encontra um erro, a seguir vê-se nos logs UCS.

O log UCS é exigido a fim isolar o lugar da causa. Refira como recolher a seção dos logs UCS para instruções sobre como recolher os traços.

Solução

O sem energia o VM e recarrega-o. Depois que a repartição, o sistema trabalha muito bem.

Encenação 4: CUCM pendura

Sintomas

O server CUCM vai a um estado onde pendure.

Como verificar

Examine estes traços CUCM:

• Coletor de dados PerfMonLog de Cisco RI
• Log de aplicativo event viewer
• Visualizador de eventos - Log de sistema
• CCM detalhado

Não há nada relevante nos traços CUCM. O CUCM para antes do incidente e é seguido por um reinício normal do serviço. Isto elimina CUCM e indica que a causa se encontra em outra parte.

A plataforma UCS onde as corridas CUCM têm o problema. A plataforma UCS tem muitos exemplos VM que são executado nela. Se qualquer VM encontra um erro, a seguir vê-se nos logs UCS.

O log UCS é exigido a fim isolar o lugar da causa. Refira como recolher a seção dos logs UCS para instruções sobre como recolher os traços.

Solução

Tente um reinício manual ver se ajuda.

Encenação 5: CUCM reage do modo somente leitura

Sintomas

Você recebe este erro:

The /common file system is mounted read only.Please use Recovery Disk to check
the file system using fsck.

Como verificar 

O editor (BAR) e um subscritor (SUB) que são instalados na mesma mostra da máquina UCS o erro do modo somente leitura. O disco da recuperação não fixa a edição.

Não há nada relevante nos traços CUCM. O CUCM para antes do incidente e é seguido por um reinício normal do serviço. Isto elimina CUCM e indica que a causa se encontra em outra parte.

A plataforma UCS onde as corridas CUCM têm o problema. A plataforma UCS tem muitos exemplos VM que são executado nela. Se qualquer VM encontra um erro, a seguir vê-se nos logs UCS.

O log UCS é exigido a fim isolar o lugar da causa. Refira como recolher a seção dos logs UCS para instruções sobre como recolher os traços.

Solução

Após a substituição de hardware, reconstrua os Nós problemáticos.

Como recolher logs UCS

Esta seção descreve como recolher os traços necessários identificar o problema ou fornece os links aos artigos que fornecem essa informação.

Como recolher os logs CIMC: Show tech

Refira estes artigos para obter informações sobre de como recolher logs CICM:

Usando Cisco CIMC GUI para recolher detalhes da mostra-tecnologia

Guia visual para recolher arquivos do suporte técnico (B e série C)

Como recolher logs ESXI: Log de sistema

Refira este artigo para obter informações sobre de como recolher logs ESXI:

Obtendo a informação de diagnóstico para ESXi 5.x hospeda usando o cliente do vSphere 

Saída da amostra CIMC CLI

Está aqui alguma amostra CIMC CLI output de uma falha no disco rígido:

ucs-c220-m3 /chassis # show hdd
Name Status LocateLEDStatus 
-------------------- -------------------- -------------------- 
HDD1_STATUS present TurnOFF 
HDD2_STATUS present TurnOFF 
HDD3_STATUS failed TurnOFF 
HDD4_STATUS present TurnOFF 
HDD5_STATUS absent TurnOFF 
HDD6_STATUS absent TurnOFF 
HDD7_STATUS absent TurnOFF 
HDD8_STATUS absent TurnOFF
 

ucs-c220-m3 /chassis # show hdd-pid
Disk Controller Product ID Vendor Model 
---- ----------- -------------------- ---------- ------------ 
1 SLOT-2 A03-D500GC3 ATA ST9500620NS 
2 SLOT-2 A03-D500GC3 ATA ST9500620NS 
3 SLOT-2 A03-D500GC3 ATA ST9500620NS 
4 SLOT-2 A03-D500GC3 ATA ST9500620NS
 
 

ucs-c220-m3 /chassis/storageadapter # show physical-drive
Physical Drive Number Controller Health Status Manufacturer Model Predictive
Failure Count Drive Firmware Coerced Size Type 
--------------------- ---------- -------------- ---------------------- ------
-------- -------------- ------------------------ -------------- -------------- ----- 
1 SLOT-2 Good Online ATA ST9500620NS 0 CC03 475883 MB HDD 
2 SLOT-2 Good Online ATA ST9500620NS 0 CC03 475883 MB HDD 
3 SLOT-2 Severe Fault Unconfigured Bad ATA ST9500620NS 0 CC03 0 MB HDD 
4 SLOT-2 Good Online ATA ST9500620NS 0 CC03 475883 MB HDD

Está aqui alguma amostra CICM CLI output da falha de controlador RAID:

ucs-c220-m3 /chassis/storageadapter # show virtual-drive
Virtual Drive Health Status Name Size RAID Level Boot Drive 
------------- -------------- -------------------- ---------------- ---------- 
---------- ---------- 
0 Moderate Fault Degraded 951766 MB RAID 10 true

Saída da amostra CIMC GUI

Está aqui alguma amostra CIMC GUI output de uma falha no disco rígido:

Está aqui alguma amostra CIMC GUI output de um erro roxo da tela:

(Falha de controlador da invasão | Defeito: Exceção 14 CSCuh86924 ESXi PSOD PF - Controlador 9266-8i LSI RAID)

Está aqui alguma amostra CIMC GUI output de uma falha BBU: