Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

Problèmes courants CUCM sur la plate-forme UCS : Noyau, CPU de haute - E/S, état arrêté

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment dépanner cinq scénarios de problème courant produits avec Cisco Unified Communications Manager (CUCM) sur la plate-forme de l'Unified Computing System (UCS).

Certaines des causes classiques sont :

  • Panne de disque dur
  • Choix redondant de panne de contrôleur des disques indépendants (RAID)
  • Panne des batteries de sauvegarde mémoire (BBU)

Contribué par Sivakumar Shanmugam, ingénieur TAC Cisco.

Scénario 1 : Utilisation du CPU élevé due à la question d'attente E/S

Symptômes

Reprise de services de Cisco Call manager (CCM) et de couplage de la téléphonie et de l'informatique (CTI) due au noyau de CCM CTI.

Comment vérifier

Suivis CUCM

Employez ces commandes CLI afin de collecter des suivis CUCM :

  • affichez le processus utilisant-plus la CPU
  • affichez l'état
  • les utils creusent la liste active
  • le noyau utilisation analysent la sortie <latest, dernier output> le deux

Examinez ces logs de l'outil de suivi en temps réel (RTMT) :

  • CCM détaillé
  • CTI détaillé
  • Unité de collecte de données du serveur d'information en temps réel (RIS) PerfMonLogs
  • Journaux de l'observateur d'événements
  • Logs système de visualisateur d'événements

Exemple de sortie

Voici une certaine sortie témoin :

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
====================================

De l'unité de collecte de données RIS PerfMonLogs, vous pouvez voir l'E/S élevée de disque pendant le principal temps.

Le backtrace apparie l'ID de bogue Cisco CSCua79544 : Fréquentez les process cores CCM dus à l'E/S élevée de disque. Cette bogue décrit un problème matériel et explique comment isoler plus loin le problème.

Enregistrement E/S de fichier d'enable (FIOR) :

Employez ces commandes afin d'activer FIOR :

utils fior start
utils fior enable

Puis, attente la prochaine occurrence. Voici la commande CLI de collecter la sortie : le fichier obtiennent l'activelog platform/io-stats. Sélectionnez ces commandes afin de désactiver FIOR :

utils fior stop
utils fior disable

Voici un certain log témoin FIOR sorti :

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.

Solution

L'ATTENTE E/S est habituellement une question avec la plate-forme UCS et sa mémoire.

Le log UCS est exigé pour isoler l'emplacement de la cause. Référez-vous le comment collecter la section de logs UCS pour que les instructions collectent les suivis.

Scénario 2 : Réinitialisations CUCM périodiquement

Symptômes

Les réinitialisations CUCM dues à un crash ESXI mais au problème intrinsèque est que l'ordinateur UCS perd l'alimentation.

Comment vérifier

Examinez ces suivis CUCM :

  • Unité de collecte de données de Cisco RIS PerfMonLog
  • Journal de l'observateur d'événements
  • Visualisateur d'événements - Log système
  • CCM détaillé

Il n'y a rien approprié dans les suivis CUCM. Le CUCM arrête avant l'incident et ceci est suivi une reprise normale de service. Ceci élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS où les passages CUCM a le problème. La plate-forme UCS a beaucoup d'exemples du virtual machine (VM) qui fonctionnent là-dessus. Si n'importe quelle VM rencontre une erreur, alors on le voit dans les logs UCS.

Le log UCS est exigé afin d'isoler l'emplacement de la cause. Référez-vous le comment collecter la section de logs UCS pour des instructions au sujet de la façon collecter les suivis.

Contrôleur de gestion intégré de Cisco témoin (CIMC) sorti

Voici une certaine sortie témoin :

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
 

Solution

Quand vous rencontrez cette erreur, l'alimentation Pilot2SrvPower.c:466:Blade a changé à : [HORS FONCTION] - actionnez la question, il signifie que l'ordinateur UCS perd l'alimentation. Par conséquent, vous devriez s'assurer que l'ordinateur UCS obtient l'alimentation suffisante.

Scénario 3 : Crash CUCM

Symptômes

Les crash VM CUCM mais répond toujours aux pings. Les affichages d'écran de console de vSphere ces informations :

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

Comment vérifier

Examinez ces suivis CUCM :

  • Unité de collecte de données de Cisco RIS PerfMonLog
  • Journal de l'observateur d'événements
  • Visualisateur d'événements - Log système
  • CCM détaillé

Il n'y a rien approprié dans les suivis CUCM. Le CUCM arrête avant l'incident et est suivi par une reprise normale de service. Ceci élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS où les passages CUCM a le problème. La plate-forme UCS a beaucoup d'exemples VM qui fonctionnent là-dessus. Si n'importe quelle VM rencontre une erreur, alors on le voit dans les logs UCS.

Le log UCS est exigé afin d'isoler l'emplacement de la cause. Référez-vous le comment collecter la section de logs UCS pour des instructions au sujet de la façon collecter les suivis.

Contournement

Mettez hors tension la VM et redémarrez-la. Après que la réinitialisation, le système fonctionne bien.

Scénario 4 : CUCM s'arrête

Symptômes

Le serveur CUCM va à un état où il s'arrête.

Comment vérifier

Examinez ces suivis CUCM :

  • Unité de collecte de données de Cisco RIS PerfMonLog
  • Journal de l'observateur d'événements
  • Visualisateur d'événements - Log système
  • CCM détaillé

Il n'y a rien approprié dans les suivis CUCM. Le CUCM arrête avant l'incident et est suivi par une reprise normale de service. Ceci élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS où les passages CUCM a le problème. La plate-forme UCS a beaucoup d'exemples VM qui fonctionnent là-dessus. Si n'importe quelle VM rencontre une erreur, alors on le voit dans les logs UCS.

Le log UCS est exigé afin d'isoler l'emplacement de la cause. Référez-vous le comment collecter la section de logs UCS pour des instructions au sujet de la façon collecter les suivis.

Contournement

Essayez une reprise manuelle pour voir si elle aide.

Scénario 5 : CUCM est en mode en lecture seule

Symptômes

Vous recevez cette erreur :

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

Comment vérifier 

Publisher (BAR) et un abonné (SOUS-TITRE) qui sont installés sur la même exposition d'ordinateur UCS l'erreur en lecture seule de mode. Le disque de reprise ne répare pas la question.

Il n'y a rien approprié dans les suivis CUCM. Le CUCM arrête avant l'incident et est suivi par une reprise normale de service. Ceci élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS où les passages CUCM a le problème. La plate-forme UCS a beaucoup d'exemples VM qui fonctionnent là-dessus. Si n'importe quelle VM rencontre une erreur, alors on le voit dans les logs UCS.

Le log UCS est exigé afin d'isoler l'emplacement de la cause. Référez-vous le comment collecter la section de logs UCS pour des instructions au sujet de la façon collecter les suivis.

Solution

Après remplacement de matériel, reconstruisez les Noeuds problématiques.

Comment collecter des logs UCS

Cette section décrit comment collecter les suivis requis pour identifier le problème ou fournit des liens aux articles qui prévoient ces informations.

Comment collecter les logs CIMC : Affichez le tech

Référez-vous à ces articles pour des informations sur la façon collecter les logs CICM :

Utilisant le GUI de Cisco CIMC pour collecter des détails d'exposition-tech

Guide visuel pour collecter des fichiers de support technique (B et séries C)

Comment collecter des logs ESXI : Logs système

Référez-vous à cet article pour des informations sur la façon collecter des logs ESXI :

Obtenir les informations de diagnostic pour des hôtes d'ESXi 5.x utilisant le client de vSphere 

Sortie témoin CIMC CLI

Voici un certain échantillon CIMC CLI sorti d'une panne de disque dur :

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

Voici un certain échantillon CICM CLI sorti de la panne de contrôleur 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

Sortie GUI témoin CIMC

Voici un certain GUI témoin CIMC sorti d'une panne de disque dur :

Voici un certain GUI témoin CIMC sorti d'une erreur pourpre d'écran :

(Panne de contrôleur d'incursion | Défaut : Exception 14 CSCuh86924 ESXi PSOD PF - Contrôleur RAID 9266-8i LSI)

Voici un certain GUI témoin CIMC sorti d'une panne BBU :


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118702