Problèmes courants de CUCM sur la plate-forme UCS : Coeur, CPU élevé - E/S, état de blocage

Options de téléchargement

  • PDF     (488.8 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (299.6 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (267.5 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:6 janvier 2015
ID du document:118702

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Ce document décrit comment dépanner cinq scénarios de problèmes courants rencontrés avec Cisco Unified Communications Manager (CUCM) sur la plate-forme Unified Computing System (UCS).

Les causes les plus courantes sont les suivantes :

  • Défaillance du disque dur
  • Panne du contrôleur RAID (Redundant Array of Independent Disks)
  • Panne de l'unité de sauvegarde de la batterie (BBU)

Scénario 1 : Utilisation élevée du CPU en raison d'un problème d'attente d'E/S

Symptômes

Les services Cisco Call Manager (CCM) et CTI (Computer Telephony Integration) redémarrent en raison du coeur CTI de CCM.

Comment vérifier

Traces CUCM

Utilisez ces commandes CLI afin de collecter les traces CUCM :

  • show process using-most cpu
  • show status
  • liste active principale utils
  • résultat de l’analyse du coeur de l’outil <dernière, deux dernières sorties>

Examinez ces journaux RTMT (Real-Time Monitoring Tool) :

  • CCM détaillé
  • CTI détaillé
  • PerfMonLogs du collecteur de données RIS (Real-time Information Server)
  • Journaux d'application de l'Observateur d'événements
  • Journaux système de l'observateur d'événements

Exemple de sortie

Voici un exemple de résultat :

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

À partir du collecteur de données RIS PerfMonLogs, vous pouvez voir des E/S de disque élevé pendant la durée du coeur de réseau.

Le backtrace correspond à l'ID de bogue Cisco CSCua79544 : Coeurs de processus CCM fréquents en raison d'E/S de disque élevé. Ce bogue décrit un problème matériel et explique comment isoler le problème.

Activer les rapports d'E/S de fichier (FIOR) :

Utilisez ces commandes afin d'activer FIOR :

utils fior start
utils fior enable

Ensuite, attendez la prochaine occurrence. Voici la commande CLI pour collecter les résultats : fichier get activelog platform/io-stats. Entrez ces commandes afin de désactiver FIOR :

utils fior stop
utils fior disable

Voici un exemple de sortie de journal 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.

Solution

L'attente d'E/S pose généralement un problème avec la plate-forme UCS et son stockage.

Le journal UCS est nécessaire pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Scénario 2 : Redémarrage périodique de CUCM

Symptômes

CUCM redémarre en raison d'une panne ESXI, mais le problème sous-jacent est que la machine UCS perd de l'énergie.

Comment vérifier

Examinez les traces CUCM suivantes :

  • PerfMonLog du collecteur de données Cisco RIS
  • Observateur d'événements - Journal d'applications
  • Observateur d'événements - Journal système
  • CCM détaillé

Il n'y a rien de pertinent dans les traces de CUCM. Le CUCM s'arrête avant l'incident et est suivi d'un redémarrage normal du service. Cela élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS sur laquelle CUCM s'exécute présente le problème. La plate-forme UCS comporte de nombreuses instances de machine virtuelle (VM) qui s'y exécutent. Si une machine virtuelle rencontre une erreur, elle apparaît dans les journaux UCS.

Le journal UCS est requis pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Exemple de sortie CIMC (Integrated Management Controller) de Cisco

Voici un exemple de résultat :

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

Lorsque vous rencontrez cette erreur, Pilot2SrvPower.c:466:Blade Power a été remplacé par : [ OFF ] - Problème d'alimentation, cela signifie que l'ordinateur UCS perd de l'alimentation. Par conséquent, vous devez vous assurer que la machine UCS est suffisamment alimentée.

Scénario 3 : plantages CUCM

Symptômes

La machine virtuelle CUCM plante mais répond toujours aux requêtes ping. L'écran de la console vSphere affiche les informations suivantes :

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

Comment vérifier

Examinez les traces CUCM suivantes :

  • PerfMonLog du collecteur de données Cisco RIS
  • Observateur d'événements - Journal d'applications
  • Observateur d'événements - Journal système
  • CCM détaillé

Il n'y a rien de pertinent dans les traces de CUCM. Le CUCM s'arrête avant l'incident et est suivi d'un redémarrage normal du service. Cela élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS sur laquelle CUCM s'exécute présente le problème. La plate-forme UCS comporte de nombreuses instances de VM qui s'exécutent sur elle. Si une machine virtuelle rencontre une erreur, elle apparaît dans les journaux UCS.

Le journal UCS est requis pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Solution de contournement

Mettez la machine virtuelle hors tension et redémarrez-la. Après le redémarrage, le système fonctionne correctement.

Scénario 4 : blocages CUCM

Symptômes

Le serveur CUCM passe à l'état où il se trouve.

Comment vérifier

Examinez les traces CUCM suivantes :

  • PerfMonLog du collecteur de données Cisco RIS
  • Observateur d'événements - Journal d'applications
  • Observateur d'événements - Journal système
  • CCM détaillé

Il n'y a rien de pertinent dans les traces de CUCM. Le CUCM s'arrête avant l'incident et est suivi d'un redémarrage normal du service. Cela élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS sur laquelle CUCM s'exécute présente le problème. La plate-forme UCS comporte de nombreuses instances de VM qui s'exécutent sur elle. Si une machine virtuelle rencontre une erreur, elle apparaît dans les journaux UCS.

Le journal UCS est requis pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Solution de contournement

Essayez un redémarrage manuel pour voir s'il aide.

Scénario 5 : CUCM est en mode 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 

Le serveur de publication (PUB) et un abonné (SUB) installés sur la même machine UCS affichent l'erreur de mode en lecture seule. Le disque de récupération ne résout pas le problème.

Il n'y a rien de pertinent dans les traces de CUCM. Le CUCM s'arrête avant l'incident et est suivi d'un redémarrage normal du service. Cela élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS sur laquelle CUCM s'exécute présente le problème. La plate-forme UCS comporte de nombreuses instances de VM qui s'exécutent sur elle. Si une machine virtuelle rencontre une erreur, elle apparaît dans les journaux UCS.

Le journal UCS est requis pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Solution

Après le remplacement du matériel, reconstruisez les noeuds problématiques.

Collecte des journaux UCS

Cette section décrit comment collecter les traces nécessaires pour identifier le problème ou fournit des liens vers des articles qui fournissent cette information.

Comment collecter les journaux CIMC : Afficher les technologies

Reportez-vous aux articles suivants pour obtenir des informations sur la collecte des journaux CICM :

Utilisation de l'interface utilisateur graphique de Cisco CIMC pour collecter des informations sur show-tech

Guide visuel pour collecter des fichiers d'assistance technique (séries B et C)

Comment collecter les journaux ESXI : Journaux système

Reportez-vous à cet article pour plus d'informations sur la collecte des journaux ESXI :

Obtention d'informations de diagnostic pour les hôtes ESXi 5.x à l'aide du client vSphere

Exemple de sortie CLI CIMC

Voici un exemple de sortie CLI CIMC d'une défaillance 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 exemple de sortie CLI CICM issue d'une défaillance du 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

Exemple de sortie de l’interface graphique du CIMC

Voici un exemple de sortie de l'interface utilisateur graphique CIMC d'une défaillance de disque dur :

Voici un exemple de sortie de l'interface utilisateur graphique CIMC à partir d'une erreur d'écran violet :

(défaillance du contrôleur RAID) | Défaut : CSCuh86924 ESXi PSOD PF exception 14 - contrôleur RAID LSI 9266-8i )

Voici un exemple de sortie de l'interface utilisateur graphique CIMC d'une défaillance BBU :

TAC Authored

Contribution d’experts de Cisco

  • Sivakumar Shanmugam
    Cisco TAC Engineer

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits